Pool funding
Pool funding is the first constraint on credible insurance. A future slashing-insurance reserve cannot protect suppliers merely because the docs say it exists. It needs a defined source of capital, a defined claim on that capital, a refresh process, and an honest rule for what happens when capacity is too thin.
This page is design framing only. Lyrasing does not have active reserves, fee routing, deployed contracts, a token, tokenomics, governance process, or an implemented pool in this repository.
Funding sources
Future funding can come from several sources, but each source creates a different policy promise:
| Source | Design use | Boundary |
|---|---|---|
| Protocol fee allocation | Route a share of future borrowing, liquidation, or market fees into a reserve. | No live revenue or fee route exists today. |
| Spread allocation | Use a future risk spread from AVS-aware borrowing to capitalize coverage for the slash surface creating that spread. | No spread schedule or market parameter exists today. |
| Reserve allocation | Seed a reserve from protocol-owned capital or treasury allocation once such capital exists. | No active reserve, treasury policy, or protocol equity account exists today. |
| Surplus after claims | Rebuild capacity from excess fees after operating and prior claim obligations are clear. | Surplus cannot be assumed before accounting rules exist. |
| External backstop capacity | Contractual or off-chain capital commitment that absorbs a defined class of events. | A backstop is not coverage until enforceability, priority, and withdrawal terms are defined. |
| Redistributed slashed funds | If a slash route redirects funds to harmed parties or a recipient, those proceeds can affect the loss calculation. | Redistribution depends on the source protocol and cannot be counted unless the recipient, asset, and timing are known. |
The funding source should map to the covered exposure. If borrowers pay for AVS-aware leverage, the reserve argument is strongest when the fee route funds the specific AVS, operator, vault, or collateral class that creates the loss. Generic platform revenue is weaker because it can be consumed by unrelated events before the relevant claim arrives.
Capitalization posture
Capitalization should be recorded by surface, not by brand:
| Surface | Funding record should answer |
|---|---|
| AVS or network | Is capacity allocated to the service that can slash the backing position? |
| Operator set or operator cluster | Does the reserve recognize correlated operator incidents across several LRT candidates? |
| Vault or strategy | Is capacity tied to the vault epoch, withdrawal slashability, or Burner settlement path? |
| LRT collateral variant | Does the reserve distinguish canonical, wrapped, bridged, receipt, and queued-claim variants? |
| Looping exposure | Does capacity account for recursive supply-borrow positions that amplify the same loss? |
The reserve should not treat a large nominal balance as universal coverage. A pool can be large and still irrelevant if it is not assigned to the event class that actually impaired collateral.
Replenishment
Replenishment policy should be written before the first claim. A useful design record would define:
- Which future fees refill the pool after a payout.
- Whether new borrowing is capped or paused while capacity rebuilds.
- Whether replenishment is surface-specific or shared across all markets.
- Whether a reserve target exists before new leverage is allowed.
- Whether external backstop capacity can be drawn repeatedly or only once.
Replenishment should feed collateral policy immediately. Thin or depleted capacity should compress caps, reduce LTV posture, limit looping, and shorten review cadence. It should not wait for a governance ritual if suppliers are already exposed.
Depletion
A depleted pool is a risk signal. The design should specify what changes when available capacity is consumed:
| Condition | Conservative response |
|---|---|
| Capacity drops below the surface’s open exposure. | Compress borrow and supply caps for that surface. |
| A claim is pending but not verified. | Treat capacity as reserved until the claim is resolved. |
| A payout is made and replenishment is uncertain. | Lower LTV posture and restrict new looping. |
| Several correlated surfaces can claim the same pool. | Allocate capacity by priority before counting it as coverage. |
| External backstop capacity can withdraw or expire. | Treat it as unavailable after the notice or expiry boundary. |
If depletion can create supplier shortfall, the docs should say that directly. Insurance can reduce loss severity only while it has capacity, priority, and an enforceable payout path.
No-tokenomics boundary
This page does not introduce a native token, emissions schedule, staking model, governance UI, fee switch, treasury account, or reserve contract. Future tokenomics may exist elsewhere, but they are not part of this repository’s current implementation scope.
Source notes
EigenLayer’s slashing and redistribution docs distinguish burned funds, redistributed funds, Unique Stake, and redistributable Operator Sets. Symbiotic’s slashing docs distinguish vault-level slashers, VetoSlasher timing, and Burner routing. Lyrasing uses those mechanics to frame funding questions only; it does not claim live fee routes, live reserves, or integrations.