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.)

That APR-weighted want is then capped two ways:

• Exposure cap so no single protocol takes 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\%)$$

• Depth cap so a protocol never receives more than a fraction of its reserve’s currently withdrawable cash. Here depthᵢ is the reserve’s available (unborrowed) liquidity (total supplied minus total borrowed), so this keeps the vault inside the market’s exit capacity. It never becomes a position it could not later withdraw, and if a reserve’s available cash shrinks the cap shrinks with it, pulling the vault back on the next rebalance.

$$\text{depth\_cap}_i = \text{depth}_i \cdot \frac{\text{max\_depth\_bps}}{10{,}000} \quad(\text{default } 50\%)$$

The final target is the smallest of the three:

$$\text{target}_i = \min(\text{want}_i,\ \text{max\_per},\ \text{depth\_cap}_i)$$

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 exposure cap is 700, so B is capped: target B = 700, target A = 250. (The remainder stays available and is handled on the next tick.)
• If B’s reserve only held, say, 1_200 of withdrawable cash, its depth cap (50% × 1_200 = 600) would bind first and lower target B to 600, leaving the rest in idle or A.
• 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.