Looking for traders to help test Drift ahead of relaunch. We’re opening private beta soon and want feedback to make sure the experience is smooth, stable, and ready for users. If you’re interested in testing, DM me your SOL wallet and I’ll add you to the list.

I've been deep in the trenches getting @DriftProtocol relaunched and can't wait to show you all the exciting changes we've been making so here's a brief high level update: 1) every risk parameter on perp and spot market (what you know as borrow/lend), is being empirically derived. nothing is being left for eyeballing/guess work, instead being measured from book's past behavior during crashes and size around that. plan is to start relatively conservative and loosen incrementally as TVL rebuilds, more than happy to go deep on the methodology per metric but keeping that for dedicated posts. 2) OI caps are sized to what we can actually liquidate. more than just a demand forecast, it's also worst-case absorption limit. we stress every market against an instant ~40% adverse move (harsher than oct 10-11 realized) and size so that even with makers fully withdrawn there's no bad debt. I'm aware this might be more aggressive than needed so it's not the final caps, which will still account for backstop liquidity/IF. 3) I spend a lot of time working on vAMM (our internal market maker + fallback liquidity), some major changes: did a big refactor that decoupled it off the PerpMarket struct into its own quoter interface, which makes the whole thing far cleaner to reason about and to audit. alongside ex-gauntlet researchers, lot of modeling and formalization (which I'd love to release publicly at some point in future) is being done to improve quoting/spread logic so you get the best price with good liquidity. this will continue improving post launch. 4) on funding rate mechanism, we've added clamps to reduce extreme spikes, updated the base funding rate in dead zone, and there's ongoing modeling to reduce volatility with the goal of funding that's smoother and more predictable to trade against. 5) a big part of the relaunch is lowering the attack surface, so been removing legacy code paths that don't need to exist anymore. this is the same tech debt @redacted_noah has been posting a lot about lately 6) more soon.. we will also release a detailed changelog at relaunch so you can go through entire list yourself. meanwhile, I want to be as transparent as I can so will post more and please feel free to ask/tag me with any questions around exchange's economics/mechanism 🫡

A common question we're getting on the Drift relaunch is: why is it taking so long? Why do you even need a 'relaunch' when it was already live? One of the biggest decisions early on was: new program or reuse the old one? We decided to launch with an entirely new program/program ID. Why? 1. The existing program's state was in limbo after the hack. It didn't fully resolve the liquidations because the exploiter's collateral was never marked to 0. We wouldn't want to muddy that state, because it is needed to snapshot what everyone is owed. 2. Security is not something you can just strap on - it takes thoughtful design from the outset. Adding extra security means making breaking changes to on-chain state. Making these changes while providing a migration path for existing state is 10x harder. An analogy - code is like a Jenga tower. Security is at the bottom of the tower. It is very hard to change the blocks at the bottom without toppling the tower. If the code is not in production, though, you can simply put the top part of the tower off to the side and fix the bottom. Next. Why is it taking so long? Part of making a program more secure is lowering the attack surface. Over the years, Drift developers were forced to make less-than-ideal design decisions in order to not change existing code in a non backwards compatible way. In tech circles, we call this accumulating 'tech debt'. Now that the program needs to be completely re-audited from scratch, that debt not only adds heaps of time and cost to the audit schedule, it also increases the attack surface and makes the code hard to reason about. Is this a complete rewrite? No. That would take far too long, and would be unproductive as it would lose all of the hard-fought lessons built into the existing code. Think of it more as mowing the lawn. It's overgrown, and there are weeds everywhere. I'm whacking the legacy problem sections I can find, and trying to make the code easier to audit. I'm not going to catch everything, or have time to fix all tech debt, but I'm fixing all of the top offenders. I'll share more in later tweets of specific changes I've been making, as I want to be as transparent as possible.

While it's been an epic few years at Helium, I couldn't resist the call of another migration-level challenge. Those of you who know me know I can't resist chewing some glass. As such, I am going to join @DriftProtocol team and help them relaunch. Why? Because I genuinely believe that Drift provides a valuable set of primitives to the ecosystem and is worth saving. This is also the best path to funding user recovery; we must build something so useful it can generate the revenue needed for the recovery pool. Tall order. The landscape has shifted. Trust is eroded. Things that are worthwhile are rarely easy, and this is no exception. I fully acknowledge I could be applying for a job at Wendy’s in 6 months. Everyone has forks in the road in their careers, easier paths vs harder paths. I have chosen the harder path at every turn; and it has paid off. Not every swing hits, but even in failure you massively level up your skillset. My focus is on improving the security stance of Drift, getting it relaunched, then turning it into the best perps exchange in existence: First, that means working with STRIDE to ensure we're following the best multisig and opsec practices. I won’t be taking this endeavor alone, the chads at @asymmetric_re and @osec_io have been incredibly helpful and continue to be deeply involved in auditing both new code and new operational practices. Security does not come from one individual, it comes from cultivating a culture of security and having outside professionals continuously verify that work. Second, I am overhauling the codebase (within reason). Over the years it has picked up a large set of features, many of which no longer need to be used. The protocol has solid bones, but tight coupling has led to a buildup of tech debt that is easier to fix during this downtime. Third, I want to build multiple levels of security and circuit breakers into the protocol. DeFi protocols must be structured to limit the ability of a single incident or contagion to create havoc. I will be thinking from the perspective of defense-in-depth; there should be layers of protection to prevent incidents like the April 1st hack. The program should reject suspicious changes even if they come from an operational multisig. Lastly, and more long term, I want Drift to become the most compelling perps exchange on the market. I am very much looking forward to entering the arena that is perps on Solana. It is an honor to be competing with the chads on all the other teams (Phoenix, Bulk, Gm, Imperial, Pacifica, etc). Steel sharpens steel, and I eagerly await the firehose of knowledge over these next few months. Solana needs as many shots on goal as it can get. One (or many) of us will win.

CLARIFICATION: DIP-10 is unrelated to the Insurance Fund. It is specifically about the remaining spot assets in the Borrow/Lend pool, and proposes to authorise Drift Foundation to convert those assets into stablecoins to seed the recovery pool at launch. Affected users will receive recovery tokens representing their verified loss, which can be claimed against the recovery pool as it grows.

Vote now: v2.realms.today/dao/FVVXu18a…

Vote for DIP-10: Treatment of Remaining Asset in Borrow Lend is currently live.

Read the full draft and join the discussion: driftgov.discourse.group/t/d…

New Discussion: Treatment of Remaining Assets in Borrow/Lend The new discussion covers: • Converting remaining borrow/lend spot assets into USDT for the recovery pool • Settlement methodology and treatment of user balances post-incident • Improving transparency, reporting, and governance oversight around implementation and recovery processes The objective is to support long-term protocol sustainability while improving transparency and governance standards following the April 1, 2026 incident.

Clarification: Users are able to redeem at any time after redemption opens; however, early redemption occurs at a discount to the full claim value as users receive a pro-rata share of the current pool. Holders who wait may benefit from a higher recovery price as the pool continues to grow.