# Cómo Crear un Smart Contract en Solidity: Guía 2026 | Alher Tech > Guía práctica 2026 para construir smart contracts en Solidity de nivel producción: patrones de diseño, optimización de gas, errores de seguridad, despliegue en Ethereum y L2s, y el flujo de desarrollo completo. - Canonical page: https://alhertech.com/es/guias-blockchain/como-crear-smart-contracts-solidity/ - Site: Alher Tech (custom software, AI agents and SEO engineering, https://alhertech.com/) - Contact: https://alhertech.com/es/contacto/ --- Solidity sigue siendo el lenguaje dominante para smart contracts en Ethereum, Arbitrum, Base, Polygon, Optimism y la mayoría de cadenas EVM. Construir uno es fácil. Construir uno que maneje dinero real en producción, y sobreviva a una auditoría, es otro deporte. Esta guía recorre el flujo que usamos en Alher Tech para entregar smart contracts en Solidity eficientes en gas, conscientes de upgrades y seguros por diseño. ## Cuándo Necesitas Realmente un Smart Contract Un smart contract es la herramienta correcta cuando necesitas hacer cumplir reglas on-chain, de forma verificable, entre partes que no se confían. Emisión de tokens, vesting, escrow, marketplaces, governance, lending y tokenización de activos reales califican. Si tu caso es solo una base de datos con un wallet pegado, un smart contract es matar moscas a cañonazos. Hemos rechazado proyectos donde una tabla en Postgres y un JWT entregaban el 95% del valor al 10% del coste. - Transferencia de valor entre múltiples partes sin intermediario - Reglas verificables (subastas, vesting, royalties, pagos) - Tokenización de activos, valores o derechos - Acceso sin permiso a un sistema (marketplaces abiertos, DEX) - La auditabilidad pública es parte de tu propuesta de valor El código de un smart contract es para siempre. Una vez desplegado y en uso, arreglar bugs sale caro, a veces imposible. Cada línea que escribas debe justificar su coste. ## El Flujo de Solidity en 2026 El desarrollo moderno en Solidity ya no va de Remix y un faucet. Los equipos serios usan un pipeline que detecta errores 1000 veces más barato que mainnet: - **Foundry como toolchain por defecto**: Más rápido que Hardhat, fuzz tests nativos, invariant tests, snapshots de gas y forge script para despliegue. Hardhat sigue ganando para integraciones ricas con JS, pero Foundry es el estándar serio. - **Solidity 0.8.24+ con storage nombrado**: Checks de overflow integrados, transient storage, errores custom y los nuevos patrones layout-aware. Los contratos en 0.6 ya son legacy. - **OpenZeppelin v5**: Implementaciones probadas en batalla para ERC-20, ERC-721, ERC-1155, AccessControl, UUPS upgradability. No reinventes lo que ya existe. - **Slither + Mythril + Aderyn en CI**: Análisis estático en cada PR. Detecta reentrancy, storage no inicializado y decenas de bugs comunes antes del code review. - **Tenderly + Anvil para debug local**: Anvil para nodos locales rapidísimos, Tenderly para simulación tipo producción, fork de mainnet y replay de transacciones cuando algo se rompe. ## Anatomía de un Contrato de Producción Abajo está el esqueleto del que partimos para cualquier contrato no trivial. Usa deliberadamente upgradability, control por rol, errores custom y guardas de reentrancy: las cuatro cosas que lamentas saltarte después. - Hereda de UUPSUpgradeable + AccessControlUpgradeable de OpenZeppelin - Usa errores custom (revert MyError(arg)) en vez de require strings; ahorra 50-200 gas por revert - Marca toda función que muta estado con check de rol explícito - Usa ReentrancyGuard en cada función externa que toca balances - Emite eventos en cada cambio de estado, porque los indexers y la analítica off-chain dependen de ellos - Funcionalidad Pausable durante los primeros 6-12 meses tras el lanzamiento El layout de storage es parte de tu API pública cuando eres upgradable. Documenta el orden de slots. Nunca reordenes variables existentes; solo añade al final. ## Optimización de Gas Que de Verdad Importa La mayoría de consejos de optimización en internet son prematuros. Esto es lo que mueve la aguja en 2026: - **Storage packing**: Empaqueta uint128 + uint128 en un solo slot en vez de dos uint256. Ahorra 20.000 gas en cada SSTORE. La optimización con mejor ROI. - **Errores custom sobre require strings**: Ahorra 50-200 gas por revert. Quita ~10KB del tamaño del contrato, ayudando a entrar bajo el límite Spurious Dragon de 24KB. - **Calldata sobre memory para arrays read-only**: Parámetros que no se modifican deben ser calldata. Ahorra gas en cada llamada. - **Cachea reads de storage en memory**: Leer la misma variable de storage dos veces en una función cuesta el doble. Cachéala una vez al principio. - **Bloques unchecked donde sea seguro**: Solidity 0.8+ añade checks de overflow en todas partes. En loops apretados donde el overflow es imposible, unchecked ahorra 30-50 gas por iteración. No optimices hasta haber perfilado con forge snapshot. La mayoría de veces el ahorro son 5.000 gas en una función de 200.000 y no compensa la pérdida de legibilidad. ## Seguridad: Los 8 Bugs Que Vacían el TVL De los más de 2.000 millones $ perdidos por exploits en 2024, ocho clases de bug acumulan más del 80% de incidentes. Interiorízalas. - **Reentrancy**: Llamada externa antes de actualizar estado deja al contrato llamado re-entrar y drenar fondos. Usa checks-effects-interactions y ReentrancyGuard. El bug que mató a The DAO y a muchos desde entonces. - **Errores de control de acceso**: onlyOwner ausente en initialize, funciones públicas que deberían ser internal, transferencia de roles sin confirmación en dos pasos. Audita cada función external/public. - **Overflow / underflow de enteros**: Solidity 0.8+ comprueba por defecto, pero los bloques unchecked reintroducen el riesgo. Mucho cuidado con matemáticas de bajo nivel. - **Manipulación de oráculos**: Usar precio spot de un AMM con poca liquidez es un exploit de dinero gratis esperando. Usa Chainlink, TWAPs de 30+ minutos o múltiples fuentes. - **Frontrunning / MEV**: El mempool público hace que cualquiera pueda sandwichear tus transacciones. Usa esquemas commit-reveal, routing MEV-Boost-aware o RPC privado en flujos sensibles. - **Replay de firmas**: Mensajes firmados off-chain sin nonce ni chain ID se pueden replayear entre chains o transacciones. EIP-712 con nonces correctos es el arreglo. - **Griefing de approvals/allowances**: Race condition de ERC-20 entre approve y transferFrom. Usa increaseAllowance/decreaseAllowance o Permit2. - **Errores lógicos en reglas de negocio**: La clase más difícil. Ninguna herramienta caza una dirección de redondeo errónea en un cálculo de fees. Para esto existen las auditorías manuales. ## Despliegue y Verificación El despliegue a mainnet son los 30 minutos más arriesgados de la vida de un contrato. El pipeline que usamos: - Despliega primero a Sepolia o Holesky. Lanza tests de integración al menos 7 días contra el contrato de testnet. - Usa un script de despliegue (forge script) revisado por pares. Nunca despliegues desde la terminal local de un dev. - Verifica en Etherscan inmediatamente. Los contratos no verificados rompen la confianza del usuario y el tooling. - Bloquea el admin inicial en un multisig Gnosis Safe desde el minuto cero. Nunca despliegues con admin EOA y 'plan de migrar luego'. - Time-lock de al menos 24h en todas las funciones upgradeables para que los usuarios reaccionen a propuestas maliciosas. - Monitoriza con Tenderly Alerts o Forta el primer mes. Quieres saberlo en el momento que algo anómalo pase. ## Constrúyelo Una Vez, Constrúyelo Bien Los smart contracts son infraestructura que maneja dinero real en un entorno adversarial. El coste de equivocarse no es un ticket de bug: es un TVL vacío en Twitter. Si vas a entregar un protocolo en 2026, no necesitas un freelancer con un tutorial de Solidity bajo el brazo. Necesitas ingenieros que han sobrevivido auditorías, gestionado respuestas a incidentes y entregado a mainnet sin perder fondos de usuarios. ## Preguntas frecuentes ### ¿Cuánto tarda construir un smart contract? Un ERC-20 simple con vesting tarda 1-2 semanas incluyendo tests. Un protocolo DeFi multi-contrato con preparación de auditoría son 8-16 semanas. La auditoría en sí añade otras 3-6 semanas según la firma. ### ¿Hardhat o Foundry? Foundry para proyectos nuevos en 2026. Más rápido, mejor testing, gas reporting nativo. Hardhat sigue ganando si estás muy integrado con un frontend JS/TS o necesitas plugins que no existen en Foundry. ### ¿Cuánto cuesta construir un smart contract en Solidity? 15.000-40.000 $ por un token simple + vesting. 60.000-200.000 $ por un protocolo a medida. Suma 25.000-150.000 $ por una auditoría seria. Multiplica por 1,5-2x en proyectos con tokenomics complejos o mecánicas novedosas. ### ¿Necesito auditoría si mi código es un fork de un protocolo probado? Sí. Los forks introducen bugs sutiles en los puntos de integración y elecciones de parámetros. Hasta un fork 'simple' de Uniswap ha costado millones cuando pequeñas modificaciones interactuaron mal con el resto del protocolo. ### ¿En qué chain debería desplegar? Ethereum mainnet por prestigio y TVL. Arbitrum o Base por UX barata. Polygon para emerging markets y gaming. Optimism por grants del ecosistema. Elige según dónde están tus usuarios reales, no por lo más barato. ## Guías relacionadas - [Auditoría de smart contracts: cómo preparar tu código](https://alhertech.com/es/guias-blockchain/auditoria-smart-contracts/) - [¿Cuánto cuesta desarrollar una DApp en 2026?](https://alhertech.com/es/guias-blockchain/cuanto-cuesta-desarrollar-dapp/) - [Nuestros servicios de desarrollo blockchain](https://alhertech.com/es/servicios/desarrollo-blockchain/) - [Pide una estimación de smart contract](https://alhertech.com/es/contacto/)