Revolution V2: Why We Are Rebuilding on ZKsync OS

On 4 September 2026, ZKsync published a security update with a clear line in it: “Within the next six months, EraVM chains will begin a transition: the EraVM execution environment is going to be retired” (ZKsync). The same update recommended that public EraVM chains raise their execution delay from 3 hours to 24 hours. ZKsync is also working with every active EraVM chain to run an independent second node that confirms each executed batch (Blockchain Reporter).

Revolution’s first network, Libertas (V1 network), ran on EraVM. We had already decided to move. This post explains why Revolution V2 is a regenesis onto ZKsync OS, what we learned from Libertas (V1 network), and what carries forward unchanged.

The problem: a custom VM on a retiring stack

Libertas (V1 network) was an EraVM testnet on zkSync Era protocol v29. EraVM is a custom virtual machine. Contracts compile with zksolc, not standard solc. Accounts use EraVM native account abstraction. Features that looked convenient in 2024 became liabilities in 2026.

ZKsync’s own documentation is direct about the path. ZKsync OS “will replace EraVM for ZKsync chains”, and “Eventually chains that use EraVM with the legacy system will be deprecated” (ZKsync OS FAQ). The same FAQ states that native account abstraction from EraVM is not supported on ZKsync OS, while ERC-4337 is.

A chain built on EraVM-specific features has two options: migrate those features or rebuild on standards. We chose to rebuild.

What Libertas (V1 network) taught us

We are publishing these findings because anyone evaluating Revolution should see them.

No real proofs. Libertas (V1 network) used a placeholder verifier. It never produced real validity proofs.
Emission drift. Emission was tied to batches, with an assumed 40 seconds per batch. Libertas (V1 network) averaged 108 seconds. It emitted about 20.8M REVO where the curve intended about 53.0M over the same period.
Code outside any repository. Libertas (V1 network) depended on a NodeContract and a bootloader gas waiver whose code is not in any repository. The running configuration and wallets were also not in a repository.
Throughput limits by configuration. A 2.5 second batch seal timeout produced about one transaction per batch. The sequencer was limited to 0.3 CPU with its database on network storage. Reward distribution ran inside block production.

None of these is a flaw in the idea of Revolution. They are flaws in how V1 was built and operated. A regenesis removes every one of them at once.

How ZKsync OS works

ZKsync OS is “the new operating system of the ZK Stack” (zksync-os-server). It defines the chain’s state transition function and supports multiple execution environments. Today that environment is the EVM. ZKsync’s documentation describes it as “fully EVM equivalent” and says developers can use standard tooling in place of zksolc (ZKsync OS FAQ).

The design choice that matters most for a proving system: ZKsync OS is written once in Rust, compiled to x86 for the sequencer and to RISC-V for the prover. ZKsync summarizes this as “what you execute is what you prove” (ZKsync OS overview).

The prover is Airbender. ZKsync describes it as an open source RISC-V prover, MIT licensed, built on STARKs, and states that it “is live on mainnet today” (Airbender). Airbender was integrated in the Atlas upgrade to the ZK Stack, announced on 7 October 2025 under the headline “beyond 15K TPS with one-second ZK finality” (ZKsync).

Ethereum itself moved in the same direction. Pectra activated on 7 May 2025. It raised blob capacity from an average of 3 and maximum of 6 per block to “an average of 6 and maximum of 9”, and introduced EIP-7702 for smart account features on existing addresses (Ethereum Foundation). Fusaka activated on 3 December 2025 with PeerDAS, which lets nodes verify blob data by sampling. Two follow-up forks raised the blob target to 10 and then 14 (Ethereum Foundation). For an L2 that posts data to Ethereum, both upgrades lowered the cost of doing it properly.

Standards over custom VM features

V2 replaces every EraVM-specific dependency with an open Ethereum standard.

ERC-4337. V2 uses the canonical EntryPoint v0.8 at 0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108, the same address as on Ethereum. The eth-infinitism team released v0.8.0 on 26 March 2025, with native support for EIP-7702 authorizations (GitHub).
ERC-7579. V2 accounts are Biconomy Nexus accounts. ERC-7579 defines “Modular smart account interfaces and behavior for interoperability with minimal restrictions for accounts and modules” (EIP-7579). It is still a Draft, and we track changes against an audited implementation.
ERC-7562. These rules protect bundlers “from denial-of-service attacks through unpaid computation” (EIP-7562). The Cornerstone Paymaster is written to stay inside them, so public bundlers can accept it.

Wallets, bundlers and auditors already understand these standards. That lowers integration cost and audit risk. It also means a contract that works on Ethereum works on Revolution without a special compiler.

Here is a concrete example. Libertas (V1 network) planned to make certain calls free by waiving gas in the bootloader. ZKsync OS gives chains no bootloader hook. V2 delivers the same outcome with a standard ERC-4337 paymaster funded by the Cornerstone Budget, a share of staking emissions and not new issuance. The flow is ordinary 4337:

Smart account (zero balance) -> Bundler -> EntryPoint v0.8
  -> Cornerstone Paymaster: every target a cornerstone contract?
                            sender passes the identity gate?
                            reserve worst-case cost against this period's allowance
  -> execute -> postOp: true up to actual cost

