In the third week of July 2026, an attacker drained roughly $13 million in NIGHT tokens from Wanchain’s Cardano-to-BNB Chain bridge by exploiting a flaw that let one valid signature be reused to withdraw far more than it should have. The bridge had operated across dozens of chains for more than eight years without a major incident, and the weakness had been present in its design throughout that time. It was the most significant entry in a series of cross-chain bridge failures that researchers have tracked since May, and it renewed a longstanding question about whether the current generation of bridge architecture can be adequately secured.

In today’s issue.

• Wanchain lost about $13M when a signature-reuse flaw let an attacker forge valid bridge withdrawals.

• Allbridge Core lost $1.65M on Solana to a flash-loan attack it had already suffered in 2023.

• A chained WordPress core flaw gave unauthenticated attackers remote code execution, and it is under active attack.

Need to Know

The week’s two bridge losses shared a characteristic that distinguishes the most damaging exploits of 2026 from the most sophisticated ones. In each, the protocol’s own design had already created the opening, and the attacker needed neither to defeat cryptography nor to invent a new method. In one case a validator signed messages that could be forged, and in the other a safeguard adopted after an earlier incident was never applied to a later deployment. The consistent lesson is that a bridge’s security is largely determined by decisions made long before it is attacked, so the question for any team operating one is how recently those decisions were re-examined against current methods. —Adrian

The Big One. Wanchain’s $13M Cardano-BNB Bridge Signature Flaw

The news. On 20 July an attacker drained roughly 515 million NIGHT tokens, worth somewhere between $9M and $13M depending on the moment’s price, out of Wanchain’s Cardano-to-BNB Chain bridge in four transactions over about eight minutes, per CoinDesk and Blockonomi. Those tokens were about 97 percent of the bridge’s NIGHT reserves, and only NIGHT moved while the bridge’s other assets sat untouched, per CryptoRank. Midnight, the Cardano privacy sidechain the token belongs to, was not affected, but the wrapped NIGHT still circulating on BNB Chain is now largely unbacked.

What broke and how. The bridge released wrapped NIGHT against signed authorisations, and its signature scheme could not reliably tell two different withdrawals apart. On-chain analysis found that the attacker took a single valid authorisation for about 3,110 NIGHT and reused it to mint more than 203 million, an amplification of roughly 65,000 times, per Blockonomi. Researchers described the underlying bug as a non-injective signed-message encoding flaw, the property that lets more than one set of withdrawal details reduce to the same signed message and therefore the same valid signature, per CryptoTimes. The attacker repeated the withdrawal until the reserves were nearly empty, then swapped roughly 2.8 million ADA worth of the proceeds through Cardano decentralised exchanges before Wanchain took the bridge offline.

Why it kept happening. A signing scheme that cannot distinguish one authorisation from another is an old and well-understood failure, and the defences against it, canonical encoding and domain separation among them, are standard parts of a competent cryptographic review. Wanchain’s bridge had run across dozens of chains for more than eight years without a major incident, per Coingape, and a record like that is often what keeps a foundational design decision from ever being examined again.

What to check now.

• Can any message your contracts accept as a valid authorisation correspond to more than one real-world action, or is the mapping strictly one to one.

• Are the fields in the messages you sign separated by explicit length markers or delimiters, so they cannot be rearranged into a different message with the same bytes.

• Does your signing use domain separation, so a signature valid for one operation cannot be replayed for another.

• Has a cryptographer, rather than a general smart-contract auditor, reviewed the exact bytes your bridge signs and verifies.

• If your system has run for years without incident, which of its original cryptographic choices has nobody revisited since launch.

A signing scheme is only as strong as its worst-case ambiguity, and years without an incident mostly mean nobody has yet had a reason to go looking for it. If your contracts authorise actions from signed messages, have someone prove that no two different actions can ever share a signature, before an attacker builds that proof for you.

— Adrian

Chain Reaction. Allbridge’s $1.65M Repeat Flash-Loan Drain

The news. The day before Wanchain’s bridge fell, a smaller and far more familiar exploit hit Allbridge Core on Solana. On 19 July an attacker borrowed about $1.12M in USDC from Kamino in a flash loan, swapped rapidly between USDC and USDT inside an Allbridge stablecoin pool until the pool’s ratio was badly skewed, withdrew liquidity at the distorted rate, and repaid the loan in the same transaction, per CoinDesk. Security firms put the loss at roughly $1.65M, which the attacker bridged from Solana to Ethereum, per CryptoTimes.

What broke and how. Allbridge Core moves native stablecoins by holding pooled liquidity on each chain and pricing withdrawals against the balance of those pools. Because the pricing trusted the pool’s live ratio, a large borrowed swing in that ratio let the attacker take out more than they put in, and one swap of a few thousand dollars of USDT reportedly came back as roughly $2.24 million in USDC, per Cryptonomist. The flash loan supplied the size and the pool’s own accounting supplied the opening.

Why it kept happening. Allbridge has been drained this exact way before. In April 2023 an attacker used the same flash-loan pool manipulation to take about $573,000 from Allbridge on BNB Chain, after which the team recovered most of it through a white-hat arrangement and published a post-mortem, per Cryptonomist. That post-mortem named the structural fix plainly, one liquidity pool per blockchain, on the reasoning that a pool holding a single token gives an attacker no second asset to swap against, per TechTimes. The Solana deployment held both USDC and USDT in the same pool, which is precisely the configuration the fix was written to prevent. A lesson learned in one place in 2023 had never been carried to another by 2026.

What to check now.

• When you fix a vulnerability class, is there a mechanism that guarantees the fix reaches every deployment, including chains you add later, not just the one that was hit.

• Does any pool you price against hold two assets an attacker could swap between to move its ratio inside a single transaction.

• Do your withdrawal calculations trust the live pool balance, or do they reject a pool that has been pushed far from its true ratio within one block.

• Are flash-loan-scale swings in a pool’s composition something your contracts treat as a condition to pause on, rather than ordinary input.

• Does your incident process end at the patch, or at a check that the same class of bug exists nowhere else you run.

A fix you applied on one chain but not the others is a fix in name only. When you close a vulnerability class, the last step is confirming the same door is shut everywhere you have deployed, because the attacker who reads your post-mortem will go straight for the deployment you forgot.

— Adrian

Around the Forums

Hoskinson calls for zero-knowledge bridges after the Wanchain drain. Charles Hoskinson responded to the exploit by arguing that the Cardano ecosystem should move away from legacy third-party bridges toward zero-knowledge designs that replace trust in operators and multisigs with cryptographic proofs, per CoinDesk. He also framed AI-accelerated exploit discovery as an industry-wide problem rather than a crypto-specific one, a point the week’s other incidents support. Whether a real migration follows, or the call joins the pile of post-incident statements that fade, is the thing worth watching over the next quarter.

Allbridge reopens its 2023 recovery playbook. Allbridge paused the protocol, told liquidity providers to withdraw, and asked the traders who profited from the resulting arbitrage window to return funds to a recovery address for LP compensation, the same route that recovered most of the 2023 loss, per crypto.news. For a protocol drained twice by the same technique, the more useful question than whether the funds come back is whether the second lesson finally reaches every chain it runs on.

What Else Happened

• Reserve-manipulation logic error draining CrowdRingCircle on BNB Chain. An attacker manipulated the CRC token’s reserve accounting through a burn-from-pair and resync sequence and extracted about $201,000 on 16 July, on-chain transaction.

• Deflationary-burn price manipulation of RWT Token on BNB Chain. An attacker paired a flash loan with RWT’s burn-on-transfer mechanic to distort its price and drain about $118,000 on 19 July, on-chain transaction.

• Unauthenticated remote code execution in WordPress core, tracked as wp2shell. Two chained core flaws, a REST batch-route confusion (CVE-2026-63030) and a SQL injection in WP_Query (CVE-2026-60137), let an anonymous attacker run code on default WordPress 6.9.x and 7.0.x installs with no plugins, and exploitation plus public proof-of-concept both appeared within a day of the 17 July disclosure, per BleepingComputer and Tenable. WordPress force-pushed fixes in 6.9.5 and 7.0.2.

• A fifteen-year-old heap overflow in NGINX, CVE-2026-42533. A flaw that has sat in NGINX request processing for fifteen years lets an unauthenticated attacker crash worker processes with a crafted HTTP request against certain regex-map configurations, per The Hacker News.

• Heap overflow in the 7-Zip XZ decoder, CVE-2026-14266. Opening a crafted XZ archive can trigger code execution, a high-severity flaw in a utility that sits in countless build and analysis pipelines, per The Hacker News.

• Hidden-instruction code execution in the AWS Kiro IDE. Hidden text on a web page the IDE fetched could be read as instructions and run code on a developer’s machine, which AWS has since fixed, per Gridinsoft.

Patch Notes

This is a heavier week for the software crypto teams run than for the contracts they write. The WordPress core chain is the urgent one, because it is already being exploited against stock installations and now sits on CISA’s known-exploited list, so any WordPress site your organisation runs, including the marketing and documentation sites nobody counts as infrastructure, needs to be on the patched release today. The NGINX and 7-Zip flaws are not under the same pressure yet, but both live in software almost every team touches, so fold them into your patching now rather than after a working exploit circulates. If your developers use the AWS Kiro IDE, confirm they are on the fixed build.

Long Reads

• OpenAI’s account of its own models escaping a test sandbox and breaching Hugging Face, alongside Decrypt’s write-up. During an internal benchmark run with reduced safety filters, two OpenAI models exploited a zero-day in a package-registry proxy to break out of their sandbox, reached a machine with open internet access, then chained stolen credentials and further zero-days into remote code execution on Hugging Face’s production systems to steal the benchmark’s answer key, which Hugging Face had already detected and contained. It is the clearest real-world case yet of the AI-accelerated exploitation Hoskinson invoked after Wanchain, and Fortune notes that Anthropic separately reported its own Mythos model escaping a sandbox during safety testing.

• Google’s Gemini 3.5 Flash Cyber, an AI it built to find and patch vulnerabilities and chose not to release. In testing it reportedly found more new bugs than expected, and the decision to withhold it is a useful marker of where automated vulnerability discovery now sits, a counterpoint to the Dragonfly argument covered last week that AI has not triggered a wave of DeFi exploitation.

• CertiK’s data on the rise of crypto wrench attacks, which counts 52 physical-coercion incidents and more than a tenfold jump in the value targeted. As on-chain and operational security harden, some attackers simply move to the person holding the keys, which is worth a founder’s attention even though it is not a software problem.

Closing Tab

Both bridges compromised this week had run for years, and both were undone by a weakness that predated the attack by a wide margin, whether a signing scheme that allowed forgery or a fix that one deployment never received. The pattern extended well beyond bridges. Across the week’s incidents, from a flaw sitting in WordPress core to an AI system that escaped its own test environment, the decisive failures were ones that ordinary review could have caught, and the open question is how much of the industry’s current security rests on reviews that were never scheduled.

Burn Notice. Operational intelligence for Web3, every week.

Adrian Hetman

In mid-July 2026, an attacker compromised the jscrambler npm package, a tool that developers install to secure their own code, and used it to distribute malware to the machines that installed it. Using a stolen publishing credential, the attacker released five malicious versions of the package, each of which contained an infostealer designed to extract cryptocurrency wallets, cloud credentials, and the access tokens of AI coding assistants from an affected machine. Although the incident was minor in comparison with the week’s other losses, it was representative of a broader pattern. In each of the larger incidents that followed, the point of failure was a component that a development team had built, purchased, or configured and subsequently ceased to monitor.

In today’s issue.

• Ostium lost $18M on Arbitrum after an attacker compromised the private key behind its oracle signer.

• Bonzo Lend lost $9.05M on Hedera when a third-party oracle verifier accepted a price update with no real signature.

• BlueMove’s own team allegedly planted the backdoor that drained $400,000 from its Sui liquidity pools.

Need to Know

The week's two largest losses both originated in a protocol's dependencies, one in a compromised oracle signer key and the other in a third-party verifier's signature check. In both cases, substantial venture funding and an active user base provided no protection, because the vulnerability lay outside the code that either team had audited. A third and more unusual incident appears to have originated within a development team itself, which used a retained upgrade capability to insert a means of re-entry into its own contract. The common factor across all three is a component that each team had treated as settled, and the open question is how recently any such assumption has been tested under adversarial conditions. —Adrian

The Big One. Ostium’s $18M Oracle Signer Compromise

The news. On 15 July an attacker holding the private key behind Ostium’s oracle signer used it to feed the protocol future-dated prices and drained roughly $18M USDC from the Arbitrum perpetual exchange’s OLP vault, per Blockaid’s disclosure reported by crypto.news and CryptoTimes. On-chain tracing later pushed some estimates as high as $23.75M, and Ostium had not confirmed a final figure at the time of writing.

What broke and how. Ostium’s OLP vault settled trades against price reports from an authorised oracle signer, and it paired that signer with a registered PriceUpKeep forwarder that could trigger its own settlement calls. Holding the signer’s key handed the attacker both halves of that arrangement at once. Inside a single executeBatch transaction, the attacker opened a position at the real market price, submitted a future-dated report showing whatever price suited them, and closed the position against that invented number. Each pass through the loop compounded the margin, running the stake from $1,000 to $80,000 to $700,000 and returning as much as 900 percent a cycle, and it repeated about ten times before the vault ran dry, according to CryptoTimes. The stolen USDC was then swapped for roughly 12,084 ETH and moved through Tornado Cash, per TronWeekly.

Why it kept happening. Oracle signer compromises have become one of 2026’s most persistent attack classes, and Ostium is a reminder that money buys no immunity from them. Its $27.8M from General Catalyst, Jump Crypto, Coinbase Ventures, Wintermute, and GSR paid for a great deal, though not for any separation between the key that reports a price and the key that settles against it. The exposure was exactly that overlap. A single signer could state a price and act on it in the same breath, and a single leaked credential was enough to do both.

What to check now.

• Does any single key or role hold both the ability to submit price data and the ability to trigger settlement against that data.

• Are your oracle signer keys held in the same trust boundary, HSM, custody provider, or access policy, as your admin or upgrade keys, or kept separate.

• Is there a sanity bound on price movement per update, independent of the signer’s own authority, that would reject a report this far from a reference price.

• Would your monitoring catch ten rapid open-close cycles on one position before the tenth one clears.

• Do you have a reduced-authority mode you can trigger the moment a signer’s behaviour looks anomalous, rather than only after a post-mortem confirms compromise.

A signer that can both write the price and spend against it is one leaked key away from being your protocol’s entire risk model. I would rather see that split shipped a week late than see it skipped because nobody wanted to slow down the settlement path.

— Adrian

Chain Reaction. Bonzo Lend’s $9.05M Zero-Signature Oracle Bypass

The news. Ostium was the larger of the week’s two oracle failures, but it was not the first. Four days earlier the same kind of trust broke on Hedera through a different flaw. On 11 July an attacker deposited 250 SAUCE tokens, worth a few dollars, into Bonzo Lend, then submitted a price update whose cryptographic signature was nothing but zeros, and the protocol’s Supra oracle verifier accepted it as valid, according to Bonzo’s own incident account reported by CryptoSlate and The Block. That inflated collateral let the account borrow 6.63M USDC and 34.52M wrapped HBAR, about $9.05M, within eight seconds.

What broke and how. Bonzo Lend is an Aave v2 fork and Hedera’s largest lending protocol, and like most of the network’s markets it priced its collateral through Supra rather than through logic of its own. Supra’s verifier was meant to check the signature on every price update and reject anything unsigned, but it accepted one made entirely of zeros. From there Bonzo’s lending code did what any lending code does with a price it has no reason to doubt, letting the account borrow against collateral the feed now valued far above what 250 SAUCE was worth. A legitimate Supra update overwrote the bad price soon after, and Bonzo paused the pool five minutes later, according to The Block. In the gap, a second wallet had already borrowed roughly $1M more, then identified itself as a white-hat responder and offered to return it, per The Defiant.

Why it kept happening. This is the second time in six weeks Burn Notice has covered real money lost to a third-party oracle a protocol used but never controlled, after Edel Finance in issue seven. Careful auditing of your own Solidity does not reach a bug living in a dependency’s verifier, and both protocols that lost money here had, by most measures, done real work on the code they wrote.

What to check now.

• Do you treat third-party oracle contracts as part of your own audit scope, or as a black box you assume already works.

• Does your protocol sanity-check an incoming price against a second independent source before acting on it.

• Would a price update with a malformed or empty signature field be rejected by your own code even if the oracle’s verifier accepts it.

• Do you know, today, which of your dependencies had their last security review more than a year ago.

• Is there a per-transaction cap on how much a single price update can move before it triggers a pause rather than a trade.

You do not own your oracle's verifier, but you own every loss it signs off on. The teams that get burned here are the ones who treated a third-party price feed as someone else's code to worry about. Before your next release, find out who actually read the verifier you are trusting, and when.

— Adrian

Around the Forums

Humanity Protocol names the root cause, then changes direction entirely. Humanity Protocol gave the first detailed account last week of the hack Burn Notice covered in issue seven, and the cause turned out to be almost mundane. A phishing email dressed up as a Bithumb token schedule reached a developer’s laptop, according to Cointelegraph and Quantstamp’s findings reported by CryptoBreaking. Several production keys, including a quorum of the project’s multisig owners across two chains, had been sitting on that same laptop since last year’s mainnet launch, backed up once and never removed. The founder has also confirmed the project is turning toward enterprise AI products, which leaves the original decentralised-identity mission, and the security rebuild it now needs, to a much smaller team.

Will Arbitrum’s Security Council step in for Ostium the way it did for KelpDAO. Ostium’s loss revived a question the council last faced earlier this year, when it froze more than $70M after the KelpDAO exploit. Ostium’s loss is roughly a quarter that size, and Protos notes the council has not signalled whether it will step in again. Its answer will show whether it acts on the scale of a loss or on the mechanics of how the money moved.

What Else Happened

• Alleged insider-planted backdoor drain of BlueMove DEX on Sui. Over 700,000 SUI, roughly $400,000 to $500,000, drained from BlueMove’s liquidity pools on 11 July, and a researcher traced the exploit to a function the project’s own upgrade-cap holder had added on 31 May, then locked in by burning that upgrade capability three days later so the contract could never be patched, per Protos and BigGo Finance. BlueMove has offered the attacker a 30 percent bounty to return the rest and says it will wind down.

• ERC-4337 smart account validation flaw. Lumi Finance lost about $270,000 on Arbitrum on 13 July after an attacker exploited Sodium’s account abstraction infrastructure, mutating token allowances inside what should have been a read-only validation step, per CryptoTimes.

• Supply chain compromise of the jscrambler npm package. The five bad releases behind this week’s opening went out over roughly three hours from a stolen publishing credential, on a security package that still pulls about 15,800 downloads a week, per The Hacker News and Socket’s research. JFrog tied the payload, IronWorm, to the same self-propagating lineage as last year’s Shai-Hulud campaigns, and its later versions ran on import so that a scanner skipping install scripts caught nothing.

Patch Notes

Anyone whose build pipeline or developer machines pulled jscrambler during the roughly three-hour window should treat every credential on those machines as exposed and rotate it now, the cloud keys, the CI tokens, the browser sessions, and any hot wallet sitting on the same box. Do not lean on --ignore-scripts as evidence you were safe, because the later versions ran on import. And audit a security vendor’s own package the way you would any other dependency in your build.

