Drift Victims Committee

1/ Every day @DriftProtocol stays silent, the on-chain evidence speaks louder against them. We aren't here for PR bedtime stories. No more hiding. Time to answer questions 👇 @Solana #DriftProtocol #DeFi #Exploit

@goldenhotplasma @Trader_CSK 😀 notice how drift hasn't said a word about this?

@DriftVictims @Trader_CSK We dont need a POC. We get it a master key that can override everything.

After reading the comments I can see more clarity is needed. I have looked further into Drift's governance history and there's a lot more to this than stated in the original post Before I get into it, here's a timeline tldr March 23 - Drift signers nonce accounts created (per Drift's post mortem) March 24 - Attacker funded, created own Squads V4 multisig at 5RTeGGEhb6pZ85kWeaK6hDoXy837aGBPeTrbjRDcLCp3, ran the create/propose/approve sequence March 25 - Drift creates new multisigs 2LW6PS (2/5) and BBC5g (3/5) March 26 - Drift V2 State admin transferred from 61ApQqLoW to 2LW6PS March 29 - Program upgrade authority for 7 Drift programs (including Drift V2) transferred from Er82vnft to BBC5g. 2LW6PS still held the Drift V2 State admin role from March 26 March 31 - Attacker's second key provides the second approval on their own multisig, completing the 2/2 threshold. Less than 24 hours before the real attack April 1 - 6UJbu9ut5V (compromised signer) receives 0.01 SOL from a wallet linked to the named attacker addresses, a few minutes before the exploit April 1 - Drift's legitimate test withdrawal from insurance fund April 1 - Exploit fires, two transactions one second apart, Drift V2 State admin transferred to attacker April 2 - Recovery, Drift V2 upgrade authority moved from BBC5g to new multisig E44y4Gm The details I identified 6 Drift admin multisigs, all owned by the Squads V4 program, all with the same external configAuthority - 61ApQqLoW... created at 3/5 threshold on April 21 2024 - Er82vnft... created at 3/5 threshold on April 21 2024, same day as 61ApQqLoW - GMNVGNk8... created at 3/5 threshold on May 2 2024, same 5 members as 61ApQqLoW - BBC5g... created at 3/5 threshold on March 25 2026, currently controls upgrade authority for 6 Drift programs (Vaults, Stake Voter, Competitions, JIT Proxy, Oracle Receiver, Merkle Distributor airdrop) - 2LW6PS... created at 2/5 threshold on March 25 2026, this is the multisig that was actually exploited - E44y4Gm... created at 3/5 threshold on April 2 2026, current Drift Protocol V2 upgrade authority There are two separate admin roles. State admin and upgrade authority. State admin is a field on the Drift program's state account. Whoever holds it can call admin only instructions like removing withdrawal limits or transferring admin to someone else. Upgrade authority is a different role, it controls who can upload new program code. Different multisigs can hold different roles. Both can drain a protocol, just in different ways. The April 1 exploit went through the State admin path On the threshold history. Both 61ApQqLoW and Er82vnft were created at threshold 3/5 on April 21 2024. On April 29 2024, both had their thresholds changed to 2/5 - 61ApQqLoW stayed at 2/5 from then on, all the way to the exploit - Er82vnft was bumped back to 3/5 on May 2 2024 and has been there since. Still on chain at 3/5 today, last active March 29 2026 The external configAuthority was set on 61ApQqLoW and Er82vnft on May 13 2024. After that, no further config changes happened on either until the migration in March 2026 Drift's old setup ran one group of five signers across three multisigs in parallel - 61ApQqLoW at 2/5 - Er82vnft at 3/5 - GMNVGNk8 at 3/5 2LW6PS became State admin for Drift Protocol V2 (Perps). BBC5g became the upgrade authority for Drift Vaults and 5 other Drift programs Both 2LW6PS and BBC5g were created on the same day, March 25 2026 Both new multisigs are identical except for threshold. They shared - Five signer addresses - Same configAuthority - Zero timelock - Almighty permissions on every member 2LW6PS and BBC5g shared the same five signers. A third compromised key would have made BBC5g reachable too. The attacker had two, enough to meet 2/5 on 2LW6PS but not 3/5 on BBC5g, so BBC5g was untouched For comparison, Jupiter runs Jupiter Perps and Jupiter Lend on separate Squads V4 multisigs with zero signer address overlap between them. Same organisation, different product domains. Jupiter Perps has a 24 hour timelock and Jupiter Lend has a 12 hour timelock. 2LW6PS and BBC5g both had zero The same configAuthority is still set on all 6 of these multisigs, including the recovery one. This is what Squads calls a Controlled Multisig setup. The configAuthority is a single private key wallet, system owned, no program code. It has never signed a transaction in nearly two years This could be intentional. An emergency recovery key held offline is one explanation. I'm unable to find Drift's reasoning. Either way, Squads own documentation states this setup is not recommended for most use cases and tells operators to understand the trade offs of having an active Config Authority before choosing it Whoever holds that key can change threshold, members, or timelock on any of the attached multisigs at any time without a vote, including the new recovery multisig E44y4Gm The Controlled Multisig setup also blocks the standard members vote on config change flow. After the exploit, attempts to push config changes through 2LW6PS via the standard proposal path failed because the program rejected them. On a Controlled Multisig, config changes have to go through the configAuthority What the configAuthority can do at any time, on its own, no vote required - Lower any Drift multisig's threshold to 1 - Add a new member - Execute through whatever those multisigs control BBC5g controls 6 Drift programs. E44y4Gm controls Drift Protocol V2. Whoever holds the configAuthority key has the standing ability to take over the whole Drift program suite. The April 1 exploit didn't use this path, so the attacker didn't control it. The path is still live today The signer set on 2LW6PS was a near complete rotation from the old group. Of the five signers on 2LW6PS, only 39JyWrdb carried over. The other four were new members. The Drift Protocol V2 State admin moved from 61ApQqLoW to 2LW6PS on March 26. Both were at 2/5 threshold so the threshold did not change in the handover. 61ApQqLoW had been at 2/5 since April 29 2024 Of the 6 Drift multisigs documented here, 2LW6PS was the only one created at 2/5 from the start. The others were all created at 3/5 The migration was multi stage. Three days after the State admin transfer, on March 29, upgrade authority for 7 Drift programs was transferred from Er82vnft to BBC5g in two batches. Six of those seven were Drift V2 era programs (Vaults, JIT Proxy, Oracle Receiver, Stake Voter, Competitions, Merkle Distributor) and the seventh was Drift Protocol V2 itself (moved on to E44y4Gm on April 2 during recovery). Er82vnft still holds the upgrade authority for one more program today, the deprecated Drift V1 (Dynamic AMM, the predecessor to V2 that was wound down in 2025) Per Drift's post mortem, durable nonce accounts associated with old group members 39JyWrdb and 45cZ5Fj97 had been created on March 23, two days before the new multisigs. The rotation dropped 45cZ5Fj97 and retained 39JyWrdb. A durable nonce account for 6UJbu9ut5V was also created on March 30. The two compromised signers used in the April 1 exploit were 39JyWrdb (the retained one) and 6UJbu9ut5V (one of the four new members) On March 24, the day before Drift created the new multisigs, CZRBcHAv (one of the attacker addresses Drift later named) created their own Squads V4 multisig (5RTeGGEhb6pZ85kWeaK6hDoXy837aGBPeTrbjRDcLCp3). The multisig was set to 2/2 with both Drift named attacker addresses as members, CZRBcHAv and 48cV6Mw5Y. Three minutes after creating it they ran the full create, propose, and approve sequence (VaultTransactionCreate, ProposalCreate, ProposalApprove). Nine minutes after that, they ran the same sequence again The proposals sat pending for a week. On March 31, less than 24 hours before the real attack, 48cV6Mw5Y came back and provided the second approval, completing the 2/2 threshold. Same instruction pattern as the exploit the next day On cold wallets. Drift said all signers are cold wallets. I scanned all 11 unique signers across these multisigs. 10 of 11 had no DeFi or marketplace activity in recent transactions. One had a single TITAN swap The actual exploit was two transactions, one second apart - Tx 1 created the malicious admin transfer and added the first approve (1 signature) - Tx 2 bundled the second approve and the execute call into one transaction (2nd signature + execute combined) - Execute called UpdateAdmin on Drift Protocol V2, changing the admin to an attacker controlled address The compromised signer 6UJbu9ut5V was also topped up with 0.01 SOL minutes before the attack, likely gas for the approve transaction Both were pre signed using durable nonces. Per Drift's own post mortem, a legitimate test withdrawal from the insurance fund happened about a minute before the attack. The pre signed transactions fired immediately after Three things made the 1 second execution possible. Take any one of them away and the attack stops or slows down - A meaningful timelock would have created a queued admin change visible on chain. The attack executed in 1 second with no delay. Jupiter Perps runs 24 hour, Jupiter Lend 12 hour - Without active durable nonce accounts, signatures expire in under 2 minutes. The attacker would have had to coordinate signatures in real time instead of firing pre signed ones whenever - Higher threshold means more signers to compromise before any of this is possible After the admin transfer, the exploiter drained user collateral and the funds were bridged to Ethereum using Circle's CCTP Drift named four Ethereum wallets holding the bridged funds: 0xAa843eD65C1f061F111B5289169731351c5e57C1, 0xD3FEEd5DA83D8e8c449d6CB96ff1eb06ED1cF6C7, 0xbDdAE987FEe930910fCC5aa403D5688fB440561B, 0x0FE3b6908318B1F630daa5B31B49a15fC5F6B674 ZachXBT counted 232M+ USDC bridged across 100+ transactions over 6 hours. Elliptic attributed the attacker to DPRK. Drift's own forensics with SEAL 911 came back with medium high confidence pointing to UNC4736, the same group behind the October 2024 Radiant Capital hack Drift has since announced a new community multisig for relaunch with timelocks, disabled durable nonces, dedicated signing devices, independent transaction verification, need to know signer identities, and real time alerts for anomalous proposals. The configAuthority wasn't in the announcement and I'm not sure if Drift has addressed it publicly elsewhere. There's likely a reason for the setup that only Drift can speak to. Either way, by Squads own documentation the Controlled Multisig pattern carries risk. Who holds it and what the plan is are fair questions but ones only Drift can answer If you come across any other supporting data, that's welcomed and would be helpful. Hoping to reverse engineer all of this to see what other patterns exist and do my part to help reduce the chances of this happening to others

