Recursive flow

Recursive flow is the conceptual pattern behind looped leverage: supply collateral, borrow against it, resupply borrowed exposure when policy permits, and repeat only within explicit loop-depth and risk controls. For LRT collateral, the pattern is useful only when the risk envelope is visible before the position grows.

This page is methodology framing. It does not provide a transaction sequence, router path, target APY, maximum-turn recipe, or market configuration.

Flow components

Component	Review question	Conservative posture
Initial supply	What collateral unit starts the position, and what backing/redemption path does it carry?	Treat each LRT, wrapper, vault share, or chain variant as separate until reviewed.
Borrow leg	What asset is borrowed, and does it increase correlation with the supplied collateral?	Prefer lower correlation and deeper liquidity before permitting recursion.
Resupply step	Does the borrowed exposure become collateral again, directly or through another route?	Require the same collateral review on every resupplied unit.
Repeat boundary	How many turns are allowed before the position must stop expanding?	Make loop depth an explicit risk control, not an interface convenience.
Exit path	Which route can unwind the stack when account health deteriorates?	Assume stressed liquidity and delayed redemption before assuming smooth unwind.

Loop depth

Loop depth is the number of recursive supply-borrow turns allowed after the initial supply. It should be reviewed as its own parameter because each extra turn increases the sensitivity of account health to price moves, oracle lag, liquidity depth, redemption timing, and slashing events.

Depth should compress when:

the collateral’s AVS exposure is opaque, changing, or concentrated;
the borrow asset is strongly correlated with the collateral or its backing route;
redemption relies on a queue, epoch, safety delay, veto period, or delayed claim object;
liquidation liquidity depends on the same venues the loop would stress;
insurance capacity is shared, pending, depleted, or unmapped to the repeated slash surface.

Correlation and timing

Correlation is not just price beta. A loop can be correlated through several channels:

Channel	Why it matters
Collateral/borrow asset	A borrowed ETH-like or LRT-like asset can move with the collateral instead of diversifying the account.
Operator and AVS exposure	Several LRTs can reference nearby operator sets, networks, or slash conditions.
Liquidity venues	The same pool or market maker can be needed for both liquidation and deleveraging.
Redemption timing	Queue, epoch, safety-delay, veto, or settlement windows can make primary exits slower than liquidation requires.
Insurance capacity	The same capacity record can be reused by several loop turns even though capacity is finite.

The conservative posture is to treat timing windows as exposure. If a position can be captured for slashing, waiting for epoch completion, or pending a safety delay while the account is still borrowable, the loop has a timing mismatch that should lower appetite.

Not an APY optimizer

Lyrasing does not frame recursive flow as an APY optimizer. The builder-grade question is not “how many turns maximize return?” The question is “which recursive exposure can survive a stressed price, liquidity, timing, slashing, and insurance-capacity path without hiding supplier risk?”

Recursive exposure compounds risk as well as any return. It can amplify:

collateral price movement;
borrow rate and liquidity pressure;
oracle or reference-price lag;
exit queue and epoch timing;
AVS slashing exposure;
operator or vault concentration;
insurance capacity reuse.

Policy output

The output of recursive-flow review should be a policy state, a maximum depth band, and the conditions that would compress or pause new loops. The detailed parameter posture lives in Parameter posture; the combined risk envelope lives in Risk envelope.