A signature replay attack occurs when an attacker intercepts or observes a signed message or transaction and successfully submits it, or a manipulated version of it, to the network a second time. This exploits the fact that the cryptographic signature itself remains cryptographically valid, even if the original transaction has already been processed. The core vulnerability lies not in the signature algorithm (like ECDSA) but in the application logic that fails to ensure each signature is unique and single-use. Without proper safeguards, this can lead to unauthorized transfers, duplicate votes in governance, or repeated access to a service.
LABS
Glossary
Signature Replay
A signature replay attack is a blockchain security vulnerability where a valid cryptographic signature is intercepted and fraudulently reused in a different context or transaction.
Chainscore © 2026
definition
SECURITY VULNERABILITY
What is a Signature Replay Attack?
A signature replay attack is a critical security flaw in smart contracts and blockchain protocols where a valid cryptographic signature, once used in a transaction, is maliciously reused to execute the same or a similar action again without the signer's consent.
To prevent replay attacks, systems must implement mechanisms that make signatures non-replayable. The most common defense is incorporating a nonce—a number used once—into the signed message. The contract stores the last used nonce for each account and rejects any signature with a previously seen nonce. Another critical defense is including the chain ID in the signed data, which prevents a signature valid on one blockchain (e.g., Ethereum Mainnet) from being replayed on another (e.g., a testnet or fork). For contract-to-contacket interactions, using address(this) (the contract's own address) in the signed data can confine the signature's validity to a single specific contract instance.
A classic example is a blind signature for a token allowance. If User A signs a message granting 10 tokens to a service, and the contract only checks the signature's validity, an attacker could replay that same signed message to drain an additional 10 tokens after the initial grant. This flaw was famously demonstrated in early implementations of the ERC20Permit standard before the inclusion of nonces. Developers must audit all signature verification logic, ensuring signed data includes immutable, context-specific parameters like nonce, chain ID, deadline, and the precise contract address to create a unique signed digest for every intended action.
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 duplicate or malicious transaction on a blockchain or in a digital system.
A signature replay attack occurs when an attacker intercepts a legitimate, digitally signed message—such as a blockchain transaction authorization—and maliciously resubmits it to the network to execute the same action again. This exploits the fact that the cryptographic signature itself remains cryptographically valid, even if the context of its use is illegitimate. The core vulnerability lies not in breaking the signature algorithm, but in the system's failure to detect that a specific signed authorization has already been consumed. This can lead to double-spending of assets, unauthorized access, or repeated state changes that the original signer did not intend.
To execute a replay, an attacker typically monitors the mempool or network traffic to capture a signed transaction. They then broadcast this identical transaction data again. If the smart contract or protocol logic only verifies that the signature is cryptographically correct for the given message and signer's address, it will process the duplicate. This is analogous to a thief photocopying a signed paper check and cashing it multiple times. The attack is particularly effective in systems where transactions are not uniquely identified or where the same signature can authorize actions across multiple independent chains (a cross-chain replay).
Developers prevent signature replay attacks by implementing mechanisms that make each signature unique and single-use. The most common defense is incorporating a nonce—a number used once—into the signed message data. Ethereum transactions, for example, use a transaction nonce that increments with each sent transaction, making every signature distinct. Other techniques include using chain identifiers (like EIP-155 in Ethereum to prevent cross-chain replays), adding timestamps with expiration windows, or employing commit-reveal schemes. Smart contracts must explicitly check these values in their verification logic to invalidate any previously seen signatures.
A historical example of this vulnerability was exploited during the Ethereum Classic (ETC) and Ethereum (ETH) chain split. Transactions signed for one chain were valid on the other because initial wallet software did not implement chain ID replay protection. This allowed attackers to replay transactions from one chain to the other, stealing funds from users who held the same private key balance on both networks. This incident underscored the necessity of EIP-155, which later mandated including the chain ID in the signed transaction data, binding the signature to a specific network.
key-features
SIGNATURE REPLAY
Key Characteristics of Replay Attacks
A signature replay attack exploits the reuse of a valid cryptographic signature to execute an unauthorized duplicate transaction. These attacks highlight critical vulnerabilities in transaction design and state management.
01
Cross-Chain Replay
Occurs when a signature from a transaction on one blockchain is replayed on a forked or parallel chain where the same state (e.g., account balance) is also valid. This was famously exploited during the Ethereum/ETC fork, where transactions were replayed across both chains. Mitigation involves using a unique chain identifier in the signed data.
02
Cross-Contract Replay
Happens when a signature authorizing an action for one smart contract is reused to perform the same action on a different, often similar, contract. This targets systems where multiple contracts share signature verification logic. Prevention requires including the contract's address (msg.sender) or a unique nonce in the signed message hash.
03
The Nonce Defense
A primary cryptographic defense where a monotonically increasing number is included in the signed message. Each transaction from an account must have a unique nonce, making every signature single-use. Key implementations:
- Transaction Nonce: Used in networks like Ethereum for sequencing.
- Contract Nonce: Managed within a smart contract's state for specific user actions.
04
EIP-155 & Chain ID
Ethereum Improvement Proposal 155 introduced a definitive fix for cross-chain replay by mandating the inclusion of the chain ID in the transaction signing scheme. This ensures a signature is only valid for the intended network (e.g., Mainnet ID: 1). This standard is now fundamental to all Ethereum-compatible transaction formats.
05
Time-Locked Signatures
A mitigation strategy that restricts the validity of a signature to a specific time window using a deadline or expiry timestamp. This limits the attacker's opportunity window to replay a captured signature. It is commonly used in decentralized exchange permits and meta-transactions to reduce the risk of signature reuse.
06
Real-World Example: The DAO Fork
The 2016 Ethereum hard fork to recover funds from The DAO hack created a classic replay attack vector. Transactions were valid on both the new Ethereum chain and the original Ethereum Classic chain because signatures lacked chain-specific data. This event directly led to the development and adoption of EIP-155.
visual-explainer
SIGNATURE REPLAY ATTACK
Visualizing the Attack Flow
A step-by-step breakdown of how a signature replay attack exploits the reuse of a valid cryptographic signature to execute unauthorized transactions on a blockchain.
A signature replay attack occurs when an attacker intercepts a legitimate, signed transaction and maliciously resubmits it to the network to execute it again. This attack vector exploits the fundamental property that a valid digital signature does not inherently contain context about its intended single use. The core vulnerability lies in the smart contract's logic failing to track whether a specific signed message, or signature hash, has already been processed. Without proper safeguards, the network sees the replayed signature as a new, valid authorization from the original signer.
The attack flow typically follows a predictable sequence. First, a user signs a transaction—for example, authorizing a token transfer—creating a unique cryptographic signature. An attacker, often by monitoring the public mempool, captures this signed data. They then replay this captured signature by packaging it into a new transaction, which they broadcast to the network. Because the signature cryptographically verifies against the original signer's public key and the transaction data, the network's validation logic approves it, resulting in a duplicate, unauthorized transfer of assets from the victim's account.
To prevent this, developers implement specific defense mechanisms. The most common is the use of a nonce—a unique, incrementing number included in the signed message. The smart contract stores the last used nonce for each account and rejects any signature containing a nonce that has already been used. Another robust method is to incorporate chain identifiers and contract addresses into the signed data, a technique formalized in EIP-712 for structured signing. This domain separation ensures a signature is only valid for a specific contract on a specific blockchain, preventing cross-chain and cross-contract replay attacks.
Real-world examples highlight the severity of this flaw. Early token contracts without replay protection were vulnerable when Ethereum forked into Ethereum and Ethereum Classic; a signature made on one chain could be replayed on the other. Furthermore, poorly implemented multi-signature wallets or authorization schemes have been drained by attackers who intercepted and reused a single approval signature. These incidents underscore that signature validation must account for transaction uniqueness and execution context, not just cryptographic correctness.
Ultimately, visualizing the attack flow clarifies that the vulnerability is not in the cryptography itself but in the application-layer logic. Secure design mandates that every signed message must be uniquely identifiable and single-use. By integrating nonces, chain IDs, and deadline timestamps into the signable payload, developers can transform a reusable cryptographic proof into a context-bound, one-time authorization, effectively neutralizing the replay attack vector.
common-contexts
SIGNATURE REPLAY
Common Contexts for Replay Vulnerabilities
A signature replay attack occurs when a valid cryptographic signature is maliciously reused in a different context, allowing an unauthorized action. These vulnerabilities typically arise in smart contracts that fail to properly scope or invalidate signed messages.
01
Cross-Chain Replay
A signature validated on one blockchain is replayed on a forked or parallel chain with identical contract addresses. This is a critical risk during network upgrades or hard forks (e.g., Ethereum Classic fork).
- Mechanism: The attacker obtains a signed message authorizing a transaction on Chain A.
- Attack: They submit the same signature to an identical contract on Chain B, where the authorization is still considered valid.
- Prevention: Include the
chainId(EIP-155) in the signed message digest to bind the signature to a specific network.
02
Cross-Contract Replay
A signature intended for one smart contract is reused to execute a function on a different contract, often within the same protocol or ecosystem.
- Mechanism: A user signs a message to permit
Contract Ato spend tokens.Contract AandContract Buse the same signature verification logic. - Attack: An attacker takes the signature and submits it to
Contract B, tricking it into executing a similar privileged action. - Prevention: Incorporate the contract's own address (
address(this)) into the signed message hash, creating a unique digest for each contract.
03
Replay via Malleable Signatures
Certain signature schemes, like Ethereum's early personal_sign, are vulnerable to signature malleability, where the same signed digest can have multiple valid signature representations.
- Mechanism: The ECDSA
(v, r, s)tuple can be transformed into a different, yet valid,(v', r, s')signature for the same message. - Attack: A contract that only checks if a signature is valid, without recording which specific signature was used, can have the transformed signature replayed.
- Prevention: Use higher-level standards like EIP-712 for structured data, or implement a nonce system to record used signatures.
04
Lack of Nonce or Deadline
The most common vulnerability: signed messages (e.g., for token approvals or meta-transactions) lack a unique identifier or expiration, making them valid indefinitely.
- Example: A user signs "Approve 100 tokens to Bob." Bob can replay this signature daily to drain 100 tokens repeatedly.
- Critical Fixes:
- Nonce: Include a sequentially incrementing number in the message. The contract must track used nonces.
- Deadline: Include a timestamp (
deadlineorexpiry) in the signed data, after which the signature is invalid.
- Standard: EIP-2612 (permit) for ERC-20 tokens mandates the use of a nonce and deadline.
05
DelegateCall & Proxy Context
In proxy contract architectures using delegatecall, the execution context (like msg.sender and address(this)) changes, which can break signature verification logic.
- Mechanism: A signature is verified in a logic contract. When called via a proxy's
delegatecall,address(this)refers to the proxy's address, not the logic contract's. - Vulnerability: If the signed message hash was computed using the logic contract's address, verification in the proxy context will fail, or worse, create a mismatch attackers could exploit.
- Prevention: Explicitly define and use a immutable, agreed-upon domain separator (as in EIP-712) that accounts for the proxy's address.
06
Prevention Checklist
A robust signature scheme must incorporate multiple defenses to be replay-resistant.
- Always Include:
chainId: Binds signature to a specific network.- Nonce: A unique, incrementing identifier for each signer.
- Deadline: A timestamp for signature expiration.
- Strongly Recommended:
- Use EIP-712 for structured, human-readable signing.
- Include verifying contract address (
address(this)) in the digest. - For proxies, use a domain separator that is immutable and proxy-aware.
- Verification: Store used nonces and check deadlines in the contract state.
prevention-mechanisms
SIGNATURE REPLAY
Standard Prevention Mechanisms
A signature replay attack occurs when a valid cryptographic signature is intercepted and fraudulently reused in a different transaction. These mechanisms are essential for ensuring transaction uniqueness and security across blockchain networks.
01
Nonce
A nonce (number used once) is a unique, incrementing counter attached to an account or transaction. It is the most fundamental defense, ensuring each signature is tied to a specific transaction sequence.
- Account Nonce: In Ethereum, each account has a nonce that increments with every transaction, making replay impossible on the same chain.
- Transaction Nonce: Explicitly included in the signed data, guaranteeing uniqueness.
02
Chain ID (EIP-155)
EIP-155 introduced the inclusion of the chain ID in the transaction signing process. This prevents a signature valid on one Ethereum network (e.g., Mainnet) from being replayed on another (e.g., a testnet or fork).
- How it works: The chain ID is encoded into the
vcomponent of the signature. - Impact: Made cross-network replay attacks obsolete, a critical upgrade for network security.
03
Domain Separator (EIP-712)
Used for typed structured data signing, the EIP-712 domain separator creates a unique signing context for smart contracts. It includes the chain ID, verifying contract address, and other data.
- Prevents: Replay of a signature between different contracts or across different chains.
- Common Use: Secure signatures for permits in DeFi (e.g., ERC-20
permitfunction) and off-chain approvals.
04
Deadline / Expiry Timestamp
Incorporating a deadline or expiry timestamp into the signed message limits its validity window. This is a time-based replay protection mechanism.
- Function: The signature is only valid if used before the specified block timestamp or Unix time.
- Application: Critical for meta-transactions, gasless transactions, and decentralized exchange orders to prevent stale signatures from being executed later.
05
Contract-State Nonce or Salt
Smart contracts can implement their own internal nonce or a user-provided salt for actions like creating contracts or executing specific functions.
- Contract-Counter Nonce: A mapping that tracks the number of times a user has performed an action.
- Unique Salt: A random value provided by the user, ensuring the hash of the transaction data is unique every time.
- Example: Used in CREATE2 for deterministic contract address generation and replay-safe multi-signature wallet executions.
06
Replay Protection in Forks
During a blockchain fork, transactions can be replayed on both chains because they share a history. Projects implement specific fork replay protection.
- Opt-In Protection: Users may need to add a marker (e.g.,
OP_RETURNdata in Bitcoin) to differentiate chains. - Automatic Protection: Some forks change signature schemes or enforce different transaction formats from the genesis block.
- Historical Note: The Ethereum Classic fork initially suffered from replay attacks before implementing protective measures.
code-example
SIGNATURE REPLAY
Code Example: The Vulnerability and Fix
This section dissects a smart contract vulnerability where a valid digital signature can be maliciously reused, and demonstrates the standard mitigation.
A signature replay attack occurs when a valid cryptographic signature, intended for a single authorized transaction, is intercepted and submitted multiple times to execute the same action. This vulnerability is common in systems where signatures are not intrinsically bound to a specific transaction instance or chain context. For example, a user might sign a message to authorize a one-time token transfer, but an attacker could replay that signed message to the network, causing the transfer to execute repeatedly and drain the signer's funds. The core issue is the lack of a mechanism to mark a signature as used.
The standard defense is to incorporate a nonce—a number used once—into the signed message. Before executing the signed instruction, the contract checks a stored mapping to see if the nonce has been used. This is often combined with the chainId to prevent cross-chain replay attacks, where a signature valid on one blockchain (e.g., a testnet) is replayed on another (e.g., mainnet). Implementing these checks ensures each signature is uniquely tied to a single transaction on a specific network, rendering any intercepted copy invalid for future use.
Consider a contract function claimAirdrop(bytes signature). A vulnerable version would simply verify the signature corresponds to an eligible address and transfer tokens. The fixed version requires the signed message to include claimantAddress, nonce, and chainId. The contract logic then verifies: 1) the signature is valid for this message, 2) the chainId matches the current blockchain, and 3) the nonce for the claimantAddress has not been recorded as used. Upon success, it transfers the tokens and records the nonce, preventing any replay of that exact signature.
ecosystem-standards
SIGNATURE REPLAY
Ecosystem Standards & Implementations
A signature replay attack occurs when a valid digital signature is maliciously reused to execute a transaction or action it was not originally intended for, exploiting insufficient context in the signature's message.
01
Core Vulnerability
The fundamental flaw is that a signature is a cryptographic proof of approval for a specific message hash. If the signed data (e.g., transaction details) does not include unique, binding context, an attacker can replay it in a different but valid context. Common missing elements include:
- Chain ID: To prevent cross-chain replay.
- Nonce: To prevent replay on the same chain.
- Contract Address: To prevent reuse on a forked or duplicate contract.
- Deadline: To enforce a validity window.
04
Nonce-Based Protection
Within a single chain/contract context, nonces are the primary mechanism to ensure one-time use of a signature. Each signed message or permit must include a unique, incrementing nonce.
- Account Nonce: In native transactions, the sender's transaction count prevents replay of the same transfer.
- Contract Nonce: Standards like EIP-2612 (Permit) for ERC-20 tokens mandate a user-specific
noncestored in the token contract. Once a signature with a given nonce is used, it can never be used again, even if all other parameters (amount, spender) are identical.
06
Best Practices for Developers
To prevent signature replay attacks, smart contract and dApp developers must implement a defense-in-depth approach:
- Always use EIP-712 for structured signing with a domain separator.
- Include a Chain ID in all signatures.
- Implement a Nonce System for stateful actions and ensure it's part of the signed message.
- Use Deadlines (
deadlineorexpiry) to limit signature validity. - Verify in Contract: The verifying contract must explicitly check all these parameters (e.g.,
block.chainid,nonces[owner],deadline > block.timestamp) before accepting a signature.
SIGNATURE REPLAY
Common Misconceptions About Replay Attacks
A signature replay attack occurs when a valid digital signature from one transaction is maliciously reused to authorize another, unintended transaction. This glossary clarifies widespread misunderstandings about this critical blockchain security vulnerability.
A signature replay attack is a security exploit where a valid digital signature from a legitimate transaction is intercepted and fraudulently reused to authorize a separate, unauthorized transaction. This is possible because the signature itself only cryptographically proves the signer approved the signed data; if that same data (or a maliciously identical copy) is submitted again to the network, the signature remains valid. The core vulnerability lies not in the cryptography but in the application logic failing to make each signature uniquely bound to a single, specific operation.
For example, if a user signs a message to approve a token transfer of 10 ETH, an attacker could 'replay' that signed message to the same smart contract, causing the 10 ETH transfer to execute a second time without the user's consent, effectively doubling the intended payment.
SIGNATURE REPLAY
Frequently Asked Questions (FAQ)
Signature replay attacks are a critical security vulnerability in smart contracts that can lead to unauthorized transactions. This FAQ addresses common questions about how these attacks work, how to prevent them, and their real-world implications.
A signature replay attack is a security exploit where a valid cryptographic signature, intended for a single authorized transaction, is maliciously reused ('replayed') to execute the same or a similar transaction again without the signer's consent. This occurs when a smart contract fails to properly invalidate or track signatures after their first use. The attack exploits the fact that the signature itself is just data; without a mechanism to mark it as 'used,' it can be submitted repeatedly.
Key Mechanism:
- A user signs a message (e.g., 'Transfer 10 tokens to address X') and submits it to a contract.
- The contract verifies the signature is valid and executes the transfer.
- If the contract does not record that this specific signature hash has been used, an attacker can copy the signed data from the blockchain and submit it again, causing the contract to execute the transfer a second time.
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