Crypto security incident timeline: how to read what happened next

A crypto security headline usually compresses several events into one alarming word: hack. That word can describe a smart-contract logic error, stolen validator keys, malicious software inserted into a website, a deceived multisignature team or compromised exchange custody. The immediate user response depends on which component failed, what authority the attacker gained and whether the path to further loss remains open.

The second compression happens in the recovery headline. “The bridge is back,” “funds are backed,” “the exploit is contained” and “affected users are made whole” are not synonyms. A protocol can patch vulnerable code yet remain paused while balances are reconstructed. A platform can continue withdrawals after absorbing a treasury loss. Stolen assets can be frozen but not returned. An attacker can return funds even though the original design flaw still requires a rebuild.

This guide studies eight first-party incident records from 2022 through 2025: Wormhole, Ronin, Euler, Ledger Connect Kit, two separate Radiant Capital events, Bybit and Cetus. They were selected because their official reports expose different failure modes and different outcomes. The goal is not to rank disasters by their dollar value. It is to build a reading method that still works when the next event is new.

The useful question is not only “Was it hacked?” Ask what failed, what remains exposed, what is usable now and who has actually recovered value.

The four states every incident update should separate

Incident response unfolds in stages, and the stages can overlap. Teams often publish while facts are incomplete because users need an immediate warning. Early uncertainty is normal. The editorial mistake is treating an early statement as the final post-mortem or treating one completed stage as proof that every later stage is complete.

1. Detection: what has been observed?

Detection begins with an anomaly: an unexpected transfer, distorted pool balance, unauthorized package version, failed signature flow, abnormal withdrawal or alert from an outside researcher. The first notice may use careful language such as “investigating,” “potential incident” or “unusual activity.” That caution does not necessarily indicate evasion; scope is still being established.

A good detection notice identifies the earliest known time, affected product and immediate precaution. It should not guess at attribution. On-chain transactions can show where assets moved, but they do not by themselves prove who controlled the destination. A company statement can identify compromised infrastructure, but a later forensic report may narrow or revise the root cause.

2. Containment: can further loss continue?

Containment means closing or restricting the active path. A protocol may pause contracts, disable a market, rotate keys, replace a malicious package, block a wallet interface or ask validators to reject transactions from named addresses. An exchange may move assets away from a wallet system under investigation. The action should match the attack surface.

Containment can be incomplete. A patch may protect new interactions while attacker-controlled keys remain valid elsewhere. A front end can be clean while users still hold malicious approvals granted during the incident. Frozen assets can move if the freeze depends on voluntary cooperation. Readers should look for a component-by-component statement rather than accepting “under control” as a technical description.

3. Restoration: what can users safely use?

Restoration is the controlled return of service. It can require code review, audits, balance reconciliation, testing, governance approval, liquidity replacement or migration to a new contract. A service reopening does not prove that every affected account has been compensated. It proves only that the operator considers the stated function ready under the new conditions.

The restoration notice should name the supported interface and any user action. A bridge may reopen at a new contract. A decentralized exchange can relaunch unaffected pools before affected pools. An exchange can keep trading and withdrawals open while replacing a custody provider. Old bookmarks and contracts may remain reachable even after deprecation, so the official destination matters.

4. Recovery: what value was returned, replaced or compensated?

Recovery is an economic and legal outcome. Stolen assets can be returned by an attacker, frozen by validators or issuers, replenished by a sponsor, covered by a company balance sheet, repaid through a DAO plan or remain missing. Each route gives users a different claim and timeline.

“Funds recovered” should identify the quantity, asset, recipient and remaining shortfall. Dollar figures change with market prices, so token quantities and the valuation time matter. “Users made whole” should identify which users and which balances. A treasury loss may be excluded even when retail balances are restored. A proof-of-reserves report can support an exchange's current backing claim without proving that stolen assets themselves were recovered.

Four failure families hidden inside the word “hack”

Bridge verification and validator compromise

