> 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/deposits-and-withdrawals.md). # Deposits and withdrawals Move SOL into a Rome ZK EVM chain and withdraw its native coin to a Solana wallet. In the v0.3.0 devnet setup, the chain's native coin is backed by wrapped SOL in its Solana vault. A deposit locks wrapped SOL and credits the named EVM address. A withdrawal burns that coin on the chain and pays wrapped SOL from the vault to a Solana recipient. One gwei on the chain corresponds to one lamport of wrapped SOL. The [full withdrawal guide](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/WITHDRAWALS.md) has the exact call, checks and refusal names. The [devnet guide](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md) covers deposit setup and the depositor command. ## Deposit SOL The operator first needs a proved root, a wrapped SOL vault, an active exit configuration that names the bridge, and a deposit queue. Without these, a new chain cannot accept deposits. The chain's genesis starts with no balance unless its operator declared and backed one balance. A depositor uses `./rollup deposit` with an amount in lamports, an EVM recipient, their own Solana signer and `--wrap-sol`. That option wraps the SOL in the same Solana transaction as the deposit. The command is a dry run until `--confirm` is added. The default minimum is 1,000,000 lamports, or 0.001 SOL. The default queue fee is 100,000 lamports, or 0.0001 SOL, paid to the chain authority. The depositor also pays the transaction fee and rent for the deposit record. The bridge locks the wrapped SOL in that chain's vault and appends a numbered record. The sequencer reads finalized Solana deposits and credits them in order in new EVM blocks. The balance appears at the chain RPC when its block seals. The credit is final only when the batch containing it is proved and its root lands on Solana. The default queue inclusion deadline is 12 hours, with at most 256 deposits per batch and 4 per block. The inbox checks the deadline when a batch finalizes. That rule does not force the operator to produce or prove a batch. The operator can still delay a deposit by stopping the chain. Deposit-record rent can return to the depositor after the crediting batch's root is final and the batch authority sends `CloseBatch`. Then anyone can send `CloseDeposit`. The deposit remains in the vault as backing. The v0.3.0 runner does not send `CloseBatch`, so records do not close automatically and their rent stays locked. ## Withdraw to Solana Withdrawals are for the chain's native coin only. Send a payable `initiateExit(bytes32 solRecipient)` call to the exit portal at `0x4200000000000000000000000000000000000016`. The value is the amount to withdraw. The recipient is a **Solana wallet address encoded as 32 bytes**, not the address of its token account. Check that address before sending. The coins are burned as soon as the transaction lands, and nothing in the portal can give them back. Keep the message hash from the `ExitInitiated` event. Wait for a proved root covering that transaction. The exit prover uses the verifier node to make a storage proof of the portal's message against that final root. Solana settlement checks the proof, the active exit configuration, the portal and the withdrawal cap. The exit prover then sends a release. The bridge takes the amount from the chain's vault and pays the recipient's wrapped SOL associated token account. It can create that token account when needed. The payout follows the proof without a separate waiting period. The release transaction reads the recipient from the proved record, so the operator or any other sender cannot redirect it. The program consumes the record and pays out atomically, preventing a second payout for the same withdrawal. Most of the wait is the time to close, post and prove the batch. The exit prover polls every two seconds and pays soon after a final root is available. In Rome's devnet run, a withdrawal started in block 192 was paid out on Solana about four minutes later. This is one measurement, not a fixed withdrawal time. An exit cap limits how much can leave in each 172,800-slot challenge window. An exit that does not fit in the current window waits for the next one. A single exit larger than the whole cap needs the chain authority to raise the cap. Exit configuration changes take at least one challenge window to become active. A payout can still wait after proof if the recipient lacks a wrapped SOL token account and the amount is below the default 0.01 SOL threshold. The exit prover leaves it for a manual release rather than pay to create that account. The user or operator can use `./rollup release-exit --message-hash` with the message hash and `--confirm`. Anyone can release a valid exit. ## What the operator runs Create and fund the wrapped SOL vault after registration. For a backed genesis balance, lock that same amount before requesting the verification key. After the first proved root, set an exit portal, bridge and cap with `./rollup exit-config propose`. Wait at least one challenge window, then run `./rollup exit-config activate --confirm`. The chain authority opens the deposit queue with `./rollup deposit-queue init --confirm`. Set `EXITS=on`, then run `./rollup init` and `./rollup up` to start the exit prover. It needs its **own funded payer**, separate from the batcher's payer. Each exit proof costs its payer a Solana fee and record rent. The runner rejects a missing or shared exit payer. Automatic payout is on by default; the exit prover also retries proved records left open after a restart. Run `./rollup check`. It checks vault backing, deposit caps and backlog, the active bridge and exit configuration, the exit prover, stuck exits, its log scan and its payer balance. The default exit-payer floor is 0.1 SOL. Use `./rollup vault show` and `./rollup deposit-queue show` to inspect funds and queue state. The full guides above give the commands for funding a vault and changing queue settings. --- # 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/deposits-and-withdrawals.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.