> 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/verification-key.md). # Verification key Build a chain-specific batch guest and request registration of its ZisK verification key. Each chain has its own batch guest. The guest contains the chain's genesis and fee recipient. It checks the batch data and execution, then commits the public values that Solana settlement checks. The guest's `programVK` identifies the program being proved. A permissionless chain registers with an empty verification-key registry. It cannot post a final root until Rome adds a key for that chain. The chain authority cannot include a key in its registration transaction. This is the v0.3.0 process on Solana devnet. ## Build the guest From `deploy/rollup` in the v0.3.0 checkout, use the release settings `ROME_ZK_TAG=v0.3.0`, `ROME_ZK_GUEST_TAG=v0.3.0` and `ZISK_RELEASE=1.3.1-alpha`. Run `./rollup init` first so the genesis and chain ID are rendered. You need the chain registered before you send the request. Then run: ```sh ./rollup guest-build ``` The command builds an image with the ZisK toolchain, clones the rollup and guest sources at those tags, builds the guest from your genesis and checks that it carries your chain ID. It prints the guest ELF's SHA-256. The generated metadata records that hash, the genesis hash, the chain ID, the ZisK release and its scheme number. For this release those last two values are `1.3.1-alpha` and `2`. To compute `programVK` locally, the build needs the matching ZisK proving keys and about 36 GB of RAM. That step takes about 40 seconds. If you skip that step or do not have the keys, the build reports `ProgramVkNotComputed`. The prover refuses metadata without `programVK`; compute it with the matching keys or ask Rome for it before you start proving. Two machines building the same genesis at these tags get the same ELF hash. A changed genesis means a different guest, and genesis cannot be changed after chain registration. The build refuses a genesis whose chain ID differs from your chain's ID (`ChainIdMismatch`) and a genesis that gives more than one account a balance (`GenesisFundedAccountLimit`). ## Ask Rome to register it Use the [verification-key request form](https://github.com/rome-protocol/solana-zk-evm/issues/new?template=vkey-request.yml). Have your chain ID, the chain authority's public key and the signature of the transaction that registered the chain ready. Include the guest tag and the generated metadata: ELF hash, genesis hash, `programVK`, `zisk` and `scheme`. Attach or paste the rendered genesis. If genesis declares a backed balance, have the matching funded vault ready. Include a `./rollup check` result that passes except for items waiting on the key. Rome rebuilds the guest from the tag and genesis. It checks the chain ID, genesis, ELF hash and `programVK` against your request, then registers the key under the matching ZisK release. Rome replies on the issue with the signature of the key registration transaction. The key becomes usable at its recorded activation slot; run `./rollup check` after that slot. With the prover on, the `verification key` check should pass. The deposit-capable key check should pass too. Rome registers a **complete request within two business days**. If a request is incomplete, Rome replies with what is missing. The two business days start when the request is complete. The timing matters because the reclaim window starts when you register the chain, not when its key becomes active. The v0.3.0 devnet window is 6,480,000 slots, about 30 days. If no root is posted when that window ends, anyone can reclaim the chain and its 5 SOL deposit goes to the treasury. Rome's registry authority can change the global window, subject to a 216,000-slot minimum. After activation, give the prover the matching guest, metadata and ZisK proving keys, turn `PROVER=on`, then run `./rollup init`, `./rollup up` and `./rollup check`. The proof must use an active key registered for this chain. Moving later to a different ZisK release needs another guest build and another registered entry; see [Releases](/rome-zk-evm/releases.md). The full request fields and operator steps are in [Run on devnet at v0.3.0](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md). --- # 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/verification-key.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.