Skip to main content

yETH

yETH is a user-governed liquidity pool token consisting of various Ethereum Liquid Staking Derivatives (LSTs).

The yETH protocol is an Automated Market Maker (AMM) for LSTs. Each LST in the yETH pool is priced according to the amount of beacon chain ETH it represents. This lets users deposit their LSTs into the pool and receive yETH tokens pegged 1:1 with beacon chain ETH. Users can also stake their yETH tokens to mint st-yETH, accrue yield, and participate in yETH governance.

This AMM model, combined with the governance and incentive mechanisms of the yETH protocol, aims to provide an optimal risk-adjusted yield for ETH staking by dynamically adjusting the weights of the LSTs in the pool. It also offers users flexibility with single-sided deposits and withdrawals, and maintains the pool's balance and diversification through a weight management system.

The yETH protocol is governed by its users who can vote to adjust the weights of the LSTs in the pool, helping to maximize yield and mitigate risks associated with individual LSTs.

All yields generated by yETH go to Staked yETH (st-yETH) holders, making yETH an ideal token for Liquidity Providing in stableswap pools like those on Curve. To acquire yETH, users can mint yETH by depositing LSTs or swap against the yETH/ETH Curve pool.

Staked yETH (st-yETH)

Users stake their yETH to mint st-yETH, accrue yield, and later unstake st-yETH to receive yETH back according to their earnings. Stakers receive all yield and slashings from the beacon chain (Ethereum proof-of-stake validators) and earn incentives if they participate and vote in yETH governance.

By bundling LSTs, st-yETH aims to generate the best risk-adjusted yield from ETH staking. Through protocol governance, st-yETH users can readjust pool weights to maximize yield while mitigating catastrophic scenarios where one or several LSTs in the yETH composition suffer adverse events like de-pegging or security incidents.

st-yETH user vote weight

Each user has an internal vote weight that increases asymptotically to the user's share count. After t seconds, their vote weight is s * t / (t + t_half) where s is the number of shares and t_half is the voting half-time.

The voting half-time variable determines the time it takes until half the voting weight is reached for a staker. You can find the current voting half-time on Etherscan in seconds. Thus the wait to get to half of your st-yETH voting power is 60 days.

The user's external vote weight equals the internal vote weight at the end of the previous week.

Pool Weights for each LST

In yETH, each Liquid Staking Derivative (LST) has an assigned weight representing its proportion in the pool. The weight management system ensures that the pool remains diversified and balanced. As an LST performs well or gains popularity, its weight in the pool may increase, attracting more liquidity and providing better returns. Conversely, if an LST underperforms or faces issues, its weight may decrease, reducing its impact on the overall pool performance. This dynamic adjustment helps maintain an optimal risk-adjusted yield for yETH users.

For each epoch, users can vote to adjust the weights of the LSTs in the pool. The voting process also involves a "do nothing" option, allowing the current weight distribution to remain unchanged. If a new LST is added during the voting process, it starts at 0% weight and gradually increases to 1% in the first epoch. In the subsequent epoch, they participate like all other LSTs.

Example

Suppose we have four LSTs: A, B, C, and D with weights 10%, 20%, 30%, and 40% respectively in epoch n. For the next epoch (n+1), C has incentives worth $100.

The voting outcome for epoch n+1 is:

  • Do nothing: 30%
  • A: 7%
  • B: 10%
  • C: 43%
  • D: 10%

Here's how the voting outcome affects the weights:

  1. The "do nothing" vote is distributed to the current weight, reducing the total redistribution to 7%.
  2. The incentives for voting are distributed only to those who explicitly voted for a particular LST, making the incentive system more effective.
  3. If a new LST, say E, is added during the voting process, they start at 0% weight and do not fight for the 7% redistribution. They are gradually increased to 1% in the first epoch. In the next epoch, they participate like all other LSTs.

Single-Sided Deposits and Withdrawals

Single-sided deposits and withdrawals allow users to add or remove a specific asset from the pool. This differs from balanced operations where users deposit or withdraw a proportionate amount of all assets in the pool. Single-sided operations can be more convenient but may also incur bonuses or penalties.

Single-Sided Deposits

When a user makes a single-sided deposit, they add a specific amount of one asset to the pool. The system calculates the equivalent amount of yETH tokens to mint based on the current rate of the deposited asset.

However, single-sided deposits can distort the balance of assets in the pool. The system applies a deposit penalty if the deposited asset's weight increases above its target weight due to the deposit. This penalty reduces the amount of yETH tokens minted for the depositor, making the deposit operation more expensive. The penalty serves as an incentive for users to maintain the balance of assets in the pool.

Conversely, the system applies a deposit bonus if the deposited asset's weight is below its target weight. This bonus increases the yETH tokens minted for the depositor, making the deposit operation cheaper. The bonus serves as an incentive for users to restore the balance of assets in the pool.

