Beyond LRTs: A Liquid AVS Token for directional restaking yield

TLDR

On EigenLayer, traders are two degrees removed from the AVSs that generate yield: Operators sit in the middle deciding which AVSs to run and how to allocate LSTs, dampening any directional view a trader might want to express. Liquid AVS Token (LAT) is a new primitive that unbundles AVS selection, per-AVS asset selection, and Operator switching. This turns generic blended restaking yield into a per-AVS yield curve that products like fixed yield, leveraged yield, and yield vaults can be built on.

Background

EigenLayer is a marketplace for any service (AVS) to “rent” crypto-economic guarantees on structured job execution from “Operators” (entities that perform the job execution and could get slashed if they break their guarantees) and “stakers” (users who put up the slashable stake in the form of LSTs*¹ to the Operators) without having to bootstrap the staking liquidity themselves. AVSs pay out rewards to Operators for their service, pro-rata to the stake that was put up. Operators in-turn distribute the rewards to the stakers after taking a cut, earning them a certain APY on the collected stake.

A few of us at Bless found EigenLayer very novel. As we explored the ecosystem, we maintained EigenExplorer, the most popular data service (explorer + API) for all EigenLayer on-chain data which served millions of requests a month. Ideas started brewing and I ended up leading the development of Liquid AVS Token (LAT)*².

Problem

Assuming a thriving universe of 100+ AVSs providing competitive yield, incentive campaigns, well-defined slashing conditions & supported by a large ecosystem of mature Operators, how might a trader of a given risk profile maximise their yield over a given time horizon?

We quickly realized that the protocol design of EigenLayer prevents a trader from truly expressing their market views because:

• Price signal (rewards) come from AVSs (and on a per-LST basis)

• Operators decide for themselves which AVSs to Operate and how much to allocate

• Traders can only perform one action, allocating to a single Operator

The trader being two-degrees away from from AVS selection, causes the following inefficiencies:

• The Operator’s expertise is in infra / devops, not yield optimization. Also, a given Operator must spend non-trivial resources to support and maintain a new AVS, so they won’t operate all AVSs. Hence, any alpha is severely dampened due Operator dependency.

• For a given AVS, yields can vary based on which LST is staked. Operators cannot influence LST allocation as they must directly restake the same token given to them by their users. Thus, uninformed stakers can dilute yield for all stakers.

• A trader cannot swiftly act on market information because switching between Operators incurs a 7-day exit period.

Without direct access to AVS selection, asset selection within an AVS, and quick switching between Operators, we felt that a new a primitive needed to be engineered, unbundling these three constraints.

The Idea

We designed Liquid AVS Token as a new primitive that accepts LSTs from users and restakes them to one single AVS, with active rebalancing to achieve the maximum possible yield from that AVS. A LAT is launched per AVS, per token group, for example:

• xEigenDA-ETH is a LAT that accepts ETH LSTs and restakes them towards EigenDA

• xARPA-BTC is a LAT that accepts BTC LSTs and restakes them towards ARPA Network

Since each LAT is token-grouped, its price is pegged to the underlying group (in this case ETH or BTC), allowing the trader to underwrite price exposure. The main additional risk taken by a LAT holder is slashing risk (the same as any generic EigenLayer staker).

The Difference from LRTs

• What the holder is expressing

An LRT holder is taking generic "restaking exposure" while a LAT holder is taking a directional view on one AVS's yield.

• Risk profile

LRT spreads slashing risk across (AVS, Operator) pairs while LAT concentrates slashing risk to (one target AVS, Operator) ie, additional slashing risk from the target AVS being adversarial or unsophisticated.

• New market potential

LRTs blend ecosystem-wide yield into a single number. A LAT world surfaces a per-AVS-yield curve that creates a market for products like fixed yield (like Pendle), trading yield with leverage, yield vaults, etc.

Finally, the 3 core design considerations we came down to were:

1. How can a LAT concentrate yield into a single AVS?

2. How can the manager optimize yield for a given LAT?

3. How do we accurately price the LAT in the case of a slashing event?

The Design

The LAT system comprises of on-chain contracts and an off-chain “Manager”:

