Safe Wallet Signature Replay Attacks Across Chains: Why EVM Wallet Deployments Need Chain-Specific Guards

A development team deploys a Safe Wallet on Ethereum mainnet to manage protocol treasury assets. The same wallet address is then deployed on Polygon, Arbitrum, and Optimism. For convenience, the team uses identical signer configurations and approval thresholds across all chains. Then a transaction is signed on Ethereum with a specific nonce and gas price. An attacker observes the signed transaction data, extracts the signature, and submits it to the same wallet address on a different chain—where the transaction executes because the chain-specific context information is missing from the signature.

This is a replay attack, and it is far more than a hypothetical risk in multichain deployments. Safe Wallet’s smart contract architecture, while robust on a single network, becomes vulnerable when identical wallet addresses exist across multiple EVM-compatible chains without proper chain-differentiation mechanisms. The core issue is that a multisignature transaction approved on one chain can be replayed on another if the approval process does not anchor the signature to specific chain data. For teams managing DAOs, protocols, or treasuries across multiple networks, understanding and preventing signature replay is no longer optional—it is essential infrastructure.

How replay attacks exploit identical wallet addresses across chains

Safe Wallet uses deterministic contract deployment, meaning that the same wallet address is generated on multiple chains if the same creation parameters are used. This is convenient for treasury teams managing assets across Ethereum, Layer 2 solutions, and other EVM networks: the wallet address remains consistent, reducing address management complexity and simplifying governance processes. However, this consistency creates a critical vulnerability when combined with multisignature transaction approval.

A multisignature transaction consists of transaction data (recipient, amount, function call), a nonce, and signatures from the required signers. When a signer approves a transaction on Ethereum using a Web3 wallet, they sign a hash that includes the transaction details and the current nonce. The signature is cryptographically tied to that data. On a single network, this is secure: a signature for nonce 5 on Ethereum cannot be used for nonce 6. But across chains, the signature becomes portable. If no chain-specific information is included in the signed hash, the same signature can be reused on another network where the same wallet exists.

The attack sequence is straightforward. An attacker observes a confirmed multisignature transaction on Ethereum—for example, a treasury transfer sending 100 tokens to an address. They extract the signatures and transaction data from the blockchain. They then submit the same signatures and data to the Safe Wallet contract at the identical address on Polygon or Arbitrum. If the receiving chain’s version of the wallet has not incremented its nonce past the one used on Ethereum, and if the contract logic does not verify chain ID, the transaction executes on the second chain. The attacker has now replayed the same transaction on another network without generating new signatures or compromising any private keys.

This attack is especially dangerous in treasuries because it can move funds silently. If a protocol’s Polygon Safe Wallet holds USDC and the transaction duplicates a treasury transfer that was legitimately approved on Ethereum, the replayed version withdraws funds from the unrelated Polygon balance. No governance vote was taken on Polygon; no new signatures were collected. The transaction simply replayed because the Safe Wallet logic did not differentiate between networks.

The role of chain ID in signature verification

EVM specification includes a concept called chain ID, a unique identifier for each blockchain. Ethereum mainnet is chain ID 1, Polygon is 137, Arbitrum One is 42161, and Optimism is 10. The EIP-155 standard specifies that transaction signatures should include chain ID to prevent replay attacks between networks. However, a Safe Wallet’s multisignature scheme is not a standard EVM transaction—it is a smart contract function call. The wallet contract must explicitly validate the chain ID in its signing process.

Modern Safe Wallet implementations include domainSeparator logic, which encodes the chain ID into the signed data. This is a cryptographic domain separator, similar to EIP-712. When a signer signs a Safe transaction, the signature hash includes a reference to the specific chain ID. If an attacker attempts to replay that signature on a different chain, the chain ID in the signed hash no longer matches the current chain’s ID, and the signature fails verification. The wallet contract rejects the transaction.

However, this protection is only effective if the Safe Wallet instance has been deployed with current Safe Wallet software versions that implement domain separation. Older wallet instances, custom implementations, or wallets deployed using simplified signing mechanisms may not include chain ID verification. Additionally, if a team manually configures multisignature approval without using the standard Safe Wallet interface, they might bypass these protections entirely. On the official site, users and developers can verify the security standards applied to their deployment.

The practical implication is that not all Safe Wallet instances are equally protected. A wallet deployed on Ethereum using Safe Wallet’s latest interface has chain ID domain separation built in. But a wallet deployed years ago using older contract code, or one deployed on Polygon using a different team’s custom implementation, may lack this protection. Auditing existing wallet deployments to confirm chain ID inclusion is therefore a critical security maintenance task.

Nonce management and the window of vulnerability

Every multisignature wallet maintains a nonce counter to prevent the same transaction from being executed twice on the same chain. After a transaction is executed, the nonce increments. The next transaction must reference the new nonce or it will be rejected. This mechanism is sound for single-chain operations: a signature approved at nonce 5 cannot be replayed because nonce 5 has already been used.

