Drift Protocol: Incident Report

On April 1, 2026, Drift Protocol lost $285 million in 12 minutes. The attackers had been building toward this for six months, constructing false identities, meeting Drift contributors in person across multiple countries, and pre-signing malicious multisig transactions months before deploying them. 

The loss was the result of an operational security failure, not an exploit of Drift's smart contracts. The same group of attackers is believed to be behind the $50 million Radiant Capital exploit in October 2024, and the operation followed a pattern seen in several major crypto heists over the past two years.

How the attack unfolded

Phase 1: Infiltration (Fall 2025 – February 2026). Starting in fall 2025, a group of individuals posing as representatives of a quantitative trading firm approached Drift contributors at a major crypto conference. A Telegram group was established at that first meeting. What followed were months of substantive conversations about trading strategies and vault integrations, multiple in-person meetings at conferences across multiple countries, and enough technical fluency to seem credible. 

From December 2025 through January 2026, the group onboarded an Ecosystem Vault on Drift, depositing over $1 million of their own capital. They filled out intake forms, asked detailed product questions, and built a functioning operational presence inside the Drift ecosystem. The profiles they deployed had fully constructed identities: employment histories, public-facing credentials, professional networks that held up under scrutiny. Drift's own April 5 update notes that the individuals who appeared in person were not North Korean nationals; threat actors operating at this level are known to use third-party intermediaries for face-to-face relationship-building.

Integration conversations continued through February and March 2026. Throughout this period, links were shared to projects, tools, and apps the group claimed to be building. The attackers compromised at least two devices of Drift contributors through at least two known malware vectors: a malicious code repository exploiting a known VS Code/Cursor vulnerability and a fake app distributed via Apple's TestFlight.

Phase 2: Preparation (March 2026). Using the compromised devices, the attackers obtained pre-signed multisig approvals from two of Drift's five Security Council members. Solana's durable nonce feature, which allows transactions to be signed in advance and remain valid indefinitely. Standard Solana transactions expire after roughly 90 seconds; a durable nonce transaction can sit dormant for weeks and execute on command.

Separately, the attackers created a fake token, Carbon Vote Token (CVT), seeded it with roughly $500 in liquidity on Raydium, and used wash trading to fabricate a price history that Drift's oracles would accept. On March 27, Drift migrated its Security Council to a zero-timelock configuration, removing the last window for detection.

Phase 3: Execution (April 1). On April 1, the attackers deployed pre-signed transactions. The attacker listed CVT as valid collateral, raised withdrawal limits to approximately $500 trillion, deposited CVT, and executed 31 withdrawal transactions draining $285 million. The largest single component was $155.6 million in JLP tokens, followed by $60.4 million in USDC and $11.3 million in cbBTC, with the remainder spread across USDT, WETH, DSOL, WBTC, and others. Right as the exploit happened, the group's Telegram chats and malicious software were completely scrubbed.

The attacker then bridged $232 million in USDC to Ethereum via Circle's own Cross-Chain Transfer Protocol across more than 100 transactions over six hours. Remaining funds were converted to ETH and laundered through Tornado Cash.

Current status (April 9). TRM Labs and Elliptic independently attributed the attack to UNC4736, a North Korean state-affiliated group also tracked as AppleJeus and Citrine Sleet, a group that has been discussed at length by security experts such as samczun of the Security Alliance in the past. Drift's April 5 update, supported by the SEAL 911 investigation team, assessed with medium-high confidence that this was the same operation behind the October 2024 Radiant Capital hack. All remaining protocol functions have been frozen, and the compromised wallets have been removed from the multisig. The attacker's wallets have been flagged across exchanges and bridge operators. The Drift team has been working with law enforcement to trace the stolen funds.

How the damage spread

Drift sits at the center of Solana's DeFi ecosystem. Many protocols use Drift vaults as the yield layer for their own products: savings accounts, lending markets, structured yield tokens and delta-neutral strategies. When Drift was drained, the losses cascaded across at least 20 protocols within 72 hours.

Estimated downstream losses across affected protocols exceed $22 million, with final figures likely to be higher once assessments are complete. Solana DeFi TVL fell 12% in the week that followed, from $8.1 billion to $5.7 billion.

What should have been different

The SEAL (Security Alliance) publishes two frameworks considered the industry benchmark for protocol security: the Multisig Security Framework and the Operational Security Framework. Any one of the following controls would have changed the outcome.

• Timelock enforcement: A 24-48 hour timelock on admin transactions would have created a detection window. Drift removed its timelock entirely on March 27. 

• Higher multisig threshold:A 3-of-5 multisig threshold, rather than 2-of-5, would have required compromising an additional signer. 

• Transaction verification procedures: Any of the signers independently decoding and verifying the transactions before signing. 

• Address whitelisting: Address whitelisting at the contract level would have blocked CVT from being listed as collateral regardless of oracle data. 

• Endpoint security and device separation: Dedicated signing devices, separate from development machines, would have isolated the VS Code and TestFlight malware before it reached privileged keys. 

• On-chain monitoring: Continuous onchain monitoring would have flagged the CVT token creation, durable nonce account setup in the weeks before the attack, and the zero-timelock migration on March 27.

