Rebalancer

One cycle#

The keeper runs a cycle every 10 minutes. For each tier, Bedrock then Rapids:

1. Read rates

   Fetch every venue's APY, TVL and utilisation from the venue APIs or DefiLlama, cached for 5 minutes. See rate sources.

2. Run the risk sentinel

   Classify each venue as ok, caution or pause, which can lower its cap or set it to zero. See Risk sentinel.

3. Read the vault

   Read idle, total assets and every strategy position from the chain.

4. Smooth, solve and plan

   Update the smoothed APYs, solve target weights and decide which moves are worth making this cycle.

5. Save memory, then execute

   Persist the planner's memory (cooldowns, turnover, smoothed rates) before sending anything. Then send one deallocate or allocate per venue, deallocations first, stopping at the first failure.

6. Mirror rates and log

   Write every venue's live APY into its devnet reserve, then append the decision and the new targets to the log.

A cycle never overlaps the previous one, and a failure in one tier does not stop the other. Saving memory first means a crash in the middle of a rebalance can only make the keeper more cautious after a restart; it never repeats a move.

Smoothed rates#

The planner never acts on a single spot sample. It uses an exponential moving average of each venue's APY:

• The average has a 12-hour half-life.
• One observation can pull the average by at most 2 APY points. A short spike barely registers; a sustained change comes through in about a day.
• A venue seen for the first time, or after a restart without memory, starts from its 7-day median rather than the spot rate.

Each decision records both the smoothed and the spot APY of every venue, so you can see how far apart they are. The risk sentinel works on spot rates, so smoothing never delays an exit.

Targets#

The optimizer computes where each tier should ideally sit. Each venue gets a risk-adjusted score, then the weights solve:

subject to:

• each weight between its floor and its cap (the lowest of the on-chain cap, the sentinel cap and the 35% concentration limit);
• all weights together at most 95%, leaving the 5% idle buffer;
• each non-Solana chain at most 50%, and all cross-chain venues together at most 50%;
• the best three eligible venues at least 5% each, so a vault never piles into one or two.

The quadratic term is a concentration penalty: the more weight a venue already has, the less the next dollar there is worth. The solution is a water-filling whose level is found by bisection, with chain groups pinned to their caps when needed.

With λ = 0.08, a Bedrock venue with risk score 3 is charged 0.72 points against 0.32 for a score of 2, so it must pay 0.4 points more to compete. Rapids charges less than a third as much, which is what lets it hold riskier venues. The latest targets are served at /targets.

Planning moves#

Targets say where to go. The planner decides how much of the way is worth moving now, in this order:

1. Safety exits. Any position above its cap, whether the on-chain cap or a lower one from the sentinel, is cut to the cap at once and the excess goes to idle. Exits ignore every churn limit below.
2. Frozen venues. A venue the sentinel flags now, or flagged in the last 24 hours, can lose funds but never gain them, so the sentinel and the optimizer cannot fight over a spike.
3. Deploy idle. Idle above the 5% buffer goes into under-target venues, best score first, as long as the expected yield at least pays for the move. Deploys are one-way and do not count toward turnover.
4. Venue-to-venue moves. Only when every condition below holds. Each move closes at most half of a venue's gap.

Finally the moves are netted to one deallocate or allocate per venue, deallocations first, and handed to the executor. The executor clamps each allocation to the live on-chain headroom under the cap, with a 5 bp margin, and skips anything under 1 USDC.

The cost check#

A venue-to-venue move must pay for itself within the holding period, even if the spread shrinks a little:

A real example from the decision log on 8 October 2026. The planner considered moving 14,896 USDC from Jupiter Lend to Aave v3 on Base, and held:

Jupiter Lend → Aave v3 14,896 USDC: -0.09% spread gains -6.85 USDC over 30d vs 9.48 cost (needs 2x, after a 0.5% margin)

The cost is 1.50 USDC to leave Jupiter (0.01 + 1 bp) plus 7.98 USDC to enter Aave across CCTP (5 + 2 bp). After risk adjustment Aave scored slightly lower than Jupiter, so the gain was negative before the margin and the move was never close. A deploy from idle skips the margin and only needs the gain to cover its cost.

The decision log#

Every cycle writes one decision per tier, whether it moved or not. The app's Rebalancer view shows them; the keeper serves the latest 200 at /decisions.

How well it works#

On 8 October 2026, 197 of the 200 decisions the keeper served were holds and the other 3 were sentinel exits; there was no yield-driven reallocation in that window. Spreads between blue-chip USDC venues are usually smaller than the 0.5-point margin plus the cost of moving.

A backtest replays historical rates through the real cycle (the same sentinel, smoothing and planner, with a paper executor). Over 90 days from 10 July 2026, with 6-hour steps and 1,000,000 USDC per tier:

The policy captures about 89% (Bedrock) and 95% (Rapids) of the oracle bound and lands within 0.03 points of holding its first allocation, while keeping the ability to exit a venue on a risk signal. Parameter sweeps moved realised APY by at most 0.03 points, with the direction changing between windows, so the defaults are unchanged.

Tuning#

Every planner parameter can be overridden with an environment variable on the keeper. None are set in production. Sentinel thresholds and optimizer parameters are constants in the code.