Overview
Address:0x0000000000000000000000000000000000000001
Introduced: Frontier
EIP: EIP-2 (Signature Malleability Protection)
The ecRecover precompile recovers the Ethereum address from an ECDSA signature using the secp256k1 elliptic curve. Given a message hash and signature components (v, r, s), it returns the 20-byte Ethereum address of the signer. This is fundamental for transaction validation and signature verification in Ethereum.
EIP-2 enhanced this precompile by enforcing signature malleability protection, requiring that the s value be in the lower half of the curve order. This prevents transaction replay attacks where the same signature could be used with different s values.
Gas Cost
Fixed:3000 gas
The cost is constant regardless of input validity. Even invalid signatures consume the full gas amount.
Input Format
Output Format
Usage Example
Error Conditions
- Out of gas (gasLimit < 3000)
- Invalid v value (not 0, 1, 27, or 28) → returns zero address
- r = 0 or r ≥ secp256k1_n → returns zero address
- s = 0 or s > secp256k1_n/2 → returns zero address (EIP-2)
- Point not on curve → returns zero address
- Invalid signature → returns zero address
Use Cases
- Transaction validation: Ethereum nodes use this to recover sender addresses from transaction signatures
- Signature verification: Smart contracts verify off-chain signed messages (EIP-191, EIP-712)
- Meta-transactions: Contracts validate user signatures for gasless transactions
- Multisig wallets: Verify multiple signers approved a transaction
- Account abstraction: Validate custom signature schemes
Implementation Details
- Zig: Uses secp256k1 public key recovery from crypto module, applies keccak256 to derive address
- TypeScript: Wraps Secp256k1.recoverPublicKey and Keccak256.hash
- Integration: Depends on Secp256k1 and Keccak256 crypto modules
- Security: Enforces EIP-2 malleability protection - rejects s > secp256k1_n/2
- Validation: Checks r and s are in valid range [1, secp256k1_n)
Signature Malleability (EIP-2)
Before EIP-2, signatures had malleability: for every valid signature (r, s, v), there exists another valid signature (r, -s mod n, v’). This allowed attackers to modify transaction signatures without invalidating them. EIP-2 solved this by requirings ≤ secp256k1_n/2, where secp256k1_n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141. Any signature with s in the upper half is rejected.
Test Vectors
References
Specifications
- Yellow Paper - Appendix E (Precompiled Contracts)
- EIP-2: Homestead Hard-fork Changes
- secp256k1 Curve Parameters

