Concept overview
Lyrasing is designed around a simple observation: an LRT is not just another ETH-denominated wrapper. It carries exposure to the restaking path that produced it, including operator selection, AVS opt-ins, slashing conditions, withdrawal timing, and any insurance or backstop design around those risks.
Most money-market collateral models can price ETH beta, liquidity, volatility, oracle freshness, and liquidation depth. Those inputs are necessary, but they are not sufficient for LRT collateral. Two LRTs can trade close to ETH while encoding materially different AVS exposure and slashability. Treating them as fungible ETH derivatives hides the part of the risk that matters most to restaking.
Thesis
Lyrasing treats LRTs as first-class collateral with AVS-aware risk surfaces. Collateral policy should ask four questions before it assigns an LTV:
- Which restaked assets and strategies back the LRT?
- Which operators, operator sets, networks, or AVSs can create slashable exposure?
- Which events can impair collateral value, delay exits, or reduce guarantees before a liquidation path can react?
- Which insurance pool, reserve, or haircut absorbs the loss if a slashing event occurs during a borrower position?
That framing makes Lyrasing different from a generic ETH-derivative market. The core primitive is not “lend against ETH-like yield assets.” The core primitive is “lend against restaking collateral after modeling the AVS-specific loss surface.”
Restaking and collateral are coupled
EigenLayer’s original design frames AVSs as services with off-chain execution and on-chain slashing/payment contracts, and describes restaking as a way for validators to opt into additional modules that can impose additional slashing conditions. Symbiotic’s vault model similarly makes collateral reusable across networks while making slashing policy explicit through vault, delegator, slasher, and burner modules.
Those designs make the collateral question harder, not easier. A lending market cannot only ask whether the collateral is liquid today. It also needs to ask what happens when the same economic security is reused across multiple services, when an operator’s allocated stake becomes slashable, and when pending withdrawals remain within the penalty window.
Lyrasing risk stack
The documentation uses this stack consistently:
| Layer | Question |
|---|---|
| LRT collateral | What asset is pledged, what backs it, and how exits work. |
| AVS exposure | Which services, networks, or operator sets can affect that collateral. |
| Slashing surface | Which faults can reduce collateral or route value away from the position. |
| Oracle and methodology | Which inputs can be measured without pretending an implementation exists. |
| Insurance design | Which reserve or pool absorbs modeled loss before suppliers are impaired. |
| LTV policy | Which borrowing limit follows from the above, and when it must be reduced. |
What this section does not claim
This repository does not contain protocol contracts, oracle implementations, deployed vaults, supported collateral, live TVL, live APY, tokenomics, governance, or a working app. Concept pages describe the intended risk model and documentation vocabulary so later Phase 3 pages can become more formal without mixing research framing with launch claims.
Source notes
Concept framing is checked against the EigenLayer whitepaper , EigenLayer restaking overview , EigenLayer slashing overview , and Symbiotic’s slashing and vault concepts.