Cross-chain bridges must decide when an event on one chain is sufficient to release or mint value on another. If message verification can be forged, wrapped assets can be created without matching collateral. If enough validator keys are compromised, a withdrawal can appear authorized under the bridge's own threshold rules.

Wormhole and Ronin demonstrate different versions of this family. Wormhole's 2022 incident involved verification logic on the Solana side. Ronin's incident involved compromised validator keys and a threshold that the attacker could satisfy. Both affected bridges, but their root causes, remediation and trust assumptions were different. “Bridge exploit” is only the category label.

Smart-contract logic and accounting errors

A smart contract can execute exactly as coded while the code permits an economically invalid state. Euler's missing health check enabled a self-liquidation sequence. Radiant's January 2024 event involved the liquidity index of a newly launched market with empty reserves. Cetus reported an overflow-check flaw in a library used by its concentrated-liquidity pools.

Audits reduce risk but do not prove the absence of exploitable behavior. Code changes, library dependencies, unusual initial conditions and interactions among functions can create paths that prior reviews missed. When a team says a contract was audited, the next questions are which version, which scope and whether the vulnerable path existed during that review.

Software supply-chain and front-end compromise

A protocol's on-chain contracts can remain unchanged while the software that prepares a transaction becomes malicious. Ledger's Connect Kit incident began when an attacker gained access to a former employee's package-publishing account and released malicious versions of a JavaScript library. Third-party decentralized applications loading the package could present a wallet-draining interaction.

This family changes the user check. Contract-address monitoring alone may not reveal that a website is constructing a malicious approval or transfer. Clear transaction details on a trusted wallet display, dependency pinning, package integrity and deployment controls become important. A hardware wallet protects keys from extraction; it cannot make a transaction safe when the owner authorizes harmful instructions.

Signer deception and operational compromise

Multisignature custody is designed so one key cannot act alone, but it still depends on the independence of signers and the integrity of the information they review. Radiant's October 2024 post-mortem described compromised contributor devices that displayed legitimate transaction information while malicious transactions were signed. Bybit's February 2025 investigation pointed to compromised Safe infrastructure and a deceived signing process during a routine cold-to-warm wallet transfer.

The number of signatures is not the whole security model. If several signers view the same compromised interface or share a vulnerable operational path, the approvals may not be independent in practice. Strong systems use transaction simulation, out-of-band verification, known contract hashes, role separation, delays and limits so that a convincing screen cannot authorize unlimited change.

Eight incident files, read by failure and outcome

2 February 2022 — Wormhole: forged verification, then recapitalization

Wormhole reported that its network had been exploited for 120,000 wrapped ETH. The official incident account described a failure in the Solana-side verification path that allowed an attacker to create a fraudulent verification state and mint wrapped value without the corresponding locked ETH. The network was halted while the vulnerability was fixed.

The incident's economic outcome differed from a direct recovery. ETH was added so the wrapped ETH would again be backed one-for-one, and the network returned to operation. That replenishment protected the backing relationship, but it did not mean the attacker returned the original assets. For a wrapped-asset holder, backing status and bridge operation were the immediate facts that mattered.

The durable lesson is about message validity. A bridge can have a distributed guardian set and still fail in the contract that verifies the guardians' message. Readers should locate the exact verification boundary rather than translating the event into “the chain was hacked.”

29 March 2022 — Ronin: validator keys and a bridge threshold

Ronin announced a bridge security breach after unauthorized withdrawals involving 173,600 ETH and 25.5 million USDC. Its subsequent security work emphasized validator distribution, withdrawal limits and governance changes. The relevant failure was not a generic wallet compromise for every Ronin user; the attacker gained enough validator authority to approve bridge withdrawals.

When the bridge reopened on 28 June 2022, Ronin said user funds were fully backed one-for-one and users had been made whole, while separately describing the Axie DAO treasury portion. The redesigned bridge had undergone internal and external audits and introduced circuit breakers, tiered approval thresholds and a daily withdrawal limit.