• Set of smart contracts on Ethereum
• Assigned a target AVS on deployment.
• Accepts LST deposits in return for ERC20 LAT tokens and conversely, accepts burning LAT tokens for LSTs.
• Aware of its AUM and able to correctly price LAT for LST at the time of any deposit or withdrawal.
• Able to accurately act on instructions from the manager when requested to swap, stake or withdraw funds.
• Able to recoup funds from EigenLayer after the 7-day withdrawal period and makes sure they are available for re-allocation by the manager or isolated for a user’s withdrawal request.

Repo: liquid-avs-token

• Off-chain “Manager”
• Runs an indexer to pull and maintain data from 4 sources daily:
• LAT emitted events: Live state and state transitions for a given LAT’s contracts.
• EigenExplorer API: Operator metadata (total TVL, per-token TVL, AVS registrations), per-AVS-per-token APYs, and native EigenLayer incentive APYs.
• DefiLlama Yields API: Native staking yield APYs for LSTs which gets added on to APYs received from restaking.
• CoinMarketCap API: Token prices and major price deviation alerts.
• Runs an automated and deterministic rule engine with the goal of yield optimization to accurately instruct the LAT contracts on swap, stake and withdrawal actions

Repo: lat-backend

💡

The manager is a cause for centralization risk. Since it is automated and deterministic we planned to migrate it to a trustless setup (like EigenCompute) over time.

Concentrating yield into a single AVS for a given LAT

The LAT acts as a group of EigenLayer stakers, and hence has to delegate its stake to some combination of Operators. Hence this is an Operator selection problem with 2 possible strategies:

1. Find the optimal concentration path within the existing set of Operators on EigenLayer

Here, we accept the trade-off that it may not be possible to guarantee that all stake collected by the LAT will go to the target AVS and some portion it might leak into other AVSs. The optimal solution would be:

• For a given LST, rank the set of Operators in descending order of proportion of stake that would reach the target AVS
• Filter out Operators that do not meet some threshold criteria (trade AVS concentration for lower slashing risk)
• Diversify across the shortlisted top-n Operators and rebalance as rankings drift over time

2. Run our own set of Operators on EigenLayer, each dedicated to a single AVS

Here, we accept the overhead of running a full-scale Operator business along with the reputation stake against slashing, but enabling complete concentration of stake into target AVSs. If the “pure Operator” business is profitable enough, we’d see (and welcome) more pure Operators which would help decentralization over time. LAT ends playing the role of distribution funnel for pure Operators.

In the spirit of getting market feedback as soon as possible, we decided to kick off with 1 and transition to 2 over time.

This is how we designed Operator selection:

• For every day that an Operator that passes all three conditions accumulates daysInPreference and conversely accumulates daysInWarning for failing any condition. Warning days decrement one-per-day upon passing, and preference only begins accumulating once the warning fully clears, valuing consistency and long-term actors.

• For any given Operator that crosses the threshold of daysInPreference or daysInWarning a new “staker node” (smart contract controlled by the core LAT contracts) is spun up or down.
• Whitelist: Registers itself as a staker on EigenLayer pledging delegation toward the target Operator. This contract can now receive LSTs (from user deposits) from the core LAT contracts and stake to / withdraw from EigenLayer
• De-list: The staker node assigned to the target Operator “undelegates” from EigenLayer which causes it to withdraw all assets and its delegation from the Operator. The received funds are later transferred back to the core LAT contracts for re-use into other Operators.

threshold constants:
      MIN_DAYS_IN_PREF       = 3
      MAX_DAYS_IN_WARN_SEV3  = 7      
      MAX_DAYS_IN_WARN_SEV2  = 14     
      MAX_DAYS_IN_WARN_SEV1  = 21     

state per (Operator, LST) pair:
    daysInPreference                // incr if the pair passes conditions
    daysInWarning                   // incr if the pair fails any condition
    warningSev ∈ { None, 3, 2, 1 }
    bias                            // manual override to prefer an Operator

eligible_for_new_allocation(O, L):
    return  O.isDelegated
        AND (O.warningSev == None  OR  O.bias > 0)     // operator-level gate
        AND  pair.warningSev == None                   // pair-level gate
        AND (pair.daysInPreference >= MIN_DAYS_IN_PREF // earned via consistency
             OR is_lst_genesis(L))                     // OR first allocation
                
should_retire(pair):
    return  pair.daysInWarning > MAX_DAYS_IN_WARN_SEV1
        AND pair received no allocation this round     // if bias-revived

Optimizing yield for a given LAT

• Calculating APY

