--- title: "Desarrollo para Ethereum (EVM)" url: "https://www.unknowngravity.com/servicios/desarrollo-para-ethereum-evm" site: Unknown Gravity published: "2025-01-28T13:45:14+00:00" modified: "2026-07-15T10:51:34+00:00" language: es-ES description: "Desarrollamos soluciones personalizadas para Ethereum (o EVMs compatibles), la blockchain más confiable y utilizada en el ecosistema cripto." section: "Inicio > Desarrollo para Ethereum (EVM)" --- # Desarrollo para Ethereum (EVM) > El desarrollo para Ethereum y EVM consiste en programar contratos inteligentes en Solidity para la Máquina Virtual de Ethereum, compatible además con Polygon, Arbitrum, Base, Optimism, Avalanche y BNB Chain. Un mismo contrato puede desplegarse en varias de esas redes. Unknown Gravity desarrolla y audita sobre este ecosistema. CONTRATOS INTELIGENTES SEGUROS DAPPS, TOKENIZACIÓN Y NFTS COMPATIBILIDAD MULTI-CHAIN [Agenda una reunión](/meeting) El desarrollo para Ethereum y EVM consiste en programar contratos inteligentes en Solidity para la Máquina Virtual de Ethereum, compatible además con Polygon, Arbitrum, Base, Optimism, Avalanche y BNB Chain. Un mismo contrato puede desplegarse en varias de esas redes. Unknown Gravity desarrolla y audita sobre este ecosistema. **Desarrollamos contratos inteligentes, tokens y aplicaciones sobre Ethereum y el resto de redes compatibles con la EVM.** Un mismo lenguaje, un mismo modelo de seguridad y la libertad de desplegar en la red que encaje con tus costes. ## 01 / ¿Por qué desarrollar en Ethereum (EVM)? La máquina virtual de Ethereum (EVM) es el entorno de ejecución que comparten Ethereum y decenas de redes: Arbitrum, Base, Polygon, Optimism o BNB Chain. Elegirla es entrar en el ecosistema con las herramientas más maduras, más auditores disponibles y las carteras que tus usuarios ya tienen instaladas. Se traduce en tres ventajas concretas: **los estándares ya están escritos**, **el talento existe** y **la infraestructura de terceros está integrada**. **Cuándo no tiene sentido.** Si necesitas datos personales en cadena, confidencialidad entre participantes o miles de operaciones por segundo, una red pública EVM no es la respuesta: ahí planteamos una red permisionada o descartamos blockchain. Decirlo antes de firmar ahorra presupuesto. ## 02 / Elegir red: mainnet de Ethereum, L2 o cadena compatible La red condiciona el coste por operación, el tiempo hasta que una transacción es irreversible y la complejidad de mover fondos. Tres criterios: - **Coste de gas.** La [mainnet de Ethereum](/blockchain/desarrollo-blockchain-ethereum) es la opción cara y la que menos supuestos exige. Un rollup como [Arbitrum](/blockchain/desarrollo-blockchain-arbitrum) o Base reduce el coste por transacción en órdenes de magnitud, a cambio de confiar en su secuenciador. - **Finalidad.** Una confirmación rápida en un L2 no equivale a finalidad en Ethereum: en los rollups optimistas la ventana de retirada al L1 se mide en días. Si liquidas contra un banco o un registro, ese detalle entra en el diseño desde el primer día. - **Puentes.** Cada puente añade superficie de ataque. Preferimos el puente canónico de la red antes que puentes de terceros y reducimos al mínimo los saltos entre cadenas. ## 03 / Contratos en Solidity: Foundry, OpenZeppelin y estándares ERC Escribimos en Solidity y partimos de **OpenZeppelin** para lo que ya está resuelto y revisado: control de acceso por roles, pausado de emergencia, implementaciones de ERC-20, ERC-721 y ERC-1155. El código propio queda para la lógica de negocio, que es donde merece la pena revisar línea a línea. El entorno es **Foundry** (tests en Solidity, fuzzing, invariantes y medición de gas), con **Hardhat** cuando hacen falta scripts en TypeScript. Todo contrato pasa por tests unitarios, pruebas contra un fork de la red real y análisis estático antes de acercarse a un despliegue. Un aviso que damos siempre: **el estándar del token no determina su naturaleza jurídica**. Un ERC-20 puede ser un criptoactivo bajo MiCA o un instrumento financiero sujeto a la LMVSI y a MiFID II, con obligaciones distintas. Conviene cerrar esa clasificación antes de fijar suministro y permisos; el [clasificador MiCA/MiFID](/clasificador-mica-mifid) da una primera orientación. ## 04 / Seguridad y patrones de despliegue Un contrato desplegado ya no se parchea a la ligera. El gobierno del sistema se decide antes de escribirlo: - **Actualizabilidad.** Proxy UUPS o transparente si el producto va a evolucionar; contrato inmutable si el compromiso es que nadie pueda cambiar las reglas. - **Claves y permisos.** Las funciones privilegiadas se firman desde un multisig, nunca desde una clave individual, y los cambios sensibles pasan por un timelock que da margen de reacción. - **Frenos.** Pausa de emergencia, límites por operación y separación entre el contrato que custodia fondos y el que ejecuta la lógica. Antes de mainnet, revisión externa: para cualquier sistema que custodie valor recomendamos una [auditoría de smart contracts](/servicios/auditoria-smart-contracts) hecha por alguien distinto de quien escribió el código. ## 05 / Despliegue, verificación y monitorización El despliegue se ejecuta con scripts versionados y reproducibles, no a mano desde una consola. El código se **verifica en el explorador** de cada red para que cualquiera pueda cotejar el bytecode publicado con el fuente. Al cerrar el proyecto recibes: - Repositorio con contratos, tests y scripts de despliegue. - Direcciones y código verificado en cada red, con los hashes de las transacciones de despliegue. - Documento de arquitectura: roles, funciones privilegiadas y procedimiento de actualización y de pausa. - Monitorización de eventos y alertas sobre las funciones críticas, con el runbook de respuesta. La monitorización no es opcional: un contrato sin vigilancia solo avisa cuando el daño ya está hecho. FAQ ## Preguntas frecuentes **¿Qué es la EVM y por qué importa?** La EVM (Ethereum Virtual Machine) es el entorno que ejecuta los contratos inteligentes en Ethereum. Que otras redes sean compatibles con EVM significa que aceptan el mismo bytecode y las mismas herramientas: quien desarrolla para Ethereum puede desplegar en Arbitrum, Polygon o Base sin cambiar de stack. **¿Mainnet de Ethereum o una red L2?** Depende del importe de cada operación y de quién asume la confianza. Con muchas transacciones pequeñas de usuario final, una L2 gana por coste. Si el sistema liquida importes altos o necesita finalidad en Ethereum sin intermediarios, la mainnet lo justifica. También se combinan ambas. **¿Se puede modificar un contrato ya desplegado?** Solo si se diseñó para ello. Con un patrón de proxy se puede sustituir la lógica manteniendo estado y dirección, bajo las llaves y los plazos definidos. Un contrato inmutable no admite cambios: la única vía es desplegar uno nuevo y migrar. Es una decisión de producto y conviene tomarla al principio. Esta página es informativa. No es asesoramiento jurídico, fiscal ni de inversión, ni sustituye al análisis de cada caso. Las normas citadas cambian: consulta la versión vigente en el [BOE](https://www.boe.es) y en [EUR-Lex](https://eur-lex.europa.eu). SERVICIOS RELACIONADOS [Consultoría Blockchain para Empresas en España](/servicios/consultoria-blockchain) [Desarrollo de DApps: Aplicaciones Descentralizadas](/servicios/aplicaciones-descentralizadas-dapps) [Desarrollo de smart contracts](/servicios/empresa-desarrollo-smart-contracts) [Emisión de tokens](/servicios/emision-de-tokens) [Real World Assets (RWA)](/servicios/real-world-assets-rwa) [Tokenomics](/servicios/tokenomics) [Whitepapers](/servicios/whitepapers) [Todos los servicios blockchain](/servicios)