This sequence separates three milestones: breach disclosure, security redesign and user-balance backing at reopening. Anyone recording only the March loss misses the recovery structure. Anyone recording only the June reopening misses the validator-key failure that motivated the new controls.

13 March 2023 — Euler: contract logic exploit and negotiated return

Euler V1 was exploited through a code path involving the donateToReserves function. Euler's later account explained that a missing health check allowed the attacker to create an unhealthy position and benefit from self-liquidation. The function had been introduced as part of an earlier fix and had undergone review, which illustrates how a remediation can create a new interaction risk.

The economic outcome was unusual. After on-chain communication, investigation and negotiation, the attacker returned recoverable funds. The Euler Foundation announced that all recoverable funds had been returned, and Euler later described users' assets as fully recovered. That recovery did not erase the need to retire and rebuild the affected version.

Euler shows why recovery status cannot be inferred from exploit mechanics. A severe contract loss can lead to substantial return; a smaller incident can remain unresolved. The attacker's later behavior, legal pressure, traceability and negotiation are separate variables from the code vulnerability.

14 December 2023 — Ledger Connect Kit: malicious dependency versions

Ledger's Connect Kit incident affected a JavaScript library used by third-party decentralized applications. Ledger said a former employee was phished, enabling an attacker to publish malicious package versions 1.1.5, 1.1.6 and 1.1.7. The malicious code used a rogue WalletConnect project to redirect user funds. Ledger and partners disabled the path and published genuine version 1.1.8.

The scope statement mattered: Ledger said the integrity of Ledger hardware and Ledger Live was not affected. The incident concerned users who interacted with third-party applications loading the malicious kit during the window and then signed a harmful transaction. Owning a Ledger device without interacting with an affected application was not the same exposure.

For users, the lesson is to inspect the transaction on the trusted display. “Connect wallet” can lead to permissions or transactions beyond a simple login. For developers, package publishing access, pinned versions, code review and a secure build pipeline are part of the security boundary.

2 January 2024 — Radiant: a newly launched market and bad debt

Radiant Capital's January post-mortem described a flash-loan-based exploit of the newly introduced native USDC market on Arbitrum. The attack manipulated the liquidity index under the market's empty-reserve condition and created unauthorized borrowing and bad debt. Radiant paused relevant activity and later used a DAO-approved repayment process.

The affected scope was a market, not every blockchain component carrying the Radiant name. That distinction guides the first user check: which chain, market, pool or contract held the position? A global “Radiant hacked” headline could not tell a depositor whether their specific market was touched.

The later repayment of communal bad debt was not an attacker return. It used project resources under governance decisions. Both can lead toward restoring user balances, but the cost falls differently and can affect the protocol's future capacity.

16 October 2024 — Radiant: compromised devices and malicious signatures

Radiant experienced a second, separate incident in October. Its post-mortem said three long-standing contributors using hardware wallets and geographically distributed devices were compromised. The interface displayed expected transaction data while malicious ownership-changing transactions were signed and executed in the background.

The event demonstrates why an incident history cannot be summarized at brand level. January involved a market accounting condition; October involved the operational signing environment. The remediation for one would not necessarily stop the other. More audits of lending logic would not by themselves secure developer devices or multisignature transaction review.

Radiant's later updates said recovery remained ongoing and uncertain, and in 2026 the DAO described a reduced recovery-focused footprint. This is an example where containment and investigation did not become a claim that affected users were fully restored. A responsible timeline must leave the outcome open.

21 February 2025 — Bybit: a deceived cold-wallet signing flow

Bybit's incident affected one Ethereum cold wallet during a routine transfer. The platform's later forensic update said compromised Safe developer credentials allowed unauthorized access to Safe infrastructure and deceived signers into approving a malicious transaction. Bybit and third-party reviewers reported no indication that Bybit's own infrastructure was compromised.

Bybit kept withdrawals operating and moved funds away from Safe-administered addresses. A later proof-of-reserves review reported sufficient one-for-one backing for in-scope customer assets after the reserve gap was restored. That is a backing and solvency statement, not proof that the stolen assets had returned from the attacker.

