Technical Documentation

ether.fi is a - truly - non-custodial and decentralized staking protocol where stakeholders retain complete control of their assets while leveraging the power of permissionless decentralization. Our protocol provides a secure and seamless delegated staking service while offering higher returns and fewer costs through innovative revenue streams and aggressive operational efficiency optimizations.

Project Roadmap

(DONE) Phase 1. [Deleg8] Delegate Staking

  • Release of ether.fi Desktop App

  • Delegated staking via an auction mechanism

  • Withdrawals of the staking rewards and the unstaked ETH

  • ether.fi Transferrable NFT (T-NFT) and Bond NFT (B-NFT)

  • ether.fi protocol treasury contract

(DONE) Phase 2: [Pool Fiesta] Liquify Staked ETH on eETH Pool

  • Integration of Oracle for validator nodes information

  • Integration with EigenLayer's ReStaking

  • ether.fi Liquid ReStaking Token (LRT) token, eETH and weETH

  • ether.fi protocol treasury management contract

  • DeFi integrations

(WIP) Phase 3: [Permission-less] Node Staking

  • Integration of Distributed Validator Technology

  • Integration with EigenLayer's AVS

  • Add the permissioned DVT validators

  • ether.fi permission-less node staking

  • ether.fi node client

User Roles

  • Stakers and B-NFT (Bond) Holders

    • stake multiples of 32 ETHs

    • manage validator keys, perform monitoring duties of their validator nodes, receive higher yields

  • Stakers in eETH

    • stake less than 32 ETH

    • don't want the technical responsibility of monitoring nodes

  • Node Operators

    • participate in staking auctions and run the validator nodes

    • may join as ether.fi infrastructure service providers and run the ether.fi node client

Validator Keys

Ownership

"Stake your ETH and retain complete control over your funds with ether.fi."

ether.fi is a delegated staking service that distinguishes itself from others, such as Rocket Pool and Lido, by giving stakers complete control over their validator keys. These keys are necessary and sufficient to trigger the exit of validator nodes. We employ the T-NFT and B-NFT, representing the claims on the staked ETH. While the T-NFT is transferable for liquidation to ETH or eETH, the B-NFT is bound to the person who generates and retains the validator key. The B-NFT represents the ownership of the validator keys, and the B-NFT holder is responsible for exiting the node when necessary. In exchange for the additional responsibility, the B-NFT holder earns 50 % higher yield than the T-NFT and eETH holders.

Secure Transfer to Node Operators

For a node operator to run the validator node on behalf of the staker, they must have access to the staker's validator keys. That is, the validator keys generated by the stakers should be shared with the corresponding node operator. However, if the validator keys are compromised, the validator nodes are exposed to slashing attacks and potential losses.

ether.fi uses a secure and unique implementation of ECIES for the stakers to share the validator keys while retaining control of them. Figure 1 depicts the overall process. Before a node operator can participate in the auction, they must generate ECC keypairs and register their public keys. The stakers generate their validator keys and encrypt them via a shared secret generated using the node operator public key associated with the winning bid. To ensure forward secrecy, the node operator can make one bid for each public key they register. The encrypted message can be decrypted only by the private key of the corresponding public key. The encrypted message is submitted as an on-chain transaction for the node operator to locate, obtain, and decrypt the keys for running the validator nodes.

For cost efficiency, we use off-chain IPFS storage for key exchange. Node operators store their public keys on IPFS. Similarly, stakers store their encrypted validator keys on IPFS. Their hashes of the IPFS storage are uploaded on-chain.

A shared validator key, while an improvement for most stakers, remains unsatisfactory. In the future, ether.fi plans to further enhance security and improve the user experience by leveraging the EIP-5630 or sharded keys with Distributed Validator Technology (DVT).

ether.fi Desktop Application

ether.fi provides a user-friendly GUI desktop application for secure key management. Upon deployment to mainnet, it will be a fully open-sourced here: etherfi-desktop. The ether.fi desktop application is a React app running in Electron. It uses the official version of the eth2.0-deposit-cli tool to generate validator keys. For secure encryption/decryption, it uses the ECIES encryption scheme.