@Cyborg_Hawk69 @DriftProtocol @tether 💯

@DriftProtocol @tether 3/X The second problem is, this kind of recovery only helps those who were directly affected by the hack, while the "believers", who insisted to HODL throughout the hack dump stay in loss.

Today, Drift is announcing a collaboration with @tether and other partners totaling up to nearly $150 million to support our commitment to a relaunch with USDT at the center, and a path to user recovery. These funds encompass a $100M revenue-linked credit facility, an ecosystem grant, and loans to market makers, designed to fund a dedicated user recovery pool. Learn more 👇

@petpau @JacobRobinsonJD agreed. fair and full recovery, or community will have no choice but to escalate

@JacobRobinsonJD This is going to be an easy money for Circle to counter sue. Drift protocol and Solana will get sued left and right by Circle and victims. Not even Tether bailout will save their negligence.

Circle is being sued for allegedly allowing North Korean hackers to move $230 million in stolen USDC after the Drift Protocol hack.

Let’s get this straight: users lose assets (e.g. SOL), and @DriftProtocol gives them a token as % of a fund capped at $295M? Pool is underfunded → users take the loss. Stolen assets moon → users miss the upside. A market assets buyback + compensate would be far more fair..

@metadev5 @tracybbd yeah, looks like a bailout for @DriftProtocol , not for users...

