$285M Gone: How Blockaid's Cosigner Could have Protected Drift Protocol

On April 1, 2026, at approximately 16:05:39 UTC, Drift Protocol — Solana's largest perpetuals DEX — became the victim of the most sophisticated governance-layer attack in DeFi history. Approximately $285 million was drained from the protocol's vaults, representing more than 50% of its total value locked, across 15+ asset types including JLP, USDC, wBTC, cbBTC, wETH, dSOL, and liquid staking tokens. The entire drain took under 12 minutes.

This was not a smart contract vulnerability. This was not a seed phrase compromise. This was a meticulously planned, multi-week social engineering and operational security attack that exploited the most fundamental trust assumptions in DeFi governance: the humans behind the keys.

Blockaid's research team was actively monitoring the situation from the moment anomalous activity was first detected onchain. This post details what we observed, how the attack unfolded, the onchain forensics, and what Blockaid's role was in the response and ongoing remediation effort.

Background: What Is Drift Protocol?

Drift Protocol is a Solana-native, exchange-grade composite DeFi protocol. Launched in 2021, it operates as a decentralized perpetuals and spot exchange powered by a virtual automated market maker (vAMM). Beyond trading, Drift had expanded into borrow/lend markets and vaulted yield products, growing to over $550M in TVL and more than 175,000 active traders at its peak, with more than $20 billion in cumulative trading volume.

The protocol maintains a Security Council — a small group of trusted multisig signers empowered to take fast-track emergency action without waiting for full DAO governance votes. This council was the attack's primary target.

The Attack: A Multi-Week Campaign

This was not a smash-and-grab. The attacker invested significant time and operational discipline in staging the exploit across multiple phases spanning at least nine days.

Phase 0: Token Pre-Positioning (Weeks Prior)

Long before the execution phase, the attacker created a token called CarbonVote Token (CVT) — a fake asset minted solely to serve as illegitimate collateral. Approximately 750 million CVT were minted, with the attacker controlling roughly 600 million (80%) of the supply.

Critically, the attacker seeded a Raydium liquidity pool with approximately $500 and then executed wash trades against their own positions to fabricate a price history near $1. Over time, this artificial trading volume was ingested by a SwitchboardOnDemand oracle — one the attacker themselves controlled — which anchored CVT's apparent onchain value. This price history was instrumental in making CVT appear to be a legitimate, market-priced asset.

Phase 1: Durable Nonce Setup (March 23–30)

Between March 23 and March 30, the attacker created four durable nonce accounts:

45cZ5Fj97Va5Abipr6NN8Zf1BqZqWneSek1hU5cQRvhw — Drift Security Council member
39JyWrdbVdRqjzw9yyEjxNtTbTKcTPLdtdCgbz7C7Aq8 — Drift Security Council member
CZRBcHAvXU6TzzjGuG4rT98UuTR7PBUeSGPZRDW5mfYW — attacker-controlled
48cV6Mw5Y5afT8ofukvtFaMtrsCohHhsv8MfbdW8agh3 — attacker-controlled

For readers unfamiliar: durable nonces are a Solana-native mechanism that allows a transaction to be signed in advance and executed at an arbitrary later time, bypassing the standard "recent blockhash" expiry that normally causes unsigned transactions to expire after ~90 seconds. In legitimate usage, durable nonces help developers batch, retry, or stage complex transaction flows. In this attack, they became the instrument of delayed detonation.

Two legitimate Security Council members were induced — through social engineering or deliberate transaction misrepresentation — to pre-sign nonce-bound transactions that appeared benign at the time of signing, but whose payloads encoded a malicious admin transfer.

Phase 2: Multisig Migration Window (March 27)

Drift executed a planned Security Council migration around March 27 due to a change in council membership. The new configuration established a 2-of-5 multisig with a 0-second timelock. Of the five new signers, only one carried over from the previous setup; the other four were brand new.

The attacker had already compromised effective signature authority over the old multisig. On March 30, they obtained a pre-signed nonce transaction from a member of the new multisig as well — meaning, critically, that they had now obtained 2-of-5 effective authority across the updated council before the execution day arrived.

This was the moment the attack became inevitable.

Phase 3: Execution Day (April 1, 16:05 UTC)

At approximately 16:05 UTC, the attacker detonated in a precise, multi-step sequence:

Step 1 — Admin Takeover (~seconds): Two pre-signed durable nonce transactions were submitted four Solana slots apart. The first created and approved a malicious admin transfer; the second approved and executed it. Combined, they handed the attacker full control of Drift's protocol-level administrative authority.

