Loop policy

Loop policy turns the risk envelope into an operating posture for recursive leverage. It defines whether a collateral/borrow pair is reviewable, conservative, compressed, or no-loop. The policy state should govern caps, LTV posture, health buffers, and loop-depth caps together.

This page does not assign numeric values. It defines review states and triggers for a future market.

Policy states

State	Meaning	Parameter posture
Reviewable	Collateral, borrow asset, liquidity, oracle unit, AVS exposure, operator/vault posture, timing, and insurance capacity are mapped and current enough for review.	Ordinary review, still with explicit caps and depth limits.
Conservative	Inputs are mostly mapped but one or more surfaces require lower appetite.	Lower LTV posture, wider health buffer, lower caps, and low-depth loops.
Compressed	Several inputs are stale, correlated, thin, pending, or weak.	Material cap compression, materially lower loop depth, and short review cadence.
No-loop	A blocking input is unresolved or the position would reuse an unacceptable risk surface.	Recursive use unavailable until the blocker is resolved.

The policy state should be visible to builders. A loop policy that hides a compressed posture behind a normal-looking LTV makes the review harder to challenge.

Review cadence

Loop policy should be refreshed whenever a relevant input can change:

Input	Review cadence driver
AVS or operator-set allocation	New services, deallocations, redistribution posture, or changed slash conditions.
Operator concentration	Operator churn, cluster growth, key-management incident, or infrastructure dependency.
Vault or middleware posture	Epoch duration change, veto/resolver change, burner route change, or withdrawal behavior change.
Liquidity and redemption	Secondary depth, primary queue, inventory buffer, or settlement delay change.
Oracle/reference price	Unit mismatch, stale NAV, wrapper exchange-rate change, or claim-state lag.
Insurance capacity	Capacity moves between mapped, thin, shared, pending, depleted, or unmapped bands.

Short cadence is a policy response, not a substitute for compression. If an input is too weak, reviewing it often does not make high-depth recursion safe.

Compression and pause triggers

Trigger	Policy response
AVS exposure becomes opaque or materially changes	Move toward conservative or compressed until exposure is remapped.
Operator concentration increases	Reduce caps and loop-depth caps; review isolation treatment.
Liquidity depth falls or concentrates	Compress borrow caps and health-buffer posture.
Primary redemption slows	Lower LTV posture and treat claim timing as part of the risk envelope.
Oracle unit becomes stale or mismatched	Stop relying on the old reference price for recursion.
Insurance capacity becomes thin, shared, pending, depleted, or unmapped	Compress loops before simple collateral use.
Slash, veto, safety-delay, or settlement event is unresolved	Pause new recursive exposure on affected surfaces.
Unwind evidence contradicts the current route assumption	Move toward compressed or no-loop until route policy is updated.

Compression should be explicit. A future parameter record should say which trigger fired, which surface it affected, and which cap or posture changed.

Insurance-capacity coupling

Insurance capacity is not a separate comfort layer. It should be coupled to loop policy because recursive positions can reuse the same coverage argument multiple times.

Capacity band	Loop policy effect
Mapped	Can support review if collateral, liquidity, oracle, and timing inputs are also reviewable.
Thin	Conservative or compressed; depth should be low even if base collateral remains eligible for review.
Shared	Allocate before counting it for a specific loop; avoid double-use across related surfaces.
Pending	Treat as unavailable for new recursive exposure until evidence and accounting resolve.
Depleted	Move affected surfaces toward no-loop or heavy compression.
Unmapped	Do not count as support for recursive leverage.

This coupling should feed slashing-insurance capacity policy and LTV adjustments. It should not appear only in a local parameter note.

Deleveraging and unwind review

Loop policy should require review when a position can no longer unwind through the assumed route. Triggers include secondary depth deterioration, primary redemption queue growth, epoch or veto timing changes, claim-object uncertainty, insurance payout uncertainty, or account-health behavior that differs from the model.

The output can be a lower loop-depth cap, reduced borrow cap, wider health buffer, tighter isolation treatment, or no-loop posture. Forced unwind design is future protocol work; this page only defines when the review should begin.