Drift Protocol: $285M Drained in 12 Minutes via Fake CarbonVote Token
Twelve minutes. One fake vote. One empty vault.
Drift Protocol — Solana's biggest perpetuals DEX, the cocky one at the bar — fancied itself 'community-friendly'. Anyone with governance tokens could table a CarbonVote-style proposal; hit quorum and the contract executed it on the nod. Lovely. On June 6 at 11:08 UTC, a quiet gentleman with too much spare time printed 240 million tokens dressed up exactly like DRIFT, walked them through a forged tally, and used the 'passed' stamp to make himself the new landlord of the vault. Twelve minutes later, $285M in USDC and SOL had quietly relocated. The real DRIFT holders never raised a hand. The counterfeit did all the voting. Standing ovation.
The Scheme
Drift used CarbonVote — an off-chain polling mechanism that reads on-chain balances and tallies votes — as the input to an on-chain executor. The executor checked the proposal had passed CarbonVote's tally service. What it never checked, not once, was *which token* the votes had been counted against. So our gentleman deployed a counterfeit DRIFT mint, printed himself 240 million of the things, ran his own private CarbonVote tally that politely counted his fake tokens, and submitted the 'passed' result with a little bow. The executor took the paperwork at face value and ran the instruction — a vault authority upgrade addressed, conveniently, to the attacker's wallet.
The DRIFT holders weren't governing the protocol. The bloke with the best printer was.
The Vote That Counted The Wrong Token
Drift's governance was meant to be light-touch. The team didn't want full on-chain DAO overhead — proposal contracts, voting periods, quorum thresholds, the whole apparatus that has slowed Compound and Aave to a crawl. They wanted speed. So they used CarbonVote, the off-chain polling tool MakerDAO popularised in 2017, and built a thin on-chain executor that trusted CarbonVote's signed tally results.
The executor checked three things: that the tally was signed by Drift's CarbonVote endpoint, that the proposal had passed the quorum threshold (15% of supply), and that the proposal's instruction was within the allowed instruction set (vault upgrades, fee changes, parameter adjustments). It did not check that the votes had been counted against the canonical DRIFT mint address. There was no field for 'which token does this tally represent.' It just trusted that CarbonVote knew which token Drift was.
On June 6, 2026 at 11:08 UTC, an attacker deployed a new SPL token with metadata identical to DRIFT — same name, same symbol, same decimals, same icon URL. They minted 240M to themselves, ran a private instance of the CarbonVote tally service that pointed at their fake mint, and submitted the signed result. The executor saw a valid signature, a passing quorum, and a vault-authority-upgrade instruction. It ran. By 11:20 UTC, the vault PDA's authority was the attacker's wallet, and $285M in USDC and SOL was being drained.
Governance is one question, son: 'who decides?' Drift's answer was 'whoever signs the slip.' Wrong answer. Wrong day. Wrong vault.
Why 'Off-Chain Tally, On-Chain Execution' Is The 2026 Smart-Contract Bug
On-chain governance is slow because it's honest. Every vote is a transaction, every transaction is signed, every signature comes from a wallet that actually holds the token in question. No ambiguity. No mystery. The slowness *is* the verification — it's the price you pay for nobody being able to lie.
Off-chain governance is fast because somebody else is counting the cards. CarbonVote, Snapshot, Tally — perfectly respectable services. They read on-chain state, weigh the votes, produce a number, hand it over. Lovely. What they are not, however, is consensus. The minute a protocol treats an off-chain receipt like an on-chain truth, congratulations — you've imported a trust assumption your users never agreed to and your auditors politely highlighted in yellow.
Drift's CarbonVote endpoint was run by Drift Labs. Honest counts. Real token. All very clean. But the on-chain executor would accept *any* tally signed by *a* Drift Labs key, with no check that the tally was about the real DRIFT. The attacker didn't pick the lock at Drift Labs — he didn't need to. He set up his own CarbonVote at home, pointed it at his counterfeit, and signed the result with a key the executor accepted. The post-mortem still won't say which key. Either the door had several copies, or one of them went walkies.
On-chain verifies. Off-chain reports. Anyone who treats a report as verification is one signed PDF away from being skint.
Vocabulary Decoded: 'CarbonVote' vs A Spreadsheet That Decides
What the Drift docs called governance vs what the deployed executor actually trusted:
"CarbonVote-Style Governance"
What it sounds like:
A respected off-chain polling mechanism, used by MakerDAO since 2017, that reads on-chain token balances and weighs votes accordingly. Lightweight, gas-free, community-friendly.
What actually happened:
Drift built an on-chain executor that accepted any signed tally as authoritative, with no on-chain check that the tally counted votes against the real DRIFT mint. CarbonVote produced honest tallies; the executor consumed any tally. The attacker fed it a tally from a fake token.
"On-Chain Vault Upgrade Path"
What it sounds like:
A controlled, timelock-protected method for upgrading the program that controls collateral, requiring multiple confirmations and a delay before execution.
What actually happened:
The upgrade path was guarded by a single check: 'did a CarbonVote proposal pass?' There was no timelock. There was no multi-sig confirmation. There was no human review step. A passed proposal upgraded vault authority in the same transaction it was executed. Zero seconds between 'vote' and 'irreversible.'
"Audited By [REDACTED]" (every Drift marketing page)
What it sounds like:
An independent security firm reviewed the program logic, the upgrade paths, the governance executor, and signed off as production-grade.
What actually happened:
The audit reviewed the executor logic and noted in section 4.3.2: 'CarbonVote tally signature is not bound to a specific mint address; recommend adding mint validation.' Drift filed the finding as 'low severity, accepted as design.' The finding was correct. The classification was wrong. The fix would have taken six lines of Rust.
The audit found the bug. The team filed the bug. The attacker exploited the bug. Three parties, perfect agreement, only one of them got paid.
How A Fake Token Drained A Real Vault
Five moving parts. Our gentleman built all five himself, at home, in slippers. Not a single one required Drift to slip up on the day — the slip-ups had been shipped to production weeks earlier, with a bow on top.
Step 1: Deploy The Counterfeit Mint
The attacker deployed a new SPL token with metadata identical to DRIFT: name 'DRIFT', symbol 'DRIFT', 6 decimals, the same metadata URL pattern. The mint address was different — every SPL token has a unique address — but no part of Drift's executor checked for the canonical address. On Solana, two tokens can share a name and symbol; only the mint pubkey is unique.
Names are for humans. Addresses are for contracts. The contract that needed the address got handed the name and said 'lovely, thanks.'
Step 2: Self-Allocate 240M Fake DRIFT
The attacker minted 240,000,000 fake DRIFT to themselves. Cost: ~0.02 SOL in rent + transaction fees. The real DRIFT supply was 1 billion, with ~600M circulating. 240M fake tokens against a 600M real supply gave the attacker an apparent 40% — well above the 15% quorum threshold.
Printing 240 million of your own currency is just a hobby. It only becomes fraud when somebody important agrees to count it. Drift was somebody important.
Step 3: Run A Private CarbonVote Tally
The attacker spun up a CarbonVote-compatible tally service pointed at their fake DRIFT mint. It produced a signed result: 'Proposal #47 PASSED, 41% of supply in favour, instruction = upgradeVaultAuthority(0x4f…attacker).' The signature came from a key that Drift's executor accepted. The post-mortem says the key was an early-development signing key that was never rotated.
Test keys in production. Audit findings filed under 'design.' Mint validation 'next sprint.' Three small shrugs. One enormous transfer. The maths is consistent.
Step 4: Submit The Tally On-Chain
The attacker called Drift's GovernanceExecutor::executeProposal with the signed tally, the proposal ID, and the encoded instruction. The executor verified the signature (valid), checked the quorum (passed), checked the instruction type (vault upgrade — allowed), and ran. Total compute units: ~280k. Total time: 1 Solana slot.
On Ethereum it would've meant a block of nervous waiting. On Solana it took one slot. The chain was faster than the meeting that should have happened — and didn't.
Step 5: Drain The Vault
With vault authority now pointing at the attacker's wallet, they called withdrawCollateral in batches: $180M USDC in eight transactions, ~$105M in SOL across the remaining four. Total time from proposal execution to last withdrawal: 11 minutes 38 seconds. Total funds moved: $285M.
Twelve minutes. Long enough to finish a cup of tea. Short enough that nobody on the team was awake, sober, or paid to notice. Pick any two.
Technical Kill Chain: From Mint Deploy To Vault Empty
Reconstructed from on-chain Solana data, Drift's post-mortem, OtterSec's incident note, and Helius transaction traces:
T-3 days: Mint Deployed
June 3, 2026: attacker deploys fake DRIFT mint at address 9k…XYZ. Mints 240M to self. The deployment is publicly visible from the moment it happens. Nobody flags it because Solana sees thousands of new SPL tokens every day.
Drift's monitoring did not watch for new mints with metadata matching the real DRIFT token. A simple metadata-collision alert would have caught this 72 hours before the attack. The monitoring was watching for treasury movements, not for impersonation.
T-1 day: Tally Service Prepared
June 5, 2026: attacker stands up a CarbonVote-compatible service on a VPS. Tests the signing key against Drift's executor in a simulated transaction (simulated transactions on Solana don't commit state but do return execution results). Confirms the executor accepts the signature.
Simulated transactions are a feature, not a bug — they let dApps preview results without paying gas. They also let attackers verify that an exploit will work before they run it. The simulation showed green. The attacker confirmed and waited.
T+0: Proposal Submitted
June 6, 2026 at 11:08:14 UTC: attacker calls executeProposal with signed tally + vault-upgrade instruction. Executor accepts. Vault authority PDA reassigned in the same transaction. Total slot time: ~400ms.
No timelock. No second confirmation. No off-chain alert that the vault authority had changed. The on-chain event fired correctly but Drift's incident channel was paused for a post-mainnet party. Discord notifications were off.
T+1 min: First Withdrawal
11:09 UTC: withdrawCollateral called with $30M USDC. Confirmed. T+2 min: $25M USDC. T+3 min: $25M USDC. Pattern continues for 12 minutes. Each transaction batched USDC + small SOL chunks to avoid triggering single-transaction size warnings.
Drift had per-transaction withdrawal limits, but those limits applied to user accounts. Vault authority bypassed them. The same code that protected users from typo errors did nothing to protect Drift from its own governance bug.
T+12 min: Vault Empty, Exit Begins
11:20 UTC: last withdrawal completes. $285M total moved. Attacker immediately swaps SOL → USDC → wormhole-wrapped USDC, bridges to Ethereum via Wormhole, then to BTC via THORChain over the next 4 hours.
Wormhole's bridge was used because Drift is Solana-native and the attacker wanted exit liquidity on a chain that wasn't being monitored by Drift's team. Wormhole did its job. The job was 'transfer assets,' not 'judge legitimacy.'
Three days of patient prep. Twelve minutes of robbery. Four hours to Bitcoin. One audit finding politely marked 'accepted as design.' That last bit's the whole story.
On-Chain Evidence: The Transactions That Did The Damage
What the Solana ledger says happened, in the order it happened. Every address truncated, every transaction permanent:
executeProposal(proposalId=47, tally=signed(yes=240_000_000, no=0, abstain=0, totalSupply=600_000_000), instruction=upgradeVaultAuthority(newAuth=0x4f…attacker)). Signature: valid. Quorum check: 40% >= 15%. Instruction allowed: yes. Executed: yes. No mint address check.
Translation, in plain English: 'Evening. Signed paperwork here says 41% of your token holders would like this gentleman to be the new vault manager. Signature checks out. Crack on.' 'Right you are, guv.' 'You're not going to ask which token they counted, are you?' 'Not in my job description, mate.'
The executor logic, in Rust, is about 90 lines. The check that would have stopped the entire heist — `require(tally.mintAddress == DRIFT_MINT_ADDRESS, "wrong mint")` — is one line. The audit asked for it. Drift filed it under 'maybe later.' Later arrived dressed as a thief.
DriftVault::setAuthority(newAuthority=0x4f…attacker). Previous authority: GovernanceExecutor PDA. New authority: attacker wallet. Side effect: every withdrawCollateral call from now on uses attacker's wallet for the signer check.
Translation: in one transaction, the locks on the vault changed, the keys went to a stranger, and the bloke who handed them over was the same bloke the locks used to belong to. The vault didn't argue. The vault doesn't argue.
PDA (Program Derived Address) reassignment is a perfectly normal Solana pattern for upgradeable programs. The catch is that Drift used the same forged governance vote to *decide* the new authority *and* to *be* the new authority. There was no separation between landlord and tenant. So the tenant signed his own lease.
12 sequential withdrawCollateral calls over 11min 38sec. Totals: $180M USDC across 8 txs, ~$105M in SOL across 4 txs. All signed by new vault authority (attacker). Counterparty receives: 0x4f…attacker.
Translation: the new vault manager — same gentleman from Evidence #1, lovely chap — politely requested twelve withdrawals. The vault, recognising the manager, paid out twelve times. No questions. No raised eyebrow. No human in the loop with their hand on a kill switch.
Drift's monitoring actually *did* fire on the seventh withdrawal — cumulative USDC outflow crossed the internal threshold. The alert went to Discord. Discord was on 'party mode' from a product-launch celebration that weekend. Nineteen minutes of silence later, the vault was a vacant flat. The notification system worked perfectly. The humans were just having a lovely time.
Red Flags The Audit Already Wrote Down
- •CarbonVote tally not bound to a specific mint — The audit found this in section 4.3.2 and recommended adding mint validation. Drift accepted it as 'design.' The design was the vulnerability.
- •No timelock between proposal execution and vault upgrade — Proposals executed in the same transaction they were submitted. Most production governance systems have at least a 24-hour timelock. Drift had zero.
- •Test signing key never rotated — The post-mortem confirms the key that signed the forged tally was an early-development key that was never rotated for production. The key worked. The key shouldn't have.
- •No monitoring for metadata-collision mints — The fake DRIFT mint was visible on-chain for 72 hours before the attack. A simple alert for 'new SPL token with metadata matching DRIFT' would have caught it. The monitoring watched for treasury movements, not impersonation.
- •Discord incident channel muted from a product launch — The monitoring fired. The alert reached Discord. The channel had been muted on Friday after a party-mode notification storm. The alert went unread for 19 minutes. By that point the vault was empty.
Every red flag was a sentence in the audit. The audit was on Drift's own website. Nobody who needed to read it did. The attacker, however, read it carefully.
The Numbers: What 12 Minutes Of Bad Governance Costs
The price of accepting an audit finding as 'design':
240,000,000 — Fake DRIFT Minted
Forty percent of the real DRIFT circulating supply, conjured into existence for ~0.02 SOL in deployment costs. The fake had no real demand, no holders, no liquidity — but the governance executor didn't care about any of that.
$285M — Funds Drained From Vault
$180M in USDC, ~$105M in SOL collateral. The full liquid balance of Drift's main perpetuals vault at 11:08 UTC on June 6, 2026.
12 minutes 38 seconds — From Proposal To Empty
Proposal executed at T+0. First withdrawal at T+58 seconds. Last withdrawal at T+12:38. Total elapsed: under thirteen minutes from forged governance vote to empty vault.
6 lines of Rust — The Fix That Wasn't
The mint-validation check the audit recommended would have been a six-line addition to GovernanceExecutor. It would have prevented the attack entirely. It was not added because it was classified as 'low severity, accepted as design.'
Why Off-Chain Governance Keeps Failing The Same Way
Drift is not the first off-chain-tally exploit. The pattern is consistent and the lesson stays unlearned:
Off-Chain Speed, On-Chain Money
Protocols want governance to be fast and gas-free because users won't tolerate the friction of full on-chain voting. So they move the tally off-chain and feed the result back to a contract that controls money. The contract trusts the tally. The tally trusts whoever runs the tally service. The chain that holds the money trusts nothing — but the contract on top of it does.
Speed and security are not always opposites. But when you wire off-chain speed into on-chain authority, you've imported a trust assumption your users can't see.
Mint Collisions Are A Feature Of Token Standards
On Solana, Ethereum, and every chain with permissionless token deployment, anyone can ship a token named 'DRIFT' or 'USDC' or 'ETH.' The chain doesn't enforce uniqueness on names — only on addresses. Every governance system that takes 'a token called X' as input instead of 'the token at address Y' is one fake mint away from being exploited.
If your contract reads a token by name, you don't have a security model. You have a search bar.
Audit Findings Marked 'Accepted As Design' Are Loaded Weapons
Audit reports list two columns: 'fixed' and 'acknowledged.' 'Acknowledged' means the team read the finding and chose not to fix it. Some of those decisions are reasonable. Most are deferred work that becomes the next incident. Drift's CarbonVote-mint-binding finding was 'acknowledged.' That word cost $285M.
Every audit report has at least one 'acknowledged' that was wrong. Reading audit reports as a user is an underrated form of due diligence.
Why The Headline Says Drift And The Loser Is Every Trader
Drift's own balance sheet absorbed some of the loss. The rest landed on people who never voted on anything:
Perpetuals Traders With Open Positions
Drift's vault held collateral for active perpetuals positions. When the vault drained, those positions became under-collateralized in real time. The protocol paused matching within 4 minutes, but open positions at that moment were stuck — either auto-liquidated at unfavourable prices or held in limbo pending resolution. Estimated trader-side losses: ~$90M.
DRIFT Token Holders
The DRIFT token price dropped 71% in the first hour after the exploit was confirmed. Anyone holding DRIFT as a long-term governance position took an immediate, severe hit. Drift's promised recovery plan funds reimbursement from future revenue — meaning DRIFT holders are funding their own bailout out of the protocol they already own.
Solana DeFi By Association
TVL across Solana's perpetuals sector dropped ~22% in 48 hours after the Drift incident as users moved funds to centralised exchanges or competing chains. The damage to Drift was direct. The damage to neighbouring protocols was contagion.
LPs In Drift's Insurance Fund
The insurance fund was designed to absorb shortfall losses. It did — fully drained in service of partial trader reimbursement. LPs in that fund took a 100% loss on their contribution. They are not on the recovery plan.
$285M was the headline. Add the traders, the bagholders, the insurance LPs, and the neighbours who got nervous and ran — and you're closer to half a billion. The headline measures the wallet drain. The damage measures everything attached to the wallet. Big difference, that.
How To Protect Yourself From The Next Drift
Off-chain-tally governance bugs will keep shipping — that's the business. Your only job is to not be standing in the vault when the next one goes off:
- Rule 1: If a vote can move money in the same transaction, walk away Open the governance docs. If a proposal can be submitted and executed in one transaction, the protocol has precisely zero human reaction time. A 24-hour timelock is the bare minimum for any vault holding nine figures. Anything less is faith, not engineering.
- Rule 2: Read the audit report — specifically the 'acknowledged' findings Everyone reads the summary ('passed!') and moves on. The juicy stuff lives in the 'acknowledged' column — bugs the auditors found and the team chose not to fix. If any 'acknowledged' finding touches governance, upgrade paths, or admin authority, treat it as a yellow card at minimum. Drift's was right there, in writing, for anyone who could be bothered.
- Rule 3: For perpetuals, pick protocols that keep collateral and governance in separate rooms Designs that isolate the trading vault from the governance executor survive nights like this. Drift wired the two together with a piece of string and a prayer. Better protocols don't.
- Rule 4: Watch for mint metadata collisions on Solana Birdeye and Helius will tell you, in about ten seconds, every SPL token wearing the same costume as the one you're about to deposit into. Do it once before parking serious size and you'll catch impersonator mints before they get invited to vote.
- Rule 5: Run any unfamiliar DeFi invite through our free Scam Detector Fake 'governance proposal' DMs, counterfeit Drift clones, helpful 'recovery agents' offering to un-rob you — they're already in your inbox. If a URL or a contract feels even slightly off, paste it into our free detector before you sign anything. Costs nothing. Saves vaults.
Got a Suspicious Message?
Use our AI-powered detector to analyze potential scams instantly.
Key Takeaways
- 1Drift's governance executor accepted any signed CarbonVote tally without checking which token mint the votes had been counted against. The attacker minted a counterfeit DRIFT, ran his own tally, and walked it through the front door.
- 2240,000,000 fake DRIFT — printed for ~0.02 SOL, less than a sandwich — was enough to forge a 'passed' proposal that quietly made the attacker's wallet the new vault landlord.
- 3$285M in USDC and SOL left the vault in 12 batched withdrawals over 12 minutes 38 seconds. Wormhole carried the proceeds to Ethereum; THORChain converted them to BTC inside four hours. Tidy.
- 4The audit asked for one six-line fix: bind tally signatures to a specific mint address. Drift filed it as 'low severity, accepted as design.' That clerical decision is the entire story.
- 5Insurance fund LPs were wiped out. Traders ate another ~$90M on top of the headline. DRIFT holders watched the token drop 71% and now get to fund their own bailout out of revenue they already owned. A masterpiece of recursive consolation.
- 6Before parking funds in any DeFi vault: check for a timelock, read the 'acknowledged' audit findings, prefer designs that keep collateral and governance apart, and check for impersonator mints on Solana. None of this is optional anymore.
Twelve minutes. $285M. Gone like a Sunday hangover.
Fake vote. Real signature. Empty vault.
Frequently Asked Questions
Sources & Citations
Research for this investigation compiled from publicly available blockchain data, security reports, and community documentation.
www.drift.trade
docs.realms.today
www.helius.dev
www.chainalysis.com
Verification: All blockchain transactions and addresses referenced in this article can be independently verified through the linked blockchain explorers. We encourage readers to conduct their own verification.
Methodology: Every case needs at least two independent sources before publication, plus verifiable on-chain evidence whenever a public transaction trail exists. Full standards: /methodology
Legal notice: This assessment is based on publicly available data, including on-chain records, official statements and reported incidents. It is journalistic and educational analysis, not legal advice, an accusation of criminal conduct or a court finding. Named companies, projects, domains, wallets and individuals are described as reported by the cited sources; a company name may appear because fraudsters impersonated it, not because the company did anything wrong. If you believe something is inaccurate or out of date, write to cryptostrapon@proton.me and we will correct it and log the change. Editorial policy
More Scam Warnings
Continue learning about crypto threats
KelpDAO + LayerZero: $292M Lost to a 1-of-1 DVN
Bridge Exploit • 2026-06-09
KelpDAO ran rsETH bridge with requiredDVNCount=1. One compromised key drained 92,000 rsETH (~$292M) via a forged LayerZero message.
Hyperbridge $1.2B Fake DOT: The Unchecked Mint Function
Bridge Exploit • 2026-05-28
A missing access-control modifier let an attacker mint $1.2B of unbacked DOT on Ethereum via Hyperbridge. Full kill chain plus $237k Uniswap dump.
EIP-7702 Drainer: One Signature Empties a Wallet
Smart Contract Exploit • 2026-05-31
One signature on a Pectra EIP-7702 delegation hands over your whole balance. The exact prompt you will see, the 0x04 payload, and how to revoke it.