RIP-7212 is a Rollup Improvement Proposal that adds a native precompile to Ethereum L2s for verifying secp256r1 (P-256) signatures. It drops the gas cost of P-256 verification from roughly 300,000 gas to about 3,450 gas, a reduction of nearly 100x. That cost reduction is what makes passkey-based wallets practical on EVM chains. The precompile lives at address 0x100.
​

To understand why that matters, you need to know what P-256 is and why Ethereum could not use it cheaply before RIP-7212 existed.
​

Ethereum and Bitcoin both rely on a different curve called secp256k1 for signing transactions. The secp256k1 curve was chosen for its favorable security properties and the fact that EVM had a hardcoded precompile (at address 0x01) for recovering its signatures cheaply. But the devices people actually carry around, phones, laptops, hardware security keys, use a different curve: secp256r1, also called P-256. Apple's Secure Enclave, Android's Keystore system, and the WebAuthn/FIDO2 standard that backs passkeys all generate and verify P-256 signatures natively.
​

Without a precompile, verifying a P-256 signature inside the EVM required reimplementing elliptic curve arithmetic entirely in Solidity. That pushed gas costs to the neighborhood of 300,000 gas per verification. At realistic gas prices, that is an impractical cost to impose on every wallet transaction.
​

RIP-7212 solves this by adding P-256 verification as a native precompile at the L2 level, analogous to how secp256k1 recovery already works at the base layer. The spec is available at the ethereum/RIPs repository on GitHub.
​

Before RIP-7212, developers who wanted to accept WebAuthn or passkey signatures in a smart contract had to pay around 300,000 gas per verification. That figure is not theoretical: it reflects the real cost of running full elliptic curve point multiplication in the EVM using pure Solidity libraries. For context, a simple ETH transfer costs 21,000 gas. A Uniswap v3 swap costs roughly 120,000 to 150,000 gas. Signature verification at 300,000 gas would cost more than two Uniswap swaps for the single act of proving you authorized a transaction.
​

The root cause is that the EVM has no built-in instruction for P-256 arithmetic. Every multiplication, addition, and modular inverse operation must run through the EVM's general-purpose opcode set. Elliptic curve verification requires several of these operations chained together. Each opcode costs gas, and the total accumulates fast.
​

Libraries like daimo-eth/p256-verifier made this workable for some use cases, but 300,000 gas was still prohibitive for anything that needed to happen on every transaction. It ruled out passkey authentication as a first-class signing mechanism and pushed developers toward custodial workarounds that reintroduce the key-management risks they were trying to eliminate.
​

The deeper structural issue is that device-native cryptography and EVM-native cryptography have historically operated on different curves. Until RIP-7212 bridged them, wallets either required users to manage secp256k1 private keys (foreign to every standard mobile security chip) or accepted prohibitive gas overhead. Neither option produces a wallet that a non-technical person can use safely.
​

For more on how cryptographic proofs and signature verification work at the blockchain layer, that background is worth reviewing before going further.
​

RIP-7212 introduces a precompile at address 0x100 that accepts a P-256 signature verification request and returns a result for approximately 3,450 gas. The L2 node handles the actual elliptic curve math natively in its execution client rather than running it through the EVM opcode loop, which is why the cost is so much lower.
​

The calldata format is fixed. A call to 0x100 passes exactly 160 bytes:

The precompile returns a single 32-byte word. A value of 1 means the signature is valid. Any invalid input or failed verification returns empty bytes or 0. A smart contract checks the return value and branches accordingly, exactly the same pattern used when calling any other precompile.
​

From a security standpoint, the spec mandates that the implementation follow NIST FIPS 186-5 for P-256 parameter definitions and signature verification steps. This matters because P-256 implementations with subtle parameter deviations can be vulnerable to signature malleability or forgery. The NIST standard eliminates ambiguity.
​

The 100x gas reduction changes the economics entirely. At 3,450 gas, a passkey verification adds a modest, predictable overhead to any transaction rather than dominating its cost. Developers can now use 0x100 in account validation logic, in smart contract wallets, and in session key checks without pricing users out of routine interactions.
​

The two curves serve different ecosystems and were optimized for different deployment environments. secp256k1 powers Bitcoin and Ethereum and benefits from decades of custom tooling in the blockchain world. secp256r1 (P-256) was standardized by NIST and is built into virtually every mobile security chip and hardware authenticator sold today. They are mathematically similar but not interchangeable, and their hardware support profiles are nearly opposite.
​

The private-key exportability row is particularly significant. A secp256k1 key stored in a software wallet can be exported, copied, and stolen. A P-256 key generated inside an Apple Secure Enclave or Android Keystore cannot be read out of the chip by any software, including malware. The hardware generates the key, stores it internally, and only performs signing operations on request. This is a fundamentally different security model from a seed phrase, and it is the model that RIP-7212 brings to onchain transaction authorization.
​

The WebAuthn guide at webauthn.guide covers how P-256 fits into the broader FIDO2 authentication stack if you want a deeper understanding of the protocol layer above the curve itself.
​

