A replay attack is the reuse of a genuine, correctly signed message in a setting where its author did not intend it to count. In computer security the term covers anything from a captured login token sent again to a server to an intercepted payment instruction resubmitted to a bank. In crypto it usually means taking a transaction broadcast on one blockchain and rebroadcasting it on another chain where the same signature is also valid.
Cross-chain replay became a practical problem with the contested hard forks of 2016 and 2017, when two chains suddenly shared the same addresses, keys and transaction format. The usual defence is automatic replay protection, built into the fork itself, together with nonces, chain identifiers and timestamps that tie each message to one network and one moment.
Replay attack in plain terms
Picture a signed cheque made out to a friend. The bank pays it once and stamps it as cashed. Now imagine your account was copied overnight into a second, identical bank, and the friend walks into that second bank with a photocopy of the same cheque. Your signature is real, the account number matches, and the second bank has no record that the cheque was already used. It pays again.
A replay attack exploits exactly that gap. Nothing is forged. A real instruction is simply presented somewhere else, or presented again, where nothing tells the system that it has already been honoured or was meant only for the first place.
How a replay attack works on a blockchain
A transaction is authorised by a digital signature made with the sender's private key over the transaction data. After a fork, both chains recognise the same keys and wallet addresses, so if the signed data contains nothing that identifies which chain it belongs to, the signature verifies on both. Someone watching one network's mempool can copy the raw transaction and broadcast it on the other, moving the sender's coins there too, often to an address controlled by an exchange or by the original recipient.
Within a single chain, replays are blocked by bookkeeping. On Bitcoin each input spends a specific unspent output that can only be spent once. On Ethereum every externally owned account has a nonce that must increase by one with each transaction, so an old transaction cannot be reused. These rules do nothing across chains, because each chain has its own copy of the same history.
Historical examples
- Ethereum Classic, 2016. After the DAO fork on 20 July 2016, transactions sent on Ethereum could be replayed on the Ethereum Classic (ETC) chain and vice versa. Users and exchanges lost ETC or ETH they did not intend to send, and Ethereum later added chain identifiers to signatures through EIP-155 in the Spurious Dragon upgrade of November 2016.
- Bitcoin Cash, 2017. Bitcoin Cash (BCH) launched in August 2017 with replay protection built in from the start, a direct lesson from the Ethereum experience.
- SegWit2x, 2017. A planned increase of Bitcoin's block size was criticised partly because its initial design lacked strong replay protection; the fork was called off in November 2017.
Prevention
Defences fall into three groups. The first is protocol design: binding each signature to a specific chain, as EIP-155 does with a chain ID, or adding a fork-specific flag to signatures as Bitcoin Cash did. The second is wallet and exchange practice. Before replay protection existed, users "split" their coins by sending them in a transaction that could only be valid on one chain, for example by including outputs that exist on only one side, and exchanges often paused withdrawals around a fork. The third is general security engineering: one-time tokens, timestamps and sequence numbers in APIs, payment messages and smart contracts, so that any signed message expires or is consumed after first use.
Smart contract developers face a related risk when the same signed off-chain message, such as a permit or meta-transaction, is accepted by more than one contract or network. Including the chain ID, the contract address and a nonce in the signed data is the standard fix, and is part of EIP-712 structured-data signing.
Risk for exchanges, custodians and users
For exchanges, custodians and payment firms, a replay is a silent loss of funds that may not show up until reconciliation. Around any fork, a crypto exchange or custodial wallet provider has to confirm whether the new chain has replay protection, decide whether to credit the forked coin, and separate customer balances before moving anything. Individuals holding keys in a non-custodial wallet carry the same risk themselves and should wait for wallet guidance before transacting during a contested split.