The event exposes the difference between cold storage and safe operations. A cold wallet limits online exposure, but funds move through a ceremony involving software, devices, signers and contract authority. If the ceremony presents false information consistently, several valid keys can authorize an invalid outcome.

22 May 2025 — Cetus: pool math, frozen assets and relaunch

Cetus reported an exploit of its concentrated-liquidity market-maker pools on Sui. Its incident report linked the vulnerability to an incorrect overflow check in an open-source math library. The attacker used flash-swap and liquidity operations to create an artificially large position with minimal input and drain pool reserves.

Cetus disabled core pools and then relevant contracts. Sui validators voted to refuse transactions from attacker addresses, freezing a portion of affected assets on Sui, while other assets had moved outside the ecosystem. A freeze reduced movement; it did not itself transfer ownership back to users.

The protocol later published a recovery plan and relaunched on 8 June 2025 after patching, audits and balance work. Restoration depended on both technical remediation and a plan for affected liquidity. The event is a useful example of an ecosystem response that combined contract controls, validator action, governance and project funding.

How to build an incident record that survives later corrections

A useful incident record is a sequence of sourced claims, not a paragraph frozen at the moment of maximum confusion. Start one row for the first unauthorized action and another for public detection. They are often different. Ronin's bridge withdrawals and their later discovery illustrate why “incident date” can hide two clocks. Record the transaction time, detection time and disclosure time separately when the project supplies them.

Give each update a publication timestamp and preserve its uncertainty language. If the first statement says a breach “appears limited” to one component, do not rewrite that as a final finding. Add the later forensic conclusion as a new row. This keeps the record honest about what users knew at each decision point and prevents hindsight from making an early response look more certain than it was.

For the technical field, use a layered description. The broad family may be smart-contract logic, but the specific defect could be a missing health check under a particular accounting sequence. The affected object may be a single market on one chain. The privilege gained may be unauthorized borrowing. These layers let another reader distinguish the root cause from the attack technique and the financial effect.

For the economic field, keep at least four columns: assets initially affected, assets frozen, assets returned by the attacker and assets supplied from another source. Add a fifth column for distributions to users. A project can truthfully report large frozen or replenished quantities while the distribution column remains incomplete. If the source publishes only a dollar estimate, record its publication date and avoid updating the figure with today's price.

For restoration, list functions instead of writing “back online.” Deposits, withdrawals, swaps, borrowing, liquidations, claims and the front end can resume at different times. Include the contract or version where available. A service running through a new contract does not reactivate an old contract; users need to know which address and route the project now supports.

Finally, keep a visible cutoff. Security investigations, legal actions and recovery programs can continue for years. This article's cutoff is 23 August 2026. A reader viewing the page later should know that “ongoing” describes the sourced status at that cutoff rather than an assertion about the present. The companion tool uses the same boundary and links each card to the project record so a current check begins at the source.

How to read a live incident update without guessing

Start with the affected object

Copy the nouns exactly. Is the affected object one wallet, one market, a bridge, a package version, a front end, a validator set, an account database or every product? “Infrastructure” is too broad unless the notice defines it. A provider may operate many wallets and chains with different key systems.

Also identify the asset representation. Native ETH, wrapped ETH on another chain and a fund share that tracks ETH are different objects. A bridge backing failure can affect the wrapped representation without changing Ethereum's ledger. A token price can react broadly even when the technical scope is narrow.

Separate confirmed facts from working hypotheses

Early updates should be timestamped and treated as provisional. “We believe,” “preliminary,” “appears limited to” and “under investigation” tell the reader that the boundary can move. A later forensic report can attribute a compromise to an employee account, developer device or third-party system after the first notice described only an unauthorized transaction.

Do not turn an on-chain label into identity. Analytics firms can cluster addresses and authorities can attribute campaigns, but attribution needs evidence beyond a familiar laundering pattern. If a project says a particular group is responsible, note whether that is its own assessment, a named investigator's assessment or an authority's finding.

