Automated Yield Routing

Overview

AggreLend continuously steers each deposit toward the most favorable supply-side lending venue available for its token, operating a simple but relentless loop of measurement, comparison, and on-chain rebalancing so that the user experience remains “deposit and hold” while the protocol’s routing logic does the unglamorous work of switching venues whenever a materially better net APY appears; this is implemented by reading rates from integrated markets at regular intervals, scoring them with lightweight guardrails for liquidity depth and reliability, and, only when a clear improvement threshold is crossed, invoking program instructions that withdraw from the previous venue and deposit into the new one via CPI in a single routed optimization.

The routing surface is intentionally narrow—there are no orderbooks, no perps, and no borrow-looping behaviors—so the only thing that ever changes is the user’s supplied asset location between vetted lending venues, and the decision is always made to prefer predictable, repeatable outcomes over momentary, hard-to-capture spikes in quoted yield that disappear as quickly as they arrived.

When an optimization happens (what we mean by “optimization”)

An optimization is the program’s on-chain action that atomically withdraws funds from the currently selected venue and deposits them into a different supported venue for the same token, updating the AggreLend position state in the same transaction. It is a single, routed “withdraw-then-deposit” CPI sequence that commits or fails as one unit; no user input is required once a position exists.

An optimization is considered when all of the following conditions hold within the same observation window:

1. Net Rate Improvement: A destination venue advertises a meaningfully higher effective APY for the token (the effective rate includes any venue rewards normalized back into the base asset using conservative quotes).
2. Capacity Check: The destination venue shows sufficient available liquidity and utilization headroom for the expected transfer size such that the act of moving will not immediately degrade the realized rate below the current venue’s level.
3. Durability Signal: The improvement persists across a short confirmation window (hysteresis) to avoid churn from transient prints; if the improvement is fleeting, the router defers.

When these are true, the router performs the optimization CPI: withdraw (source) → deposit (destination) → update PDA, completing atomically at the program level.

Partial optimizations

For larger balances or thin destinations, the router may execute a partial optimization, moving only a portion of funds to the top venue while keeping the remainder in the runner-up venue(s). This reduces slippage against venue caps and keeps realized APY closer to the displayed figure, especially during volatile utilization.

Cool-downs and backoff

After any optimization, the position enters a short cool-down to prevent immediate oscillation if rates flip back. Repeated deferrals or failed venue health checks increase a backoff timer, which gradually resets as conditions stabilize.

How we evaluate rates

Reported APYs from venues are normalized into a comparable effective APY by:

• accounting for ordinary lending interest;
• including venue reward streams (where applicable) by converting rewards into the base token at a conservative spot quote and prorating on a time basis; and
• discounting venues with rate prints known to decay on fill due to caps, utilization cliffs, or rapid oscillation.

This approach means the APY displayed in the interface is the APY you earn in-kind, because rewards (if any) are periodically harvested, converted into the deposit token, and re-supplied to the position, keeping accounting simple and balances compounding in the same asset you deposited.

Liquidity and reliability guards

Because the headline “best rate” is not always the best outcome, the router applies liquidity health checks and stability heuristics that can down-weight venues with thin capacity, abrupt utilization changes, opaque caps, or unusually noisy prints. Where sensible, the router:

• prefers the second-best but more reliable venue;
• splits a large position across the top venues to keep each leg inside comfortable capacity; and
• waits for durable improvement before optimizing, so realized earnings track the on-screen number rather than transient spikes.

Execution path and settlement

Optimization follows a straightforward path:

1. Read venue set and current per-token rates;
2. Score venues with liquidity and reliability guards;
3. Apply hysteresis and cool-down/backoff constraints;
4. If eligible, perform CPI withdraw (source) → CPI deposit (destination);
5. Update the AggreLend position PDA to reflect the new allocation;
6. Emit logs sufficient for external monitoring and reconciliation.

If any unrelated instruction appears in the same transaction that is not part of this flow, program-level guards refuse execution. The optimization is atomic—either the entire routed change commits or the state remains exactly as before.

Failure handling

If a venue rejects a deposit due to a live capacity drop, the transaction reverts and no funds leave the current venue. If source withdrawal succeeds but destination admits a late failure, the transaction still fails atomically, preventing partial moves. Retries follow the backoff policy and re-check rates and capacity before attempting again.

Design philosophy

The architecture favors clarity over cleverness—fewer moving parts, deterministic decisions, observability in logs, and repeatable results—so the system is easy to reason about for users and integrators. Because we only integrate lend-only markets with sensible audits and operational history, the surface for failure is reduced to a minimal, understandable set of on-chain interactions, and “optimization” remains what it should be: a small, reliable step that quietly lifts your realized APY without introducing new kinds of risk.