> 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/how-it-works.md). # How it works Follow an EVM block through Solana data posting, ZisK proving and final settlement. Your sequencer accepts EVM transactions through JSON-RPC. It checks the signature, nonce, funds and gas, then executes accepted transactions in arrival order. It writes signed sub-blocks and their transactions to a durable ordered log before returning a pre-confirmation. The sequencer embeds reth to produce the chain's blocks. A pre-confirmation tells you what the sequencer accepted and ordered. It is not a final Solana root. The rest of the path publishes the data and proves that executing it gives the claimed state. ``` EVM transaction -> sequencer -> ordered log -> batcher -> Solana inbox Solana inbox -> derive -> reth-verifier -> blocks + witnesses blocks + witnesses -> prover (ZisK batch guest) -> proof + root proof + root -> Solana settlement (PostRootProved) -> final root ``` ## From blocks to an inbox batch The batcher reads consecutive blocks from the ordered log. The example `chain.toml` closes a batch at 60 blocks, or 60 seconds after its first block, whichever comes first. It compresses the batch into frames, posts the frames as inbox chunks on Solana, then finalizes the batch's Merkle commitment. The inbox commitment covers the chain and batch IDs, the opening slot, the chunk count, the Merkle root of the chunks and the batch's deposit range. Finalizing an inbox batch means its data has been posted. It does not make its state root final. The chain authority signs the batch finalization. The batcher cannot skip a block number. Settlement also takes the next batch in order. That is why a stuck or abandoned batch blocks later roots. The batcher resumes a partly written batch under the same number after a restart when it can reconstruct it. ## Derive, verify and prove `derive` reads finalized inbox batches from Solana. It reconstructs the blocks and drives a separate `reth-verifier` node to execute them again. This node serves the execution witnesses the batch prover needs and the state proofs the exit prover needs. It runs reth's testing API, so it must stay off the public network. The prover reads each finalized inbox batch, obtains blocks and witnesses from the verifier node, and runs the chain's batch guest in ZisK. The guest checks that the blocks match the inbox data and execute correctly. It commits the batch's public values, including the resulting state root. Your genesis and fee recipient are compiled into this guest, so each chain has its own guest and `programVK`. The prover checks the proof locally, then sends `PostRootProved`. The settlement program checks the active verification key registered for this chain and the ZisK release named by that key. It also checks the proof's public values against the chain ID, block range, predecessor, inbox commitment and claimed root. Veritas is Rome's verifier for ZisK PLONK proofs. Settlement links its verifier code and runs it inside `PostRootProved`; it does not call the separately deployed Veritas program. A valid proof writes a `Final` root and advances the finality head in the same Solana transaction. The genesis root of a permissionless chain is not final by itself. Its first final root needs a proved batch. ## Funds crossing the boundary A deposit starts on Solana. The bridge program moves the deposited token from the depositor into that chain's vault and appends a numbered deposit record. The sequencer reads finalized Solana deposits and credits the named EVM address in order. The batcher commits the deposit range with the batch. The balance appears on the chain when its block seals, but its credit is final only when that batch's root is proved on Solana. A withdrawal starts on the chain at its exit portal. The portal records a message and burns the native asset. The exit prover watches for that message and obtains an Ethereum storage proof from the verifier node against a final root. It checks that proof locally, then sends `ProveExit` to Solana settlement. Settlement checks the portal, message, final root and exit cap, and prevents the same exit from being proved twice. The exit prover then sends the bridge's release transaction. The bridge consumes the proved exit and pays the recipient from that chain's vault in one atomic transaction. The recipient comes from the proved record, so the person sending the release cannot change it. Read the full [v0.3.0 architecture](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/ARCHITECTURE.md) for wire formats, component boundaries and the checks on each instruction. --- # 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/how-it-works.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.