A signature replay attack is a security exploit where an attacker intercepts a valid, signed message or transaction and maliciously resubmits it to the system to execute an unintended action. This attack is possible when the signature verification process fails to ensure the signed data is unique and non-reproducible. In blockchain contexts, this often means an attacker can reuse a signed transaction to drain funds or alter state multiple times, as the network sees the replayed signature as proof of the original signer's consent.
LABS
Glossary
Signature Replay Attack
A signature replay attack is an exploit where a valid cryptographic signature is intercepted and reused maliciously in a different context or on a different network to authorize unauthorized transactions.
Chainscore © 2026
definition
SECURITY VULNERABILITY
What is a Signature Replay Attack?
A signature replay attack is a critical security flaw where a valid cryptographic signature is intercepted and fraudulently reused in a different context or transaction.
The core defense against replay attacks is the inclusion of a nonce—a number used once—or other unique identifiers within the signed data. For example, Ethereum transactions include a nonce that increments with each transaction from an account, making every signature unique. Cross-chain or cross-contract replay attacks are more sophisticated, where a signature valid on one blockchain or smart contract is replayed on a forked chain or a different contract with identical logic. Protocols must implement domain separation, using a unique chain ID or contract address within the signed message to bind the signature to a specific context.
To mitigate these attacks, developers must design signature schemes that are context-aware. Best practices include: using EIP-712 for typed structured data hashing, which explicitly includes the chain ID and verifying contract address; implementing non-sequential nonces for off-chain signatures (like in gasless meta-transactions); and ensuring signed messages include an expiration timestamp. Auditing smart contracts for replay vulnerabilities is essential, as a lack of these safeguards can lead to significant financial loss, as historically seen in early token sale contracts and bridge implementations.
key-features
SIGNATURE REPLAY ATTACK
Key Characteristics
A signature replay attack is a security exploit where a valid cryptographic signature is intercepted and fraudulently reused in a different transaction or context to gain unauthorized access or funds. This section details its core mechanisms and defenses.
01
Core Mechanism
The attack exploits the non-uniqueness of a signed message. An attacker captures a legitimate signature from a broadcast transaction and re-submits it, often on a different network (cross-chain replay) or after a blockchain fork. The signature remains cryptographically valid, tricking the system into authorizing a duplicate or malicious action the original signer never intended.
02
Common Vulnerability: Missing Nonce
A primary cause is the absence of a nonce (number used once) or unique transaction identifier within the signed data. Without it, two different transactions can produce identical signed messages. Smart contracts must include a nonce or a deadline in the signed payload to ensure each signature is bound to a single, specific execution context.
03
Cross-Chain Replay
A major risk when a blockchain undergoes a hard fork. If the forked chains share the same address and transaction format, a signature valid on the original chain is also valid on the new one. An attacker can broadcast the same signed transaction on both chains, potentially doubling the transfer of assets. This was a significant concern during the Ethereum/ETC fork.
05
Chain ID Protection
Including the chain ID (a unique network identifier) in the signed message is a fundamental defense. This prevents a signature created for Ethereum Mainnet (chain ID 1) from being replayed on a testnet (e.g., Sepolia, chain ID 11155111) or a forked chain with a different ID. Most modern wallets and protocols enforce this.
06
Contract-Level Mitigations
Smart contracts implement specific checks to prevent replays:
- Nonce Incrementing: Storing and validating a per-user nonce that increments with each use.
- Signature Expiry: Using timestamps or block numbers to set a deadline for signature validity.
- Unique Hash: Generating a one-time use hash for critical operations like permit functions (ERC-2612).
how-it-works
SECURITY VULNERABILITY
How a Signature Replay Attack Works
A signature replay attack is a critical security flaw where a valid cryptographic signature is intercepted and fraudulently reused to authorize a new, unauthorized transaction.
A signature replay attack occurs when an attacker intercepts a legitimate digital signature from a signed message or transaction and maliciously re-submits it to the network. Because the cryptographic signature itself remains cryptographically valid—it correctly verifies against the signer's public key and the original data—the network may accept the replayed transaction as authentic. This attack exploits the fact that some systems fail to implement mechanisms to detect and reject duplicate uses of the same signature, allowing the attacker to repeat an action, such as a fund transfer, without the original signer's consent.
The core vulnerability lies in the system's failure to maintain state or context about previously seen signatures. To prevent replays, systems must implement safeguards. Common defenses include using a nonce (a number used once), a strictly increasing transaction counter, or incorporating a chain identifier and the current block height into the signed message hash. The widely adopted EIP-155 standard for Ethereum introduced a chain ID to prevent signatures from one network (e.g., a testnet) from being replayed on another (e.g., mainnet). Without these measures, a signature is dangerously context-free.
In practice, replay attacks can manifest in several scenarios. A cross-chain replay might involve signing a message for a fork of a blockchain and having it accepted on the original chain. A more subtle within-chain replay can happen if a user signs two identical transaction parameters (e.g., sending the same amount to the same recipient) and an attacker broadcasts the first signature twice before the second is processed. Smart contracts are particularly vulnerable if they do not track processed signatures in a mapping, allowing a single authorization for a withdrawal to be executed multiple times.
Mitigating replay attacks is a fundamental responsibility for blockchain developers. For standard transactions, relying on the network's native transaction nonce is essential. For off-chain signatures used in systems like meta-transactions or EIP-712 typed structured data, the signing schema must include unique, protocol-defined fields. A best practice is to include the signer's address, a domain separator for the application, a specific version string, and a nonce that the contract increments after each successful use, rendering every signature uniquely bound to a single operation.
attack-contexts
SIGNATURE REPLAY ATTACK
Common Attack Contexts & Vectors
A signature replay attack occurs when a valid digital signature is maliciously reused to execute an unauthorized transaction or action, exploiting insufficient context binding in the signature's message.
01
Core Vulnerability
The attack exploits a lack of uniqueness or context in the signed message. If a signature does not include a nonce, a chain identifier, or a specific deadline, it can be valid on multiple networks or for multiple transactions. The classic vulnerability is in functions like permit for ERC-20 approvals or in multi-step contract interactions where the same signed data can be submitted twice.
02
Cross-Chain Replay
A signature created for a transaction on one blockchain (e.g., Ethereum Mainnet) can be replayed on a forked or compatible chain (e.g., Binance Smart Chain) if the signature's message does not include a chain ID. This was a significant risk during network forks. The EIP-155 standard, which includes the chain ID in transaction signing, was introduced to mitigate this specific vector for native transactions.
03
Contract-Level Replay
Even with EIP-155, replay attacks can occur at the smart contract application layer. Common scenarios include:
- ERC-2612
permit: Reusing a signature for the same tokenamountanddeadline. - Meta-Transactions: Replaying a signed meta-transaction request.
- Voting/Signing: Reusing a signature in a governance context.
Mitigations involve incorporating nonces (e.g.,
permituses the owner's nonce) and deadlines that make the signature invalid after a certain time.
04
Prevention & Mitigation
Developers prevent replay attacks by ensuring signed data is unique and context-bound. Standard practices include:
- Incorporate a Nonce: A monotonically increasing number tied to the signer's account.
- Include Chain ID: Use
block.chainidin the signed message hash. - Use Deadlines: Make signatures expire with a timestamp.
- Use EIP-712: A standard for typed structured data hashing and signing that explicitly defines the domain (including chain ID) and message, reducing ambiguity.
05
Real-World Example: The DAO Fork
The 2016 Ethereum hard fork that created Ethereum Classic (ETC) created a prime environment for cross-chain replay attacks. Transactions signed on the new Ethereum (ETH) chain were valid on the unforked ETC chain because the original signature scheme lacked a chain identifier. This led to users inadvertently repeating transactions (like token transfers) on both chains. This event directly motivated the implementation of EIP-155.
06
Related Concepts
- EIP-712: Standard for typed structured data signing.
- EIP-2612: ERC-20 extension with
permitfunction using signatures. - Nonce: A number used once to ensure uniqueness.
- Meta-Transaction: A transaction where the fee is paid by a relayer, not the signer.
- Signature Malleability: A different but related vulnerability involving modifying a valid signature to create another valid one.
prevention-mechanisms
PREVENTION MECHANISMS & STANDARDS
Signature Replay Attack
A signature replay attack is a security vulnerability where a valid cryptographic signature is maliciously reused to execute an unauthorized transaction or action on a blockchain or smart contract.
In a signature replay attack, an attacker intercepts a legitimate, signed transaction message—such as a token transfer or contract call—and resubmits it to the network. Because the digital signature remains cryptographically valid, the network or contract incorrectly accepts the duplicate transaction as a new, authorized instruction from the original signer. This can lead to the unintended repetition of actions, such as draining funds from an account or triggering state changes multiple times. The core vulnerability stems from the system's inability to distinguish between the first legitimate use of a signature and its subsequent malicious reuse.
Preventing these attacks requires mechanisms to ensure signature uniqueness. The most common defense is incorporating a nonce—a number used once—into the signed message. Each transaction includes an incrementing nonce, making every signature unique to that specific transaction instance. Another standard technique is using a chain identifier (like EIP-155 for Ethereum), which binds the signature to a specific blockchain network, preventing a signature valid on a testnet from being replayed on the mainnet. Smart contracts can also implement checks for processed transaction hashes or use deadlines via timestamps to invalidate stale signatures.
Developers must be vigilant, as replay vectors can exist across multiple dimensions. A cross-chain replay occurs when a signature is valid on two forked chains sharing an address space. An in-contract replay can happen within a single contract if its logic does not track executed actions. Standards like EIP-712 for typed structured data hashing improve clarity for users and reduce ambiguity in what is being signed. Implementing comprehensive safeguards—combining nonces, chain IDs, and explicit state tracking—is a fundamental requirement for secure smart contract and protocol design to ensure the idempotence and intended single-use nature of authorized operations.
real-world-examples
SIGNATURE REPLAY ATTACK
Real-World Examples & Incidents
Historical incidents demonstrate the critical importance of proper signature nonce and domain separation in smart contract security.
01
The ERC-20 Permit() Exploit
A classic replay vector occurs when a signed permit message for token approval is replayed across different chains or forks. The attack exploits the lack of a chain ID in the original EIP-2612 structured data. A signature valid on Ethereum Mainnet could be replayed on a fork (e.g., during the 2016 DAO fork) or a sidechain, allowing an attacker to drain allowances.
- Mechanism: The signed message contains
owner,spender,value,deadline, but not a unique chain identifier. - Mitigation: EIP-712 and later implementations mandate including the
chainIdand verifying contract address in the signed domain separator.
02
Cross-Chain Bridge Vulnerability
Bridges that use off-chain signatures for minting assets are prime targets. An attacker can intercept a valid signature authorizing a mint on Chain A and replay it on Chain B before it expires.
- Example: A user's signature to mint wrapped assets on Avalanche could be re-submitted to the bridge contract on Polygon.
- Root Cause: The signed message often lacked a destination chain identifier or a single-use nonce scoped across all connected chains.
- Solution: Implement a global, nonce-incrementing mechanism per user address across all bridge endpoints.
03
The CREATE2 Factory Replay
Smart contract factories using CREATE2 can be vulnerable if they accept signatures to deploy contracts with specific initialization code. An attacker can replay a successful deployment signature after the original contract has been selfdestructed, as CREATE2 generates the same address.
- Attack Flow: 1) User signs to deploy a contract. 2) Contract is deployed and later selfdestructs. 3) Attacker re-submits the same signature to redeploy a malicious contract at the same address, potentially hijacking expected interactions.
- Prevention: Include a salt in the signed message that is unique to the deployment transaction (e.g., a nonce).
04
Multi-Signature Wallet Replay
Older multi-sig wallet implementations sometimes allowed signature reuse for separate transactions if the nonce wasn't properly managed. A signature authorizing Transaction A for amount X could be replayed to authorize Transaction B.
- Vulnerability: Storing signatures off-chain and submitting them later without binding them to a specific transaction hash and nonce.
- Modern Standard: Signatures must be over the precise EIP-712 typed data, which includes the wallet nonce, destination, value, and data, making each signature unique to a single transaction.
05
Preventing Replay: Nonce Patterns
The primary defense is a robust, incrementing nonce. Different implementation patterns include:
- Sequential Nonce: A simple counter per user address (e.g., Ethereum's transaction nonce).
- Bitwise Nonce (Parallel): A bitmap where each bit represents a nonce position, allowing multiple pending signed messages without ordering constraints.
- Deadline/Timestamp: Including a
deadlinefield in the signed message, making the signature invalid after a certain block timestamp. - Chain ID & Domain Separator: Mandatory in EIP-712 to isolate signatures to a specific chain and contract.
06
EIP-712: The Standard Defense
EIP-712 (Typed Structured Data Hashing) is the canonical standard for preventing signature replay. It defines a domain separator that cryptographically binds a signature to a specific context.
Key components of the domain separator:
name: The user-readable name of the signing contract.version: The version of the signing protocol.chainId: The EIP-155 chain ID (e.g., 1 for Ethereum Mainnet).verifyingContract: The address of the contract that will verify the signature.salt: A disambiguating salt (bytes32).
By hashing this data into the signature, a message signed for one contract on one chain cannot be replayed elsewhere.
IMPLEMENTATION GUIDE
Replay Protection Methods: A Comparison
A comparison of common on-chain and off-chain techniques to prevent signature replay attacks in smart contracts.
| Mechanism | Nonce (Sequential) | Nonce (Bitmap) | Chain ID / Domain Separator |
|---|---|---|---|
Core Principle | Incrementing counter per signer | Used nonce bits flipped in a bitmap | Unique identifier for a specific chain/contract domain |
State Management | Stores single integer per account | Stores uint256 bitmap per account | Encoded in signature payload, no on-chain state |
Gas Overhead (per tx) | ~5k gas (SSTORE new nonce) | ~5k-20k gas (bitmap update) | < 1k gas (signature verification only) |
Replay Scope Prevention | Single chain | Single chain | Cross-chain and cross-contract |
Parallel Transaction Support | |||
Common Standard | EIP-161 (Account Nonce) | EIP-2612 (permit), EIP-4494 | EIP-712 (Structured Data) |
Primary Use Case | Native transaction sequencing (e.g., ETH transfers) | Gasless token approvals (ERC-20 permit) | Secure off-chain signatures for DEX orders, vouchers |
security-considerations
SIGNATURE REPLAY ATTACK
Security Considerations for Developers
A signature replay attack occurs when a valid digital signature from one transaction is maliciously reused to authorize a second, unauthorized transaction. This glossary section details the attack vectors, prevention mechanisms, and real-world examples critical for secure smart contract development.
01
Core Mechanism
A signature replay attack exploits the reuse of a valid cryptographic signature. The attack vector is:
- A user signs a message (e.g., a transaction approval) for a specific context.
- An attacker intercepts this signed message.
- The attacker re-submits the same signature in a different context (e.g., a second transaction, or on a forked chain).
- The verifying contract, lacking proper replay protection, accepts the signature as valid for the new, unauthorized action.
02
Cross-Chain Replay
This occurs when a signature valid on one blockchain is replayed on another, often after a network fork (e.g., Ethereum/ETH and Ethereum Classic/ETC).
- Prevention: Include the chain ID (EIP-155) in the signed message. This binds the signature to a specific network, making it invalid on any other chain. Modern wallets and libraries like ethers.js and web3.js implement this by default for EIP-1559-type transactions.
03
Contract-to-Contract Replay
The most common form, where a signature is replayed within the same contract or across multiple instances of the same contract.
- Prevention Mechanisms:
- Nonces: Maintain a per-user incrementing counter (
nonce) that is included in the signed hash. The contract must check and record the used nonce. - Deadlines: Include a timestamp (
deadlineorexpiry) in the signed data, after which the signature is invalid. - Context-Specific Data: Hash unique contract state (like the contract's own address) into the signed message.
- Nonces: Maintain a per-user incrementing counter (
05
Real-World Example & Impact
The Parity Multisig Wallet Hack (2017) involved a replay attack variant. A flaw in the library contract's initWallet function allowed an attacker to become the owner of any newly deployed wallet that used it.
- Root Cause: The
initWalletfunction lacked proper state validation, allowing its initialization call to be replayed on already-initialized wallets. - Impact: Over $30 million USD in Ether was frozen (not directly stolen) due to the library being killed, rendering dependent wallets inoperable. This highlights how replay vulnerabilities can have catastrophic, systemic consequences.
06
Developer Checklist
To prevent signature replay attacks, implement these checks in your signature-verifying functions:
- âś… Include a Nonce: Use
address => uint256mapping to track and increment a user-specific nonce. - âś… Bind to Chain: Integrate
block.chainidinto your signed message hash (EIP-155 for txs, custom for off-chain sigs). - âś… Bind to Contract: Include
address(this)in the signed data. - âś… Set a Deadline: Use a
uint256 validUntiltimestamp. - âś… Use EIP-712: For off-chain signatures, adopt the EIP-712 standard for maximum security and UX clarity.
- ❌ Never verify a signature without these context-binding parameters.
SIGNATURE REPLAY ATTACK
Frequently Asked Questions (FAQ)
A signature replay attack is a critical smart contract vulnerability where a valid, previously used digital signature is maliciously reused to execute an unauthorized transaction. This FAQ addresses its mechanics, prevention, and real-world examples.
A signature replay attack is a security exploit where an attacker intercepts and re-submits a valid digital signature from a prior, legitimate transaction to execute a new, unauthorized action on a blockchain. This attack bypasses authentication because the cryptographic signature, while authentic, is not bound to a single, unique transaction context. The core vulnerability lies in the signature's malleability when the signed data does not include sufficient unique identifiers to prevent reuse across different contexts or chains.
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall