Smart Accounts by Default: Passkeys, Recovery, and Free Cornerstone Calls

The FIDO Alliance now counts “5 billion passkeys now in active use”. In the same report, 75% of consumers say they have enabled passkeys on at least some accounts. Ethereum moved the same way. The Fusaka upgrade activated on mainnet on 3 December 2025 and brought EIP-7951, a secp256r1 precompile. The Ethereum Foundation said it enables “direct integration with modern secure hardware like Apple Secure Enclave, Android Keystore, and FIDO2/WebAuthn devices”.

The signing hardware is already in people’s pockets. Most on-chain accounts have not caught up. Here is how Revolution V2 closes that gap, and what is built versus specified.

The problem: three taxes on a new user

A new user on most chains pays three taxes before doing anything useful.

The seed phrase. A 12 or 24 word secret, written on paper, with total loss if it leaks or disappears.
The gas token. The user must acquire the native token before the first transaction. For a first action that may never lead to a purchase, that is a hard stop.
The raw key. An externally owned account (EOA) has one key with unlimited authority. There is no spend limit, no session scope, and no revocation.

Passkeys address the first tax off chain. The FIDO Passkey Index 2025 reports a 93% sign-in success rate for passkeys against 63% for other methods, and an average of 8.5 seconds per sign-in against 31.2 seconds for traditional MFA. On chain, the other two taxes remain unless the account itself changes.

How it works: the standards stack

ERC-4337 and EntryPoint v0.8

ERC-4337 moves account logic into a smart contract. Users sign a UserOperation. A bundler submits it to a singleton EntryPoint contract. A paymaster can pay the gas. The model is in production at scale. BundleBear’s live dashboard shows 1,295,095,917 total UserOps and 67,661,419 accounts with at least one UserOp. Its paymaster view lists Alchemy, Coinbase, and Pimlico as the largest sponsors by UserOps served.

EntryPoint v0.8 was released on 26 March 2025 at 0x4337084d9e255ff0702461cf8895ce9e3b5ff108. The release notes list “Native support for EIP-7702 authorizations in the EntryPoint contract”, “Native support for ERC-712 based UserOperation hash and signatures”, and a fix to errors in calculating the paymaster postOp actualGasUsed value. They also note that “The unused gas penalty no longer applies if unused gas is below 40,000 gas.”

EIP-7702: an upgrade path, with a warning

EIP-7702 shipped with Pectra in May 2025. It lets an existing address delegate to smart account code. The Block reported “Over 11,000 EIP-7702 authorizations” in the first week. The early data also carried a warning. Wintermute found that “over 97% of all EIP-7702 delegations were authorized to multiple contracts using the same exact code”. Wintermute described these as sweepers that drain incoming ETH from compromised addresses. ethereum.org states the risk plainly: “If a user unknowingly delegates their account to a malicious contract, an attacker could easily gain control and steal funds.”

P-256 on chain

Passkeys sign with the P-256 curve, not Ethereum’s secp256k1. Verifying them in Solidity alone is expensive. A precompile fixes that. EIP-7951 is Final, lives at address 0x100, and “supersedes RIP-7212 by implementing the same functionality with the same interface, but without the vulnerability.” It prices a verification at 6,900 gas on L1.

ERC-7562: why paymasters must be boring

A paymaster that sponsors gas is an attack surface. ERC-7562 sets the validation rules bundlers enforce to “protect Account Abstraction nodes from denial-of-service attacks through unpaid computation.” It bans opcodes such as TIMESTAMP and NUMBER during validation because they read “block-specific information that is not yet finalized.” It tracks paymaster reputation and throttles or bans entities whose operations fail on chain. The ERC-4337 documentation lists the common abuse classes: “Replay abuse”, “Gas griefing”, “Whitelist bypass”, and “Stake draining”. Commercial services answer with policy limits. Pimlico’s sponsorship policies can cap “the global amount of sponsorships” and “the amount of sponsorships per user”.

What Revolution V2 does

Revolution V2 runs on ZKsync OS. The ZKsync OS FAQ states that “EraVM and native EraVM account abstraction are not supported” and that “EIP-7702 is not yet supported, but will be soon.” Revolution therefore builds every account on ERC-4337. EIP-7702 becomes an onboarding path for existing addresses once ZKsync OS supports it (Phase 5). The account model does not depend on it.

Built and tested on the devnet

Component	Status
EntryPoint v0.8 at `0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108`	Deployed on the ZKsync OS devnet through the canonical CREATE2 deployer with byte-identical salt and init code. Checked against a normalized runtime hash.
Biconomy Nexus accounts (ERC-7579)	Built from source at a pinned commit. Audit coverage at V2’s compiler settings is being confirmed. ECDSA (K1) signing module built and tested.
P-256 precompile at `0x100`	Tested. A valid signature returns 1, an invalid one returns empty, at about 31,000 gas per verification on the devnet.
Cornerstone Paymaster	Built and tested.
Cornerstone Budget in RevoStaking	Built. The repository’s 51 contract tests pass, including four stateful invariants.
Keeper and API	Built.

Specified, not yet built

Component	Phase
Passkey signing module, integrated from an audited implementation	Phase 2
Recovery model for verified parents	Phase 2. Open item A5 calls it the “Hardest consumer question in the design.”
Session executor and policy hook for an Agens (agent) under a Mandatum (delegated authority)	Phase 2
Agent Identity Registry replacing the allowlist identity gate	Phase 2
EIP-7702 onboarding	Phase 5, when ZKsync OS supports it

The canonical address means existing bundlers, SDKs, and wallets recognize Revolution without custom configuration.

Free to prepare, paid to settle

The design principle is short. A buyer will not pay to post an intent that may never fill. A human will not pay to register an Agens (agent) that has done nothing yet. A fan should not pay gas to claim rewards. If preparation costs money, the trust layer goes unused. So preparation is free and settlement is paid.

Libertas (V1 network) planned to waive gas in the bootloader. ZKsync OS gives chains no bootloader hook. V2 reaches the same outcome with a standard ERC-4337 paymaster run by the network: the Cornerstone Paymaster.

The flow: a zero-balance account sends a UserOperation naming a period in paymasterData. In validatePaymasterUserOp, the paymaster checks targets and eligibility, reserves the worst-case cost, and returns a validAfter and validUntil window. postOp trues the charge up to actual cost.

The rules, enforced by contract

Rule	How
Only cornerstone targets	The paymaster decodes the account’s call data. ERC-7579 single and batch calls and legacy `execute` and `executeBatch` are accepted. Every target must be a registered cornerstone contract. Delegatecall and other execution modes are refused.
Identity gate	The sender must be an active Agens (agent) identity whose parent holds a verified Sigillum (verified identity). Until the Agent Identity Registry ships, an allowlist gate stands in. Open mode is for devnets only.
Per-identity allowance	Each identity has an allowance per period. The EntryPoint enforces the period window through `validAfter` and `validUntil`, so validation never reads the clock. This keeps the paymaster inside ERC-7562 and usable by public bundlers.
Cost cap per operation	Operations above `maxCostPerOp` are refused.
Accurate accounting	Worst-case cost is reserved at validation and trued up after execution, with an upper bound for post-operation gas and the EntryPoint penalty on unused gas.
Bounded emergency pause	Each guardian pause lasts at most `maxPauseDuration` (3 days proposed) and expires on its own. Only the owner, a governance timelock, can change targets, the gate, limits, or withdraw funds.
Graceful exhaustion	When an allowance or the budget runs out, the paymaster declines. The client resubmits and pays its own gas. Service continues.

The clock rule matters. ERC-7562 forbids TIMESTAMP in validation, so the period lives in paymasterData and the EntryPoint enforces the window.

Cornerstone targets at launch are the staking contract (free claims), the Agent Identity Registry, the Proof Verifier, the Mandate Anchor, the Intent Book, escrow creation, and bond and delegate calls on the Reputation Registry. Governance adds each one as it ships.

V2 funds the paymaster from staking emissions.

Parameter	Value	Where
`cornerstoneBps`	500 (5%) proposed, governance-set	RevoStaking
Hard cap	2,000 (20%) enforced in code	RevoStaking
`periodLength`	1 day	Paymaster, fixed at deploy
`allowancePerPeriod`	Set from measured cost of a normal day’s cornerstone calls	Paymaster
`maxCostPerOp`	Most expensive cornerstone call plus margin	Paymaster

On every emission update, the staking contract sets aside cornerstoneBps of the scheduled emission before the staker split. Anyone can call releaseCornerstone() to move the set-aside into the paymaster’s EntryPoint deposit. The total emission does not change. The budget is carved from it. At 5%, the budget in era 1 is 0.1 REVO per second, about 777,600 REVO over the 90-day era. One of the four stateful invariants checks it on every build: budget set aside equals budget released plus budget accrued.

The devnet result

A new Nexus account holding zero REVO sent a sponsored single call and a sponsored batch call to cornerstone targets through EntryPoint v0.8. The budget released from staking emissions paid the gas. The allowance was charged 0.00006837 against an actual cost of 0.00005876. That gap is the intended upper-bound accounting: reserve the worst case, then true up. In tests, a non-cornerstone target, an ineligible sender, an over-allowance request, and a delegatecall were each refused.

This is a devnet result. Virtus (V2 testnet) is not live. No public users hold these accounts today.

What this means for developers

Standard tooling. Canonical EntryPoint, standard solc, and v0.8 account SDKs without a custom fork.
Scoped sponsorship. Cornerstone calls need no separate sponsorship service. Keep sponsored paths free of delegatecall.
Plan for the fallback. When the paymaster declines, resubmit with the account paying gas. The user sees a fee, not an error.
Budget gas for passkeys. The devnet figure is about 31,000 gas per P-256 verification.
Design for bounded authority. The account class sets baseline Potestas (permissions). An Agens (agent) never holds the owner key. It holds a session key carrying a Mandatum (delegated authority), revocable at any time.

What is next

Open items from the whitepaper, stated plainly:

Budget sizing (E7). 5% is a proposal without usage data. Too low stalls free calls. Too high dilutes stakers. The plan is to measure on testnet and set the allowance and share from data.
Passkey module selection (A4) and the recovery model (A5) must be chosen and specified before the Phase 2 exit.
Allowlist to registry (A6). The identity gate becomes the Agent Identity Registry in Phase 2.
Audits (A7). RevoStaking, EmissionSchedule, RevoCornerstonePaymaster, and AllowlistIdentityGate have no independent audit yet. Every contract is audited before mainnet.

The Phase 1 exit test: on public testnet, a zero-balance account claims staking rewards for free. The Phase 2 exit test: a verified user creates Agens (agent) identities with a passkey and no gas.