Rome Protocol

• Name: Rome Protocol
• URL: https://www.rome.builders/
• Category: EVM-on-Solana execution environment / sovereign appchain infrastructure / oracle and compliance middleware
• Summary: Rome Protocol is best cataloged as an EVM execution environment that runs natively inside the Solana runtime, plus a growing product stack built around that core. Its official materials position Rome as a way for Solidity developers and app teams to keep standard Ethereum tooling while gaining atomic access to Solana programs, Solana liquidity, and custom per-app EVM environments. The most useful current source of truth is the docs corpus rather than a canonical whitepaper.
• What it does:
  • Embeds an EVM bytecode interpreter inside a Solana onchain program so Solidity contracts can execute within the Solana runtime
  • Exposes standard Ethereum-style JSON-RPC through Rome Proxy and, optionally, a modified OP-Geth layer for fuller Ethereum RPC compatibility
  • Lets app teams launch sovereign EVM environments on Solana with their own chain ID, their own SPL gas token, and fee revenue routed to the application treasury
  • Offers additional product surfaces including Oracle Gateway (Pyth and Switchboard exposed through Chainlink-style interfaces), Meta-Hook Router for Token-2022 compliance hooks, and DeFi Composer / Rome SDK tooling
  • Emphasizes single-state interoperability, where EVM users and Solana users share the same underlying application state and liquidity rather than bridging between separate systems
• Key claims:
  • The docs describe Rome as an “EVM execution environment running natively inside the Solana runtime,” with “single state” and atomic CPI access to Solana programs as the main differentiators
  • The architecture docs say Rome embeds a SputnikVM-fork bytecode interpreter in a Solana BPF program and maps Ethereum addresses to Solana PDAs while exposing precompiles for SPL and CPI access
  • The App Sovereignty docs say each app can get its own chain ID, custom gas token, and full fee accrual to the app treasury instead of sharing fees with a broader L2 or sequencer network
  • The docs are unusually candid about limitations, including a single-operator deployment model, OP-Geth divergence risk, account-locking during iterative execution, and several token / oracle edge cases
  • The public GitHub org currently shows no public repositories, so the docs and website carry more of the observable primary-source burden than open-source code does in this pass
• Whitepaper: No canonical Rome Protocol whitepaper or litepaper was found in this pass. The strongest current primary sources were the official website plus the docs corpus, especially the Getting Started, Architecture, Execution Model, Token Interop, App Sovereignty, and Known Limitations pages; see ../whitepapers/rome-protocol-primary-sources-2026-04-27.md.
• Sources:
  • https://www.rome.builders/
  • https://docs.rome.builders/
  • https://docs.rome.builders/readme.md
  • https://docs.rome.builders/getting-started/architecture
  • https://docs.rome.builders/products/app-sovereignty
  • https://docs.rome.builders/security/known-limitations
  • https://docs.rome.builders/readme.md?ask=What%20are%20Rome%20Protocol%27s%20core%20products%2C%20target%20users%2C%20and%20key%20technical%20differentiators%3F
  • https://docs.rome.builders/readme.md?ask=Does%20Rome%20Protocol%20publish%20a%20canonical%20whitepaper%20or%20litepaper%2C%20and%20what%20documents%20are%20the%20best%20current%20source%20of%20truth%3F
  • https://github.com/rome-labs
• Last reviewed: 2026-04-27 UTC