ecrecover

The ecrecover function is a core precompiled contract (at address 0x1) that performs Elliptic Curve Digital Signature Algorithm (ECDSA) recovery on the secp256k1 curve. It takes four inputs: the 32-byte message hash (e.g., keccak256 hash), the recovery identifier v, and the signature components r and s. Its output is the 20-byte Ethereum address of the account that originally signed the message. This function is fundamental for on-chain signature verification, enabling smart contracts to authenticate actions like token approvals, meta-transactions, and decentralized identity proofs without relying on external oracles.

A critical nuance is that ecrecover does not verify the signature itself; it merely performs mathematical recovery. The calling contract must explicitly check that the returned address is non-zero and matches an expected signer. Furthermore, developers must ensure the provided hash is the exact data the user intended to sign, often a structured EIP-712 hash or a prefixed message hash ("\x19Ethereum Signed Message:\n" + len(message) + message) to prevent replay attacks across different contexts. Mismanagement of these inputs is a common source of security vulnerabilities.

In practice, ecrecover is invoked within Solidity using the global ecrecover(bytes32 hash, uint8 v, bytes32 r, bytes32 s) returns (address) function. For example, a multisig wallet contract uses it to validate that a transaction proposal was signed by a sufficient number of authorized signers. While ecrecover is gas-efficient for single verifications, newer abstractions like EIP-1271 for contract signatures and account abstraction (EIP-4337) offer more flexible verification schemes, though they often rely on ecrecover as a foundational primitive.

The name ecrecover is a contraction of Elliptic Curve Recover. It is a precompiled contract—a highly optimized, native function—within the Ethereum Virtual Machine. Its sole purpose is to execute the ECDSA public key recovery operation, which is the process of deriving the public key (and thus the Ethereum address) from a signed message hash and its corresponding signature. This function is fundamental to verifying the authenticity of transactions and signed messages on-chain.

The Elliptic Curve Digital Signature Algorithm (ECDSA) is the cryptographic standard used by Ethereum, specifically the secp256k1 curve. In a typical signature verification, you have the public key and verify it matches the signature. ECDSA recovery is the inverse: given the signature and the original message hash, the algorithm can compute the public key. The ecrecover function encapsulates this complex mathematical operation, providing a gas-efficient way for smart contracts to perform identity verification without implementing the cryptography themselves.

The function's signature is ecrecover(bytes32 hash, uint8 v, bytes32 r, bytes32 s) returns (address). The inputs are the components of an ECDSA signature: the hash of the signed data, and the v, r, and s values that constitute the signature itself. A critical security note is that ecrecover returns address(0) on failure, which smart contracts must explicitly check. Its origin is deeply tied to Ethereum's need for native cryptographic primitives that enable trustless verification, forming the bedrock for systems like multi-signature wallets and permissioning schemes.

The ecrecover function is a precompiled contract within the Ethereum Virtual Machine (EVM) that performs Elliptic Curve Digital Signature Algorithm (ECDSA) signature recovery. Given a 65-byte signature (comprising v, r, and s values) and the original 32-byte message hash (messageHash), it computes and returns the 20-byte Ethereum address of the signer. This process is fundamental for verifying that a specific account authorized a transaction or message, as the recovered address must match the expected signer.

The function operates on the secp256k1 elliptic curve used by Ethereum. It takes the signature components—r and s (the signature itself) and v (the recovery identifier, 27 or 28)—and mathematically derives the public key from them using the signed hash. This public key is then hashed with Keccak-256, and the last 20 bytes of that hash become the final Ethereum address. A critical prerequisite is that the messageHash input must be the exact Keccak-256 hash of the original data, often requiring senders to follow the EIP-191 or EIP-712 structured signing standards to prevent replay attacks.

Developers most commonly interact with ecrecover in Solidity via the global ecrecover(bytes32 hash, uint8 v, bytes32 r, bytes32 s) returns (address) function. A typical verification pattern involves hashing the message with keccak256, calling ecrecover, and comparing the returned address to a known signer. It is essential to validate the s value is within the lower half of the curve's order to prevent signature malleability, a check often enforced by OpenZeppelin's ECDSA library which provides a safer wrapper for this low-level operation.

While ecrecover is a core verification tool, its direct use has pitfalls. The caller is responsible for all pre-hashing logic and security checks. Furthermore, it only returns an address; for broader signature schemes, the newer EIP-1271 standard for contract signatures is used, allowing smart contracts to validate signatures in a more flexible way. Understanding ecrecover is key to building secure systems for meta-transactions, multi-signature wallets, and any application requiring off-chain authorization.

The following Solidity code snippet demonstrates a common pattern for signature verification using ecrecover. The function verifySignature takes a messageHash (typically a keccak256 hash of structured data), a v, r, s signature tuple, and the expected signer address. It uses the ecrecover precompile to derive the signing address from the hash and signature, then compares it to the provided signer address, returning true if they match. This is the foundational mechanism for meta-transactions, permit functions (like ERC-2612), and off-chain authorization.

Key components of the example include: the use of keccak256 to create a Ethereum Signed Message hash, the proper splitting of the signature bytes into v, r, and s components, and the critical check that recoveredSigner is not the zero address, which indicates an invalid signature. The ecrecover function is called as a low-level staticcall, and its return value is the 20-byte Ethereum address of the entity that signed the original message. It is essential that the exact same messageHash that was signed is provided for verification.

In practice, developers must be aware of signature malleability and replay attack vectors. To prevent malleability, ensure the s value is in the lower half of the secp256k1 curve's order (checking s <= 0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0). To prevent cross-context replay, the hashed message should include the contract's address (address(this)) and a nonce. The upcoming EIP-7212 aims to standardize and optimize secp256r1 signature verification, which may offer a more gas-efficient and standardized alternative for certain use cases compared to the current ecrecover pattern.