EIP-712 Struct Hash Collisions: Replay Attacks Across Chains

By DeFi Intel Research · Reviewed 2026-07-02 · 6 min read · advanced

EIP-712 struct hash collisions arise when the same typed data structure and parameters produce identical hashes on different blockchain networks, creating a vector for cross-chain replay attacks. This deep dive explains the cryptographic underpinnings, the role of domain separators, and how protocols like Uniswap and OpenSea have addressed or failed to address these vulnerabilities.

We will dissect real exploit scenarios, compare domain separator fields across chains, and provide concrete mitigations for developers building cross-chain applications that rely on off-chain signatures.

The Hidden Danger of EIP-712 Struct Hash Collisions

EIP-712 introduced a standard for hashing typed structured data to improve security and user experience for off-chain signature verification. However, when the same struct types and field values are hashed on different chains, the resulting hashes can be identical if the domain separator does not diverge. This EIP-712 struct hash collision allows an attacker to take a signature intended for one blockchain and replay it on another, executing unintended actions.

For example, a user signs a limit order on Ethereum mainnet. If the contract on Polygon uses the same domain separator (e.g., missing chainId), the same signature can authorize the same trade on Polygon. This is not just theoretical — several high-profile exploits have leveraged this gap.

How EIP-712 Domain Separators Were Supposed to Prevent Cross-Chain Replay

The EIP-712 standard includes a domainSeparator (a keccak256 hash of domain fields: name, version, chainId, verifyingContract, salt) to bind a signature to a specific domain. The intent is that different chains have different chainId, and different contracts have distinct verifyingContract addresses. However, many early implementations omitted chainId or verifyingContract, making domains identical across deployments.

• Missing chainId: If a contract is deployed at the same address on Ethereum and on a sidechain (e.g., Polygon), the entire domain can match.
• Missing verifyingContract: Without this field, signatures are valid for any contract using the same name/version/salt.
• Salt misuse: Some protocols use a static salt (e.g., zero bytes), negating its purpose.

The Mechanics of Struct Hash Collisions

The EIP-712 hash computation involves two keccak256 hashes: one over domainSeparator and one over typedData. The final digest is keccak256(0x1901 || domainSeparator || hashStruct(message)). If the domain separator is identical across chains, and the message struct is identical, the final digest collides.

Consider a struct Order(address maker, address taker, uint256 amount, bytes32 salt). A user signs one order. On Ethereum, the domain includes chainId=1. On Polygon, chainId=137. If the contract does not include chainId in its domain separator, both hashes are equal — collision. The signature can be replayed.

Real-World Examples: Where Collisions Strike

Several real incidents highlight the risk:

• OpenSea (Wyvern Protocol) — The early Wyvern exchange domain separator did not include chainId, so in principle an order signed for the contract on Ethereum mainnet could be replayed on any EVM fork where a contract existed at the same address (for example a fork or testnet replica). OpenSea later added chainId and required re-signing.
• Uniswap Permit2 — Early versions of Permit2 had to explicitly add chainId validation to prevent cross-chain replay. Although the domain separator includes chainId by default, integrators sometimes omit it.
• Gnosis Safe — Multi-sig signatures using EIP-712 can be replayed if the same safe address exists on multiple chains and domain fields are incomplete. The Safe team now enforces chainId in its domain.

These cases demonstrate that even major protocols have had to strengthen domain separation to close off replay vectors.

Cross-Chain Replay Attacks: The Attack Vector

A cross-chain replay attack using EIP-712 struct hash collisions works as follows:

1. Victim signs a message on chain A (e.g., Ethereum) with a struct of type Transfer(address to, uint256 amount). The signature is valid for domain on chain A.
2. Attacker intercepts the off-chain signature (e.g., via a public mempool, dApp frontend, or data breach).
3. Attacker submits the same signature to chain B (e.g., Polygon) where the same contract address exists and domain separator matches.
4. Chain B verifies the signature as valid, executing the transfer on the victim's behalf on chain B.

The key enabler is the absence of chain-specific domain fields. The attack does not require any private key compromise — only signature reuse.

Comparison Table: Domain Separator Fields and Collision Risks

Mitigations: Proper Domain Separator Usage

Developers must ensure the domain separator is unique per chain and per deployment. Best practices:

• Always include chainId — Use block.chainid (Solidity) or the chain's EIP-155 identifier. Never hardcode zero.
• Set verifyingContract to address(this) — This prevents the same contract on different chains at the same address from being interchangeable.
• Use a unique salt — Generate a random salt per deployment, or use a hash of the chainId + contract address to guarantee uniqueness across chains.
• Validate domain on verification side — The verifying contract should check that the domain separator matches its own computed domain.

Example correct domain construction in Solidity: EIP712Domain({ name: "MyApp", version: "1", chainId: block.chainid, verifyingContract: address(this) }).

Protocol-Level Safeguards (EIP-5267, EIP-712 with chainId Enforcement)

EIP-5267 proposes a standard for retrieving domain separator information from contracts, making it easier for off-chain signers to verify they are signing for the correct chain. Additionally, wallets and SDKs (like ethers.js and web3.js) now enforce chainId in EIP-712 methods. For example, MetaMask automatically prepends the chainId from the wallet's active network into the signing request, reducing human error.

Protocols should also implement nonce-based replay protection or include a unique identifier (like a deadline or order ID) in every struct. While these don't prevent cross-chain collisions directly, they limit the window for replay.

Testing Your Contracts for Collisions

To detect potential EIP-712 struct hash collisions, developers should:

• Unit test domain separators — Deploy your contract to testnets with different chainIds (e.g., Sepolia, Goerli, Mumbai) and verify the domain separator hash differs.
• Fuzz testing — Use fuzzing to generate many struct variations across simulated chain IDs, ensuring no two produce the same final digest.
• Audit for missing fields — Automated static analysis tools (Slither, MythX) can check that chainId and verifyingContract are present in domain definitions.
• Cross-chain simulation — Deploy the same contract on two local hardhat networks with different chain IDs and attempt to replay a signature.

OpenZeppelin's EIP-712 utilities provide a solid foundation, but always customize the domain constructor.

Future of EIP-712 and Cross-Chain Signatures

The Ethereum ecosystem is moving toward native cross-chain interoperability (e.g., LayerZero, Chainlink CCIP). EIP-712 struct hash collisions will become more critical as dApps expand across many chains. Future standards may introduce mandatory domain fields or a global registry of domain separators.

Until then, the responsibility lies with protocol developers. Vigilance in domain separation is cheap; a single missed field can cost millions. The community should adopt tooling that warns when chainId is omitted, and wallets should enforce domain uniqueness before signing.

Common mistakes to avoid

• Omitting chainId from the domain separator because the contract is only expected on one chain.
• Hardcoding the domain separator hash offline without accounting for future chain forks or reorgs.
• Assuming that different contract addresses on different chains automatically differentiate signatures (missing verifyingContract in domain).
• Using the same salt across all deployments (e.g., zero bytes) instead of generating a unique salt per chain.
• Not validating the recovered signer address matches the expected signer in the context of the specific chain.

Frequently asked questions

Related reading

• How To Verify Cross Chain Bridge Security
• How To Safely Bridge Tokens Cross Chain
• Layerzero Zro Cross Chain Messaging
• Permit2
• Sandwich Attack
• Smart Contract
• How To Audit Smart Contract Yourself
• How To Avoid Address Poisoning Attacks