Why would the attacker spend time minting an obscure fake Token like CVT instead of just attacking an existing asset directly?
This is precisely what made the attack so sophisticated. Manipulating the price of a deeply liquid asset like SOL or USDC would require enormous capital and would be far more likely to trigger market anomaly monitoring. Creating a brand-new token with no trading history and extremely shallow liquidity, by contrast, only required a few thousand dollars to wash-trade the price to wherever the attacker wanted — because a shallow pool means even small amounts of capital can move the quoted price dramatically.
The real problem isn't that the token's price was fake — it's that Drift's Oracle system allowed a newly listed token with thin liquidity to be treated as valid collateral without any minimum liquidity threshold or time-weighted validation. This is exactly the second structural lesson TRM Labs' report calls out: oracles need defense in depth, not just a snapshot of the current quote.
Durable nonce is a legitimate Solana feature — why did it end up being the attack's key tool?
Durable nonce solves a real, practical problem: ordinary Solana transactions have a very short validity window (expiring within minutes), which is inconvenient for multisig governance that requires coordinating signatures across time zones and departments. Durable nonce lets a transaction be pre-signed and then executed at any point in the future, letting multisig signers complete their signing process in batches.
The feature itself isn't the problem — the problem is that the attacker used social engineering to get signers to sign pre-staged transactions carrying hidden admin authorizations without fully understanding what those transactions actually did. Because durable nonce transactions never expire, the attacker could patiently wait until March 27, when the Security Council threshold was changed and the timelock was removed, before executing all the pre-signed transactions at once. This is exactly why multiple analyses emphasize that the real weakness wasn't the technical mechanism — it was that signers' process for reviewing transaction content wasn't rigorous enough.
Drift changed its Security Council to a 2-of-5 threshold with no timelock just a week before the attack. What was likely behind that decision?
Publicly available information doesn't state exactly why the Drift team made the March 27 change, but based on typical governance design logic, a lower signing threshold (2-of-5) combined with no timelock is usually meant to speed up emergency response — for example, enabling faster decisions and execution during a market anomaly or security incident, without waiting through a lengthy timelock period.
The issue is that this kind of tradeoff — sacrificing buffer time for speed — may be reasonable under normal circumstances, but once the signing process itself is compromised (as it was here, through social engineering), removing the timelock eliminates the one opportunity that might have caught the anomaly. TRM Labs' report lists this as its first structural lesson, essentially reminding protocol teams that a timelock's value isn't in preventing "normal" governance proposals from going wrong — it's in preserving a window to react to the worst-case scenario where the signing process itself has been compromised.
Velocity DEX completed audits from OtterSec and Asymmetric Research and open-sourced its code — does that mean this attack vector has been fully addressed?
Audits and open-sourcing mainly address the question of whether the code logic contains vulnerabilities. That genuinely reduces the chance of a repeat and is an important step in rebuilding trust. But the core weaknesses in this attack weren't in the code at all — the Oracle's validation of the fake CVT Token, the Security Council's threshold and timelock configuration, and signers' process for recognizing social engineering were all governance and operational issues, not the kind of risk a code audit alone can eliminate.
For users, a more practical way to judge this is to check whether Velocity DEX has publicly disclosed its new Security Council governance design after relaunch — whether the threshold has been raised back up, whether a timelock has been reinstated, and whether signers now have concrete improved review processes. Without disclosure of these governance-level details, "passed audit" and "open source" alone aren't enough to conclude the same type of attack can't happen again.
On September 29, 2026, the Solana-based perpetual contracts protocol Drift Protocol relaunched under a new brand, Velocity DEX. On the same day, co-founder Cindy Leow announced she was stepping down, handing the protocol over to a rebuilt team. This wasn't a simple rebrand — five months earlier, on April 1, 2026, Drift suffered an attack by North Korean hackers that drained approximately $285 million, making it the largest DeFi hack of 2026 to date and the second-largest hack in Solana's history, trailing only the roughly $326 million Wormhole bridge exploit in 2022.
According to an official analysis from blockchain intelligence firm TRM Labs, the attack was staged as early as March 11, when the attacker withdrew just 2 ETH from the mixing tool Tornado Cash as seed capital. The core exploit ran along two parallel tracks. First, the attacker created a fake Token called "CarbonVote Token" (CVT), minted 750 million units, and seeded only a few thousand dollars of shallow liquidity on Raydium. By exploiting how the price oracle sourced its data, the attacker wash-traded CVT's on-chain price up to roughly $1, causing Drift's system to treat it as legitimate collateral. Second, between March 23 and 30, the attacker used Solana's "durable nonce" feature — a legitimate mechanism designed to let transactions be pre-signed without expiring — to set up multiple pre-signed accounts, then used social engineering to get Drift's Security Council multisig signers to unknowingly sign transactions carrying hidden admin authorizations. On March 27, Drift migrated its Security Council to a 2-of-5 signing threshold with no accompanying timelock, eliminating the detection-and-response window that might otherwise have caught the anomaly. On April 1, those pre-signed transactions executed: CVT was listed as valid collateral, withdrawal limits were raised, and 31 withdrawal transactions drained assets including USDC and JLP in roughly 12 minutes, totaling about $285 million. The DRIFT token fell more than 40% in response, and most of the stolen funds were bridged to Ethereum within hours.
Rather than simply restoring the existing system, the Drift team spent nearly five months rebuilding. According to reporting from KuCoin and ChainCatcher, before Velocity DEX relaunched on September 29, it completed independent audits from two separate firms, OtterSec and Asymmetric Research, and open-sourced its codebase. The product's scope was also narrowed, refocusing solely on perpetual contracts rather than operating multiple product lines as before. Solana's broader DeFi total value locked saw a double-digit percentage decline after the attack and has since recovered to above $6.5 billion. Cindy Leow announced her departure on the same day the rebrand launched, handing operations to the rebuilt team — a timing coincidence widely interpreted as directly tied to accountability and restructuring following the April incident, rather than an unrelated personal career decision.
TRM Labs' report identifies three structural lessons. First, timelocks on governance and admin actions aren't optional decoration — Drift's decision to remove its timelock before the attack directly eliminated the buffer period that might otherwise have allowed the anomaly to be caught and stopped. Second, Oracle design needs defense in depth: minimum liquidity thresholds, time-weighted price validation, and circuit breakers before accepting any new asset as collateral — a single shallow-pool price quote should never be trusted directly by the system. Third, multisig signer discipline matters just as much: signers need verification processes that are independent of whatever social engineering narrative they're presented with, especially for transactions touching admin permissions, and should never sign based solely on another party's account of what a transaction does.
If you've used or are currently using a Perpetual DEX, this incident is a reminder that whether a protocol has been hacked matters just as much as how it was hacked. Not a single line of Drift's Smart Contract code was broken in this attack — the entire incident ran through gaps in governance architecture and human signing processes. Next time you evaluate a protocol, beyond checking whether it's been audited, it's worth asking: are admin permission changes paired with a timelock? Is the multisig signer verification process disclosed publicly? Does the Price Oracle rely on a single source or shallow-pool pricing that could be manipulated?