Find the next action and its audience

A useful action is scoped. “Do not interact with affected decentralized applications until further notice” is different from “move all assets.” Developers may need to update a package while users revoke approvals. Liquidity providers may wait for a balance-reconstruction process while ordinary token holders need no action.

Urgency should attach to a verified path. Before revoking or migrating, reach the official notice independently. Attackers commonly buy promoted search results, reply under incident posts and send fake compensation forms. A legitimate incident creates a large audience already expecting unusual instructions.

Ask what evidence supports restoration

Restoration evidence can include a patched commit, audit report, new contract address, governance vote, network restart time, proof-of-reserves report or public balance checker. Each proves something different. An audit evaluates stated code and scope; it does not certify the project's balance sheet. Proof of reserves addresses assets and liabilities under a methodology; it does not test every operational control.

The strongest update names limitations. It says which pools remain paused, which balances are excluded, whether an old contract is deprecated, and when the next report will appear. A general “all systems normal” message is less informative than a table of services with explicit states.

Track recovery in native units

Dollar loss estimates can change while the attacker holds the same tokens. Record the asset and quantity where the project publishes them, then record the valuation basis separately. If a project says $200 million was lost and $240 million returned after prices rose, that does not necessarily imply more token units came back than left.

Distinguish returned, frozen, replenished and reimbursed. Returned assets move back from attacker control. Frozen assets are restricted but may still require legal or governance action. Replenished assets come from a sponsor or provider. Reimbursed users receive value under a compensation plan. A single recovery percentage can obscure these routes.

Why similar losses can produce different outcomes

Architecture determines what can be stopped

An upgradeable contract can be paused or replaced if administrators retain that authority. A validator set may refuse specified transactions. A centralized exchange can move reserves and keep an internal ledger operating. An immutable contract without emergency controls cannot be patched in place. These differences shape containment speed and the trade-off between decentralization and emergency intervention.

A freeze is not costless. Validator-level intervention can preserve recoverable value while raising governance questions about transaction neutrality. Administrative pausing can stop a drain while creating reliance on key holders. The incident report should document who exercised the control and under which rule.

Balance-sheet capacity determines who can absorb a loss

Wormhole's backing was replenished. Ronin said users were made whole through a refill and restructuring. Bybit reported that customer assets remained backed after replacing the reserve gap. A smaller protocol may rely on treasury funds, token governance, outside financing or future revenue. The technical severity can be similar while the economic capacity differs dramatically.

Users should not assume a future sponsor will appear because it happened before. A promise to cover losses needs a funding source, legal obligation and execution plan. “Committed” is not the same stage as “distributed.”

Attacker behavior changes the recovery path

Euler's negotiated return is not a default outcome. Some attackers engage through on-chain messages; others launder quickly, lose funds to other actors or face sanctions constraints. A bounty can create an incentive but does not guarantee compliance. Projects may keep negotiation details private because public disclosure could weaken recovery efforts.

This creates a communication tension. Users need enough information to protect themselves, while investigators may withhold tactics. A limited statement is not proof that no work is happening, but it should still provide status, scope and a time for the next update.

Composability spreads effects beyond the exploited contract

DeFi positions are often used as collateral, treasury assets or liquidity in other protocols. An exploit can cause bad debt, depegs, liquidations or paused integrations elsewhere. The direct loss and downstream exposure should be counted separately to avoid double counting.

For users, this means checking dependencies. If a vault deposits into an affected lending market, the vault can be exposed even though the user never visited the lending protocol. If a stablecoin holds an affected asset, its own redemption position matters. A protocol status page may not describe every integration.

A user response plan that does not depend on rumors

