Replay Attack Explained in Detail
A replay attack happens when valid data is accepted more than once or in the wrong context. The replayed item might be a signature, permit, bridge message, withdrawal proof, order, or transaction payload.
Replay protection usually uses nonces, deadlines, chain IDs, contract domains, and used-message tracking.
Smart contract example
require(!used[digest], "used");
used[digest] = true;
The contract marks the approved digest as used before it performs the sensitive action.
Replay Attack in Auditing
Replay attacks can duplicate withdrawals, claims, orders, approvals, or cross-chain messages. They are common anywhere off-chain data authorizes on-chain action.
Auditors check exactly what context is bound to the approval and exactly when it is consumed.
Red flags in code
-
Signed data omits nonce, deadline, chain ID, or contract address.
-
A used mapping is updated after external calls.
-
Bridge messages do not track consumed message IDs.
-
The same proof can claim more than once.
-
Signatures are tracked by raw bytes instead of digest and nonce.
How to test or review it
-
Submit the same signature, proof, or message twice.
-
Replay across chains, contracts, users, and epochs.
-
Mutate context fields and check validation.
-
Test cancellation and nonce invalidation.
-
Confirm used-state updates happen before risky interactions.