With the ether.fi Desktop Application:

  • Node operators generate their public/private keys

  • Stakers generate their validator keys

  • Stakers encrypt the validator keys with the public key of their matched node operators

  • Node operators decrypt the encrypted validator keys with their private keys

You can find the detailed guide here.

ether.fi Node Client

The ether.fi Node Client offers a seamless setup process for running validator nodes. Furthermore, it provides exceptional opportunities for node operators to enhance their earnings. By combining the ether.fi Node Client with staking clients, node operators can significantly increase their revenue streams within the ether.fi ecosystem.

Through ether.fi Node Client, Node operators can:

  • Run validator nodes

  • Monitor validator nodes

  • Powering ether.fi and Ethereum's distributed infrastructure with RPC endpoints, Custom On-Chain Data APIs, and Dedicated nodes

You can find the detailed guide here.

ether.fi Protocol Design

ether.fi Smart Contracts, upon deployment to mainnet, will be fully open-sourced and audited.

Overview

Through ether.fi smart contracts:

  • Node operators can register their public keys to be used by stakers to encrypt their validator keys

  • Node operators participate bid to operate validator nodes

  • Stakers deposit 32 ETH and nominate the winning node operator with the highest bid

  • Stakers submit the encrypted validator key to be shared with the corresponding node operator

  • Node operators accept their winning bids, triggering the deposit of 32 ETH into the Ethereum Deposit Contract

  • Holders of the {B, T}-NFTs skim their rewards

  • Holders of the T-NFTs send exit requests to corresponding holders of B-NFTs

  • Stakers can stake their ETH and receive ether.fi's liquid staking derivative token, eETH

  • All participants can trade their {ETH, eETH, T-NFT} in the ether.fi liquidity pool

  • Any individual can trigger the redistribution of the withdrawn funds from the withdrawal safe contract to the associated parties.

Detailed Mechanisms

Delegated Staking via Auction

The Auction Contracts play a crucial role in the ether.fi system by conducting auctions and managing bids from node operators. The purpose of these auctions is to determine which operator will be granted the rights to run a validator node.

After registering their public keys, the node operator places a Bid in ETH (e.g., 0.01 ETH). The auction revenue is shared across protocol participants.

Then, when a staker deposits 32 ETH into the Auction Deposit Contract, it triggers the Auction Manager Contract to run the auction and identify the winning bid and corresponding operator. In the future, ether.fi aims to allow stakers to select their preferred node operator.

The process continues with the staker generating and submitting encrypted validator keys through an on-chain transaction. For cost efficiency, the stakers store the encrypted validator keys into IPFS and upload its CID on-chain for the node operator to locate, download the keys, and decrypt.

Finally, the node operator sends the acceptance confirmation transaction to the Auction Manager Contract, which mints the {B, T}-NFTs to the staker's wallet and creates a new instance of the Withdraw Safe Contract. The 32 ETH is then transferred to the official Ethereum Deposit Contract using the withdraw safe contract as the withdraw credentials. Upon the completion of the validator node setup by the node operator and the activation of the validator node, the validator node begins earning rewards.

The collected fees from the auction are shared within the ether.fi ecosystem in the form of ether.fi's rebasing token eETH. Upon the confirmation transaction for accepting the validator, the node operator receives a predetermined amount of ETH proportional to their bid.

T-NFT and B-NFT

Upon the creation of a validator node, the staker receives both T-NFT and B-NFT. While the T-NFT is transferable, the B-NFT is soul-bound to the staker (not transferable.)

The {B, T}-NFTs are implemented based on the ERC 721 standard. The {B, T}-NFTs contain metadata about the validator node's {index, status, performance}, node operator, and so on.

The T-NFT and B-NFT represent claims of 30 ETH and 2 ETH, respectively, for the withdrawn funds upon the validator node's exit. That is, the staker can liquify 93.75% (= 30/32) of their staking position. Here, because the staker retains control of the validator key, the B-NFT acts as insurance against slashing as well as a commitment to exit the validator node upon request from the T-NFT holder.

