June 2026 Protocol -
Engineering Recap

Humanity Protocol – ~$32M-$36M Bridge Multisig / Private-Key Compromise (June 8, 2026)

On June 8, 2026, Humanity Protocol lost roughly $32M-$36M worth of its $H token across Ethereum and BNB Smart Chain (BSC) in an operational-security failure rather than a smart-contract code bug (CoinDesk’s initial June 9 report cited “$32M+” with losses still climbing; Halborn, Decrypt and later coverage settled on ~$36M). Malware on a Humanity Foundation developer’s laptop gained root access and exfiltrated seven private keys: one hot-wallet key plus two full sets of Safe/Gnosis multisig owner keys — three owner keys for the Ethereum bridge Safe and three for the BSC bridge Safe. These keys had been accidentally backed up onto that single machine during the June 2025 mainnet launch, so the supposed 3-of-6 (Ethereum) and 3-of-5 (BSC) multisigs effectively lived on one device, meaning a single host compromise crossed the approval threshold on both chains. Using the stolen keys, the attacker drained the hot wallet (~6.05M H), then on Ethereum took over the bridge ProxyAdmin, transferred ownership, and pushed a malicious bridge-contract implementation upgrade that drained ~141M H in one transaction; on BSC the attacker seized ProxyAdmin control and deployed an unlimited-mint implementation, minting an estimated 200-300M unauthorized H. In total roughly 447M $H was stolen or fraudulently minted, and the proceeds were swapped to ETH and dumped on DEXs. Quantstamp responders linked the tooling to North Korea (DPRK)-associated groups, while ZachXBT publicly flagged the event as “possibly staged,” leaving attribution contested; the reported initial delivery vector was a spear-phishing lure impersonating exchange Bithumb.

How it could have been avoided: the core failure was co-locating every Safe owner key on one internet-connected laptop, so the primary fix is true multisig key segregation — each owner key must live on a separate person AND a separate hardware device (hardware wallet, HSM, or air-gapped signer), never exported to the filesystem, never backed up as plaintext or keystore files, and never generated on a networked machine. Signing keys for privileged bridge and ProxyAdmin operations should be hardware-bound (e.g., Ledger/Trezor, or MPC with per-participant TEEs) so root-level malware cannot exfiltrate raw private keys in the first place. Because the attacker’s payload was an instant, single-transaction ProxyAdmin upgrade, moving the upgrade/bridge-admin authority behind a timelock would have delayed the malicious implementation long enough to detect and pause it. Signers should also be geographically and organizationally distributed so no single compromised host can meet threshold on either chain, and any keys ever touched by an internet-connected machine — especially during a mainnet launch — must be rotated, destroyed, and explicitly audited for stray backups afterward. Finally, dedicated, monitored signing workstations with endpoint hardening and phishing-resistant FIDO2 authentication would blunt the spear-phishing entry vector. Any one of key segregation, hardware-bound signing, or a timelock on the upgrade path would have blocked this attack.

Sources: Humanity’s $36 million exploit happened because a ‘multisig’ lived on one laptop (CoinDesk), Explained: The Humanity Protocol Hack (June 2026) (Halborn), Humanity Protocol says compromised admin keys led to $36M exploit (crypto.news)

Syscoin Bridge – ~$8M-$10M Cross-Chain Proof-Validation Exploit (June 7, 2026)

On June 7, 2026, the Syscoin cross-chain bridge that connects the network’s UTXO layer to its NEVM (EVM) layer was exploited, allowing an attacker to mint roughly 5 billion unauthorized SYS on the UTXO side with no corresponding burn on the NEVM side. Estimates of the fiat value range from about $8M to $10M, since sources price the same ~5 billion SYS at different points: Rekt.news and Halborn anchor ~$8.56M using the June 7 close of $0.00171/SYS, while several outlets cite ~$10M at intraday value and DefiLlama-style trackers record ~$8M; the invariant across reports is ~5 billion SYS, or roughly 85% of circulating supply and about 568% inflation. The root cause was an implementation-level flaw, not a cryptographic break: the bridge mints SYS on the UTXO side only against a proof of a corresponding burn/lock on the NEVM side, and the attacker submitted a malformed SPV/transaction proof deliberately structured so the relay’s parser misread it as valid. The malformed payload exploited a cross-layer interpretation mismatch between Syscoin Core and the NEVM relay, involving ambiguous or duplicate asset commitments targeting the same output, so the parser inferred validity for a NEVM burn that never occurred. The relay accepted this invalid proof and authorized an unbacked mint, without any private-key compromise. This places the incident in the same vulnerability class as the 2022 Nomad bridge hack, where an invalid proof was accepted as valid.