Step 2 — Market Creation: The attacker called InitializeSpotMarket, creating Spot Market #63 for CVT. The parameters were tuned specifically for maximum extractability: initial asset weight set to allow unlimited borrowing, maintenance margin effectively zeroed out.

Step 3 — Circuit Breaker Removal: In the same transaction, the attacker lifted the withdrawal circuit breakers on five real asset markets by a factor of 20x or more:

USDC: 25T → 500T
wETH: 200B → 500T
dSOL: 5T → 500T
JLP: 5B → 500T
cbBTC: 10B → 500T

Step 4 — Collateral Deposit and Drain: 500 million CVT tokens were deposited into Drift as collateral. Because the attacker-controlled oracle priced CVT at approximately $1, the protocol perceived this as hundreds of millions in legitimate collateral. The attacker then executed 31 rapid withdrawals against this phantom collateral, draining real assets: USDC, JLP, SOL, wBTC, cbBTC, wETH, dSOL, JTO, and others.

The JLP vault went from 41.7 million JLP to 133 JLP remaining — a 99.9997% drain.

Post-Exploit: Fund Movement and Laundering

After the drain, the attacker moved rapidly to launder and convert the stolen assets. Blockaid and our partners began tracking fund flows immediately.

The stolen funds were routed from the primary exploit wallet (HkGz4KmoZ7Zmk7HN6ndJ31UJ1qZ2qgwQxgVqQwovpZES) through a launderer wallet (8ubo4HbWJHKyFJYJc2Gh74dxCP7bN7Fu2Pi13KZ9rGxw), then swapped via the Jupiter aggregator on Solana before bridging cross-chain via deBridge and Wormhole to Ethereum. On the Ethereum leg, assets were converted into ETH (approximately $82M worth), and funds were dispersed across multiple Ethereum addresses before movement toward mixers. Portions were also deposited to Hyperliquid and Binance.

The exploiter's primary Solana wallet ended the day holding approximately 0.112 SOL — essentially dust — suggesting near-total asset egress.

Blockaid’s Incident War Room: Detection, Marking, and Response

Blockaid's research team began monitoring anomalous activity as it was first detected onchain in the hours preceding Drift's public acknowledgment. Here is how we engaged:

Threat Intelligence and Entity Marking: The exploiter wallet HkGz4KmoZ7Zmk7HN6ndJ31UJ1qZ2qgwQxgVqQwovpZES and the compromised admin address H7PiGqqUaanBovwKgEtreJbKmQe6dbq6VTrw6guy7ZgL were flagged and marked as malicious in Blockaid's threat intelligence platform in real time. Any wallet or dApp interaction touching these entities is now surfaced as a high-severity threat to all Blockaid-integrated products.

Customer Triage: We conducted an immediate review of all assets uploaded to the Blockaid platform by our customers. Customers who were not directly notified by our team were not materially affected by this specific incident. We are continuing to monitor for any secondary exposure from Solana DeFi contagion.

Ecosystem Coordination: We are actively working with Drift Protocol, bridges, exchanges, and the broader Solana security ecosystem to support remediation and asset tracing. If you have information relevant to the investigation, Drift has requested contact at [email protected].

Pattern Recognition: This attack shares a structural fingerprint with the Resolv USR exploit from ten days prior, in which a SERVICE_ROLE key compromise enabled the minting of $80M in unbacked USR and the extraction of $25M+. The recurrence of this pattern — privileged key compromise → fake asset creation → oracle manipulation → vault drain — points to a persistent threat actor profile that DeFi teams and their security partners must treat as an active, iterating adversary.

The Structural Problem: Keys Are the New Attack Surface

The smart contracts passed audits. Trail of Bits reviewed the codebase in 2022. ClawSecure issued a passing grade as recently as February 2026. Neither review caught the governance configuration that made this attack possible.

That is because the attack surface was not the code — it was the key management architecture.

Drift's admin signer had, in a single unsigned transaction moment, the ability to:

Create a new collateral market with arbitrary parameters
Assign an attacker-controlled oracle to that market
Disable withdrawal guards on every major vault

And after the March 27 multisig migration:

No timelock was in place
The 2-of-5 threshold was the lowest defensible quorum
Brand-new signers with no track record on the council had near-equal authority to long-tenured members
Durable nonces were not specifically prohibited or monitored for governance-sensitive paths

