> For the complete documentation index, see [llms.txt](https://docs.rome.builders/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rome.builders/core-concepts/constraints.md). # Constraints Limits when building on Rome EVM — Solana transaction size, \~1.4M CU budget, account caps, storage layout, and how Rome works around each. Important limits and boundaries when building on Rome EVM. Understanding these constraints helps you design contracts that work reliably. ## Solana Transaction Limits | Constraint | Value | Impact | | -------------------- | ------------------ | ------------------------------------------------------------------------------------------------------- | | Transaction size | 4 KB (4,096 bytes) | Rome sends Solana v1 transactions; larger EVM txs are staged in holder accounts (transparent) | | Compute units per tx | \~1.4M CU | Operations exceeding this use iterative mode, which has its own caps (below) | | Accounts per tx | 64 addresses | The v1 transaction cap; everything the EVM tx and its CPIs touch, including Rome's own accounts, counts | | Max holder size | 80 KB | Max RLP size for a single EVM transaction | ## EVM Execution Limits | Constraint | Value | Notes | | ----------------------------------- | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Contract storage slots | 256 per storage account | Multiple storage accounts can be created per contract | | Opcodes per iteration | Adaptive | Packed to each Solana tx's CU budget (VmIt) | | Account lock TTL | 3 s (4 s when the session touches more than 28 accounts) | During iterative execution; renewed each step | | Iterative session length | 160 steps | Past the cap the next step releases the session's locks and ends it without committing anything | | Legs planned by the Rust Rome SDK | 128 | The iterative composer's ceiling; real calls settle in far fewer | | Transactions per wallet-signed plan | 64 | The most `rome_submitSignedV1Plan` accepts in one call; see [Relayed calls and long calls](/developer-guides/call-evm-from-solana.md#relayed-calls-and-long-calls) | | Treasury wallets | 64 | Fee pool wallets | | Contract size limit | 24 KB | Same as Ethereum (EIP-170, 24,576 bytes) | ## CPI Constraints | Constraint | Value | Notes | | ---------------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | CPI depth | 4 levels max | Solana's CPI depth limit | | Accounts per CPI call | Within the 64-address transaction cap | Shared with every other account the transaction touches | | CPI + Transfer Hook depth | Uses CPI levels | Transfer hooks from inside CPI may exceed depth | | One track per contract | Legacy (`0xff…07/08/09`, `0x42…16`) **or** cached (`0xff…04/05/06/0b`) | Mixing mutating calls from both in one transaction is refused | | Legacy CPI in iterative mode | Not allowed | A legacy-track CPI in an iterative transaction fails with `CpiProhibitedInIterativeTx`; cached-track effects are allowed | **CPI depth is the most critical constraint.** Rome EVM consumes one CPI level when Solana calls the Rome program. If your Solidity contract then calls another Solana program via CPI, that's level 2. If that program calls another, that's level 3. You have at most 4 levels total. ``` Level 0: Solana Runtime → Rome EVM Program Level 1: Rome EVM Program → Your CPI target (e.g., Jupiter) Level 2: Jupiter → another program (e.g., Raydium) Level 3: Raydium → SPL Token (maximum depth) ``` ## Token-2022 Transfer Hook Constraints | Constraint | Impact | | ----------------------- | ----------------------------------------------------------------------------------- | | One hook per mint | A Token-2022 mint has a single transfer-hook slot | | `transfer_checked` only | Hooks don't fire on plain `transfer`. Rome bridge operations use `transfer_checked` | | Mint/burn not hooked | Controlled via mint authority, not hooks | ## Gas and Pricing Constraints | Constraint | Notes | | -------------------- | ---------------------------------------------------------- | | Gas pricing source | Meteora DAMM pool, v1 or v2 (SPL gas token) | | Gas price multiplier | Configurable per proxy (`gas_price_mul`) | | Minimum gas price | Set by proxy configuration | | Gas estimation | Performed off-chain via Mollusk emulator before submission | ## Network-Specific Constraints | Environment | Chain ID | rome-evm Program ID | | ----------------- | -------- | --------------------------------------------- | | Hadrian (testnet) | 200010 | `RPTWwELXAY4KC9ZPHhaxp7Sq1hHtU3HNEgLbSegCcWf` | | Rubicon (mainnet) | 7531 | `RomePq9X3iAoTr813HR7uRarafFDUJty6GdiEceYpzX` | ## Precompile Constraints | Precompile | Constraint | | -------------------------- | ------------------------------------------------------------------------------------------------------------------ | | Modexp (0x05) | **Disabled** — a call reverts with `big_mod_exp call is disabled` until Solana activates the `big_mod_exp` syscall | | BN254 ecPairing (0x08) | About 22K CU plus 12.8K per pair by the program's pricing; a four-pair check fits one atomic transaction | | CPI precompile (0xFF...08) | Accounts must be declared upfront in the Solana transaction | ## Transaction Validation | Rule | Effect | | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Signature malleability (EIP-2) | A signed transaction whose `s` is above the curve order's half is rejected | | RLP shape | A transaction whose RLP list carries trailing bytes past its last item is rejected | | Unimplemented opcode | Aborts the whole transaction (`IncompatibleVersionEVM(opcode)`); nothing is committed and a calling contract cannot swallow it | | Gas metering | Rome has no per-opcode gas schedule: the gas passed to `CALL`/`CREATE` is not enforced, and there is no 2300-gas stipend — do not rely on stipend-based reentrancy protection | ## Oracle Constraints | Constraint | Value | | --------------------- | ------------------------------------------------------------ | | Default max staleness | 60 seconds | | Historical round data | Not supported — `getRoundData(roundId)` reverts | | Switchboard EMA | Not supported — `latestEMAData()` reverts on SwitchboardV3 | | Parser offsets | Empirically validated — must re-validate before redeployment | ## Design Recommendations 1. **Keep CPI depth shallow.** Design contracts to minimize nesting. If you're calling Jupiter which calls Raydium which calls SPL Token, you're at 3 levels — dangerously close to the limit. 2. **Prefer atomic mode.** Design operations to fit within \~1.4M CU. Iterative mode adds latency (3-4 second locks), a cap of 160 iterations per session, and a wallet prompt per leg on the Solana lane when the wallet signs the legs itself. A call that makes legacy-track CPIs cannot run iteratively at all. 3. **Declare accounts upfront.** All Solana accounts touched by CPI must be known at transaction creation time (the proxy's emulation discovers them). Dynamic account discovery within a CPI call is not possible, and the total must fit the 64-address cap. 4. **Pick one precompile track per contract.** Calling a custom Solana program (`invoke_signed`) is legacy-track and atomic-only; see [Integrate a Solana program](/developer-guides/integrate-solana-program.md). 5. **Use `transfer_checked`.** If you're building anything that touches Token-2022 tokens, always use `transfer_checked` to ensure hooks fire. 6. **Test CU consumption.** Measure real Solana compute units from the transaction receipt (`computeUnitsConsumed`) — EVM `gasUsed` is not a faithful proxy for Solana CU. Optimize with Yul for hot paths. ## What's Next * [Compute Budget](/core-concepts/compute-budget.md) — detailed CU costs per operation * [Token Interop](/core-concepts/token-interop.md) — ERC-20 ↔ SPL bridging model * [Precompile reference](/reference/precompiles.md) — every selector and its dispatch class --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.rome.builders/core-concepts/constraints.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.