How it could have been avoided: the mint path should have enforced strict, canonical, fail-closed validation of the SPV/burn proof before authorizing any UTXO-side mint. First, canonicalize and length/structure-check the proof payload and reject any ambiguous or duplicate asset commitments targeting the same output, so that Syscoin Core and the NEVM relay parse identical bytes to identical meaning and the cross-layer interpretation mismatch is eliminated at the source. Second, verify that the referenced NEVM burn actually exists and is finalized via Merkle inclusion against a confirmed block header, rather than trusting parser-inferred validity. Third, enforce a strict mint <= verified-burn accounting invariant, backed by a per-epoch mint rate-limit and supply-cap circuit breaker that would have halted an attempted mint of ~85% of circulating supply. Fourth, apply differential fuzzing and property-based testing across the two independent parser implementations (Core versus relay) to detect divergent interpretations of the same proof before deployment, reinforced by an independent audit of the proof-verification logic.

Sources: Syscoin – Rekt News, Explained: The Syscoin Bridge Hack (June 2026) – Halborn, SYS Drops 20% After 5B Unauthorized Tokens Minted in Syscoin Bridge Exploit – CryptoPotato

jaredFromSubway.eth MEV Bot – ~$7.5M (some estimates ~$15M) Counter-MEV Honeypot Drain (June 20, 2026)

On June 20, 2026, the well-known “jaredFromSubway.eth” sandwich/MEV bot on Ethereum was drained of an estimated ~$7.5 million (the most-cited figure from Blockaid, The Block, thirdweb, and others), with some on-chain analyses putting the total value touched closer to ~$15 million. This was not a private-key compromise, phishing, or a bug in the bot’s own contract, but a counter-MEV honeypot that weaponized the bot’s automated approve-per-route logic. Over several weeks the attacker deployed roughly 66 counterfeit token and wrapper contracts plus fabricated liquidity pools that mimicked WETH, USDC, and USDT and appeared as profitable MEV/sandwich routes. Early interactions behaved normally (approve, wrap, swap, unwrap, profit), building trust, but the malicious wrappers embedded a conditional toggle (reported as a getStatus()-style switch) that, on certain blocks, skipped the expected transferFrom and left the granted ERC-20 allowance unconsumed. Across roughly 600 blocks the bot repeatedly re-approved these contracts against its genuine WETH/USDC/USDT holdings (one example being an approval of about 92.16 WETH to an attacker helper contract), accumulating standing dangling allowances. Once enough unconsumed approvals had built up across all ~66 contracts, the attacker fired a single transaction invoking every backdoor at once, sweeping the bot’s real tokens via transferFrom; proceeds were consolidated into thousands of ETH and partly routed through Tornado Cash.

How it could have been avoided: the bot needed strict ERC-20 approval hygiene rather than blind approve-per-route execution. It should grant exact-amount allowances scoped to a single trade instead of unlimited or standing approvals, and immediately zero out each allowance after a route via approve(spender, 0) so no dangling permission can survive an unconsumed transferFrom. Its opportunity-detection logic should enforce counterparty allowlisting – interacting only with known, verified canonical token addresses (real WETH/USDC/USDT) and audited AMM pools/routers, rejecting any contract that merely emits legitimate-looking Transfer/Swap events, which would have excluded all ~66 counterfeit tokens and fake pools. Pre-execution simulation and invariant checks (Blockaid/Forta/OpenZeppelin Defender-style) should verify that each route actually consumes the allowance it was granted and flag routes leaving residual approvals or whose token/pool bytecode is unverified or contains conditional transferFrom-skipping logic. Finally, a residual-approval monitor that alarms on accumulating outstanding allowances would have surfaced the growing dangling-approval exposure well before the single sweep transaction executed.

Sources: The Block – Notorious ‘jaredfromsubway’ MEV bot drained for roughly $7.5 million in counter-MEV honeypot, thirdweb – Jaredfromsubway.eth MEV Bot Exploited for $7.5M: What Builders Need to Know, crypto.news – JaredFromSubway MEV bot gets drained in $7.5m approval trap

Secret Network / Axelar Bridge – ~$4.67M CW20-ICS20 Infinite-Mint Exploit (June 10, 2026)

