Drift Was Audited. That Was Never the Point.

The most important detail in the Drift Protocol exploit is not the $285 million.

It is a small finding in a 2024 Neodyme security audit, and the assumption behind its severity rating.

Neodyme logged an informational issue, ND-DFT1-IN-01, titled “Admin Can Pass Invalid Oracle Accounts.” Drift fixed the validation gap. But the reason the issue was only informational is the part worth sitting with: the instruction was admin-gated. The admin was assumed to be honest.

That assumption was the real security boundary.

Not the line of code. Not the check Drift patched. The whole authority model depended on a privileged actor staying trustworthy, careful, and uncompromised. And that is exactly what a six-month North Korean operation attacked.

Drift was not under-audited. Its docs list reviews from Trail of Bits, Neodyme, and OtterSec. Neodyme called the protocol’s security excellent, with real findings “few and far between,” most of them fixed and re-verified.

Then, on April 1, 2026, Drift lost roughly $285 million anyway — more than half its TVL and the largest DeFi exploit of the year — without a conventional smart-contract bug. The code did what it was written to do. The transactions carried valid admin signatures. Standard security checks did not flag them because, from the protocol’s point of view, nothing unauthorized had happened.

That distinction matters.

A missing check in a function is a code bug. A signer approving a transaction they do not understand is an operational bug. A 2-of-5 multisig with no timelock controlling market creation, oracle assignment, and withdrawal limits is a control-plane bug.

Drift failed in the last category: the distance between the system that was audited and the system that kept changing after the audit.

That distance is audit drift.

What an audit actually certifies

When an audit says, explicitly or implicitly, “the admin is trusted to…,” that sentence is doing a lot of work.

It marks the edge of the threat model.

Inside that edge, the auditor can ask concrete questions. Can an unprivileged user initialize a market? Can someone bypass margin checks? Can a non-admin assign an oracle or withdraw funds they do not own?

Drift’s audits appear to have answered those questions well. Neodyme’s scope covered implementation security, architecture, economic attacks, business logic, and authority structure. The code came out looking unusually solid.

Outside that edge is a different kind of risk: the privileged powers the protocol deliberately gave itself.

A key that can create markets, assign oracles, change parameters, and lift withdrawal limits is not automatically a vulnerability. It may be a launch-phase control, an emergency mechanism, or a governance choice. The auditor documents it. The team accepts it. The report moves on.

That is normal. It is also why the oracle-admin finding was informational instead of critical. The danger was real, but it was behind the admin key, and the admin was assumed to behave.

The audit can get you to that handoff. It cannot keep verifying the handoff forever.

It cannot guarantee that a future signer rotation preserves the same trust model. It cannot guarantee a timelock is still present two years later. It cannot guarantee signers understand what they are signing. It cannot guarantee that a patient adversary will not spend months earning access to the humans around the protocol.

The audit looked at the door.

It did not — and could not — guarantee the door would still be locked later.

The assumption that decayed

Here is the part most summaries skip: the configuration that failed did not exist when Neodyme reviewed Drift in early 2024.

According to Chainalysis, Drift migrated in late March 2026 to a new 2-of-5 Security Council multisig with zero timelock. Rekt’s reconstruction adds that the migration lowered the threshold from 3-of-5 and replaced four of the five signers.

The important security property is simple: any two of five keys could authorize an instant, irreversible, protocol-level change. No delay window. No time for monitoring to catch up. No cancel path once execution began.

The code did not change.

The assumption did.

And no one seems to have treated that assumption change as a critical security event, because that is not what a point-in-time code audit is built to do.

A useful way to think about this is to split a protocol’s claims into four tiers:

A code audit is strongest in Tiers 1 and 2.

Drift failed in Tiers 3 and 4.

“Our signers operate securely” cannot be confirmed from the repository. “We maintain a robust multisig” may have been true when the reports shipped and false by spring 2026.

The exploit did not find a hole in the audited code. It found the space between a snapshot and a living system.

For a protocol named Drift, the case study is almost too neat.

The control plane is the attack surface now

For a live DeFi system, “the protocol” is not just the code.

