Blog

Life after Bybit: Takeaways from the biggest hacks in crypto history

Resources
No items found.
·
·
Bryce Ferguson, Co-Founder & CEO of Turnkey

About: This article examines the biggest crypto hacks by value lost, explains what failed in each case, and highlights the security controls that actually matter at execution time.

Audience: Web3 and fintech developers, security engineers, protocol designers, infrastructure teams, and product leaders responsible for wallet architecture, signing workflows, and asset security.

What you’ll learn:
  • How the largest crypto hacks happened
  • Where signing workflows, message trust, and key authority broke down
  • The recurring security lessons across exchanges, bridges, and custody systems
  • Which modern controls could have helped to mitigate these security incidences

Reading time: ~14 minutes

In February 2025, the Dubai-based cryptocurrency exchange Bybit suffered what is widely regarded as the largest crypto exchange hack ever. Attackers stole approximately 400,000 ETH and related tokens, valued at roughly $1.4 billion to $1.5 billion at the time. 

Crypto has come a long way in less than two decades. But even as technology evolves, the lessons from major security incidents remain strikingly consistent. These biggest crypto hacks reveal deep problems in how systems manage trust, keys, signing authority, and the assumptions developers make about control.

This article looks at some of the most impactful crypto hacks of the last decade, explaining what happened, why it happened, and what that teaches us about building secure systems.

Why it’s important to understand crypto security incidents of the past

Studying past crypto hacks can help developers better understand where assumptions break down in production. They show which controls fail first, which layers attackers target, and which security measures only work on paper. By analyzing past hacks, we can avoid repeating the same mistakes, rather than defending against hypothetical threats.

Just as importantly, historical incidents reveal what kind of controls matter. Many of the largest losses were not caused by missing audits or novel cryptographic attacks, but by weaknesses in signing workflows, key custody, operational trust, and system visibility. Understanding that helps teams focus security efforts on the control surfaces that actually fail at scale.

Ranking history’s worst crypto hacks

The hacks in this article are ranked by total value lost at the time of the incident, using reported figures from exchanges, blockchain analytics firms, and public investigations.

This ranking is not intended to imply severity in terms of user impact, technical sophistication, or long-term ecosystem damage. Some smaller incidents introduced more important security lessons than larger ones. However, dollar value provides a consistent and widely understood benchmark for comparison.

Crypto's Greatest Hacks
Crypto's Seven Greatest Hacks

Across exchanges, bridges, and custody systems, these seven incidents show that crypto failures rarely come from broken cryptography. They occur when signing authority, message trust, asset creation, or key access is insufficiently constrained. 

1. Bybit hack (2025)

What happened

Hackers drained approximately 400,000 ETH, worth an estimated $1.4 to $1.5 billion, from an Ethereum cold wallet by manipulating the signing approval workflow.

Why it happened

Transactions were constructed in a way that hid their true behavior, causing legitimate signers to approve malicious transfers without realizing what they were authorizing.

What this teaches us

A valid signature gives absolute authority. If an attacker can influence what is being signed, the system will execute it exactly as written.

The modern security solution

  • Intent-based transaction construction: Transactions are built from structured fields rather than signed as opaque payloads
  • Human-readable transaction parsing: Signers approve decoded actions instead of hashes or calldata
  • Secure policies: protected guardrails that many not have let users sign in even if they tried to 

2. Ronin Network hack (2022)

What happened
Attackers stole approximately $625 million from the Ronin Bridge by obtaining control of enough validator private keys to approve fraudulent withdrawals.

Why it happened
Although Ronin used a validator threshold, signing authority was operationally centralized. A small set of validators controlled the bridge, and some keys were accessible through shared infrastructure and legacy trust assumptions. 

Once attackers compromised a sufficient number of validator keys, withdrawals appeared fully valid to the system.

What this teaches us
Threshold signing alone does not provide security if key custody, operational access, or trust boundaries are weak. If multiple “independent” signers can be compromised through the same failure path, the threshold becomes meaningless.

Modern security solution

  • Enforced threshold signing with hard isolation
    Threshold approval must be paired with cryptographic and infrastructural isolation, so compromising one environment does not increase access to others.

  • Independent trust domains for signers
    Each signer must live in a separately secured execution environment with no shared credentials, no shared access paths, and no implicit trust between validators

3. Poly Network hack (2021)

What happened

Poly Network lost around $610 million after attackers crafted malicious cross-chain messages that instructed contracts on destination chains to release assets to attacker-controlled addresses.

Why it happened

The bridge trusted the content of incoming cross-chain messages without sufficiently verifying who was authorized to send them and under what conditions. Attackers were able to forge messages that looked structurally valid but were not legitimately authorized by Poly Network’s governance or control logic.

What this teaches us

In cross-chain systems, messages are authority. If a system cannot cryptographically and contextually verify that a message was produced by the correct actor, for the correct action, under the correct rules, then asset movement becomes unrestricted.

Modern security solution

  • Strict cross-chain message allowlisting: Only approved message sources and message types are accepted
  • Origin and destination verification: Messages must come from known contracts and trigger-approved actions

4. Binance BNB Chain Bridge hack (2022)

What happened
Attackers exploited a flaw in the BNB Chain bridge to mint approximately 2 million BNB, worth around $570 million, before some funds were frozen.

Why it happened
The bridge treated submitted “proofs” as direct authorization to mint new tokens. If a message claimed assets were locked on the source chain and passed basic checks, minting proceeded without additional authority or limits. Attackers exploited this assumption to submit forged messages that created assets without a real underlying deposit.

What this teaches us
Bridges are not just transport mechanisms. They are systems that decide when value is allowed to exist. If the rules that govern that decision are flawed, the system can create assets out of nothing.