On June 10, 2026, a modified CW20-ICS20 token contract on Secret Network (Cosmos/IBC) that backed Axelar-wrapped assets was drained for roughly $4.67 million (Cointelegraph rounds to $4.7M) in an infinite-mint exploit. The contract had been reworked from an escrow-based to a mint-based model for the Axelar integration, and in doing so two critical validation checks were commented out in do_ibc_packet_receive: parse_voucher_denom, which verifies a voucher denom’s port/channel trace against the packet’s actual source, and reduce_channel_balance, which caps redemptions at the amount genuinely escrowed on a given channel. As a result the contract minted saTokens based solely on allow-listed denomination names, without checking which IBC channel had actually carried the deposit. Because IBC channel opening is permissionless, the attacker stood up a single-validator counterfeit Cosmos chain (ibc-dev-allowlist-denom-1), opened channel-227 to the vulnerable contract, and self-relayed forged packets carrying approved denominations such as uusdt; a uusdt arriving on the attacker’s channel-227 was indistinguishable from one on Axelar’s legitimate channel-69, so the bridge minted genuine but unbacked saUSDT, saUSDC, saDAI, saWETH, saWBTC, saWBNB and sawstETH (per Common Prefix: saWETH ~$1.537M, saUSDT ~$1.121M, saWBTC ~$1.065M, saUSDC ~$638K, saDAI ~$174K, saWBNB ~$102K, sawstETH ~$38K). The unbacked tokens were then redeemed over the legitimate Axelar channel to release the real escrowed assets, which were bridged through Osmosis to Ethereum and converted to ETH. The attack ran across seven transactions between ~19:01 and 19:20 UTC and went unnoticed for roughly seven days, surfacing around June 17 only when an “insufficient funds” error on a cross-chain transfer exposed the drained account; no external audit had been requested for the integration.

How it could have been avoided: the ICS-20 denomination-trace validation (parse_voucher_denom) and per-channel escrow accounting (reduce_channel_balance) must never be removed or commented out when forking CW20-ICS20 — every inbound packet needs its source port/channel verified against the voucher denom path per the ICS-20 spec before any minting, so a token can only be minted from the exact channel on which it was escrowed. The minting contract should further restrict accepted transfers to a hardcoded allow-list of trusted counterparty channels (e.g. only Axelar’s channel-69) rather than any permissionlessly-opened channel, and cap redemptions at genuinely-escrowed per-channel balances, which alone would have made the attacker’s channel-227 deposits non-mintable. Any security-critical fork that removes core validation checks — especially a change from an escrow model to a mint model — must be re-audited by an external party before deployment. Finally, real-time supply/escrow-invariant monitoring should assert that total minted saTokens always equal total escrowed backing and alert immediately on any divergence, so an infinite-mint cannot sit undetected for a week until a downstream transfer happens to fail.

Sources: Common Prefix — Secret Network CW20-ICS20 Exploit: What Exactly Happened, Secret Network’s Axelar bridge drained for $4.67 million in infinite-mint exploit that went unnoticed for seven days | The Block, Axelar Reports $4.67M Bridge Exploit with Secret Network | ForkLog

Polymarket – ~$3M-$3.1M Frontend Supply-Chain Attack (June 25, 2026)

On June 25, 2026, prediction-market platform Polymarket lost roughly $3M to $3.1M in PUSD (its USDC-backed stablecoin) in a client-side supply-chain attack; early reports put the figure near $2.9M before it rose to around $3.1M, and the proceeds were bridged from Polygon to Ethereum and swapped into approximately 1,893 ETH into a single wallet. The root cause was a compromise of a third-party frontend vendor whose JavaScript dependency was loaded into Polymarket’s website: the attacker injected malicious script that was served to some users directly from the legitimate Polymarket domain. That script silently manipulated the wallet transaction-approval flow, presenting draining transactions as routine market actions so that fewer than roughly 15 users signed them, ultimately emptying PUSD from about 11 wallets on Polygon. Polymarket confirmed that its own servers, backend infrastructure, and smart contracts were not compromised, and the PUSD peg held throughout the incident. The event is distinct from a separate ~$700K Polymarket private-key incident on May 22, 2026, and the platform stated it would reimburse affected users.

How it could have been avoided: because the malicious code entered through a trusted third-party vendor bundle served from Polymarket’s own domain, the primary defenses are integrity controls on frontend assets. Subresource Integrity (SRI) hashes on every third-party / tag would cause the browser to refuse to execute any vendor bundle whose contents were tampered with, and a strict Content-Security-Policy whitelisting only trusted script origins while blocking inline and unexpected script execution would prevent injected code from running. Third-party frontend dependencies should be self-hosted and pinned (version-locked and hash-verified) rather than pulled dynamically from vendor CDNs, with any vendor update gated behind a build-time integrity check and code review. Finally, because the attack succeeded by disguising a fund-draining approval as a routine market action, client-side transaction simulation with human-readable “what will this transaction do” signing prompts would let users detect the drain before signing, and runtime frontend-integrity monitoring should alert on unexpected DOM or script modifications served from the production domain.