1. Stop new interaction with the named component. Do not sign, bridge, deposit or approve until the official source clarifies scope.
2. Preserve evidence. Save transaction hashes, account records, balances, timestamps and the exact interface used. Do not share seed phrases or private keys.
3. Check whether exposure is active. A malicious token approval, compromised session or leaked key can remain dangerous after a website is fixed.
4. Use an independently reached official channel. Type the known domain or use a previously saved bookmark. Do not follow compensation links from replies or direct messages.
5. Read the requested action literally. Developers, liquidity providers, exchange users and hardware-wallet users may receive different instructions.
6. Test migrations with a small amount. Confirm the destination contract and network before moving a full balance.
7. Track the four states. Write down detected, contained, restored and recovered with a source and timestamp for each.
8. Recheck after the post-mortem. The root cause and affected versions can change from the initial notice.

If your seed phrase or private key was exposed, revoking approvals is insufficient. Assets should move to a new wallet created from uncompromised material, following trusted wallet guidance. If only a token allowance was malicious, a verified revoke transaction may address that permission without changing the seed. Do not guess which case applies.

For a centralized exchange incident, focus on withdrawals, customer-asset backing, the affected wallet and the legal entity serving the account. A cold-wallet theft does not automatically mean the internal ledger is insolvent, and continued withdrawals do not by themselves prove full backing. Both operational evidence and balance evidence matter.

For a DeFi incident, identify the contract holding the position and whether it is upgradeable or paused. A front end can say a balance is unavailable while the position still exists on-chain; conversely, a displayed balance can be stale after a pool drain. Use the official recovery interface only after its contract is published and independently verified.

The second incident: fake support and recovery scams

Security incidents create perfect social-engineering conditions. Users are anxious, expect unusual announcements and may believe they must act before a deadline. Scammers impersonate moderators, publish fake revoke tools, offer to “validate” wallets and send forms that request seed phrases.

No legitimate recovery requires a seed phrase or private key. A wallet connection can still be dangerous even without those secrets because it can request approvals or signatures. Read the transaction on the wallet display. If the display cannot explain the action, stop.

Look for domain substitutions, extra hyphens, different top-level domains and promoted search ads. An official social account can itself be compromised, so corroborate high-impact instructions on the project's established website, status page, governance forum or repository. A message repeated by many new accounts is not independent confirmation.

Claims services can also outlive the immediate event. Bookmark the authentic claim page from an official announcement and check whether it has a deadline. Fraudsters may copy a real compensation design after the authentic window closes. Never pay an upfront “unlock,” “gas verification” or tax fee to an unknown recovery agent.

Questions readers ask after a crypto incident

Does “exploit fixed” mean it is safe to use again?

Not necessarily. The vulnerable path may be patched while balances, integrations or old approvals remain unresolved. Wait for an explicit restoration notice naming the service, version or contract you intend to use.

Does a hardware wallet protect against every incident?

No. It can protect private keys from leaving the device, but it cannot make an authorized transaction harmless. A compromised front end can ask a user to sign a malicious approval or contract change. Trusted-display review and clear signing remain important.

Why can a multisig fail if several people must approve?

Several keys improve security only if the signers and their verification paths are sufficiently independent. Shared compromised software, deceived displays or compromised devices can cause several valid signers to approve the same malicious action.

Are frozen funds recovered?

No. Frozen means movement has been restricted. Returning the funds may require issuer cooperation, validator action, court process, governance or a signed transaction. Record frozen and returned as separate quantities.

Can an audit guarantee a protocol will not be exploited?

No. An audit examines a defined code version and scope using available time and methods. Later upgrades, dependencies, operational processes and untested economic states can introduce risk. Audits are useful evidence, not a guarantee.

Why not rank incidents only by dollar loss?

Dollar values change with token prices and do not describe scope, user outcome or failure mode. A smaller supply-chain compromise can expose many applications. A large theft can be fully absorbed. Native token quantities, affected users and recovery route add necessary context.

Is this timeline complete?

No. It is a selected set of eight events chosen to teach distinct reading patterns. The dataset cutoff is 23 August 2026. Use the linked first-party reports for these events and current official channels for any new incident.