At Nexus Mutual, we are strong proponents of the Security Alliance's work to promote industry standards, detect emerging threats, share information about threat actors, analyze hacks and exploits, and respond in real time when losses happen onchain. If more teams adopted the Security Alliance's frameworks, we could dramatically reduce losses due to operational security failures and better secure critical infrastructure in the onchain economy. 

A well-defined standard for operational security in web3 would enable Nexus Mutual to underwrite cover to protect against this attack vector for teams that are certified and stay in compliance.

Does Nexus Mutual cover this?

The Drift exploit raises important questions about how onchain cover products respond to attacks that blend social engineering, oracle manipulation, and multisig compromise. Before examining Nexus Mutual’s coverage clauses, it is important to establish the root cause: a six-month social engineering campaign, malware on developer devices, and a multisig key compromise.

Nexus Mutual’s Protocol Cover addresses protocol-layer failures including smart contract exploits, oracle manipulation, governance takeovers, and liquidation failures in the designated protocols. Protocol Cover does not protect against operational security failures at the team level, such as social engineering, phishing, or malware that compromises privileged keys. While Nexus Mutual would like to cover losses that stem from these attack vectors, it is incredibly difficult to verify a protocol team's operational security practices and ensure they are following industry best practices. Without an industry standard for operational security in web3, the risk premium to cover this attack vector would be extremely expensive for teams or end users.

Two covered event clauses in Nexus Mutual’s Protocol Cover product appear relevant on first read. 

The CVT oracle manipulation fits the surface definition of oracle manipulation under Clause 2.2.2 (of Nexus Mutual Protocol Cover Terms), but it was only possible because the attacker had already hijacked the Security Council multisig. The oracle manipulation was a downstream effect of the key compromise, not an independent failure of Drift's oracle system. 

The unauthorized admin transactions superficially resemble a governance takeover under Clause 2.2.4, but a governance takeover requires exploiting an onchain governance mechanism. What happened at Drift was off-chain social engineering followed by multisig key compromise.

The decisive clause is Clause 10.2, which excludes losses due to phishing, private key security breaches, malware, or any other activity where the designated protocol continues to act as intended. Throughout the attack, Drift's contracts executed exactly as designed. They processed valid, properly signed multisig transactions. The protocol didn't malfunction. It faithfully followed instructions from what appeared to be authorized signers. That the signers had been deceived doesn't change the code-level outcome.

While Protocol Cover does not cover losses due to operational security failures, it is designed to cover losses in lending markets from liquidation failure. We shared in our Resolv Protocol: Incident Report: "When fixed-rate oracles are not updated to reflect the true value of an asset, prevent liquidation of unhealthy borrow positions, and bad debt is socialized across lenders, that's a covered event under Protocol Cover's liquidation failure clause." At this time, it's unclear if liquidation failure occurred in any of the protocols impacted by the Drift loss event.

Drift Protocol Cover has never been listed on Nexus Mutual. None of the downstream protocols that absorbed losses are currently listed either. No claims have been received as a result of this event. We'll provide an update if that changes.

Why smart contract audits are no longer enough

The Drift exploit isn't isolated. Nine days before it, Resolv lost approximately $23-25 million when an attacker compromised an AWS signing key, minted 80 million unbacked USR tokens, and extracted value within minutes. The same structure appears across the Ronin Bridge hack, the WazirX breach, and the Bybit heist: patient infiltration, compromise of privileged signers or keys, rapid execution.

Drift escalated the pattern in two ways. It demonstrated that Solana-specific infrastructure, specifically durable nonces, can be exploited in ways most protocols hadn't modeled. And it proved that DeFi composability means a single operational failure can cascade to 20+ protocols and tens of millions in secondary losses within hours.

Smart contract audits are necessary to secure onchain code. They're not designed to review privileged actions and admin-level access via centralized dependencies within a protocol's architecture. The protocols that survive the next wave will be the ones that treat operational security with the same rigor they apply to code: higher multisig thresholds, mandatory timelocks, dedicated signing devices, continuous onchain monitoring, active human-layer security testing. The easiest way to avoid this attack vector is to design a protocol without centralized points of failure. If that's not possible, teams should adhere to best practices laid out by the security experts like the Security Alliance.

Protocol Cover is built to protect against worst-case scenarios when smart contracts, oracles, economic design, or governance processes fail. The industry's biggest losses are now caused by operational security failures when teams do not follow industry best practices. Closing that gap requires cover products that explicitly address operational security risk alongside the protocol-layer events that existing products already cover. Until those products exist, investors should understand the distinction clearly. Knowing what your cover protects you against is as important as having it.

Operational security failures have been a leading cause of loss for the last several years and are responsible for nearly 50% of all losses in DeFi and CeFi since 2016. This attack vector is responsible for the majority of losses in Q1 2026. Our team takes this threat seriously, and we have been working with security experts in the Security Alliance to build a cover product that can cover losses from operational security failures. Look for more updates on this cover product in Q2 2026.

If you want to know how you can cover your current positions, reach out at nexusmutual.io/contact.

Nexus Mutual has paid 100% of valid claims since 2019. That record exists because we're precise about what we cover and honest about what we can't cover.