Sources: Polymarket customers lose $3 million in supply-chain attack (BleepingComputer), Explained: The Polymarket Hack (June 2026) (Halborn), $3 Million Reportedly Stolen in Polymarket Hack (SecurityWeek)

TesseraDAO (TSR) – ~$2.4M-$2.5M Infinite-Mint / Admin-Key Takeover (June 1, 2026)

On June 1, 2026, TesseraDAO (TSR) on BNB Chain was drained of roughly $2.4M-$2.5M through an infinite-mint and dump enabled by an access-control failure rather than a code bug (usethebitcoin and CryptoTimes cite ~$2.4M; PeckShield, Rekt, and Cryptopolitan cite ~$2.5M, with Rekt reporting $2.49M in stablecoins converted to 1,285.5 ETH plus an additional ~$16,224 swept later). The protocol retained a single privileged admin/owner role with total authority over minting, role assignment, ownership transfer, and the trade() and withdrawal() functions, and this role was never revoked nor gated behind a multisig or timelock. The attacker gained control of this privileged address (an ownership-takeover / compromised-deployer-key scenario) and, in roughly six transactions, reassigned the trader and withdrawer roles to their own wallet, transferred ownership, and called the mint function to create 99,000,000 TSR directly from the zero address into 0x6f2b45B950d1739EF67C76F4106df6d6E84904cB (mint tx at 2026-06-01 11:38:25 UTC). The minted supply was then routed through the protocol’s own trade() function to swap the tokens into ~$2.47M BSC-USD, which was withdrawn and bridged to Ethereum for laundering. On-chain analysts at Rekt and PeckShield emphasized that the exploiter did not find a bug in the code but instead used the protocol’s own privileged functions against it, pointing to an insider/backdoor or key-compromise root cause.

How it could have been avoided: because the root cause was an unrestricted, single-key admin role retaining infinite-mint and ownership-transfer authority, the fix is to eliminate that privileged path rather than patch code. After token distribution is finalized, unrestricted mint capability should be renounced entirely in favor of a fixed or capped supply with no live privileged mint path; where an admin role must persist, every privileged function (mint, role assignment, ownership transfer, trade, and withdraw) should be gated behind a multi-signature wallet plus a timelock so no single key can unilaterally mint or reassign ownership. The token contract should enforce per-transaction and cumulative mint caps, and deployment operations should monitor for owner-role reassignment and large mint events with automated circuit-breakers and pausable logic to halt a drain in progress. Deployer keys should be rotated to a hardware-backed multisig before mainnet launch, and independent audits should explicitly flag any live, non-multisig admin key with infinite-mint or ownership-transfer authority as a critical centralization risk rather than an accepted operational assumption.

Sources: TesseraDAO – Rekt News, PeckShield Says TesseraDAO Exploit Minted 99 Million TSR, Stole 2.5 Million USDT – Bloomingbit, TesseraDAO TSR Token Crashes 99% Following 99M Token Mint Exploit – Crypto Times

SecondFi – ~$2.4M (up to ~$20M at risk) Cardano Wallet Nonce-Derivation Exploit (June 21-23, 2026)

Between June 21 and 23, 2026, SecondFi, a Cardano wallet provider, suffered a cryptographic key-compromise exploit across three separate draining events, with public disclosure on June 23. Attackers drained roughly 16M ADA (approximately $2.4M) from 374 wallet addresses, while the total at-risk exposure was estimated as high as ~$20M / ~129M ADA (a SlowMist figure including NFTs and tokens); of that, ~129M ADA was proactively routed to an independent custodian and secured rather than lost, and the vulnerable-account footprint was reported as high as 3,072 accounts. The root cause was a deterministic nonce-derivation flaw in SecondFi’s proprietary Cardano software signer, which generated the per-signature secret value k with predictable or insufficient randomness. Because Cardano uses Ed25519/EdDSA signatures over the ed25519 curve, a faulty deterministic nonce means that once an affected address publishes even a single on-chain signature, an attacker can algebraically recover the long-term private key from public signature data alone. The defect was strictly in the signer’s nonce-generation code, not in the wallet UI, the seed phrase, or the Cardano protocol itself. Consequently, restoring the recovery phrase into a different wallet provides no mitigation, because it recreates identical addresses whose private keys are already recoverable by anyone observing the chain.

