Rebalancing

Rebalancing is how SAM moves the pool toward the best-yielding mix. It is permissionless: anyone can trigger it, and the entire allocation is computed on-chain from each protocol’s measured APR. No one chooses the split by hand, and no single protocol can be over-filled.

The idea

Think of every protocol plus the idle buffer as a set of buckets. SAM works out a target for each protocol from its yield, then moves liquidity from over-target buckets to under-target ones: deploying spare idle, moving funds directly protocol-to-protocol, and topping the idle buffer back up if it ran low.

Step 1: what’s available to spread

$$\text{idle} = \text{liquid balance}, \quad \text{deployed} = \sum_i \text{current}_i, \quad \text{total} = \text{idle} + \text{deployed}$$

A fraction of the vault is always held liquid as the idle buffer:

$$\text{buffer} = \text{total\_coin\_in} \cdot \frac{\text{idle\_buffer\_bps}}{10{,}000} \quad(\text{default } 5\%)$$

Everything above the buffer is the pool to spread across protocols:

$$\text{pool} = \max(0,\ \text{total} - \text{buffer})$$

Step 2: each protocol’s target

Targets are proportional to learned APR, so a higher-yielding protocol gets more capital:

$$\text{want}_i = \frac{\text{APR}_i}{\sum_j \text{APR}_j} \cdot \text{pool}$$

(If no protocol has learned an APR yet, the pool is split evenly instead.)

Each target is then capped for diversification, so no single protocol can take more than a fixed share of the pool:

$$\text{max\_per} = \text{pool} \cdot \frac{\text{max\_exposure\_bps}}{10{,}000} \quad(\text{default } 70\%), \qquad \text{target}_i = \min(\text{want}_i,\ \text{max\_per})$$

A protocol holding more than its target has releasable supply supplyᵢ = max(0, currentᵢ − targetᵢ).

Step 3: move toward the targets

For each protocol below its target, SAM funds the shortfall in order:

1. From idle, deploy spare idle (above the buffer) into the protocol.
2. From over-target protocols, move funds directly from a protocol that has releasable supply into the one that needs it (idle is never touched for this).

Then, if the idle buffer is below its target, SAM reclaims leftover over-target supply back into idle until the buffer is refilled.

Note

Moves smaller than a tiny dust threshold (MIN_DEPLOY, 1_000 base units) are skipped. This avoids deposits so small they’d be rejected by the underlying protocol, and it means an already-balanced vault produces no moves, so rebalancing can’t be spammed to churn funds.

Worked example

Two protocols, 5% idle buffer, 70% exposure cap, a pool of 1_000:

• Protocol A APR 4%, Protocol B APR 12%.
• Weights: A = 4/16 = 25%, B = 12/16 = 75%.
• Raw targets: A = 250, B = 750. The cap is 700, so B is capped: target B = 700, target A = 250. (The remainder stays available and is handled on the next tick.)
• SAM deploys idle and/or moves funds so A holds ~250 and B holds ~700.

If B later harvests a reward that lifts its measured APR, its weight rises, its target rises to the cap, and the next rebalance shifts more of the pool into B, automatically.

What a rebalance cannot do

A rebalance only ever moves funds between registered protocols and the idle buffer. The amounts are computed on-chain and the funds are handed straight to the protocol connectors, the person who triggered the rebalance cannot redirect any of it to themselves. Triggering a rebalance is a keeper/janitor action, not a privileged one.