The 0-second timelock is perhaps the most critical failure. A 24-hour timelock on admin operations would have provided an actionable detection window. A 48-hour timelock would have given the security community time to identify and block the malicious pre-signed transactions before they detonated.

Instead, the attacker's two nonce transactions were submitted and executed in four slots.

How Blockaid Cosigner Could Have Protected Drift

About Blockaid Cosigner

Every multisig setup has an inherent security paradox: the humans approving transactions are simultaneously the protocol's most important safeguard and its most exploitable weakness. Sophisticated attackers — as demonstrated in both Bybit and Drift — do not need to break cryptography. They need to deceive a person into signing something they do not fully understand.

Blockaid Cosigner is built to close that gap. It is an automated, policy-enforcing signer that integrates natively into multisig and MPC wallet workflows — including Gnosis Safe, Fireblocks, and Squads — and acts as an independent, always-on validation layer that sits between transaction creation and execution. Unlike human signers, Cosigner does not read a wallet UI. It receives the raw transaction payload, simulates its full onchain execution using Blockaid's real-time threat engine, evaluates the decoded outcome against your organization's configured security policies, and then either co-signs or rejects — in milliseconds, before any human signature is applied.

Critically, Cosigner operates entirely within the onchain model. There is no proprietary execution environment or offchain dependency for enforcement. Neither Blockaid nor the protocol team has unilateral control over execution — the design eliminates single points of failure by requiring both Cosigner validation and quorum from designated human signers before any transaction proceeds. As Blockaid describes it: Cosigner cannot sign unvalidated transactions, and the organization cannot bypass Cosigner without explicitly using a designated override path.

The threat surface Cosigner addresses is broad: front-end compromise and UI spoofing (Bybit, Radiant Capital), malicious contract upgrades, blind signing of delegatecall payloads, unauthorized admin transfers, supply chain injection via npm packages, insider threats, and — directly relevant to Drift — durable nonce-based deferred execution attacks that appear benign at signing time but encode malicious payloads.

The Multisig Threshold Tradeoff

Multisig governance thresholds exist to distribute risk. A single-signer arrangement concentrates total protocol authority in one key — if that key is compromised, the protocol is fully exposed. Adding a second required signer reduces this risk materially: an attacker must now compromise two independent parties, two separate environments, and two separate operational security postures simultaneously.

A third required signer reduces the risk further still — but introduces a new operational friction that protocols feel acutely in practice. Real-world multisig councils have scheduling constraints, time zones, key availability windows, and human unavailability. A 3-of-5 or 4-of-7 threshold means that governance actions can stall for hours or days if signers are unreachable, which creates pressure on security teams to use lower thresholds or introduce emergency override paths — both of which erode the security posture the threshold was designed to protect.

This is why Drift's Security Council operated on a 2-of-5 threshold with a 0-second timelock after the March 27 migration. The team was trying to preserve operational agility. The cost was that acquiring just two approvals — each potentially deceivable through social engineering — was sufficient to hand an attacker full protocol-level admin authority.

Cosigner as the Intelligent Signing Layer

This threshold tradeoff is precisely the problem Cosigner is designed to solve. Instead of forcing protocols to choose between adding slow, fallible human signers or accepting concentrated key risk, Cosigner provides a third option: an additional signer that is instantaneous, incorruptible by social engineering, and policy-driven.

In the context of Drift's 2-of-5 multisig: if Cosigner were configured as a mandatory participant in the signing quorum — functioning as a required co-signer in addition to the 2-of-5 human threshold — the attack's durable nonce transactions would have reached Cosigner's validation engine before reaching execution. Cosigner would have simulated the decoded payload, identified the malicious admin transfer, flagged the policy violations (detailed below), and withheld its signature. Without Cosigner's approval, the transaction could not have proceeded — regardless of how many human signers had been deceived into pre-signing.

Cosigner does not tire, cannot be phished, cannot be manipulated by a well-crafted social engineering campaign, and does not sign based on what a UI displays. It signs based exclusively on what the transaction will actually do onchain.

For operational transactions — routine withdrawals, parameter adjustments within defined bounds, known counterparty interactions — Cosigner evaluates against policy and co-signs automatically, in sub-300ms latency. This means safe transactions move faster, not slower, because Cosigner eliminates the waiting time for a third or fourth human signer to become available. The signature burden on human council members decreases precisely because Cosigner handles the validation that previously required careful manual review of each transaction's raw payload.

How Cosigner Could Have Been Configured for Drift

