Different Types of Attacks on Blockchains

With its immutability, global consensus, and open verification, blockchain may look like the ultimate security system. In practice, every blockchain is built from a stack of moving parts: a peer-to-peer network, a consensus mechanism, a smart contract runtime, and the wallets and users on top. Each of those layers has its own attack surface, and skilled attackers spend their time looking for the weakest link.

This guide walks through the most important attack types in use today, what they target, how they work, and which defences make them harder to pull off.

What Are Blockchain Attacks?

A blockchain attack is any deliberate attempt to break the integrity, availability, or confidentiality of a blockchain system. The goal can be financial (stealing funds, double-spending coins, draining a smart contract), strategic (censoring transactions, splitting a network), or reputational (slowing the chain to a crawl during a high-profile launch).

The most useful way to think about these attacks is by layer. The network layer carries blocks and transactions between nodes. The consensus layer decides which version of history the network agrees on. The smart contract layer runs the application code that holds user funds. The user layer is where private keys and wallet approvals live. An attack at any one of these layers can compromise everything above it.

Consensus and Network Attacks

Attacks at the base of the stack target how nodes talk to each other and how the network agrees on the canonical chain. They tend to require either a lot of resources or a lucky position in the network topology, and they are the most studied class of blockchain attacks.

51% Attack

The 51% attack is the most well known threat to public proof-of-work chains. An attacker who controls more than half of the total hash rate can secretly mine an alternative chain, then publish it to overwrite recent blocks. The result is usually a double spend: the attacker spends coins on one branch, then erases that transaction by replacing the chain with their longer private branch.

Smaller proof-of-work coins like Ethereum Classic and Bitcoin Gold have suffered confirmed 51% attacks. Bitcoin and other large networks remain economically unrealistic to attack this way, since renting that much hash rate would cost more than any plausible payout.

Sybil Attack

In a Sybil attack, a single adversary spins up many fake identities to gain disproportionate influence over a peer-to-peer network. On a blockchain, that can mean flooding the network with malicious nodes that refuse to relay certain transactions, vote dishonestly in governance, or surround a victim node so it only sees the attacker’s view of the chain.

Most blockchains defend against Sybil attacks by making identity expensive: proof-of-work requires real hardware and electricity, while proof-of-stake requires real capital locked as collateral.

Eclipse Attack

An eclipse attack is a targeted version of a Sybil attack. Instead of trying to dominate the entire network, the attacker monopolises every connection from a single victim node. The victim only talks to attacker-controlled peers, so it sees a manipulated view of the blockchain.

Eclipsed nodes can be tricked into accepting double spends, censoring their own transactions, or wasting hash power on a fake chain. Proper peer selection, more outbound connections, and trusted bootstrap lists are the standard defences.

DDoS Attack

A distributed denial-of-service (DDoS) attack tries to make a network resource unavailable by flooding it with traffic from many sources. On a blockchain, a DDoS can target individual full nodes, public RPC endpoints, validator infrastructure, or the mempool itself by spamming low-value transactions.

The hard part is telling fraudulent traffic from legitimate use. Transaction fees raise the cost of spam, but they have to stay low enough that ordinary users and smart contracts can still afford to transact. Mature chains rely on a mix of fee markets, rate limits at the RPC layer, and well-distributed validator infrastructure to soak up the load.

Routing Attack

Routing attacks exploit the internet itself rather than the blockchain protocol. By tampering with BGP routes between large hosting providers, an attacker can intercept or delay traffic between mining pools or validators. Even short delays can fork the chain, double-spend transactions, or deny rewards to specific miners.

Routing attacks are difficult and noisy, but they have been demonstrated against real networks. Encrypted peer-to-peer connections and geographically diverse infrastructure raise the bar significantly.

Selfish Mining

Selfish mining is a strategy in which a miner finds new blocks but withholds them from the rest of the network. By releasing a private chain at the right moment, the selfish miner can orphan blocks found by honest miners and earn a larger share of rewards than their hash rate would normally allow.

The strategy becomes profitable above roughly a quarter of the network hash rate and is one of the reasons Bitcoin protocol designers care about mining-pool decentralisation.