Single-Sided Withdrawals

Users who make a single-sided withdrawal burn a specific amount of yETH tokens to withdraw one asset from the pool. The system calculates the amount of the asset to send based on the current rate.

Like single-sided deposits, single-sided withdrawals can also distort the balance of assets in the pool. If the withdrawn asset's weight decreases below its target weight due to the withdrawal, the system applies a withdrawal penalty. This penalty reduces the amount of the asset sent to the withdrawer, making the withdrawal operation more expensive.

Conversely, the system applies a withdrawal bonus if the withdrawn asset's weight exceeds its target weight. This bonus increases the amount of the asset sent to the withdrawer, effectively making the withdrawal operation cheaper.

Examples

Let's consider a pool with two assets, A and B, with a target weight of 50%. Due to market fluctuations, the current weights are 60% for A and 40% for B.

  • If a user deposits asset A, they will incur a deposit penalty because the deposit increases the weight of A above its target weight. The system will mint fewer yETH tokens for the depositor than the rate would suggest.
  • If a user deposits asset B, they will receive a deposit bonus because the deposit brings the weight of B closer to its target weight. The system will mint more yETH tokens for the depositor than the rate would suggest.
  • If a user withdraws asset A, they will receive a withdrawal bonus because the withdrawal brings the weight of A closer to its target weight. The system will send more asset A to the withdrawer than the rate would suggest.
  • If a user withdraws asset B, they will incur a withdrawal penalty because the withdrawal decreases the weight of B below its target weight. The system will send less asset B to the withdrawer than the rate would suggest.

For a deeper dive into the math behind the calculation of yETH weighted stable swap check this paper: https://github.com/yearn/yETH/blob/main/whitepaper/derivation.pdf

Contracts & Roles

NameAddress
yETH0x1BED97CBC3c24A4fb5C069C6E311a967386131f7
st-yETH0x583019fF0f430721aDa9cfb4fac8F06cA104d0B4
Management0xbBBBBbbB6B942883EAd4976882C99201108c784d
Protocol Owned Liquidity0x929401e30Aab6bd648dEf2d30FF44952BaB04478
Bootstrap: Deposit, Vote, Claim Incentives0x41B994C192183793bB9cc35bAAb8bD9C6885c6bf
Bootstrap: Claim st-yETH0x7cf484D9d16BA26aB3bCdc8EC4a73aC50136d491
Guardian0xDC775e813cDB38a4f02c4BAd3942319088018eFA
Pool0x0Ca1bd1301191576Bea9b9afCFD4649dD1Ba6822
Rate Providers0x90cfBe0fCccfbd6F895E3b065Aa45C56B635903B

Due to a redeploy of st-yETH during the bootstrap process the first st-yETH contract has been deprecated, use the Bootstrap: Claim st-yETH contract to claim the new version if you participated in the bootstrap phase.

Deprecated Contract Addresses


These contracts were deprecated when mevETH was removed from yETH.

NameAddress
Deprecated Pool0x2cced4ffA804ADbe1269cDFc22D7904471aBdE63
Deprecated Rate Providers0x4e322aeAf355dFf8fb9Fd5D18F3D87667E8f8316

Management Role

Trusted addresses with privileged access for limited operations. Should eventually be replaced by a smart contract:

  • Can start a gradual weight change, as long as no weight change is active yet.
  • Can whitelist a new asset, which sets an initial weight, sets the rate provider, and requires an initial deposit. New assets can only be whitelisted if no weight change has been scheduled yet.
  • Can update the rate provider for every whitelisted asset.
  • Can approve rate increases above 10%.
  • Can update the staking contract.
  • Can set the pool swap fee.
  • Can set the tolerance range.
  • Can set the new management address.
  • Can set the new guardian addresses.
  • Can trigger pause mode.
  • Can trigger killed mode.

Pause mode

This mode is to be activated in the event of extreme market conditions or detected suspicious behavior, either in the protocol itself or in the underlying LST tokens that back it.

  • No user may swap assets with the contract.
  • No user may deposit assets into the contract.
  • Users may only withdraw assets in a balanced manner, single-sided withdrawals are not allowed.
  • Weights, rates, and rate providers cannot be updated during this mode.
  • Management or guardian can undo pause mode to resume normal operation.

Killed mode

This mode is to be activated in the event of critical failures, whether in the protocol itself or in any of the underlying LST tokens that back it. This can also be used to migrate to a new version of the yETH protocol.

  • No user may deposit assets into the contract.
  • Users may only withdraw assets in a balanced manner.
  • The reward controller may not update the beacon chain amounts.
  • Pause mode may not be undone.

There is no way to undo killed mode.

Guardian Role

Trusted addresses with emergency privileges:

  • Can trigger pause mode.

Protocol Specs