SIGNATURE REPLAY: SINGLE-USE AND DOMAIN-BOUND AUTHORIZATION

A signature replay attack reuses a valid authorization in a context the signer did not intend. The cryptographic check can be completely correct: the defect is that the signed payload or verifier does not make each action single-use and bind it to the intended domain.

REPLAY CLASSES

Within one contract, a signed withdrawal, order, or approval can execute repeatedly if its nonce or operation identifier is not consumed. Across contracts, identical message formats can collide when the digest omits the verifying contract. Across chains or forks, the same authorization may validate wherever the digest omits the relevant chain identifier. Upgrade and migration designs also need an explicit decision about whether old signatures remain valid.

EIP-712 supplies typed hashing and an extensible domain separator, commonly including chainId and verifyingContract. Its specification explicitly says it does not include replay protection. The application must put a nonce, unique identifier, or other consumption rule into the signed action and enforce it on-chain.

ERC-2612 shows the full pattern for token permits: the signed structure includes the owner's current nonce and a deadline, while the domain separates the token contract and chain. A successful permit increments the nonce. Copying only the EIP-712 envelope without those state transitions is insufficient.

REVIEW AND TESTING

Inventory every entry point that accepts a signature, including relayed calls, permits, orders, bridge messages, and administrative approvals. Reconstruct the exact digest from source rather than relying on a function name. Check that it binds all security-relevant arguments, the intended verifier, the intended network or explicit cross-chain scope, an expiry where stale execution matters, and a replay value.

Trace the replay value through every success path. It must be checked and marked used before any external call that can re-enter; if later execution reverts, the EVM rolls that write back. Shared nonce spaces and unordered bitmap nonces have different cancellation and concurrency behavior. Tests must cover successful reuse, failed execution followed by retry, duplicate relayers, chain-ID changes, proxy upgrades, and two verifier contracts with the same implementation.

Firepan can inspect digest construction, domain fields, and nonce consumption in a submitted repository and commit. Off-chain encoders, unsubmitted deployments, and cross-chain governance assumptions remain outside that evidence unless supplied.

MITIGATION AND LIMITS

• Use reviewed EIP-712 helpers, but treat domain separation and replay protection as separate requirements.
• Include a nonce or unique action ID in the signed structure and mark it consumed before external interaction. A successful action must retain the consumed state.
• Include verifyingContract and chainId when authorization is meant for one deployment on one chain. Cross-chain messages need an explicit source/destination design instead of blindly using the current chain.
• Add a deadline when delayed execution changes the signer's risk, and bind every recipient, amount, asset, and mode that affects authority.

Nonce design is protocol design. Sequential nonces impose ordering; unordered nonces need correct bitmap or ID handling. Deadlines limit lifetime but do not make a signature single-use. Signature malleability controls canonical encoding but does not replace replay state.

SOURCES

• EIP-712: Typed Structured Data Hashing and Signing
• ERC-2612: Permit Extension for ERC-20 Signed Approvals
• OpenZeppelin Contracts: Cryptography