The T-NFT holder can send the exit request to the corresponding B-NFT holder. If the B-NFT holder does not honor an exit request, their ETH claims get penalized until they exit the validator node, and the node operator is incentivized to exit the node instead. The penalty levied results in a daily decrease of 3% from the 1 ETH claim among 2 ETH. In exchange for the additional responsibility, the B-NFT holder earns a 50 % higher yield than the T-NFT holder. The B-NFT holder is responsible for monitoring the validator node for performance as well. In the case of a slashing event, the B-NFT is used to supply the deductible for slashing insurance.

Permissionless Withdrawals

After the Shanghai upgrade for the Ethereum Execution Layer and the Capella upgrade for Consensus Layer, EIP-4895 will enable withdrawals of staked ETH and validator rewards.

There will be two types of withdrawals: Partial withdrawals for rewards skimming and Full withdrawals for unstaking. For partial withdrawals, the validator node's balance in excess of 32 ETH (earned rewards) is pushed to the withdrawal address while the validator node continues to earn staking rewards. For full withdrawals, once the validator is exited, the entire balance (32 ETH principal + rewards) is withdrawn.

With ether.fi's permissionless design, without any intermediaries:

  • The B-NFT holder can exit the validator node

  • The T-NFT holder can send the exit request to the B-NFT holder

  • The node operator is incentivized to exit the validator node if the B-NFT holder does not serve the exit request

  • Anytime, any party can trigger the redistribution of the partially withdrawn (skimmed) rewards or the fully withdrawn (unstaked) funds to the interested parties (node operator, NFT holders)

Rewards Skimming

TLDR; without any delayed approval from the 3rd parties such as the Protocol or the Oracle, you can skim your rewards from your withdraw safe contract as long as the balance in your withdraw safe contract is below 16 ETH.

ether.fi supports the permission-less and oracle-less rewards skimming, which leads to lower operational costs and a seamless user experience. In addition, we've aggressively optimized on our smart contracts to minimize the gas cost for batch-processing of rewards skimming.

The only condition for successful rewards skimming is that the balance of the withdraw safe contract should be below 16 ETH. If the balance goes above 16 ETH, you cannot perform skimming rewards and you are encouraged to exit the node and withdraw the full funds.

When will you have more than 16 ETH in your withdrawal safe?

  • Case 1. The amount of the accrued rewards are above 16 ETH. Assuming a 5% APR, it takes 10 years. We believe you are glad to exit the node, take the profits, and restart the staking.

  • Case 2. Someone donated their ETH to your withdrawal safe contract. We believe you are glad to take the donation and use it for good.

Full Withdrawal

If the balance of your withdrawal safe contract is above 16 ETH, you are encouraged to exit the node and to trigger the full withdrawal process.

Once your request for exiting the validator node is fully processed, you will receive your unstaked ETH (between 16 ETH and 32 ETH) into your withdrawal safe contract. Then, any individual can trigger the redistribution of the unstaked ETH to the associated parties.

ether.fi supports the permission-less and oracle-less withdrawal of the unstaked ETH. The payouts to the individuals are calculated based on the balance of the withdrawal safe contract. Please refer to here for the details.

As explained in [T-NFT and B-NFT], in the case of a slashing event, 1 ETH of the B-NFT holder is used to cover the loss of the T-NFT holder. In the upcoming protocol upgrade, the entire 2 ETH of B-NFT bond will be used to cover the loss.

eETH

eETH is ether.fi's liquid staking token. eETH is a rebasing ERC-20 token. The eETH token represents a claim on the same amount of ETH which is held by the ether.fi liquidity pool or being staked earning rewards within the Ethereum Proof-of-Stake system. The staking rewards are distributed to the eETH holders by the rebasing mechanism where its balance is updated automatically on all the addresses. The rebase mechanism is implemented via shares where the share represents the eETH holder's share in the total amount of ether controlled by the ether.fi protocol.

The eETH balance of an account is computed as follows:

BalanceOf(account)=TotalPooledEthāˆ—Shares[account]TotalShares BalanceOf(account) = TotalPooledEth * \frac {Shares[account]}{TotalShares}

- TotalPooledEth = the total amount of ETH controlled by the protocol - Shares[account] = the account's share of eETH - TotalShares = the total shares of eETH