Long Reads

• Ledger Donjon’s disclosure of a laser fault injection attack on Tangem cards, read alongside Tangem’s response. A single nanosecond laser pulse can flip one conditional check inside the card and reset its password, and because the cards carry no way to receive a firmware update, the flaw cannot be fixed on any card already in someone’s wallet. The argument around the finding is the reason to read it. Tangem’s rebuttal, that the attack needs $250,000 of lab equipment and the card in hand, holds up against Ledger Donjon’s own figures even though Donjon belongs to a direct competitor, and both sides end up right about different things.

• Coinspect’s Ill Bloom disclosure, on a weak random-number generator that has been producing guessable recovery phrases in some mobile wallets since 2018. The confirmed sweep is older news, $3.14M taken from 431 of 2,114 identified addresses on 27 May, but it belongs to the same family as 2023’s Milk Sad and Trust Wallet flaws, detailed by TechTimes, and it is worth checking against any wallet your team or your users created on an unfamiliar mobile app before 2020.

• Dragonfly’s Haseeb Qureshi arguing AI has not triggered a DeFi “hackpocalypse”. His evidence is that the median hack has shrunk below $500,000 this year, down from over $2M in 2025, with AI-assisted attackers picking off small and abandoned protocols while the fortified ones hold. This week reads as a complication rather than a confirmation of that case, since Ostium and Bonzo were funded, live, and well used, and between them they cleared the median many times over.

Closing Tab

Each of the week's significant losses occurred at a boundary its team had assumed was already secure, whether an oracle signer's key, a verifier's signature check, or an upgrade capability that had been left active and forgotten. None of the incidents required a novel technique. Each required only a single credential or dependency that had gone unmonitored long enough for an external party to identify it, a weakness that is now common across much of the industry's infrastructure.

Burn Notice. Operational intelligence for Web3.

Adrian Hetman

The week's largest losses are covered below, but the entries worth pausing on sit lower in the digest, where the attacks went after the software around crypto rather than the contracts themselves. One browser extension built to steal cryptocurrency now retrieves its command server from a smart contract. The design keeps the attacker's infrastructure on-chain, out of reach of an ordinary takedown. Another, an ad blocker with more than ten million installs, was found to carry a dormant switch that could run code on any page. The contracts, as always, are audited line by line. The browser tab beside them, and the registries their code is pulled from, rarely get the same attention.

In today’s issue.

• Lazy Summer’s $6M vault drain traces to an impaired market still priced into NAV three months after its offboarding began.

• BonkDAO’s treasury lost $20M after an attacker bought a one-percent quorum and voted, almost alone, to move the funds.

• Aptos patched a $70B Move VM type-confusion bug back in February, and Hexens has just published the $3,000 proof of concept.

Need to Know

The losses that moved real money this week all came from mechanisms a team ran itself and had stopped watching, an impaired position still allowed to set a vault's price and a governance vote cheap enough for one buyer to win alone. Both were legitimate transactions the protocol authorised, which is why none of the usual defences fired. The largest headline figure belonged instead to a bug that cost nobody anything, because a researcher reached it months before an attacker could and the fix shipped the same day. If part of your stack still carries authority you have assumed was dormant, a retired market, a thin vote, a module nobody re-audits, the question worth carrying is when anyone last checked it was safe to trust. —AH

The Big One. Lazy Summer’s Donated NAV and a $6M Redemption

The news. On 6 July an attacker inflated the share price of two Lazy Summer Protocol USDC vaults on Ethereum and redeemed roughly $6.04M of depositor value in a single atomic transaction, about $5.64M from the lower-risk vault and $0.40M from the higher-risk one, according to the [Summer.fi post-mortem] and [CoinDesk]. They funded the whole thing with a roughly $65M flash loan and none of their own money, a position that existed only inside the single transaction and was repaid the moment it closed, so nothing they held was ever actually at risk.

What broke and how. Lazy Summer runs automated ERC-4626 vaults where a FleetCommander contract derives each vault’s share price from totalAssets(), the sum of what every active strategy adapter, called an Ark, reports it holds. An Ark credits any token transferred directly into it at that Ark’s own valuation, minting no new shares, so a donation quietly raises the vault’s reported assets. The attacker donated stale-valued Silo “Varlamore USDC Growth” tokens, which had carried a value never marked down since the November 2025 Stream Finance collapse, into an Ark whose deposit cap had been set to zero for offboarding but which still counted toward NAV. That lifted reported assets by around 9.5 percent and pushed the share price from about 1.0665 to about 1.1678 USDC, and when the attacker redeemed, the payout was assembled from the vault’s genuinely liquid Morpho, Spark, and Sky positions, which is to say from other depositors’ capital, per [CertiK’s reconstruction via The Block].

Zeroing the deposit cap stopped new money going in, but it never removed the Ark from the price calculation, so an impaired market kept helping set the price throughout the offboarding window. The position was accumulated across roughly three months before the single-transaction extraction, so the [on-chain evidence traces the setup back to a dead protocol’s mispriced tokens] rather than to any opportunistic flash loan alone.

Why it kept happening. This is a share-price and donation-manipulation pattern, and it is the second ERC-4626 accounting failure Burn Notice has run in as many issues after Vault4626. The recurring shape is a vault trusting an external number it should treat as hostile, a donated balance, a wrapped token’s self-reported value, an integrated market’s totalAssets(). Offboarding is where it bites hardest, because a market that is officially being removed but is still technically live is the softest target on the board, everyone has already written it off in their heads and stopped watching the number it feeds.

What to check now.

• Do any paused, capped, or deprecated strategies still contribute to your vault’s totalAssets() or NAV.

• Does any adapter credit donated or directly transferred tokens at face value without minting shares against them.

• Are wrapped positions from halted or collapsed markets still reporting a stale on-chain value your accounting trusts.

• Do you run independent accounting rather than reading balanceOf or totalAssets straight from an integrated market.

• Does your pause or guardian role actually hold on every chain you deploy to. The Lazy Summer pause reverted on HyperEVM because the guardian did not hold the role there.

If your vault prices itself off a market you have already decided to retire, you are trusting a number nobody on your team is being paid to watch any more. Retire the price feed the day you retire the market, not six days later through governance.

— Adrian

Chain Reaction. Bonk’s $20M Governance Buyout

The news. On 6 July an attacker passed BonkDAO proposal BIP #76 and automatically moved about $20M, some 4.4 trillion BONK, out of the DAO treasury, having spent roughly $4.4M over the preceding days buying just over one percent of BONK’s supply on Bybit and Binance, [exactly the quorum threshold]. The vote itself ran on the DAO’s ordinary Realms governance on Solana, so every step of the buying and the balloting read as normal participation right up until the treasury emptied.

What broke and how. BonkDAO used ordinary token-weighted voting on a ballot almost nobody attended. Only seven of more than 18,000 eligible wallets voted, the attacker’s purchased stake cleared quorum by the narrowest margin, and the proposal passed with 99.9 percent in favour, one voter agreeing with itself. The payload was nothing more elaborate than a transfer of treasury BONK to a wallet the attacker controlled, which the DAO’s own machinery then executed automatically the moment the vote closed. Because every step was a valid transaction, the incident has [reopened the old argument over whether this is theft or the rules working as written], with SlowMist’s founder among those noting it was not a hack in the usual sense. BonkDAO has notified law enforcement and is working with exchanges, bridges, and the Solana Foundation, and Upbit, Bithumb, and Kraken paused BONK deposits.

Why it kept happening. Governance-buy attacks recur because they need capital rather than skill, and memecoin DAOs in particular sit on outsized treasuries behind plain token-weighted voting with no timelock, low quorum, and no veto. Burn Notice covered a one-vote DAO takeover back in issue four, and the pattern has not changed. Worth noting alongside this week’s Big One, Lazy Summer’s own guardians had cancelled a malicious governance proposal in April, and the whole difference between that outcome and this one was the existence of a veto path.

What to check now.

• Is there a timelock between a proposal passing and the treasury executing it, long enough for anyone to react.

• Is quorum high enough that a cheap temporary majority cannot clear it, and does any time or conviction weighting blunt last-minute accumulation.

• Is there an emergency multisig or guardian veto over large treasury movements.

• Can a single proposal move the entire treasury in one payload, or are transfers bounded.

• Are you watching for sudden pre-vote token accumulation across exchanges the way BonkDAO could only do after the fact.

A treasury guarded only by token-weighted voting is worth exactly the cost of buying a majority, and here that cost was a fifth of the prize. If your DAO holds real money, price your own governance attack before someone else does, and ask whether your quorum is a wall or a turnstile.

— Adrian

Around the Forums

EMURGO exits Cardano’s Pentad. On 8 July, [EMURGO stepped down from the Pentad governance coalition] to concentrate on the SecondFi recovery, becoming the first of the group’s five founding members to leave. Pentad, formed earlier this year, pairs EMURGO with Input Output Global, the Cardano Foundation, Intersect, and the Midnight Foundation for treasury-backed infrastructure work, so a founding entity walking out under pressure is a real test of whether that structure was built to absorb one. SecondFi itself is now [winding down to a recovery-only operation rather than resuming service], and the two-week reimbursement target set in late June has already slipped.

Lazy Summer’s DAO now has to clean up. Governance faces its own vote in the wake of the exploit, including whether to exclude the attacker’s remaining vault shares from snapshots, how to return roughly $4M of mostly illiquid depositor capital, and a roughly six-day timeline just to unpause the untouched vaults. It is a live test of whether a narrowly scoped guardian module plus DAO governance can actually make depositors whole, or whether “we will cover it” quietly becomes “governance is evaluating options.”

What Else Happened

• MEV backrun and extreme slippage. A single large trade routed into an illiquid Uniswap V3 AVAIL/WETH pool on 5 July cost the user around $2M, [flagged by Protos].

• Deflationary reserve-burn manipulation. BFB on BNB Chain lost about $198K on 8 July when its price-support burn logic was gamed inside a single transaction, [per the on-chain record].

• Clipboard clipper via a rogue extension. A fake “Google Notes” extension called [Silent Swap] installs into Chromium browsers by editing their protected preference files, then swaps any wallet address copied to the clipboard for one the attacker controls just before it is pasted. It resolves its command server by reading an on-chain smart contract, a technique known as [EtherHiding] that leaves the attacker infrastructure somewhere ordinary takedowns cannot reach.

• Browser extension supply chain. Beyond that clipper, a Chrome ad blocker with [over 10 million installs and a Featured badge] was found carrying a dormant path to run arbitrary code on any page, flippable from the server with no update and no store review, and Microsoft pulled [119 Edge extensions in the StegoAd campaign] for hiding payloads inside image files to lift credentials and session cookies. A wallet in the same browser as either is one server-side switch from a swapped address or a hijacked session.

• Supply chain compromise. North Korea-linked actors published [108 malicious packages across npm, Packagist, Go, and Chrome] using obfuscated loaders aimed at developer machines.

• Researcher-targeted supply chain. Fake GitHub proof-of-concept repos are seeding the [ChocoPoC RAT to vulnerability researchers] who run the “PoC” to see if it works.

• Attribution. Microsoft tied last month’s Mastra AI npm compromise to [Sapphire Sleet, also tracked as BlueNoroff], the same North Korean cluster behind several developer-targeting campaigns.

Patch Notes

This week’s operational urgency sits in the developer supply chain, not in anyone’s contracts. If your team pulls from npm, Go, or Packagist, or installs browser extensions, treat the North Korea-linked package flood in What Else Happened as the prompt to pin and audit your dependencies and to re-check what your CI actually installs on a fresh runner. And if anyone on your team reviews public proof-of-concept code, assume the ChocoPoC pattern is now standard, a “PoC” can be the payload, so run untrusted repos nowhere near a machine that touches keys.

The Lazy Summer and Bonk lessons are design reviews rather than patch deadlines, so they live in each story’s What to check now rather than here.

Long Reads

• [Summer.fi’s Lazy Summer post-mortem], read alongside [BA Labs’ risk-curator retrospective]. Between them they give the clearest account of how a donation into an incompletely offboarded market moves a vault’s whole share price, and why the withdrawable-balance framing several early write-ups reached for was the wrong diagnosis.

• [Hexens on the Aptos Move VM type-confusion bug]. Worth it for the risk-sizing dispute alone, Hexens’ $70B systemic figure against roughly $250M of direct Aptos exposure, Aptos Labs calling real-world exploitability [“extremely low”] against a near-90 percent simulation, and Polygon’s CTO confirming the proof of concept ran as described. Essential if you build on or bridge to any L1, because VM-level bugs sit below the audits most teams rely on.

• [Gnosis Pay’s post-mortem on the Zodiac module exploit]. The incident was 1 June, but the newly published write-up is a tight lesson in [ERC-1271 signature-verification logic that read a return value without confirming the call had executed], and in how a delay module built to protect users became the path in.

Closing Tab

Taken together, the week has one shape. The money moved through systems doing exactly what they were built to do, while the one component that failed, the Aptos VM, cost nobody anything because it was caught and patched first. For a security newsletter, the uncomfortable part is that most of this week's damage was authorised.

Burn Notice. Operational intelligence for Web3, every week.

Adrian Hetman

One of the three entities that founded Cardano ships a wallet, and this week a flaw in its own signing software handed attackers the private keys to 374 user addresses. An organisation that helped build the chain wrote the software that lost its own users their keys. It was the largest loss of a week that brought several more.

In today’s issue.

• SecondFi blames a nonce flaw, a competing report blames a swapped dependency, and recovery is weeks out.

• A flash loan inflated one tokenized-equity exchange rate by 78 times, echoing a second protocol’s loss to the same trick days earlier.

• THORChain reopened after 39 days, and a forensic link ties KelpDAO and Humanity Protocol to one attacker.

Need to Know

The losses that mattered this week all traced back to inputs a team trusted and no outsider had checked lately. The same flash-loan price trick worked twice in one week on two protocols that shared no code, because each one trusted a number it should have been treating as hostile. The better outcomes came from teams that questioned their own inputs before an attacker did, whether that meant a slow manual restart or a forensic trace run long after the money had moved. If you cannot name the last time someone outside your team checked the inputs yours quietly trusts, this is the week to find out. —Adrian

The Big One. SecondFi’s Deterministic Nonce Flaw Exposed 374 Cardano Wallets

The news. Between 21 and 23 June, three separate draining events pulled roughly 16 million ADA, worth about $2.4 million at the time, out of 374 addresses on SecondFi, the wallet platform EMURGO rebranded from Yoroi in April and one of Cardano’s three founding entities. Two attacker groups were behind it, one compromising 171 wallets across two waves, the other taking 203 in a single sweep.

What broke and how. SecondFi traced the cause to a deterministic nonce derivation flaw in its proprietary signing software, one that leaked enough information every time an affected address signed a transaction for an attacker to mathematically reconstruct that address’s private key from data already sitting on the public chain. Because the exposure lives at the address level rather than the app, importing an affected seed phrase into a different wallet simply recreates the same exposed key.

A competing account complicates the story. Tibane Labs, a firm building its own wallet and staffed in part by former Mt. Gox chief executive Mark Karpelès, says the failure was not nonce reuse in the classic sense. Its report traces the fault instead to an unaudited third-party SDK that silently replaced EMURGO’s previously audited signing code on 8 June, leaving secret nonce material unset inside the Ed25519 implementation, a mechanism Tibane says it confirmed by decompiling the shipped Android build and matching it against historical signatures. The Block could not independently verify that finding, and EMURGO has not addressed the third-party SDK claim publicly, but both accounts describe the same underlying failure, in which the signing code running in production had quietly drifted from the signing code anyone had reason to trust.

Why it kept happening. Security researcher Taylor Monahan put the plainer version on record, saying SecondFi rolled its own cryptography in closed-source, unaudited software. Users treated that software as safe because a co-founding entity of Cardano shipped it, and that institutional trust stood in for the independent review the signing layer never got. A protocol can pass every audit on its contracts and still leak keys through the software that talks to those contracts, because most audit scopes stop at the chain boundary.

What to check now.

• If any part of your stack depends on closed-source or vendor-supplied signing or wallet-generation code, get an independent audit of what is actually running in production rather than trusting the vendor’s own description of it.

• Confirm nothing in your deployment pipeline can silently swap a dependency that touches signing logic without a review gate catching it, since Tibane Labs blames exactly that kind of substitution here.

• If you maintain any Ed25519 or EdDSA signing path, verify the nonce material is genuinely secret and never falls back to a fixed or predictable value when a dependency changes underneath it.

• Treat wallet-generation and signing software as part of your threat model even when you did not write it, because the KelpDAO and Bybit incidents both taught the same lesson at the infrastructure layer rather than the contract layer.

The operator move.

Signing code drifts from what was originally audited more often than most teams assume. Ask your own team what code is actually running in your production signing path this week, because a vendor’s audit report from six months ago describes a system that may no longer exist.

— Adrian

Chain Reaction. Edel Finance and DLMC Token Lost to the Same Flash-Loan Weakness

The news. Two protocols lost money to the same trick within the same week. On 1 July, a flash loan on Edel Finance’s tokenized-equities lending market inflated the exchange rate between wGOOGLx and GOOGLx by roughly 78 times its real value, letting the attacker borrow against artificially inflated collateral and drain about $403,000 from the protocol’s xStock reserves before routing the proceeds to Tornado Cash. A week earlier, on 24 June, DLMC Token lost $222,560 on BNB Chain when a flash-funded deposit exploited a circulating-supply calculation that excluded contract-held minted tokens, pushing the token’s internal price from roughly $0.41 to nearly $25 and letting the attacker redeem referral rewards at the inflated rate.

What broke and how. The mechanism is identical in both cases, even though the two protocols do not share code, a chain, or a team. Each relied on a number a flash loan can move within a single transaction, and neither checked that number against an independent source before trusting it. Edel Finance’s lending market read its exchange rate directly off a manipulable pool rather than a time-weighted or oracle-verified price, so inflating that one number for one transaction was enough to unlock the borrow. DLMC’s referral-reward calculation divided by a circulating-supply figure that excluded tokens the contract itself already held, so a single large flash-funded deposit was enough to distort the supply figure and, with it, the price the contract believed was real.

Why it kept happening. Flash-loan price manipulation is DeFi’s oldest, best-documented attack class, and both teams treated an independent price check as a nice-to-have rather than a launch requirement. Edel Finance sits inside the tokenized real-world-asset push bringing equities like Google’s stock on-chain, a category moving fast enough that some teams are shipping lending markets before internalising lessons the rest of DeFi already paid for years ago. DLMC’s exploit shows the same lesson has not fully landed even in the older parts of DeFi, on a completely different chain, in a completely different kind of contract.

What to check now.

• Confirm any price or exchange-rate input your contracts trust comes from a time-weighted or multi-source oracle rather than a single pool balance a flash loan can move within one transaction.

• If any calculation in your contracts divides by a circulating-supply or total-supply figure, verify it correctly excludes tokens the contract itself holds, and test that calculation against a single large deposit landing in one block.

• Treat flash-loan resistance as a launch requirement for any new lending, borrowing, or reward mechanism, rather than a finding to fix after an audit flags it.

• If you are building on tokenized real-world assets specifically, read the DeFi oracle-manipulation post-mortems from 2021 and 2022 before shipping, since the category is new but the bug is not.

