Company

Drift Protocol lost $285M on April 1, 2026, without a single line of contract code being broken. The attackers spent six months posing as a quant firm, harvested pre-signed transactions weeks in advance, and walked through a governance door that had been quietly unlocked four days earlier. This is what continuous Web3 Security Posture Management is built to catch. Dedge Security provides Web3 Security Posture Management (W3SPM) assessments covering smart contract architecture, governance configuration, cloud infrastructure posture, compliance alignment, and operational incident response design.
On April 1, 2026, an attacker submitted two transactions four Solana slots apart and drained $285 million in user assets from Drift Protocol, the largest decentralized perpetual futures exchange on Solana. The exploit took twelve minutes to complete. Drift's smart contracts were audited in 2022 and re-audited in February 2026. Neither review surfaced the vulnerability, because the vulnerability was not in the contracts.
The failure lived across three layers: governance configuration, signer hygiene, and collateral whitelisting policy. Each was independently observable on-chain before execution day. None was within the scope of either audit engagement.
TRM Labs, Elliptic, and Chainalysis independently assessed the attack as consistent with tradecraft attributed to UNC4736, the DPRK-linked threat cluster also tracked as AppleJeus or Citrine Sleet — the same group widely believed responsible for the 2024 Radiant Capital exploit.
At $285M, this is the largest DeFi loss of 2026.
Two audits. One in 2022, one completed six weeks before the attack. Neither was
scoped for what actually happened.
What is Drift Protocol
Drift Protocol is an open-source, fully on-chain DEX built on Solana, launched in 2021 by Cindy Leow and David Lu under Drift Labs. By April 2026, it held over $400M in user deposits across four integrated products: perpetual futures, spot trading, borrow/lend pools, and yield vaults. All four share a single cross-margined risk engine.
This architecture is relevant to the exploit. A single change to the collateral whitelist propagates instantly across every borrow path in the system. Governance authority over three surfaces — the collateral whitelist, the oracle authority, and the risk parameter set — constitutes effective control over the entire protocol. These are not exotic permissions. They are how the protocol operates.
Whoever controls those three surfaces controls Drift.
Finding 1: Durable Nonce Accounts Used to Pre-Stage Irrevocable Signed Authorizations
Severity: Critical. Observable on-chain during staging.
Between March 23 and 30, the attacker created multiple durable nonce accounts on Solana, several of which were explicitly tied to addresses belonging to legitimate Drift Security Council members. Through a social engineering campaign spanning several months — in which the attackers posed as a quantitative trading firm and made in-person contact with Drift contributors at industry events in late 2025 — two of the five council members were induced to pre-sign transactions that encoded admin-transfer instructions.
Solana's durable nonce mechanism removes the standard ~90-second blockhash expiry. A transaction signed against a durable nonce does not expire. It can be executed weeks later, on the attacker's schedule, with no further action required from the signer. Once signed, there is no revocation path available to the signer.
The compounding failure here is at the signing layer, not the protocol layer. Signers approved transactions on compromised devices, without decoding and verifying the instruction payload at signing time. The description text displayed by the signing UI does not constitute verification of what is being authorized.

Note: Left and right sections use different time scales separated by the ‖ scale break. On-chain event dates from Solana mainnet and TRM Labs / Elliptic post-incident analysis. Social engineering starts with the attacker's Tornado Cash infrastructure funding activity.
What Dedge flags: The creation of durable nonce accounts associated with known governance signer addresses is an observable on-chain event. A posture monitoring surface baselining governance-adjacent account activity would flag new durable nonce account creation tied to Security Council addresses as anomalous, regardless of whether those accounts are used immediately. We do not have visibility into whether Drift's team was aware of these account creations at the time.
Finding 2: Zero-Second Timelock Governance Migration Executed Without Public Governance Vote
Severity: Critical. Observable on-chain at execution.
On March 26–27, four days before the drain, Drift's Security Council was migrated to a new 2-of-5 multisig configuration with a zero-second timelock. Four of the five signers were replaced. The migration was executed without a public governance vote.
Two compounding failures are present here.
First, the timelock removal. A 2-of-5 multisig is already a low-friction governance threshold for a protocol holding several hundred million dollars in user assets.
Removing the timelock collapsed proposal approval and execution into a single atomic moment. With a non-zero timelock, the malicious admin-transfer proposal created at block 410344005 would have surfaced on-chain before taking effect, giving Drift's team, monitoring services, and the broader security community a window to detect and intervene. With a zero-second delay, there was no such window.
Second, the absence of public communication. A migration that simultaneously replaces four of five signers and eliminates the timelock is a material change to the protocol's security posture. It was not communicated publicly before landing on-chain. Until 16:05 UTC on April 1, no one outside the core team had registered that Drift's last defensive layer had been removed.

