Rome Protocol ha publicado los detalles de conexión de su testnet Hadrian, ofreciendo a los desarrolladores un entorno financiado con USDC para probar aplicaciones de estilo Ethereum dentro de Solana, mientras que su documentación enumera por separado una red mainnet llamada Rubicon.
Resumen
- El testnet Hadrian de Rome se ejecuta en Solana Devnet, mientras que su documentación enumera por separado Rubicon como mainnet.
- Las implementaciones de Compound v3 y Aave v3 siguen siendo aplicaciones de referencia, sin migraciones oficiales de protocolo confirmadas.
- Hadrian utiliza USDC de prueba para el gas, con el precio de las transacciones controlado mediante configuraciones de operador configurables.
- Rome informa de una auditoría de Halborn, mientras que su documentación enumera la compatibilidad con Ethereum y los límites de ejecución.
La publicación del 18 de octubre de Rome Protocol identifica a Hadrian como un testnet que se ejecuta en Solana Devnet, con ID de cadena 200010, un endpoint RPC, un explorador e instrucciones para obtener USDC de prueba. La captura de pantalla proporcionada dirige a los desarrolladores al faucet de Circle y a una interfaz de puente para financiar sus billeteras.
La documentación para desarrolladores del proyecto enumera a Rubicon por separado como mainnet, con ID de cadena 7531 y un endpoint RPC diferente. Su página introductoria describe a Rubicon como usando USDC real, distinguiendo el entorno de producción de los activos de prueba de Hadrian.
La EVM de Rome ejecuta código Solidity dentro de Solana
La documentación de ejecución de Rome describe una Máquina Virtual de Ethereum implementada como un programa de Solana. Un proxy recibe transacciones firmadas de estilo Ethereum, las verifica mediante un emulador fuera de cadena y empaqueta sus instrucciones para su ejecución por los validadores de Solana.
Según la arquitectura descrita por el proyecto, los contratos Solidity pueden llamar a programas nativos de Solana mediante invocación entre programas, o CPI. Los desarrolladores pueden usar herramientas familiares de Ethereum mientras sus contratos se ejecutan dentro del runtime de Solana.
La documentación describe un estado de aplicación compartido entre usuarios de EVM y de Solana. Su afirmación de que no se necesita un puente se refiere a las interacciones dentro de ese entorno; las instrucciones de financiación de Hadrian dirigen por separado a los usuarios a un puente cuando traen USDC de prueba a la red.
La guía de ejecución de Rome distingue dos modos de procesamiento. Las operaciones que caben dentro de una sola transacción de Solana utilizan ejecución atómica, donde la transacción completa tiene éxito o se revierte en conjunto.
Para operaciones más exigentes, la misma guía describe una ejecución iterativa a través de varias transacciones de Solana. Las cuentas se bloquean durante el procesamiento y los efectos en caché se confirman al final. El proyecto enumera un límite de sesión de 160 pasos y restricciones sobre qué llamadas a programas de Solana pueden usar ese modo.
La capacidad de transacciones de Solana ha sido objeto de cambios de red separados. En un informe del 30 de agosto, Jacob Creech describió un movimiento planificado de transacciones de 1.232 bytes a un formato de 4.096 bytes, como informó previamente crypto.news. El anuncio programó Transaction V1 para el 9 de septiembre y trató las reducciones de tiempo de slot y Alpenglow como actualizaciones separadas.
Las implementaciones de Compound y Aave siguen siendo aplicaciones de referencia
La guía de Hadrian de Rome nombra a Uniswap, Compound y Aave como aplicaciones de referencia validadas primero en el testnet.
El repositorio Aerarium del proyecto describe una aplicación de préstamos Compound v3 con dos rutas de billetera que comparten un único pool de préstamos. Una ruta acepta transacciones firmadas de estilo Ethereum a través de MetaMask; la otra usa Phantom y una identidad derivada de Solana sin requerir una clave de Ethereum.
Según ese repositorio, ambas rutas acceden al mismo mercado Comet, cubriendo depósitos de USDC, depósitos de garantía, préstamos, pagos y retiros. La dirección de la aplicación listada usa un dominio de devnet. GitHub
El repositorio de la interfaz de Aave de Rome llama explícitamente al producto una demo y lo sitúa en Hadrian. Su repositorio de contratos adjunto describe un fork del código de Aave.
Esos materiales establecen cómo Rome presenta sus implementaciones. No establecen que la organización gobernante de ninguno de los dos protocolos de préstamos haya aprobado un despliegue en producción ni haya trasladado posiciones de usuarios existentes a Rome.
Rome ha buscado otras aplicaciones financieras mediante asociaciones. En marzo de 2025, el proyecto anunció su colaboración con KiiChain en activos tokenizados y finanzas de pagos entre cadenas para América Latina. Los ejecutivos describieron planes que involucran bienes raíces, productos agrícolas y acceso a la liquidez de Solana.
Los pagos de gas en USDC dependen de la configuración del operador
La guía de red de Hadrian especifica USDC como su token de gas e identifica el mint de USDC de Circle en Solana Devnet. Los desarrolladores que financian desde Solana necesitan USDC de prueba y algo de SOL de devnet, según la guía.
El faucet de Circle admite tanto Solana Devnet como Ethereum Sepolia. El proveedor describe los tokens del faucet como activos de prueba sin valor en el mundo real y actualmente indica una distribución de 20 USDC de prueba por solicitud, sujeta a sus límites.
La documentación de cadena de aplicación de Rome permite a un operador seleccionar un token SPL para pagos de gas y dirigir los ingresos por comisiones de transacción a una tesorería de la aplicación.
La misma documentación describe un servicio de precios que convierte el token de gas elegido frente a SOL para los costos subyacentes de transacción en Solana. Su configuración puede obtener precios de pools de Meteora o de un respaldo de Pyth/Hermes.
La página de restricciones de Rome enumera precios mínimos de gas configurables y un multiplicador a nivel de proxy. Por lo tanto, el marco publicado describe una fijación de precios configurable, sin establecer un costo universal en dólares para cada transacción de aplicación.
Las afirmaciones de auditoría y compatibilidad conllevan límites definidos
El repositorio EVM de Rome identifica un programa de mainnet y afirma que Halborn lo auditó. El repositorio proporciona instrucciones para reconstruir el programa y compararlo con el binario desplegado, con los metadatos de tiempo de compilación y hash de commit enmascarados durante la comparación.
La documentación de compatibilidad del proyecto enumera diferencias con Ethereum, incluida la funcionalidad de exponenciación modular deshabilitada y un comportamiento del gas que no reproduce el esquema por operación de Ethereum.
La página de restricciones indica que las transacciones de Rome deben declarar las cuentas de Solana que tocan antes de la ejecución. Enumera un límite de transacción de 64 direcciones y aproximadamente 1,4 millones de unidades de cómputo por transacción. La guía recomienda medir el consumo real de cómputo de Solana a partir de los recibos de transacción, porque la cifra de gas usado de la EVM no representa fielmente ese uso de recursos.
Su tabla de despliegue en mainnet nombra una cartera multifirma de Squads como autoridad de actualización.
Proyectos de interoperabilidad separados se han dirigido a mercados institucionales. En agosto, Interstice Digital anunció un motor de intercambio entre cadenas que conecta Canton con Ethereum, Solana y Robinhood Chain. FalconX proporciona liquidez, mientras que Interstice dijo que no custodia activos de clientes ni ejecuta transacciones en nombre de los usuarios.
