1. Intro
Earlier this year, we unveiled new use-cases for the SD token, making it front and center of the ETHx architecture and the broader Stader ecosystem.
Phase 1 of ETHx launch required a bond of 0.4 ETH worth of SD, and in the 4 months of mainnet, Stader has witnessed 1000+ validators being spun up by 180+ different permissionless Node Operators.
Today, we are unveiling Phase 2 details, which unlocks additional use-cases for SD holders and further reduces the barriers of entry for Node Operators into the Stader ecosystem and the broader Ethereum staking realm. These are slated to go live in the next few weeks, after gathering feedback from the community.
2. Executive Summary
Let’s explore the tokenomics and workflow of the SD Utility Pool, a feature designed to enhance the scalability of Stader’s permissionless pool. This feature allows Node Operators to maintain delta neutrality to SD, running nodes exclusively with ETH exposure. Simultaneously, it unlocks a new use-case for SD holders, enabling them to earn delegation fees.
In the Utility Pool:
- SD holders become SD Delegators after delegating their SD to the Utility pool.
- Node Operators use SD from the Utility pool to operate an ETHx validator, paying a utilization fee.
The fees paid by the Node Operators are put back into the SD Utility Pool, increasing SD Delegators’ holdings, i.e. generating returns for them. Simple and effective!
Utilization fee calculation
The fee on the utilized SD will accrue per block, adding to the existing utilized amount. Node operators can view their current Utilization position on the CLI or Grafana Dashboard.
The Utilization Fee will be set at a fixed percentage of the Utilized SD. Autocompounding will occur with every Utilization Pool activity (state change of the pool), and it will apply only to the accumulated fees. To simplify:
- A fixed percentage rate applies to the Utilized SD, and the Utilization fee per block is calculated initially.
- Auto-compounding occurs exclusively on the total Utilization fee during each pool state change.
Governance
These Utilization base rate will be determined through governance.
Delegation and Utilization limits
Delegation limit for each delegator
- Minimum: 1 SD
- Maximum: No Limit
Utility Pool global delegation limit - No Limit
Utilization limit for each Node Operator
- Minimum: 1 SD
- Maximum: 1 ETH worth of SD per validator
Accessibility for Node Operators
Node operators can easily utilize SD from the SD Utility Pool during their regular node operations on the CLI. Stader will create specific commands for SD Utilization, Repayment, and Utilization status check, among others.
Accessibility for SD Delegators
Stader will offer a straightforward UI similar to their staking UI format, enabling the delegator to delegate SD tokens into the Utility Pool, earn rewards, and withdraw as needed with a few simple clicks.
Liquidation and asset security
- For liquidation and asset security, we will be using the Health Factor as a parameter for SD Utilization. Whenever the Health Factor for a node is 1 or goes below 1, that node will be liquidated (exited) to recover the Utilized SD using the ETH deposit of the Node Operator.
- For robust safeguarding and enhanced asset security, we calculate the Health Factor based on a collateral value, which is half of the ETH deposit (e.g., for a node with one validator, we will consider a collateral value of 2 ETH, even though the node operators deposit 4 ETH.) Additionally, we consider a liquidation threshold of 70%.
- For node operators with an active Utilization position who decide to exit the node, a portion of their ETH deposit will be temporarily blocked until they repay their total utilization fee.
Slashing risk
In rare instances, ETHx Node Operators utilizing SD from the Utility Pool may face slashing. In this scenario, SD tokens from the pool can be used to offset the losses. However, in such rare cases, the ETH deposited by the node operators will take precedence to cover the slashing penalty, followed by their self-bonded SD collateral. Only after exhausting these options, the Utilized SD collateral will be used to address any remaining deficiencies.
3. SD Delegators UX Flow and specifications
UX Flow
We will offer a straightforward UI similar to our staking UI format, enabling them to delegate SD tokens in the Utility Pool, earn rewards, and withdraw as needed.
Delegate:
- Visit SD Utility Pool page.
- Connect wallet.
- Delegate SD tokens via the Delegate tab.
Withdraw:
- Visit SD Utility Pool page.
- Connect wallet.
- Initiate a withdrawal request using the Withdraw tab.
Claim:
- Visit SD Utility Pool page.
- Connect wallet.
- Claim tokens after withdrawal request has been processed via the Claim tab.
Reward Accrual
The utilization fee from the Node Operators will be added back to the Utility Pool, increasing the pool TVL. Once the utilization fee is added to the pool, the net position, i.e., SD Holdings of the Delegators, will increase. (SD Holdings = Delegated SD + Fee Earned for delegation)
Withdrawal and Cooldown Period
- Unbonding Period
After the request is processed, there will be an unbonding period of 7 days. Delegators need to wait for unbonding period after their withdrawal request is processed before they can claim their tokens.
- Withdrawal Limit
The withdrawal limit will be displayed to SD Delegators. The withdrawal limit is the maximum amount up to which Delegators can withdraw their SD from the pool without waiting in the queue. If a Delegator attempts to withdraw more than the withdrawal limit, they will be placed in a withdrawal queue.
4. Permissionless Node Operator UX Flow and specifications
Node operators can either completely self-bond, using their own SD for SD Collateral deposit, or fully utilize SD from the Utility Pool, paying a utilization fee. Alternatively, they can choose a mix of both—some parts self-bonded and some parts utilized from the Utility Pool.
Node operators can utilize a maximum of 1 ETH worth of SD per validator when adding a new validator or simply add extra SD collateral to earn SD rewards.
Utilization UX Flow while Creating a New Validator
During registration, node operators will be prompted to choose between two options:
- Deposit your own SD: Node operators will deposit their own SD and then ETH to add validators.
- Utilize SD from the Utility Pool: If the node operator chooses to utilize SD from the pool, the CLI will prompt them to enter the amount they would like to utilize; they can utilize a maximum of 1 ETH worth of SD per validator. After this, the CLI will check the limit and whether there is enough free SD in the Utility Pool.
- If yes, the node operator can create a validator using the utilized SD.
- If no, the node operator will be prompted that there is not enough SD in the pool, and they should try again after some time.
Utilization UX Flow for Top-ups
Existing Node Operators can also utilize SD from the Utility Pool to top up their current bonded SD collateral by running a command on the CLI. They can borrow a maximum of 1 ETH worth of SD per validator. There can be two cases here:
- Existing Utilization Position: If the SD already bonded as collateral is utilized from the pool, we will provide only the difference. If they have reached the maximum utilization capacity per validator, they won’t be able to utilize SD from the Utility Pool.
- Zero Utilization Position: If the node operator has initially bonded their own SD, they can utilize 1 ETH worth of SD per validator from the SD Utility Pool.
Rewards on SD Collateral
There is no change in the rewards computation and disbursement process. Even in the case of utilized SD, the rewards on the SD collateral will be received by the Node operators. If the SD collateral (self-bonded + utilized) falls below 10% for an operator, the node will stop accruing SD rewards.
SD Collateral Withdrawals
- Completely Self-Bonded SD collateral — Same as the current process. NOs can withdraw SD either when the collateral is above 200% or after exiting their validators.
- Completely Utilized SD collateral — NOs cannot withdraw the excess SD collateral above 200%. If the SD collateral is above 200%, then operators can move the excess SD back to the Utility pool, thereby repaying the utilized SD and reducing their position.
- Self-Bonded SD + Borrowed SD — If SD collateral (self-bonded + utilized) is above 200%, then operators will have to first move the excess SD back to the Utility pool, thereby repaying the utilized SD and reducing their position. If after closing the utilization position, there is still some excess SD, it can be claimed to the reward address.
Re-payment
Node operators can use the re-payment command to repay their utilized SD. They have the option to make a full repayment or a partial re-payment to reduce their utilization position.
Validator Exits
-
Completely Self-Bonded SD: Same as the current process.
-
Completely or Partially Utilized SD: The node operator can exit the validator. After the exit is processed on the beacon chain, the ETH deposit will be moved to the claim vault and blocked. However, the entire 4 ETH won’t be blocked; the node operator can still withdraw some part of their ETH deposit from the claim vault until the health factor is above 1. (Check the liquidation section for more details)
Process:
- The node operator will exit the validator.
- The 4 ETH & rewards will be collected in the claims vault and locked.
- The SD utilized by the node operator will be unlocked and moved to the lending pool.
- The node operator will be required to repay the utilization fee to the SD Utility Pool.
- After settling the fee payment, the ETH deposit will be unlocked, and the node operator will be able to claim it.
Liquidation flow
- For liquidation and asset security, we will be using the Health Factor as a parameter for SD Utilization. Whenever the Health Factor for a node is 1 or goes below 1, that node will be liquidated (exited) to recover the Utilized SD using the ETH deposit of the Node Operator.
- For robust safeguarding and enhanced asset security, we calculate the Health Factor based on a collateral value, which is half of the ETH deposit (e.g., for a node with one validator, we will consider a collateral value of 2 ETH, even though the node operators deposit 4 ETH.) Additionally, we consider a liquidation threshold of 70%.
- For node operators with an active Utilization position who decide to exit the node, a portion of their ETH deposit will be temporarily blocked until they repay their total utilization fee.
Case 1: A Node Operator exiting the node themselves
Assumption: The operator is running 1 node - 1 validator. The SD collateral is completely borrowed, and the Health factor is 1.5
In this case, after the exit, the ETH deposit of the node operator will be locked. However, the entire 4ETH won’t be locked; the node operator can still withdraw some part of their ETH deposit from the claim vault until the health factor is above 1.
So, in such a case, we will display two values on the CLI when node operators run the claim command:
-
The amount of ETH that they can currently claim.
-
The amount of SD they need to repay for closing the utilization position and claiming the remaining ETH.
Edge Case
- Initially the Health Factor was more than 1 and the NO exited. After that they started claiming ETH till the health factor was above 1. After sometime, the health factor drops below 1 - In such a case, liquidation will take place and the SD would be recovered using deposited ETH.
Note: The same logic will apply to a node operator with more than one validator. The greater the number of validators, the higher the collateral in the form of ETH deposit. The Health Factor will be calculated accordingly.
Case 2: A Node getting liquidated after the health factor drops to 1 or below 1
Assumption: The operator is running 1 node - 1 validator. The SD collateral is completely borrowed, and the Health factor is below 1.
In this case, the node can be liquidated by anyone; this will be a public function and can be called by anyone. For decentralization, the liquidation will not be initiated by Stader first; some other party can do this. However, if the node is not liquidated after a particular time period, then Stader will liquidate the node to safeguard the assets.
Any party or Stader, who liquidates this node, will first pay the Utilized SD on Node Operator’s behalf, and the same amount will be given back to the liquidator with some premium using the 4ETH deposit of the Node Operator, i.e. the liquidator will be incentivized to call the liquidity function. The amount of ETH left after closing the utilization position and paying the liquidation fee can be claimed by the node operator…
Note: The same logic will apply to a node operator with more than one validator. The greater the number of validators, the higher the collateral in the form of ETH deposit. The Health Factor will be calculated accordingly.
5. Conclusion
Stader’s ETHx tokenomics were designed to ensure Node Operators can participate in running validators for ETHx with the lowest bonding requirement and highest return possible (35% higher returns compared to solo-staking). The hundreds of individuals that have joined in the first 4 months of mainnet are a testament to the success of our approach.
Now, with Phase 2 of ETHx tokenomics, a new stride towards further decentralization by our ever-growing Stader family begins. We appeal to the Node Operator community to rally under the ETHx banner. Strengthening Ethereum is an endeavor well worth undertaking.
We would love to continue hearing feedback from the community on our tokenomics. Please share your thoughts here in the forum or in any of our communities across socials!