How it could have been avoided: the signer should never have used bespoke nonce-derivation logic; the per-signature value k for Ed25519/EdDSA must be derived exactly as specified, by hashing the private-key prefix concatenated with the message (analogous to RFC 6979 for deterministic ECDSA), so that distinct messages produce uncorrelated nonces and identical private keys are never leaked. In practice this means delegating signing to audited, constant-time cryptographic libraries such as libsodium’s ed25519 or cardano-crypto rather than reimplementing randomness or nonce generation in proprietary code. Before shipping, the signer should have been subjected to cryptographic review and validated against known-answer test vectors, plus duplicate/correlatable-nonce detection that confirms distinct messages never reuse or produce algebraically related k values. Because key rotation is impossible for addresses whose nonce scheme is already compromised, the only remediation once such a defect is deployed is immediate withdrawal of all funds to freshly generated addresses signed by a correct implementation, which is precisely why detection had to happen before, not after, on-chain signatures were published.

Sources: Cardano wallet exploit: SecondFi traces attack to private key flaw, warns users not to restore seed phrases – AMBCrypto, Security Incident Update – FAQ | SecondFi (official knowledge base), SecondFi maps recovery path after $2.4 million Cardano wallet exploit – The Block

Aztec Private Rollup Bridge – ~$2.15M-$2.21M Immutable Escape-Hatch Claim-Proof Drain (June 17, 2026)

On June 17, 2026, an attacker drained the deprecated Aztec Private Rollup Bridge on Ethereum L1 by abusing its emergency escapeHatch(bytes,bytes,bytes) withdrawal path. The on-chain drain (tx 0xab306cd2…, 18:34:47 UTC) removed 1,158 ETH (worth roughly $2.15M) from the bridge’s custody at 0x737901be…; broader reporting places the full loss at approximately $2.15M-$2.21M, with some sources including 150,000 DAI and 0.4696 renBTC and others citing ~$2.16M. The root cause was a claim-proof recipient-binding failure: the circuit and on-chain TurboVerifier did not constrain the withdrawal recipient (outputOwner) to the legitimate note owner, so a proof with an attacker-controlled outputOwner was accepted as valid. The attacker set rollupSize = 0, which the contract interpreted as a single escape-hatch transaction, routing attacker-supplied proof data through processRollupProof() and processDepositsAndWithdrawals() with no ownership check. Because the escape-hatch path treated verifier success alone as authorization and lacked rollup-provider auth, onlyOwner restriction, and recipient signature verification, a fresh EOA was able to specify a 1,158 ETH payout to itself. The contract, deployed as immutable in 2021 and deprecated in 2022, could not be paused or patched, so the residual custody balance was emptied from 1,158.76 ETH to 0.76 ETH. This was the second attack on Aztec infrastructure in three days, contributing to a combined loss of roughly $4M.

How it could have been avoided: the escape-hatch verifier circuit must cryptographically bind the withdrawal recipient to the claim/note owner as a constrained public input, committing to outputOwner and requiring the verifier or contract to enforce that it equals the recorded note owner, so a valid proof alone cannot authorize releasing funds to an arbitrary address. As defense-in-depth at the L1 bridge layer, the contract should perform independent entitlement checks (the withdrawal amount and recipient must match a recorded, un-spent user note) rather than trusting the proof’s embedded outputOwner field, and should reject degenerate inputs such as rollupSize == 0 that bypass rollup-state validation. The escape-hatch path itself needed explicit authorization gates, such as rollup-provider authorization, an onlyOwner restriction, or a user signature over the recipient, instead of treating TurboVerifier success as sufficient authorization to release custody. Finally, given that the contract was deployed immutable, its residual funds should have been fully migrated out and the bridge sunset when it was deprecated in 2022 rather than left live, and any immutable custody contract should have had a guardian pause or maximum-withdrawal rate-limit designed in before deployment.

Sources: Aztec Private Rollup Bridge Escape-Hatch Claim-Proof Drain — DARKNAVY, Aztec Network attacked twice in 3 days – Hacker drains $2.21M in digital assets — AMBCrypto, Aztec Network’s RollupProcessor Exploited for $2.21 Million — Crypto Times

Aztec Connect – ~$2.2M Deprecated ZK-Rollup Settlement-Boundary Exploit (June 14, 2026)

