Cómo Crear un Smart Contract en Solidity: Guía 2026

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.