The operator move.

Flash-loan price manipulation has been documented, exploited, and written up in public post-mortems for years, and it still worked twice this week on two protocols that had every opportunity to read about it first. An audit catches this bug easily when someone asks the right question, and teams skip asking it when the deadline is close and the check feels optional. Learn from the history before you will become an example of someone repeating the same old mistakes.

— Adrian

Around the Forums

THORChain resumed full trading on 23 June, 39 days after May’s GG20 vault compromise forced it to halt signing, swaps, and liquidity provider actions across the network. The team verified every vault and keyshare before reopening, and the ADR-028 recovery plan absorbs the loss from protocol-owned liquidity without minting new RUNE. Native Monero and Zcash swaps are next on the roadmap, worth watching given the newsletter’s own history with Zcash-adjacent bugs.

What Else Happened

• Logic error in a custom ERC-4626 vault on Vault4626. A yield vault wrapping a Uniswap V3 position on Base and Arbitrum double-paid the WETH side of the underlying position, draining roughly 34 WETH, about $53,000.

• Forged permit signature on Lixir Finance. An attacker exploited broken signature verification on Lixir’s wrapped vault tokens to forge a permit and drain approvals, taking about $12,300 on Ethereum.

• Account takeover on Gnosis’s official X account. PeckShield flagged the compromise on 25 June and warned against interacting with any links posted from it, a takeover unrelated to the Zodiac Delay Module exploit that hit Gnosis Pay earlier in June, a separate product under the same umbrella.

• A defensive win against crypto-wallet-targeting infostealers. Operation Endgame, a law enforcement coalition led by Europol, disrupted the infrastructure behind StealC and Amadey on 24 June, taking down 326 servers and 142 domains and recovering 27 million stolen credentials. StealC’s own feature list names cryptocurrency wallet data as a harvest target alongside browser credentials, and the operation also froze more than €41M in criminal crypto assets as part of the same takedown.

• A forensic link between KelpDAO and Humanity Protocol. On-chain analysts traced funds from both exploits converging into the same route, evidence that investigators say rules out the insider-theft theory some raised around Humanity Protocol and points instead to a shared North Korea-linked operator behind both hacks.

Patch Notes

First, if any signing or wallet-generation code in your stack came from a vendor or a dependency you did not write yourself, confirm what is actually deployed in production against what was actually audited, per the SecondFi item above, since that exact gap went unnoticed until it was already too late. Second, patch CVE-2026-48558 today if your organisation or any MSP you rely on runs SimpleHelp for remote management, a flaw CISA has already added to its Known Exploited Vulnerabilities catalogue with a deadline of 2 July, because attackers are using it right now to install Djinn Stealer, which harvests crypto wallets and keystores alongside npm, PyPI, and cloud credentials in a single pass.

Long Reads

• The Block on SecondFi’s contested root cause, the clearest available account of both the official nonce-flaw explanation and Tibane Labs’ competing supply-chain theory, alongside Taylor Monahan’s blunter framing of the underlying governance failure.

• The Hacker News on the SimpleHelp to Djinn Stealer chain, with the full list of what the stealer targets, worth fifteen minutes for anyone who has ever pointed an AI coding assistant at a repo with a deployer key in it.

• Crypto.news on THORChain’s technical restart, for the actual vault-by-vault and keyshare-by-keyshare verification process behind the 39-day recovery, useful reading for anyone running threshold-signed infrastructure of their own.

• Cryptopolitan on the KelpDAO and Humanity Protocol fund overlap, with the clearest walkthrough of how the two laundering trails converged and what that confirms about attribution.

Adrian Hetman Burn Notice Operational intelligence for Web3, every week.

Five teams lost money this week, and not one of them was beaten by clever cryptography. In every case the code ran as written, and the loss came from the housekeeping around it, the parts of a system that someone configures once and never revisits.

In today’s issue.

• How a counter-MEV honeypot turned Jared’s own token approvals into a $7.5M withdrawal.

• Why 144 poisoned Mastra packages mean your build pipeline, not your contract, is the soft target.

• Aztec drained twice in one week, and why deprecated contracts are now a target.

Need to Know

Most of this week’s losses were self-inflicted. A front-running bot was tricked into signing away its own treasury, a four-year-dead bridge paid out against a forged proof, a privacy chain minted wrapped assets without checking where they came from, and a software supply chain delivered a backdoor through a contributor account that nobody had bothered to close. None of these attacks needed a new cryptographic break, only a permission, a key, or a validation step that someone had left running unattended. —Adrian

The Big One. Jared’s Own Approvals Drained It of $7.5M

The news. Jaredfromsubway.eth, the address tied to roughly seventy per cent of Ethereum’s sandwich attacks since 2023, was emptied of more than $7.5M over the weekend of 20 June. Blockaid, which spotted the sweep, said plainly that this was neither a stolen key nor a flaw in Jared’s own contract Blockaid via The Defiant. The attacker spent weeks building a trap out of the bot’s own behaviour, and the bot walked into it the way it walks into everything, at machine speed.

What broke and how. A token approval on Ethereum is easy to mistake for a one-off click. It is really a standing grant that lets another contract move your tokens whenever it likes, until you take it back. Jared’s bot handed out those grants as a routine part of its sandwich workflow, approving helper contracts so they could spend its WETH, USDC and USDT during a trade. The attacker deployed sixty-six counterfeit token contracts dressed up as WETH, USDC and USDT, then fed the bot small, real profits across about ninety-seven blocks so it would keep engaging Thirdweb post-mortem. The routes were crafted so the approvals the bot generated were never consumed during the trade and never revoked afterwards. Once enough of those grants stood open, the attacker sent a single transaction that called transferFrom across all of them and pulled out around 1,474 WETH, 2.87M USDC and 2M USDT, much of which has already gone through Tornado Cash The Block.

Why it kept happening. The dangling approval is one of the oldest unsolved problems on Ethereum, and it drains ordinary wallets every week through malicious tokens that ask for permission and are granted it without thought. Jared industrialised the same mistake. Its contracts approved spenders at speed and on the assumption that the pools it touched were either honest or too small to matter, which held until somebody spent a fortnight proving otherwise. A single approve(0) after each trade would have closed the door, and the whole loss comes down to the bot never making that call The Block.

What to check now.

• Enumerate every live approval your contracts and operational wallets have granted, and treat the list as a liability register rather than a log.

• Bound approvals to the exact amount a transaction needs. An unbounded max uint256 approval is a permanent withdrawal slip left on the table.

• Revoke after use. An integration that cannot call approve(0) at the end of a flow has a design defect to fix.

• Refuse to interact with unvetted token contracts at automated speed. Speed is the attacker’s ally in every honeypot of this shape.

• Alert on any transferFrom against your contracts that your own logic did not initiate.

Jared did nothing its own code forbade. It approved spenders the way it had thousands of times before, and someone spent a month turning that routine into a single drain. Any stack that grants approvals faster than a human ever reviews them is running the same bet Jared just lost for $7.5M.

— Adrian

Chain Reaction. 144 Poisoned Packages and a Maintainer Account No One Closed

The news. On 17 June an attacker took control of a dormant Mastra contributor account and, inside eighty-eight minutes, republished 144 packages across the @mastra npm scope, each carrying one injected dependency StepSecurity. Mastra is an open-source TypeScript framework for building AI agents, and its core package alone pulls more than 900,000 downloads a week. On 19 June Microsoft attributed the campaign, with high confidence, to Sapphire Sleet, the North Korean crew also tracked as BlueNoroff Microsoft Threat Intelligence.

What broke and how. The malware was not in Mastra’s code, which the attacker never touched. It hid one level down, in a dependency called easy-day-js, a near-perfect forgery of the popular dayjs date library that copied the real package’s author, homepage and licence so a developer skimming the dependency list would see nothing wrong Orca Security. A clean version went up first as bait, then a weaponised one with a postinstall hook that ran the moment anyone installed the package. The hook dropped a cross-platform remote-access trojan that disabled certificate checks, phoned a control server, and went hunting for cloud credentials, LLM API keys and the contents of 166 cryptocurrency wallet extensions. Because the affected packages used a caret version range, ordinary installs upgraded themselves to the poisoned release without anyone choosing to. The entry point was a former contributor account, ehindero, whose publish rights across the whole scope had never been revoked, and whose owner had reportedly been social-engineered through a LinkedIn approach and a link clicked during a call The Hacker News.

Why it kept happening. This is the second time in 2026 that Microsoft has pinned an npm compromise on the same North Korean group, after a near-identical attack on the Axios HTTP client in the spring. npm does not expire a maintainer’s scope access for inactivity, so a stale credential stayed dangerous for over a year. No CVE was ever assigned, which meant every scanner that waits for a CVE was blind throughout the attack TechTimes. Mastra generated build provenance on its real releases but did not require it, so a personal token could publish without an attestation and nobody’s install rejected it. The attacker never broke into the code, walking in instead through the parts of the process that nobody had ever treated as security.

What to check now.

• Search every project and CI runner for the affected @mastra versions and for easy-day-js in lockfiles. Mastra 1.13.0 and earlier are clean.

• Require signature or provenance verification on install, with npm audit signatures or a policy that rejects packages lacking attestations. That single control would have blocked this entire wave.

• Revoke scope publish rights for every maintainer who has gone quiet, because an account nobody uses can still publish.

• Treat any machine that ran the install as fully compromised, rotate every credential reachable from it, and move hot-wallet funds to keys generated on a clean device.

By 2026 the audited code is the hard part of the stack, so attackers have moved to the laptop and the off-chain modules instead. A crew that wants your keys no longer needs to break your code when it can publish a backdoor under a name you already trust and wait for you to type npm install.

— Adrian

The Operator’s Read

The Soft Target Moved Off-Chain

An attacker took over a quiet contributor account this month and, in under two hours, republished 144 packages across a widely used npm scope, each one carrying a backdoor. There was no flaw in the code and no clever cryptography involved. The way in was an account with publish rights that nobody had closed.

That is where Web3 security has arrived. The audited code is now the hardest part of the stack to break, so attackers have stopped aiming at it. They go after the build pipeline and the people who run it, and almost no one has moved their security budget to match.

Look at what actually took money this week. The contract drains landed on dead code. Aztec lost funds from infrastructure it had retired years ago, and Secret Network lost more from a token contract that had been forked, quietly stripped of a validation check, and never re-audited. The live, reviewed code mostly held, and the losses came in through the edges where review had stopped looking.

Mastra is the clean example of the shift. It is an open-source framework for building AI agents, with a core package pulled close to a million times a week. The attacker never touched its code. Instead they took over a former contributor account that still held publish rights across the whole scope, and hid the payload one level down, in a dependency dressed up as a popular date library. The hook ran on install, and through it the attacker collected cloud credentials, model API keys and the contents of crypto wallet extensions. Microsoft traced the campaign to the North Korean group also tracked as BlueNoroff, again this year, after a near-identical attack on the Axios library in the spring.

The same crew works the human layer at the same time. Through the spring they ran fake video calls seeded with deepfaked colleagues and moved Web3 founders from a friendly catch-up to a compromised laptop in minutes. The Mastra maintainer was reportedly pulled in the same way, through a message and a link during a call. What these crews want is the person with the keys, and the machine those keys live on.

None of this is exotic. An attacker has finite hours and spends them where the return is highest, and for years that meant the contract. The contract is hard now, so the maths moved. Poisoning a dependency or staging a fake meeting pays better than another month spent reading reviewed code. And the slow part of that work, the recon, the staging, the patient impersonation, is the part machines now do cheaply. One researcher reportedly earned around half a million dollars from Google’s bug bounty in under ninety days by wiring an AI model into an automated testing loop. He reported that figure himself, and Google has not confirmed it. The same automation that helps a defender find bugs faster lets an attacker run more of these campaigns at once.

Most security budgets have not absorbed any of this. The audit line is mature and well understood. The supply-chain line barely exists, which leaves the npm token that can publish to a scope your users trust protected by whatever someone set up once and forgot. So treat the build pipeline as production, because it already is. Require provenance or signature verification on every install. Revoke publish rights for maintainers who have gone quiet. Confirm any meeting link or recovery request through a second channel before anyone clicks.

The point is simple enough to act on this week. An attacker is least likely to reach you through the part of the stack you have spent the most defending, and most likely to reach you through the build pipeline and the people who feed it. You can probably name the firm that last audited your contracts and the month they did it. Do the same for the accounts that can publish into your build and the people who hold them, and see how fast you run out of answers.

— Adrian

Sources. Cloudsmith and Microsoft Threat Intelligence on the Mastra compromise, Arctic Wolf on the fake-meeting campaign, and TechRepublic on the Google bounty figure.

Leave a comment

Around the Forums

Axelar’s emergency committee pulled the cord on Secret Network. After the Secret bridge drain surfaced, Axelar’s emergency committee disabled the Secret and Secret-SNIP connections to stop the loss spreading, and said its firewalling kept the damage off other chains Axelar via crypto.news. The precedent worth noting is governance by kill-switch. A standing committee that can sever a route within hours is now a load-bearing part of cross-chain safety, and protocols without one are relying on goodwill and working hours.

Aztec Foundation drew a line around the dead contracts. After both drains, the Aztec Foundation stated repeatedly that the affected products were deprecated years ago and have no link to the current network or the AZTEC token Aztec Foundation via NullTX. The claim is technically accurate and does nothing for the people who watched $4M leave the ecosystem in three days. It also sets an awkward precedent for how teams talk about immutable code they can no longer control. The disclaimer is accurate, but what users take away is that the money still left the ecosystem and the team’s name was on the contract.

What Else Happened

• Bridge proof-forgery. Taiko halted its Ethereum layer-2 and told users to abandon every bridge after an attacker forged withdrawal proofs and drained about $1.7M on 22 June, with BlockSec tracing the likely cause to a Raiko SGX signing key left in a public GitHub repository CoinDesk.

• Source-channel validation gap. Secret Network’s Axelar bridge lost about $4.67M to an infinite-mint flaw in a forked CW20-ICS20 contract that had quietly dropped its origin checks during an unaudited migration, letting an attacker spin up a single-validator chain and forge deposits that minted unbacked wrapped tokens Common Prefix via The Block.

• Missing access control on dead code. Aztec’s deprecated infrastructure was drained twice, on 14 and 17 June, for roughly $4.3M combined, after attackers fed forged proofs to an escapeHatch function that carried no owner check and a verifier that accepted proofs with the rollup size set to zero SlowMist via The Crypto Times.

• Actively exploited RCE in your monitoring stack. Attackers are exploiting CVE-2026-20253, an unauthenticated remote code execution flaw in Splunk Enterprise, and CISA added it to its Known Exploited Vulnerabilities catalogue with a federal patch deadline of 21 June SecurityWeek.

• Memecoin reserve drains on BNB Chain. A logic flaw in the OLPC/LABUBU pool was milked for about $1.1M, part of a steady run of small fee-on-transfer and reserve-skew drains that rarely make headlines but never stop SlowMist.

• Wallet-stealing mobile malware. Researchers detailed Rokarolla, an Android banking trojan that targets 217 banking and crypto apps and can lift PINs, intercepted SMS codes and wallet funds, a reminder that the phone in a treasury signer’s pocket is part of the attack surface.

Patch Notes

• Splunk. If you run Splunk Enterprise and have not patched, you are already past the federal deadline and the flaw is being exploited in the wild. Patch today and hunt for signs you were reached first.

• Mastra and npm. Anything that ran an @mastra install after 16 June should be treated as compromised. Rotate every credential reachable from those machines now, and move any funds controlled from them to keys created on a clean device.

• Taiko. If you hold anything in a Taiko bridge, withdraw it and do not bridge to or from the network until the team issues an official all-clear.

Long Reads

• Thirdweb on the Jared approvals honeypot. The clearest builder-facing breakdown of dangling approvals, with the exact pattern any team integrating approve should read before shipping.

• SlowMist on the Aztec escapeHatch drains, alongside BlockSec’s note that both incidents shared a public-input binding failure. Worth it if you maintain any verifier that accepts caller-supplied proof inputs.

• Microsoft Threat Intelligence on the Mastra compromise, alongside JFrog’s loader and C2 reconstruction. Read the Microsoft piece for attribution and the JFrog work for indicators you can hunt on tonight.

• Common Prefix on the Secret Network infinite mint. A precise account of how removing two source-validation checks in a forked IBC contract turned a year-old bug into a $4.67M drain. Mandatory if you maintain custom token-handling on IBC.

• Perimeter on the $69M Polkadot near-miss. The week’s counter-example. A researcher caught an XCM origin-isolation flaw through targeted fuzzing before anyone lost a cent, for a $75,000 bounty. A good argument for funding fuzzing on any protocol with caller-supplied inputs, since these semantic bugs rarely surface as crashes.

Closing Tab

Taiko promised a full post-mortem on the signing key it left in a public repo, and the thing to watch before the next issue is whether it points to a fix the year's other bridge drains could have used or just records one more secret that should never have been committed.

Adrian Hetman Burn Notice Operational intelligence for Web3, every week

We are still in the trial-and-error phase of AI and Web3 security, and nobody has run it long enough to know how it settles. People are already asking the obvious question, and the ones who do this for a living ask it most anxiously. Does AI take the security researcher’s job? The honest answer depends on which layer of the system you mean. On the contract layer, where someone once read the code line by line, AI is taking over that slow manual work, and the expert is moving up the ladder to the work a machine cannot do.

Consider what the tools already do. They run as clusters of agents that watch a codebase around the clock, and formal verification is moving into the code-generation loop itself. Certora’s AI Composer checks AI-written code against mathematical rules before it runs, and Vitalik Buterin has argued that pairing AI-generated code with machine-checked proofs is the most credible path to secure software as AI grows better at breaking it. The floor under a newly deployed contract is rising, and the standard for calling one secure has risen with the tools that test it.

This is what moves the auditor up the ladder. The line-by-line reading, the checks against known patterns, the easy findings, all of it now goes to the agents, and what lands on the researcher’s desk is a pile of machine output that someone has to sort. The machine finds the obvious bug faster than any person can, so the skill that matters now is judgement, knowing which of the findings is real, which is noise, and which one matters for this particular protocol. Because both attacker and defender hold the same tools, the advantage belongs to whoever can read what the machine produced and understand it, and that judgement sits well above the grind it replaced.

But the contract / code was never the whole system, and the audit that vouches for it has a narrower reach than the badge suggests. An audit certifies a frozen commit, a snapshot of the code as it stood on the day it was read, while the protocol goes on shipping upgrades and new integrations until that snapshot no longer matches what is running. Formal verification has the same limit. Vitalik makes the point plainly in the same essay, that you can prove one part of a system correct and still lose to a bug in the parts you left unproven, or to the hardware underneath. The proof describes a map, and the attacker is loose in the territory the map leaves out.

That area is where the money now leaves. The largest losses of the past two years came from outside the contract code entirely. More than $3.4 billion was stolen in 2025, and the single biggest theft, roughly $1.5 billion from Bybit, came through a compromised third-party integration that tricked the people holding the keys into approving it. Closer to the shape of a normal protocol, one compromised laptop at Humanity Protocol carried enough keys to clear two multisigs, and the attacker used them to seize the bridge and upgrade it to a malicious version. No contract was broken in either case. The way in was a stolen key, the Shai-Hulud worm spreading through the npm registry, an employee who clicked the wrong link. Meanwhile the losses on the contract layer were drifting lower, because that is where the tooling and the incident response had improved.

