Sign in

Execution Layer Shift

Dependency Independency

Write the exit

Outside World and Dependencies - Test

Dependency Independency

Suggest an edit

System resilience requires minimal dependencies, and for those that are difficult to avoid, explicit decoupling paths. With this approach, the protocol can achieve what we call ‘Dependency Independency’.

Examples

Zeebit on MagicBlock. The casino needs instant moves, so it runs rounds on an ephemeral rollup (a temporary, fast layer-2 network built just for short-lived tasks). This is a real dependency because the rollup is a separate validator that can stop or fail. But the player deposits into Zeebit's program on Solana, and the money stays there. Only the state of the current round is handed to the rollup. When the round ends, the result is written back to Solana and the payout happens there. The dependency lasts one round and never touches the funds, so the exit is the normal flow, not an emergency plan.

Drift keeps the oracle of every market as a setting: moving a market to another feed is an admin instruction, not a deploy. Drift already has a one win situation with this. Before FTX collapsed, Drift used Serum (the main orderbook on Solana). After the crash it became unsafe to use but because a Serum market was a config account that the admin could enable or disable Drift successfully moved to OpenBook (community fork of Serum).

Anti-Examples

UXD kept its hedge on Mango Markets with no way to move it, and when Mango was hacked there was nothing left to do but close the product. A delta-neutral stablecoin makes sense with any deep enough perpetuals, so Mango was a part, and a part needs a way to be replaced.

Serum's upgrade key was held by FTX, so when FTX collapsed the only exit left was a fork.

Drift (in April 2026) lost far more because of its dependency on their Security Council. It was just a Squads multisig that needed 2 of 5 signers and there was no timelock. Attackers spent months gaining the trust from contributors and obtained approvals from two signers for transactions the signers did not understand. Drift lost $285m and later relaunched as Velocity.

The test is simple: would the product make sense without this dependency? If yes, the dependency is just a part of it, and parts can get replaced. A lending protocol makes sense with any price feed, so the feed is a part (you dont need to add Pyth oracles if you already utilize Raydium in other part of your protocol, just use TWAPs). If not, there is nothing to plan. Sometimes, protocols exist just because of their dependency, and this is okay. Aura exists only because Balancer does; if Balancer disappears, Aura loses nothing, it simply wouldn't be there in the first place without Balancer. It’s an EVM example, but the concept is the same for any chain and frankly, any product in any field.

Dependencies and their exits A table of six dependencies. Zeebit depends on an ephemeral rollup, would make sense without it, and leaves it in the normal flow because every game ends on Solana. Drift depends on an oracle feed and can switch it with an admin setting, without a deploy, which is fast but is also a path for an attacker who holds the admin. Drift depended on Serum, and moving to OpenBook took a program upgrade after the failure, because Serum's id was a constant in the code. UXD depended on Mango for its hedge, had no exit planned, and dropped that design after Mango was exploited. Serum depended on a key held by FTX, had no exit, and was forked by the community. Aura depends on Balancer and would not make sense without it, so there is nothing to plan. Dependencies and their exits protocol depends on makes sense without it? exit Zeebit ephemeral rollup yes normal flow: each game ends on Solana Drift oracle feed yes admin setting: fast, but also an attack path Drift Serum yes upgrade after the failure: id in code UXD Mango for its hedge yes none planned: the design was dropped Serum key held by FTX yes none: the community forked it Aura Balancer no nothing to plan Every row with a "yes" needs an exit that exists before it is needed. The red rows had none, and the exit had to be built after the failure.

List every dependency of your protocol, including the oracle, every protocol it trades on, every layer it runs on, every bridge and the upgrade key. For each, write down such things: would the product make sense without it, what is the exit if it fails, who can trigger that exit, what can someone do if they gained control over the keys.

Previous

Execution Layer Shift

Next

Write the exit