Drift Protocol engineer explains why the
@DriftProtocol relaunch is taking longer.
TL;DR:
The solana:DriFtupJYLTosbwoN8koMbEYSx54aFAVLddWsbksjwg7 relaunch is taking time because developers are deploying a brand-new program rather than patching the old one.
This allows them to preserve the post-hack state for accurate user snapshots, clear out years of accumulated technical debt, and fundamentally harden security for a fresh audit without risking a live, messy codebase.
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.