On April 1, 2026 (UTC), Drift Protocol on Solana was compromised through a coordinated attack combining multisig approval manipulation and durable nonce exploitation, a Solana transaction mechanism that allowed pre-signed approvals to remain valid indefinitely, resulting in an estimated loss of approximately $285.3M [1, 2]. After weeks of on-chain staging, the attacker induced two of five Security Council multisig signers to pre-sign malicious governance transactions through phishing or misleading signing requests. The signed instructions were held until the attacker's chosen moment, then executed in two rapid transactions to complete the admin takeover and transfer administrative control. With full admin privileges, the attacker introduced a malicious collateral asset (CVT), inflated its oracle price, relaxed withdrawal protections, and drained high-value assets through the protocol's lending pathways.
As of the time of writing, Drift has released an initial statement [1] but has not yet published a full post-mortem. The analysis below is based on publicly available on-chain data, Drift's official timeline, and independent research [2]. We first examine how durable nonces fundamentally alter the security assumptions of multisig governance, then reconstruct the multi-week attack staging, the governance takeover execution, and the fund extraction process, and conclude with lessons learned for mitigating this class of risk.
Best Security Auditor for Web3
Validate design, code, and business logic before launch
Background
Drift Protocol and Squads Multisig
Drift Protocol is a DeFi protocol on Solana supporting margin trading, lending, spot markets, and derivatives. Its high-privilege operations, including admin changes, market creation, oracle configuration, risk parameter updates, and withdrawal limit adjustments, are governed by a multisig rather than a single private key.
Drift uses the Squads multisig framework, a common on-chain governance system on Solana. In Squads, privileged actions are packaged as transactions under a proposal. Once enough members approve the proposal, the stored instructions can be executed atomically through vaultTransactionExecute. At the time of the attack, Drift's Security Council operated under a 2-of-5 threshold configuration with zero timelock, meaning any two of five signers could authorize administrative actions with immediate effect. The security of this system depends not only on signer key custody, but also on the integrity of the full approval pipeline: what transaction was created, what signers believed they were approving, and whether the final executed instructions matched that review context.
Durable Nonce Accounts
Durable nonce accounts introduce a critical temporal dimension to transaction execution [3]. Under normal conditions, Solana transactions rely on a recent blockhash and expire quickly after signing if they are not broadcast in time. Durable nonces replace that short-lived blockhash with a nonce stored in a dedicated account, allowing a signed transaction to remain valid indefinitely until the nonce is advanced. This feature is useful for legitimate cases such as offline signing or delayed submission, but it also creates an important attack primitive: it separates when a transaction is signed from when it is executed on-chain. Critically, once a signer approves a durable nonce transaction, they cannot revoke their signature unless the nonce authority manually advances the nonce account.
This separation has a subtle but fundamental impact on multisig security. Under normal blockhash-based transactions, the short expiration window acts as an implicit safety layer: a signer's authorization either gets executed promptly or expires harmlessly. This temporal constraint means that even if a signer is tricked into approving a malicious transaction, the attacker must broadcast it within a narrow window, limiting the scope for coordinated, multi-step exploitation. Durable nonces remove this constraint entirely. With indefinitely valid signatures, the cost of a single signing mistake changes fundamentally: a tricked approval no longer expires within minutes but remains exploitable with no automatic time limit, giving the attacker full control over execution timing and the ability to coordinate follow-up steps at will.
Attack Analysis
The attack unfolded in three distinct phases. In the Pre-Attack Staging phase, the attacker conducted a multi-week operation to manufacture a fake collateral asset and obtain governance access through misleading signing requests. In the Governance Takeover phase, two pre-signed durable nonce transactions were submitted in rapid succession to seize administrative control. In the Fund Extraction phase, the attacker manipulated protocol parameters and drained real assets through the protocol's lending pathways. The diagram below illustrates the attack execution flow across three phases, corresponding to the subsections that follow. The parallel CVT manufacturing track, detailed in Pre-Attack Staging, is not shown in the diagram.
Pre-Attack Staging
The attack was not a single opportunistic strike but a multi-week operation running two parallel preparation tracks. The first track focused on manufacturing a plausible collateral asset. On March 11, the attacker withdrew 10 ETH from Tornado Cash and used the funds to deploy CarbonVote Token (CVT), minting 750 million units. Over the following weeks, the attacker seeded a small amount of liquidity on Raydium and used wash trading to build an artificial price history near $1, giving CVT a surface-level appearance of market legitimacy [4].
The second track targeted governance access. According to Drift's official timeline [1], on March 23, four durable nonce accounts were created: two linked to Drift Security Council multisig members, and two controlled by the attacker. This indicated that at least two of five signers had already signed transactions tied to durable nonce accounts, giving the attacker the required 2-of-5 approval threshold.
On March 27, Drift executed a planned Security Council migration due to a council member change. This migration invalidated the previously collected signatures under the old configuration. However, by March 30, a new durable nonce account appeared tied to a member of the updated multisig, indicating that the attacker had re-obtained the required two-of-five approval threshold under the new configuration.
This sequence reveals that the attacker was actively monitoring on-chain governance changes and adapting in real time. Rather than a single phishing campaign, the signature collection was an ongoing operation that survived a mid-preparation multisig reconfiguration. The migration itself may have inadvertently aided the attacker: during governance transitions, signers are more likely to encounter and approve administrative signing requests, creating a natural social engineering window.
On April 1, the attacker chose a precise execution window. Drift first performed a legitimate test withdrawal from the insurance fund. Approximately one minute later, the attacker submitted the pre-signed attack transactions. This timing suggests the attacker was monitoring on-chain activity in real time and waited for a successful legitimate operation to confirm the system was in a normal operational state before striking.
Governance Takeover
At approximately 16:05 UTC on April 1, the attacker submitted the two pre-signed durable nonce transactions four slots apart. The first transaction (2HvMSg...2C4H) created and approved the malicious admin transfer proposal. The second transaction (4BKBmA...RsN1) approved and executed it, beginning with AdvanceNonceAccount to activate the stored nonce, then proceeding through proposalApprove and vaultTransactionExecute, ultimately invoking UpdateAdmin to transfer administrative control to an attacker-controlled address.
This execution flow highlights a key property of the attack: the decisive authorization did not occur at execution time, but at the earlier signing stage. The on-chain transactions merely materialized permissions that had already been granted.
Fund Extraction
After gaining administrative control, the attacker took three preparatory steps before extracting funds: creating a malicious collateral market for CVT, switching to an attacker-controlled oracle to inflate its price, and relaxing withdrawal protections to enable large-scale extraction.
The first step was to create a malicious collateral market for CVT. The issue with this market was not just that it was new, but that it lacked real liquidity while being assigned overly lenient risk parameters. An asset with no redeemable value, once accepted as high-weight collateral within the protocol, can be used to create non-existent borrowing power.
The second step was to switch to an attacker-controlled oracle and inflate the price. With admin permissions, this step required no further restrictions to bypass. Once the oracle was under the attacker's control, the book price of CVT could be arbitrarily inflated, making an asset with almost no real market value appear as high-value collateral within the protocol.
The third step was to relax withdrawal protections and circuit breakers. Even with inflated collateral pricing, withdrawal limits on major asset markets would have constrained large-scale extraction. These guardrails had to be raised or removed before the fabricated collateral value could be converted into extractable real assets.
Once these steps were completed, the attacker deposited a large amount of overvalued CVT into the protocol, then executed 31 rapid withdrawals over approximately 12 minutes, draining real assets including USDC, JLP, SOL, cbBTC, USDT, wETH, dSOL, WBTC, JTO, and FARTCOIN. This closed the profit-extraction loop: gain governance control, alter parameters, package a worthless asset as high-value collateral, and move funds out along the protocol's pre-existing lending and withdrawal pathways.
As of the time of writing, the total loss is $285,279,417.69, calculated based on the attacker's withdrawal account (HkGz4K...pZES).
Lessons Learned
-
Multisig security extends beyond key custody. Protecting private keys and enforcing signature thresholds is insufficient. The entire authorization pipeline, including transaction construction, display, and signer interpretation, must be trusted. In this incident, the signers' keys were not compromised, but the approval process was manipulated to authorize unintended actions.
-
Timelocks are critical for high-privilege operations. Administrative actions such as ownership transfers should not be immediately executable. Drift's zero timelock configuration meant that once the pre-signed transactions were triggered, administrative control was transferred and exploited within minutes, leaving no opportunity for detection or intervention. A timelock would have created a response window to identify and block the malicious transfer.
-
Delayed execution mechanisms require additional safeguards in governance contexts. Durable nonces decouple signing from execution, removing the implicit temporal guarantees that signers rely on. In governance systems, this class of mechanism should be paired with higher signature thresholds, time-bound or revocable approvals, and restrictions that prevent signed transactions from remaining valid indefinitely.
Conclusion
This incident was not caused by a smart contract vulnerability or key compromise, but by a breakdown in the multisig authorization process combined with durable nonce-based delayed execution. The attacker pre-collected valid multisig approvals from two of five Security Council signers through misleading signing, preserved them using durable nonce transactions, and later executed them to gain administrative control. The subsequent fund extraction was a direct consequence of compromised governance, carried out through otherwise valid protocol operations. Mitigating this class of risk requires securing the full authorization pipeline, enforcing timelocks on high-privilege operations, and implementing additional safeguards for delayed execution mechanisms. Combined with on-chain monitoring systems capable of detecting anomalous governance activity in real time, these measures form a comprehensive security system against this class of governance-layer attacks.
References
[1] DriftProtocol, "Official statement": https://x.com/DriftProtocol/status/2039564437795836039
[2] Phalcon (BlockSec), "Drift Protocol Exploit Analysis": https://x.com/Phalcon_xyz/status/2039602380074016909
[3] Solana, "Introduction to Durable Nonces": https://solana.com/developers/guides/advanced/introduction-to-durable-nonces
[4] CoinDesk, "How Drift attackers drained more than $270 million using a Solana feature designed for convenience": https://www.coindesk.com/tech/2026/04/02/how-a-solana-feature-designed-for-convenience-let-an-attacker-drain-usd270-million-from-drift
About BlockSec
BlockSec is a full-stack blockchain security and crypto compliance provider. We build products and services that help customers to perform code audit (including smart contracts, blockchain and wallets), intercept attacks in real time, analyze incidents, trace illicit funds, and meet AML/CFT obligations, across the full lifecycle of protocols and platforms.
BlockSec has published multiple blockchain security papers in prestigious conferences, reported several zero-day attacks of DeFi applications, blocked multiple hacks to rescue more than 20 million dollars, and secured billions of cryptocurrencies.
-
Official website: https://blocksec.com/
-
Official Twitter account: https://twitter.com/BlockSecTeam
-
π Phalcon Compliance