Blockaid's customizable, label-based policy engine allows security teams to define granular rules governing which transaction types are permitted, under what conditions, and with what level of automated response.

The following policy configurations would have been directly relevant to the Drift attack:

Policy 1 — Admin transfer flagging: Any transaction encoding a change of administrative authority to an address not on a pre-approved allowlist triggers an immediate rejection and high-severity alert. The Drift attacker's first durable nonce transaction — Create + approve malicious admin transfer — would have been caught at this layer. No new admin address would be accepted without explicit out-of-band approval through a secondary verification channel.

Policy 2 — New market creation controls: Any call to InitializeSpotMarket that sets initial asset weight above a defined threshold (e.g., >80%), maintenance margin below a defined floor, or assigns an oracle address not on an approved oracle registry, is automatically rejected. This would have blocked the CVT market creation in its entirety, regardless of whether the admin key had been compromised.

Policy 3 — Circuit breaker modification restrictions: Any transaction that modifies withdrawal limits on multiple markets simultaneously, or increases any single market's withdrawal ceiling by more than a configurable multiplier (e.g., 5x), is flagged as critical and blocked. The attacker's circuit breaker removal — lifting withdrawal caps by 20x across five markets in a single transaction — would have been a textbook trigger.

The result of these policies operating in concert: the attack's administrative takeover is blocked at Policy 1, before the attacker ever gains the authority to create CVT, manipulate the oracle, or touch the circuit breakers. The subsequent drain phase never occurs.

Learn how Blockaid's Cosigner and secure your Multisig or MPC Wallet →

The Broader Pattern: An Industry-Wide Problem

Drift is the second major DeFi exploit in 10 days driven by a compromised privileged key. It will not be the last. The DeFi ecosystem continues to grow in scale — but operational security postures have not kept pace with the asset custodied.

Protocols managing hundreds of millions in user funds are relying on admin key setups that would be considered unacceptable in traditional finance for a fraction of that AUM. Every admin key is a single point of failure. The question is no longer whether it will be compromised — it is when, and what controls limit the blast radius when it is.

What we recommend for every protocol building today:

Timelock all admin operations. A minimum of 24 hours; 48–72 hours for any action that changes market parameters, collateral weights, or oracle assignments.
Harden multisig thresholds. A 2-of-5 configuration is a starting point, not an endpoint. Consider 3-of-5 or 4-of-7 for protocols managing >$50M TVL, with mandatory signer rotation reviews.
Audit durable nonce usage. Explicitly restrict or monitor durable nonce pre-signing for any transaction touching governance or admin upgrade paths. Implement onchain guards that reject nonce-signed admin transactions above a defined value threshold.
Bound admin key capabilities contractually. No single admin action should be capable of simultaneously disabling circuit breakers across multiple markets. Rate-limit admin operations and enforce parameter bounds that cannot be overridden in a single transaction.
Treat governance as an attack surface. Smart contract audits are necessary but not sufficient. Conduct threat modeling on your key management setup, multisig topology, and signer onboarding process with the same rigor applied to your onchain code.

Conclusion

The Drift Protocol exploit of April 1, 2026 will be studied for years — not because it represented a novel cryptographic or smart contract vulnerability, but because it demonstrated how a patient, sophisticated adversary can render $285M extractable through nothing more than social engineering, a $500 liquidity pool, and a governance architecture with no detonation delay.

Blockaid will continue to publish updates as our investigation develops. A more thorough post-mortem covering the multisig migration, Solana DeFi contagion effects, and full vault exposure analysis is forthcoming.

Exploiter Wallet: HkGz4KmoZ7Zmk7HN6ndJ31UJ1qZ2qgwQxgVqQwovpZESCompromised Admin: H7PiGqqUaanBovwKgEtreJbKmQe6dbq6VTrw6guy7ZgLStatus: Both entities marked malicious across the Blockaid platform.

About Blockaid

Blockaid is the onchain security platform trusted by the largest companies operating in Web3. Built by veterans of elite intelligence and cybersecurity units, Blockaid provides end-to-end protection for financial institutions, protocols, and end users — combining direct wallet and dApp integrations with real-time monitoring, detection, and response across smart contracts, infrastructure, and externally owned accounts. Since 2025, Blockaid scanned over 6.3+ billion transactions and blocked 585+ million attacks. Blockaid is the security infrastructure behind Coinbase, MetaMask, Uniswap, Safe, and dozens of the most widely used platforms in the industry.

Learn more at blockaid.io, and follow us on Twitter and LinkedIn.