Skip to main content

Rebalance and Allocation Lifecycle

Allocation changes do not activate immediately.

Allocation Update Flow​

  1. Curator calls update_allocation with timelock_secs.
  2. Program stores pending_allocations + pending_allocations_activation_ts.
  3. Depositors can review changes and exit during timelock window.
  4. On next eligible rebalance, if timelock is expired:
    • pending allocations are promoted to active allocations,
    • pending state is cleared,
    • AllocationUpdateApplied is emitted.

apply_allocation_update validates pending/timelock state and returns a clear error that activation happens on rebalance.

Orphan Guard​

When allocations are removed, update_allocation requires the corresponding VaultReservePosition.shares == 0. This prevents orphaned reserve positions with stranded funds.

Rebalance Paths​

Same-mint rebalance​

move_vault_reserve_liquidity moves capital between reserve classes of the same mint (e.g. USDC-idle to USDC-Kamino).

Cross-mint rebalance​

Uses a two-phase swap pattern:

  1. rebalance_swap_begin — locks the vault, validates pre-conditions, marks swap in progress.
  2. Keeper executes the swap via router (Jupiter/Titan).
  3. rebalance_swap_end — validates post-conditions, updates reserve positions, unlocks vault.

Sequence Diagram​

Why This Matters​

  • Clear and enforceable depositor exit window.
  • No surprise strategy switch outside rebalance path.
  • Single operational point for activation and drift correction.
  • Orphan guard prevents funds getting stuck in removed allocations.