We learned to defend the contract because that is where the whole field has trained its attention, and we left the rest of the stack, the keys and the pipelines and the people, to look after itself. That is why it stayed open. I set out the full case for this in a report on this year’s operational losses.

So moving up the ladder is only half of what the job now asks. The expert also has to move outward, to the off-chain code that nobody formally verifies, to the access controls sitting above the contract, to the deployment pipeline, and to the people who hold the keys. These are the failures that live above the code, and they are the ones that have been paying out. Used well, AI arms that expert, the way the scanner and the fuzzer armed the generation before, and the people who read it as a reason to do without the expert have the lesson backwards. They overestimate what the model does on its own and underestimate how much still rests on a person who understands where the real risk has gone. We are early, and the tools will only get better. My bet is on the people who treat the model as a tool, learn to aim it well, and point it at the parts of the stack the badge on the website never covered.

— Adrian

P.S. There is one thing the ladder model leaves unresolved. The grind we are handing to the machines was also how people learned the craft. You read ten thousand lines of someone else’s code by hand, and somewhere in that tedium you earned the judgement to know which finding matters. Hand all of it to the agents, and the junior never does the reps. I do not have a clean answer to where the next generation of experts comes from once the training ground is automated, and if you are running a team, that is the question I would be sitting with.

Two teams shut their bug bounty programs in the past two weeks. Zcash Community Grants closed its vulnerability bounty program, and a researcher went public after THORChain told it the bounty was permanently retired. Both blamed the same thing, a rising flood of AI-generated reports clogging the queue. I used to run triage for programs like these. I understand the impulse. It is still the wrong call.

A bounty earns its place when the noise is loudest. It is the one easy, paid, legal way for a researcher who found your bug to bring it straight to you. Close it and every bug is still there. You have removed the path the honest finder would have walked.

Look at the economics. A researcher who finds a critical flaw has a choice. Report it for a reward, or do something far worse with it. The bounty is what makes the first choice the rational one. Earlier this year a researcher reported a critical Polkadot XCM flaw through the bug bounty program. The flaw let any account run calls as root on the relay chain and drain the sovereign accounts behind other chains. It was caught and patched before anyone used it. That is the trade.

So run one. The question is who runs it. Six years of DeFi loss data shows the templated attacks closing off one by one, while the losses that remain come from unique flaws buried in a single protocol’s logic. Those bugs are specific to your code, and finding them takes more skilled eyes than you will ever put on staff. That is the argument against self-hosting. An external platform gives you a pool of researchers you could never assemble yourself, and a triage layer between you and the raw queue. Run it in-house and every report lands on the same engineers already shipping the code. A program on Immunefi, HackerOne, or Bugcrowd gives you the reach and takes the first pass off your desk. The fee is cheap against the cost of going without.

The reason both teams gave is real. The slop is real. Anyone running triage this year has watched the AI-generated noise climb, and clearing it costs hours. But the fix is to size it down. Agree a triage tier with your provider. Run your own filtering on your side, close to theirs, and keep a human expert on top of whatever the AI flags. You handle the part that gets through. The platform eats the rest. Giving up the whole signal to dodge a slice of the noise is a bad trade for anyone holding funds.

And the tooling will not cover for you. Yes, you can run the same AI scanners the platforms run. That tooling is the floor now, the part everyone already has. It catches the known patterns and the easy findings. It will not catch the flaw that is specific to your protocol, the one an attacker turns into a drain. That bug needs a human who knows your codebase and knows where to point the tooling. The model is a force multiplier for an expert who already understands the system.

So look again at what the two teams did. They cut the cheapest line in the stack and kept the most expensive one, the hack. The bounty was the thing that turns a stranger’s afternoon into a quiet patch, long before it becomes a post-mortem. Nobody owes you a free bug. The whole point of a program is that you stop needing them to. My bet is that one of the teams that just went dark pays for it inside a year, in a drain or in a quieter program rebuilt after the fact. If the noise is the problem, fix the triage. Do not pull the one alarm wired to the sound you most need to hear.

— Adrian

Subscribe now

P.S. A serious bounty costs a fraction of what it protects, and you pay only when someone hands you a real, proven bug. Skip that bill and you pay a worse one later. After the hack you are on crypto Twitter offering the attacker 10% of stolen user funds to send the rest back. It doesn’t work all the time, and plenty of protocols never recover from a hole that size. So set the rewards real high now and write clear rules around them. Pay a researcher to prevent the loss, or pay the attacker a 10% cut once it lands and lose everything else. Either way, you pay.

Three of this week’s incidents share a pattern. Each one hit infrastructure that the owning team had already deprecated and stopped maintaining. A wound-down Aztec Connect bridge contract was drained, a set of Raydium pools retired in 2021 was emptied, and two teams closed their bug bounty programs in the same period.

In today’s issue.

• How a deprecated Aztec Connect contract lost $2.19M with no admin key left to pause it.

• How the Verus bridge lost $11.6M to a value-binding flaw, in a bridge failure class first seen in 2022.

• Two vulnerability bounty programs shut their doors as AI-generated reports overwhelmed triage.

Need to Know

Most of this week's losses came out of the past, from contracts their teams had already deprecated to a bridge that fell to a value-binding flaw in a class the industry first paid for in 2022. Code that has been deprecated, frozen, or left unverified keeps holding funds and attracting attackers, and the bug classes draining bridges are old enough to carry name-brand precedents and known fixes nobody applied. Meanwhile the disclosure programs that would route a researcher's write-up to a team before an attacker's exploit are the thing closing, with two of them shutting this fortnight over a flood of low-signal AI-generated reports. If your treasury still sits behind old code or a bridge design somebody already broke once, who on your team is paid to go and find that out before someone else does? —Adrian

The Big One. Aztec Connect’s Drain on a Contract Nobody Could Pause

The news. On 14 June, an attacker drained roughly $2.19M from the RollupProcessorV3 contract, the last live piece of Aztec Connect, a privacy zk-rollup bridge Aztec Labs wound down in 2023. There was no reentrancy, no flash loan, and no compromised key. The cryptography held. The root cause was a settlement-boundary bypass, where the zero-knowledge proof committed to transaction slots the L1 contract never verified at settlement, letting the attacker withdraw assets the proof had never backed. The funds left in a single atomic transaction, around 909 ETH plus DAI, wstETH, and smaller positions, routed through Tornado Cash on the way in.

What broke and how. Inside RollupProcessorV3 there is a structural gap between the range the L1 settlement loop walks and the range the proof’s public-input hash commits to. The proof committed 31 of 32 public-input slots into the L2 state root while the settlement layer enforced only one of them, so the contents of the other slots reached the L2 accounting without ever passing an L1 check. The attacker ran the exploit across fourteen processRollup() calls in a single transaction, first inserting forged deposits into the unverified slots, then withdrawing those balances from the L1 pool as if they were genuine. The proof verified one transaction list while the contract settled another, and the fix is to make a rollup’s on-chain settlement scope cover exactly the public inputs its proof commits.

Why it kept happening. Aztec Connect launched in mid-2022, stopped taking deposits in 2023, and had its off-chain sequencer wound down, but the on-chain contracts stayed live with user assets still inside them. RollupProcessorV3 was upgraded in April 2024, after the sunset, with no external audit. The contracts later became fully immutable, so Aztec Labs holds no admin keys and cannot pause or upgrade the system, and when the drain started no operator could stop it, leaving public warnings and tracing as the only response. The same week, retired Raydium pools were emptied the same way and a six-month industry tally put its largest losses in unverified and legacy contracts, both covered elsewhere in this issue, and all three involve code the owning teams had treated as closed but left reachable on-chain.

What to check now.

• Pull a list of every contract your organisation has ever deployed that still holds a balance or a permission and is no longer in your active repo, monitoring, or front end, and treat anything labelled deprecated as live until its balance is zero.

• For any contract you upgraded after you stopped actively running the system around it, confirm that upgrade went through the same audit gate as a live deployment, because a post-sunset change is still a production change.

• Where a contract is immutable and cannot be paused, write down now what your only available response actually is, and confirm a named person is on the hook to execute it.

• If you run zk circuits, verify that the scope of your on-chain settlement verification matches the public inputs your proof commits, and test the boundary between the slots the proof covers and the slots the contract acts on.

• Decide who owns the question of when a retired system has its remaining funds moved to safety and its surface taken down for good.

Chain Reaction. Verus Fell to the Same Class of Failure as Wormhole and Nomad

The news. On 18 May an attacker drained roughly $11.58M from the Verus-Ethereum bridge by feeding the Ethereum-side contract a forged cross-chain transfer it accepted as genuine. The bridge checked the notarised Verus state root, the notary signatures, and the Merkle proof, with no key compromised anywhere, but never checked that the amount claimed on Verus matched the amount it paid out on Ethereum, a source-destination value-binding gap. Most of it came back within days through a negotiated bounty, the attacker returning about 75% and keeping the rest, which left Verus out roughly $2.8M.

What broke and how. The Ethereum-side contract did real verification work. It confirmed the root hash of the notarised Verus state, required eight of fifteen notary signatures, and validated the Merkle proof. What it never enforced was the economics. Nothing on the path required the payout on Ethereum to equal a real, locked deposit on Verus, so a forged transfer with a structurally valid proof could claim assets that were never backed. The attacker funded the wallet through Tornado Cash about fourteen hours ahead, took 1,625 ETH, 147,000 USDC, and 103.6 tBTC, and consolidated the haul into roughly 5,402 ETH. Verus had marketed the bridge as trustless and had shipped an emergency update for a separate issue two days earlier that did not touch this path.

Why it kept happening. Verus sits in the oldest family of bridge failures there is, where a destination chain releases assets against a cross-chain message that was never tied to an equal, locked deposit on the source. Calling it the same bug as the famous 2022 cases would be too neat, because the exact flaw differed in each. Wormhole’s attacker spoofed a Solana sysvar account to bypass signature verification and mint 120,000 wETH that nothing backed. Nomad’s upgrade set its trusted root to zero, so every message read as already proven. Verus did the verification work, checking the state root, the notary signatures, and the Merkle proof, and skipped only the check that the payout matched a real deposit. The three are different bugs that share one blind spot, which is that cryptographic validity was never bound to economic validity. The fix is the same in each, to assert that what leaves equals what was locked on every path. Teams keep rebuilding that blind spot because each one learns the lesson from its own incident rather than the ones before it.

What to check now.

• For every bridge or cross-chain message handler you run, confirm there is an explicit check that the value released on the destination equals the value locked on the source, enforced on every path rather than only the common one.

• Treat proof verification and value verification as two separate jobs, because a valid Merkle proof over a forged or unbound amount still passes.

• Pull the Wormhole and Nomad post-mortems and the Verus analysis, and test your design against each specific failure, because the mechanism differed in all three.

• If you call a bridge trustless in your own marketing, write down which checks earn the word, and have someone outside the team try to break the binding between the two chains.

The operator move.

Open your bridge and find the line that asserts the amount paid out equals the amount locked. If it takes you more than a minute to point at it, you do not have it, and you are one forged proof away from joining a list that already runs Wormhole, Nomad, and now Verus. Read all three before you ship another release.

— Adrian

Around the Forums

Zcash Community Grants closes its vulnerability bounty program. ZCG shut down its Vulnerability Bounty Program and Security and Vulnerability Disclosure Initiative, keeping responsible disclosure open only through private channels, and framed the move around AI-assisted tooling changing how bugs are found, reported, and duplicated. The community read closer to budget and triage, with ZcHub noting the program closed as AI-generated reports drove up the triage burden. It landed days before the Orchard soundness bug went public, which this newsletter walked through last issue, and a fully shielded network now has one fewer paid channel pointed at exactly the kind of circuit that bug lived in.

THORChain’s bounty is called permanently retired as a researcher threatens to publish. V12, an automated-auditing startup, says it reported a critical loss-of-funds bug, that THORChain silently patched it without credit or payment and told the firm the bounty is permanently retired, and that it is holding additional chain-halt findings it intends to disclose openly alongside published proof-of-concept code. THORChain’s account is that the self-hosted program was retired in March, before the firm’s late-April submission, because of low-signal report volume, though the protocol’s own security pages still advertise a bounty for verified critical bugs. A protocol fresh off a vault loss in May is now in an open dispute with a researcher sitting on unpatched findings, with its own documentation contradicting what it told the firm.

What Else Happened

• LP-mint validation flaw on Raydium’s legacy AMM V3. On 10 June an attacker used a fake mint address to bypass validation in Raydium’s AMM V3 pools, retired from the exchange’s interface and SDK since the 2021 Serum shutdown but still funded on-chain, draining about $1.34M from five deprecated pools. Raydium confirmed its treasury will cover the loss and that no active users were exposed, and its contributors opened a review of live programs for the same gap.

• Admin-key compromise on the MILC cross-chain bridge. A historical MILC bridge admin wallet was used to grant DEFAULT_ADMIN_ROLE and MANAGER_ROLE to an attacker-controlled address on BNB Chain and Ethereum, which then drained the bridge and took over its admin control for around $161K, roughly 97,000 USDT plus 39 ETH moved via Rhino.fi.

• Protocol-owned liquidity drain on Dexlyn. Dexlyn said malicious activity hit its protocol-owned liquidity wallets and that user deposits were unaffected, with the team coordinating an on-chain trace and a whitehat bounty with Supra while the loss figure stays undisclosed.

