> 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/compute-budget.md). # Compute Budget Solana compute unit (CU) costs for Rome EVM operations — atomic vs. iterative budgets and how to design CU-efficient Solidity contracts. Every Solana transaction has a compute budget measured in Compute Units (CU). Understanding CU costs helps you design efficient Rome contracts. ## Budget Overview | Mode | Max CU | Notes | | ---------------- | ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | Atomic (VmAt) | \~1,400,000 CU | Single Solana transaction | | Iterative (VmIt) | Up to \~1,400,000 CU per leg; at most 160 iterations per session | Each leg is its own Solana transaction; adaptive opcodes/step — packed to each tx's CU budget | Each Solana transaction has a default budget of 200,000 CU, extendable to \~1.4M CU via compute budget instructions (added automatically by the Rome SDK). Iterative execution is not unlimited. One session ends after 160 iterations, and the Rust Rome SDK's iterative composer plans at most 128 legs. A plan the wallet signs itself goes through `rome_submitSignedV1Plan`, which accepts at most 64 transactions per call. Most calls need far fewer. Legacy-track CPIs are refused inside an iterative session, so a call that makes them has to fit the atomic budget. See [Relayed calls and long calls](/developer-guides/call-evm-from-solana.md#relayed-calls-and-long-calls) and [Constraints](/core-concepts/constraints.md). ## CU Cost Estimates ### EVM Operations | Operation | Approximate CU | Notes | | ------------------------------------------ | -------------------- | ---------------------------------------------------------------------------------- | | Transaction signature check (EVM-key lane) | \~25,000 CU | The `secp256k1_recover` syscall, the same cost as the `ecrecover` precompile below | | Simple transfer | \~50,000-100,000 CU | Balance updates only | | ERC-20 transfer | \~100,000-150,000 CU | Includes SPL precompile call | | Contract deployment (small) | \~200,000-400,000 CU | Depends on bytecode size | | Storage write (SSTORE) | \~5,000-20,000 CU | Cold vs warm access | ### Precompile Operations | Precompile | Approximate CU | Notes | | --------------- | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ecrecover | \~25,700 CU | | | SHA-256 | \~257 CU per 32-byte word measured | Plus a small fixed cost. The program prices SHA-256, RIPEMD-160 and the identity precompile with one shared per-word figure of about 2,200 CU, sized to RIPEMD-160, the costliest of the three, so a SHA-256 call is charged more than it uses | | BN254 ecAdd | Close to 0 CU | Cheaper than copying 32 bytes | | BN254 ecMul | \~4,200 CU | | | BN254 ecPairing | \~22,000 CU plus \~12,800 CU per pair | A four-pair check is about 73,000 CU, well inside one atomic transaction | These figures come from the program's own calibration, which used compute units read back from a Solana node on a testnet deployment. They are not re-measured for this page; measure your own call with `computeUnitsConsumed`. ## Optimization Techniques ### 1. Use Yul for Hot Paths Solidity's optimizer produces reasonable code, but Yul (inline assembly) can reduce CU significantly for critical operations: ```solidity // Before: ~600K CU function createPairAccount(bytes32 token0, bytes32 token1) external { // Solidity-level operations } // After: ~150K CU (Yul optimization) function createPairAccount(bytes32 token0, bytes32 token1) external { assembly { // Direct memory manipulation, skip ABI encoding overhead } } ``` ### 2. Cache PDA Derivations PDA derivation via `find_program_address` is expensive. Store derived PDAs in contract storage rather than computing them on every call: ```solidity mapping(address => bytes32) private cachedPdas; function getPda(address user) internal returns (bytes32) { bytes32 cached = cachedPdas[user]; if (cached != bytes32(0)) return cached; bytes32 pda = RomeEVMAccount.pda(user); cachedPdas[user] = pda; return pda; } ``` ### 3. Hardcode Known Program IDs Don't load program IDs from storage — use constants: ```solidity // Expensive: reads from storage bytes32 splTokenProgram = storage_program_id; // Cheap: compile-time constant bytes32 constant SPL_TOKEN_PROGRAM = 0x06ddf6e1d765a193d9cbe146ceeb79ac1cb485ed5f5b37913a8cf5857eff00a9; ``` ### 4. Minimize Account Count Each account in a Solana transaction adds CU overhead. Reduce the number of accounts by: * Batching operations that share accounts * Using fewer intermediate accounts * Avoiding redundant ATA creation checks ### 5. Use Optimizer Settings ```typescript // hardhat.config.ts — enable the optimizer in a build profile solidity: { profiles: { default: { version: "0.8.28" }, production: { version: "0.8.28", settings: { optimizer: { enabled: true, runs: 200 } }, }, }, } ``` Build with `npx hardhat compile --build-profile production`. ## Measuring CU Consumption Use `eth_estimateGas` to measure CU before submitting: ```bash cast estimate --rpc-url https://hadrian.testnet.romeprotocol.xyz/ \ 0xCONTRACT "myFunction(uint256)" 42 ``` Or via ethers.js: ```javascript const gas = await contract.myFunction.estimateGas(42); console.log("Estimated gas:", gas.toString()); ``` ## What's Next * [Constraints](/core-concepts/constraints.md) — full list of limits and boundaries --- # 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/compute-budget.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.