@tracybbd Stronger ? $280M gone and now launching a meme token which is not guarantee refund, what'll be the liq on the new token

brb im crying we come back stronger

@Mockingbirds231 @DriftProtocol Depends. Will they cover 100% of losses, or just force us to dump a recovery token for pennies?

Finally some good news @DriftProtocol ! Would you keep using drift if they successfully recovered affected funds ? I would.

@range_org @DriftProtocol 😂😂😂Ah, the ‘DPRK’ script. Again. This narrative is dead. Nobody buys it. Is this recycled bullshit just PR prep for @DriftProtocol’s comeback tour? x.com/DriftVictims/s…

DPRK-linked actors spent 6 months and $1M+ building trust before draining $285M from @DriftProtocol. We've put together an analysis of what happened and how DeFi teams can protect themselves against state-level intelligence tradecraft 👇 range.org/blog/inside-th…

@RT714104 @Trader_CSK The threshold was lowered (3/5 -> 2/5) two years ago. The migration (16:58:31 Mar 25, 2026 (UTC)) left this setting in place. github.com/DriftVictimsCo…

@Trader_CSK Sorry perhaps I’m reading wrong — it was my understanding Drift changed its admin security procedures (namely the number of admins needed for approval to 2 of 5) a few weeks prior to the exploit, are you saying that’s not the case?

