Table of Contents
Researcher
Key Takeaways
On April 1, 2026 at 16:05 UTC, an exploit worth approximately $285M struck Drift Protocol, a leading perpetual DEX on Solana. The attack was a sophisticated collateral manipulation scheme: the attacker used compromised admin keys to list a worthless token on a new spot market, disabled withdrawal safeguards, and then drained real assets using the fabricated collateral value.
The attack combined durable nonce-based pre-signing with sophisticated social engineering. Starting March 23, the attacker created durable nonce accounts for two multisig signers and two attacker-controlled accounts. Even after a legitimate multisig migration on March 27, the attacker re-established access to signers of the new multisig. The attacker obtained pre-signatures from legitimate signers through transaction misrepresentation, stored them via durable nonces, and batch-executed them on April 1 to seize admin authority. No seed phrase leaks or smart contract bugs were involved.
This incident marks yet another major operational security failure, coming just 10 days after the Resolv exploit. Resolv collapsed because it had no multisig at all; Drift collapsed despite having one, due to a low threshold and the absence of additional security mechanisms. Together, these two incidents demonstrate that a fundamental redesign of privilege structures is overdue.
1. Incident Overview
Source: @DriftProtocol
On April 1, 2026 at 16:05 UTC, Drift Protocol, Solana's flagship perpetual DEX, suffered a massive exploit. Drift is a protocol offering leveraged trading, spot trading, lending, and various other DeFi services built on a hybrid architecture combining a virtual automated market maker (vAMM) with an onchain order book. Just before the incident, the protocol held approximately $309M in total value locked (TVL).
Source: @PeckShieldAlert
Around 18:10 UTC, roughly two hours after the attack began, the Drift team posted on X urging users to halt deposits. They subsequently confirmed the attack and suspended all deposits and withdrawals. Multiple security and onchain analytics firms, including PeckShield and Lookonchain, have estimated the damage at approximately $285M. Phantom Wallet moved quickly to block access to the protocol.
What makes this incident particularly notable is that it occurred just 10 days after the Resolv exploit, making it yet another large-scale admin key compromise in quick succession. Both incidents share a common thread: the root cause was not a smart contract code vulnerability, but an operational security failure.
2. Root Cause Analysis
At the core of this attack was collateral manipulation through compromised admin privileges. If the Resolv incident was "compromise of a key with minting authority," the Drift incident was "compromise of a key with market listing and safeguard configuration authority." Different branches, same root. Let's walk through the attack flow step by step.
Source: Dexscreener
The most direct instrument of the attack was CarbonVote Token (CVT), an extremely low-liquidity token. One of the attacker's addresses, FnYXwy...LpAjjx, issued it three weeks before the attack. The total supply was approximately 750 million tokens, with the attacker's wallet holding over 80%. The attacker created a minimal liquidity pool on Raydium worth roughly $500, then conducted continuous wash trading.
Drift’s initializeSpotMarket function allows the admin to directly specify oracle address and source parameters. Examining SDK configurations for existing spot markets confirms that each market has individually defined oracle, oracleSource, and mint fields. This means that even a token like CVT, which has no Pyth feed, can be listed on a market with an arbitrary oracle source as long as admin privileges are secured.
In this attack, the attacker assigned a Switchboard feed as the oracle for the CVT market. Switchboard is an oracle network where creating custom feeds is relatively straightforward, and the attacker configured a feed under their control to value 785 million CVT at hundreds of millions of dollars. Price trackers like Dexscreener displayed CVT at roughly $1, but its actual market liquidity and intrinsic value were effectively zero.
The drainer wallet used in the attack (HkGz4K...ovpZES) first became active approximately eight days prior, on March 24. This wallet received pre-funding through NEAR Protocol intents, and onchain records show a total of 325 transactions up to the day of the attack.
The onchain activity history of the admin signer (H7PiGq...y7ZgL) used on the day of the attack is also worth noting. This key recorded only 29 total transactions. Its first transaction was on March 31 at 15:05 UTC, one day before the attack, and its last was on April 1 at 18:05 UTC, the day of the attack. The key's entire onchain existence spanned roughly 27 hours. The reason becomes clear from onchain records.
Drift's admin privileges were managed not by a single EOA but by a multisig. However, the attack path uncovered in subsequent investigation was far more sophisticated than a simple multisig breach. Approximately nine days before the attack, the attacker created four durable nonce accounts. Two were associated with signers of the Drift Security Council multisig, and the other two were attacker-controlled accounts. A durable nonce is a mechanism on Solana that bypasses the standard blockhash expiration (~1 minute) for regular transactions, allowing signatures to be collected in advance and executed later. The attacker is believed to have used this to obtain pre-signatures from legitimate signers by misrepresenting the actual contents of the transactions.
Four days later, the Drift team executed a planned multisig migration following a change in Security Council membership. This migration was a routine operational procedure, but the attacker adapted to the change.
One day before the attack, a new durable nonce account was created for a signer (6UJbu9...Pvu924) of the migrated multisig. The attacker had re-established valid access to 2 out of 5 signers on the updated multisig. This indicates the attacker had penetrated deeply enough into the system to adapt even to an unexpected variable like a multisig migration.
On the day of the attack, the Drift team executed a routine test withdrawal from the insurance fund. Approximately one minute later, the attacker executed two pre-signed durable nonce transactions in rapid succession.
Source: solscan
The first transaction executed
VaultTransactionCreate,ProposalCreate, andProposalApproveon the Squads multisig, creating the malicious admin transfer and recording the first approval.Immediately after, the second transaction used a durable nonce to execute
ProposalApproveandVaultTransactionExecute. The 2/5 threshold was instantly met, and because the timelock was set to zero seconds, the transaction executed immediately. At this point, theUpdateAdmininstruction on the Drift V2 program was invoked, transferring the admin address to the attacker's (H7PiGq...y7ZgL).
The critical detail here is that both transactions were fully signed beforehand and submitted in batch on the day of the attack. The signers most likely did not fully understand what they were signing at the time. The Drift team's use of the phrase "transaction misrepresentation" suggests that the signers were tricked into signing malicious admin transfer transactions that were disguised as routine operational transactions. The durable nonces served to store these pre-signatures indefinitely, allowing the attacker to execute them at the moment of their choosing.
The replaced admin signer then called the Drift V2 program (dRifty...cn33UH) to perform two actions.
Source: solscan
First, the attacker registered CVT as a new spot market (Market 63) on Drift via initializeSpotMarket. During this process, a new spot market account (BY3WYn...FVU1Cf) and two CVT token accounts were created, with the Drift vault PDA (JCNCMF...XXJfrw) set as the token owner.
Drift operates a multi-asset collateral system, meaning tokens registered on a new spot market can immediately be used as collateral. However, to be recognized as collateral, the market's initial_asset_weight and maintenance_asset_weight must be positive values greater than zero, and the default initialization values are low or near zero. Analysis of the attack transaction (4a5962R...st82X) reveals that updateSpotMarketMarginWeights (or an equivalent risk parameter update) was bundled in the same transaction as initializeSpotMarket, and the attacker set CVT's collateral weights to maximum.
This exposes a critical design flaw from a defense-in-depth perspective. Market registration, oracle source designation, maximum collateral weight configuration, and withdrawal guard neutralization could all be completed in a single transaction. The weight haircut (IMF factor) designed to prevent concentration risk on large positions also loses practical effectiveness once the weights themselves are set to maximum. Had the program enforced an upper bound on weights for newly created markets or required a separate timelock for weight changes, an attack that dismantled all defenses in a single transaction would not have been possible.
Source: solscan
Second, within the same transaction, the attacker called updateWithdrawGuardThreshold() five times to raise the withdrawal limits on major asset markets to extreme levels. All markets had their limits set to the same ~500 trillion level, effectively pushing the Withdraw Guard's threshold to infinity and neutralizing a safeguard designed to block anomalous large withdrawals.
This single transaction (4a5962R...st82X) simultaneously dismantled three core defenses of Drift.
First, the price mechanism was captured by assigning an attacker-controlled Switchboard feed as the oracle. Second, the collateral weights (initial_asset_weight, maintenance_asset_weight) were set to maximum, allowing a worthless token to be recognized as top-tier collateral. Third, the Withdraw Guard's threshold was raised to the ~500 trillion level, effectively eliminating the anomalous withdrawal blocking mechanism.
Including the admin change, a total of two transactions brought down the protocol's entire security architecture. This creates a compelling paradox from the perspective of code auditing. Drift's contract code functioned exactly as verified by audits. initializeSpotMarket registered a new market as designed, assigned an oracle source, and set weights; updateWithdrawGuardThreshold modified limits as designed. The problem lay in the design itself, which allowed the entire attack chain to be executed in a single transaction. This falls not within the domain of code auditing, but within the domain of privilege architecture and parameter constraints.
In the end, the attacker deposited approximately 785 million CVT as collateral through a newly created Drift user account. The attacker-controlled Switchboard oracle feed valued this at hundreds of millions of dollars, and the maxed-out collateral weights recognized nearly the full valuation as collateral. Drift's margin system worked exactly as designed. The problem was that every parameter fed into that system had been manipulated by the attacker.
3. Stolen Fund Status
According to PeckShield and Lookonchain, total stolen funds amount to approximately $285M. By asset breakdown, JLP (Jupiter Liquidity Provider) tokens comprised the largest share at roughly 41.72 million tokens (~$155M), followed by $51.6M–$60M in USDC, $11.3M in cbBTC, $10.4M in WSOL, and over $4.7M in other tokens including WBTC and WETH.
Immediately after the theft, funds moved from the Drift vault to the primary drainer wallet (HkGz4K...ovpZES). This wallet was confirmed to have received pre-funding through NEAR Protocol intents approximately eight days before the incident, with test transactions observed onchain a week prior.
Once funds arrived at the drainer wallet, they were rapidly dispersed and laundered in three stages. The first stage involved onchain dispersion and swaps within Solana. Starting from the drainer wallet, at least four layers of wallet layering were conducted, with large-scale USDC, SOL, and JLP swaps executed through major Solana DEXs including Jupiter Aggregator, Raydium, Orca, and Meteora. Some SOL was observed moving to Hyperliquid and then being exchanged for ETH.
The second stage was cross-chain bridging. The primary route was Circle's CCTP, which burned USDC on Solana and re-minted it on Ethereum, moving large volumes of funds. Additional direct bridging through Wormhole and auxiliary cross-chain swaps via Mayan were also identified. The majority of stolen funds passed through this stage to reach Ethereum. The third stage was laundering on the Ethereum side. After arriving on Ethereum, purchases of at least 19,913 ETH (approximately $42.6M) were observed, with some reports estimating even higher volumes. Certain wallets showed historical association patterns with Tornado Cash, and interactions with Backpack, a KYC-enabled wallet, were also observed. Funds appear to have undergone additional swaps through Chainflip as well.
Even five to six hours after the incident, some funds were still in transit. Freezing attempts were made by several CEXs and bridges, but they failed to block the full amount. cbBTC could have been frozen by its issuer, but the attacker appears to have completed swaps first. The drainer wallet's current balance is approximately 1.1 SOL, with only minor assets remaining: three troll tokens (1 billion each) presumably minted by the attacker and approximately 1.14 DRIFT tokens. The vast majority of stolen funds have already been moved through other channels. The Drift team halted the protocol to prevent further damage, but recovering the funds already drained will be extremely difficult.
4. Audit History
Drift Protocol has a fairly extensive audit track record. From November to December 2022, Trail of Bits conducted a security audit of the DEX and smart contracts, with no high-severity vulnerabilities reported. In August 2023, OtterSec performed an audit of the SNAP Solana program. From February to April 2024, Neodyme AG conducted an independent audit of core contracts. The Neodyme audit noted that Drift's development continued throughout the audit period, making it difficult to fully audit all changes. Beyond these, Drift has also maintained a continuous bug bounty program.
However, this incident fell outside the scope of those audits. Smart contract audits verify code logic, oracle manipulation possibilities, liquidation mechanisms, re-entrancy attacks, and the like, but they do not cover how admin keys are managed or the security of offchain infrastructure. Drift's contract code functioned exactly as verified by audits. initializeSpotMarket registered a new market as designed, and updateWithdrawGuardThreshold modified limits as designed. The problem was that the authority to call these functions was compromised, which falls within the domain of operational security, not code auditing.
This mirrors the exact same pattern as the Resolv incident. Resolv also went through multiple audits, but collapsed due to operational security issues: a single-EOA structure for SERVICE_ROLE and the absence of onchain guardrails. The fact that two protocols were exposed to the same type of attack within 10 days suggests this is not an individual protocol's mistake but a structural blind spot across the industry.
5. Implications
5.1 Korean Exchange Response
The ripple effects of this incident extended well beyond the protocol and security infrastructure. A clear pathway through which the attack inflicted secondary damage on retail investors was observed in the Korean market, illustrating just how far the fallout from an operational security failure can spread.
DRIFT is listed on major Korean exchanges including Upbit and Bithumb. Deposits and withdrawals were simultaneously suspended on both approximately two hours after the attack (roughly one hour after it became publicly known). When Korean exchanges halt deposits and withdrawals, arbitrage is cut off, domestic circulating supply forms a closed market, and prices are driven purely by speculative demand, a phenomenon commonly known as "fish farm pumping" (가두리 펌핑).
Source: Upbit
Source: Bithumb
Up until 16:00 UTC on April 1, when the exploit occurred, Bithumb's DRIFT price was around 108 KRW, showing a deviation from the global price of $0.072 that was within normal range. Then at 17:00 UTC, as news of DRIFT's crash to $0.055 on global markets spread, Bithumb's price briefly plunged to 82.98 KRW. Trading volume surged roughly 187x, from 46,778 in the prior hour to 8.75 million. But the trajectory reversed immediately after this dip. At 18:00 UTC, Bithumb's price started at 97.63 KRW and surged to 156 KRW, with volume climbing further to 17.8 million. It hit 169 KRW at 19:00 UTC and peaked at 195 KRW at 20:00 UTC. From the 82.98 KRW low to the 195 KRW high, the price rose 135% in approximately three hours.
During the same window, the global price was continuing to fall, hovering around $0.050. Converting the Bithumb peak of 195 KRW to dollars gives approximately $0.128, a premium of roughly 157% over the global price. Despite an obvious negative event in the form of a hack, the price in the closed market reached more than 2.5x the global price.
This pump began to retrace starting at 21:00 UTC, gradually declining to 172 KRW, 152 KRW, and then 130 KRW. However, as of the time of writing, the Bithumb price remains at 230 KRW, maintaining a premium of approximately 253% relative to global prices. On Upbit, no pumping as extreme as Bithumb's was observed, but during the global selloff window (17:00–20:00 UTC), prices held at the 107–110 KRW range, recording a premium of roughly 44%. Subsequently, at 02:00 KST (17:00 UTC), the price plunged to a 52-week low of 77.4 KRW on volume of 46 million DRIFT, undergoing a delayed correction. It has since resumed its climb alongside the price increase on Bithumb.
As a result, retail investors who bought during the pump likely suffered significant losses unrelated to the hack itself. This is a structural problem repeatedly observed in the Korean crypto market: when deposits and withdrawals are halted, the price discovery function becomes distorted, producing a familiar pattern of additional harm to individual investors.
5.2 Observations on the Attacker
The hypothesis most frequently raised by onchain data and threat intelligence analysis is the involvement of a North Korean-linked hacker group (Lazarus/APT38).
Two main pieces of circumstantial evidence support this hypothesis. First, the meticulous planning and sophistication of the attack, which was systematically staged over more than three weeks from token creation to oracle price manipulation, is consistent with the profile of a state-level actor. Second, the possibility that the admin key compromise was achieved through a software supply chain attack or social engineering aligns with TTPs (tactics, techniques, and procedures) that the Lazarus Group has repeatedly demonstrated in recent large-scale hacks.
That said, there are also indicators that do not fit the hypothesis. The specific money laundering routes deviate somewhat from the patterns seen in previously confirmed Lazarus hacks. In prior Lazarus incidents, there was heavy reliance on specific routes such as fund movement via Tron and conversion to Bitcoin-family chains through THORSwap. In this case, however, more diversified laundering paths through various bridges were observed. The direct use of CCTP, which is censorable by a centralized operator, is notably bold for a Lazarus operation. Whether this reflects an evolution in Lazarus Group tactics or the work of a different actor remains difficult to determine at this point.
Accordingly, it is appropriate to withhold judgment on the attacker's identity for now. Further onchain tracking and threat intelligence analysis will be needed before any definitive conclusions can be drawn.
5.3 Bridge Infrastructure Response Time
The fact that the attacker used Circle's CCTP as a primary laundering channel in this incident is significant. Onchain data shows that a substantial portion of the stolen funds followed the exact path of USDC burn → CCTP → Ethereum re-mint, with Wormhole and Mayan serving as auxiliary routes to rapidly disperse funds across multiple chains. CCTP is Circle's cross-chain transfer protocol, which works by burning USDC on one chain and re-minting it on another. As the issuer of USDC, Circle has the technical authority to freeze specific addresses' USDC or add them to a blacklist.
The issue is the speed at which this authority was exercised. Even though Helius's Mert was observed requesting urgent contact with Circle immediately after detecting the incident, no immediate freeze was placed on CCTP routes in the hours following the attack. During this window, a significant volume of funds was bridged to Ethereum and converted to ETH.
Source: @zachxbt
There is a fundamental tension that must be acknowledged when discussing this issue. The decentralization camp has long criticized Circle's freeze authority itself as a centralization risk and censorship tool. Yet in this incident, Circle is being criticized precisely for not exercising that freeze authority fast enough. This contradiction is not Circle's alone; it is a dilemma the entire industry has yet to resolve. Censorship resistance and the ability to intercept illicit funds are structurally at odds, and there is no consensus on where to strike the balance.
Nevertheless, given that Circle already possesses and has exercised freeze authority, criticism of the speed and criteria of its exercise is legitimate. In a situation where an exploit of this magnitude is unfolding in real time, multiple security firms including PeckShield and Lookonchain are simultaneously sounding alarms, and the Helius CEO is personally requesting emergency contact with Circle, the fact that not even a mechanism to temporarily hold CCTP burn routes within one to two hours was functional exposes a clear limitation of the current system. As onfchain detective ZachXBT has pointed out on multiple occasions, there is a considerable gap between industry expectations and reality when it comes to Circle's emergency response capabilities.
5.4 Structural Redesign of Admin Privilege Management
The Resolv and Drift exploits, occurring 10 days apart, appear identical on the surface but reveal a more uncomfortable truth upon closer inspection. Resolv had core privileges assigned to a single EOA with no multisig in place at all. Drift, on the other hand, managed admin privileges through a Squads V4 multisig. Yet the attack succeeded despite the multisig being present.
The core attack vector exposed by the Drift incident is the combination of durable nonce-based pre-signature collection and social engineering. The attacker tricked legitimate signers into misunderstanding the actual contents of transactions to obtain pre-signatures, stored them indefinitely via durable nonces, and executed them at the time of choosing. Combined with a low 2/5 threshold and a zero-second timelock, the result was a structure where deceiving just two out of five signers instantly handed over the protocol's highest-level authority. Particularly noteworthy is that even after the legitimate multisig migration on March 27, the attacker re-established signer access on the new multisig within just three days. This suggests the attacker had infiltrated not just individual signers, but the team's operational processes themselves.
I see four necessary directions for change.
First, changes to core protocol parameters such as UpdateAdmin and InitializeSpotMarket should require a mandatory timelock of at least 48 hours. In this incident, the timelock was set to zero seconds, which enabled immediate execution of pre-signed transactions. Had a timelock been in place, even with pre-signatures secured, the delay between execution and attack completion would have given the community or monitoring systems a window to detect anomalies and intervene.
Second, an industry-wide shift in awareness regarding the risks of pre-signing via durable nonces is necessary. Durable nonces are a useful mechanism commonly employed in multisig operations, but this incident demonstrated that when combined with social engineering, they can create a lethal environment where signers cannot verify what they are actually signing. A signature verification interface that clearly displays transaction contents in human-readable form, along with a separate confirmation process for transactions involving core privileges, is essential.
Third, DeFi protocols must adopt physical security layers for offchain key management, such as HSMs (Hardware Security Modules) and air-gapped signing. The entry point of the breach in this case is believed to have been social engineering targeting signers, and HSMs can limit the effectiveness of remote social engineering by physically isolating the signing process. However, to defend against a scenario where a signer misunderstands the transaction contents and signs with an HSM anyway, explicit transaction verification procedures must accompany HSM deployment.
Fourth, as I emphasized in my Resolv analysis, continuous security frameworks that go beyond one-off audits are needed. Changes to admin privileges, multisig membership rotations, anomalous market registrations, and sudden withdrawal limit modifications should be immediately detected by real-time monitoring systems, with automatic protocol pauses triggered accordingly. The fact that a sequence of anomalous operations from admin transfer to spot market registration to withdrawal guard neutralization proceeded without a real-time alert being triggered clearly demonstrates the absence of such a framework.
6. Closing Thoughts
Ten days ago, wrapping up my analysis of the Resolv exploit, I wrote that "security architecture should be designed with the goal of minimizing damage when a breach occurs." The Drift incident proved just how urgent that statement is, in the span of merely ten days.
Resolv fell without a multisig; Drift fell despite having one. In both cases, once operational authority was compromised, hundreds of millions of dollars evaporated. This is the weakest link in DeFi security today. As long as the industry's practice remains focused solely on verifying smart contract logic while paying comparatively little attention to the structure and management of the authority that controls that logic, incidents of this type will continue.
I hope this incident is not consumed as just another isolated hack. The message running through both the Resolv and Drift incidents is clear: safe code and a safe protocol are not the same thing, and having a multisig and having secure authority are not the same thing either. And as this incident demonstrates, operational security failures do not stay confined to the protocol itself; they cascade into secondary harm to retail investors through bridge infrastructure response delays and structural issues in exchange markets. Securing a protocol requires a comprehensive security framework that spans every layer beyond the code: key management, multisig and timelock design, emergency response systems, coordination with external infrastructure, and containment of damage propagation pathways. That is the lesson left to us by two major exploits in ten days.
