Solidity

ecrecover

ecrecover is Solidity's interface to the EVM precompile for recovering an Ethereum address from a secp256k1 signature over a 32-byte hash.

ecrecover attempts to recover the address for a digest and signature; the contract must still validate the signature format and what was signed.

ecrecover Explained in Detail

ecrecover is Solidity's interface to the EVM signature-recovery precompile. It returns the address associated with an ECDSA signature over a 32-byte digest. The inputs are the digest, v, r, and s signature fields.

The recovered address only proves that a key signed the digest. Intent depends on what the digest includes: domain, action, parameters, nonce, deadline, chain ID, and verifying contract.

Smart contract example

The code below recovers a signer but omits replay protection:

function authorize(bytes32 digest, uint8 v, bytes32 r, bytes32 s) external {
    address signer = ecrecover(digest, v, r, s);
    require(signer == owner, "bad signature");
    _grantAccess(msg.sender);
}

If the same digest can be reused, the signature may authorize the action more than once or on another contract.

ecrecover in Auditing

Signature bugs often become access control bugs. The hard part is usually not ecrecover itself, but the message being signed.

Auditors review whether the signed digest is unique to the intended protocol, chain, contract, signer action, and execution window. EIP-712 is often safer than ad hoc string or packed encoding.

Red flags in code

  • Zero-address recovery is not rejected, or the authorized signer can accidentally be address(0).

  • Missing nonce, deadline, chain ID, or verifying contract in the signed data.

  • Signatures accepted across multiple actions or contracts.

  • High-s signatures accepted without malleability handling.

  • Digest built with ambiguous abi.encodePacked inputs.

  • Raw ecrecover used instead of a helper such as OpenZeppelin ECDSA.recover or equivalent low-s validation.

How to test or review it

  • Replay the same signature twice and across similar contracts if possible.

  • Try expired, wrong-chain, wrong-action, and wrong-recipient signatures.

  • Verify nonce consumption happens before or atomically with the authorized action.

  • Confirm the code rejects zero-address recovery and malformed signatures.

  • Prefer established ECDSA helpers and typed-data domains when reviewing production authorization flows.

Sources