On June 14, 2026, an attacker drained roughly $2.1M-$2.19M (with some outlets reporting up to $2.21M as a cumulative figure) from the immutable, deprecated Aztec Connect RollupProcessorV3 contract (0xff1f2b4adb9df6fc8eafecdcbf96a2b351680455) on Ethereum L1. The root cause was a settlement-boundary bypass: a structural gap between the traversal range of the L1 settlement loop and the commitment range of the ZK proof’s SHA256 public-input hash. The attacker controlled the numRealTxs value directly from calldata (offset ~4516) with no on-chain constraint; while decoded_slots were rounded up to 32 slots for SHA256 precompile compatibility and thus all 32 slots were committed by the ZK proof to the L2 state root, the L1 settlement loop only iterated over the numRealTxs-declared slots (effectively 1), leaving slots 2-32 (31 slots) committed to L2 state but never subjected to L1 settlement verification. Forged deposit operations (proofId=1) were inserted into these unverified gap slots while the visible real slot held only no-ops. Across 14 processRollup() calls in two phases (7 calls minting ~217 unbacked forged deposit entries into L2 without decrementing the L1 pool, then 7 calls withdrawing the inflated L2 balances as legitimate L1 assets), the attacker drained ETH, DAI, wstETH, LUSD, yvDAI, yvWETH, and yvLUSD. Funds moved through intermediate contract 0x06f585…d0fcD to EOA 0x0F18D8b44a740272f0be4d08338d2b165b7EdD17.

How it could have been avoided: The L1 contract had to enforce that the set of transaction slots settled on L1 is identical to the set committed by the ZK proof’s public-input hash, rather than deriving the settlement loop bound from an attacker-supplied numRealTxs calldata field. Concretely: (1) never let a caller-supplied count (numRealTxs) determine the L1 settlement iteration range independently of the value bound inside the SNARK public inputs — derive the loop bound from the proof-committed value; (2) prove inside the circuit that the padding slots added purely for SHA256 precompile alignment (slots beyond real txs) are no-ops / zero-value deposit operations, so committed-but-unsettled gap slots cannot carry value-bearing deposits; and (3) add on-chain secondary verification asserting decoded_slots == numRealTxs (or that gap slots are empty) before minting any L2 balances. Because the RollupProcessor was immutable and deprecated, an additional mitigation would have been to withdraw or migrate the remaining L1 pool liquidity out of the abandoned contract after Aztec Connect’s shutdown, rather than leaving user funds in a frozen, unpatchable contract exposed to exactly this class of latent settlement flaw.

Sources: Analysis of the $2.19 Million Asset Theft from Aztec Connect: ZK-Rollup Settlement Boundary Bypass (SlowMist), Explained: The Aztec Connect Hack (June 2026) – Halborn, SlowMist Details Root Cause of $2.19M Aztec Connect Exploit – CryptoTimes

Taiko Bridge – ~$1.7M SGX Proof-Forgery Exploit via Leaked Raiko Signing Key (June 21, 2026)

On June 21, 2026, an attacker drained approximately $1.7 million from Taiko’s Ethereum Layer 2 bridge by forging cryptographic proofs that the L1 verifier accepted as valid L2 state transitions. The root cause was an RSA-3072 Intel SGX enclave signing key for Raiko, Taiko’s multi-prover/SGX proving stack, that had been committed as a file (reported as enclave-key.pem) to the public taikoxyz/raiko GitHub repository. Raiko’s SGX enclaves normally produce attestations that Taiko’s L1 bridge/verifier contracts trust as proof of valid L2 execution; with the private key public, the attacker enrolled their own SGX prover and signed fraudulent state attestations and withdrawal proofs. This let them register fake cross-chain bridge messages and submit L1 withdrawal requests that had no matching MessageSent events or deposits on Taiko L2, draining the L1 Bridge (ETH) and the ERC20Vault (stablecoins, WETH, WBTC, and other assets); roughly $170,000 of the total was around 2 million TAIKO tokens the attacker moved, some to MEXC, before the freeze. Blockaid flagged the attack in real time and BlockSec traced the root cause to the leaked Raiko signing key. Taiko activated its Security Council multisig to pause withdrawals and halt block production on June 21-22 and pledged to reimburse affected users from the treasury. Reported figures cluster at roughly $1.7 million, with some headlines characterizing it as “nearly $2M.”

How it could have been avoided: The private enclave signing key should never have been in source control. Concretely: (1) keep enclave signing keys out of git entirely, storing them in an HSM or secrets manager (AWS KMS/CloudHSM, HashiCorp Vault) and injecting them into the enclave at runtime; (2) enforce pre-commit and CI secret scanning (gitleaks, trufflehog, GitHub secret scanning with push protection) to block *.pem and private-key patterns from ever being pushed; (3) design the on-chain verifier to trust a specific measured enclave identity (MRENCLAVE/MRSIGNER) plus an on-chain allowlist of registered provers behind governance-gated enrollment, and require an M-of-N quorum from the multi-prover set rather than accepting any single SGX attestation, so one leaked key cannot unilaterally forge accepted proofs; (4) rotate and revoke the compromised key immediately and require fresh Intel remote attestation for prover enrollment; and (5) add L1-side sanity checks such as per-epoch withdrawal caps, deposit/withdrawal reconciliation, and circuit-breaker rate limits so forged withdrawals with no matching deposits are throttled and flagged before a large drain completes.