A passkey wallet uses biometric authentication (Face ID, fingerprint, Windows Hello) to authorize blockchain transactions without a seed phrase. RIP-7212 is the missing piece that makes passkey wallets viable onchain: it provides the cheap verification endpoint that a smart contract wallet needs to check whether a biometric-authorized signature is legitimate.
​

The full flow works like this:

The private key never leaves the device. The user never sees or manages a seed phrase. If the user loses their phone, recovery works through standard passkey backup mechanisms (iCloud Keychain, Google Password Manager) or through social/guardian recovery built into the smart contract wallet. This is materially different from seed-phrase wallets where losing the phrase means losing funds permanently.
​

The WebAuthn specification defines the authentication ceremony in detail. The blockchain layer, via RIP-7212, handles only the final step: verifying that a valid P-256 signature authorizes a given transaction hash. The two protocols complement each other cleanly.
​

Understanding how private keys work in crypto wallets helps clarify why hardware-bound, non-exportable keys represent such a significant upgrade for end-user security.
​

RIP-7212 is a rollup-level improvement, not an Ethereum mainnet EIP, because L1 gas economics and the broader EIP governance process make deploying new precompiles to mainnet slower. L2 teams can ship it independently. Several major L2s had already deployed the precompile by early 2024, ahead of any formal mainnet equivalent.
​

The OP Stack deployment is notable because Base inherits it automatically. Any chain running the Canyon hard fork or later already has the precompile available. This means the combined user base across OP Stack chains can use passkey wallets without any additional infrastructure changes from wallet developers.
​

The broader deployment picture reflects how RIPs differ from EIPs in governance: a rollup team can implement an RIP unilaterally, test it on their chain, and ship it without waiting for Ethereum mainnet consensus. The ethereum/RIPs repository tracks the proposal status and deployment history across chains.
​

RIP-7212 and ERC-4337 solve different problems but combine to produce something neither delivers alone: a seedless smart wallet secured by device biometrics. ERC-4337 defines how smart contract accounts submit and validate transactions using a mempool of UserOperations. RIP-7212 gives those contracts a cheap way to validate P-256 signatures during the validation step. Together they close the gap between consumer-grade authentication and onchain key authorization.
​

In a pure ERC-4337 wallet without RIP-7212, the account's validateUserOp function could call a P-256 library, but the 300,000 gas cost would make the wallet uneconomical. The bundler (the entity that submits UserOperations onchain) simulates validation before including a transaction, and a 300,000-gas validation step would push bundler fees high enough to deter use.
​

With RIP-7212 deployed on the L2, the same validateUserOp function calls 0x100 directly. The 3,450 gas cost is comparable to any other signature check. Bundlers include it in standard fee estimates. Users pay a transaction fee that feels like a normal swap or transfer, not a premium for exotic cryptography.
​

This architecture is what teams like Coinbase Smart Wallet built on. The wallet stores a passkey-generated P-256 public key onchain, validates every transaction against it using the RIP-7212 precompile, and presents users with a Face ID or fingerprint prompt instead of a seed phrase confirmation dialog. No browser extension. No seed phrase. No separate hardware wallet.
​

The combination also works with ERC-7715 session permissions, where a user can grant a dapp limited spending permissions for a session. The session key can itself be a P-256 key, verified cheaply via the precompile, so the full interaction from passkey authentication through session-scoped signing happens without touching a seed phrase at any point.
​

For a full explanation of the ERC-4337 account abstraction model that underpins all of this, see What Is ERC-4337: Account Abstraction Explained.
​

Not yet. RIP-7212 is a Rollup Improvement Proposal, scoped to L2s. Ethereum mainnet has a separate process (EIPs) for adding precompiles. An analogous EIP-7212 exists under discussion, but as of mid-2026 it had not been scheduled for a mainnet hard fork. Developers targeting mainnet still face the ~300,000 gas cost for P-256 verification.
​

Yes. The Secure Enclave generates the key internally and will not export the private key bytes under any circumstances. Signing requests require biometric authorization. An attacker with access to your device cannot extract the key through software. The security model is meaningfully stronger than a software wallet storing a secp256k1 private key in application memory.
​

Recovery depends on how the wallet was set up. Passkeys backed up to iCloud Keychain or Google Password Manager restore automatically when you sign into a new device. Smart contract wallets can also implement social recovery or guardian-based recovery modules that let trusted contacts authorize a key rotation. Unlike seed-phrase wallets, losing a device does not necessarily mean losing access to funds.
​

No. Externally owned accounts (EOAs) are hardcoded to secp256k1. RIP-7212 benefits only smart contract wallets that implement their own signature validation logic and can call the precompile at 0x100. This is one reason the RIP-7212 and ERC-4337 combination matters: ERC-4337 smart accounts can define whatever validation logic they want, including P-256 verification.
​

The RIP-7212 spec sets 3,450 gas as the cost for a successful verification call. This is a fixed cost defined at the protocol level, analogous to other precompile gas schedules. It does not vary with the size of inputs (which are always 160 bytes) or network congestion. The base fee still applies to the transaction as a whole, but the precompile call itself costs a predictable 3,450 gas every time.
​