M. Daeva 🌒⛓

SC dev at @xplaceapp, @solanaturbine grad,Team Lead at @StarGops_nft, former Lead SC dev at @Eclipsefi

[M. Daeva 🌒⛓ @m_daeva]

Watching 7 hours video without timestamps is such a pain, so I generated a summary for @solana Breakpoint 2025 dev stage
https://t.co/7L6VQHUXje

[Aursen @exoaursen]

LiteSVM 0.12.0 is out!

Node LiteSVM with web3.js is 0.8.0
Node LiteSVM with Kit is 1.1.0

Thanks to all contributors!

https://t.co/ICD5nyqgOK

[Kamino @kamino]

Introducing Credit Mode on @xplaceapp, powered by Kamino.

Unlock liquidity against your crypto while maintaining exposure to your assets and earning yield as you spend.

Onchain credit markets are enabling a new framework for wealth management.

[XPlace @xplaceapp]

Credit Mode is back live! 💳

Now proudly powered by @kamino.

Our first-of-its-kind product on @solana allows you to grow your wealth whilst funding your lifestyle.

Here’s how...

[M. Daeva 🌒⛓ @m_daeva]

@niran7 @SolanaFndn Huge lack of smart contract dev roles

[Aursen @exoaursen]

Just to clarify the situation, @SolanaFndn will support us this year. It's a misunderstanding on both sides. We have an agreement for the coming year. Thank you @SolanaFndn for that. Long live open source - I think it's the best chain to do it!

[M. Daeva 🌒⛓ @m_daeva]

@exoaursen @L0STE_ @SolanaFndn I can't imagine testing solana programs without LiteSVM

[Rektoff @rektoff_xyz]

Big news for Rektoff students: [Training meets placement.]

We're officially partnered with @SuperteamTalent, a community-powered recruiting agency building careers in the Solana ecosystem, backed by @SolanaFndn and @superteam.

From now on, beyond the top-notch training in Rust and Solana security, every Rektoff student now gets a direct pipeline into the best jobs the Solana ecosystem has to offer.

[CSK @Trader_CSK]

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

[Drift @DriftProtocol]

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 👇

[Tether @tether]

Tether Leads Support to the $150M Drift Recovery Plan, Stabilizes Relaunch as Drift Plans to Expand USD₮ Usage on Solana

Read more:

https://t.co/7GtC2zOxFe

[M. Daeva 🌒⛓ @m_daeva]

@emmanuelSR77 @BigOsCrypt Good idea but doesn't work well. If a hacker controls multisig of upgrade authority he can just update a program and add any logic he needs. Time lock is more effective against such attacks

[M. Daeva 🌒⛓ @m_daeva]

@emmanuelSR77 @BigOsCrypt What guards are you talking about?

[M. Daeva 🌒⛓ @m_daeva]

Sometimes you take a look at a project's code and think, “Damn, is this really code for a financial app?”

[M. Daeva 🌒⛓ @m_daeva]

@0xcastle_chain What's the point of using wincode for instruction data (de)serialization instead of bytemuck?

[M. Daeva 🌒⛓ @m_daeva]

@inspiration_gx @solana_devs Actually, no problem. 2 tools for work and everything else to play 🙂

[micaiah @micaiah_txtx]

I tested each of the new token instructions starting with a CPI doing a batch transfer: https://t.co/06TrRKFbrX

For each instruction, the CUs are crazy:
InitializeMint: 99 CUs
InitializeAccount: 149 CUs
InitializeMultisig: 167 CUs
Transfer: 78 CUs
Approve: 123 CUs
Revoke: 102 CUs
SetAuthority: 133 CUs
MintTo: 120 CUs
Burn: 133 CUs
CloseAccount: 120 CUs
FreezeAccount: 137 CUs
ThawAccount: 134 CUs
TransferChecked: 107 CUs
ApproveChecked: 160 CUs
MintToChecked: 153 CUs
BurnChecked: 140 CUs
InitializeAccount2: 161 CUs
SyncNative: 201 CUs
InitializeAccount3: 233 CUs
InitializeMultisig2: 279 CUs
InitializeMint2: 214 CUs
InitializeImmutableOwner: 37 CUs
WithdrawExcessLamports: 258 CUs
UnwrapLamports: 140 CUs

Congrats @0x_febo!

[Dean 利迪恩 (⚛️,🐱) | sbpf/acc @deanmlittle]

batch is a game changer bros, rip it.

[M. Daeva 🌒⛓ @m_daeva]

Everyone has shared the news about p-token on the testnet, but almost no one is talking about p-token’s extended instruction set 🤯

[M. Daeva 🌒⛓ @m_daeva]

@ivmidable Is it ~1.6 kB program size? Feels like a magic 🤯

[M. Daeva 🌒⛓ @m_daeva]

LFG @rektoff_xyz