Modern security solution

  • Mint authority separation
    Evidence that assets exist elsewhere must not automatically grant permission to mint. Proofs should be inputs to a decision, not the decision itself.

  • Supply caps and issuance limits
    Even if verification logic fails, hard limits on issuance prevent catastrophic asset creation.

5. Coincheck Hack (2018)

What happened

Hackers stole approximately $534 million in NEM tokens after gaining access to an exchange’s hot wallet.

Why it happened

Large balances were kept online without strong multi-party controls, allowing attackers to move funds rapidly once access was obtained.

What this teaches us

Custody architecture many times determines loss severity. Always-online access can in certain conditions maximize the blast radius of a breach.

Modern security solution

  • Hot wallet exposure limits: Only minimal operational balances remain online
  • Time-delayed withdrawals: Large transfers cannot execute immediately

6. Wormhole Bridge Hack (2022)

What happened

Attackers minted approximately $326 million in wrapped assets by exploiting a validation bug that allowed forged signatures to be accepted.

Why it happened

The system trusted signatures without enforcing limits on what those signatures were allowed to authorize.

What this teaches us

A valid signature is not the same as a safe action. Signatures must be constrained by purpose and scope.

Modern security solution

  • Signature context validation: Signatures are evaluated against purpose and scope
  • Scoped mint authorization: Signers cannot approve unlimited asset creation

7. DMM Bitcoin Hack (2024)

What happened

Attackers stole roughly 4,500 BTC, valued at about $305 million, after gaining unauthorized access to private keys controlling exchange wallets.

Why it happened

Keys controlling user assets were accessible in a way that allowed unauthorized use.

What this teaches us

Key security remains the dominant risk surface. Operational and regulatory controls do not replace technical isolation.

Modern security solution

  • Secure hardware key execution: Private keys operate inside hardened execution environments
  • Action-scoped key permissions: Private keys are restricted to specific assets and operations

What Bybit and these otherwell-known crypto hacks show

Across exchanges, bridges, and custody systems, these incidents point to the same root failure: unconstrained authority at execution time.

In every case, the system behaved as designed once a valid input was accepted.
A signature was valid.  A message passed verification. A proof was accepted.

The loss occurred because nothing limited what those inputs were allowed to do.

Modern crypto security failures are not about broken cryptography. They are about missing guardrails.

Alchemy Statement

How Turnkey addresses these security failures

Turnkey is built around a simple premise: signing is where authority is exercised in crypto systems, and that authority must be constrained at execution time.

Rather than treating wallets as passive key stores, Turnkey provides infrastructure for policy-enforced signing, where every operation is evaluated against developer-defined rules and executed inside isolated, verifiable environments. 

Developers use Turnkey to define what actions are allowed. Turnkey enforces those decisions at the moment a signature would otherwise be produced. 

This model directly targets the failure modes seen across Bybit, Ronin, Poly Network, Wormhole, and similar incidents:

  • Valid signatures that should not have authorized those actions
    Turnkey evaluates every signature against policy. A cryptographically valid signature does not imply unrestricted authority.

  • Messages that should not have been trusted
    Cross-chain and transaction messages are only allowed to trigger explicitly approved actions from known sources, rather than being accepted as opaque inputs.

  • Keys that should never have had broad, implicit power
    Keys are scoped to specific assets, actions, amounts, and destinations, sharply limiting blast radius even if a key is compromised.

The protections highlighted by these incidents are not add-ons in Turnkey. They are foundational to its design. 

With Turnkey, fintech and web3 developers get:

Policy-enforced intent
Every action is checked against deterministic rules that define what may be signed, under which conditions, and within which limits. Authority is explicit, not implied.

Isolated execution with TEEs
All signing operations occur inside hardened, trusted execution environments. Private keys are never exposed, and any compromise of surrounding infrastructure does not grant signing capability.

Scoped permissions and limits
Keys and signers can be restricted by asset type, transaction type, amount, destination, and frequency.

Deterministic verification
Turnkey provides verifiable guarantees about what code is running, which policies are enforced, and which actions were approved, replacing assumptions with observable proof.

Multichain, chain-agnostic enforcement
The same security guarantees apply across chains. Expanding to new networks does not weaken protections, because policies and execution constraints remain consistent everywhere.

Each of these mechanisms is ineffective on its own, but Turnkey enforces them together, at the moment actions are executed, where real losses occur. This is how wallet infrastructure evolves from trusting that nothing goes wrong to ensuring that when something does, it cannot turn into a catastrophic loss.

TEE ebook Statement

Turnkey: secure wallet infrastructure in a world of threats

Crypto infrastructure now secures billions of dollars in real value. Turnkey provides secure wallet infrastructure designed for teams that need strong guarantees around how assets are controlled, approved, and protected at scale. 

Crypto does not need stronger cryptography. It needs stronger guarantees about how authority is exercised. The next generation of infrastructure will not be defined by who can sign, but by what they are allowed to sign, under which conditions, and with what provable constraints.

If you are building systems that move value, span chains, or operate at scale, now is the time to rethink where trust lives in your architecture.

Learn how Turnkey enforces intent, isolation, and verification at the signing layer, and why modern crypto security starts there.

Get started with Turnkey. 

Related articles

Web3 security: Implicit trust, dependencies, and verifiability

Learn how verifiable systems allow participants to confirm that infrastructure is operating correctly by making system behaviors observable rather than assumed.

Resources
No items found.
January 23, 2026

Crypto wallet app development companies vs WaaS

Understand the differences between white-label crypto wallet app development and Wallet-as-a-Service (WaaS) solutions.

Resources
January 21, 2026