The Drift exploit wasn't about who had access. It was about what that access was still allowed to do. Here's how the attack unfolded and how Hypernative's monitoring and policy enforcement layer could have prevented it.
On April 1, Drift Protocol - the largest perpetual futures exchange on Solana - was drained of roughly $285M in less than 12 minutes. It is governed by a Security Council multisig, a standard DeFi pattern in which multiple signers must approve sensitive actions.
The attack combined social engineering, durable nonce transactions, privileged access, malicious market configuration, and rapid extraction of real assets against fabricated collateral. The attack did not include a contract bug.
The attack unfolded in several stages.
Before interacting with Drift, the attacker prepared the asset that would later be used in the drain.
A token called CarbonVote Token (CVT) was created, with roughly 750 million tokens minted and about 600 million controlled by the attacker. A small Raydium liquidity pool was seeded and the attacker used wash trading over several weeks to build a credible price history near $1. This step matters because the protocol does not evaluate whether an asset has real economic backing. It evaluates the inputs it is given: price feeds, liquidity signals, collateral parameters, and account health. If a new asset is accepted as collateral, and the protocol sees a price feed that looks valid, that asset can become borrowable collateral even if the underlying value is fabricated.
Between March 23 and March 30, four durable nonce accounts were created. Two were tied to Drift Security Council members, and two were attacker-controlled.
Durable nonces allow a transaction to be signed in advance and executed later, rather than expiring quickly with a recent blockhash. In this case, that feature was used to separate the signing moment from the execution moment.
Legitimate signers were induced to pre-sign nonce-bound transactions. That gave the attacker signed, executable transaction paths that could be used later without requiring real-time approval.
Around March 27, Drift’s Security Council was migrated to a new 2-of-5 multisig. Critically, the new configuration had a 0-second timelock that eliminated any delay that would have allowed detection or intervention before a privileged action could take effect. Only one signer carried over from the previous council; the other four were new.
By March 30, the attacker had obtained enough effective approvals across the old and new signer sets to reach 2-of-5 authority in the updated council before execution day.
At ~16:05 UTC on April 1, the execution phase began. 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. Together they transferred administrative control.
Once admin control was in place, the attacker moved immediately: a new spot market was created for CVT with parameters tuned for maximum extractability, maintenance requirements were set low enough to make the collateral highly extractable, and withdrawal circuit breakers were raised by 20x or more across five real asset markets (USDC, wETH, dSOL, JLP, and cbBTC) removing every withdrawal safeguard simultaneously.
The attacker deposited 500 million CVT as collateral. Because the oracle priced CVT at roughly $1 based on the manufactured trading history, the protocol treated this as approximately $500 million in legitimate collateral. The attacker then executed 31 rapid withdrawals, draining real assets across multiple markets. The JLP vault went from 41.7 million JLP to 133 JLP remaining.
At this point, the risk engine was not protecting the protocol. It was enforcing the state it had been given. Once the attacker controlled the privileged inputs, the protocol’s own collateral and withdrawal logic enabled the drain.
After the drain, funds were routed through Jupiter, bridged cross-chain via deBridge and Wormhole to Ethereum, converted into ETH, and dispersed across multiple addresses. The speed of the laundering phase (most stolen assets were bridged within hours) underscores how limited post-incident intervention is when pre-transaction controls are absent.
The speed of the laundering phase underscores how short the response window was once the drain started, and how limited post-incident intervention is when pre-transaction controls are absent.
The Drift exploit was not a single-call failure. It was a sequence of valid privileged actions that created an unsafe system state:
A stronger design would not rely only on signer validity. It would also enforce hard limits on what privileged operations are allowed to do.
Each aspect of the Drift exploit passed through a gap where a hard control could have stopped the sequence:
These are not process improvements, they are hard controls on protocol behavior.
This is the kind of hack Guardian is meant to prevent.
The key issue in Drift was not only that privileged access was reached. The bigger issue was that once access was reached, there were too few constraints on what could be done with it.
Guardian adds that extra layer.
With Hypernative Guardian, protocols can define and enforce DeFi-native policies around privileged actions and protocol configuration. Those policies are enforced onchain, not left to signer judgment or manual review.
Guardian policies are not abstract principles. They are configurable rules that teams define and Guardian enforces onchain. Here is what a policy set designed for an attack like Drift would look like in plain language:
Guardian’s strength is that these policies are highly configurable and DeFi-native. Teams can define them in Python or through a no-code workflow, and keep extending them over time as the protocol evolves. As more operational rules are encoded, unexpected access becomes much less useful because there are fewer ways to turn that access into a drain.
Policies enforce limits at the moment of execution. But several stages of the Drift attack were observable days or weeks before the drain and would have been flagged by a monitoring layer configured with protocol-specific context:
The monitoring layer and the policy layer are complementary. Monitoring surfaces risk as it develops like governance changes, privilege escalations, or unusual market activity, giving teams time to investigate and respond before an attack reaches execution. Policies enforce hard limits at the point of execution, blocking unsafe state changes regardless of whether a human has reviewed the alert. Together, they close the gap that Drift's architecture left open: the weeks of observable staging that preceded the attack, and the 12 minutes of uncontrolled execution that followed.
This matters beyond adversarial scenarios. The same policy layer that blocks an exploit path also catches the operational mistakes that happen during normal protocol management, and those happen far more often than state-sponsored attacksThat matters not only for hacks. It also matters for everyday operational safety. The same policy layer that blocks an exploit path also reduces the chance of bad market listings, unsafe parameter updates, and rushed admin actions during normal protocol operations.
Consider a protocol team that is listing a new collateral market under time pressure. Without Guardian, a misconfigured asset weight or an insufficiently vetted oracle goes live the moment the transaction is signed. The risk engine enforces whatever parameters it is given, whether those parameters were set by an attacker or by a team member who made an error under deadline. With Guardian, the listing policy catches the same issues regardless of intent: the liquidity depth check fails, the oracle history requirement is not met, the collateral weight exceeds the approved range. The transaction is blocked before it reaches the protocol.
Or consider a routine parameter update where a team member accidentally raises a withdrawal limit by 100x instead of 10x. Without a blast radius policy, that change takes effect immediately. With Guardian, the delta check catches the overshoot and blocks it the same way it would block an attacker making the identical change deliberately.
This is what distinguishes protocol-level policy enforcement from transaction-level security. Transaction validation asks: is this specific action malicious? Policy enforcement asks: is the resulting protocol state safe? The second question catches a much wider range of problems, because it does not require the cause to be adversarial. Misconfigurations, fat-finger errors, rushed deployments, and under-tested upgrades all produce unsafe states. Guardian treats them the same way it treats an exploit because from the protocol's perspective, the outcome is identical.
That is the main lesson from Drift.
The problem was not only who had access. It was what that access was still allowed to do.
Hypernative Guardian is built to enforce those limits before a protocol reaches an unsafe state.
