Taiko, an Ethereum Layer 2 network, halted all block production and urged every user to withdraw funds from its bridges on Monday after an attacker drained approximately $1.7 million from its L1 Bridge and ERC-20 Vault contracts. The root cause was not a flaw in any smart contract — it was a cryptographic signing key for Taiko’s hardware-based prover system that had been committed to a public GitHub repository. BlockSec Phalcon, the blockchain security firm that traced the breach within hours, said the exposed key may have broken the entire trust model underlying Taiko’s bridge. The TAIKO governance token fell about 10% on the news, with CoinGecko data showing it trading near $0.07 — close to its all-time low.
What the Attacker Found in a Public Repo
The key that enabled the attack was an RSA-3072 private key used to sign Intel Software Guard Extensions (SGX) enclaves inside Raiko, Taiko’s multi-prover stack. It had been committed to the publicly accessible taikoxyz/raiko repository on GitHub — visible to anyone who knew where to look.
Intel SGX is the company’s Trusted Execution Environment technology, built into server-class CPUs to create encrypted, isolated memory regions called enclaves. The entire premise of an SGX-based security system is that signing keys never leave the secure hardware. Once one does, the architecture’s guarantees collapse entirely: an attacker who holds the signing key can present their own hardware as a legitimate, certified participant in the network.
Taiko’s L1 bridge contracts verify enclave authenticity using a field called MrSigner — a hash derived from the public portion of the signing key. Any enclave whose signature matches the stored MrSigner value is accepted as genuine. With the private key in hand, the attacker enrolled their own SGX prover instances as if they were legitimate participants in the Taiko prover network.
How Forged Proofs Become Stolen Funds
Security analysis from QuillAudits and BlockSec Phalcon reconstructed the two-phase attack sequence in detail.
In the first phase, the attacker used their fraudulently registered enclave to generate fake Layer 2 state attestations — cryptographic proofs claiming to describe valid transaction history on the Taiko chain. These forged attestations enabled calls to the processMessage() function on the L1 bridge contracts, which set withdrawal statuses to RETRIABLE for transactions that had never legitimately occurred on Taiko.
In the second phase, the retryMessage() function executed against those fraudulently elevated statuses with minimal additional checks, releasing real assets from both the bridge and the ERC-20 Vault on Ethereum mainnet. The result was a sequence of withdrawal authorizations backed by nothing — fake L2 deposits accepted on Ethereum as genuine, with no corresponding on-chain activity on the Taiko side.
A Mandatory Prover With One Whitelisted Key
What made this operational security failure so damaging was an architectural reality that the attack exposed: Taiko required SGX proof for every single batch of transactions. Per L2Beat’s technical registry, the protocol mandates SGX (Geth) alongside at least one other proof system for every proposal range, and at the time of the exploit, proving was controlled by a ProverWhitelist with just one registered prover.
That design — a mandatory TEE component with a single whitelisted key holder — created a network-wide single point of failure. Unlike a system where SGX serves as an optional fallback, Taiko’s architecture meant that a compromise of that one prover’s key material was sufficient to forge valid-looking attestations for the entire bridge verification stack. Smart contract auditors cannot catch this class of risk. OpenZeppelin conducted three comprehensive audits of the Taiko protocol across multiple versions, identifying 113 issues including 13 critical and high vulnerabilities — all resolved before deployment. None of that work covered the operational security of key material managed in the team’s developer pipeline.
Taiko’s Response: Network Halt and Legal Action
The Taiko team posted a security notice to X at approximately 8:44 p.m. ET on Sunday, advising all users to immediately withdraw funds from every bridge deployed on the network. The team asked centralized exchanges to suspend TAIKO deposits and directed all block proposers to stop producing new blocks while the investigation continued.
By 2:00 a.m. ET on Monday, the team confirmed the exploit was fully contained. Withdrawals through the main bridge and token vault had been halted; pending transactions were paused rather than lost. Before the freeze took hold, the attacker had already moved approximately 2 million TAIKO tokens — worth roughly $170,000 — to an account on the MEXC exchange. Taiko published a list of attacker addresses and said it was pursuing both technical and legal responses. The project’s Security Council, a multisig governance body, was activated to coordinate the containment.
Thirdweb, in a technical post-mortem published Monday, called it “a textbook example of why key management is one of the most critical operational security challenges in blockchain infrastructure.” A monitoring tool called Blockaid helped the team detect the attack early enough to limit total losses, according to Thirdweb’s analysis.
DeFi Bridges: $340M Lost in 2026, Same Flaw Repeating
The $1.7 million loss is small relative to 2026’s broader bridge-exploit record, but it fits a pattern that is becoming one of the defining security crises in decentralized finance. According to CoinDesk, bridges produced more than $340 million in losses across at least 14 exploits in 2026 alone — making cross-chain infrastructure the highest-value attack target in crypto this year.
The class of vulnerability is consistent across incidents: an attacker finds a mechanism to make the destination chain believe a withdrawal is legitimate when no corresponding deposit ever occurred on the source chain. In April 2026, a forged LayerZero message drained $292 million from Kelp DAO’s bridge in what became the largest DeFi exploit of the year. In May, a forged transfer drained $11.5 million from the Verus-Ethereum bridge.
What distinguishes the Taiko attack is the entry point. The Kelp DAO and Verus incidents involved flaws in cross-chain messaging verification or bridge configuration. Taiko’s breach began one step earlier — with a private key that never should have been in a version-controlled file in the first place. That distinction matters for developers building on TEE-assisted proving systems: the attack surface includes not just the code, but every secret that code depends on.
What TEE-Assisted Proving Means for Other L2 Networks
Taiko, which launched its mainnet in May 2024, was one of the first Ethereum L2 networks to deploy as a “based rollup” — a design that relies on Ethereum’s own validators for transaction sequencing rather than a centralized sequencer, co-founded by former Loopring CEO Daniel Wang. Its multi-prover system, which combines Intel SGX with zero-knowledge proof systems including SP1 and RISC0, was intended as a defense-in-depth approach: an attacker would need to defeat two independent proof systems simultaneously to compromise the network.
That design has theoretical merit. But Monday’s exploit demonstrated that hardware-based proving introduces an operational security risk that is categorically different from software vulnerabilities. Trusted Execution Environments like SGX offer powerful cryptographic guarantees — but only when key material never escapes the secure hardware boundary. A private key committed to a public git repository is as compromised as if it had been posted on a forum. The two-proof requirement provides no protection when both proofs can be forged with the same leaked key.
As TEE-assisted proving gains traction across the broader zero-knowledge and optimistic rollup ecosystem, Taiko’s experience is a warning that key management discipline must match the sophistication of the cryptographic design.
Taiko said it is preparing a full post-mortem and asked users not to bridge assets until an official all-clear is issued through its official channels.
Frequently Asked Questions
Is it safe to use the Taiko bridge now?
No, not as of June 22, 2026. Taiko has halted the main bridge and the ERC-20 Vault and has explicitly told users to withdraw funds from all bridges deployed on the network. The team has not issued an all-clear. Do not bridge assets to or from Taiko until an official resumption announcement is made through Taiko’s official channels.
What is an SGX enclave signing key, and why did leaking it break Taiko’s bridge?
Intel SGX (Software Guard Extensions) is a CPU-level security technology that runs sensitive code inside encrypted memory regions called enclaves. The bridge’s L1 contracts authenticate SGX enclaves using a value called MrSigner — a hash derived from the public portion of the signing key. Any enclave whose signature matches that hash is accepted as legitimate. When the RSA-3072 private key was committed to a public GitHub repository, the attacker could use it to generate signatures matching the stored MrSigner value, letting them register their own hardware as a trusted prover and generate fraudulent withdrawal proofs that Taiko’s contracts accepted as valid.
How do crypto bridge exploits work, and why do they keep happening?
Cross-chain bridges work by locking assets on one blockchain and releasing equivalent assets on another, relying on cryptographic proof that a legitimate deposit occurred. Exploits consistently target the proof verification step — finding ways to make the destination chain release funds without a real deposit. According to CoinDesk, more than $340 million was stolen across at least 14 bridge exploits in 2026 alone. The failure modes vary — smart contract bugs, compromised validator keys, misconfigured messaging systems — but the structural weakness is the same: when a bridge trusts a proof it cannot independently verify, an attacker who can forge that proof can drain the reserve.
What can developers building with TEE-based proving systems learn from this?
Key material for SGX enclaves must never appear in source code repositories, build scripts, or any file committed to version control — public or private. Secret scanning tools should be integrated into CI/CD pipelines to catch accidental commits before they reach a repository. For protocols where a TEE component is architecturally mandatory, a single leaked signing key is sufficient to defeat the entire trust model, regardless of how many smart contract audits the protocol has passed. Operational security for key management is not covered by smart contract audits and requires a separate, dedicated review.
