Two transactions, $285 million vanished: A full analysis of the Drift protocol attack.

From pre-signature to breach of permissions, why is Drif's security defense so ineffective?
Written by: Four Pillars
Compiled by: AididiaoJP, Foresight News
Key points
On April 1, 2026, at 16:05 (UTC time), the Drift protocol suffered a major attack worth approximately $285 million. Drift is a leading perpetual contract decentralized exchange in the Solana ecosystem. This attack involved a sophisticated collateral manipulation scheme: the attackers used a compromised administrator key to launch a new spot market for worthless tokens, subsequently disabled withdrawal protection, and finally withdrew real assets using fabricated collateral value.
This attack combined persistent random number-based pre-signature technology with advanced social engineering techniques. Starting March 23, the attacker created persistent random number accounts for two multi-signature signers and two accounts controlled by the attacker. Even after the protocol provider performed a legitimate multi-signature migration on March 27, the attacker successfully regained access to two of the new signers. The attacker obtained pre-signatures from the legitimate signers by misleading the transaction content, stored them using persistent random numbers, and executed them in batches on April 1, ultimately seizing administrator privileges. This incident did not involve mnemonic phrase leakage or smart contract vulnerabilities.
This incident represents yet another major operational security failure, occurring just 10 days after the Resolv attack. Resolv's collapse stemmed from its complete lack of a multi-signature mechanism; while Drift, despite having multi-signature, also succumbed due to a low threshold and a lack of additional security mechanisms. Both incidents underscore the urgent need for a fundamental redesign of privileged architectures.
Event Overview
Source: @DriftProtocol
On April 1, 2026, at 16:05 (UTC), Drift, the flagship perpetual contract decentralized exchange protocol on Solana, suffered a massive attack. Drift is a protocol that provides leveraged trading, spot trading, lending, and a variety of other decentralized financial services. Its architecture combines virtual automated market makers with on-chain order books. Just before the attack, the protocol had approximately $309 million locked in total value.
Source: @PeckShieldAlert
Around 18:10 (UTC time), about two hours after the attack began, the Drift team posted a message on the X platform asking users to suspend deposits. Subsequently, the team confirmed the attack and suspended all deposit and withdrawal functions. Several security and on-chain analytics companies, including PeckShield and Lookonchain, estimated the losses at approximately $285 million. Phantom Wallet quickly took action, blocking access to the protocol.
This incident has attracted particular attention because it occurred only 10 days after the Resolv attack, making it another large-scale administrator key breach in a short period. Both incidents share a common root cause: the fundamental reason is not a vulnerability in the smart contract code, but rather operational security errors.
Root cause analysis
The core of this attack lies in the attacker's manipulation of collateral using leaked administrator privileges. If the Resolv incident was a case of "a key with minting privileges being leaked," then the Drift incident was a case of "a key with market launch and security configuration privileges being leaked." While their manifestations differ, their root causes are the same. The attack process will be analyzed step-by-step below.
Source: Dexscreener
The most direct tool used in this attack was the CarbonVote Token (CVT), a token with extremely low liquidity. One of the addresses controlled by the attacker (FnYXwy...LpAjjx) issued this token three weeks before the attack. The total supply of CVT is approximately 750 million, with the attacker's wallet holding over 80%. The attacker created a minimum liquidity pool worth approximately $500 on Raydium and subsequently engaged in continuous wash trading.
The `initializeSpotMarket` function in the Drift protocol allows administrators to directly specify the oracle address and its parameter sources. A review of existing spot market software development kit configurations reveals that each market defines its own oracle, oracle source, and token minting fields. This means that even tokens like CVT, which lack a Pyth price feed, can be listed on the market using any oracle source if an attacker gains administrator privileges.
In this attack, the attacker designated a Switchboard price feed as their oracle for the CVT market. Switchboard is an oracle network, and creating custom price feeds is relatively easy. The attacker configured a price feed under their control, valuing 785 million CVT at hundreds of millions of dollars. Price tracking platforms such as Dexscreener showed the CVT price at around $1, but its actual market liquidity and intrinsic value were virtually zero.
The emptied wallet used in the attack (HkGz4K...ovpZES) first became active approximately eight days prior, on March 24th. This wallet attempted to receive pre-charged funds via the NEAR protocol; on-chain records show that the wallet completed 325 transactions by the day of the attack.
The on-chain activity history of the administrator signer (H7PiGq...y7ZgL) used on the day of the attack is also noteworthy. This key only recorded 29 transactions in total. Its first transaction occurred on March 31st at 15:05 (UTC time), the day before the attack; the last transaction occurred on April 1st at 18:05 (UTC time), the day of the attack. This key existed on-chain for approximately 27 hours. The reason for this is clearly evident from the on-chain records.
Administrator privileges in the Drift protocol are not managed by a single externally owned account, but rather through a multi-signature mechanism. However, subsequent investigations revealed an attack path far more complex than a simple multi-signature intrusion. Approximately nine days before the attack, the attacker created four persistent random number accounts. Two of these were associated with signers for the Drift Security Committee's multi-signature process, while the other two were controlled by the attacker. Persistent random numbers are a mechanism on Solana that bypasses the approximately one-minute block hash validity period in normal transactions, allowing for the early collection of signatures and later execution. It is believed that the attacker exploited this mechanism to obtain pre-signatures from legitimate signers by misleading the transaction content.
Four days later, the Drift team executed a planned multisignature migration due to changes in security committee members. This migration was part of a routine procedure, but the attackers successfully adapted to the change.
The day before the attack, the attacker created a new persistent random number account for one of the signers in the migrated multisignature (6UJbu9...Pvu924). At this point, the attacker had regained valid access to two-fifths of the signers in the updated multisignature. This indicates that the attacker had deeply penetrated the system and was even capable of handling unexpected changes such as multisignature migrations.
On the day of the attack, the Drift team performed a routine test withdrawal from the insurance fund. About a minute later, the attackers quickly executed two pre-signed persistent random number transactions in quick succession.
Source: solscan
The first transaction executed the VaultTransactionCreate, ProposalCreate, and ProposalApprove instructions on Squads multisignature, creating a malicious administrator transfer proposal and recording the first approval.
Immediately following, the second transaction executed the ProposalApprove and VaultTransactionExecute instructions using persistent random numbers. The two-fifths threshold was immediately reached, and because the time lock was set to zero seconds, the transaction was executed instantly. At this point, the UpdateAdmin instruction in the Drift V2 program was invoked, transferring the administrator address to the attacker (H7PiGq...y7ZgL).
The key detail here is that both transactions were fully signed beforehand and submitted in batches on the day of the attack. The signer likely did not fully understand the content of the transactions they were signing. The term "transaction misrepresentation" used by the Drift team suggests that the signer was tricked into signing malicious administrator transfer transactions disguised as routine operations. The purpose of persistent random numbers is to store these pre-signatures indefinitely, allowing the attacker to execute them at a time of their choosing.
The replaced administrator signer then invoked the Drift V2 program (dRifty...cn33UH) and performed two operations.
Source: solscan
First, the attacker registered CVT as a new spot market on Drift using the initializeSpotMarket instruction. In this process, a new spot market account (BY3WYn...FVU1Cf) and two CVT token accounts were created, and the program-derived addresses of the Drift vault (PDA, JCNCMF...XXJfrw) were set as the token owners.
Drift operates a multi-asset collateral system, meaning tokens registered on a new spot market can be immediately used as collateral. However, to be considered eligible collateral, the market's `initial_asset_weight` and `maintenance_asset_weight` parameters must be set to positive values ​​greater than zero, while the default initial values ​​are low or close to zero. Analysis of the attack transaction (4a5962R...st82X) shows that `updateSpotMarketMarginWeights` (or an equivalent risk parameter update) and `initializeSpotMarket` were executed in the same transaction, with the attacker setting the CVT's collateral weight to the maximum value.
This exposes a critical design flaw from a defense-in-depth perspective: operations such as market launch, oracle source designation, maximum collateral weight configuration, and withdrawal protection disabling can all be completed in a single transaction. The weight discount factor, intended to prevent the risk of large position concentration, loses its effectiveness once the weight itself is set to its maximum value. If the program sets an upper limit on the weight of newly created markets, or sets an independent time lock for weight changes, then this attack that could dismantle all defenses in one fell swoop would be impossible.
Source: solscan
Second, in the same transaction, the attacker invoked the `updateWithdrawGuardThreshold` command five times, raising withdrawal limits in major asset markets to extreme levels. All market limits were set to a uniform value of approximately 500 trillion, effectively pushing the threshold of withdrawal protection mechanisms to infinity, thus rendering the security features designed to prevent abnormally large withdrawals ineffective.
This transaction (4a5962R...st82X) simultaneously destroyed three of Drift's core defenses.
First, the price mechanism was compromised by assigning a Switchboard price feed controlled by the attacker as an oracle. Second, the collateral weight was set to the maximum value, allowing a token with no intrinsic value to be considered high-quality collateral. Third, the withdrawal protection threshold was raised to approximately 500 trillion, effectively eliminating the blocking mechanism for abnormal withdrawals.
Including the change of administrator privileges, the attacker dismantled the entire security architecture of the protocol with just two transactions. From a code auditing perspective, this presents a profound paradox: Drift's contract code operated exactly as the audit confirmed. `initializeSpotMarket` registered the new market, specified the oracle source, and set the weight parameters as designed; `updateWithdrawGuardThreshold` modified the limit as designed. The root of the problem lies in the system design itself—a design that allows the entire attack chain to be completed within a single transaction. This goes beyond the scope of code auditing; it falls under the category of privileged architecture and parameter constraint design.
Ultimately, the attacker deposited approximately 785 million CVT as collateral through a newly created Drift user account. The attacker-controlled Switchboard oracle valued this at hundreds of millions of dollars, and the highest collateral weighting recognized almost the entire valuation as valid collateral. Drift's margin system functioned exactly as designed. The problem was that every parameter input into the system had been maliciously manipulated by the attacker.