Introducing ether.fi
Acknowledgements
Many delegated staking solutions have been built before ether.fi. We owe a debt of gratitude to everyone who has been building in the space. They’ve inspired and motivated us.
We believe decentralized, non-custodial staking is an essential and foundational good for Ethereum. There is a need for a variety of solutions that serve many types of users and purposes.
We want to give particular shoutouts to the teams that built RocketPool, StakeWise, Diva and Lido. We are fans and have learned a lot from your work.
Principles
We take our ethics seriously and want the community to hold us accountable for living up to the following:
- Decentralization is a primary objective. We will never compromise on the non-custodial and decentralized nature of the protocol. Stakers must maintain control of their ETH.
- The ether.fi protocol is a real business with a sustainable revenue model. We’re in this for the long haul. We think and plan on the scale of decades. No ponzinomics f*ckery.
- We will do the right thing for the Ethereum community, always. If and when we mess up, we will own it and course correct quickly.
Executive summary
ether.fi is a decentralized, non-custodial delegated staking protocol with a Liquid Staking Derivative token. One of the distinguishing characteristics of ether.fi is that stakers control their keys. The ether.fi mechanism also allows for the creation of a node services marketplace where stakers and node operators can enroll nodes to provide infrastructure services and the revenue from these services is shared with stakers and node operators.
What makes ether.fi different
There are two main differentiators for ether.fi:
- Stakers generate and hold their own staked ETH keys.
- An NFT is minted for every validator that is launched via ether.fi.
With most other delegated staking protocols the starting point is that the staker deposits their ETH and is matched with a node operator, who generates and holds the staking credentials. Although this approach can be implemented such that the protocol is non-custodial, in practice in most cases it creates a mechanism that is custodial or semi-custodial. This can expose the staker to significant and opaque counterparty risk.
With ether.fi the staker controls their keys and retains custody of their ETH while delegating staking to a node operator. This significantly reduces their risk surface area.
The ether.fi mechanism mints an NFT for every validator that is launched via the protocol. The Liquid Staking Derivative token eETH is minted from a liquidity pool that contains these NFTs.
These NFTs control the 32 ETH staked and store metadata related to the validator — the client it runs, the geography it is in, the node operator, and any node services it is running. These NFTs can be used to create a programmable layer on top of staking infrastructure (made more powerful with integration with EigenLayer eventually.)
High-level operational summary
This section contains a high-level summary of ether.fi mechanisms. For a detailed description, please see the ether.fi whitepaper technical section.
There are several users and stakeholders on ether.fi:
- Stakers who are also bond-holders
- Stakers who only hold eETH, the ether.fi LSD (Liquid Staking Derivative)
- Node operators
- Node services users
There are 3 phases on the ether.fi roadmap:
- Delegated staking
- Liquidity pool
- Node services
In each phase, the roles above play evolving roles described briefly below.
Delegated Staking — Phase 1
In the case of stakers who wish to hold a bond and stake in multiples of 32 ETH, the workflow below is followed:
- A node operator submits a bid in order to be available to be assigned a validator node to run. Trusted node operators may submit a nominal bid to be marked as available. Trustless node operators participate in the auction mechanism and are assigned validators based on their winning bid.
- The staker deposits their 32 ETH into the ether.fi deposit contract. This triggers the auction mechanism and assigns a node operator to run the validator. This also mints a withdrawal safe and two NFTs (T-NFT, B-NFT) that confer ownership of the withdrawal safe. The T-NFT represents 30 ETH and is transferable. The B-NFT represents 2 ETH and is soulbound. The only way to recover the 2 ETH is for the validator to be exited or fully withdrawn.
- The staker encrypts the validator key using the public key of the winning node operator and submits it as an on-chain transaction. The transaction emits an event to which the node operator is listening. In future versions, this step will be replaced with a sharded key DVT based solution.
- The node operator launches the validator utilizing the decrypted validator key.
- The staker (or node operator) may submit the exit command to exit the validator and recover the staked ETH into the withdrawal safe. The staker can then burn the NFTs to recover their ETH net of fees.
The B-NFT is used to supply the deductible for slashing insurance (in case of a slashing event) and represents a responsibility to monitor the validator node for performance. It pays a boosted yield (approximately 50% higher) than the T-NFT due to the added risk and responsibility. ether.fi makes it easy to monitor validator performance via notifications and alerts.
Liquidity Pool and eETH — Phase 2
Stakers with less than 32 ETH, or stakers who don’t wish to take on the responsibility of monitoring validator nodes, can participate in ether.fi staking by minting eETH in the NFT liquidity pool.
The liquidity pool contract contains a mixture of assets consisting of ETH and T-NFTs (described above.) At any given time, ETH represents a small percentage of the pool assets.
Minting and burning eETH
When a staker deposits ETH into the pool, the pool mints eETH tokens and transfers them to the depositor. A staker who holds T-NFTs can deposit them into the liquidity pool and mint the eETH equivalent to the value of the T-NFT (determined via an oracle.)
A staker who holds eETH can swap it for ETH in the liquidity pool on a 1:1 basis, assuming sufficient liquidity. If there is insufficient liquidity, the swap triggers a validator exit.
Bond-holders and minting new T-NFTs and B-NFTs
Stakers who wish to specifically stake with B-NFTs (because of their higher yield) deposit their ETH into the pool and enter a queue to be allocated a B-NFT. These stakers are bond-holders, and perform a similar role as full-node stakers who have sold their T-NFT.
When the amount of ETH in the liquidity pool crosses above a threshold then the next bond-holder staker in the queue is assigned. They generate private keys and trigger the staking process where 32 ETH gets staked, and two nfts are minted: the T-NFT into the pool, and the B-NFT to the bond-holder.
Exiting validators
When the amount of ETH in the liquidity pool crosses below a threshold, then an exit request is triggered on the oldest T-NFT. This emits an event to which the bond-holder corresponding to that T-NFT must listen (ether.fi provides a free notification service to the bond-holders to make this easy).
This exit request records a timestamp and begins a timer. If the timer expires and the validator has not been exited then the B-NFT holder is slashed progressively. The node-operator receives a reward upon exit of an expired validator (in order to incentivize them to exit the validator in case the bond-holder is unwilling or unable to do so.)
Upon validator exit, the T-NFT and B-NFT are burned and the ETH (net of fees) is deposited into the liquidity pool.
Node Services — Phase 3
This is a speculative phase for the protocol, and many of the technical decisions have yet to be made. We’ll update this document as we iterate.
The NFTs, which represent the economic value of the staked ETH, allow for the creation of a programmable layer on staking infrastructure by creating economic incentives for node operators and stakers.
We plan to incorporate EigenLayer when we’re able as a mechanism to support our node services layer.
Enrolling nodes into services
NFTs can be enrolled to provide node services by setting metadata parameters that are part of the NFT contract.
In the initial implementation, the node operator must be running the ether.fi client bundle and be registered to provide node services.
All 3 parties must effectively consent to enroll any given node to provide additional services — the node operator, B-NFT holder, and ether.fi.
ether.fi node client
The node client bundle is an easy-to-use CLI that allows launching, monitoring, and registering clients on ether.fi.
Billing for services
Billing for node services is executed via a billing contract. Services tracking and attribution done via a centralized service run by ether.fi. This will change over time.