The indexer’s goal is to maintain a live feed of APYs for every (LST, Operator) pair. For a given LST L restaked through whitelisted Operator O, the predicted APY is calculated as:

APY(L, O) = LST_base(L) + EL_incentives(L) + (1 - fee(O)) * AVS_rewards(L)

Where:

• LST_base(L) = native staking APY for L, pulled from DefiLlama
• AVS_rewards(L) = AVS rewards APY, attributed to L (operator-invariant)
• EL_incentives(L) = EigenLayer's native incentives APY for L
• fee(O) = Operator's declared commission on AVS rewards, typically 10%.

This rate is what each (L, O) pair would earn on the next unit of stake at current TVLs.

 

When utilizing APY(L, O) to make stake allocation decisions, we consider the dilution that occurs as a mathematical consequence of the pair’s marginal TVL increase due to the allocation. Hence, for a given allocation x denominated in the unit of L , we calculate netAPY as:

netAPY(L, O, x_base) = LST_base(L) + EL_incentives(L)
                    + (1 - fee(O)) * AVS_rewards(L) * dilution(L, x_base)

dilution(L, x_base)  = TVL_base(L) / (TVL_base(L) + x_base + allocated_so_far_base)

💡

Due to dilution, the marginal APY drops as the LAT is allocated into a pair.

 

AVS_rewards can be calculated after making 2 considerations:

1. EigenLayer distinguishes between two types of stake allocated to an AVS, slashable and unslashable stake. For a given LST, the Operator can decide the proportion they wish to allocate to each.
💡

If an AVS’s slashable stake provides higher rewards than unslashable stake (which is most likely true in all cases), the manager will always choose opt-in to slashable stake as slashing risk is acceptable by default.

2. For a given token, AVSs release a certain amount of rewards for a given time period. The allocation of rewards is pro-rated to each staker to the amount and time they staked during the reward period. Since the rewards are released retrospectively without the AVS requiring to declare the amounts, one can only predict a token’s APY based on past patterns.
 

For a single reward submission s released against a given the slashable stake of LST L , say the AVS pays out amount of some reward token t over duration seconds, then that submission's annualized contribution to APY of (AVS, L) is:

rate(s) = (amount_t * price_base(t)) / TVL_base(L)  *  (seconds_in_year / duration_s)

AVS_rewards(L) is then the sum of rate(s) over every submission targeting L . Since all Operators are treated equally, we treat AVS_rewards(L) as operator-invariant.

• Optimizing APY

The net APY of a LAT at any given point in time is calculated as:

Let S(L, O) be the LAT's stake in pair (L, O), denominated in the LAT's unit of account (e.g., ETH for an ETH-grouped LAT). The LAT's blended APY at any point in time is the TVL-weighted average across all live allocations:

 
$$\mathrm{LAT\_APY} = \frac{\sum_{(L,O)} S(L,O)\,\mathrm{APY}(L,O)} {\sum_{(L,O)} S(L,O)}$$

The manager’s job is to allocate stake every 24 hours so as to maximize this value, adjusted for the following signals:

• Purity: the proportion of an Operator's total stake that actually reaches the target AVS. For eg: A high-APY allocation through an Operator with 10% purity leaks 90% of stake into other AVSs, defeating the LAT's premise.
• Bias: a manual override to forcibly keep an Operator in the candidate set (zero by default, positive to bypass warnings).
 

Hence, we introduce a scoring system on a per-(Operator, LST) level:

P(O, L)  =  0.10 * bias(O)
         +  0.45 * purity(O)
         +  0.45 * apyScore(L, O, x_base)

The manager needs to allocate new stake correctly whilst also re-balancing old stake if it has been underperforming over an unacceptable period of time. We achieve this by running the following algorithm every 24h, against the indexed snapshot:

Inputs

• W = whitelisted Operator/LST pairs

• (LST_base, EL_incentives, AVS_rewards, fee, purity, bias) per (Operator, LST)

• TVL_base(L) for each supported LST

• IDLE(L) = unstaked balance of L in the LAT’s LiquidToken contract

• pending user withdrawal requests on the LAT

• HELD(L, O) = current per-node staked positions on EigenLayer

Step 1: budget the LAT in base-asset terms

restakeableTvlBase = max(0, unstakedTvlBase - pendingUserWithdrawalsTvlBase)
quantum_base       = 1 ETH worth of base asset
steps              = ceil(restakeableTvlBase / quantum_base)

