Summary
Add a P256 (secp256r1) signature verification precompile so that end users can authenticate transactions using device passkeys (FaceID, fingerprint, hardware security keys) via WebAuthn, instead of managing secp256k1 private keys.
Motivation
Private key management is the single biggest UX barrier for consumer-facing blockchain applications. Users lose keys, get phished, and struggle with seed phrases. Modern devices universally support WebAuthn/FIDO2 passkeys backed by the P256 curve (secp256r1), which is different from Ethereum's secp256k1.
Tempo has validated this pattern: their 0x76 transaction type supports passkey-based biometric authentication (FaceID, fingerprint) as a first-class signing method. Since ev-reth already implements the 0x76 transaction type (ADR-0003), adding P256 verification is the natural next step to unlock passkey auth.
Customer impact:
- Users sign transactions with biometrics -- no seed phrases, no browser extensions
- Mobile-first UX becomes possible without smart contract wallets
- Reduces key management liability for enterprise customers
- Compatible with existing WebAuthn infrastructure (Apple, Google, Microsoft passkey providers)
Design
Precompile specification
- Address: Fixed system address (e.g.,
0x0100 or a higher address to avoid EIP conflicts)
- Input:
(hash: bytes32, r: bytes32, s: bytes32, x: bytes32, y: bytes32) -- the message hash and P256 public key coordinates
- Output:
(success: bytes32) -- 1 if signature is valid, 0 otherwise
- Gas cost: ~3,450 gas (per RIP-7212 / EIP-7212 benchmarks)
Integration points
crates/ev-precompiles/: Implement P256 verification precompile using a well-audited Rust P256 library (p256 crate from RustCrypto)
crates/ev-revm/: Register the precompile in the custom EVM configuration, activated via chainspec height
crates/ev-primitives/: Extend EvNodeTransaction (0x76) signature validation to accept P256 signatures as an alternative to secp256k1
- Chainspec: Add
p256_precompile_activation_height to EvolveConfig extras
Transaction flow with passkeys
- User authenticates with device biometric (FaceID/fingerprint)
- Device signs the transaction hash using its P256 private key via WebAuthn
- Transaction includes P256 signature instead of secp256k1
- EVM handler verifies signature via the P256 precompile
tx.origin maps to the user's P256-derived address
Prior art
Summary
Add a P256 (secp256r1) signature verification precompile so that end users can authenticate transactions using device passkeys (FaceID, fingerprint, hardware security keys) via WebAuthn, instead of managing secp256k1 private keys.
Motivation
Private key management is the single biggest UX barrier for consumer-facing blockchain applications. Users lose keys, get phished, and struggle with seed phrases. Modern devices universally support WebAuthn/FIDO2 passkeys backed by the P256 curve (secp256r1), which is different from Ethereum's secp256k1.
Tempo has validated this pattern: their 0x76 transaction type supports passkey-based biometric authentication (FaceID, fingerprint) as a first-class signing method. Since ev-reth already implements the 0x76 transaction type (ADR-0003), adding P256 verification is the natural next step to unlock passkey auth.
Customer impact:
Design
Precompile specification
0x0100or a higher address to avoid EIP conflicts)(hash: bytes32, r: bytes32, s: bytes32, x: bytes32, y: bytes32)-- the message hash and P256 public key coordinates(success: bytes32)--1if signature is valid,0otherwiseIntegration points
crates/ev-precompiles/: Implement P256 verification precompile using a well-audited Rust P256 library (p256crate from RustCrypto)crates/ev-revm/: Register the precompile in the custom EVM configuration, activated via chainspec heightcrates/ev-primitives/: ExtendEvNodeTransaction(0x76) signature validation to accept P256 signatures as an alternative to secp256k1p256_precompile_activation_heighttoEvolveConfigextrasTransaction flow with passkeys
tx.originmaps to the user's P256-derived addressPrior art