Technical Documentation 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

Phase 1. [Deleg8] Delegate Staking

  • Release of Desktop App
  • Delegated staking via an auction mechanism
  • Withdrawals of the staking rewards and the unstaked ETH
  • Transferrable NFT (T-NFT) and Bond NFT (B-NFT)
  • protocol treasury contract

Phase 2: [Pool Fiesta] Liquidity Pool

  • Integration of Oracle for validator nodes information
  • Liquid Staking Derivative (LSD) token, eETH
  • Liquidity Pool to enable trades of {ETH, eETH, T-NFT}
  • protocol treasury management contract

Phase 3: [Boost] Node Services

  • Release of node client
  • Integration of Distributed Validator Technology
  • infrastructure services
  • infrastructure service billing contract

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 infrastructure service providers and run the node client
  • Infrastructure Services Users
    • use infrastructure services: RPC endpoints, Custom APIs, Dedicated nodes

Validator Keys


"Stake your ETH and retain complete control over your funds with" 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.
Figure 1. Secure exchange of validator key from Staker to Node Operator. 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, plans to further enhance security and improve the user experience by leveraging the EIP-5630 or sharded keys with Distributed Validator Technology (DVT). Desktop Application 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 desktop application is a React app running in Electron. It uses the official version of the eth2.0-deposit-cli tool without modification to generate validator keys. For secure encryption/decryption, it uses the ECIES encryption scheme.
With the 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. Node Client

The 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 Node Client with staking clients, node operators can significantly increase their revenue streams within the ecosystem.
Through Node Client, Node operators can:
  • Run validator nodes
  • Monitor validator nodes
  • Powering and Ethereum's distributed infrastructure with RPC endpoints, Custom On-Chain Data APIs, and Dedicated nodes
You can find the detailed guide here. Protocol Design Smart Contracts, upon deployment to mainnet, will be fully open-sourced and audited.


Through 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's liquid staking derivative token, eETH
  • All participants can trade their {ETH, eETH, T-NFT} in the 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

Figure 2: Process of's Delegated Staking via Auction.
The Auction Contracts play a crucial role in the 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, 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 ecosystem in the form of's rebasing token eETH. Upon the confirmation transaction for accepting the validator, the node operator receives a predetermined amount of eETH proportional to their bid.


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.
In the case of a slashing event, insurance is arranged to cover the loss of the T-NFT holder. The B-NFT’s 0.5 ETH is used to pay the deductible for the insurance, which covers the loss of the T-NFT holder up to 6 ETH.

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'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 8 ETH. 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 8 ETH. If the balance goes above 8 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 8 ETH in your withdrawal safe?
  • Case 1. The amount of the accrued rewards are above 8 ETH. Assuming a 5% APR, it takes 5 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 8 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. 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, the insurance is arranged using the 0.5 ETH of the B-NFT holder as the deductible to cover the loss of the T-NFT holder up to 6 ETH. The insurance payout to the T-NFT holder is manually processed by the protocol monthly.
What if your withdraw safe contract has more than 8 ETH while the validator node is still active? This is possible if someone sends their ETH to your contract. Even in this case, our smart contracts perform the transfers of the funds as in here, but there will be no insurance payout.


eETH is's liquid staking derivative token. eETH is a rebasable ERC-20 token. The eETH token represents a claim on the same amount of ETH which is held by the 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 protocol.
The eETH balance of an account is computed as follows:
BalanceOf(account)=TotalPooledEthShares[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,'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 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: liquidity pool allows anyone with 2 ETH to join 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'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 web app or they can use our 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.


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 smart contracts do not have the access to the status and balance of validator nodes. collaborates with the Rated.Oracle team for the secure and reliable on-chain delivery of the validator nodes data to the smart contracts.
The Oracle report is necessary to rebase eETH token balance. The report occurs daily based on the first finalized epoch after 00:00 UTC. The process takes snapshots of the consensus layer state and the execution layer and scans all of the validator nodes registered in 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).

Sharing Protocol Revenue shares its protocol revenue equally across the associated parties of the validator nodes in its ecosystem. Through Phase 1, 2 and 3, adds various sources of the revenue to the ecosystem: the auction fee revenue, the liquidity pool trading fee revenue and the infrastructure service revenue.
All revenues are directed into the protocol's smart contract. For gas-efficient revenue sharing operations, we implement the rebasing mechanism on calculating the participants rewards and the pull-based rewards claim mechanism.
Whenever a new revenue is streamed into the protocol contract, the Protocol Revenue Index is incremented by (Amount of the incoming revenue) / (Number of validator nodes). When a new validator node is registered through the auction, the corresponding withdrawal safe contract copies the value of the Protocol Revenue Index at the moment into its contract state called the Local Revenue Index. The claimable reward for the withdrawal safe contract is computed as (Protocol Revenue Index - Local Revenue Index). When the rewards are claimed, it updates the value of the Local Revenue Index to that of the Protocol Revenue Index.
Last modified 1mo ago