How crypto hacks happen: the main attack types

Most crypto hacks happen in one of a few ways: a flaw in a smart contract, a price the protocol trusts that can be moved, a governance process that can be captured, a private key that leaks, or software in the delivery chain that gets replaced. This guide explains each type with real cases from our verified hack database, with every amount as the primary source states it.

How we classify incidents

Every incident in our hack database is written from primary sources: the affected project's post-mortem, an official announcement, a governance post or an authority's press release. Each one gets a type. The types describe how the loss happened, not who is to blame:

The database also has types for phishing, rug pulls and depegs. How we collect and check the facts is described in How we report incidents. Year-by-year totals are in our reviews of 2025 and 2026 so far; this guide is about the mechanics.

Smart contract bugs

A smart contract does exactly what its code says, including what its authors did not intend. An exploit finds a path through the code that lets an attacker withdraw more than they put in.

The flaws are often small. KyberSwap Elastic's pools were drained through a rounding flaw at a tick boundary of its swap mechanism; the team put the loss at about $55.2 million from the pools.¹ Onyx Protocol lost about $2.1m through a rounding bug in a newly listed market.² See KyberSwap Elastic and Onyx Protocol.

A bug can also sit below the protocol. Several Curve Finance pools were exploited through a latent bug in the reentrancy guard of older releases of the Vyper compiler, according to the Vyper team's post-mortem.³ The pools' own code was not the cause; the compiler that turned it into bytecode was (incident page).

Some of the largest cases ended with funds returned. Euler's lending protocol lost assets worth about $197M at the time of the attack, and after negotiations the exploiter returned all recoverable funds, according to the Euler Foundation.⁴ See Euler Finance.

Prices the protocol trusts

Lending protocols value collateral with a price feed, an oracle. If that price is wrong, or can be pushed, a borrower can take out loans against collateral that is worth less than the protocol thinks.

• A price that is moved. On Sentiment, an attacker manipulated the oracle price of a Balancer LP token, borrowed against the inflated collateral and left about $1,092,191.98 of bad debt, according to the team's recovery plan.⁵ (incident page)
• A price that is wrong. On Moonwell's Base market, a faulty feed valued one wrsETH at more than a million ETH, and an attacker borrowed against minimal collateral, leaving $3.7M of bad debt.⁶ (incident page)
• A price that stops. During the LUNA collapse a price feed was suspended at a floor while the token kept falling, and accounts borrowed on Venus Protocol against the stale price, leaving a shortfall of about $14,200,000.⁷ (incident page)

Flash loans make the first case cheaper: an attacker can borrow a large amount within one transaction, move a price, use it and repay the loan before the transaction ends.

Governance and upgrades

Many protocols let token holders vote on changes. If voting power can be borrowed, or the voting contract has a bug, the protocol's own process becomes the attack.

Beanstalk lost about $77M in user assets when an attacker used a flash loan to gain enough voting power to pass a proposal that sent the funds to a wallet they controlled.⁸ Audius lost 18,564,497 AUDIO from its community treasury after an attacker used a bug in the initialization code of its governance contracts to pass a malicious proposal.⁹ See Beanstalk and Audius.

Stolen keys and signing systems

A protocol can have flawless code and still lose everything if the key that controls it is taken. In our database, key compromises are among the largest incidents.

• A spoofed signing interface. The FBI attributed the theft of about $1.5 billion from the exchange Bybit to North Korean actors; Bybit said one Ethereum cold wallet was drained after its Safe signing interface was spoofed.¹⁰ (incident page)
• A key on a server. An attacker who obtained the SSH key of a Garden Finance solver operator read a private key stored in an environment variable and drained about $11.4M of the solver's assets.¹¹ (incident page)
• Minting keys. Attackers who reached Resolv's signing infrastructure illicitly minted 80M USR and extracted about $25M as ETH.¹² (incident page)

The software supply chain

The code users run is delivered through libraries, browser extensions, build pipelines and developers' machines. Each is a place to swap in something malicious.

• An attacker who phished a former Ledger employee published a malicious version of the Ledger Connect Kit library, which injected drainer code into the apps that loaded it.¹³ (incident page)
• A malicious build of the Trust Wallet browser extension was published outside the normal release process. Trust Wallet identified 2,520 wallet addresses drained by the attackers and about $8.5 million in impacted assets associated with 17 attacker wallet addresses.¹⁴ (incident page)
• At WOO X, attackers backdoored a developer's laptop through a fake open-source collaboration, reached production systems and made $14 million in unauthorized withdrawals from nine user accounts.¹⁵ (incident page)

Bridges and market manipulation

Bridges hold large pools of locked assets and rely on a message from another chain to release them, which makes them a frequent target. Kelp DAO's rsETH bridge accepted a forged cross-chain message and unlocked 116,500 rsETH for an attacker, according to the LayerZero Labs incident report.¹⁶ (incident page)

Market manipulation needs no bug at all. The SEC charged a trader with manipulating the MNGO token of Mango Markets and using the inflated position to borrow and withdraw about $116 million.¹⁷ (incident page)

Limits of the database

• Amounts as stated. We use the figure the primary source gives, in its own currency. Token amounts are not converted into dollars, so not every incident has a dollar figure.
• Verified incidents only. An incident enters the database once its primary sources are checked. Incidents without a checkable primary source are not included.
• No blame beyond the sources. Attribution, for example to a state actor, appears only when an authority or the project's own report states it.

The hack database lists every incident with its type, chain, amount and sources. Addresses that official sources name as attacker wallets, and where their funds moved next, are on Listed wallets.