It is also the multisig signer set, the signing threshold, the timelock, admin authority, upgrade authority, oracle assignment, collateral listing, withdrawal caps, pause authority, deployment keys, signer devices, monitoring, incident response, and every human process that can change what the code does.

That is the control plane.

It is not “around” the protocol. It is part of what users are trusting.

In Drift’s case, it was the whole attack surface.

Once the attacker held valid authority, the protocol simply obeyed. The program did not see an exploit. It saw a trusted operator submitting valid transactions.

Getting that authority took months.

Chainalysis describes individuals posing as a quantitative trading firm. They approached Drift contributors at crypto conferences, kept contact through Telegram and working sessions, onboarded a vault, deposited more than $1 million of real capital, and built credibility over time.

Then came the signatures.

Solana durable nonces allow a transaction to be signed now and executed later. That is a legitimate feature for offline and multisig workflows. The attackers used it to get at least two Security Council members to pre-sign transactions they did not fully understand.

That is blind signing. It pre-authorized the takeover before the attack started.

Drift has pointed to a possible malicious repository or editor-exploit vector behind the device compromise, while noting that multiple intrusion paths remain under forensic review. So the safest claim is the one the chain supports: social engineering, pre-signed transactions, and a signing workflow that approved what it could not see.

Then the attack compressed into seconds.

At 16:05:18 UTC on April 1, the first pre-signed transaction proposed the admin transfer. One second later, the second approved and executed it. Two transactions were enough to give the attacker full administrative control.

From there, it was authority abuse.

The attacker listed CarbonVote Token (CVT) as collateral. CVT had been created about three weeks earlier. The attacker controlled the supply, seeded a few hundred dollars of Raydium liquidity, wash-traded it to a fake price, and fed it through an attacker-controlled oracle. Then they deposited 500 million CVT and borrowed real assets against it.

The largest withdrawals happened within minutes. The drain continued for roughly two and a half hours. Funds started reaching Ethereum about 23 minutes after the takeover.

No circuit breaker stopped it.

Drift later said Mandiant’s forensic review attributed the operation to UNC6862, a North Korean threat group. That attribution matters because it shows the level of adversary now treating a six-month con as a reasonable investment.

“We met them in person” is not a control.

“They deposited real money” is not a control.

“They seemed legitimate” is not a control.

Those are inputs to trust. They are not constraints on authority.

The baseline was boring. That was the point.

The controls that would have broken this chain are not exotic.

They are boring, and that is why they work.

SEAL’s multisig guidance calls for at least three signers and at least a 50% threshold, with no threshold reductions without documented justification. It recommends seven or more signers once a multisig protects more than $1 million. It calls for hardware wallets on dedicated, hardened devices; raw transaction verification before signing; out-of-band confirmation for signer or admin changes; and a mandatory timelock so teams have a chance to detect and respond to malicious proposals.

Hold Drift’s live setup against that baseline and the shape of the failure is obvious.

A five-signer council guarded hundreds of millions, where the guidance points to seven or more. The threshold was lowered to 2-of-5. There was no timelock. Signers approved transactions they did not understand. The signer migration itself was social-engineered into place.

Monitoring deserves the same treatment.

SEAL’s monitoring framework says every alert needs an owner and a response. For a protocol, that usually means a pause, veto, or circuit breaker. Drift’s drain ran for more than two hours without that kind of containment.

An alert that lands in a channel nobody is responsible for is theater.

An “admin changed” alert is not very useful if nothing can happen before withdrawals clear.

None of this requires new cryptography. It requires treating the control plane as production security infrastructure, not administrative housekeeping.

Radiant was the warning

Drift was not the first version of this story.

Radiant Capital was hit in October 2024 by the same class of failure at smaller scale: roughly $50 million through a 3-of-11 multisig.

Radiant’s own post-mortem describes three long-standing, trusted developers being compromised despite hardware wallets and geographic distribution. Their machines displayed legitimate transaction data in the Safe front end while malicious transactions were signed in the background and used to seize control of the protocol’s contracts.

Radiant showed that hardware wallets do not save you if the signer is not approving the transaction they think they are approving.

Drift showed that in-person trust, conference familiarity, and a multisig do not save you if signers can be induced to pre-approve transactions they do not understand.

The pattern is not “teams forgot to get audited.”

