A single file left exposed in a public code repository is now the leading explanation for one of 2026's cleaner-but-costly layer-2 incidents. On June 22, Ethereum L2 Taiko froze its entire network after roughly $1.7 million was drained from its bridge — and the recovery is still in motion.
What Changed: Taiko L2 Blocks Halted, Bridge Drained June 22
Taiko, an Ethereum-equivalent layer-2 rollup, halted block production network-wide on June 22, 2026 after an attacker drained an estimated $1.7 million from its bridge and ERC-20 vault. The activity was reportedly detected and contained between roughly 2:00 and 2:08 a.m. ET, with Blockaid's monitoring system credited for flagging it in real time . The $1.7M figure is press-reported; Taiko has pledged a full incident report but has not yet published an official postmortem .
Taiko moved fast on containment. According to thirdweb's writeup, the team activated its Security Council multisig and locked down the affected surfaces. The standard L2 emergency playbook was visible across reporting from CoinDesk and The Block:
- L1 bridge and ERC-20 vault withdrawals frozen.
- Centralized exchanges asked to suspend TAIKO deposits.
- Attacker addresses published, with a pledged incident report.
- Block production halted chain-wide within minutes of detection.
The market read it as a trust failure, not a treasury wipeout. TAIKO fell about 10% intraday , and before the freeze the attacker reportedly moved roughly 2 million TAIKO — about $170,000 — to a MEXC account . Taiko's own recovery work frames the severity plainly:
"Fixes all the structural issues the exploit caused." — Taiko recovery pull request #21820 (source: taiko-mono GitHub)
Why It Matters: One Public File Broke SGX's Entire Trust Model
The damage traces to a single committed file. Security firm BlockSec, through its Phalcon monitoring arm, identified the likely root cause as an Intel SGX RSA-3072 private signing key for Taiko's Raiko proving stack — left publicly readable as enclave-key.pem in the taikoxyz/raiko GitHub repository, where anyone could copy it . That key is normally sealed inside secure hardware and never leaves it.
Taiko's L1 contracts trusted any SGX enclave matching a stored MrSigner value. With the real key in hand, the attacker registered a forged prover that the on-chain verifier accepted as legitimate . The hardware-backed trust model held — it just trusted the wrong operator.
From there the mechanics were clean:
- The trusted prover signed fake L2 state attestations and withdrawal proofs .
- The attacker then submitted Ethereum withdrawal requests with no matching deposits on Taiko L2.
- The bridge contracts had no way to reject proofs that verified correctly, so the funds left .
Several outlets placed it in the same class of cross-chain proof-forgery flaws blamed for more than $340 million in bridge losses across 14-plus exploits in 2026 . As BlockSec's Phalcon team framed it, this was "the same cross-chain proof-forgery pattern" that has drained bridges all year — a verifier doing exactly what it was told, with a credential it should never have been able to read.
The dollar figure understates the impact. TAIKO's market capitalization sat near $14.5 million at the time of the incident . The roughly $1.7 million drained equals about 11.7% of the token's entire market cap . For a chain whose pitch is decentralized, hardware-verified proving with no central sequencer, the confidence hit lands harder than the loss itself.
Recovery Status: Four Protocol Fixes, Bridge Still Frozen
Taiko's fix arrived as code, not a press release. The central artifact is pull request #21820, "feat(protocol): port hack recovery hooks to v3," opened June 22 at 17:09 UTC against the v3.0.0 protocol and stating it "fixes all the structural issues the exploit caused" . At the inspected snapshot it was still open and unmerged — 7 commits, 15 changed files, 485 additions, 269 deletions — and bundles four recovery measures .
Each measure targets a different part of the forged-proof path:
- Checkpoint versioning (PR #21806): SignalService checkpoints are namespaced by an immutable version, so a single version bump instantly invalidates all stored checkpoints — blocking the attacker's proven state transitions from being replayed without any storage migration .
- Inbox state reset (init2): a one-time
Inbox.init2()restores core chain state to a point before the attack . - Bridge message invalidation (init3): three specific attacker message hashes are marked
DONErather thanNEW, so already-proven malicious messages cannot re-execute as fresh withdrawals after the rollback . - QuotaManager restoration: a rate limiter caps bridge outflows, debiting quota only when funds actually leave the chain .
The quota numbers are the clearest signal of intent. Taiko's deploy script configures a 15-minute quota window with example L2-to-L1 limits near USD 200,000 per period, priced with ETH at USD 3,100 and TKO at USD 5 . That throttle would contain any single-window drain going forward, but it also concedes the original design lacked one.
One caveat matters for readers tracking this live. The GitHub record confirms an exploit and the bridge-withdrawal recovery, yet it does not itself verify the $1.7 million figure, the attacker address, or final losses, and Taiko's public status page still read "All systems operational" at the time checked . Until an official postmortem lands, the four code fixes are the most reliable account of what broke and how Taiko is sealing it.
What to Watch: Postmortem, Bridge Restart, and 2026's Bridge Tally
The next confirmation traders should wait for is the merge of PR #21820, which sat open and unmerged at publication . A bridge restart hinges on three sequential gates — merging that fix, a post-merge audit, and a Security Council sign-off — and Taiko has confirmed no public timeline for any of them.
Treat the headline numbers as provisional. The roughly $1.7 million drained and the published attacker addresses are press-reported, not yet confirmed in a primary postmortem . At the time checked, Taiko's status page still read "All Systems Operational," which does not corroborate the network-halt phrasing .
The broader signal is structural: 2026 bridge exploits have now exceeded $340 million across 14-plus incidents, and Taiko's SGX proof-forgery vector is a distinct attack class from prior oracle-manipulation or multisig-compromise hacks .
Concrete signals to track:
- PR #21820 merge and an official bridge-reopen announcement.
- The incident report — root-cause confirmation and any reimbursement plan.
- TAIKO price and liquidity, with a roughly $14.5 million market cap under sustained pressure .
The takeaway: until the code merges and the postmortem lands, the bridge stays frozen and the dollar figure stays unverified. Watch the repository, not the headlines.
Frequently asked questions
Is my TAIKO token at risk from this exploit?
Your TAIKO tokens held in self-custody or on a centralized exchange were not directly stolen. The attack drained ETH and ERC-20 assets held inside Taiko's bridge contracts — not user wallets. The reported loss was about $1.7 million . TAIKO's price fell roughly 10% on lost confidence in the bridge's trust model, not on direct token theft . The bridge remains frozen pending recovery, so funds bridged through it are temporarily inaccessible.
What is an SGX enclave signing key and how did it end up on GitHub?
An Intel SGX enclave is a hardware-isolated computation environment, and each enclave is identified by a signing key — the value Taiko's contracts track as MrSigner. That key should never leave secure hardware. According to thirdweb and Crypto Times, security firm BlockSec traced the likely root cause to this signing key — reported as an RSA-3072 private key in an enclave-key.pem file — being left publicly accessible in the taikoxyz/raiko repository, downloadable by anyone with a GitHub account . These granular technical details come from secondary coverage, not primary Taiko statements.
How did the attacker forge withdrawal proofs with no real deposits?
Taiko's L1 contracts accepted proofs signed by any SGX enclave whose signing key matched the trusted MrSigner value. With the leaked key in hand, the attacker reportedly registered a malicious prover the on-chain verifier treated as legitimate, signed fake L2 state attestations and withdrawal proofs, then submitted withdrawal requests on Ethereum with no matching deposits on Taiko . The contract had no mechanism to confirm the deposits ever existed on L2, so it released bridge and ERC-20 vault funds against the forged proofs .
When will Taiko's bridge reopen?
There is no official timeline at publication. A reopen depends on recovery pull request #21820 — which bundles checkpoint versioning, an Inbox state reset, bridge-message invalidation, and quota controls — being merged, followed by a post-fix security review and Security Council multisig approval . At the inspected snapshot, that PR was still open and unmerged with 15 changed files . To track progress, monitor the taikoxyz/taiko-mono GitHub repository and Taiko's official Discord and X channels for merge and reopen announcements.
How does Taiko's exploit differ from other 2026 bridge hacks?
Most 2026 bridge losses stemmed from oracle manipulation or multisig key compromise. Taiko's attack instead targeted SGX hardware attestation — a distinct trust model. The proof-forgery path (leaked enclave key → forged prover registration → fake state attestation → fake withdrawal) is an underexplored attack surface in ZK and TEE-based rollup bridges. Several outlets grouped it with the broader pattern of cross-chain proof-forgery flaws that have driven more than $340 million in bridge-related losses across 14-plus exploits in 2026 .
