> 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/rome-zk-evm/trust-model.md). # Trust model Who can change a Rome ZK EVM chain on devnet and what depositors and withdrawers must trust. The shared v0.3.0 programs on Solana devnet are upgradeable. A proved root is final under the rules those programs enforce when it posts. Operators and users should also account for who can change those rules, who controls each chain, and who can stop publishing data. Read the [full v0.3.0 devnet trust model](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/TRUST-MODEL.md) for the exact powers of each authority and the checks in the current programs. ## Rome's program and registry authorities Rome holds the upgrade authority for the shared inbox, settlement, Veritas and bridge programs. It is a single-signature authority on devnet. An upgrade can take effect without a notice period and can change any current program rule. Treat this as a devnet trust assumption when depositing funds. Rome also holds the settlement registry authority. Under the current programs, it can turn permissionless registration on or off, change registration deposits for new chains, change settlement fees even for an existing chain without a protocol cap, choose the treasury, change allowed timestamp drift and change the global reclaim window. The reclaim window can be shortened for registered chains, but not below 216,000 slots under the current program. The registry authority registers, retires and changes the activation slot of a chain's verification keys. A proof counts only against an active key for that chain. This authority can therefore change which guest's proofs can finalize new roots or leave a chain with no usable key. A new entry can be active as soon as its registration transaction lands. Already-final roots stay final when a key is retired. Without upgrading the programs, Rome's keys cannot create a vault for a chain whose authority Rome does not hold, change that vault's mint, choose where its payouts go, or withdraw from it without a proved exit. Program upgrade authority can change those rules, so users must trust Rome not to make such an upgrade on devnet. ## Your chain authority In the `./rollup` setup, the Solana payer is also the chain authority. It signs inbox batch publication and finalization, proved-root posting, and chain configuration. It can close eligible batch, chunk and pending-root accounts to recover their rent. There is no instruction to rotate this authority, so losing it stops those signed actions. Registration fixes the chain's ID, genesis, inbox program and challenge-window length. The authority cannot edit the registered genesis. It chooses a fee recipient in that genesis. A new chain normally starts with zero balances; any declared starting balance needs matching vault backing before Rome registers its verification key. Settlement does not itself check that backing. The authority can propose a different exit portal, bridge program, withdrawal cap and poster bond. A proposal becomes active no sooner than one chain challenge window later. Anyone may activate it after that slot. Users should inspect the active exit configuration before withdrawing. After the first proved batch, the authority can create a deposit queue and choose its inclusion deadline, per-batch and per-block limits, minimum deposit, fee and fee recipient. Changes also have a delayed activation slot. The current program constrains which waiting deposits a **finalized** batch may leave out. It does not force the operator to produce that batch. ## What a user relies on A depositor trusts the operator to keep the sequencer running, include the queued credit in a batch, post the batch and prove its root. The operator can choose EVM transaction order and refuse transactions; there is no general forced-inclusion lane for EVM transactions. A deposit balance can appear at the chain RPC before its root is final on Solana. A withdrawer needs a final root covering the exit message, an active exit configuration and enough wrapped SOL in the chain vault. The operator can delay that root by stopping batches or proofs. They can delay payouts by stopping the exit prover or leaving the vault or exit payer unfunded. Anyone can submit a valid exit proof and release, so the operator's exit prover is not the only path once the data and final root are available. Under the current programs, settlement binds an exit proof to the configured portal and a final root. It limits exits per challenge window and prevents replay. The bridge reads the recipient from the proved record and checks the recipient's associated token account. Whoever sends the release cannot redirect its payout. A vault without enough funds cannot pay, even if the exit proof is valid. The 5 SOL registration deposit is a chain-registration bond, not backing for users' balances. It becomes refundable to the chain authority after the first final root or ten posted roots. If no root is posted before the reclaim window ends, anyone can reclaim the chain and its unrefunded deposit goes to the treasury. The devnet window at v0.3.0 is 6,480,000 slots, about 30 days, measured from registration. --- # 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/rome-zk-evm/trust-model.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.