A replay attack occurs when an attacker captures a legitimate transaction or message and resubmits it to achieve unauthorized effects. In blockchain systems, this typically means executing the same action multiple times when it should only execute once—such as withdrawing funds repeatedly using a single valid withdrawal authorization.

How Replay Attacks Work

Consider a simple cross-chain bridge where users lock tokens on Chain A to receive tokens on Chain B. The bridge validators sign a message authorizing the mint on Chain B. Without replay protection, an attacker could:

1. Make a legitimate deposit of 100 tokens on Chain A
2. Receive a signed message authorizing 100 tokens on Chain B
3. Submit the signed message and receive 100 tokens
4. Submit the same signed message again and receive another 100 tokens
5. Repeat until the bridge is drained

The signature remains valid because none of the signed data has changed. Without explicit tracking of which messages have been processed, the bridge has no way to distinguish the first submission from subsequent replays.

Types of Replay Attacks in DeFi

Same-Chain Replay: Resubmitting a transaction on the same blockchain. Standard Ethereum transactions are protected by account nonces—each transaction must use a sequential nonce, so a transaction can only be included once.

Cross-Chain Replay: Submitting a transaction valid on one chain to a different chain. This became prominent after the Ethereum/Ethereum Classic split and again after various hard forks. Transactions signed for one chain could be valid on both if chain IDs weren't included in the signature.

Cross-Protocol Replay: Using signed messages from one protocol in another. If two protocols use the same signature format without domain separation, a signature intended for Protocol A might be valid in Protocol B.

Historical Replay: Resubmitting old valid messages that have been superseded. For example, replaying an old authorization message after a user has revoked permissions.

Replay Protection Mechanisms

Nonces: A counter that increments with each transaction. Each nonce value can only be used once, preventing replay of the same transaction:

1mapping(address => uint256) public nonces;
2
3function executeWithNonce(
4    bytes calldata data,
5    uint256 nonce,
6    bytes calldata signature
7) external {
8    require(nonce == nonces[msg.sender], "Invalid nonce");
9    require(verifySignature(data, nonce, signature), "Invalid signature");
10    
11    nonces[msg.sender]++;
12    // execute action
13}

Message Hash Tracking: Store hashes of processed messages and reject duplicates:

1mapping(bytes32 => bool) public processedMessages;
2
3function processMessage(bytes calldata message, bytes calldata proof) external {
4    bytes32 messageHash = keccak256(message);
5    require(!processedMessages[messageHash], "Already processed");
6    
7    require(verifyProof(message, proof), "Invalid proof");
8    
9    processedMessages[messageHash] = true;
10    // execute message
11}

Chain ID Inclusion: Include the target chain's identifier in signed messages. A signature for Ethereum (chain ID 1) won't be valid on Polygon (chain ID 137):

1bytes32 messageHash = keccak256(abi.encodePacked(
2    block.chainid,
3    recipient,
4    amount,
5    nonce
6));

Timestamps and Expiration: Include timestamps in messages and reject expired ones:

1function processMessage(
2    bytes calldata message,
3    uint256 deadline,
4    bytes calldata signature
5) external {
6    require(block.timestamp <= deadline, "Message expired");
7    // verify and process
8}

Domain Separation: Use EIP-712 structured data signing with unique domain separators for each protocol. This prevents cross-protocol replay:

1bytes32 public DOMAIN_SEPARATOR = keccak256(abi.encode(
2    keccak256("EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)"),
3    keccak256("MyBridge"),
4    keccak256("1"),
5    block.chainid,
6    address(this)
7));

Replay Attacks on Cross-Chain Bridges

Bridges are particularly vulnerable to replay attacks because messages must be verified across trust boundaries. Common attack vectors include:

Cross-Chain Message Replay: A valid message for Chain A is replayed on Chain B. If the bridge doesn't include chain identifiers in signed messages, the same signature might authorize mints on multiple chains.

Re-relay Attacks: A message that was already processed is relayed again. Without tracking processed message hashes, the bridge may execute the same action twice.

Fork Replay: After a chain forks, transactions valid on one fork may be replayed on the other. Bridges must handle chain reorganizations and forks carefully.

Prevention Best Practices

For cross-chain bridge developers:

1. Include chain ID in all signed messages - Both source and destination chain identifiers
2. Track processed message hashes - Maintain a mapping of all executed messages
3. Use sequential nonces per sender - Each sender's messages must be processed in order
4. Set message expiration times - Old messages should become invalid
5. Implement domain separation - Use EIP-712 or similar standards
6. Handle chain forks explicitly - Have procedures for reorganization scenarios

For auditors reviewing bridge security:

1. Trace all signature verification paths - Ensure replay protection exists everywhere
2. Check for cross-chain ID inclusion - Messages must be bound to specific chains
3. Verify message uniqueness tracking - Processed messages must be recorded
4. Test with duplicate submissions - Attempt to replay valid messages
5. Review fork handling logic - Understand behavior during reorganizations

Replay attacks represent one of the most fundamental security concerns in blockchain systems. Proper replay protection is non-negotiable for any protocol handling value, and especially critical for cross-chain bridges where the attack surface spans multiple networks.