Here, TotalPooledEth = (D + P + R) as reported by the Oracle: -D = the total ETH deposits in the liquidity pool -P = the total ETH claims on principals for the T-NFTs in the liquidity pool -R = the total ETH claims on rewards for the T-NFTs in the liquidity pool

Liquidity Pool

While being a place where all participants can swap their {ETH, eETH, T-NFT} in exchange for another, ether.fi's liquidity pool also plays crucial roles in powering the protocol's economics: minting/burning of eETH, minting of the T-NFTs with the delegated staking and burning of the T-NFTs for liquidation.

Minting/Burning eETH : The stakers with less than 32 ETH, or simply stakers who don't want to take on the responsibility as the B-NFT holder, can participate in ether.fi staking by depositing their ETH and minting eETH. The eETH staker can burn their eETH and receive ETH, assuming there is sufficient liquidity. If there is insufficient liquidity, it triggers a full withdrawal (i.e. exit) from the validator node associated with the oldest T-NFT.

What happens with the ETH deposited into the liquidity pool?

Minting T-NFT: ether.fi liquidity pool allows anyone with 2 ETH to join ether.fi staking as a B-NFT holder. The B-NFT staker's 2 ETH is combined with 30 ETH from the liquidity pool in the auction. In this, the created T-NFT is handed over to ether.fi's liquidity pool to ensure that the minted eETH tokens are properly backed by the staked ETH and accrued rewards. At this point, a keen reader may come up with the idea of holding multiple B-NFTs with higher yields instead of the T-NFTs. Yes! anyone can be the B-NFT accumulator. Of course, the greater yields come with greater responsibilities; securely managing the validator keys and honorably exiting the nodes upon the requests from the T-NFT holders as explained here.

What if everyone wants to become the B-NFT accumulator? Then, each individual is queued and is granted the opportunity when there is sufficient ETH in the liquidity pool. If they do not respond within a day, the next candidate can take the chance. In the future, we may run an auction for this process as well.

Under sudden increasing demands for swapping eETH for ETH, the liquidity pool can lack ETH liquidity because the ETHs are locked in validator nodes associated with the T-NFTs in the liquidity pool.

Burning T-NFT: When the amount of ETH in the liquidity pool goes below a threshold, an exit request transaction is triggered on the oldest T-NFT in the pool. It records the timestamp and begins a timer emitting an event to which the B-NFT holder corresponding to that T-NFT must listen. For notification, users can register their emails in the ether.fi web app or they can use our ether.fi telegram bot. 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 the expired validator in order to incentivize them to exit the validator in case the B-NFT holder is unwilling or unable to do so. Upon the validator exit, the T-NFT and B-NFT are burnt and the withdrawn ETH is deposited into the liquidity pool. The execution of the withdrawal is as described here.

Oracle

Ether.fi utilizes the decentralized oracle set of eOracle to add security and robustness to its operations.

In Ethereum, the execution layer where the smart contracts are running cannot communicate with the consensus layer where the Proof-Of-Stake happens and the data on the validator nodes reside. Therefore, the ether.fi smart contracts do not have the access to the status and balance of validator nodes. ether.fi initiates the hash-consensus Oracle network and collaborates with the external teams to make it robust and decentralized for the secure and reliable on-chain delivery of the validator nodes data to the ether.fi smart contracts.

The Oracle report is necessary to rebase eETH token balance. The report occurs at least once daily. The process takes snapshots of the consensus layer state and the execution layer and scans all of the validator nodes registered in ether.fi protocol smart contract. Given the snapshots, based on the balances of the withdrawal safe contracts and the validator nodes, it calculates the total amount of ETH staked and accrued for the validator nodes and reports them on-chain.

In the future, the dependency on the Oracle can be removed once the required infrastructure is added to Ethereum (e.g., EIP-4788, EIP-7002).

Sharing Protocol Revenue

ether.fi shares its protocol revenue equally across the associated parties in its ecosystem. Through Phase 1, 2 and 3, ether.fi adds various sources of the revenue to the ecosystem. Examples are the auction fee revenue, the liquidity pool trading fee revenue and the infrastructure service revenue.

Currently, the auction revenue being shared to the ether.fan holders increasing the overall APRs.

Last updated