Real Proofs, Real Settlement: What a Rollup Should Mean

In February 2026 Vitalik Buterin put the question plainly: “If you create a 10000 TPS EVM where its connection to L1 is mediated by a multisig bridge, then you are not scaling Ethereum” (CoinDesk). He said L2s should be clear with users about what guarantees they provide.

We agree, and we start with our own record. Revolution’s first network, Libertas (V1 network), used a placeholder verifier. It never produced real proofs. V1 material also described EigenDA for data availability. That integration was not found in the Libertas (V1 network) code and is not part of V2. We have withdrawn those references.

This post explains what Revolution V2 does instead, and why.

The problem: “rollup” has become a loose word

L2BEAT’s definitions are precise. A rollup is “A blockchain that inherits consensus and data availability from another blockchain called L1.” A validium “uses validity proofs for settlement and publishes the data offchain, therefore requiring an additional trust assumption” (L2BEAT glossary).

Three things separate a real rollup from a chain that only uses the word:

Proofs that are real. A proof system that can reject an invalid state transition. A placeholder verifier accepts anything.
Data on L1. If the data is off chain, users depend on whoever holds it to rebuild state and exit.
Settlement that actually happens. Proofs and data mean nothing if batches stop reaching Ethereum.

L2BEAT’s Stages framework builds on the same base. Two of its Stage 0 checks are “Does the project use a proper proof system?” and “Does the project provide Data Availability (DA) on L1?” (L2BEAT Stages). The bar is rising. In November 2025 L2BEAT proposed new Stage 1 requirements for ZK systems, including that “source code for all used onchain verifiers must be available online, including the recursion and final wrap provers” (L2BEAT forum).

Libertas (V1 network) failed the first and the third. V2 is designed to meet all three from public testnet onward.

How it works: proofs

Every V2 batch carries a validity proof from Airbender, the ZKsync OS prover. ZKsync describes Airbender as open source, MIT licensed and built on STARKs, and states that it “is live on mainnet today” (Airbender). ZKsync OS compiles the same Rust code to x86 for execution and to RISC-V for proving, so “what you execute is what you prove” (ZKsync OS overview).

Proving has become fast and cheap enough to make this the default. In December 2025 the Ethereum Foundation reported that zkEVM proving latency fell from 16 minutes to 16 seconds in nine months, and that “zkVMs now prove 99% of all Ethereum blocks in under 10 seconds on target hardware” (Ethereum Foundation). The same post set security targets of 100-bit provable security by end of May 2026 and 128-bit by end of 2026.

Why real proofs matter is best shown by an incident. On 2 September 2025 Starknet had an outage of about nine hours, with two reorgs. Its report explains that “When the proving layer detects an inconsistency (or any other invalid logic), it cannot generate a valid proof” (Starknet). The proving layer caught the inconsistency. A placeholder verifier catches nothing.

Proof diversity is the next step. Matter Labs publishes a second proof system for ZKsync OS based on ZiSK. It “runs alongside the primary Airbender (RV32I) proof system” and “L1 verification requires both proofs” (GitHub). We will evaluate it for Revolution as it matures.

Revolution V2 on proving. Fake provers run only on local devnets. From Virtus (V2 testnet) onward, every batch gets a real Airbender proof. Revolution rents GPUs. On testnet one host with a 24 GB class GPU and at least 192 GB of RAM runs both the FRI and SNARK roles. On mainnet two dedicated hosts run them, with marketplace GPUs for bursts. Several batches share one SNARK where the prover allows it, which reduces L1 prove transactions.

How it works: data on Ethereum, in blobs

Revolution V2 is a rollup that publishes its data to Ethereum in blobs. We considered a validium and did not choose it.

Ethereum made this decision easier. Pectra, on 7 May 2025, raised the blob target from 3 to 6 per block (Ethereum Foundation). Fusaka, on 3 December 2025, added PeerDAS, so nodes verify blob availability “through sampling rather than downloading entire blobs”. Follow-up forks raised the target to 10 and then 14 (Ethereum Foundation). Fusaka also included EIP-7918, which gives blobs a reserve price tied to execution gas so the blob base fee cannot collapse to near zero (EIP-7918; Fidelity Digital Assets).

Blob costs stay small even for large chains. In November 2025 Fidelity Digital Assets reported that Base “paid a total of $5.2 million in blob fees over the past year while making roughly $94 million in revenue from user transaction fees” (Fidelity Digital Assets).

The reasoning in the V2 whitepaper, section 4.3:

Factor	Rollup with blobs	Validium
Data availability	Ethereum	External DA vendor or committee
L1 commit, prove, execute transactions	Paid	Also paid
Blob fees	Small at Revolution’s volume	None
Extra components	None	DA vendor, verification bridge, more audit scope
Recoverability	Anyone can rebuild state from L1	Depends on the DA provider
Assurance for RWA, custody and ACommerce counterparties	Strongest	Weaker

The key point: the larger L1 cost is the commit, prove and execute cycle, and a validium pays that too. ZKsync’s own server documentation describes the unit as “1 batch = 1 proof = 1 L1 commit” (ZKsync Docs). Moving data off chain saves the smaller cost and adds the larger risk.

Validium remains a possible later cost option, only if Phase 1 confirms that the chain admin can change the data availability settings on protocol v31. It is not the plan.

How it works: verifying nodes co-sign batches

Proofs show a batch is valid. They do not guarantee someone else holds the data before it is committed, and they add no independent check on execution. V2 adds both with ZKsync OS batch verification.

A verifying node is an external node run by a staked operator. It replays every block from the sequencer. With batch verification on, the sequencer asks verifying nodes to sign each batch before it is committed. A batch moves forward only with a threshold of signatures.

Network	Threshold
Virtus (V2 testnet)	2 of 3 signers
Mainnet	3 of 5 signers, at least three independent of Revolution and Amplify

This gives two properties. Recoverability: committed data already exists on independent machines. An execution check: where the L1 side uses a multisig committer, the same signatures are required on Ethereum, a check independent of the proof system.

ZKsync applies the same idea to its own chains. Its September 2026 EraVM update is adding an independent second node to confirm each executed batch. Matter Labs is also developing EraBender, an Airbender-based second prover, so that an exploitable flaw would have to exist in two independently built proving systems (Blockchain Reporter).

We are candid about the trade-off. Upstream signature collection retries until it succeeds. If too many verifying nodes are down, batching stalls, and through backpressure block production stops. That is why the threshold sits below the signer count. It tolerates an operator outage and still keeps an independent check.

The staking contract ties economics to the role. A node registers a separate verifier key. Only that key can send the node’s heartbeat. A node that misses heartbeats past the liveness window (1 hour proposed) can be jailed by anyone and stops earning. Jailing does not slash stake today. Slashing for verification failures is an open item to specify before mainnet.

How it works: settlement you can monitor

Batches are committed, proven and executed on Ethereum, each step signed by a separate operator key held in a KMS. Settlement lag is a service level objective with alerts on commit, prove and execute. The batcher is not highly available upstream, so a second consensus node is the designated standby, with a drilled runbook and a target of settlement resuming within 30 minutes.

Operational failures are real, even on the largest L2s. On 5 August 2025 Base halted block production for 33 minutes when a failover sequencer “had not been fully provisioned” (CoinDesk). Standbys only help if they are ready.

The operating cost reasoning

Whitepaper section 4.7 gives planning estimates from public list prices in September 2026. They are not commitments.

Environment	Infrastructure per month	L1 settlement per month
Virtus (V2 testnet)	$960 to $1,700	About $0 (Sepolia)
Mainnet at launch	$2,800 to $5,450	$350 to $1,730 at a 1 hour batch cadence and 0.2 to 1 gwei

The largest variable cost is settlement cadence. Under the whitepaper’s planning assumptions at 1 gwei, one settlement cycle costs about $2.40. Settling every 5 minutes would cost up to about $20,700 a month. Settling every hour costs up to about $1,730. Mainnet therefore launches with a 1 hour batch timeout plus size-based sealing, which still meets the 3 hour withdrawal target. The cadence shortens as fee revenue grows.

What is built, what is specified, what is next

Built and tested on a devnet: the ZKsync OS devnet, the staking contract with heartbeats and jailing, EntryPoint v0.8 at its canonical address, Nexus accounts, the Cornerstone Paymaster and Budget, fee routing, a keeper, an API and a Libertas (V1 network) snapshot tool. 51 contract tests pass, including four stateful invariants. The devnet uses fake provers.

Phase 1 work, not yet live: ZK Stack ecosystem contracts on Sepolia, the Airbender prover on a rented GPU host, batch verification at 2 of 3, a public explorer that shows L1 settlement status, and a bridge portal.

Specified only: the identity and ACommerce contracts.

Virtus (V2 testnet) passes its exit test when a batch commits, proves with a real proof and executes on Sepolia, and a verifying node co-signs batches and heartbeats. Mainnet follows in Phase 4, after independent audits.