Across chains, however, nonce state diverges. The Ethereum Safe Wallet might be at nonce 100 after ten treasury transfers. The identical wallet on Arbitrum might still be at nonce 5 if few transactions have occurred there. If an attacker observes a transaction signed at nonce 5 on Ethereum and the Arbitrum wallet is also at nonce 5, that same signature can be replayed on Arbitrum because the nonce matches what the Arbitrum contract expects. The replay is undetected because nonce 5 is legitimate on that chain—it is just not the same transaction.

This vulnerability is time-sensitive but real. The window of vulnerability exists between the moment a transaction is signed on one chain and the moment the nonce on another chain advances past that number. If the Ethereum Safe Wallet is very active and nonces advance quickly, a signature becomes stale rapidly. But if a Safe Wallet exists on a lower-activity Layer 2, nonces may remain low for weeks or months, creating an extended window where older Ethereum signatures can be replayed.

The solution is chain-specific nonce management combined with domain separation. Each chain’s Safe Wallet instance should maintain an independent nonce that cannot be confused with nonces on other chains. Additionally, the nonce should be included in the domain separator or signed hash so that even if nonce values happen to match across chains, the signatures from one chain cannot validate on another. Wallets without these controls should be considered at risk and either upgraded or abstained from cross-chain deployment.

Safe Wallet’s built-in protections and their limitations

Recent versions of Safe Wallet include explicit chain ID verification in their EIP-712 domain separator. This is the primary Layer 2 wallet security mechanism that prevents cross-chain replay. When the Safe contract validates a signature, it reads the current chain ID from the EVM runtime, encodes it into the domain separator, and verifies that the signed hash matches. If the signature was generated on chain ID 1 but is being validated on chain ID 137, the domain separator mismatch causes the signature to fail verification.

However, Safe Wallet’s protection depends on consistent deployment practices. If a team deploys a Safe Wallet on Arbitrum using a custom setup that does not include the latest contract code, or if they use an older proxy instance from years past, the chain ID protection may be absent or incomplete. Additionally, Safe Wallet’s on-chain security model assumes that signers are using legitimate Safe Wallet interfaces or tools that properly encode the chain ID. If a signer uses a direct contract call or a third-party tool that does not implement proper domain separation, the signature might not include chain context.

Another limitation emerges when Safe Wallets are deployed on newly forked or bridged networks. If a blockchain forks or if a new Layer 2 is created from Ethereum’s state, the new chain may initially have the same contracts and the same wallet addresses as the original network. If the fork does not change the chain ID properly, or if bridge protocols do not enforce chain ID differentiation, replay vulnerabilities can persist across the fork boundary. Teams managing treasuries should verify that each deployment location has a unique, immutable chain ID and that wallet contract code includes verification of that ID.

The broader limitation is that Safe Wallet’s security is built on smart contract logic and cryptographic verification. These protections are strong, but they require correct deployment, maintenance, and usage. If a team deploys a wallet carelessly or uses an older version without security patches, the protections erode. Additionally, Safe Wallet itself cannot control how signers behave or what tools they use to sign transactions. If a signer’s device is compromised or a signing tool is malicious, it can generate signatures that ignore chain context, and the wallet cannot prevent that attack vector.

Preventing replay: operational and technical practices

The first defense is accurate inventory of Safe Wallet deployments. Teams should document every chain on which their wallet is deployed, the creation date, the contract code version, and the signer configuration. This inventory should be reviewed quarterly or whenever Safe Wallet releases security updates. If any wallet instances are running outdated code, they should be upgraded or replaced. Upgrade processes for smart contract wallets can be complex—Safe Wallet uses proxy patterns and guardians to manage updates—so teams should test upgrade procedures on testnet deployments first.

Second, verify chain ID integration in each deployment. A team can call the wallet contract directly to inspect its state and confirm that chain ID is incorporated into domain separators. They can also test by attempting to submit a signature from one chain to another; the transaction should fail if chain ID protection is active. Testnet environments like Sepolia for Ethereum and Mumbai for Polygon are ideal places to validate this behavior before operating mainnet wallets.

Third, use Safe Wallet’s official interfaces and SDKs when possible. The official Safe Wallet platform, Safe{Core} SDK, and Safe Transaction Service handle chain ID encoding automatically. Teams that build custom signing logic or use third-party tools should audit those tools to confirm they include proper domain separation. Any custom transaction construction should explicitly encode the current chain ID and include it in the signed hash.

Fourth, implement monitoring and alerting on multisignature transactions. If a Safe Wallet on Arbitrum suddenly processes a high-value transaction that no signer approved through official governance channels, alerting mechanisms should detect the anomaly. Monitoring can compare pending transactions against governance records or flag transactions with unusual characteristics. This does not prevent replay attacks, but it enables rapid response if one occurs.