Smart Contract and Protocol Attacks

Above the consensus layer sits the application layer. Smart contracts are programs that hold and move funds, and a single bug in their code can be drained in a single block. This is where most large losses in modern crypto have actually happened.

Reentrancy Attack

Reentrancy is the classic smart contract exploit. The attacker calls a vulnerable function that sends funds to an external address, and the receiving contract calls back into the original function before it has finished updating its internal state. By repeating the cycle, the attacker can withdraw the same balance many times.

The 2016 DAO hack on Ethereum, which led directly to the Ethereum / Ethereum Classic split, was a reentrancy exploit. Modern Solidity contracts use the checks-effects-interactions pattern and reentrancy guards to prevent it.

Integer Overflow and Underflow

Many early smart contracts represented balances using fixed-width integers. If a calculation produced a value larger than the maximum, the result would silently wrap around to zero, or the other way around for subtractions. An attacker could exploit that wrap-around to mint enormous balances out of nothing, or to drain a contract by underflowing a check.

Solidity 0.8 made overflow checks the default at the language level, and audited libraries had been doing the same for years before that. It is still one of the first things auditors look for in older or unusual code.

Front-running and MEV

Front-running exploits the public mempool. When a profitable transaction is broadcast, bots see it before it is included in a block and submit their own transaction with a higher fee, getting in first. The most common form on Ethereum is the sandwich attack, where a bot buys before a large swap and sells immediately after, pocketing the price impact.

This is the most visible part of maximum extractable value, or MEV. Solutions range from private transaction relays and encrypted mempools to fair-ordering protocols at the consensus layer.

Bridge Exploits

Cross-chain bridges hold deposited assets on one chain and mint a wrapped representation on another. They have become some of the largest pots of money in crypto, and they have repeatedly proven to be the weakest link. A bridge can be attacked by compromising the validator set that signs withdrawals, by tricking the contract into releasing funds without a real deposit, or by exploiting a bug in the verification logic.

The Ronin bridge lost roughly 625 million dollars in 2022 after attackers compromised five of nine validator keys. Wormhole lost about 325 million dollars in the same year through a signature-verification bug. Nomad was drained for around 190 million dollars when a misconfigured upgrade let anyone replay valid messages.

Flash Loan Attacks

A flash loan lets a borrower take out an enormous, uncollateralised loan as long as they repay it within the same transaction. Attackers chain flash loans with vulnerable smart contracts to manipulate oracle prices, drain lending pools, or arbitrage broken markets at huge scale, all without ever putting their own capital at risk.

Flash loan attacks rarely break the loan itself. They exploit a different protocol that trusts a price feed or balance check that can be temporarily skewed by the borrowed liquidity.

Cryptographic and Transaction Attacks

This category covers attacks that target how transactions are formed, signed, or replayed, rather than the consensus or the contracts themselves.

Replay Attack

A replay attack intercepts a valid signed transaction and broadcasts it again, hoping the network will accept the duplicate. The original signer authorised it once, so the cryptography still checks out. Replay attacks are most dangerous after a chain split, where a transaction valid on one fork can also be valid on the other.

Standard defences include per-account nonces, chain identifiers in the signed payload (Ethereum’s EIP-155 added this after the DAO fork), and fresh session tokens for off-chain signed messages.

Long-Range Attack

Long-range attacks target proof-of-stake chains. An attacker who once held a large stake can use their old keys to build an alternative chain starting far back in history. If a new node bootstraps from a malicious snapshot, it might pick the attacker’s chain as the real one.

Modern proof-of-stake systems mitigate this with weak subjectivity checkpoints, slashing of historical validator keys, and finality gadgets that make rewriting old history economically impossible.

Race and Finney Attacks

A race attack is a quick double spend against merchants who accept zero-confirmation payments. The attacker broadcasts one transaction to the merchant and a conflicting one to the rest of the network, hoping the second one is mined.