Spent some time digging further into why Drift were targeted and whether other Solana protocols are showing similar risk. Their 6 month social engineering story breaks down how the attack happened, but not why they were picked in the first place. I looked into their governance operational history and applied the same checks to 49 others Drift's pre exploit governance setup had never been updated since the multisig was created in April 2024. Across 918 transactions on the original multisig over its lifetime: - Zero config changes. No threshold updates, no member rotations, no timelock adjustments - Signing activity concentrated in a narrow UTC window, making the operating schedule predictable - An external configAuthority key that could change threshold, members, and timelock without any multisig vote at all. This was the only protocol in my scan with this configuration. Squads default is for the multisig to control itself, so any config changes go through member voting. Drift has run three separate multisigs across this timeline, original, exploited, and recovery, and the same external configAuthority was manually attached to every one of them. It's still live today - Zero timelock between approval and execution - Durable nonce accounts in use by signers - Threshold ratio below what Squads recommends - Same person could propose and execute Every one of these conditions is public on-chain As for the other 49 Solana protocols, here's what I've found Multi purpose governance keys The same key approving multisig governance actions is also being used as someone's personal wallet across multiple protocols. What I found on those keys: - Meme coin trading through pumpfun and similar platforms - Airdrop farming across ecosystem campaigns - NFT marketplace activity on Magic Eden and Tensor - General swap volume through DEX aggregators - Team members trading on their own protocol The worst one I found had a large number of swaps on the same key that approves multisig actions. Squads recommends keys used only for Squads transactions. By not following this, every dapp it touches, every blind signature, every approval prompt is another place where that signing power can be phished or drained Single proposer pipelines One signer creates most of the proposals and is also the top approver. This is happening at several protocols. Even with a multi signer threshold, one person is really setting the agenda and pushing things through Multisig bloat Some protocols list more members on their multisig than actually sign. The member count makes it look distributed, but the signing activity tells a different story. Some teams might say these are emergency only or board signers, which is a fair setup. The problem is those members are still being counted in the public threshold. A 5 of 9 looks like distributed control on paper, but if 4 of those members have never signed, the real signing set is smaller than what's advertised. For multisigs that are genuinely dormant, the real threshold drops to whoever still controls the active keys No role separation Squads V4 has three permission types. Proposer, Voter, Executor. Splitting them across members stops any single key from both creating a proposal and pushing it through to execution. More than half of the Squads V4 protocols I scanned give every member full permissions, which combines all three. Squads docs say to always approve and execute in separate steps, and to avoid the approve + execute feature. More than half of V4 protocols have set this up to make that combined action possible Below recommended threshold Squads recommends a threshold of 4 of 6 or higher. No V4 protocol I scanned meets both the suggested threshold and ratio. Smaller teams have a fair point, they might not have 4 to 6 trusted people to act as signers. That's a legitimate reason to fall short on that specific recommendation. What it doesn't excuse is the rest. A 3 person team can still: - Avoid giving every key all three permissions - Add a timelock - Use dedicated keys for governance The team size argument only covers the absolute member count. Most of the protocols that fall short on threshold also fall short on the practices that have nothing to do with team size No timelocks Most of the Squads V4 protocols I scanned have zero timelock between approval and execution. Squads recommends 10 to 15 minutes for program upgrades and longer for treasury. The Drift exploit happened with zero timelock. V3 multisigs can't add timelocks at all, that's a known limit of the older program. But there are many V4 protocols that haven't turned one on. This is 3 steps in the multisig settings Durable nonces still in use The Drift exploit used pre signed transactions held in durable nonce accounts. Signers were tricked into signing transactions they thought were routine, and those signatures stayed valid indefinitely because the nonce replaces the normal blockhash expiry. More than a week later, the attacker submitted them and took admin control Squads has a 2 minute rule telling signers to wait 2 minutes between signatures, so any captured blockhash expires before it can be replayed. That defends against signature capture attacks, which is a different attack type to Drift's. Durable nonces break that defence too. If a signer has an active nonce account, the blockhash expiry doesn't protect them either way Several other protocols have signers using durable nonces. When I measured the gap between their consecutive signatures, most are signing seconds apart. The Drift style risk isn't being addressed, and the 2 minute rule isn't being followed either Solana's own docs now have a deprecation warning on durable nonces, pointing to an active discussion about removing them entirely. The base layer is questioning whether this should exist at all Off hours config changes The Drift exploit executed in the early hours of the morning in the Singapore time zone. Other protocols show patterns of operating in concentrated time windows. Teams based in Asia or the Pacific will rightly point out that what's 2am UTC for someone else is their working day. The pattern I'm describing isn't about a specific timezone, it's about predictability and visibility. A multisig that consistently makes config changes when most of its users and watchers are asleep has a smaller detection window than one whose changes are spread across the day. The fix isn't to match someone else's schedule, it's to avoid bunching sensitive changes when no one's around to notice What I think this means Some of these are coincidences. Some are operational shortcuts. Some are deliberate choices that work for the team behind them. But when you put the pieces together, they tell a story. Drift had those pieces sitting in plain view long before the 6 month operation started. The insider access made it possible, but the governance setup made it easier than it needed to be Other protocols have versions of the same framework Drift had. The same conditions Squads explicitly warns against are present right now Looking at the on-chain data, it's clear some protocols are taking security more seriously than others. Granted, there are edge cases like program timelocks and other nuances hidden without disclosure. Others could learn a lot from how the stronger ones have their governance set up Why things need to change The Drift exploit didn't just impact Drift. It cascaded through 22 other protocols, something I covered in more depth in my recent DeFi article. Yield aggregators, vaults, and lending positions were all plugged into Drift behind the scenes. The same conditions that enabled that cascade are sitting on other protocols today. Billions in TVL are wired together across the ecosystem. At that scale, a governance failure at one protocol becomes everyone else's problem too A lot of the post exploit conversation mentioned Circle for their lack of urgency. I'm not excusing how they handled the situation, but you shouldn't rely on others to patch vulnerabilities you ignored. If the basic governance practices Squads has published were being followed, we probably wouldn't be debating Circle's response time to Drift in the first place. Everything here was discovered on-chain. The Squads best practices I referenced are published on their site. None of this is gated or insider information. It takes some work to surface, but the raw data is public. Anyone motivated enough can see this for themselves h/t Helius - goated RPC

