A replay attack is when an attacker captures a valid, signed network message and re-transmits ("replays") it to trick the recipient into executing the same action a second time, without the original sender's consent. The message itself is genuine and cryptographically valid, which is why simple signature checks do not stop it. Defending against replay requires that every signed message also include a value that can only be used once — a nonce, timestamp, or chain-ID.
How a replay attack works, step by step
- Alice signs a message — for example, "transfer 1 BTC to Bob" — and broadcasts it.
- An attacker (Eve) is listening on the network. She captures the signed payload byte-for-byte.
- The legitimate transfer settles. The signature has done its job.
- Some time later — minutes, days, months — Eve re-broadcasts the exact same captured message.
- If the system has no replay protection, the verifier sees a valid signature and processes the transfer again. Bob receives a second BTC. Alice loses one she never intended to spend.
Why replay matters in crypto specifically
Replay risk shows up in three crypto-native places that are easy to overlook:
1. Forks and chain-splits
When a blockchain forks, the same address controls assets on two chains that share transaction history up to the fork block. A transaction signed for chain A is byte-identical to one valid on chain B. Without a chain-ID embedded in the signature, an attacker can replay your chain-A transfer onto chain B and drain you on the second chain. EIP-155 added an explicit chain-ID to Ethereum signatures specifically to close this hole after the ETC/ETH split in 2016.
2. Exchange APIs and signed orders
Most institutional exchange APIs require requests to be HMAC-signed with the API secret. If the exchange does not also require a strictly-monotonic timestamp or nonce in every request, a captured order can be replayed within the time-skew window — sometimes minutes — to repeat a fill. This is why every reputable exchange API specifies a recvWindow, requires a timestamp in milliseconds, and rejects duplicate nonces.
3. Off-chain order flow and RFQ systems
EIP-712 typed-data signatures used by 0x, CoW Protocol, and most institutional RFQ systems include a domain separator (chain-ID, contract address, version) and a per-order salt or expiry. Both elements exist solely to prevent replay across chains, contracts, or time.
How to defend against replay
- Nonce — a number that increments with every signed message. The verifier rejects any message whose nonce is less than or equal to the highest seen for that signer.
- Timestamp + window — every message must be signed with a current timestamp; the verifier rejects messages outside a small acceptance window (often 5 to 30 seconds).
- Chain-ID — embed the chain-ID in the signed payload so a signature for chain A cannot be replayed on chain B.
- One-shot tokens — pre-issue a token that can be spent exactly once. Common in payment authorisation flows.
Replay vs related attacks
| Attack | What the attacker does | What stops it |
|---|---|---|
| Replay | Re-sends a captured valid message | Nonce, timestamp, chain-ID |
| Man-in-the-middle | Modifies the message in transit | End-to-end signing or TLS |
| Forgery | Crafts a new message with a fake signature | Strong signature scheme + key secrecy |
| Front-running | Observes a pending order and inserts their own ahead of it | Private mempools, commit-reveal, batch auctions |
What this means for institutional crypto data consumers
If you are building infrastructure that ingests, signs, or relays exchange order flow, treat replay as a production concern from day one. At Microverse Systems we never re-broadcast a captured exchange message; our consolidated order book is reconstructed from raw L2 deltas, never re-signed payloads, which means the data we deliver cannot itself be replayed against an exchange. For backtesting via our historical replay infrastructure, replay is the entire point — but the messages are private to your simulation, never re-broadcast to a live venue.
This article is part of the Microverse Systems glossary — practical reference for institutional crypto market microstructure.