> 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/releases.md). # Releases What v0.3.0 adds and how a chain moves between supported ZisK proof releases. This section documents **Rome ZK EVM v0.3.0**. Use the matching v0.3.0 source, node image and batch guest. The guest uses ZisK 1.3.1-alpha. The release tag names the source tree used for the image. The `main` branch may have changed since the release. The [full v0.3.0 changelog](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/CHANGELOG.md#v030) records the commands, fixes and limits behind the release. The [ZisK release policy](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/ZISK-RELEASES.md) describes the on-chain registry and move process. ## In v0.3.0 Devnet chains can now take deposits and pay withdrawals from their own wrapped SOL vaults. The chain authority can open a deposit queue, set its bounds and fees, and change them after a delayed activation. The sequencer credits finalized Solana deposits in EVM blocks; the batcher commits their ordered range to the inbox batch. The node image includes an exit prover. With `EXITS=on`, it watches the chain's exit portal, proves withdrawals against final Solana roots, and sends the vault release itself. It uses its own payer. A small payout to a recipient without a wrapped SOL token account waits for manual release by default. `./rollup check` reports exit configuration, service health, stuck exits and exit-payer balance. Proofs use ZisK 1.3.1-alpha. Settlement and Veritas now keep a verifying key and pinned recursion root per ZisK release. The prover host setup downloads and checks this release's key archives, checks the GPU binaries and prepares the constant files used by aggregation. The release also adds the verification-key request and bug-report issue forms. The devnet guide links the explorer transactions from Rome's own run, from registration to payout. This release still leaves old inbox batch and chunk accounts open. Pending-root accounts remain open by default; their rent accumulates. Rome has not yet decided how long old batch data must stay on Solana. ## ZisK releases belong to each chain's key Each chain has a verification-key registry. An entry holds `programVK`, a public-values layout, an activation slot and a scheme number. That number names the ZisK release used to build the guest and key; the proof does not choose its release. The registry has four entry slots. | Scheme | ZisK release | v0.3.0 status | | ------ | ------------- | ------------------------------------------ | | `1` | `1.2.0-alpha` | Withdrawn; its proofs are refused. | | `2` | `1.3.1-alpha` | Open; new entries and proofs are accepted. | Settlement looks up the active entry matching a proof's `programVK`. The entry selects that release's Veritas key and pinned recursion root. A proof with the wrong root is refused before the public-values and pairing checks. A withdrawn release has no verifying key in the production build. ## Move a chain to a new release Install the new ZisK toolchain and proving keys while keeping the old install available. Set the rollup source tag, guest tag and ZisK release together, then run `./rollup guest-build` to build a new guest and `programVK` for the same genesis. The prover needs the matching ZisK install, guest and verification metadata. Send Rome the chain's genesis, guest tag, ELF hash and `programVK`. Rome rebuilds and checks the guest and registers the new key with a future activation slot. If the chain has posted a root, Rome also needs the previous guest and release. Check the new on-chain entry and activation slot, then switch the prover when that slot arrives. Rome retires the old entry after the switch. A future entry cannot verify early. Rome's support policy keeps at most two ZisK releases open at once. A closing release accepts no new entries, but existing entries can still verify while chains move. When Rome announces that a release is closing, chains on devnet and testnet have 30 days to move. That window is Rome's support policy, not an on-chain timer. Rome may retire entries at once for a security withdrawal. A withdrawn release accepts neither new entries nor proofs, so a chain still on 1.2.0-alpha needs an active 1.3.1-alpha entry before it can post another root. --- # 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/releases.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.