11
Drift’s $280M Hack Was a Durable-Nonce Multisig Takeover — Not a Smart‑Contract Bug
Drift Protocol lost about $280 million in early April 2026 through a premeditated social‑engineering attack that exploited Solana’s durable nonce feature and weaknesses in multisig approval operations — not because of a smart‑contract vulnerability or a straightforward private‑key leak.
Why the “smart contract bug” story stuck
Media and market reactions initially framed the incident as another DeFi code failure, partly because the loss was large and moved quickly on‑chain. That framing compressed the technical chain of events into a single alleged bug, which obscured that the attacker used legitimate transaction primitives (durable nonces and multisig approvals) in a coordinated off‑chain campaign.
Forensic timeline and what actually happened on specific dates
Investigators trace the operation to preparatory steps that began weeks before funds moved. The attacker created durable nonce accounts tied to both Drift Security Council multisig members and attacker‑controlled wallets as early as March 23, 2026. Though the Security Council’s multisig rotation was scheduled for March 27, the attacker managed to regain approval power by adding a member they controlled. On April 1, around 60 seconds elapsed between the execution of pre‑signed transactions and the lifting of withdrawal limits — a window used to move assets out of insurance and protocol wallets.
The takedown drained over $280 million in assets, including roughly 980,000 SOL, 41.7 million JLP tokens, USDC, and wrapped Bitcoin. Much of the haul was converted into USDC and bridged to Ethereum via Circle’s Cross‑Chain Transfer Protocol (CCTP). On‑chain investigator ZachXBT noted that Circle had a multi‑hour window to act but did not freeze the transfers; that inaction prompted public criticism and renewed debate about when stablecoin issuers should police stolen funds.
How durable nonces plus multisig social engineering bypassed controls
Solana’s durable nonce feature is intended for legitimate use cases like offline signing and complex multisig flows because it allows transactions to be pre‑signed and executed later without expiring. In Drift’s case the attacker weaponized that exact property. By pre‑signing administrative transactions weeks ahead and ensuring those transactions were associated with nonces tied to both genuine signers and attacker wallets, the attacker created a set of executable approvals that could be triggered once they controlled an approving identity.
The operational chain mattered more than on‑chain code: the attacker used a worthless token as collateral while manipulating a price oracle to inflate its reported value, thereby satisfying Drift’s risk checks and enabling large withdrawals. Administrative control was transferred through these pre‑signed transactions, not by exploiting a contract bug or by directly stealing seed phrases. Once admin privileges were in attacker hands, withdrawal limits were lifted and funds exited the protocol in a rapid sweep.
Concrete mitigation options for teams and users
Drift’s forthcoming post‑mortem and governance proposals will be the next checkpoints. The immediate, practical fixes fall into two categories: operational changes around signer workflows (multi‑channel confirmations, signer identity verification, expiry for pre‑signed ops) and on‑chain guardrails (shorter nonce lifetimes, stricter oracle authentication, and transaction‑level timelocks tied to rotation events).
| Control | How it would have helped | Practical threshold |
|---|---|---|
| Nonce expiry / rotation tied to governance | Prevents weeks‑old pre‑signed transactions from executing | Automated rotation every 24–72 hours for admin nonces |
| Multi‑channel signer confirmations | Makes social engineering require compromise across independent channels | At least two out‑of‑three channels (on‑chain + email/phone + hardware wallet) |
| Oracle authentication & collateral checks | Reduces risk of manipulated token values being accepted as real collateral | Multi‑source median pricing + staking/whitelisting for new assets |
Short Q&A
Did this require a code fix? No — the exploit leveraged off‑chain approvals and transaction mechanics; smart contracts themselves were not exploited.
What should users do now? Revoke any Drift‑related approvals, avoid re‑depositing until the protocol issues clear guidance, and monitor governance proposals about nonce and signer policies.
Will Circle be forced to change policy? The case has increased scrutiny: public criticism (including from ZachXBT) centers on inconsistent freezes. Any change would be driven by regulatory pressure or updated issuer policy rather than technical necessity for this specific exploit.
