> 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/security/known-limitations.md).

# Known Limitations

Current Rome EVM constraints and their implications — unsupported opcodes, storage account layout, CU ceilings, CPI depth, and oracle limits.

Honest documentation of Rome Protocol's current constraints and their implications.

## Execution Limitations

**SELFDESTRUCT not supported.** The opcode has no handler, so a contract that executes it aborts the whole transaction (see below), it does not revert a single frame.

**An opcode Rome does not implement aborts the whole transaction.** The interpreter has no handler for the byte, so the transaction ends with `IncompatibleVersionEVM(opcode)`, nothing it did is committed, and the failure reaches the sender instead of being swallowed by a calling contract.

**No per-opcode gas schedule.** The gas value passed to `CALL`, `DELEGATECALL`, `STATICCALL` and `CREATE` is accepted for ABI compatibility but not enforced — a callee runs with the caller's full remaining budget, and there is no 2300-gas stipend. Stipend-based reentrancy protection (`transfer()` / `send()`) is void on Rome; use explicit reentrancy guards and checks-effects-interactions.

**Modexp (0x05) is disabled.** A call reverts with `big_mod_exp call is disabled` until Solana activates the `big_mod_exp` syscall.

**256 storage slots per storage account.** Contract storage is partitioned across Solana accounts with 256 slots each. Contracts with large storage footprints use multiple accounts, which affects CU costs.

**\~1.4M compute units per atomic transaction.** Work that exceeds a single Solana transaction's budget falls back to iterative execution (split across multiple transactions). Some operations are atomic-only and can't run iteratively — notably legacy-track CPI (`CpiProhibitedInIterativeTx`; cached-track effects are staged and do run iteratively).

**CPI depth limit of 4.** Deeply nested CPI calls will fail. Design contracts with shallow call trees.

## Oracle Limitations

**No historical round data.** Oracle Gateway adapters only support `latestRoundData()`. Historical price queries via `getRoundData(roundId)` revert.

**Parser offsets are validated against current layouts.** Pyth and Switchboard account data is parsed using byte offsets. If Pyth or Switchboard change their account layout, adapters return incorrect data until offsets are re-validated.

## Tooling Limitations

**No Ethereum-style transaction tracing.** `debug_traceTransaction` and `trace_*` are not supported. The one trace method is `debug_traceRomeTransaction`, which breaks a transaction that bundles several calls into one batch into its sub-calls and CPIs. Ordinary transactions return `null`. For everything else, use `eth_call` and the [Via explorer](/apps-on-rome/via.md) (which shows the Solana instructions behind a transaction) to debug. See [JSON-RPC](/reference/json-rpc.md).

**`eth_getLogs` is range-capped.** Public chains reject overly wide block ranges (error `-32005`); bound your queries. See [JSON-RPC](/reference/json-rpc.md).

## Infrastructure Limitations

**Single operator model.** Each Rome deployment is operated by a single entity (the payer pool operator). There is no decentralized operator set.

**Iterative mode locking.** During iterative execution, accounts are locked for a few seconds, which can cause contention on heavily-used accounts.

## What's Next

* [Responsible Disclosure](/security/responsible-disclosure.md) — how to report issues


---

# 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/security/known-limitations.md?ask=<question>&goal=<user_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.