@Trader_CSK Actually, Drift did modify their multisig configuration in 2024 Check this out 👇 #historical-use-of-config-authority" target="_blank" rel="nofollow noopener">github.com/DriftVictimsCo…

@goldenhotplasma @DriftProtocol That’s how they removed compromised member while desperately trying to plug the hole. Looks like a total clusterfuck behind the scenes.👇 #iv-operational-chaos-the-failure-to-react" target="_blank" rel="nofollow noopener">github.com/DriftVictimsCo…

@DriftVictims @DriftProtocol bro if they opsec enough to realized they needed config auth to remove the compromised multisig wallets, they are not gonna be opsec enough to do a wallet scan. Also these things are easier after the fact, and might be missed

1/ Every day @DriftProtocol stays silent, the on-chain evidence speaks louder against them. We aren't here for PR bedtime stories. No more hiding. Time to answer questions 👇 @Solana #DriftProtocol #DeFi #Exploit

@Jiga_Solana @com7110k @DriftProtocol 🙏

@com7110k @DriftProtocol fr though, just give me my 5k back, those are life changing where im from ffs

Interim Update We recognize the impact this has had across our users and the builders who have integrated with us - many of whom rely on Drift as core infrastructure. We’re actively working on next steps and will share more once details are finalized.

@EspElement @DriftProtocol If this isn’t an exit scam, they’re doing a damn good impression of one.

