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.