# Liquid Restaking Provider
This document serves as a PoC for how liquid receipt tokens can be created for deposits on restaking platforms such as Eigenlayer. For use at [Ion Protocol](https://twitter.com/ionprotocol).
## Overview

### Restaking Positions
Restaking "positions" are defined by the following metadata.
1. The token that is being used as collateral.
- ETH, stETH, rETH, other LSTs, USDC, DAI, etc.
2. The operator that the token is delegated to.
- This operator is running an AVS client and when the operator commits a slashable offense on the AVS client, the slashable security should be deducted from this operator. Under the hood, the 'operator' entity on-chain could be tied to an individual or large node operator sets.
3. The AVS's that the operator is validating.
- Once the tokens are delegated to an operator, this operator can put up the tokens as slashable security to AVS consensus rules. The operator could be validating one AVS or multiple.

### Properties
Some properties we want from a tokenized liquid representation of restaked positions.
1. Selective Fungibility
- The LRTs with equivalent risk/reward profile should be fungible.
- In other words, staked tokens that are subject to the same set of slashing rules, earning the same rewards, and delegated to the same operators should be *fungible*.
- Some positions could also be fixed term based on configuration and tokens of different maturity should not be fungible.
2. Withdrawal Rights
- The current owner of the LRT should have exclusive redemption rights upon which the liquid restaking provider initiates withdrawals from the restaking platform. Ideally [execution layer triggered](https://eips.ethereum.org/EIPS/eip-7002).
4. Composability
- The LRTs should remain composable with the rest of DeFi.

### Token Standards

Analogous to TradFi corporate bonds which are liquid and fungible only within specified classes of risk ratings, restaked positions require a token standard that can maintain compartmentalized fungibility.

Considering multiple approaches,
- ERC-20
- Issuing a separate ERC-20 contract for each resatking position would explode the number of deployed contracts and be very gas intensive.
- While this satisfies selective fungibility, integrations with this large number of addresses would be impractical and composability is lost.
- ERC-721
- Ignoring URIs typical to NFTs, could mint a unique `id` for each position based on user, operator, AVS information.
- Some composability would be possible with NFT-lending style integrations.
- But cannot be fractionally owned or transferred which limits DeFi usecases.
- ERC-1155-Like
- Each `id` represents one or multiple restaking positions of similar risk/reward profiles.
- Each `id` contains fungible balances for partial batch transfers which achieves selective fungibility and DeFi composability.
- Gas efficient as a single contract can take care of all future restaking positions.

ERC-1155, a combination of ERC-20-like `address => uint` balance mapping, and the non-fungibility between `id`s in ERC-721, is closest to meeting the design goals.

The challenge would be determining how we want to issue and define each `id`, whether it should contain one specific restaking position, or to allow multiple restaking positions of similar risk profiles to be treated as a single `id`. The contract allows for both, and is more of a question of risk and economic analysis.

### Direction

While the ERC-1155-Like fragmented LRT approach is the most ideal in terms of segmenting risk and reward profiles, there may not be a restaking ecosystem active enough with operators running different combinations of AVS validation strategies to justify the complexity and the lack of deep liquidity that will be a byproduct of the design.

Largely, the choice for a standard is a function of at which layer does the provider want to abstract the risk from the users of the liquid restaking provider.

The provider could mint LRTs for specific collaterals and actively manage operator/AVS choice in the backend, or the provider could mint LRTs for specific collateral/operator/AVS combinations that can't be changed for fixed durations.

We now focus specifically on Eigenlayer to flesh out a deployable version.

## Eigenlayer LRT Spec

We take Eigenlayer as a first example of how Liquid Restaking Tokens could be instantiated. We ignore validator native restaking and only focus on LST restaking for simplicity.

### Eigenlayer Restaking positions
While the above outlines the general framework for how exotic staking derivatives could be represented, the Eigenlayer specific implementation may look different.

A few key points on Eigenlayer:
- On the marketplace, the stakers can choose the collateral type(s) and the operators.
- Stakers choose AVS's *indirectly* by proxy of choosing operators that validate certain AVS's.
- But the AVS's choose which operators can opt-in based on their collateral combinations.
- The AVS's control the type of assets via setting the minimum 'quorum' value, which is a weighted sum of the operator's collateral-specific shares and collateral multipliers.
- It's important noting that hard restrictions on blacklisting specific tokens may be difficult. For ex. even if the multiplier for stETH is zero, an operator can still opt-in stETH as a restaked token to an AVS if it has large amounts of another collateral that the AVS has assigned a high multiplier to.

- There is a rebalancing force where
- If the operator chooses too many risky AVS's, risk-off stakers will move from risky operators to less risky operators.
- If the AVS's allow too stringent of a quorum, there may be little demand and the AVS will need to pay higher.
- AVS's will likely pay more for higher quality strategies and less for lower quality strategies.

The main observation is that the risk for stakers is in fact hard to estimate as the stakers do not have a direct say in what AVS's their delegations will be opted-into. This poses a barrier to creating LRTs that can represent a common risk profile of AVS's.

Overall, the most intuitive way to create receipt tokens on Eigenlayer would be building on top of defined "strategies".

### Method #1 - Strategies

The provider contract takes custody of user funds and manages delegations and withdrawal requests. The provider mints an LRT for each strategy and the yield is socialized across each LRT specific to a strategy.

**LRT for Strategies**
- The provider mints an LRT for each strategy.
- Strategies could be stETH only, Top-3 LSTs, USDC-only, or Top-3 Stablecoins, etc.
- Provider/governance manages delegations to certain operator addresses.

**Deposits**
- Receives the token transfers from users.
- Provider calls `depositIntoStrategy` for the strategy tied to the LRT.
- Provider manages `delegateTo` for operators.
- Managing multiple delegations
- On Eigenlayer, each staker address can only delegate to one operator at a time. One staker address cannot have delegations in two operators.
- The LRT contract will need a factory that spins up proxy addresses in order to delegate deposited asset into multiple operators.

**Withdrawals**
- Upon redemption request of the LRT, provider queues withdrawals.
- When all [withdrawal conditions are checked](https://github.com/Layr-Labs/eigenlayer-contracts/blob/master/docs/EigenLayer-withdrawal-flow.md), upon completion, the shares or tokens are sent back to the user.
- Because the shares are delegated to multiple operators, the withdrawals should also come proportionaly from each operator to prevent drainage of a single operator upon large redemption requests.

**Earnings/Losses**
- The provider maintains the owning address of all shares that are being delegated.
- All rewards and slashes are socialized for LRT holders.
- Earnings
- The AVS payment rail to operators are not yet fleshed out on Eigenlayer docs, but presumably the total rewards available to the staker—which in this case is the provider address—will be trackable on the EL contract.
- Losses
- When an AVS slashes an operator, the operator is frozen and the removed shares are reflected in both the `stakerStrategyShares` and `operatorShares`.

**Redemptions**
- Exchange Rate
- The exchange rate is calculated as a ratio of circulating LRT supply to the total reserve post earnings and losses.
- Can be calculated off-chain and reported with zk-proofs similar to the [zk Proof-of-Reserve system](https://hackmd.io/@30BOqhL6SqG8jezxRPBPXg/By-hT10oh#Rocket-Pool-Spec).
- We favor the exchange rate method over rebasing considering ease-of-integration and avoiding wrapper tokens.
- Tracking Total Reserves
- Reserve Edge Case
- When keeping track of total reserves, the "transient" shares—shares that are queued for withdrawal but not yet completed—are removed from the staker-specific storage and the operator delegated shares aka `stakerStrategyShares` and `operatorShares`, but it is still slashable by an AVS.
- Therefore to maintain an accurate view of total reserves, should monitor
- `stakerStrategyShares` for the corresponding strategy and all `queuedWithdrawals` that belongs to the provider `staker` address.

**Pros**
- As there will be high amount of deposits tied to strategies, the LRT will have large fungible liquidity.

**Cons**
- The operators are technically free to change their AVS selections which makes risk/reward unpredictable.
- If an undesired AVS is being opted-into, provider has to withdraw and redelegate their shares.
- Requires active management when trying to silo risk into specific operators or certain AVS's.

### Method #2 - Strategy-Operator Pairs
TBD, needs more information to be fleshed out.
- LRT's specific to strategy-operator pairs.
- The LRT will be minted upon delegation to an operator, following a deposit into a strategy.
- Will be possible if stakers are able to earn rewards specific to their operator, not socialized across all strategy depositors. See outstanding questions.
- Risk will be isolated to the AVS's that the operator is opted into.

### Method #3 - Strategy-AVS Pairs
TBD, needs more information to be fleshed out.
- LRT's specific to strategy-AVS pairs.
- Similar to how there is stETH and stMatic for different chains, there would exist LRTs that are specific to strategies that are linked to specific AVS's
- This doesn't seem to be possible with the current Eigenlayer infrastructure as operators can opt into multiple AVS's with the same delegated shares.

### Outstanding Questions
- Questions surrounding how AVS's reward operators and how stakers earn.
- AVS rewards seem to be specific to operators, i.e. AVS will send tokens to well behaving operators.
- **Q: Then, do stakers who made smarter delegations earn more than other stakers in the same strategy who made different delegations?**
- If a staker delegated to a more effective operator, will this staker earn more or the same as all other strategy shareholders who may have delegated to less effective operators?
- Stakers "cash out" via `withdraw` which converts shares to underlying tokenholders based on total strategy shares and total underlying token balances.
- This conversion is uniform for all shareholders, regardless of my delegation.
- So when operators are paid,
- **Q: Are the part of the proceeds that belong to stakers are socialized across all common strategy depositors?**
- i.e. When operators earn rewards, the underlying token balance in a strategy goes up (with rewards) and shares remain unchanged. And all stakers in a strategy has a higher exchange rate.
- **Q: Or is a greater reward attributed to stakers who delegated to the operators that earned the rewards?**
- i.e. When operators are paid, the underlying token balance in a strategy goes up, and extra shares are minted to specific stakers who delegated to the operators who earned the rewards. Now the stakers who made smarter delegations diluted other shareholders for greater total redeemable value.
- Or a different method of accounting for delegation-specific rewards for stakers.