The most critical security risk in a forked chain is replay attacks.
As Ethereum transitions to a Proof-of-Stake (PoS) consensus system, the original Proof-of-Work (PoW) chain has undergone a hard fork (referred to as ETHW) with community support. However, certain on-chain protocols were not designed with hard forks in mind, leading to vulnerabilities—particularly replay attacks—on the ETHW fork.
Since the fork, ETHW has witnessed at least two replay-based attacks: the OmniBridge replay attack and the Polygon Bridge replay attack. This article examines these incidents to analyze the impact of replay attacks on forked chains and how protocols can safeguard against them.
Types of Replay Attacks
Replay attacks generally fall into two categories: transaction replay and signed message replay.
Transaction Replay
This involves copying a transaction from the original chain and executing it on the target chain. A notorious example is the Wintermute attack on Optimism, which resulted in a loss of over 20 million OP tokens. However, after EIP-155, transactions include a chainId in their signatures, preventing replay if the target chain's chainId differs.
Signed Message Replay
Unlike transaction replay, this targets messages signed with private keys (e.g., "Cobo is the best"). Since such messages lack chain-specific identifiers, their signatures remain valid across all forks. To prevent replay, messages should include a chainId (e.g., "Cobo is the best + chainId()").
Attack Mechanisms: OmniBridge and Polygon Bridge
OmniBridge Attack
OmniBridge facilitates asset transfers between xDAI and Ethereum. Validators submit cross-chain messages to authorize transfers. The vulnerability arises because:
- The validation logic checks signatures but doesn’t use the native
chainIdopcode. - Validators’ signatures from Ethereum Mainnet remain valid on ETHW, enabling attackers to replay signatures and drain assets.
Polygon Bridge Attack
Polygon Bridge relies on block proofs for withdrawals. The exploit steps were:
- Deposit funds via
depositForon Polygon. - Withdraw on Ethereum Mainnet using
exit. - Copy the
headerRootand validator signatures. - Replay the signatures on ETHW to withdraw again.
👉 Learn how to secure your assets during forks
Why Does This Happen?
Protocols like OmniBridge and Polygon Bridge were designed for single-chain use, lacking replay protection. However, users interacting with these protocols on ETHW risk having their signatures replayed on Ethereum Mainnet, leading to asset loss.
Example: UniswapV2’s permit function uses a fixed DOMAIN_SEPARATOR with a pre-set chainId. Post-fork, signatures from ETHW could be replayed on Mainnet.
Preventive Measures for Developers
- Incorporate
chainIdinto signed messages for multi-chain compatibility. - Dynamically fetch
chainIdduring verification instead of storing it as a contract variable.
Implications
For Users
Avoid interacting with unsupported forks to prevent signature replay on Mainnet.
For Exchanges/Custodians
While ETHW tokens may be traded, replay attacks don’t inflate supply. No additional safeguards are needed beyond standard security practices.
Conclusion
As multi-chain ecosystems expand, replay attacks pose growing risks. Developers must integrate chain-specific identifiers into signatures and adhere to security best practices to protect user assets.
FAQ
What is a replay attack?
A replay attack involves reusing valid transactions or signatures from one blockchain on another fork, potentially draining assets.
How can users avoid replay attacks?
Avoid engaging with unsupported fork chains and revoke unnecessary approvals.
Are exchanges at risk from replay attacks?
No. Replay attacks don’t create new tokens, so exchanges aren’t directly affected.
Why don’t all protocols include replay protection?
Many protocols are designed for single-chain use, making replay protection irrelevant unless multi-chain deployment is planned.
Can replay attacks occur on other blockchains?
Yes, any blockchain undergoing a fork without proper replay protection is vulnerable.