What is a signature replay attack?
A signature replay attack reuses a valid signature to authorise an action more than once, or somewhere it was never meant to be used: on another chain, another contract, or after it should have expired. It happens when the signed message does not bind the nonce, chain ID, contract address and expiry, which is why standards such as EIP-712 include them.
Where replay happens
- Same contract, same chain. No nonce, so the signature works again.
- Another chain. No chain ID in the signed data, so a signature for a testnet or another chain works on mainnet.
- Another contract. No contract address in the signed data, so a signature for one deployment works on another.
- After cancellation or expiry. No deadline, or cancellations that do not invalidate the signature.
- Bridges. Messages processed more than once, or on more than one destination.
Prevention
- Use EIP-712 typed data with a proper domain separator.
- Include and consume a nonce per signer.
- Include a deadline and check it.
- Track used message hashes, not signature bytes.
- Use a vetted ECDSA library that rejects malleable signatures and checks for the zero address result.
Frequently asked questions
Does EIP-712 prevent replay automatically?
It provides a domain separator that includes the chain ID and contract address, which prevents cross-chain and cross-contract replay. You still need a nonce or other uniqueness check, and an expiry, in the signed data itself.
What is signature malleability?
For ECDSA, a second valid signature can be derived from an existing one. If your contract tracks used signatures by their bytes, the altered one may pass. Track nonces or message hashes instead, and use a library that rejects malleable signatures.
Published Updated