What is a Replay Attack?
A replay attack in blockchains occurs when a transaction that was legitimately signed for one network is captured and re-submitted on a different network — where it executes a second time. Because the cryptographic signature is mathematically valid on both chains, the second network accepts it as genuine and moves the funds a second time, usually to the attacker’s benefit or simply as destructive duplication.
Replay attacks are primarily a hazard around hard forks and clones. When a blockchain splits into two chains that share the same transaction history and signing rules (for example, Ethereum / Ethereum Classic after the 2016 DAO fork, or Bitcoin / Bitcoin Cash in 2017), a transaction valid on one is often valid on the other. An attacker (or an unlucky user) can take a payment made on Chain A and replay it on Chain B, draining the corresponding balance there.
How Replay Attacks Work / Technical Details
A signed transaction is a bundle of instructions plus a cryptographic signature. The signature proves “the owner of private key X authorized this exact set of instructions.” If two chains share the same address format, the same private keys, and the same signing algorithm, that signature is valid on both — there is nothing inherently tying it to one chain unless the chain ID is bound into the signed data.
The Classic Fork Replay Scenario
- A chain splits into Chain A and Chain B, each copying the full pre-fork state (so every address has the same balance on both)
- You send 5 ETH on Chain A from your address to a merchant
- An attacker watching Chain A copies that raw, signed transaction
- The attacker submits it to a node on Chain B
- Chain B verifies the signature (valid!), checks you have ≥5 ETH (you do — same balances), and executes it
- Now 5 of your “Chain B ETH” are also sent — typically to the same merchant, or, if the attacker tweaked nothing, duplicated harmlessly — but the attacker can craft situations that benefit them
Replay Without a Fork: Smart Contract Replay
A subtler variant targets smart contracts. If a contract off-chain verifies an EIP-712 typed signature (used for gasless “permit” approvals, meta-transactions, and signature-based claiming) but forgets to bind the signature to the chain ID, that signature can be replayed across every chain where the same contract is deployed. An airdrop-claim signature valid on Ethereum mainnet can be replayed on a cheap testnet or an L2 clone to mint duplicate claims — a recurring source of smart-contract bugs.
Notable Examples and Attack Vectors
Ethereum / Ethereum Classic (2016)
After the DAO hack, Ethereum hard-forked to reverse the exploit. The non-fork chain continued as Ethereum Classic (ETC). Because both chains shared history, a transaction on one replayed on the other. This is why exchanges froze ETH/ETC withdrawals for weeks and why users had to “split” their coins using special replay-protected transactions before moving them.
Bitcoin / Bitcoin Cash (2017)
The Bitcoin Cash fork initially had no replay protection. Early users moving BTC risked accidentally moving the corresponding BCH, and vice versa, until wallets implemented split tools and BCH later added strong replay protection via a different sighash.
Cross-Chain Bridge Bugs
Several bridge and bridge-clone incidents stemmed from replayable messages: a proof valid on one chain was accepted on another because the verifier did not include a chain-specific domain separator. Every protocol that verifies off-chain signatures or cross-chain messages must bind them to their destination chain.
How Replay Attacks Are Prevented
EIP-155: Chain ID in the Signature
Ethereum’s EIP-155 (2016) added the chain ID into the data that gets signed. A transaction signed for Ethereum (chain ID 1) will be rejected by any other EVM chain (Polygon 137, Arbitrum 42161, etc.) because the chain ID in the signature won’t match. This is why modern EVM replay attacks almost always involve buggy smart contracts rather than raw transactions.
Replay Protection at Fork Time
Forks that want a clean separation add explicit replay protection:
- Strong replay protection — a different transaction format or sighash so a tx on Chain A is structurally invalid on Chain B (used by Bitcoin Cash’s later forks, Bitcoin Gold, etc.)
- Opt-in replay protection — a special “split” transaction users run once to separate balances, used in the original ETH/ETC split
Smart Contract Defenses
For signature-based logic, always:
- Include the chain ID in the signed message (EIP-712
EIP712DomainincludeschainId) - Include a contract address and nonce so a signature is bound to one deployment and usable only once
- Use an expiry timestamp so stale signatures cannot be replayed later
How to Protect Yourself
- After a fork, don’t move coins until you understand replay risk. Use a wallet with explicit splitting functionality, or move funds to a fresh address on one chain first.
- If you build smart contracts, never accept an off-chain signature without binding it to
block.chainid, the verifying contract address, and a single-use nonce. - For cross-chain messages, require a domain separator that uniquely identifies the source chain, destination chain, and bridge instance.
Frequently Asked Questions
Q: Can someone replay my everyday Ethereum transaction on Polygon? A: No. Thanks to EIP-155, every Ethereum transaction is signed with chain ID 1, and Polygon rejects it because its chain ID is 137. Cross-chain replay of raw transactions is not a practical risk on EVM chains today.
Q: Then why do replay attacks still happen? A: Almost always due to buggy smart contracts that verify off-chain signatures (permits, claims, meta-transactions) without including the chain ID — leaving the signature valid on every chain where the contract is deployed.
Q: Did SegWit or replay protection fix Bitcoin forks? A: Different mechanisms. Replay protection is implemented per-fork (often via a custom sighash flag). SegWit solved transaction malleability, a separate issue — see transaction malleability.