Sources: Taiko Bridge Exploit: How a Leaked Key Drained $1.7M from an Ethereum L2 (thirdweb), Taiko halts its Ethereum layer-2 network after a bridge exploit, token dives 10% (CoinDesk), Taiko Bridge Drained $1.7M After SGX Signing Key Left Exposed on GitHub (The Defiant)

Top Token (TOP) – ~$1.58M Aragon DAO Governance Takeover (June 9, 2026)

On June 9, 2026, an attacker seized control of the Token of Power (TOP) Aragon DAO on Ethereum and drained 944.2 WETH (~$1.58M-$1.59M gross; some outlets round to $1.6M) from the TOP/WETH Balancer V1 BPool. The root cause was a governance misconfiguration rather than any contract-code bug: TOP was an Aragon MiniMeToken with an extremely small total supply of only 16,384 tokens and no timelock or execution delay between proposal approval and execution. Using funds sourced from Tornado Cash, the attacker acquired 8,192.000001 TOP, just over 50% of supply and enough to clear the DAO’s majority-voting threshold. Because there was no execution delay, the attacker created, voted on, and executed a malicious proposal in a single atomic transaction, calling the Aragon TokenManager mint function to issue roughly 10 billion new, unbacked TOP directly to an attacker-controlled contract. Those tokens were then swapped into the Balancer pool to extract the 944.2 WETH, after which proceeds were laundered back through Tornado Cash. Balancer itself was not at fault; the pool simply priced and honored the flood of newly minted governance tokens. BlockSec estimates net attacker profit at ~282 WETH after the ~662 WETH spent acquiring majority control, while the headline gross drain remains ~$1.58M.

How it could have been avoided: The decisive fix is a governance timelock or execution delay enforced between proposal approval and execution, so a proposal cannot be created, voted, and executed in one transaction and honest holders or guardians have a window to detect and veto a malicious mint. Beyond the delay, the token economics that made the attack cheap should be addressed: avoid a tiny fixed supply (here just 16,384 tokens) that makes a >50% stake trivially purchasable, and instead use a larger, more distributed supply or delegated/quorum governance with a high approval threshold plus a mandatory voting period so a flash acquisition of majority stake cannot instantly seize control. The TokenManager mint permission should be removed from ordinary governance proposals or gated behind a separate multisig/guardian, and any mint that remains reachable should be capped or rate-limited so unbounded issuance of ~10 billion tokens is impossible. Finally, monitoring pool liquidity ratios and voting-supply concentration (especially mixer-origin holdings accumulating against total voting power) can trigger circuit breakers or alerts before an unbacked-token dump reaches the Balancer pool.

Sources: Governance takeover lets attacker mint 10B TOP tokens in $1.5m exploit – AMBCrypto, The TOP Takeover: Tornado Cash’s Latest Chapter – TRM Labs, One Vote, $1.58M Gone: TOP Token Hit by Alleged Governance Attack – Crypto Times

Raydium (Legacy AMM V3) – ~$1.3M-$1.34M Fake LP Mint Exploit (June 10, 2026)

On June 10, 2026, an attacker drained roughly $1.3M-$1.34M (sources agree on ~$1.34M; crypto.news and CCN round to ~$1.3M) from five dormant legacy pools on Raydium’s deprecated AMM V3 program on Solana, with proceeds later bridged from Solana to Ethereum. The affected pools were Sollet USDT-RAY, Sollet ETH-RAY, SRM-RAY, USDC-RAY, and RAY-SOL, and the drained assets totaled roughly 150,177 RAY, 5,603 SOL, and 893,700 USDC. The root cause was missing account validation in the legacy remove-liquidity (withdraw) instruction: it did not assert that the caller-supplied LP mint matched the pool’s canonical LP mint (no require_keys_eq!(accounts.lp_mint.key(), amm.lp_mint)) nor that the user’s LP token account belonged to the legitimate pool mint. Because the withdrawal payout was computed as coin_amount = (vault_balance x withdraw_amount) / lp_mint.supply, the attacker-controlled fake mint’s supply became the denominator. The attacker created a fake SPL mint with zero decimals and a total supply of exactly 1, then called withdraw with withdraw_amount = 1, which made the calculation resolve to vault_balance / 1 and treated them as a ~100% LP shareholder, releasing nearly the entire vault while burning only the single fake token. The attack was repeated across the five dormant pools; no live pools or admin keys were compromised.