The pattern is that operational trust is now being attacked with the patience and sophistication people used to associate with code exploits.

Mapping the gap

A code audit cannot continuously verify operational promises. Something else has to.

Every trust assumption in an audit report is a promise about the world outside the code. For each promise, there has to be a live control that keeps it true. Unlike a code property, that control can drift the moment the protocol evolves.

SEAL’s frameworks are useful here because they line up with the shape of the problem:

Read top to bottom, that table is the anatomy of the hack.

Every row is a place where a normal audit correctly reaches the edge of its model. Every row is also a place where the protocol still needed a live control.

The audit gives you a map of the assumptions your security depends on.

Operational security is the work of checking whether those assumptions are still true.

The gap between the two is audit drift.

A privileged-action review card

A protocol does not need a new audit to start closing this gap.

It can start with one artifact: a privileged-action review card.

Run it before any transaction that can change protocol behavior: signer rotation, collateral listing, oracle change, withdrawal-limit update, admin transfer, upgrade, pause change, or timelock change.

If any row is blank, the action is not routine. It is a security event.

This is not a code review.

It is the thing a code review cannot be: a repeatable check that the assumptions behind the audit are still true at the moment you rely on them.

What teams should do this week

Start by extracting the trust assumptions from your last audit.

Not just the findings. The assumptions.

Look for admin-only notes, trusted-role language, oracle assumptions, upgrade assumptions, signer assumptions, and places where the auditor correctly stopped because the next question was operational rather than technical.

Drift’s informational oracle finding is a good template for what to look for.

Then map each assumption to a live control.

If the audit assumes the admin is trusted, write down who can become admin, how fast, under which timelock, with what monitoring, and with what cancel path. If it assumes the oracle is legitimate, write down who can change oracle sources, who can list collateral, and what invariant prevents an illiquid token from becoming borrowing power.

Test whether signers understand what they sign. Have them decode a real transaction. Simulate a complex one. Practice refusing an unclear request.

Fire a test alert and watch what happens. Who receives it? Who wakes up? Does the runbook have a real pause or cancel action, or does it just tell people to investigate?

Define what “robust multisig” means for your protocol today. Then compare that definition to the current signer set, threshold, timelock, device policy, and monitoring.

Every time one of those changes, treat it as audit drift.

The lesson is not “get another audit”

Drift should not make teams conclude that audits do not matter.

They do. A good audit is still one of the highest-leverage security investments a protocol can make, and Neodyme’s work here appears to have been strong.

But an audit is a photograph of your code at a moment in time. Your trust assumptions are not a photograph. They are a living system.

They change when you rotate a signer, onboard a vault, shorten a timelock, list an asset, change an oracle, edit a deployment script, or add a contributor who can be reached at a conference.

The Neodyme report was accurate when it shipped and a little staler every day after. Not because the auditors missed the exploit. Because point-in-time artifacts age.

So the answer is not always another PDF.

It is turning audited assumptions into living controls.

If the audit assumes the admin is trusted, production needs a control on who can become admin and how fast. If it assumes the oracle is legitimate, production needs controls on oracle assignment and asset listing. If it assumes signers understand what they sign, production needs hardened signing, intent verification, and out-of-band review. If it assumes someone is watching, production needs alerts tied to named people and an executable pause.

Drift was audited. Three times.

That was never the point.

The point is what happened after the audits, when the protocol kept changing, the control plane became the attack surface, and the system accepted two valid signatures for a catastrophic action.

For most teams reading this, the next exploit is probably not hiding in the code their auditors already reviewed. It is in the next signer rotation, the next oracle change, the next collateral listing, the next routine multisig transaction, or the next trusted relationship nobody has threat-modeled yet.

Between audits is where the $285 million left.

It is also where almost nobody is looking.

---

Where has your audit drifted?

SuperDroids reviews the layer your audit didn't: who can move your money — every owner, role, signer, and timelock — and how those privileged transactions actually get signed.

Not a second audit. Not slideware. A different layer than your code review — the one where the losses above actually happened.

Start with the free Access Snapshot — a one-page map of your protocol's control plane, built from public chain data, back within 48 hours. Or go straight to the Signing & Access Review.