> 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/run-a-rollup.md). # Run a rollup Register and run your own Rome ZK EVM chain on Solana devnet with the v0.3.0 rollup runner. The `./rollup` runner starts one chain against Rome's shared Solana devnet programs. You run its node and pay its Solana costs. You do not deploy the settlement programs yourself. Registration is permissionless, but proved roots need a chain-specific verification key registered by Rome. This page uses **v0.3.0**. The [full devnet guide](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md) covers every setting, failure and recovery step. ## Before you start Use an x86-64 Linux machine with bash 4 or newer, Git, Docker Engine 28 or newer with Compose, curl, jq, openssl, the Solana CLI and Python 3.11 or newer. You need a Solana devnet RPC endpoint, a funded Solana payer keypair, which is also your chain authority, and a sequencer signing key. Keep both files private and readable by container user 999. The guide explains how to make them. Budget about **7 SOL on devnet** for the payer. Registration locks 5 SOL; `./rollup check` expects at least 1 SOL left for posting and rent. The deposit becomes refundable after the first final root or ten posted roots. If the chain is reclaimed before then, the deposit goes to the treasury. The chain also needs an EVM fee-recipient address you control. To settle roots, you need a prover host with one NVIDIA GPU with more than 30 GB of memory. A 24 GB card is too small for the final proof step. [Prover host](/rome-zk-evm/prover-host.md) gives the RAM and disk budget. The node can run and publish batches before the prover is ready, but none of its roots will be final. ## Start the node Clone the release and work from its rollup directory: ```sh git clone --branch v0.3.0 https://github.com/rome-protocol/solana-zk-evm.git cd solana-zk-evm/deploy/rollup cp .env.example .env cp chain.toml.example chain.toml ``` Set the Solana RPC, signer locations and `ROME_ZK_TAG=v0.3.0` in `.env`. Keep `PROGRAMS_JSON=programs.devnet.json`. Set `ROME_ZK_GUEST_TAG=v0.3.0` and `ZISK_RELEASE=1.3.1-alpha` for the later guest build. Keep the RPC bound to loopback for a local first run. Leave `PROVER` unset until the guest and its key are ready. Set `genesis.fee_recipient` in `chain.toml` to your EVM address. Do not choose a chain ID. Settlement derives one from the payer and its registration count; `init` reads it before sending anything. About half of all IDs are too large for MetaMask. If yours is one, `init` stops with `ChainIdNotWalletSafe`; make a new payer key, point `PAYER_KEYPAIR_PATH` at it and run `init` again. A new chain starts with zero balances. If you declare one backed balance to get gas before deposits open, lock the same amount of wrapped SOL in the chain's vault before requesting the verification key. ```sh ./rollup init ./rollup register --dry-run ./rollup register --confirm ./rollup up ./rollup check ``` `init` renders the genesis and service configuration. `register --confirm` locks the 5 SOL deposit and creates the batch cursor. `up` starts the sequencer, batcher, derive and verifier node. `check` names any missing service, then compares the chain ID, the heads, the batcher's progress, the inbox and the roots. Run it again after batches have had time to close; its first batch-progress check only records a sample. Without a prover, the sequencer serves RPC, the batcher posts transaction data to the inbox, and derive reconstructs the chain. An inbox batch is not a final settlement root. Even the genesis root waits for a proof. ## Move from batches to final roots Build the guest for your chain's genesis: ```sh ./rollup guest-build ``` The build uses the v0.3.0 guest and ZisK 1.3.1-alpha. It produces the chain's guest program and verification-key metadata. Computing `programVK` needs the ZisK proving keys and about 36 GB of RAM. Registering the chain does not register a verification key. Send the [verification-key request](/rome-zk-evm/verification-key.md) after the build. Rome checks your genesis and guest, then registers the key with an activation slot. On the prover host, set `PROVER=on` and the guest, verification metadata and ZisK settings described in the full runbook. After the key is active: ```sh ./rollup init ./rollup up ./rollup check ``` Check that the `service prover` and `verification key` items pass. The prover works through inbox batches in order. Each valid proof posts a root that is final as soon as its Solana transaction lands. ## Make the first block With no backed genesis balance, the chain has no gas for a transaction until deposits open. Deposits need a first proved root. The default `empty_block_interval_secs = 0` leaves an idle chain without blocks, so set it to `60` under `[profile]` in `chain.toml` after the key is active and the prover is running. Render and restart: ```sh ./rollup init ./rollup up ./rollup check ``` Once the first root is final, set the interval back to `0` and rerun `init` and `up` unless you want regular empty blocks. Turning them on while waiting for Rome to register the key creates a backlog. Every batch must be proved in order. With a 60-second empty-block interval and the 60-second batch close, the chain makes about one batch a minute, or about 1,440 a day. On devnet, a proved root cost the payer about **0.003 SOL**: about 0.002 SOL in pending-account rent, the 0.001 SOL settlement fee and a transaction fee on top. That cadence is about 4.4 SOL a day before inbox posting costs. Pending-account rent stays locked with the default settings. With empty blocks off, an idle chain seals no batches and pays no posting costs. To accept deposits, next create the vault, activate exit configuration after its delay, and open a deposit queue. Those commands and the checks are in [Deposits and withdrawals](/rome-zk-evm/deposits-and-withdrawals.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/run-a-rollup.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.