Idle LSTs already earmarked for in-flight user withdrawals are netted out at the top, so the rest of the workflow operates only on what's actually redeployable.

Step 2: Settle pending user withdrawals

Pay from IDLE first; the shortfall pulls from staked positions. To choose which staked positions to pull from, the manager runs the optimiser (see Step 3) and walks its output in ascending order of P, ie trims the lowest-quality pairs first. Queues the necessary withdrawals on EigenLayer per node.

Step 3: Stake the leftover budget into the best pairs

Tighter eligibility at this step:

• Operator: delegated, not in warning (or bias > 0)

• (Operator, LST) pair: cleared MIN_DAYS_IN_PREF = 3 (or lst-genesis)

Then a greedy quantum-by-quantum loop:

allocations = []
for i = 1 .. steps:
    bestPair = argmax over eligible (O, L) of  P(O, L | allocations)
    allocations.push({ bestPair, aTvlBase: quantum_base })

Because P depends on allocated_so_far_base via dilution, the best pair shifts as TVL piles into earlier winners and the loop naturally diversifies across pairs in proportion to their headroom, queuing DEX swaps if required.

Step 4: Roll the preference/warning state forward

For every eligible (Operator, LST) pair, the manager checks whether Step 3 actually allocated to it this round:

if got_no_allocation_this_round:
    daysInPreference = 0
    daysInWarning   += 1
    warningSev       = 3 if daysInWarning ≤ 7
                       2 if daysInWarning ≤ 14
                       1 if daysInWarning ≤ 21
                       retire  if daysInWarning > 21

else:                              // got an allocation
    if daysInWarning > 0:
        daysInWarning -= 1         // bleed off warning
    else if daysInPreference < MIN_DAYS_IN_PREF:
        daysInPreference += 1

Step 5: Retire sev1-overrun pairs.

For any pair whose daysInWarning > 21 and didn't sneak back into Step 3’s allocation (because of bias), queue a full withdrawal from the corresponding staker node and pulls the LSTs back to the LiquidToken contract for re-allocation next round.

Step 6: Emit all actions as multisig proposals

All actions are pre-defined tasks that take certain inputs and call certain functions on the LAT contracts. The final group of actions is proposed to the multisig by the manager at the daily rebalancing run.

Pricing a given LAT in the event of slashing

A “pricing event” takes place on every deposit or withdrawal by a user. We use standard ERC4626 vault math (formula for AUM against shares outstanding). The key difference is that AUM calculation involves a call to EigenLayer's DelegationManager.getWithdrawableShares (per staker node, per LST), which returns each node's post-slashing claim on the underlying asset.

The LAT is an ERC4626 share token. For any deposit or withdrawal:

shares_minted = amount_in_UOA * totalSupply / AUM
assets_returned = shares_burned  * AUM / totalSupply

Where the AUM is a sum across every supported token L, of three buckets, each converted to the LAT's unit of account at the oracle price P(L):

AUM = Σ_L  P(L) * [ idle(L) + queued(L) + withdrawable(L) ]

• idle(L) = unstaked balance of L sitting in the LAT contract

• queued(L) = balance of L in EigenLayer's withdrawal queue across all Staker Nodes

• withdrawable(L) = Post-slashing staked amounts EigenLayer across all Staker Nodes

In case of a slashing event, the next LAT pricing qualifies two invariants:

• Immediate awareness

The LAT must be informed of the slashing event on the first pricing event after the slashing transaction, and cause the price to weaken. The chosen data source in AUM calculation getWithdrawableShares returns the post-slashing amount. The slashed amount per node is the gap between what was deposited and what can still be withdrawn

strategy.shares(node) - withdrawableShares

• NAV-adjusted entry pricing

The slashing loss must be socialized only amongst existing depositors and not new ones. This is a natural mathematical consequence of the ERC4626 share price immediately weakening after a slashing event causing a new depositor to mint LAT at a lower price and an existing holder to burn LAT for a lower value of LSTs.

Refs:

• Repo (smart contracts): liquid-avs-token

• Repo (off-chain backend): lat-backend

• PR (Withdrawals design): Feat: Withdrawal Manager

*¹ EigenLayer also added support for accepting stake in the form of certain non-LSTs. A restaked token in EigenLayer terminology is “Strategy”. *² EigenLayer didn’t move in the direction we predicted (or perhaps its still too early) so we had to sunset the product (Area).