How it could have been avoided: the remove-liquidity instruction should have derived the canonical LP mint and vault accounts directly from on-chain pool state and rejected any caller-supplied substitutes, asserting require_keys_eq!(accounts.lp_mint.key(), amm.lp_mint) and verifying that the user’s LP token account mint equals the pool’s LP mint before any vault transfer occurs. Since the payout denominator was the LP mint supply, binding the mint to the pool’s authentic mint would have prevented an attacker-controlled fake mint (supply = 1) from ever being used as the divisor. The program should additionally validate vault ownership, vault mints, PDA/authority derivations, and token-program identity, and ship regression tests asserting that withdrawal fails when a fake mint with supply = 1 is supplied. Most fundamentally, deprecated and retired program IDs like this legacy AMM V3 should have been formally closed, upgrade-frozen, or had their instructions disabled so dormant legacy code paths could not be invoked at all.

Sources: Raydium Legacy Remove-Liquidity LP Mint Validation Bypass (DARKNAVY technical writeup), Raydium Suffers $1.34M Exploit via Fake LP Tokens (CryptoNews), Raydium promises full refund after $1.3M Solana pool exploit (crypto.news)

LABUBI / OLPC – ~$1.1M PancakeSwap Reserve-Desync Exploit (June 20, 2026)

On June 20, 2026, the PancakeSwap V2 OLPC/LABUBU pool on BNB Chain (BSC) was drained for roughly $1.1M (reported as ~1,115,903 USDT, with the attacker’s net profit cited at ~$960K). The exploit was a pre-armed malicious-tokenomics time bomb rather than a spontaneous coding error: approximately 46 days earlier, the OLPC token owner had set an internal parameter (reported as decimalsValue) from its normal value of 1 to an enormous 7326680472586200649, then renounced ownership to a dead address so the change could never be undone. That value silently amplified the burn logic inside OLPC’s _update() transfer hook, so when the attacker pushed a tiny OLPC transfer (~10 OLPC) through a malicious contract, it triggered an abnormal burn of ~51.9M OLPC and ~124,000 LABUBU directly out of the PancakeSwap pair’s balance. Because those tokens left the pair without a corresponding reserve update, the pair’s cached reserve0/reserve1 no longer matched its actual on-chain balances, leaving LABUBU severely mispriced. The attacker then swapped against the stale reserves to extract LABUBU cheaply, routing proceeds through LABUBU/WBNB and WBNB/USDT pairs; per PeckShield, AMBCrypto, and KuCoin the funds were subsequently bridged to Ethereum and ~633.4 ETH deposited into Tornado Cash (Crypto Times reported no laundering observed as of its initial writing, a reporting-timing difference rather than a disagreement on the amount).

How it could have been avoided: The core failure is that a fee-on-transfer / burn-on-transfer token with a mutable, owner-controlled multiplier was paired against a PancakeSwap-style constant-product pool, which assumes token balances only change through mint/burn/swap/skim/sync and therefore desyncs by design when a transfer hook silently removes tokens from the pair. First, the OLPC contract should never have exposed an owner-settable decimalsValue with an effectively unbounded range feeding directly into _update() burn math; a bounded/immutable parameter with strict input validation and sane upper limits would have made it impossible for a renounce to permanently arm a burn multiplier. Second, LPs, routers, and listing integrators should refuse liquidity for tokens whose transfer hooks can mutate balances, and specifically treat “ownership renounced immediately after a suspicious privileged parameter write” as a red flag rather than the trust signal renouncement is usually taken to be. Third, pre-listing static analysis should flag privileged setters and transfer-hook burn logic so latent time bombs surface before a pool accumulates meaningful TVL. Finally, runtime monitoring should continuously compare each pair’s cached reserves against its real token balances and automatically halt routing or delist when they diverge, which would have caught this pool the moment the 51.9M-OLPC burn broke the invariant, before the drain swap could execute.

Sources: BnbLabubu exploit drains $1.1mln after OLPC reserve mismatch – AMBCrypto, PancakeSwap Labubu Pool Exploited for $1.1M: What Went Wrong – Crypto Times, PeckShield: PancakeSwap OLPC/LABUBU Pool on BNB Chain Hacked, ~$1.1M taken and ETH sent to Tornado Cash – BingX