Rome Protocol has published connection details for its Hadrian testnet, giving developers a USDC-funded environment to try Ethereum-style applications inside Solana, while its documentation separately lists a mainnet network called Rubicon.
Summary
- Rome’s Hadrian testnet runs on Solana Devnet, while its documentation separately lists Rubicon as mainnet.
- Compound v3 and Aave v3 implementations remain reference applications, without confirmed official protocol migrations.
- Hadrian uses test USDC for gas, with transaction pricing controlled through configurable operator settings.
- Rome reports a Halborn audit, while its documentation lists Ethereum compatibility and execution limits.
Rome Protocol’s Oct. 18 post identifies Hadrian as a testnet running on Solana Devnet, with chain ID 200010, an RPC endpoint, an explorer, and instructions for obtaining test USDC. The supplied screenshot directs developers to Circle’s faucet and a bridge interface to fund their wallets.
The project’s developer documentation lists Rubicon separately as mainnet, with chain ID 7531 and a different RPC endpoint. Its introductory page describes Rubicon as using real USDC, distinguishing the production environment from Hadrian’s testing assets.
Rome EVM runs Solidity code within Solana
Rome’s execution documentation describes an Ethereum Virtual Machine implemented as a Solana program. A proxy receives signed Ethereum-style transactions, checks them through an offchain emulator, and packages their instructions for execution by Solana validators.
According to the architecture described by the project, Solidity contracts can call native Solana programs through cross-program invocation, or CPI. Developers can use familiar Ethereum tools while their contracts execute within Solana’s runtime.
The documentation describes shared application state between EVM and Solana users. Its statement that no bridge is needed concerns interactions inside that environment; Hadrian’s funding instructions separately direct users to a bridge when bringing test USDC into the network.
Rome’s execution guide distinguishes two processing modes. Operations that fit within one Solana transaction use atomic execution, where the complete transaction succeeds or reverts together.
For more demanding operations, the same guide describes iterative execution across several Solana transactions. Accounts are locked during processing, and cached effects are committed at the end. The project lists a 160-step session limit and restrictions on which Solana program calls can use that mode.
Solana’s transaction capacity has been the subject of separate network changes. In an Aug. 30 report, Jacob Creech outlined a planned move from 1,232-byte transactions to a 4,096-byte format, as crypto.news previously reported. The announcement scheduled Transaction V1 for Sept. 9 and treated slot-time reductions and Alpenglow as separate upgrades.
Compound and Aave implementations remain reference applications
Rome’s Hadrian guide names Uniswap, Compound and Aave as reference applications validated first on the testnet.
The project’s Aerarium repository describes a Compound v3 lending application with two wallet routes sharing one lending pool. One route accepts Ethereum-style signed transactions through MetaMask; the other uses Phantom and a Solana-derived identity without requiring an Ethereum key.
According to that repository, both routes access the same Comet market, covering USDC deposits, collateral deposits, borrowing, repayments, and withdrawals. The listed application address uses a devnet domain. GitHub
Rome’s Aave interface repository explicitly calls the product a demo and places it on Hadrian. Its accompanying contract repository describes a fork of Aave’s code.
Those materials establish how Rome presents its implementations. They do not establish that either lending protocol’s governing organization has approved a production deployment or moved existing user positions to Rome.
Rome has pursued other financial applications through partnerships. In March 2025, the project announced work with KiiChain on tokenized assets and cross-chain payment finance for Latin America. Executives described plans involving real estate, agricultural commodities and access to Solana liquidity.
USDC gas payments depend on operator configuration
Hadrian’s network guide specifies USDC as its gas token and identifies Circle’s Solana Devnet USDC mint. Developers funding from Solana need test USDC and some devnet SOL, according to the guide.
Circle’s faucet supports both Solana Devnet and Ethereum Sepolia. The provider describes faucet tokens as testing assets without real-world value and currently lists a distribution of 20 test USDC per request, subject to its limits.
Rome’s application-chain documentation allows an operator to select an SPL token for gas payments and route transaction-fee revenue to an application treasury.
The same documentation describes a pricing service that converts the chosen gas token against SOL for underlying Solana transaction costs. Its configuration can draw prices from Meteora pools or a Pyth/Hermes fallback.
Rome’s constraints page lists configurable minimum gas prices and a proxy-level multiplier. The published framework therefore describes configurable pricing, without establishing one universal dollar cost for every application transaction.
Audit and compatibility claims carry defined limits
Rome’s EVM repository identifies a mainnet program and says Halborn audited it. The repository provides instructions for rebuilding the program and comparing it with the deployed binary, with build-time and commit-hash metadata masked during comparison.
The project’s compatibility documentation lists differences from Ethereum, including disabled modular-exponentiation functionality and gas behavior that does not reproduce Ethereum’s per-operation schedule.
The constraints page says Rome transactions must declare the Solana accounts they touch before execution. It lists a 64-address transaction cap and approximately 1.4 million compute units per transaction. The guide recommends measuring actual Solana compute consumption from transaction receipts because the EVM gas-used figure does not faithfully represent that resource use.
Its mainnet deployment table names a Squads multisignature wallet as upgrade authority.
Separate interoperability projects have targeted institutional markets. In August, Interstice Digital announced a cross-chain swap engine linking Canton with Ethereum, Solana and Robinhood Chain. FalconX supplies liquidity, while Interstice said it does not hold customer assets or execute transactions on users’ behalf.
Be the first to comment