Rebalance Flow

Detailed rebalance lifecycle from solver inputs to on-chain execution proof.

Rebalance Flow

This is the canonical flow for an end-to-end rebalance.

Step 1. Collect inputs

The solver consumes:

• strategy definitions
• live snapshots
• risk policy
• manager config
• current NAV and current allocations

Step 2. Compute target weights

The solver applies the objective:

score = expected_net_apy - risk_haircut - liquidity_haircut - fee_haircut - concentration_haircut - operational_haircut

Then it assigns target weights while respecting:

• reserve minimum
• per-protocol cap
• per-strategy cap
• exotic cap
• MarginFi canary cap

Step 3. Build execution steps

For every strategy delta, the adapter creates one or more ExecutionStep objects.

Examples:

• Drift deposit
• Kamino request_withdraw
• Perena finalize_withdraw from a manifest

Step 4. Hash the plan

The solver emits:

• planHash
• targetWeightsHash
• txBundleHash

These hashes let the runtime prove that execution matches what was approved.

Step 5. Submit the rebalance plan on-chain

Ranger uses the vault program client to call:

• submit_rebalance_plan

This stores the approved plan metadata and authorized executor.

Step 6. Execute protocol bundles

Ranger sends the generated bundles:

• SDK-generated bundles for Drift and Kamino
• manifest bundles for MarginFi and Perena when available

Step 7. Finalize rebalance on-chain

Ranger calls:

• execute_rebalance
• record_execution_proof

This updates target/current allocation state and stores the execution proof hash.

Step 8. Inspect resulting state

Operators can use:

• vault-status.ts
• doctor.ts
• protocol-specific smoke tests

to validate that the runtime state matches the plan.