Upgrade strategy

Orbit Finance follows Solana’s standard upgradeable program model. The program upgrade authority is held by a multisig so changes cannot be pushed by a single person. For permissioned pools, we also use an announcement window before upgrades go live so pool participants have time to react.

On-chain state is designed to evolve without breaking older pools. We use Pool.version as a runtime switch, and we reserve space inside accounts (_pad, _reserved) so we can add fields later without forcing everyone to migrate immediately. When a change affects how state must be interpreted, the program gates behaviour based on version so older pools continue to behave safely.

If we ever need a structural change that cannot fit into reserved space, we will ship an explicit migration instruction (for example migrate_pool). That migration would be callable only by the pool admin or config authority, it would emit an event when completed, and it would keep the pool paused if anything fails mid-way. This prevents half-migrated pools from trading in an uncertain state.

During upgrades, safety comes first. We can pause swaps, deposits, and withdrawals using set_pause or set_pause_bits while an upgrade or migration is in progress. We also separate the “pause guardian” role from full admin rotation, so emergency response stays fast and does not require changing the main admin key.

Authority setup

For critical admin actions like pausing the pool, we use a Squads Multisig with a 2-of-2 threshold:

Squads Multisig (2/2): 7nEfnDyd7ZuzK2UK4mqqP45js89YdeWBqyUmd9KCxNrn

The pool admin is also controlled by multisig today. DAO governance will be integrated in the next iteration so upgrades and sensitive configuration can transition from multisig control into on-chain proposals and voting.