Fifth, practice nonce discipline. Do not assume nonce values across chains are synchronized. When a transaction is signed for one chain, document the nonce value. After the transaction executes, verify that the nonce has incremented on that specific chain before signing new transactions. If a Safe Wallet is inactive on a particular Layer 2, do not assume that old signatures are safe to replay elsewhere; they are not.

The governance and upgrade challenge for active DAOs

DAOs managing treasuries across multiple chains face an additional complexity: governance consensus. If a DAO’s Safe Wallet exists on Ethereum, Polygon, and Arbitrum, and a security update is needed to address replay vulnerability, the DAO must vote to approve wallet upgrades on all three chains. If governance processes are slow or if different chains have different quorum requirements, the update process can take weeks. During that window, the unpatched wallets remain at risk.

Some DAOs use a guardian address or a security council to expedite security updates without requiring a full governance vote. The guardian can trigger a wallet upgrade or pause transactions if a critical vulnerability is detected. This centralizes some authority but enables rapid response to threats. The tradeoff is acceptable for most DAOs because the guardian is temporary—once the vulnerability is patched, governance can revoke guardian permissions. However, this assumes the DAO has established a clear process for guardian activation and revocation.

Another approach is to segregate treasury assets by risk profile. A DAO might keep large, long-term reserves in a highly secure Safe Wallet that is deployed on only one chain and updated infrequently. Operational funds might be held in a separate wallet on multiple chains with more frequent updates and faster governance processes. This compartmentalization reduces the scope of a replay attack; even if the operational wallet is compromised across multiple chains, the core treasury remains protected.

DAOs should also consider the lifecycle of their Safe Wallet deployments. If a wallet was deployed years ago on Ethereum and has not been updated, deploying the same wallet address on new Layer 2 solutions creates unnecessary risk. A better practice is to deploy fresh wallet instances on new chains, each with the latest contract code and security patches. This requires address management—the new wallet has a different address than the original—but the security benefit justifies the complexity for institutional treasuries.

Testing replay scenarios on testnet before mainnet deployment

Before deploying a Safe Wallet on a Layer 2 or additional EVM chain, teams should conduct replay attack simulations on testnet. The process is straightforward but essential. First, deploy identical Safe Wallet instances on two testnet networks—for example, Sepolia (Ethereum testnet) and Mumbai (Polygon testnet). Use the same signer keys and approve threshold across both.

Second, construct a multisignature transaction on Sepolia: transfer test tokens to a specific recipient. Have the required signers approve the transaction. Document the signatures and transaction data. Execute the transaction on Sepolia and confirm it succeeds. Then, using the same signatures and transaction data, attempt to submit the transaction to the Mumbai wallet instance at the same address.

If the wallet is properly protected with chain ID domain separation, the Mumbai transaction should fail with a signature verification error. The wallet contract will reject it because the signed hash does not match the current chain’s domain. If the transaction unexpectedly succeeds on Mumbai, the wallet is vulnerable to replay attacks and should not be used for mainnet deployments across multiple chains without remediation.

This test can be performed using Safe Wallet’s SDK or by directly interacting with the wallet contract via ethers.js or web3.py. The test should be repeated for every chain pair the wallet will be deployed on. A team managing treasuries on Ethereum, Arbitrum, and Optimism should test Ethereum-to-Arbitrum, Ethereum-to-Optimism, and Arbitrum-to-Optimism replay scenarios. If any combination shows vulnerability, the deployment should be reconsidered or the wallet upgraded before proceeding.

Monitoring and incident response for active treasuries

Active treasuries should implement continuous monitoring of Safe Wallet transactions across all deployment chains. This means indexing confirmed transactions, comparing them against approved governance proposals, and flagging anomalies. A transaction that executes without a corresponding governance vote is a strong indicator of a replay or unauthorized execution.

Monitoring infrastructure can use Safe Transaction Service APIs or custom blockchain indexers to watch for transactions. When a transaction is detected, automated systems should cross-reference it with governance records. If there is no matching vote or approval, the system should alert the treasury team immediately. For high-value treasuries, alerts should trigger an immediate pause of affected wallets and a manual review process before further transactions are permitted.

Incident response procedures should be pre-established. If a replay attack is detected, the team should immediately freeze the affected wallet (if a pause mechanism exists), analyze the attack scope to determine which chains and assets were compromised, and assess whether funds were lost or diverted. They should then update wallet contract code if vulnerable, rotate signers if key material may have been exposed, and execute a recovery plan if necessary. This entire process should be documented in advance rather than improvised during an emergency.

Additionally, teams should maintain communication channels with Safe Wallet’s security team and other treasury teams in the ecosystem. If a new replay vulnerability is discovered, ecosystem-wide coordination accelerates patching and reduces the window where unaware teams are vulnerable. Regular security reviews and participation in bug bounty programs can also surface issues before they are exploited in the wild.