The paymaster is bounded by design. It has a per-identity allowance, a cost cap per operation, and a hard maximum of 20% of emissions in code (5% proposed). When the allowance runs out, the client pays its own gas and service continues. This matters. In May 2026 Zerion announced it would shut down ZERO Network, a ZK Stack rollup whose paymaster covered all transaction costs for its wallet users. The Crypto Times observed that the business was “directly subsidizing every transaction” and said the shutdown suggests that “the equation did not balance” (The Crypto Times). Free services need a budget and a ceiling.

V1 and V2 side by side

Area	V1: Libertas (V1 network)	V2
Stack	zkSync Era, EraVM, protocol v29	ZKsync OS, protocol v31, EVM equivalent
Compiler	`zksolc`	`solc`
Accounts	EraVM native account abstraction	ERC-4337 EntryPoint v0.8 plus ERC-7579 accounts
Free cornerstone calls	Planned bootloader gas waiver	ERC-4337 paymaster funded from emissions
Proofs	Placeholder verifier	Airbender real proofs from public testnet onward
Settlement to L1	Running, no monitored service level	Monitored service level objective with alerts
Batching	About one transaction per batch	Many transactions per batch
Emission clock	Per batch (assumed 40 s)	Per second, same curve, same total
Staking payouts	Pushed inside block production	Continuous accrual by time, paid by claim

What V2 keeps

A regenesis is not a reset of the economics.

The emission total and curve. 250M REVO over 40 eras of 90 days, about ten years. Each era’s per-second rate equals the Libertas (V1 network) on-chain per-batch value divided by 40, exactly. The emission table is generated from the live Libertas (V1 network) contract.
The published split rules. Nodes, creators and fans share emissions under the rules of the published whitepaper, now enforced exactly by contract. The node fee stays between 20% and 50%.
The caps. 250 verifying nodes and 200 creators per node.

Only the clock changes. Blocks on ZKsync OS are produced only when transactions exist, so block.number is not a clock. V2 uses block.timestamp. Tuning batch size for cost no longer changes token supply. The V2 emission start point is still an open decision, and we will publish it.

What exists today, precisely

Built and tested on a devnet. A ZKsync OS devnet runs from one script with pinned versions. The staking contract implements the published economics with time-based emissions. EntryPoint v0.8 is deployed at its canonical address. Nexus accounts are built from a pinned commit of an audited codebase; audit coverage at V2 compiler settings is being confirmed. The Cornerstone Paymaster, the Cornerstone Budget, settlement fee routing, a keeper, an API and a Libertas (V1 network) snapshot tool are built. 51 contract tests pass, including four stateful invariants such as solvency. A zero-balance smart account called a cornerstone service end to end on the devnet, with gas paid from the budget.

Specified, not built. The identity contracts for Nomen (name), Sigillum (verified identity) and Agens (agent), and the ACommerce contracts beyond the paymaster.

Not live. Virtus (V2 testnet) opens in Phase 1. Mainnet follows in Phase 4, after independent audits and the Libertas (V1 network) migration. None of Revolution’s own V2 contracts has had an independent audit yet.

One devnet number, with its caveats. On a 2 vCPU host shared by the sequencer, a local L1 and the load generator, with fake provers, 3,000 transactions ran at 1,629 tx/s end to end with a p50 confirmation of 0.99 s. These are floor numbers on minimal hardware. They are not capacity claims.

What it means for developers

Write Solidity with solc. Use Foundry, Hardhat, viem, ethers and Otterscan.
Point existing ERC-4337 bundlers and SDKs at the canonical EntryPoint. No custom configuration.
Build ERC-7579 modules once and use them on Revolution and other chains.
Use passkeys. The P-256 precompile at 0x100 is present on ZKsync OS and verified on the devnet at about 31,000 gas.
Expect one difference: ZKsync OS fees are the maximum of EVM gas cost and proving plus pubdata cost, so local simulation underestimates. Deploy with a gas multiplier.

EIP-7702 is not yet supported on ZKsync OS (ZKsync OS FAQ). V2 does not depend on it and will add it as an onboarding path when it arrives.

Why this matters now

The L2 market is consolidating. In February 2026 Vitalik Buterin said the original rollup-centric roadmap “no longer makes sense”. He said L2s should provide value beyond basic scaling and be clear with users about what guarantees they provide (CoinDesk). The Block’s 2026 outlook said most new L2 launches became “ghost towns shortly after airdrop farming cycles” (The Block).

Revolution’s answer is focus. Our distinct value is programmable staking and a trust layer for agentic commerce. Everything underneath should be standard, proven and boring.

What is next

Phase 1 ends with an exit test on Virtus (V2 testnet). A batch commits, proves with a real Airbender proof and executes on Sepolia. A REVO deposit arrives on L2 and a withdrawal finalizes. A verifying node co-signs batches. A zero-balance account makes a free staking claim. The next post covers why V2 is a rollup that posts data in blobs, and what real proofs and real settlement should mean.