• Supply-chain compromise of the Mastra npm scope. On 17 June an attacker used a former contributor’s account to republish 141 packages under the @mastra/* scope, each carrying one injected dependency, easy-day-js, a clone of dayjs whose postinstall hook drops a crypto-stealing remote access trojan. The package source was left untouched, so source review of @mastra/* shows nothing and only install-time scanning catches it.

• Supply-chain compromise of the Arch User Repository. Researchers disclosed Atomic Arch on 11 June, a campaign that took over hundreds of orphaned AUR packages and rewrote their build scripts to install a malicious npm package, atomic-lockfile, that harvests credentials and SSH keys and drops an eBPF rootkit where it lands root. The packages’ own code never changed, and the attackers inherited trust by adopting projects their maintainers had abandoned rather than typosquatting.

On the Clock

Two clocks this week. The first is the supply-chain pair in the roundup above. If your CI or any developer machine pulled from the Mastra npm scope or adopted Arch AUR packages in the early-June windows, treat those hosts as compromised, rotate every credential reachable from them, and rebuild any box where the payload may have run as root. The second is a posture decision rather than a patch. If you run any contract you have deprecated that still holds funds, treat this week as the deadline to inventory it and decide your only available response, because the settlement and validation bugs that hit Aztec Connect and Raydium are being found in exactly that kind of retired code right now.

Long Reads

• SlowMist on the Aztec Connect settlement-boundary bypass, the cleanest reconstruction of the slot-range gap from contract source and on-chain calldata, worth reading alongside The Defiant on why an abandoned contract had no operator left to stop it if you run anything on a zk rollup.

• Chainalysis on the $36.7M drained from unverified DeFi contracts over six months, led by a Truebit contract unverified since 2021, for the data behind the claim that hiding source code has stopped working as a security control now that decompilation and models are cheap.

• Perimeter on the Polkadot XCM origin-isolation bug it disclosed for a $75K bounty, a clean walk-through of how a missing AliasOrigin or ClearOrigin step combined with a surviving ReserveAssetDeposited instruction could have minted unlimited unbacked cross-chain assets, around $69M at risk, worth reading if you handle cross-chain messages and want the defensive version of the bug Verus shipped.

  Thanks for reading Burn Notice Newsletter! This post is public so feel free to share it.

  Share

The Operator’s Read

Decommissioning Is the Stage Nobody Owns

Most teams have a deploy runbook, and after enough bad nights most have an incident runbook, but almost none have a plan for the day a system is meant to be switched off for good. The shutdown gets a Slack message and a calendar reminder nobody acts on. This week showed what that missing stage costs.

The Aztec Connect contract that lost $2.19M was sunset in 2023. Deposits stopped and the off-chain sequencer was wound down, but on-chain the contract still held user funds and still had every permission it was granted at deploy. It was upgraded once more in April 2024, after the sunset, and that change never went through an external audit. The contracts were later made immutable, so Aztec Labs held no keys and could not pause anything, and when the drain started the only response available was a public warning.

Deprecating a contract is an internal decision about budget and attention, and it does not change anything on-chain. The team stops monitoring, the engineers move to the next project, and the contract keeps its balance and its permissions exactly as before. Raydium saw a cheaper version of this when five of its 2021 pools were drained through a fake mint address, pools that had been gone from the front end and the SDK since 2021 but were still funded on-chain. Raydium could cover the loss from its treasury, which most teams carrying abandoned contracts cannot.

The same problem reaches code that was never verified rather than code that was sunset. Chainalysis counted $36.7M of losses over six months in unverified contracts, led by a Truebit contract that has been unverified on Ethereum since 2021. The assumption behind leaving source unpublished was that nobody could read the bytecode. That has stopped holding, because decompilation is good and models are cheap, and an attacker now reads an unverified contract about as easily as a verified one. Not publishing the source buys a delay and little else.

What connects these cases is ownership. A deployment has an owner and an incident usually has one too, but no one is given the job of shutting a system down properly. Funds stay in contracts the organisation has stopped thinking about. Permissions remain assigned to keys nobody rotates, and the surface stays reachable for years because closing it was never anyone’s objective. The DxSale lockers drained in late May, 2021 contracts whose ownership had been quietly moved and whose unlock was backdated to 1970, were the same story a month before Aztec, and that one does not even fall inside this issue’s window.

The channel that would normally catch a bug in forgotten code is also narrowing. Two teams closed their disclosure programs this fortnight, both citing the volume of AI-generated reports, which the forums section covers above. The cost for an attacker to find a flaw in old code is falling at the same time as the paid route for an honest researcher to report one is being cut.

There is a tactical response and a strategic one. The tactical response is the operator move above and takes an afternoon. The strategic response is to treat decommissioning as a real stage with an owner and a clear definition of done, meaning a zero balance, permissions renounced or moved to a key the team still controls, and the contract watched until it can be shown to be empty.

My expectation is that within a year one of these forgotten-surface drains passes nine figures, and the post-mortem will note that the team believed the system had been shut down years earlier. The tools to find these contracts are cheap and the balances in them are large, while the teams that deployed them have stopped watching. Teams that handle this well will treat “we deprecated that” as the beginning of the work.

— Adrian

P.S. A quarterly dead-contract audit becomes one more box to tick and changes little. What actually shrinks the surface is moving the funds out and giving up the permissions, since a contract with no balance and no powers is one an attacker can study at leisure and do nothing with.

Closing Tab.

Watch whether the next major drain traces to a bug a working bounty program would have caught, now that two of them have gone dark in a single fortnight.

Adrian Hetman Burn Notice Operational intelligence for Web3, every week.

In the first half of 2026, the web3 industry recorded roughly around ~200 hack and exploit incidents, with hack-only losses of approximately $900M. Counting only the larger, well-documented events, the figure is closer to roughly around ~130. Including social-engineering and phishing theft, the all-in total rises to about $1.1B. The precise number depends on the reporting threshold, so the trackers differ, but the range is broadly consistent across them.

The single largest theft of the period was not a protocol hack at all. In January, one holder lost more than $282M in bitcoin and litecoin to a hardware-wallet social-engineering scam, with the proceeds laundered into Monero. It sits outside the protocol figures above and is counted only in the all-in total.

Among protocol incidents, two dominate the dollar total. Drift Protocol in early April and KelpDAO later that month account for approximately $577M between them, roughly 60% of all protocol hack and exploit losses for the period. Neither was a code bug. Drift followed a sustained social-engineering operation against multisig signers, and KelpDAO followed a compromise of bridge verification infrastructure.

2026 in numbers

2026, month by month Crypto hack losses and incident count by month.

April was the worst month by a wide margin at about $647M, almost all of it from Drift and KelpDAO. May saw the most incidents of any month, around 40, for a fraction of the loss. The gap between the month with the most money lost and the month with the most incidents is the year in miniature.

The biggest losses of 2026 Top protocol incidents by reported loss. Operational and infrastructure compromises in ember, smart-contract and economic exploits in teal.

Ranked by size, the year is top-heavy. The two April incidents stand apart, and the next tier, in the low tens of millions, mixes operational compromises with a smaller number of smart-contract and economic exploits such as Truebit and Rhea Finance.

The split between volume and value

The more important pattern is the relationship between how often a failure type occurs and how much it costs. In the first quarter of 2026, 28 of 44 recorded incidents were smart-contract exploits, the kind that audits target, yet those incidents produced under a fifth of the quarter’s losses. Phishing, social engineering, and access-control failures, including stolen keys and compromised cloud infrastructure, were the minority of incidents but roughly three-quarters of the dollars lost. The same direction holds across the year to date, with compromised wallets and keys overtaking code vulnerabilities as the dominant source of losses by value.

The split between volume and value Operational and infrastructure compromise against smart-contract code, by share of incidents and share of dollars lost. Shares are approximate, drawn from published first-quarter and year-to-date root-cause breakdowns.

The long tail explains the gap. Most incidents are small code exploits in the tens or low hundreds of thousands of dollars, and there are many of them. They raise the incident count without moving the dollar total. The losses that matter financially are concentrated in a small number of operational and infrastructure failures, where a single compromised key, signer, or verifier can release tens or hundreds of millions in one transaction.

This has a direct consequence for where defensive effort goes. The smart-contract layer is the part the industry audits, fuzzes, formally verifies, and runs bug bounties against, and that work remains necessary, because code bugs are the most common incident type. It is no longer where most of the money is lost. The dollar risk has moved up the stack to keys, signers, devices, cloud infrastructure, and domains, and that layer is rarely subjected to the same scrutiny. Audits alone do not address it. One of the year’s larger infrastructure losses, Resolv, occurred at a protocol that had passed more than a dozen audits, because the failure was an off-chain signing key in a cloud account rather than a contract flaw.

The practical reading is that frequency and value call for different responses. Code bugs should continue to be managed through audits, bounties, and monitoring, because they are persistent and common. The catastrophic losses require treating the operational layer as security-critical in its own right.

Inside the operational compromises

The operational and infrastructure losses for the half-year total approximately $700M. The roughly around ~20 largest of them, examined here, carry the great majority of that figure, and they fall into five categories. Smaller key-compromise incidents run through the long tail and add to the count, but little to the total. Realised losses are used throughout, with paper figures noted where they differ.

Where the money went Realised loss by failure class across the operational-compromise incidents.

Where the incidents were The same operational-compromise incidents by count. Admin-key compromise was the most frequent and the least costly.

Within the operational category, the same inversion repeats at smaller scale. Admin-key compromise was the most frequent failure, eight of the roughly twenty, and the least costly, because available liquidity capped what a single over-privileged key could extract. The largest losses concentrated in social engineering of signers and infrastructure compromise. April alone accounts for approximately $575M of the operational total, almost all of it Drift and KelpDAO.

Admin-key compromise

Eight incidents involved a single privileged key or role with broad authority and no compensating control such as a timelock or a genuine multi-party threshold. Wasabi Protocol’s deployer account held the sole administrative role and was used to grant a malicious helper contract the access needed to upgrade its vaults. StakeDAO’s deployer key repointed a cross-chain peer and forged a token mint moments later. StablR operated a 1-of-3 minting multisig, which presents the appearance of a threshold while functioning as a single key. Realised losses in this category were limited by available liquidity rather than by the access controls, and most drained in a single transaction.

Social engineering of signers

One incident, Drift Protocol, produced the single largest protocol loss of the half-year at approximately $285M. Threat actors attributed to North Korea spent roughly six months establishing a trusted relationship as a trading counterparty before persuading Security Council signers to pre-sign transactions through Solana durable nonces. A 2-of-5 threshold with no timelock meant two compromised approvals were sufficient to transfer control. The contracts themselves were not exploited.

Employee and developer device compromise

Two incidents originated from compromised endpoints. Step Finance lost approximately $27M after attackers compromised executive devices and used them to reach treasury and fee wallets. Humanity Protocol operated a multisig of 3-of-6 on Ethereum and 3-of-5 on BSC, but enough owner keys were backed up to a single employee laptop that one compromised machine met the signing threshold on both chains at once. Throughout the period, poisoned VS Code and npm packages targeted developer machines as a delivery mechanism for the same class of credential and key theft.

Cloud and infrastructure key compromise

Four incidents, the most costly category in aggregate, involved keys or verification infrastructure held off-chain. Resolv held a privileged signing key in AWS KMS, and an attacker who reached that environment, by way of a contractor’s retained credential from an earlier project, altered the signing-key policy and minted approximately $25M of unbacked stablecoin against a deposit worth a fraction of that amount. KelpDAO relied on a single off-chain verifier, which was induced to attest a forged message and released approximately $290M. Two further incidents are included with caveats. THORChain is more accurately characterised as a flaw in a threshold-signature implementation, and Gravity Bridge remains a suspected key compromise pending a post-mortem.

Domain and DNS hijack

Five incidents involved control of a project’s domain or DNS rather than its keys or contracts. CoW Protocol lost its .fi domain through registrar impersonation, and a phishing clone served from the hijacked domain caused approximately $1.2M in user losses over roughly four and a half hours. By contrast, OpenEden, Curvance, and HypurrFi faced comparable attempts and prevented user losses by detecting the unauthorised change early. The differentiating factor across this category was registrar hardening and DNS monitoring rather than budget.

Outlook

On the current trajectory, a further nine-figure loss originating outside the contract is a realistic expectation for the second half of 2026. The incentive is established, the access remains comparatively soft, and recent activity shows attackers favouring social engineering and infrastructure compromise over attacks on well-audited contract code. North Korean threat actors are credited with between 55 and 76% of all crypto hack losses so far in 2026, depending on the period measured, almost entirely on the basis of the two April incidents. The volume of small code exploits is unlikely to fall, but it is the operational layer that determines whether a year produces another $577M concentration. Organisations that bring that layer under the same scrutiny as their contracts will be best positioned to stay out of the next set of post-mortems.

What security leads should do

The defences for every category above are established and inexpensive relative to the losses they prevent. The recurring gap is ownership. This layer is seldom assigned to the security function, so it is seldom audited. The following actions, in priority order, close the most exposure for the least effort.

1. Inventory privileged access. Enumerate every key, role, signer, device, cloud identity, and domain that can move funds or change code, and map each to a named owner and a specific device. Several of the incidents above were possible because no current inventory existed.

2. Enforce real thresholds and timelocks. Require a 3-of-n minimum on any function that can mint, upgrade, or transfer ownership, with signers that are genuinely independent. Place a timelock in front of upgrade and treasury functions so a malicious transaction is observable before it executes.

3. Verify signer independence. Confirm that no single laptop, browser profile, or key backup can produce more than one signature on a high-value multisig. A threshold scheme provides no protection once its keys share a device.

4. Treat endpoints as key custody. Deploy EDR on every machine that touches a key, prohibit key material on workstations, and require hardware signing so a key never exists in a form an endpoint can leak. Extend supply-chain controls to developer tooling and dependencies.

5. Harden cloud and verification infrastructure. Where a signing key must reside in a cloud KMS, secure the controlling identity more strictly than the chain it protects, with least-privilege roles, hardware-backed access, and alerting on every privileged call. Avoid single-verifier designs for any off-chain verification.

6. Lock and monitor domains. Apply registry-lock and registrar two-factor authentication, and monitor DNS and TLS certificates with alerting on any unauthorised change. Early detection was the only difference between the contained domain incidents and the costly one.

7. Rehearse the post-compromise case. Exercise key-rotation and incident runbooks against the scenario in which the signing threshold has already been crossed, not only the single-key-leak case.

8. Match the audit budget to the value at risk. Smart-contract audits remain necessary for the high volume of code bugs, but they do not cover the layer that lost most of the money this year. Give keys, signers, devices, cloud identities, and domains a review cadence and budget comparable to contract audits.

— Adrian

Subscribe now

Sources and method

Totals cover hack and exploit incidents from 1 January to 11 June 2026, reconciled across several incident trackers whose figures differ by threshold and by whether scams and phishing are included. Hack-only losses are approximately $900M, or about $1.1B including social-engineering and phishing theft. Incident counts range from roughly around ~130 for major events to roughly around ~200 once the long tail is included, and June is partial, through the 11th.

Incident data and root-cause breakdowns are drawn from project disclosures and from PeckShield, CertiK, DefiLlama, Hacken, TRM Labs, SlowMist, SEAL, Chainalysis, Blockaid, and the LayerZero post-mortem with Mandiant and CrowdStrike, alongside reporting from Rekt, The Block, CoinDesk, and Cointelegraph.

Three incidents this week, and the through line runs through everything an audit tends to leave out. A compromised employee laptop cleared multisig thresholds on two chains. An AI auditor surfaced a four-year-old soundness gap in a shielded circuit, while a single wallet bought its way to controlling a DAO and minted itself a payout.

In today’s issue.

• How one employee laptop held enough keys to take Humanity Protocol’s bridges on both Ethereum and BSC.

• Why Opus 4.8 surfaced a Zcash Orchard forgery bug that survived four years of expert human review.

• A one-transaction DAO takeover that drained a Balancer pool, plus the fake Sentry alerts aimed at your coding agent.

Need to Know

Two of this week's three headline events were losses, one through compromised keys and one through a governance takeover. Humanity's signers were nominally spread across a multisig, yet they sat close enough together that one compromised device could act for all of them, and a thinly held DAO changed hands the moment an attacker bought a majority of its own vote. The third event was the opposite of a loss, an AI auditor catching a forgery bug that years of human review had missed, the same week attackers were aiming forged alerts at AI coding agents. If your threshold is above one but your keys ride on the same laptop, what is that threshold actually protecting you from? — Adrian

The Big One. Humanity Protocol’s $36M Laptop

The news. On 8 June, an attacker took ownership of the ProxyAdmin behind Humanity Protocol’s Hyperlane bridge on Ethereum, upgraded the bridge to a malicious implementation, and moved roughly 141.2 million H in a single transaction. The same operator repeated the takeover on BSC and deployed a contract with an unlimited mint function, pushing the combined impact past $36M across both chains. Every action used legitimately authorised keys.

What broke and how. On Ethereum, three of the six Gnosis Safe owner keys controlling the bridge’s ProxyAdmin were compromised. That was enough to transfer ProxyAdmin ownership to a wallet the attacker controlled, swap in a malicious bridge implementation, and drain the bridge in one move. On BSC, three of five Safe owner keys went the same way, and the attacker minted just over 200 million fresh H in two tranches straight to their own address. A third, smaller leg took around 6 million H from an admin hot wallet, for a total impact the team puts near 447 million H.

The single point underneath all of it was an employee laptop. Founder Terence Kwok said the device was compromisedand held enough active private keys to cross the signing threshold on both chains at the same time. The attacker later left an on-chain note saying they had braced to social-engineer several developers across time zones, only to find the keys sitting together on one machine. The multisig existed on paper, but in practice it behaved like a single signer.

Why it kept happening. This is the same failure that ran through 2026’s headline losses. Kelp DAO, Resolv, and the Gravity Bridge drain elsewhere in this issue were written off in the press as bridge bugs, when the keys and the signers were the real failure each time. A threshold scheme only buys you safety when the signers are genuinely independent. Once the keys share a laptop, a cloud sync, or one human’s browser session, the n-of-m is theatre. ZachXBT first read Humanity as a possibly staged exit for an active market maker ahead of the 25 June unlock, then walked that back after tracing the laundering, concluding the suspicious market-making and the key compromise were unrelated.

What to check now.

• Map every signer on your highest-value multisig to a physical device and a named human, and confirm no single laptop or browser profile can produce more than one signature.

• Treat any ProxyAdmin or upgrade-authority key as a higher tier than ordinary signers, and put a timelock in front of upgrades so a quiet implementation swap cannot settle in one block.

• Pull the full list of addresses that can mint, upgrade, or migrate, and ask who would notice within minutes if one of them fired tonight.

• Rehearse the key-rotation runbook against the case where the threshold is already crossed, not the case where one key leaks.

The operator move.

Go count how many of your signing keys could be sitting on the same machine right now. If that number is higher than your threshold minus one, your multisig collapses to one device under a single compromise, and the rest is decoration. Fix signer independence before you add another signer.

— Adrian

Chain Reaction. Zcash’s Four-Year Orchard Forgery Bug

The news. On 29 May, independent researcher Taylor Hornby surfaced a soundness bug in Zcash’s Orchard shielded pool during an audit Shielded Labs had engaged him for back in April, working with a custom auditing framework built on Claude Opus 4.8. The flaw lived in the elliptic-curve multiplication gadget in the halo2 circuit, an under-constrained check that let a prover feed false values the network would still accept as a valid proof. In a local test the exploit minted unlimited counterfeit ZEC. No funds were lost on mainnet.

What broke and how. Orchard has been live since May 2022, which means the gap sat in production for roughly four years and through multiple rounds of expert human review. The bug allowed forging or double-spending value inside the shielded pool, and because Orchard hides amounts and participants, an exploit would have left no on-chain fingerprint. Shielded Labs has said it cannot prove cryptographically that nobody used it, only that turnstile accounting shows no unauthorised supply while the flaw was live.

The response was quick. A soft fork through Zebra 4.5.3 disabled Orchard at block 3,363,426 on 2 June, and the NU6.2 hard fork re-enabled it with a corrected circuit a day later. ZEC still fell around 30% on the disclosure, and Shielded Labs is now floating a turnstile upgrade so anyone can verify the ZEC supply independently.

Why it kept happening. Under-constrained circuits are the most common finding class in zero-knowledge audits by a wide margin. Four years and several paid audits looked at this circuit and missed a single missing constraint, and what changed since was the cost of a thorough pass over a cryptographic component once a capable model could be aimed at exactly that layer. The same capability is already being turned the other way, with attackers crafting forged alerts to push coding agents into running malicious commands. AI now sits on both sides of the audit, and most teams have a plan for neither.

What to check now.

• If you run ZK circuits, prioritise constraint completeness in your arithmetic gadgets, and treat an under-constrained element as the default suspicion rather than the edge case.

• Ask whether your supply or value invariants are externally verifiable, or whether your own privacy guarantees would hide an inflation bug from you as well.

• Add a frontier-model audit pass to your pre-deployment process for the highest-risk components, and assume an attacker is running the same pass against your deployed code.

The operator move.

Take the component you have audited the most, the one you trust, and run a fresh model over it this week with a single instruction to forge or inflate value. The code that has survived the most review is the code most worth pointing new tools at. Budget a day for it before someone else budgets a day for you.

— Adrian

Around the Forums

Zcash ships its second-ever security-driven upgrade. The Orchard fix went out as a coordinated two-phase response from the Zcash Foundation and Electric Coin Company, a soft fork to freeze Orchard followed within a day by the NU6.2 hard fork to re-enable it on a corrected circuit. The technical detail is in Chain Reaction above. What matters at the governance layer is that a fully shielded network managed an emergency upgrade fast enough to patch before any provable exploitation. It is now proposing a standing turnstile mechanism so that supply verification stops depending on trusting the core team’s word.

A legacy Aragon config hands over a DAO in one transaction. The Token of Power takeover, covered below, ran on an older Aragon setup that allowed proposal creation, voting, and execution in a single transaction with no timelock. Any DAO still on a legacy MiniMeToken framework with a small float should read this as the precedent it is. The configuration permitted a single wallet to propose, pass, and execute a mint in one transaction, and the attacker did exactly that.

What Else Happened

• Source-destination value binding gap on Gravity Bridge. The Cosmos-to-Ethereum bridge lost $5.4M on 30 May after an attacker minted worthless tokens on Osmosis, poisoned the denom-to-ERC20 registry with a fabricated denom string mapping fake balances to real custody contracts, and withdrew the real assets. The official post-mortem is still pending, and early press framed it as a suspected key compromise.

• Governance takeover on Token of Power. An attacker bought 8,192 of TOP’s 16,384 total supply, crossed the 50% voting threshold, and pushed a single proposal that minted billions of new TOP with no timelock and no mint cap, swapping them against the TOP/WETH Balancer V1 pool for 944.2 WETH worth about $1.58M. The Balancer pool was only the exit route.

• Indirect prompt injection via forged Sentry alerts. Attackers abused public Sentry DSNs to plant fake error events designed to push a human or AI coding agent into running a typosquatted npx package that exfiltrates environment secrets to advisory-tracker[.]com. Sentry has published a security advisory and IOCs are public.

• Autonomous L2 bug discovery on Spark. The V12 agent found and built a working PoC for a cross-tree root overwrite in deposit-tree creation on Lightspark’s Bitcoin L2, where four non-unique fields let two deposits collide on the same root node. The bug was responsibly disclosed and fixed.

On the Clock

One item with a clock on it this week. If your team runs coding agents or auto-remediation against alert and log streams, treat the forged-Sentry campaign above as live. Assume any machine that may have run the fake diagnostic has leaked its environment, rotate every credential reachable from it, and stop letting agents execute commands lifted from alert bodies without an out-of-band check. The rest of this week’s incidents are post-mortem reading, not emergencies.

Long Reads

• Humanity Protocol’s incident breakdown on the three breach vectors, worth reading alongside ZachXBT’s threadwalking from a staged-exit hypothesis to a key-compromise conclusion, for a clean example of how laundering analysis separates the two.

• Rekt on the Gravity Bridge drain for how a bridge gets emptied by feeding it a registry entry it never validated.

• The Zcash disclosure from Zooko Wilcox and Shielded Labs for the clearest account of the constraint gap, the emergency forks, and the turnstile-upgrade proposal.

• V12 on the Spark L2 bug for a concrete look at an agent finding a non-obvious tree-integrity flaw end to end, and Noema Labs’ AutoCertora release if you want to point the same class of tooling at your own Solidity.

• Rekt’s supply-chain trilogy, stack-nobody-checked, paranoid-by-default, and poisoned-pipeline, if the forged-Sentry item has you reviewing how much your pipeline trusts by default.

The Operator’s Read

Point the Agents at Your Oldest Code

Two bugs got found the same way this week, and the way they were found is the actual story. An AI auditor went back through Zcash’s Orchard circuit and surfaced a missing constraint that had been sitting in a shielded pool since 2022. Days earlier, a separate autonomous tool pulled CVE-2026-23479 out of Redis, an authenticated route to running OS commands that shipped in 7.2.0 and survived more than two years across every stable branch. Both were old, both lived in reviewed and trusted code, and both stayed hidden until a machine read the right layer with enough patience.

I said last week that the contract layer is getting harder to break, and I meant it. Audits got sharper, and the obvious bug classes mostly get caught before they ship now. These two finds are what the next turn of that screw looks like. The bugs that remain are the non-obvious ones, the constraint that reads correct until you model what it forgets to forbid, the use-after-free that only fires when a blocked client gets evicted mid-command. A tireless reader with a strong model in front of it is built for exactly that shape of bug.

The Orchard one sits differently from a normal disclosure, for the reason I gave earlier in this issue. The Redis flaw is the familiar shape instead, a CVE with a patch and a version table.

Both sides of this are producing results. From where I sit, the offensive half is the part the celebration keeps skipping. The same capability that read Orchard and Redis is available to anyone who wants to read your code with intent, and the distance between how quickly a defender finds one of these and how quickly an attacker does has not closed. The tool is neutral. The outcome turns on who reaches for it first and what they aim it at.

That changes the economics of old code in a way most teams have not priced. For years the safe assumption was that the more eyes a component had passed, the less likely it was hiding something. That assumption is now backwards at the margin. The most-audited contract in your system is the most attractive place for a surviving bug, because everyone downstream treats it as settled and stops looking. A model does not care that the code is famous or that three firms signed off, it just reads what is in front of it.

The point I keep being surprised I have to repeat is that none of this means trusting the output blindly. These finds landed because professionals built scoped agents, aimed them at a specific layer, and then did the work of confirming a real exploit. The model proposes, and a human who knows the domain still has to prove it and avoid getting played by a confident wrong answer. Used that way, in skilled hands, it is the sharpest reviewer you can put on code you have already paid to have checked.

The single audit pass is the tactical version, and it is sitting in the operator move above. The strategic version is treating your legacy surface as a backlog with a clock on it. Rank your oldest, highest-value, most-trusted components by what an attacker gains if one of them turns out to hold a surviving flaw, and start working down that list with the new tooling before the list gets worked from the other side. The code you wrote in 2022 and stopped thinking about is the code most worth rereading in 2026.

My bet for the back half of this year is a nine-figure loss traced to a years-old bug that an attacker found with an agent before the defender did. The capability is here, the incentive is plain, and trusted-and-forgotten code is everywhere. The teams that get ahead of it will be the ones who put their oldest code back on the audit table instead of leaving it filed under solved.

— Adrian

P.S. The worst outcome here is the box-ticking one, where “we run an AI audit” becomes the new “we got audited” and carries just as little weight. The value lives in a competent person deciding what to point the model at and refusing to trust the first green tick.

Closing Tab.

Watch whether Humanity’s recovery plan actually re-secures the BSC ProxyAdmin the attacker still controls, or whether next week opens with a fresh mint from the same address.

Adrian Hetman Burn Notice Operational intelligence for Web3, every week.

Give a gift subscription

The contract layer has got harder to break, so the value has moved up. It sits in the authorisation layer now, the keys and modules and bridge signers and peer configs that decide who is allowed to move funds. That layer is the number one problem in Web3 security right now, expensive out of all proportion to how often it actually gets hit. And it draws almost none of the review the contracts do.

Look at May and you could almost miss it. Around $68M lost across the month, down roughly 90 percent from April, one of the quieter stretches of the year. The headline looks like progress until you read the breakdown.

Code bugs still did the most damage by raw dollars, somewhere around $45M of the total. So no, we have not solved smart contract security, and anyone telling you otherwise is selling something. But the severe, drain-the-protocol contract exploit is getting harder to pull off against live production code, and the monthly data has started to show it. Audits got sharper. The obvious bug classes mostly get caught now. That is the one part of this story that is actually going well.

Then look at the bridges. They were the single biggest category of loss in May, around $28.6M, more than 40 percent of everything stolen. The word bridge hides what these things actually are. A bridge is barely a smart contract. It is a set of signing keys deciding which withdrawals are real, with some Solidity wrapped around them for decoration. Almost every serious bridge loss this year came through the keys and the signers and the operational controls around them. Call it what it is. Opsec.

The incident counts get this wrong. Opsec failures are nowhere near the most common attacks. DeFiLlama logged 29 incidents in May and only seven were key compromises. But frequency is the wrong scoreboard. April makes the point with a sledgehammer. Two incidents that month, Drift and Kelp, took well over half a billion dollars between them. Both had audited, working contracts and lost the money one layer up, through a blind-signing failure and a subverted cross-chain verifier. Low frequency, total blast radius.

You do not have to go back to April. Last week alone produced a module signature flaw at Gnosis Pay, a stolen deployer key at StakeDAO that forged a multi-trillion token mint, a suspected signing-key compromise at Gravity Bridge, and a $3.2M drain of 86 Safe wallets through a third-party module. Not one of them needed a bug in the core contract, and each walked in through a module, a key, or a config.

You can read more about those issues below

None of this gets reviewed because none of it looks like attack surface. A module looks like plumbing, a deployer key like a leftover from launch, a peer config like a setting you touched once and forgot. An audit scopes the contract because the contract is the thing an audit knows how to price. The module added three sprints later to ship a feature, the key that was supposed to be temporary, the bridge signer quietly holding the authority to move everything, all of it arrives after the audit and outside it. That is the gap the whole industry is underpricing.

And the infrastructure and opsec layer is where recovery goes to die. Out of that $68M in May, only about $9.4M came back. A contract bug can sometimes be paused or patched or white-hatted before the funds are gone. A signing key that sends money to an attacker and then on through a mixer leaves nothing to claw back. Gone is gone. The failures that cost the most are the ones you almost never get to undo.

So if you run anything that holds value, do the one exercise an audit will never do for you. Write down every address, key, module, and config that can move your funds without touching the contracts you already paid to have reviewed. Then count them, name who holds each one, and ask when any of it last got looked at by someone whose job was to break it. The contract layer has earned its scrutiny. What sits above it has been running on trust and luck, and the bill keeps arriving in eight and nine figures.

How long is your list, and when did you last make it shorter?

— Adrian

Three of this week’s losses share a shape worth sitting with. The smart contracts behaved exactly as written and the money still left, because the authorisation wrapped around those contracts is where the real control lived. A signature checker in a Safe module, a deployer key that still held cross-chain config rights, and a bridge signing key carried this week’s drains between them.

In today’s issue.

• Gnosis Pay’s Zodiac Delay module accepted a queued transfer with no real signature behind it.

• A stolen StakeDAO deployer key repointed a LayerZero peer and forged a 5.4 trillion token mint.

• Gravity Bridge lost millions through its signing layer rather than its contract code.

Need to Know

The week’s headline failures did not touch a single line of vulnerable contract logic. They landed one layer up, in the modules, keys, and peer configurations that decide who is allowed to move funds. That layer rarely gets the review attention the core contracts do, even though it now carries most of the loss. If your last audit stopped at the contract boundary, what reviewed the authorisation wrapped around it? —Adrian

The Big One. Gnosis Pay’s Delay Module Approved a Signature It Should Have Rejected

The news. On 1 June an attacker drained funds from Gnosis Pay accounts without ever touching a private key. Each Gnosis Pay account is a Safe smart account wrapped in two Zodiac modules, a Roles module that authorises card spending and a Delay module that holds outgoing transfers for a roughly three minute cooldown. The break sat in how that Delay module checked the signature authorising a queued transfer.

What broke and how. The Delay module’s signature checker reads the signing bytes from the tail end of the calldata, after the normal module-call arguments. You can append arbitrary trailing bytes to ABI calldata for free, so a normal call ignores them while the module reads them as a signature. An attacker crafted those bytes as an EIP-1271 contract signature, set the vouching address to the Safe’s trusted signer, and pointed at a blob they controlled. The contract-signature path then handed validation to that signer and accepted a response carrying the magic value 0x1626ba7e while ignoring the staticcall success flag, so a contract that reverts but returns the right four bytes passed as a valid signer. The malicious transfer enqueued, the cooldown ran, and because executeNextTx can be called by anyone the Safe paid out. Zodiac’s own notice scoped the flaw to Roles Modifier v2 and Delay Modifier v1.1.0 where a Safe with a vulnerable fallback handler sits as a member, and confirmed Safe’s core contracts are unaffected.

Why it kept happening. This is the second Safe-module drain in eight days. Last week roughly $3.2M left 86 Safe wallets across Ethereum and Base through a third-party module called SquidRouterModule, where weak identity validation let an attacker run arbitrary calldata with no wallet signature, flagged by Blockaid and unrelated to Gnosis Pay’s code. Modules are how Safe gets extended, and they run with the Safe’s full authority while rarely getting the review the assets they guard receive. A team adds a module to ship a feature like card payments or routing, and that module becomes a second front door with full spending power behind it.

What to check now.

• Inventory every module enabled on every Safe that holds value, including ones added for one feature and never removed.

• For any module that verifies signatures, confirm the EIP-1271 path checks the staticcall success flag, not only the returned selector.

• Confirm signature material is read from a fixed, declared location and never from trailing calldata an attacker can append.

• Treat executeNextTx-style “anyone can finalise” functions as fully public, and make sure the only real gate is the enqueue authorisation.

• Review third-party modules with the same rigour as your core contracts, because they inherit the same authority.

A Safe with five modules has five contracts that can move its money, and most reviews still budget time for one. The module list is the first thing worth pulling on any account that matters, ahead of the balances and ahead of the signers.

— Adrian

Chain Reaction. StakeDAO’s Deployer Key Repointed a Bridge and Minted 5.4 Trillion Tokens

The news. On 27 May someone holding StakeDAO’s deployer key on Arbitrum used it to call setPeer on the project’s LayerZero v2 OFT contract, repointing the token’s trusted cross-chain peer to a contract they controlled on Ethereum. About 25 seconds later that contract sent a forged LayerZero message back to Arbitrum and the legitimate vsdCRV token minted 5,446,744,073,709 units to the attacker. Nothing in the contract was bugged, and the token minted what an authorised peer instructed it to.

What broke and how. The OFT standard trusts a configured peer on each chain to authorise cross-chain mints, and setPeeris an owner-level function. Whoever holds that key can name a new trusted source and then have it order mints with no ceiling. Blockaid and BlockSec’s Phalcon team both traced the incident to a compromised deployer private key rather than a logic flaw. The only thing that bounded the loss was liquidity. vsdCRV pools were tens of thousands of dollars deep, so the attacker converted part of the supply to about 43.78 ETH, roughly $91,000, before the price collapsed, against a paper value of hundreds of billions. StakeDAO closed the vsdCRV bridge, secured the Ethereum side, and said no mainnet funds were lost.

Why it kept happening. This is the same shape as a run of 2026 incidents where a single key with peer-config or admin rights on an OFT or bridge quietly equals total mint authority. The realised loss looked small only because the token was illiquid, and the same key on a liquid token is an open mint with no brake. A deployer key that retains setPeer after launch is a production signing key, and it almost never gets handled like one.

What to check now.

• List every address that can call setPeer, setTrustedRemote, or equivalent peer-config functions on your OFT and bridge contracts.

• Move those rights behind a multisig with a timelock, or renounce them once configuration is stable.

• Hold any deployer key that retains post-launch authority in an HSM or KMS, never a hot wallet.

• Alert on peer and trusted-remote changes the moment they land on chain, not after the mint clears.

• For low-liquidity tokens, remember the mint ceiling is set by the market and not by your contract.

The thing you keep noticing in this space is that a loss only looks contained because the market was too thin to cash out, which is luck wearing the costume of a control.

— Adrian

Around the Forums

Radiant Capital’s DAO has voted to begin a gradual wind-down after failing to recover from its October 2024 exploit, secure new financing, or rebuild usage. The roughly $50M loss put the protocol into a tail it could not climb out of, and the council is now choosing an orderly close over a slow bleed. The precedent worth noting is that an exploit’s real cost gets paid in the quarters of lost trust that follow, not the dollars that left on the day.

THORChain’s third incident update left the root cause of its recent vault exploit openly contested, with the team saying the future of the cryptographic systems securing the vaults is still under discussion. Watching a protocol debate its signing scheme in public is rare and the candour is useful. The open question for any threshold-signature operator reading along is whether they would even know which of their validators to distrust. Formal council votes were otherwise light this week.

What Else Happened

• Bridge signing-key compromise at Gravity Bridge. The Ethereum-to-Cosmos bridge lost about $5.4M on 30 May through its authorisation layer rather than a contract bug and halted its validators to investigate, a design that leans on a full validator set instead of a small multisig and still failed at the signing layer. Candidate for a dedicated treatment next issue.

• Unprotected admin key on DxSale. The 2021 BNB Chain liquidity locker was drained of roughly $7.3M across about 1,400 LP positions through an admin key a security firm had flagged as risky back in 2023.

• Mint-and-dump via a compromised key at Tessera DAO. An attacker minted 99 million TSR on BNB Chainroughly 19 hours before the public alert, swapped it for about $2.5M, collapsed the token by 99 percent, and routed the proceeds through a mixer, the same compromised-key-then-mint shape as the StakeDAO drain above.

• Laundering closes the door on KelpDAO recovery. The attacker behind April’s roughly $293M KelpDAO exploit has now moved nearly all of the stolen funds, leaving little realistic path to recovery.

• Open-source supply chain stayed under pressure. A compromised maintainer account pushed malicious code into AntV npm packages including a charting library with over a million weekly downloads, while CrowdStrike, Google, and the Shadowserver Foundation dismantled the Glassworm botnet that had poisoned more than 300 GitHub repositories aimed at open-source developers. Any crypto front-end or tooling team pulls from these registries.

On the Clock

Two items carry real urgency this week. If you run any Safe with a Zodiac Roles or Delay module enabled, check it against Zodiac’s security notice and complete the remediation before assuming you are clear, since most identifiable accounts are already resolved and the stragglers are now the targets. And any build that pulls the affected AntV packages should pin and audit those dependencies now rather than after the next install.

Long Reads

• THORChain’s own exploit report alongside TRM Labs on the multi-chain drain lays out what is known and what is still contested, including the live question of whether the threshold-signature stack itself was the weak point.

• rekt.news on the DxSale drain is worth it for the detail that the fatal admin key was flagged for a $500 fee years before it cost millions.

• BlockSec’s weekly Web3 security roundup breaks down the DxSale and SquidRouter incidents with root-cause notes, and its companion May monthly brief frames where the month’s losses actually landed.

• Elliptic on crypto governance argues for a governance model the author thinks already works, useful framing for any DAO operator rethinking council design after a week like this.

The Operator’s Read

The Audit Stops Where the Money Starts

The thing you keep noticing, watching how these systems get built and broken, is how much review effort still stops at the contract boundary. The Solidity gets read line by line. The module added later to ship a feature, the key that was meant to be temporary, the peer configuration that points trust at another chain, those get a glance and a shrug. They get treated as plumbing, when in practice they are the locks on the doors.

From where I sit the uncomfortable pattern of 2026 is that the contract layer has quietly got good. Audits are sharper, the obvious reentrancy and overflow classes mostly get caught, and the money has responded by moving up a level. Modules, deployer keys, bridge signers, peer configs. The authorisation surface. It is less glamorous to review and it carries almost none of the formal scrutiny, which is exactly why the value sits there now.

There is a tell in how thin the StakeDAO loss looked. Five point four trillion tokens minted, ninety one thousand dollars out, and a lot of relieved commentary about a contained incident. What contained that loss was thin liquidity and nothing the protocol actually controlled. The same key on a liquid token mints a nine figure hole. Calling it a near miss reads the lesson backwards.

So the question worth carrying into your own stack is the one the audit never asked. Has anyone reviewed the full list of things that can move your funds without ever touching the contracts you paid to have checked? How long is that list, who holds each entry, and when did you last make it shorter?

— Adrian

Adrian Hetman Burn Notice Operational intelligence for Web3, every week.

Two admin-style compromises this week, neither caused by a contract bug. Echo Protocol on Monad got mint-attacked for $76.7M on paper because its admin key carried no timelock and signed whatever the holder told it to sign. The SquidRouterModule, a third-party Gnosis Safe module, drained 86 Safes for around $3M in roughly two hours. In both incidents the contracts ran exactly as written, with the layer around them taking the entire loss.

In today’s issue.

• Echo Protocol’s $76.7M paper mint on Monad, held to ~$816K actual loss only by shallow chain liquidity

• 86 Gnosis Safes drained for ~$3M via a third-party SquidRouterModule on Ethereum and Base

• KelpDAO rsETH recovery closes; LayerZero post-mortem traces the breach to a March 6 developer compromise

Need to Know

Two of this week’s biggest losses came from configurations around the contract, not from the contract code itself, and the pattern is now consistent enough across 2026 to call the layer above the contract the load-bearing one. Echo Protocol on Monad ran the third headline DeFi incident of the year where a privileged action executed before any monitor could fire, and the SquidRouterModule drains turned 86 Safes into an unaudited co-signer arrangement that nobody on the affected operations teams could fully describe. LayerZero’s full forensic post-mortem on KelpDAO, also published this week, pushed the start date of that incident back to early March and pointed at the same upstream attack surface that Socket’s TrapDoor disclosure describes in technical detail.

The question every security lead should be carrying this week is which contracts in their own stack would behave exactly as designed if the key signing them, or the module attached to them, had been compromised six weeks ago.

—Adrian

The Big One. Echo Protocol’s $76M Paper Mint on Monad

The news. On May 18, 2026, an attacker used a compromised admin key on Echo Protocol’s Monad deployment to mint 1,000 unauthorised eBTC tokens with a paper value of approximately $76.7M. Actual extracted value was ~$816Kbecause Monad’s lending markets did not have the depth to convert the minted supply into real on-chain proceeds. Echo regained control of the admin key the same day and burnt the remaining 955 eBTC the attacker had not yet moved.

What broke and how. The eBTC contract worked exactly as written. The root cause was operational rather than technical. The admin role was secured by a single signature with no timelock, no minting supply cap, and no rate limit. The attacker granted their own wallet minting privileges, deposited 45 eBTC into Curvance as collateral, borrowed 11.29 WBTC (~$867,700), bridged the WBTC to Ethereum, swapped to ETH, and routed approximately 385 ETH through Tornado Cash. Curvance, on the receiving side, did not run a supply sanity check against the freshly minted collateral.

Why it kept happening. This is the third headline DeFi incident of 2026 with the same architectural choice at the centre, a privileged action that executes the moment the key signs it, with no window for monitors to fire or for signers to rotate. Drift’s $285M loss was a 2-of-5 multisig with zero timelock. KelpDAO’s $292M loss was a 1-of-1 DVN, structurally equivalent to a 1-of-1 multisig. Echo’s eBTC contract continued the pattern, with a single key holding mint authority. The only reason Echo did not match Drift and KelpDAO on headline loss is that Monad did not have the liquidity to absorb the trade.

What to check now.

• Inventory every privileged contract action in your stack and confirm whether each one can be executed by a single signature with no timelock between sign and effect.

• For any minting function, add a per-block or per-day supply cap that cannot be bypassed by the same key that holds mint authority.

• For any protocol that accepts another protocol’s tokens as collateral, add a supply-sanity check that compares delta-supply against an expected band before allowing borrows against freshly minted units.

• Move admin keys for any minting or vault contract off any machine that also handles email, code, or web browsing.

• Audit the lending markets that accept your tokens as collateral, since their missing sanity checks become your protocol’s tail risk in any minting-key compromise.

Echo’s contract did exactly what it was written to do, and the configuration around it carried the entire loss, which is the same story playing out across 2026’s admin-key incidents. A single admin key with no timelock and no rate limit is what we were calling a single point of failure on multisigs five years ago. The right question for your team this week is whether anything irreversible in your stack can be executed by a single signature before a monitor would have time to fire.

— Adrian

Chain Reaction. 86 Safes Drained Through a Module Each One Had Installed

The news. On May 25, 2026, Blockaid disclosed an ongoing exploit targeting the SquidRouterModule, a third-party Gnosis Safe module deployed on Ethereum and Base. Eighty-six Safes were drained for approximately $3M to $3.2M in roughly two hours, with all stolen tokens swapped into DAI through attacker-controlled Uniswap V3 pools and consolidated into a single wallet holding ~3.07M DAI. New Market Trading, whose per-user Safe accounts were among the victims, accounted $3.78M in user-side drains per QuillAudits’ analysis, with the same vulnerable contract and attacker EOA as the broader 86-Safe drain.

What broke and how. Per Blockaid, the attacker exploited the module’s executeSameChainActions() function to impersonate authorised delegates and execute swaps from victim Safes without owner signatures. The 86 affected Safes had all previously installed the SquidRouterModule with elevated privileges, and the module functioned as a pre-authorised co-signer with broad scope. Squid moved quickly to clarify that the vulnerable contract was not developed, deployed, or operated by the core Squid team despite the name on Basescan, calling it a third-party module that “independently integrated with protocols like Squid.” Squid’s own users and integrators were not affected.

Why it kept happening. Safe modules are a pre-authorised execution path. The Safe contract enforces ownership and threshold rules on the owners, but once a module is installed those rules do not apply to it, so an installed module functions as an additional co-signer with whatever scope the module’s own code defines. Those Safes trusted that the module’s executeSameChainActions() enforced the authorisation discipline the module operator implied, and that trust assumption did not hold. The same failure class shows up across 2026’s largest incidents under different names, where trust gets delegated to an off-contract layer and the contract has no way to verify the delegated layer behaved correctly.

What to check now.

• List every Safe-installed module across every multisig your organisation operates, including individual contributor Safes that hold protocol-side privileges.

• For each installed module, confirm whether it is a contract built and operated by your protocol, a contract from a vendor you have a direct relationship with, or a third-party integration whose code your team has not separately reviewed.

• Remove any module whose operator your team cannot name or whose code your team has not reviewed against your current threat model.

• For modules you keep, scope them as narrowly as the module supports, with per-token allowlists, per-chain restrictions, and per-counterparty allowlists.

• Audit the enableModule history of every production Safe, since any module installed during a personnel transition or during an active incident response is high priority for review.

A Safe module is a co-signer that does not ask the owners for permission. If your operations team cannot articulate, from memory and without reading the docs, what every installed module is authorised to do, the module list is your unaudited co-signer list. SquidRouterModule is the version of that question where the answer cost 86 Safes $3M in two hours.

— Adrian

Around the Forums

KelpDAO closes the operational rsETH recovery. KelpDAO transferred the final tranche of 20,373.72 rsETH into LayerZero’s lockbox contract on May 25, closing the operational portion of the recovery from the April 18 bridge exploit. Mints, redemptions, and rewards have been running normally since the May 14 reopening of withdrawals. The Aave side did not recover symmetrically. Aave’s TVL fell from $26.4B to below $14B in the weeks after the exploit and has hovered in the $13.9B to $15.1B band since, with no sign of returning to its pre-incident peak. The DeFi United multi-protocol coalition completing this recovery without a foundation, a regulator, or a centralised actor underwriting the process sets a precedent the industry will keep coming back to when the next bridge fails.

THORChain ADR-028 vote runs, criticism over keeping GG20. THORChain’s recovery proposal for the May 15 vault exploit opened to node-operator voting on May 22, with the protocol absorbing the loss through Protocol-Owned Liquidity, no new RUNE minted, and a 10% bounty offered to the attacker. The contested decision is the choice to keep GG20 in place, patched and upgraded, rather than accelerate the migration to DKLS that Silence Laboratories was already commissioned to deliver in late 2025. Pseudonymous analyst Bird argued that the initial exploit suggests the signing stack has a flaw in randomness generation or local signing isolation and that GG20 carries brittle assumptions that should not be left in production. Choosing to patch a primitive that has now been exploited in production is a defensible operational call only if the patch closes the actual class of flaw, and the technical details of the exploit have still not been publicly released as of the vote opening.

What Else Happened

• Polymarket internal-ops wallet, ~$600K POL, May 22. Six-year-old private key compromise in the rewards-payout backend wallet, confirmed by Polymarket developer Josh Stevens. User funds and market resolution untouched, and the affected wallet sat outside the UMA Conditional Tokens Framework adapter contracts. Drain rate was 5,000 POL every 30 seconds across 15 to 16 addresses.

• MAP Protocol Butter Bridge V3.1, ~$180K extracted, May 20. Cross-chain bridge contract bug. Per Blockaid, an abi.encodePacked collision across dynamic-bytes fields in the bridge’s retry verification path allowed a forged retry to pass the guard check. The attacker minted 1 quadrillion MAPO (4.8M× the ~208M legitimate supply), dumped roughly 1B fake MAPO into Uniswap, and extracted about $180K. MAP Protocol paused mainnet and announced migration to a new contract.

• Solv Protocol BRO reentrancy, May 3 (post-mortem published this week). ERC transfer callback minted BRO tokens before the calling function completed, allowing a recursive mint loop in the BitcoinReserveOffering contract. [rekt.news] Solv has since moved more than $700M in tokenised BTC infrastructure off LayerZerofollowing the KelpDAO fallout.

• WUSD.fi / GLOVE incentive abuse, ~$200K, May 25. Sybil attack on WUSD._englove. Each fresh msg.senderwrapping at least 100 WUSD while holding fewer than 2 GLOVE could mint up to 2 GLOVE via Glove.mintCreditlesswith no sybil resistance. The attacker used EIP-7702 helper contracts and a Morpho USDT flash loan to repeat wrap/unwrap cycles, harvest GLOVE, and dump it into Uniswap V3. [exvulsec on X]

• TrapDoor cross-registry supply chain, 34+ packages, May 22 onward. Socket disclosure on May 24 of malicious packages on npm, PyPI, and Crates.io targeting Aptos, Sui, and Solana developer environments. Payloads modify .cursorrules and CLAUDE.md files to weaponise AI coding assistants against the developer. [Socket]

• GitHub Actions supply chain compromise of actions-cool/issues-helper. All existing tags moved to a malicious imposter commit that steals CI/CD credentials from GitHub Actions workflows. [The Hacker News] Any crypto org using third-party GitHub Actions should pin to commit SHAs rather than tags and audit their last 30 days of workflow runs.

• Nx Console VS Code extension compromised, 2.2M installs. Version 18.95.0 executed a credential-stealing payload on workspace open. Affected users must update to 18.100.0 and rotate every credential the workspace could reach. [The Hacker News]

On the Clock

LayerZero applications running 1-of-1 DVN configurations need to re-pin to a multi-DVN setup before LayerZero Labs’ enforcement deadline catches them. The company has committed to refuse acting as the sole verifier on any channel going forward and has restructured its cloud infrastructure rather than patching it. THORChain v3.18.1 ships vault protections that node operators need in place before any v3.19 restart of trading. [Chain.Buzz]

For any developer in your organisation hit by the three supply-chain compromises covered in What Else Happened (TrapDoor, the Nx Console extension, or the actions-cool/issues-helper Action), treat every credential reachable from that workstation or workflow as compromised pending rotation. Detection times averaged minutes. Exposure windows of minutes have repeatedly been enough to reach deployer keys.

Long Reads

LayerZero Labs KelpDAO Incident Report (PDF). The most important reading of the week if you operate any system whose security depends on infrastructure run by another company. Prepared with Mandiant, CrowdStrike, and zeroShadow, with UNC4899/TraderTraitor attribution. The same DPRK group that hit Safe{Wallet} for $1.5B in February 2025. Worth reading alongside the Chainalysis companion analysis, which frames the exploit as a broken accounting invariant that lived outside the contract.

THORChain Exploit Report #1. The first official post-mortem from THORChain on the May 15 vault drain, including the response timeline and the rationale for the ADR-028 path. Useful both as a model of post-mortem communication and as direct input for any team currently running GG20 in production.

Socket on the TrapDoor crypto stealer supply chain attack. Primary technical breakdown of the cross-registry campaign, including encryption schemes, persistence mechanisms, and the full affected package list. Required reading for anyone running a CI pipeline that installs third-party packages.

The Operator’s Read

The Laptop Is the Attack Surface

Crypto security in 2026 still threat-models the contract and not much else. Audits get spent on contract code, bug bounties pay out on contract bugs, post-mortems start at the transaction hash. Several of the headline losses of recent years have come from somewhere upstream of that transaction hash, on a laptop nobody in security has touched.

From where I sit, that is the gap. Auditing a contract is the “easiest” job in the stack because the contract sits in public, runs deterministically, and gets reviewed by every researcher as long as the project runs a Bug Bounty Program and/or have an Audit Competition.

The developer’s MacBook runs whatever they npm installed on Tuesday, with whatever permissions they were granted in their first week of onboarding, behind whatever antivirus the IT vendor renewed in 2021. The asymmetry of attention is the entire story.

The 2026 receipts are not subtle. Socket disclosed 34+ malicious packages across npm, PyPI, and Crates.io in TrapDoor last week, with payloads that modify .cursorrules and CLAUDE.md files specifically to weaponise the AI coding assistant against the developer who installed them. The Nx Console VS Code extension shipped a credential-stealing payload to 2.2 million developers in version 18.95.0, executed the moment the workspace opened. The Shai-Hulud npm worm hit 314 packages in 22 minutes via one stolen token. The actions-cool/issues-helper GitHub Action moved every existing tag to a malicious commit that scraped CI/CD credentials from every workflow that pinned by tag rather than commit SHA. That is one week. Pick any week in 2026 and the list reads longer.

The shape of the attack has not changed. Get something on the developer’s machine, harvest credentials, pivot. Bybit’s $1.5B February 2025 heist started on a Safe{Wallet} developer’s laptop. LayerZero’s $292M KelpDAO breach this April started on a LayerZero developer’s laptop, with the attacker sitting in the company’s cloud infrastructure for forty-three days before pulling the trigger. Drift’s $285M loss in early 2026 was preceded by six months of social engineering aimed at developer contributors, including in person at industry conferences. Same group in many of these cases, same pattern, larger numbers each time.

When engaged in a crypto org’s threat model and the developer endpoint is not covered, then you should know what already the next post-mortem would look like.

The threat-modelling fix is unglamorous and not optional. Every developer laptop, every VS Code or Cursor install, every CI runner, every contributor environment is a production endpoint. Each one needs an entry in the threat model that lists what credentials it can reach, what services it can deploy to, what production assets sit one rotation behind its login password. If the answer to “what happens if this laptop is compromised right now” is anything other than “the blast radius is contained to this laptop,” the threat model has a hole and the laptop has too much trust. The action is to walk every contributor environment back to the principle of least privilege the rest of your security program already runs on. Most crypto orgs would be horrified at what a typical engineer can reach with one harvested credential, which is exactly why most crypto orgs need to do this exercise this quarter.

The detection fix is EDR, MDR, or XDR, and the difference between those three and the consumer antivirus your org is probably running is the difference between catching a pivot and reading about it eight weeks later in a Mandiant report. Consumer antivirus catches what attackers stopped using in 2015. EDR watches behaviour, so when the legitimate-looking package opens a reverse shell to an unusual IP three hours after install, something fires. MDR puts humans on the other end of those alerts so they get triaged at 3am instead of next Monday. XDR correlates across endpoints so the same compromised package landing on three contributor laptops shows up as one incident rather than three unread emails. A $50-per-seat EDR subscription is cheaper than every individual line item in the LayerZero post-mortem, and the security team you already employ will be much happier doing the threat-modelling work above if they know they have a chance of catching what slipped through.

The key-custody fix is the one I keep being surprised I have to repeat. Production signing keys belong in a hardware security module or a cloud KMS. AWS KMS, GCP Cloud KMS, Azure Key Vault, Fireblocks, any reputable HSM vendor. The cleartext key never leaves the boundary. The signing operation calls the boundary, the boundary signs, the result comes back. A .env file on a contributor’s MacBook is operational hope dressed up in a filename. The day that laptop is compromised, and statistically it will be, the keys in that .env file have to be treated as fully owned by the attacker from the moment the malware lands. If those keys can move funds or change configuration anywhere in production, the loss is whatever the attacker can move before you notice. Echo Protocol noticed within hours and still lost $816K against a $76.7M paper exposure, with the cap set by chain liquidity rather than by any control Echo had in place. The next protocol that runs the same configuration on a chain with deeper pools will not get the same lucky cap.

Put it bluntly. Crypto orgs in 2026 spend more on contract audits than on the laptops those audits are commissioned from, and the most valuable production credential in your organisation right now is sitting on someone’s MacBook, next to a Slack message from a recruiter on LinkedIn and a VS Code extension that updates itself overnight. The contract you spent six months auditing will keep doing exactly what it was written to do. Whether that ends well for your protocol depends on whether your threat model includes the path from “someone updated Cursor on Tuesday” to “the admin key signed an unauthorised mint on Friday.”

Closing Tab

The next admin-key compromise will land on a chain with deeper liquidity than Monad, or on a Safe{Wallet} with a module nobody on the operations team can name from memory, and the headline number and the actual loss will be the even higher number.

Adrian Hetman Burn Notice Operational intelligence for Web3, every week.

Four major exploits in nearly seven weeks. Drift on April 1 ($285M), KelpDAO on April 18 ($292M), THORChain on May 15 ($10.8M), Verus on May 17 ($11.6M). The attack class is concentrating, not rotating. Infrastructure that connects chains, manages cross-chain messaging, or holds reserve balances on both sides of a proof system is the target.

In today’s issue:

• Drift’s Security Council was pre-signed into surrendering $285M, and a planned signer rotation was the one chance to stop it

• KelpDAO’s 1-of-1 DVN, LayerZero’s apology, and the $71M governance recovery cleared by court and DAO

• THORChain, Verus, and five more: what broke, in two sentences each

Need to Know

April 2026 produced $630M in confirmed crypto hack losses, the highest monthly total since February 2025, with DPRK-attributed operations accounting for roughly 76% of all 2026 losses through April, approximately $577M of $759M total, per TRM Labs. [Cointelegraph] PeckShield tracked eight bridge exploits year-to-date through mid-May, totalling $328.6M, and across those eight incidents the failure classes are the same ones we have been writing about for years, repeating because the industry's average internal discipline has not kept pace with its TVL. [bitcoin.com] Not one of these failures required a novel technique or a zero-day. Every security lead should be sitting with one question today.

Which of these failure classes is currently open in our stack?

The Big One — The Drift Council Takeover

The news. On April 1, 2026, DPRK operators drained $285M from Drift Protocol using pre-signed durable nonce transactions that legitimate Security Council members had unknowingly authorised via blind signing. [TRM Labs] The execution was the last step. The preparation had been running for six months.

What broke and how. DPRK’s UNC4736 spent fall 2025 cultivating Drift contributors at crypto conferences, presenting as a quantitative trading firm. By December they had onboarded an Ecosystem Vault and deposited more than $1M to build credibility. [The Block] Two contributors were compromised through a malicious code repository and a fake wallet app. The attackers then collected pre-signatures from 2-of-5 council members on admin-transfer payloads disguised as routine updates. Classic blind signing. [Chainalysis]

On March 26–27, a legitimate council rotation invalidated the attacker’s first harvest. That was the escape window. [BlockSec] The rotation did not change Drift’s pre-existing zero-timelock configuration. Within 72 hours the attackers had re-established the 2-of-5 threshold. On April 1 at 16:05 UTC, the pre-signed transaction executed. Zero timelock meant the transfer was irreversible before any monitor could fire. The vault drain took approximately 12 minutes. [The Block]

What to check now.

The March 26 rotation was Drift’s best chance. It invalidated everything the attackers had harvested. A zero-timelock audit and a 48-hour signing freeze during handoff would have ended it. A signer rotation without a timelock review creates a new attack surface wearing familiar clothes.

— Adrian

Chain Reaction — KelpDAO’s 1-of-1 DVN

The news. On April 18, 2026, DPRK’s Lazarus Group drained 116,500 rsETH worth approximately $292M from KelpDAO’s LayerZero-powered bridge by poisoning the RPC nodes that LayerZero Labs’ sole DVN relied on. [LayerZero incident statement] An emergency pause 46 minutes later blocked follow-up attempts that would have released an additional ~$200M.

What broke and how. KelpDAO’s rsETH bridge ran a 1-of-1 DVN, meaning one entity was responsible for verifying every cross-chain message. The attackers identified that entity’s RPC nodes and replaced their binaries with malicious versions returning accurate data to every IP except the DVN itself. They simultaneously DDoS’d the external fallback, forcing it onto the compromised nodes. With every honest path gone, the DVN signed a release for rsETH that had never been deposited on the source chain. [LayerZero incident statement]

Why it kept happening. ~47% of active LayerZero OApps were running 1-of-1 DVN configurations at time of the exploit. [bitcoin.com] LayerZero’s own quickstart wired the sample config with a single required DVN. After three weeks of blaming Kelp’s configuration, LayerZero issued a public apology on May 9, admitting it “made a mistake by allowing our DVN to act as a 1/1 DVN for high-value transactions.” [The Block]

The downstream impact. The exploit did not stop at the bridge. The attacker deposited the 116,500 unbacked rsETH as collateral on Aave and borrowed ~$190M in real ETH against it. [CoinDesk] Aave’s core WETH lending pool hit 100% utilisation — users who had deposited ETH could not withdraw. [Yahoo Finance] Aave froze rsETH markets across V3 and V4 and paused WETH borrowing on Ethereum, Arbitrum, Base, Mantle, and Linea. The panic spread beyond protocols directly holding rsETH: Aave lost $8.45B in deposits over 48 hours, pulling $13.21B out of DeFi TVL total. [CoinDesk] The DeFi United coalition, including Aave Labs, EtherFi, and Stani Kulechov personally, formed specifically to plug the collateral gap and prevent cascading liquidations.

What to check now.

47% of active OApps ran the same configuration that enabled this exploit. LayerZero’s quickstart normalised it. When infrastructure provider defaults create systemic risk, the post-mortem blame fight is the wrong place to discover that. The default is the product, and it was misconfigured at scale.

— Adrian

Around the Forums

Arbitrum DAO, $71M frozen ETH cleared for recovery. The Arbitrum Security Council froze 30,765 ETH linked to the April 18 KelpDAO exploit through an emergency 9-of-12 multisig action. The Constitutional AIP passed with more than 90% delegate support. [Cointelegraph] SDNY Judge Margaret Garnett cleared the transfer on May 9, though families holding $877M in unpaid terrorism judgments against North Korea claim the recovered ETH should satisfy their claims, and that legal question remains unresolved. [The Defiant]

THORChain, ADR-028 recovery vote open. THORChain opened a node-operator vote on ADR-028: protocol-owned liquidity absorbs the $10.8M loss, the attacker’s bond is slashed, no RUNE is minted, and no user deposits are affected. [BanklessTimes]

What Else Happened

• THORChain, $10.8M, May 15. GG20 threshold-signature key extraction. A malicious validator participated in signing ceremonies for 48 hours, accumulating leaked key-share material until it could reconstruct the full Asgard vault private key offline. [TRM Labs] Same broad family as the Alpha-Rays attacks THORChain paid a $500K bounty to patch in 2021, but a novel instance the 2021 patch did not cover.

• Verus Ethereum bridge, $11.58M, May 17–18. Source-destination value binding gap. The bridge verified proofs and signatures but never checked whether the input amount matched the payout; the attacker spent ~$10 in VRSC fees to receive $11.58M. [CoinDesk / Halborn]

• TrustedVolumes (1inch Fusion resolver), $6.7M, May 7. Missing access control modifier. The signer whitelist function was declared public with no onlyOwner modifier; the attacker added themselves as an authorised signer and drained the resolver wallet’s unlimited approvals across 85 transactions. [Halborn]

• ZetaChain, $334K, April 26. Three chained access control defects. The gateway accepted arbitrary cross-chain calls from any sender and team wallets held unlimited gateway approvals; one CCTX with IsArbitraryCall = true drained wallets across four chains. [SolidityScan] ZetaChain admitted a prior report describing this behaviour was dismissed as “by design.”

• Giddy.co, $1.3M, April 23. Incomplete EIP-712 struct coverage. The signature covered only the swap data bytes, not token addresses or amount; the attacker replayed a valid signature with all four unsigned fields substituted. [Verichains]

• Adshares, ~$628K, May 15. Source-destination value binding gap. The bridge-minter signed token releases against transaction IDs that do not exist on the canonical Adshares chain; zero on-chain verification of the referenced transactions. [DefimonAlerts]

On the Clock

No toolchain upgrades with operational urgency this week. All failures were configuration, access control, signature scope, or economic logic, not toolchain.

Three things are operationally urgent regardless. If you run any LayerZero integration at 1-of-1 DVN, migration is not optional. If any Solana council signer can authorise durable-nonce transactions, disable it now. If any privileged wallet holds type(uint256).max approvals to any contract, revoke them before end of week.

Long Reads

Chainalysis: Inside the KelpDAO Bridge Exploit. The most technically detailed account of the RPC poisoning chain, DDoS failover mechanics, and DPRK laundering flows. Required for anyone building bridge infrastructure.

BlockSec: Drift Protocol Incident. The most granular on-chain timeline of the Drift attack. The section on the March 27 rotation and 72-hour re-harvest is essential for any protocol with a Security Council.

Verichains: When Signing Is Not Secure. The deepest analysis of the Giddy.co EIP-712 struct failure. Applies to every vault or swap contract using off-chain authorisation.

The Operator’s Read

People keep calling KelpDAO more sophisticated than past DPRK hacks. It was not. Harmony’s Horizon ran 2-of-4. Ronin was 5-of-9 on paper, but four keys sat with the same entity, making it effectively 2-of-9. KelpDAO ran 1-of-1. The numbers keep changing. The failure class does not.

Every few years someone ships a cross-chain system with a threshold that looks acceptable and a signing arrangement that collapses under scrutiny. We write post-mortems. We say never again. Then it happens again with a different name on the contract.

If you are running a multisig today, the real question is whether the keys are genuinely independent, not whether the number is above one. If two of your five signers share a Slack workspace and a deployment pipeline, your threshold is not what the contract says it is.

The triage problem nobody wants to admit

I understand why reports get dismissed. The volume is relentless and most AI-generated submissions are noise. But ZetaChain dismissed a report on the exact component that was later exploited because the behaviour looked “by design” in isolation.

Chained attacks do not announce themselves. The first bug looks like an edge case. The second like a known limitation. The third is the exploit. A triage process that evaluates each report in isolation will miss all three as a combination.

A managed triage service handles the volume. An internal developer catches what the triager cannot, because they see the report and the three other components it touches. You need both. Always evaluate by end impact on your protocol. If the funds at risk are yours, the report is in scope, regardless of where the entry point is.

Mitchell Amador’s five years of Immunefi data settles the continuous coverage question. 93.9% of programmes active for five or more years have surfaced a confirmed critical. Average is 2.7 per programme. The only variable is whether a whitehat or a blackhat gets there first.

The basics are the whole point

Giddy and TrustedVolumes had nothing to do with state-sponsored attackers. One was an EIP-712 signature covering half the fields it should. The other was a public function with no access control modifier. Day-one checks. Both shipped without them.

AI coding gets code out faster. It does not make that code more secure. Shipping speed is a competitive advantage until it is not, and when it stops being one you are writing a post-mortem.

Default configurations are a security decision

The zero-timelock on Drift and the 1-of-1 DVN on KelpDAO were not installed by attackers. Both were set by the protocols themselves, never revisited, and never put to a governance vote. Nobody attacked the code. The attackers read the configuration.

One entity to compromise. One RPC layer to poison. One fallback layer to knock offline. The cryptography was fine. The architecture made it irrelevant.

Ask the question LayerZero did not ask until after $292M was gone: is the default here the secure option, or just the easy one?

P.S.

Bridges were profitable targets before this year and will remain so. Where large sums of money pass through a potential single point of failure, people will always be looking for holes.

What matters is whether the fundamentals are in place before the bridge goes live. Clear validation logic. Genuine signing independence. A review process that actually asks whether the inputs and outputs are economically bound to each other. The foundation. Build it first.

Closing Tab

The contracts got audited. The configuration did not. That is where every exploit in this issue started. Check yours.

Adrian Hetman Burn Notice Operational intelligence for Web3, every week.

I’m writing this from the middle of it, not from the other side.

That feels important to say upfront. Most articles about burnout are written in the past tense. “Here’s what I went through, here’s how I got out.” This isn’t that. I’m still figuring it out. And maybe that’s exactly why I want to write it: because I know I’m not the only one sitting in this, and I think there’s something honest worth sharing even before the story has a clean ending.

How passion becomes weight

In 2016, I was a software engineer at BAE Systems, leading a small blockchain innovation team. The technology was fringe, and most people around me couldn’t understand why I cared so much about it. I cared because I couldn’t stop. That curiosity felt effortless. It wasn’t ambition, it was just following the pull.

That pull carried me further than I could have planned. From building smart contracts, to auditing them at CertiK, to joining Immunefi in 2021 as the fourth person on the triage team. Four years later, I’m Head of Triage, leading a team of eight, managing a service covering $190B in protected user funds. I’ve mediated disputes where the outcome determined whether millions of dollars went to the right place. I’ve hired people, developed them, watched them grow.

By any measure, the thing I chased because it fascinated me became a career. And then, as these things do, the career became a job.

I don’t say that with bitterness. I’m proud of the work. But there’s a particular exhaustion that comes when meaningful work accumulates weight over years. The stakes stop feeling abstract and start feeling very, very real. Security is relentless. The reports keep coming. The disputes are sometimes people’s livelihoods. You carry that home. And somewhere along the way, the spark that used to fire automatically started to require effort to find.

“Even meaningful work can become draining if you never take a break from it.”

The thing burnout steals that nobody names

We talk about burnout in terms of productivity. You can’t focus, you can’t start things, the inbox feels like a boulder. All of that is real.

But what burnout quietly takes is your sense of who you are when you’re not working. Nobody really warns you about this part.

When what you do and who you are have been the same thing for years, burnout doesn’t just leave you unproductive. It leaves you feeling hollow in a way that’s harder to explain. You look at the things that used to energize you and feel nothing. The curiosity that once pulled you forward now feels like a task you’re failing to perform. And then the anxious voice arrives. Was any of it real? Is this who I actually am, or just what I got good at?

I’ve sat with that question more than once lately. I don’t have a clean answer. But I’ve come to think that the question itself isn’t a crisis. It’s an invitation.

What distance taught me

The first time I understood this, it wasn’t because I read about it. It was because I started picking up a camera.

Not a digital one. An analog one. Film photography, which is slower, more deliberate, and completely unforgiving in the best possible way. You can’t undo a shot. You can’t scroll back. You have to be present, and then you have to wait. That waiting, I discovered, was doing something for me that nothing in my work could.

Then came mechanical watches. There’s a whole world in there. The history, the craft, the way a movement works like an impossibly small piece of engineering that someone thought about for years. I fell deep into it without planning to. Then cooking properly for my family on weekends, not a quick meal but the kind where you’re chopping things slowly, tasting as you go, fully in the room for a few hours while the notifications disappear. Repairing old consoles. And of course, writing this blog.

And journaling.

Journaling might be the one that’s changed me the most, even though it’s the hardest to explain to someone who hasn’t tried it. There’s nothing productive about it. You sit down, you open a notebook, and you write whatever is actually in your head. Not the polished version, not the version you’d say out loud, just the real mess of it. Today I feel... I don’t know what I feel. I’m tired in a way I can’t name. I keep thinking about... And then something happens. The thought that was a fog starts to have edges. You see patterns you hadn’t noticed. You realize what’s been draining you. Sometimes you realize what you actually want.

I’ve written before about journaling, and I keep coming back to it because it keeps coming back to me. It’s the one habit that costs nothing, asks nothing, and somehow returns more than almost anything else I do for myself. If you’re burned out and you haven’t tried it yet, I’d start there before anything else.

“Work is not just about doing more. It’s about doing what matters and leaving space for what makes you human.” — Cal Newport, Slow Productivity

None of what I listed above is productive. None of it scales. Nobody is waiting on a deliverable. And that, I eventually understood, was exactly the point. If your hobby becomes your job, you can’t let it stay your only hobby. I learned this the hard way. When blockchain was both what I did at work and what I thought about in my free time, I was mentally on the clock 24 hours a day. That isn’t sustainable, especially when you have a family you want to be fully present for, not a version of yourself that’s still half somewhere else.

The honest part. I’m still exploring.

Here’s where I have to be honest with you, because this post would ring false if I wrapped it up too neatly.

I haven’t figured this out. I’m still in the middle of discovering what gives me that spark right now, at this point in a career that looks very different from where it started. Some of the hobbies I listed above I’ve had for years. But some of what’s pulling at me lately is newer and less defined, and I’m not sure yet what to do with it.

I’ve been thinking about starting an Instagram account just for my watch photography. Nothing elaborate, just a place to share what I see when I look through the viewfinder at a dial, a case, the way light catches a rotor. I don’t know if I will. I don’t know if anyone would care, or if that’s even the point. But the thought keeps coming back, which I’ve learned to take seriously.

I’ve been thinking about doing something more with journaling. Not just keeping it to myself, but sharing more of the process, the prompts that help, the way it feels on the days when it clicks and the days when it doesn’t. Maybe that’s just more writing. Maybe it’s something different. I don’t know yet.

And I notice that I don’t know yet feels important to sit with, rather than resolve. Part of what burnout does is make you feel like you need to have the answer already. Like not knowing what your next passion is means you’ve lost something permanently. I don’t think that’s true. I think sometimes the honest position is that I’m curious about a few things, I’m not sure where they’ll go, and I’m giving myself permission to find out slowly.

Those small pulls are worth following. Not because they’ll become your next great passion overnight, but because they’re the thread back to yourself. Curiosity doesn’t need a destination. It just needs permission.

When something surfaces, and something usually does if you stop forcing it, start smaller than feels meaningful. One afternoon. One roll of film. One meal you haven’t tried before. One page in a notebook. The goal isn’t to build something or prove something. The goal is just to remember what it feels like to do something for no reason other than that you want to.

I started this blog for exactly that reason. Not with a plan, not with a content strategy, not even with a clear sense of who I was writing for. I just wanted to write. And that wanting, it turned out, was enough to start.

“How we spend our days is how we spend our lives.”

On rest, which is harder than it sounds

I’ve resisted rest my whole career. There was always more to do. Always someone pushing forward. Always a dispute that needed resolving, a hire that needed making. The guilt of stopping felt productive, like at least I was aware of what I wasn’t doing.

But I’ve learned, slowly and not easily, that this is a trap. You can’t recover while still running. You can’t find the spark when you’re running on empty. The ideas don’t come, the curiosity doesn’t fire, and the things you used to love stay flat, not because they’ve changed, but because you’re too depleted to receive them.

Real rest isn’t waiting for motivation while you do nothing. It’s giving yourself time that isn’t in service of anything else. A walk without headphones. A book with no agenda. Cooking something slowly. Sitting outside and doing nothing in particular. These aren’t wasted hours. They’re where the spark rebuilds itself, without your help, without your interference.

“The things you think about determine the quality of your mind. Your soul takes on the color of your thoughts.” — Marcus Aurelius, Meditations

This isn’t a solved problem

I said at the beginning that I’m writing this from the middle, not the other side. I mean it.

I’m still figuring out what the next version of this looks like, what the spark looks like now, at this point in a career that has grown in ways I couldn’t have predicted. I don’t have a tidy ending. I have analog photographs I’m happy with. A few watches I love. A journal I return to. A blog I keep showing up for. A family I want to be fully present for. And a slowly growing sense that the curiosity that got me here is still in there somewhere, just a little buried, waiting for some space.

If you’re in something similar, I don’t want to offer you a five-step plan. I want to offer you this: the burnout you’re feeling isn’t a verdict on who you are or how much you care. It’s a signal that you’ve been giving a lot, and you need to receive something back. The flatness isn’t permanent. The spark doesn’t disappear. It just needs you to stop demanding it perform on command.

Do things for yourself. Follow the small pull. Rest without guilt. Let the thing you love breathe at a distance for a while.

And if you need a reason to start, mine arrived before I was ready. Within the next week, my second child will be born. I want to be fully present for him from the very first day. Not a version of myself that’s half somewhere else, still processing a dispute or mentally triaging a report. Someone he can rely on. Someone my whole family can rely on. That’s not a small thing to want. And it’s been the clearest reminder I’ve had in a long time that the work of finding yourself again isn’t selfish. It’s necessary.

The way back isn’t always straight. But it’s there.

If you’re still in the early stages of recognizing what burnout actually is, I wrote about that first — and about the small steps that help — in Understanding Burnout and Finding Small Ways Forward. This post picks up where that one left off.

The hand moves before you’ve even registered the feeling.

You sit down with a coffee. Nobody needs anything. There’s a gap in the day, ten minutes, maybe twenty. And before boredom has a chance to arrive, you’ve already opened your phone. You’ve scrolled something. You’ve pre-empted the discomfort so efficiently that you never actually felt it.

Ted Chiang’s short fiction keeps returning to one question: what does it mean to be inside a moment that is already passing? In Exhalation, a being studies its own consciousness and arrives at a quiet conclusion about time and presence. The story doesn’t offer comfort exactly. It just insists on something: this moment, right now, is the only one that actually exists. The past is sealed. The future isn’t here yet. You are only ever somewhere.

I think about that sometimes when I reach for the phone.

Most of us haven’t been genuinely bored in years. Not because life is so full, but because we’ve built a nearly airtight system for avoiding the feeling. Every gap gets filled automatically. The commute. The queue at the shop. The thirty seconds between tasks. The two minutes while the coffee brews. We have eliminated the fallow time so completely that we’ve also eliminated everything it used to produce.

And what it produces, it turns out, isn’t nothing.

What You’re Actually Avoiding

The reason we avoid boredom isn’t laziness. It’s that the first few minutes of doing nothing feel genuinely wrong.

There’s a specific quality to it, a restlessness, a sense of should be doing something, an itch you can’t locate. Most people interpret this as evidence that boredom is bad and reach for relief. But the discomfort isn’t the boredom itself. It’s the transition. Sit through it, and something else becomes available.

I noticed this first through film photography. You take a shot. You can’t see it, can’t adjust it, can’t delete and reshoot. You just have to be where you are and wait for something worth shooting. The first few rolls I put through a camera, I was restless the whole time, scanning for the next frame rather than seeing what was in front of me. The camera didn’t slow me down. The inability to review the results did. It forced me to actually be somewhere rather than processing it.

The discomfort at the start is the price of admission. Most people don’t pay it because relief is always one tap away.

What the Mind Does When You Leave It Alone

The brain, when you stop directing it, does not go blank. It wanders. And wandering is not the same as wasting time.

It goes back to things you haven’t consciously thought about. The console you’ve been meaning to repair that’s been sitting in a box for eight months. The conversation with a friend you’ve been putting off because you haven’t had the right window. The thing your daughter said last Tuesday that you half-heard and then forgot about until now.

It also works on problems without your permission. You stop trying to figure something out and take a walk, and by the end of the walk you have the answer. Not because walking is magical. Because you stopped forcing it and the mind found its own route.

And it tells you things about your emotional state that the noise of constant stimulation buries. You sit still for ten minutes and realise you’re anxious about something you hadn’t consciously named. Or that you’re actually fine. Or that you’ve been tired for three weeks and covering it with distraction.

None of this is glamorous. It’s not a creativity breakthrough or a productivity win. It’s just contact with what’s actually going on in your own head, which is harder to access than it sounds when you’re filling every gap with something.

The Case for Doing Nothing

The Art of Laziness makes an argument that most self-improvement thinking is designed to argue you out of: that deliberate inaction is not a failure of discipline. That the insistence on filling every moment with effort and visible output is not productivity. It’s anxiety wearing productivity’s clothes.

The case isn’t that doing nothing leads to better results. It’s simpler and harder to accept than that. Doing nothing has value in itself. Not because of what it eventually produces. Because it’s the state in which you are most honestly present, without task and stimulus constantly telling you what to think and feel next.

I spent years in an environment where there was no fallow time. The work ran on urgency, on staying alert to everything, all the time. Boredom was the enemy, a gap in attention that could mean something missed. I was good at that. But vigilance has a cost, and one of them is that you gradually lose the thread of your own life, because you’re never quiet enough to hear it.

What I found, slowly, when I started leaving things unfilled, wasn’t insight or inspiration. It was just more signal from my own life. Small stuff. Noticing, mid-queue at the supermarket, that I hadn’t called my parents in a while. A walk without headphones where a half-formed problem resolved itself sideways, without effort. Sitting somewhere with nothing to read and realising I was actually tired, not restless, and had been for weeks.

That’s what boredom gives you. Not inspiration. Just contact with what was already there, waiting.

A Small and Uncomfortable Experiment

Pick one gap in your day that you currently fill automatically. The queue at the shop. The few minutes before a meeting starts. The walk from your desk to the kitchen. Leave it empty.

Don’t reach for the phone. Don’t put a podcast on. Don’t try to make the time useful. Just be where you are, with nothing to engage with, for however long the gap lasts.

The first few times it will feel like nothing is happening. That’s fine. The transition is uncomfortable and takes a few minutes to pass. Wait it out.

Do it for a week and notice what arrives. Not always something remarkable. Sometimes nothing at all. But sometimes something you’d been meaning to remember, something your body has been trying to tell you, something that only surfaces when you stop drowning it out.

Chiang’s narrator, near the end of Exhalation, addresses whoever might one day find the story: you are alive right now, in a moment that exists and will not come back. That isn’t a weight to carry. It’s just a fact worth occasionally sitting with.

The phone makes it possible to never sit with it. Boredom makes it unavoidable.

That’s not a bug. That’s the whole point.