{"id":"EIP-7951","name":"Precompile for secp256r1 Curve Support","status":"Final","chain":"both","category":{"id":"onboarding","name":"Onboarding & Access","description":"Getting users into web3 without friction"},"journeyStages":[{"id":"authentication","name":"Authentication & Identity","description":"Proving who you are and logging in"}],"uxImpact":"EIP-7951 defines native P-256 (secp256r1) signature verification. That primitive can support passkey-compatible smart-account designs when an account and wallet implement WebAuthn, authenticator, and recovery flows. It does not itself provide a universal wallet, biometric onboarding, synced recovery, or never-extractable platform key. Monad lists native P256VERIFY support under MONAD_FOUR; verify account and provider support separately.","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","officialUrl":"https://eips.ethereum.org/EIPS/eip-7951","kind":"proposal","hasDetailedContent":true,"content":{"id":"EIP-7951","sources":[{"label":"Official EIP-7951 specification","url":"https://eips.ethereum.org/EIPS/eip-7951","type":"official-spec"},{"label":"Monad precompiles documentation","url":"https://docs.monad.xyz/developer-essentials/precompiles","type":"reference"},{"label":"Monad developer changelog","url":"https://docs.monad.xyz/developer-essentials/changelog","type":"reference"},{"label":"Ethereum Fusaka activation and P-256 support","url":"https://ethereum.org/roadmap/fusaka/","type":"reference"},{"label":"Monad guide: Mera passkey accounts (a separate EOA approach)","url":"https://docs.monad.xyz/tooling-and-infra/wallet-infra/embedded-wallets","type":"reference"},{"label":"Category Labs Mera: implementation and preview status","url":"https://github.com/category-labs/mera","type":"reference"}],"lastReviewed":"2026-09-18","specConstraints":[{"id":"p256verify-precompile-surface","constraint":"P256VERIFY is a precompile at address 0x100 for secp256r1 ECDSA verification with a 6900-gas cost in this specification.","appliesTo":"infrastructure","normativity":"normative","specQuote":"We introduce `P256VERIFY` a precompile at the address `0x100` which performs ECDSA signature verification over the secp256r1 curve with a gas cost of `6900` gas","specSection":"Specification / Precompile","specUrl":"https://eips.ethereum.org/EIPS/eip-7951#precompile","designImplication":"Gate passkey or P-256 flows on chain support for the precompile and account for its specified gas cost when presenting transaction estimates."},{"id":"p256verify-invalid-input-failure","constraint":"Inputs that cannot encode valid field elements or points must produce a failed verification result.","appliesTo":"infrastructure","normativity":"normative","specQuote":"On inputs that cannot be valid encodings of field elements or points, the precompile *must* return `` (failure).","specSection":"Specification / Points and Encoding / Behavior on Invalid Inputs","specUrl":"https://eips.ethereum.org/EIPS/eip-7951#behavior-on-invalid-inputs","designImplication":"Render malformed P-256 input as a verification failure with a recovery path, not as an accepted signature or an unexplained successful transaction."},{"id":"p256verify-no-revert-equal-gas","constraint":"P256VERIFY must not revert for invalid inputs or verification failures and must consume the same gas as a successful verification.","appliesTo":"infrastructure","normativity":"normative","specQuote":"The precompile MUST NOT revert under any circumstances. Invalid inputs or verification failures MUST return `` and consume the same amount of gas had verification succeeded.","specSection":"Specification / Gas Schedule / Gas Burning on Error","specUrl":"https://eips.ethereum.org/EIPS/eip-7951#gas-burning-on-error","designImplication":"Keep failure handling in the verification result path rather than treating a revert as the only invalid-signature signal, and make the fee estimate predictable across failure and success."},{"id":"rip7212-interface-compatibility","constraint":"The precompile keeps RIP-7212 interface compatibility: address 0x100, 160-byte input, 32-byte output, and the same return values, while using a different gas cost.","appliesTo":"infrastructure","normativity":"backwards-compatibility","specQuote":"The precompile maintains a similar interface as RIP-7212 to ensure compatibility with existing Layer 2 deployments:\n\n- Same address: `0x100`\n- Same input format: 160 bytes\n- Same output format: 32 bytes\n- Different gas cost: 3450 gas vs 6900 gas\n- Same return values","specSection":"Backwards Compatibility / Interface Compatibility","specUrl":"https://eips.ethereum.org/EIPS/eip-7951#interface-compatibility","designImplication":"Reuse existing RIP-7212 call encoding and result handling where supported, but update fee previews and availability messaging for the 6900-gas schedule."},{"id":"rip7212-full-compatibility","constraint":"The EIP preserves full interface compatibility with deployed RIP-7212 implementations and does not break existing valid use cases.","appliesTo":"infrastructure","normativity":"backwards-compatibility","specQuote":"This EIP maintains full interface compatibility with RIP-7212 implementations deployed on Layer 2 networks. The same contract bytecode that works with RIP-7212 will work with this specification.\n\nThe security fixes are transparent to correctly implemented callers - they only affect edge cases that should have failed verification anyway. No existing valid use cases are broken.","specSection":"Backwards Compatibility","specUrl":"https://eips.ethereum.org/EIPS/eip-7951#backwards-compatibility","designImplication":"Keep established P-256 integration paths available during migration and explain that changed outcomes are invalid-edge-case handling rather than a new user permission model."},{"id":"p256-cryptographic-security","constraint":"secp256r1 is described as providing approximately 128 bits of security and as having undergone extensive analysis.","appliesTo":"infrastructure","normativity":"security-considerations","specQuote":"The secp256r1 curve provides approximately 128 bits of security, equivalent to secp256k1 already in use in Ethereum. The curve parameters are standardized by NIST SP 800-186[^1] and have undergone extensive cryptographic analysis by the wider cryptographic community in addition to this curve being deployed to several L2s in the form of RIP-7212.","specSection":"Security Considerations / Cryptographic Security","specUrl":"https://eips.ethereum.org/EIPS/eip-7951#cryptographic-security","designImplication":"Describe P-256 support as a cryptographic interoperability choice, not as a weaker passkey exception, while retaining the chain's actual support and threat-model caveats."},{"id":"p256-malleability-checks","constraint":"P-256 signatures are not required to be non-malleable; applications that require non-malleability should add application-layer checks.","appliesTo":"application","normativity":"security-considerations","specQuote":"Unlike secp256k1 ECDSA signatures, secp256r1 ECDSA signatures are not required to be non-malleable per NIST FIPS 186-5 standard [^2]. Applications requiring non-malleability should implement additional checks at the application layer.","specSection":"Security Considerations / Malleability","specUrl":"https://eips.ethereum.org/EIPS/eip-7951#malleability","designImplication":"If the product relies on signature uniqueness for replay, deduplication, or audit records, add and disclose an application-level non-malleability policy."},{"id":"p256-side-channel-boundary","constraint":"The precompile is not required to implement every operation with constant-time algorithms.","appliesTo":"infrastructure","normativity":"security-considerations","specQuote":"We explicitly state that this precompile **IS NOT REQUIRED** to perform all the operations using constant time algorithms.","specSection":"Security Considerations / Side-Channel Resistance","specUrl":"https://eips.ethereum.org/EIPS/eip-7951#side-channel-resistance","designImplication":"Do not market precompile availability alone as a complete side-channel guarantee for high-sensitivity signing flows; assess the surrounding wallet and host environment."}],"lastUpdated":"2026-09-18","summary":"EIP-7951 defines native P-256 (secp256r1) signature verification. That primitive can support passkey-compatible smart-account designs when an account and wallet implement WebAuthn, authenticator, and recovery flows. It does not itself provide a universal wallet, biometric onboarding, synced recovery, or never-extractable platform key. Monad lists native P256VERIFY support under MONAD_FOUR; verify account and provider support separately.","partialDeployment":{"body":"Native P-256 verification is a protocol primitive. Wallet, WebAuthn, biometric, backup, and recovery behavior depends on the account and provider implementation."},"applicability":{"whenToUse":["Your account design needs P-256 or WebAuthn signature verification.","You are evaluating passkey-compatible smart accounts with explicit wallet and provider support.","The flow can explain authenticator, device, backup, and recovery assumptions.","Connect flows must list wallets with names, icons, and explicit user choice."],"whenToAvoid":["Treat P-256 verification as proof that a wallet supports passkeys.","Promise Face ID, Touch ID, cloud sync, or recovery without provider-specific support.","Assume credentials are never extractable or that platform backup is available.","Wallet or chain support is fixed and users cannot choose providers."]},"designerTakeaways":["Design passkey-compatible account flows only when the wallet and account implementation support WebAuthn.","Separate cryptographic verification from biometric prompts, device behavior, and recovery.","Show provider, authenticator, backup, and recovery assumptions before signing.","Mera (preview) offers passkey-based EOA accounts on Monad through WebAuthn PRF. This is an available alternative to P-256 smart-account validation, not an EIP-7951 integration."],"problemsSolved":[{"problem":"Seed phrases are terrible UX and security risk","oldWay":"Write down 12-24 words, store them safely, never lose them","newWay":"Use a passkey-compatible account flow when the wallet and provider support it","impact":"critical"},{"problem":"New users scared away by key management complexity","oldWay":"Explain private keys, wallets, security... users leave","newWay":"Reduce key-management friction with an account implementation that exposes its supported authenticators","impact":"critical"},{"problem":"Mobile wallet apps have security vulnerabilities","oldWay":"Keys stored in app, potentially accessible to malware","newWay":"Use platform authenticators or wallet controls where supported; do not infer key storage from EIP-7951","impact":"high"},{"problem":"Hardware wallets expensive and clunky","oldWay":"Buy $100+ device, connect via USB, manage firmware","newWay":"Use P-256 verification as one building block for account designs; hardware-wallet tradeoffs remain product-specific","impact":"high"},{"problem":"Account recovery requires seed phrase backup","oldWay":"Lose phrase = lose funds forever","newWay":"Provide an explicit recovery path; EIP-7951 does not provide backup or credential sync","impact":"high"}],"uxPatterns":[{"name":"Passkey-Compatible Account Creation","description":"Account creation for a wallet and smart-account implementation that supports WebAuthn and P-256 verification","userFlow":["User chooses a supported wallet or account implementation","The platform authenticator prompt appears when supported","User authenticates with the available method","The account registers a P-256 credential","The account's recovery path is shown before use"]},{"name":"Transaction Signing with Biometric","description":"Confirm transactions with an authenticator when the wallet and account support it","userFlow":["User initiates transaction","App shows transaction details","The wallet invokes its supported authenticator","User authenticates or chooses the available fallback","Transaction signed and broadcast"]},{"name":"Multi-Device Account Access","description":"Show provider-reported credential or account access across devices when supported","userFlow":["User opens app on new device","The provider checks for supported credentials or recovery methods","Shows available devices or recovery options","User authenticates with the available method","Wallet access is granted or a supported fallback is offered"]},{"name":"Recovery for Passkey-Compatible Accounts","description":"Show the recovery methods configured by the account and provider","userFlow":["User views recovery settings","Sees the account's configured primary and fallback methods","Adds an available recovery method","Confirms the recovery method's status","All methods shown with status"]}],"uiComponents":[{"name":"BiometricPrompt","description":"Optional platform-authenticator prompt; availability and wording are provider and device specific","states":["idle","prompting","success","failed","unavailable"],"props":["reason","fallbackTitle","onSuccess","onFail"]},{"name":"PasskeyCreator","description":"Creates or registers a passkey-compatible credential when the wallet and account support it","states":["ready","creating","syncing","complete","error"],"props":["accountAddress","rpId","userName"]},{"name":"CredentialAvailability","description":"Show credential or recovery methods reported by the provider. Offer sync only when that provider supports it.","states":["checking","available","unavailable","recovery-required"],"props":["availableMethods","provider","onRecover"]},{"name":"PasskeyAuthButton","description":"Initiates passkey authentication flow","states":["idle","waiting","authenticated","error"],"props":["onAuth","fallbackOptions"]},{"name":"RecoveryMethodManager","description":"Configure and view recovery options","states":["no-backup","partial","fully-configured"],"props":["methods[]","onAddMethod","onRemoveMethod"]}],"antiPatterns":[{"pattern":"Only offering passkey with no fallback","why":"Lost all devices = lost wallet forever","instead":"Offer an explicit recovery path appropriate to the account; do not assume guardians are always required","severity":"critical"},{"pattern":"Treating native P-256 verification as a complete passkey wallet","why":"A cryptographic primitive does not establish wallet, authenticator, or account support","instead":"Explain the supported wallet, account, and authenticator in human terms","severity":"high"},{"pattern":"Not explaining cloud sync clearly","why":"Users don't understand how recovery works","instead":"Show the provider's actual backup or sync behavior, or say when it is unavailable","severity":"medium"},{"pattern":"Hiding where passkey is stored","why":"Users worried about security can't evaluate it","instead":"Explain the wallet and account provider's credential and key behavior; EIP-7951 alone does not establish secure-chip storage","severity":"medium"},{"pattern":"No supported authenticator or recovery fallback","why":"A platform authenticator may be unavailable or the device may be lost","instead":"Provide the fallback methods supported by the account and wallet","severity":"high"},{"pattern":"Requiring passkey for low-value actions","why":"Friction fatigue — users annoyed by constant prompts","instead":"Use scoped session permissions only when the account implementation supports them and the user has authorized appropriate limits.","severity":"medium"}],"onMonad":[{"aspect":"Native Support","ethereum":"Ethereum mainnet includes P256VERIFY at 0x0100 following Fusaka, activated on December 3, 2025.","monad":"Monad exposes P256VERIFY at 0x0100; current first-party docs list a 6,900-gas precompile and on-chain verification support.","designImplication":"Treat passkey-compatible account support as implementation-dependent even when the native primitive is available."},{"aspect":"Transaction Confirmation","ethereum":"Signing and confirmation timing depend on the network and wallet path.","monad":"P256VERIFY does not itself guarantee a confirmation time; use current wallet and RPC behavior.","designImplication":"Keep authenticator feedback separate from transaction inclusion and confirmation states."},{"aspect":"Gas for Verification","ethereum":"EIP-7951 defines a 6,900-gas native verification call. WebAuthn processing and the complete account transaction add further costs.","monad":"The native precompile is listed at 6,900 gas; the full account flow still depends on calldata, WebAuthn handling, and account logic.","designImplication":"Benchmark the complete account path before promising per-transaction economics."},{"aspect":"Reserve Balance","ethereum":"N/A","monad":"The account type and transaction path determine reserve handling. A passkey is an authentication method, not an account type; a contract account is not automatically an EIP-7702-delegated EOA.","designImplication":"Determine the account type and fee payer before applying reserve eligibility or offering MAX."}],"keyTakeaways":["P-256 verification can support passkey-compatible account designs","Wallet, WebAuthn, authenticator, and recovery support are separate dependencies","Use human terms for the authentication methods the provider actually supports","Show credential backup and recovery status only when the provider reports it","On Monad: native P256VERIFY is available; benchmark and integrate an account implementation"],"technicalNotes":"EIP-7951 defines a precompile for secp256r1 (P-256) signature verification, the curve used by many WebAuthn credentials. It does not create passkeys, choose an authenticator, store keys, sync credentials, or provide account recovery. Monad's first-party precompile documentation lists P256VERIFY at 0x0100 with a 6,900-gas cost, while the changelog records the feature under MONAD_FOUR. A P-256 smart-account flow needs account validation logic, authenticator integration, chain-aware gas and reserve handling, and an explicit recovery path. Mera, Category Labs' preview library, provides a separate approach: WebAuthn PRF output derives ordinary secp256k1 EOA keys, without requiring a smart-account contract or the P-256 precompile. It requires a PRF-capable authenticator and compatible browser or native integration. Account recovery depends on access to the same passkey, relying-party domain, and derivation settings, or an app-provided export/recovery path. Applications must manage signing sessions and explain backup and recovery."},"sources":[{"label":"Official specification","url":"https://eips.ethereum.org/EIPS/eip-7951","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=EIP-7951","type":"discussion"},{"label":"Monad precompiles documentation","url":"https://docs.monad.xyz/developer-essentials/precompiles","type":"reference"},{"label":"Monad developer changelog","url":"https://docs.monad.xyz/developer-essentials/changelog","type":"reference"},{"label":"Ethereum Fusaka activation and P-256 support","url":"https://ethereum.org/roadmap/fusaka/","type":"reference"},{"label":"Monad guide: Mera passkey accounts (a separate EOA approach)","url":"https://docs.monad.xyz/tooling-and-infra/wallet-infra/embedded-wallets","type":"reference"},{"label":"Category Labs Mera: implementation and preview status","url":"https://github.com/category-labs/mera","type":"reference"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/EIP-7951","markdown":"https://www.eipsfordesigners.com/standards/EIP-7951/content.md","agent":"https://www.eipsfordesigners.com/standards/EIP-7951/agent.md","api":"https://www.eipsfordesigners.com/api/standards/EIP-7951","official":"https://eips.ethereum.org/EIPS/eip-7951","discussion":"https://ethereum-magicians.org/search?q=EIP-7951"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}