Double-Spend Attacks: Why You Can't Just Look at "Sent" for Blockchain Transactions

IntermediateLast Updated 2026-09-24

Many users assume that once a blockchain transaction is "sent," the funds have safely arrived. But the reality is not that simple. For exchanges, merchants, and ordinary users alike, what truly matters is not just whether a transaction has been broadcast, but whether it has been confirmed by a block, whether the number of confirmations is sufficient, and whether the underlying chain carries the risk of being reorganized. Understanding these concepts is the foundation for preventing "double-spend attacks."

This article focuses primarily on proof-of-work networks, where confirmation depth and cumulative proof of work are central to reorganization risk. Other consensus systems use different finality mechanisms.

A "double-spend attack" is essentially an attempt by an attacker to spend the same digital asset twice.

To use the most intuitive example: an attacker holds only 1 BTC but simultaneously initiates two conflicting transactions. One pays a merchant or platform for a deposit, purchase, or service; the other sends the same 1 BTC back to a wallet address controlled by the attacker. Since both transactions draw on the same funds, only one can ultimately be valid on-chain. If the merchant or platform trusts a transaction that is "not yet stably confirmed" too early, the attacker can later exploit a chain reorganization or a longer chain override, causing the previously seen deposit record to become invalid — while the assets have already been released to the attacker.

Therefore, a double-spend attack is not about "duplicating assets" — it exploits insufficient transaction confirmation, competing block production, or chain reorganization to make the same asset be used twice within a business process.

Although blockchain emphasizes that transactions are irreversible, this "irreversibility" typically does not hold immediately when a transaction is first sent. It gradually approaches irreversibility after being packaged, propagated, and confirmed.

An on-chain transaction generally goes through several states:

State	Description
Created	Wallet creates the transaction
Broadcast	Transaction is broadcast to the blockchain network
Pending	Waiting for miners or validators to package and confirm
Confirmed	Transaction has entered a block and begins accumulating confirmations
Failed / Dropped / Replaced	Transaction failed, or was replaced or dropped

Risk often appears during the Pending stage, and during the Confirmed but with too few confirmations stage. At these points, the transaction "appears to exist" but is not yet sufficiently stable. If the network forks, or if an attacker controls significant hash power and constructs a longer chain, the block containing the original transaction may be discarded — and the transaction record may "disappear."

This is what is known as a "chain reorganization." A chain reorganization is not simply deleting a record; it means the entire network ultimately recognizes a different chain, causing some blocks on the original chain to become invalid. If a deposit transaction exists only on the discarded branch, the deposit record the platform previously saw may lose its validity.

The number of confirmations determines how difficult it is to roll back a transaction.

When a transaction first enters a block, it typically has only 1 confirmation. With each new block produced, the confirmation count increases — 2 confirmations, 3 confirmations, 6 confirmations, even 12 confirmations. The higher the confirmation count, the more blocks would need to be rolled back to overturn the transaction, and the higher the attack cost.

This is why exchanges typically do not credit users immediately at 0 to 1 confirmations. The risk is higher at this stage, especially for blockchains with weaker hash power or a history of 51% attacks or chain reorganizations, where higher confirmation thresholds are needed.

Double-spend attacks are not a theoretical threat. In January 2019, Ethereum Classic (ETC) experienced a major 51% attack involving double-spend transactions.

Typical Attack Process:

Step	Action
1	The attacker first gained significant hash power dominance on the ETC network, enabling them to privately mine a longer chain
2	The attacker deposited ETC to an exchange
3	After the exchange saw the deposit transaction reach the required confirmation count, it credited the attacker's account
4	The attacker quickly sold the ETC on the exchange, converted it to USDT, BTC, or other assets, and withdrew the funds
5	Meanwhile, the attacker continued privately mining a longer chain that did not include the deposit transaction
6	When this longer chain was published to the network, the network accepted the new main chain, and the deposit chain the exchange had seen was rolled back

Outcome of this attack pattern: The deposit that had been "confirmed" in the exchange's records disappeared, but the attacker had already withdrawn the converted assets, completing the double-spend.

This case illustrates a key fact: Even if a transaction is already on-chain, if the underlying network security is insufficient, or if the attacker has the ability to reorganize blocks, the transaction can still be rolled back. The "finality" of a blockchain transaction is not absolutely instantaneous — it strengthens gradually as confirmations increase.

Preventing double-spend attacks is not about relying on "the other party's screenshot" or "the transaction hash exists" — it's about establishing proper confirmation and risk control mechanisms.

First, Don't Treat "Broadcast" as "Received"

A user seeing "sent" in their wallet, or the other party providing a transaction hash, does not mean the funds are safe. Broadcast only means the transaction has entered the network propagation stage — it does not mean it has been confirmed by a block. Actions such as crediting deposits, releasing coins, shipping goods, or providing services cannot be based on Pending status.

Second, You Must Verify On-Chain Confirmation Status

To judge whether a transaction is reliable, at minimum check:

Whether the transaction has been packaged into a block
What the current confirmation count is
Whether the transaction carries risks of abnormal replacement, conflicting transactions, or being dropped

For high-risk scenarios, don't just look at "whether the transaction exists" — look at "whether the confirmation is stable."

Third, Set Reasonable Confirmation Counts Based on the Chain's Risk Level

Different blockchains have different security levels. Mainstream high-hash-power chains differ greatly from small-cap, low-hash-power chains in the cost of suffering a 51% attack or chain reorganization. For higher-risk chains, platforms should raise deposit confirmation thresholds; for large transactions, higher confirmation requirements should also be set — not a one-size-fits-all approach.

Fourth, Apply Risk Control Monitoring to Abnormal Deposit Behavior

The following behaviors should trigger additional review:

Abnormal Behavior	Risk Explanation
Multiple large deposits followed by rapid selling and withdrawal within a short period	Typical double-spend attack path
Frequent deposits using historically weak-security coins	Low hash power chains have low attack costs
Requesting immediate withdrawal of assets right after reaching the minimum confirmation count	May exploit insufficient confirmation vulnerabilities
Transactions with abnormal delays, signs of conflict, or unstable status on blockchain explorers	Possible ongoing chain reorganization

These behaviors often closely match the operational patterns of double-spend attacks.

Fifth, Don't Trust Payment Screenshots or Single-Page Status

Screenshots are the easiest to forge and the easiest to mislead. Whether for merchant payments, over-the-counter trades, or deposit reviews, always rely on blockchain explorers and system risk control verification — not chat records, payment screenshots, or verbal statements.

Sixth, Understand That "Irreversibility" Is Not "Instantaneous"

Once a blockchain transaction reaches sufficient confirmations, it is indeed typically very difficult to reverse. But when confirmations are insufficient, transactions can still change due to forks, congestion, replacement, or chain reorganization. The most common misconception in security education is interpreting "blockchain transactions are irreversible" as "once sent, it's absolutely safe." This is precisely the cognitive gap that allows double-spend attacks to succeed.

For ordinary users, the most important thing is not to deliver goods, digital assets, or services before confirmation. Especially in over-the-counter trades, peer-to-peer transfers, and payments with strangers — looking only at screenshots without checking confirmations carries extremely high risk.

For merchants and platforms, truly effective protection is not "manual experience" but standardized mechanisms:

Clear confirmation thresholds
Differentiated risk levels by chain
Identification of abnormal withdrawal paths
Extended review time for high-risk asset deposits
Heightened vigilance for coins with a history of reorganizations or 51% attacks

The core of a double-spend attack is not "a hacker duplicating a coin" — it's an attacker exploiting unstably confirmed transactions to create the illusion of "already paid" within a business process. The ETC 2019 incident has already demonstrated that as long as the underlying chain carries the possibility of reorganization, insufficiently confirmed transactions should not be regarded as finally received.

The basic principle of secure transactions comes down to one sentence:

Look at confirmations, not screenshots; look at finality, not surface status.

The higher the confirmation count, the smaller the window for a successful double-spend attack.

Disclaimer: The information on this page may come from third parties and does not necessarily reflect KuCoin’s views. It is provided for general reference only and should not be interpreted as financial or investment advice.

Virtual asset investments may involve risk. Please carefully assess the product risks and your own risk tolerance. For more information, please refer to our Terms of Use and Risk Disclosure.