@DriftVictims @DriftProtocol They are now going on a week since the last time they even tried to communicate with us. Ghosting us, I guess so they dont get charged? But silence also speaks IMO. This is a serious problem.

The main question that could turn @DriftProtocol from victim into prime suspect They had time. They had tools. They had responsibility. It’s either criminal negligence… or something worse. Still calling it “DPRK”? 👇 Chain doesn’t lie.

Breakdown 👇 github.com/DriftVictimsCo… github.com/DriftVictimsCo…

@Yot_Sangnil @DriftProtocol x.com/DriftVictims/s…

@DriftProtocol A team insider told me that they are planning to take 100% of users money and run away soon!!

@ocurry97 @0xPheaD @EricBreckenrid6 @DriftProtocol 💯

@0xPheaD @EricBreckenrid6 @DriftProtocol i don't think they want to be the next SBF! the US government will find them wherever they go, even if they go partying with the "so-called North Korean hackers" as for Solana, they better help them fix this, compensate users, or it's dead too.

@blocsys @DriftProtocol The narratives is a trap. DYOR👇 x.com/DriftVictims/s…

$285 million drained from Drift Protocol in a single exploit — and intelligence points directly to North Korea's Lazarus Group. This is no longer a hypothetical threat. This wasn't a careless dev mistake. It was a precisely engineered, state-sponsored heist. @driftprotocol had real traction and a committed community, yet sophisticated adversaries found the seam and executed with cold precision. Moreover, @chainalysis is already tracing fund movements on-chain, and the laundering patterns look hauntingly familiar to prior DPRK-attributed attacks worth billions. Furthermore, this incident forces a hard conversation across the entire Web3 ecosystem. Security cannot be bolted on after launch — it must be foundational. We need layered defenses: rigorous formal audits, real-time anomaly detection, circuit breakers, and cross-protocol threat intelligence sharing. Teams like @SlowMist_Team are doing essential work, but industry-wide adoption needs to accelerate fast. Nation-state hackers are treating DeFi like an ATM. Are you building your protocol like you know they're already watching? Drop your thoughts below — this community needs the conversation. #DeFi #Web3 #Crypto #Blockchain #CyberSecurity #DriftProtocol #LazarusGroup #NorthKorea #CryptoHack #DeFiSecurity

@PhoenixTrade respect++

The past two weeks have been tough for the Solana trading community. Some Phoenix users were directly impacted by the recent events on Drift. When our community is hurt, it matters to us. Today, we matched losses for eligible users, up to $5,000 each.

@FabianoSolana @Trader_CSK @ben_ungvari @0xINFRA nice app but it seems to not take into account the multisig config_authority 👇 x.com/DriftVictims/s…

Not trying to FUD but why does Raydium run a 2/3 multisig with such high TVL? check solgov.xyz by @Trader_CSK for details cc: @ben_ungvari @0xINFRA