The Finney attack is a variant in which the attacker is also a miner: they mine a block containing their own double-spend transaction, withhold it, pay a merchant in person, then publish the withheld block to invalidate the merchant’s payment. Both are simple to defend against by waiting for at least one or two confirmations.

User-Targeted Attacks

The largest single category of crypto losses today does not involve breaking any blockchain at all. It involves tricking the user.

Phishing

Phishing tricks a user into signing a malicious message or transaction, usually by impersonating a trusted brand. A fake exchange login page steals credentials. A fake airdrop claim asks for a wallet signature that turns out to be an unlimited token approval. A fake support agent walks a victim through revealing their seed phrase.

Hardware wallets, signature simulation in the wallet UI, and conservative use of token approvals (revoking them when no longer needed) are the most effective defences for end users.

Address Poisoning

Address poisoning is a newer trick that abuses the way wallet UIs truncate long addresses. The attacker sends a tiny transaction from an address whose first and last characters match an address the victim has used before. When the victim later copies an address from their transaction history, they grab the poisoned one and send funds to the attacker.

The fix is mechanical: never copy an address from a transaction list. Use an address book, a name service, or full visual verification of the entire string.

Cryptojacking

Cryptojacking hijacks someone else’s computing resources to mine cryptocurrency. It can run as JavaScript on a compromised website, as malware on a personal computer, or as a container hidden inside a cloud account whose credentials were leaked. The victim pays the electricity bill while the attacker keeps the rewards.

Browser-based cryptojacking has largely faded with the rise of ad blockers, but cloud account compromises remain a real and expensive problem for businesses.

Notable Real-World Exploits

The history of blockchain attacks is also the history of how the industry learned its hardest lessons. A handful of incidents are worth knowing because they shaped the defences in use today.

• The DAO (2016, around 60 million dollars): the reentrancy exploit that triggered the Ethereum hard fork and the creation of Ethereum Classic.
• Mt. Gox (2014, around 450 million dollars at the time): a long-running theft from a centralised exchange that highlighted the importance of self-custody and independent reserves.
• Parity multisig freeze (2017, around 280 million dollars): a user accidentally triggered a self-destruct in a shared library, permanently locking funds in many wallets.
• Ronin bridge (2022, around 625 million dollars): attackers compromised five of nine validator keys and drained the bridge in two transactions.
• Poly Network (2021, around 610 million dollars): a bug in cross-chain message verification let an attacker mint funds on every connected chain. Almost all of it was eventually returned.
• Wormhole (2022, around 325 million dollars): a signature-verification bug let an attacker forge a deposit and mint wrapped tokens out of thin air.
• Nomad (2022, around 190 million dollars): a misconfigured upgrade turned the bridge into a free-for-all, with hundreds of opportunistic addresses participating.

How to Defend Against Blockchain Attacks

No single change makes a blockchain bulletproof. The chains and applications that have stood up best combine several layers of defence:

• Decentralise the validator set. A protocol whose security depends on five signatures is only as strong as those five operators. Aim for many independent validators across jurisdictions and providers.
• Audit and formally verify smart contracts. Multiple independent audits, public bug bounties, and formal verification of critical invariants catch the bugs most likely to be exploited.
• Use safe coding patterns. Checks-effects-interactions, reentrancy guards, pull-payment patterns, and well-maintained libraries eliminate entire bug classes.
• Harden oracles. Time-weighted average prices, multiple data sources, and circuit breakers protect against price manipulation through flash loans.
• Limit blast radius. Bridges and lending markets benefit from per-asset deposit caps and rate-limited withdrawals so a single bug cannot drain everything at once.
• Educate users. Hardware wallets, signature previews, address books, and conservative approval management stop most user-targeted attacks before they start.

Final Thoughts

Blockchains do not fail in one place. They fail along a stack: from BGP routes and validator keys at the bottom, up through smart contract code and oracle feeds, all the way to the wallet on a user’s phone. The good news is that every successful attack of the past decade has produced concrete defences, and most of those defences are in place by default in the major chains and frameworks today.

The work, both for protocol designers and for everyday users, is to keep that mindset. The next major exploit will almost certainly happen at the layer everyone forgot to look at.