Severity classifications per Dedge Security assessment. Detection windows reflect the earliest point
at which a continuously operating W3SPM system would have generated an actionable alert. "Heuristic signal" = medium-confidence flag requiring analyst review. On-chain dates confirmed via Solana mainnet and TRM Labs post-incident analysis.
What Dedge flags: Governance configuration changes, including multisig threshold modifications, signer set changes, and timelock adjustments, are on-chain events. A posture monitoring surface that baselines governance configuration and alerts on deviations would have flagged this migration immediately on March 26–27, providing sufficient lead time before the April 1 execution to investigate and respond.
Finding 3: Trust-by-Default Collateral Whitelisting with No On-Chain Validation Against Fabricated Assets
Severity: Critical. Partially detectable before exploit.
Before execution, the attacker deployed a fictitious asset, CarbonVote Token (CVT), on Solana. It was seeded with a small amount of liquidity on Raydium and wash-traded to anchor a synthetic price near $1. On March 11, approximately 9 hours after funding the attacker's infrastructure via Tornado Cash, CVT went live on-chain. It had no legitimate use case, negligible organic liquidity, and no documented relationship to Drift or its ecosystem.
Once governance control was transferred at block 410344009, the attacker added CVT to Drift's accepted collateral list, pointed an attacker-controlled oracle at it, and configured the system to allow borrowing against it without a practical limit. A few hundred dollars in synthetic liquidity were used to borrow $285 million in real user assets. Drift's contracts executed these instructions correctly. The design assumption — that governance would never authorize a fabricated asset as collateral — had been invalidated five days earlier.
Two compounding failures are present here.
First, the absence of on-chain validation of the legitimacy of collateral assets. Collateral additions rely entirely on governance authorization, with no secondary check against asset age, liquidity depth, on-chain history, or provenance.
Second, the oracle configuration allows an attacker-controlled feed to be substituted immediately upon governance compromise, with no timelock or external attestation requirement.

The centre column represents the attack surface assessed by neither smart contract audits (which evaluate static code at a fixed commit) nor existing runtime monitoring tools (which flag transaction-level anomalies rather than governance state). Drift's February 2026 re-audit was completed before the March 26 governance migration that produced the critical exploitable condition. All three findings originate in the unmonitored post-deployment state.
What Dedge flags: The CVT deployment and its seeding activity on Raydium were observable on-chain from March 11. A posture surface monitoring for new asset deployments from addresses with funding provenance tied to mixers or known attacker infrastructure would have flagged CVT prior to its use as collateral. We note that attributing this deployment to an attacker, absent the subsequent exploit, requires heuristic analysis of funding provenance and would be classified as a medium-confidence signal rather than a confirmed finding.
Why Audits Did Not Catch This
Drift’s smart contracts were reviewed twice. Neither engagement was scoped to evaluate the live governance posture surrounding those contracts. Audits are point-in-time assessments of deployed code. They cannot evaluate a multisig migration that occurs four days before an attack, a durable nonce account created three weeks into the staging phase, or a collateral asset whitelisted at execution time.
The attack surface here was not static. It changed four days before execution. The defensive surface of two audits, both completed before that change, did not.
Execution: Two Transactions, Four Slots
At block 410344005 (16:05:18 UTC), the first transaction created the malicious admin-transfer proposal inside Drift's Squads V4 multisig and recorded the first pre-staged approval. At block 410344009 (16:05:19 UTC), one second later, the second transaction supplied the second approval and executed the stored instructions atomically.
There was no proposal review window. There was no community visibility. The attacker held administrative authority over Drift before most monitoring dashboards had finished refreshing.
From that point, the drain was procedural. CVT was added as collateral. The oracle was pointed at the attacker-controlled feed. Withdrawal limits and circuit breakers were relaxed. Vaults were drained across approximately twenty asset categories: JLP ($155.6M), USDC ($60.4M), wrapped Bitcoin variants, USDT, wrapped ETH, DSOL, and a long tail of memecoins and yield tokens. Over $230M in USDC moved across Wormhole and Circle's CCTP across more than 100 transactions within hours.
Drift's contracts never failed. They executed exactly the instructions they were given by addresses that held legitimate authority to issue them.
Summary | ||
|---|---|---|
Finding | Layer | Detection Point |
Durable nonce accounts pre-staged against signer addresses | Governance/signer hygiene | On-chain monitoring during staging |
Zero-timelock governance migration, no public vote | Governance configuration | On-chain alert at migration execution |
Fabricated asset deployed and seeded before use as collateral | Collateral posture | Heuristic monitoring of new asset deployments |
No on-chain collateral validation against fabricated assets | Smart contract | Code review |
Oracle substitution with no timelock or attestation requirement | Smart contract/governance | Code review and configuration baseline |
Recommendations
Governance threshold and timelock policy should reflect TVL and blast radius. A 2-of-5 multisig with a zero-second timelock is not a governance system for a protocol holding several hundred million dollars. Timelocks on privileged actions should be measured in days. Any migration that simultaneously alters signer set and timelock policy should require a higher-friction ratification path and public communication before it lands on-chain.
Privileged signers should operate on dedicated, isolated devices. Every transaction should be decoded and verified at the instruction level before signing. Approval based on UI description text is not verification.
Collateral additions, oracle authority changes, and bridge endpoint modifications should require timelock plus posture-system attestation. The collateral whitelist is not a routine parameter. It is a direct control surface over protocol solvency.
A continuous W3SPM surface that baselines governance configuration, signer-adjacent account activity, oracle topology, and collateral whitelists — and alerts on deviation from that baseline — would have generated actionable signals at a minimum of three points in this attack timeline before execution day.
If you are building on Solana or managing a protocol with governance-controlled economic primitives, and you have not reviewed your posture across smart contract architecture, governance configuration, or cloud key custody, reach out to the team at @DedgeSecurity or visit dedgesecurity.com.
Connect with us on: