ZENIP: 42404 Delegated Staking Reward Mechanism on EON

Governance
1

Preamble

ZenIp: 42404

Title: “Delegated Staking Reward Mechanism on EON”

Owner: Domenico Cusumano, dcusumano@horizenlabs.io

Idea Discussion: New ZenIP - Delegated Staking on EON

Status: Draft

Type: Technical

Created: April 12th 2024

Abstract

Horizen EON network is Proof of Stake, and already has a large quantity of ZEN providing security through staking to the EON forger nodes. In version 1.4 of Horizen EON, it is proposed to improve the usability of the staking system at the protocol level by automating the reward distribution among the forger hosting provider and the ZEN holders who stake their ZEN to the forger node. The goal of the upgrade is for the staking security system to calculate and pay the stake reward directly to the staker’s wallet address without first going through the forger node itself.

Motivation

The current method of staking was designed for the EON staking early adopters, those who are able to run their own forger nodes for themselves, with the staking reward of all delegated ZEN paid to the forger node operator, who then distributes it to those who delegated to the node. This system works, but it requires the hosting provider to calculate and distribute the stake reward, possibly leading to both misunderstandings and potential regulator issues.

This update would allow users to delegate stake to forger nodes, with the ability to have visibility over the return they would receive. When forgers are instantiated they would set the percentage of rewards they receive for running a forger (reward share). Delegators would receive the remaining rewards. Forgers will set a contract address to handle the distribution of the rest of rewards to delegators (smart contract address). These two variables (reward share and smart contract address) cannot be changed once set by a forger.

This new method was chosen to allow forgers to develop their own strategy for distributing rewards to delegators.

Benefits

We believe this update will provide the following benefits:

  • Provide an easy way to distribute rewards to delegators, without forgers needing to take responsibility for distribution.
  • Provide visibility to delegators and the rewards they are likely to receive.
  • Protocol changes are not needed if reward distribution mechanics need to be updated.
  • Allow for custom reward distribution by forgers. Creative mechanisms can be used to encourage further participation.
  • Reduce attacks on the network by providing a minimum staking requirement.

Specification

We propose to introduce the following changes:

  • Introduce a preliminary registration step for forgers: will be performed by executing a transaction declaring the forger public keys (VRF key and block sign key), the percentage of rewards to be redirected to a smart contract responsible to manage the delegators’ rewards (named “reward share”), and the address of that smart contract. (The last two fields will be optional).
  • A minimum amount of 10 ZEN will be required to be sent with the transaction: it will be converted automatically into the first stake assigned to the forger.
  • The registration step will not be required for existing forgers owning a stake before the hardfork: they will be automatically added to the list of registered ones, with “reward share” = 0 and “smart contract address” = none.
  • Introduce an updateForger() method to allow forgers with “reward share” = 0 and “smart contract address” = none to update the fields .
  • The update will be allowed only one time: once set, the values will be immutable. This protects delegators from distribution mechanisms being changed without their knowledge.
  • Modify the consensus lottery to consider only forgers owning an amount of stakes (directly or delegated) equals or over to 10 ZEN.
  • Modify the reward mechanism to redirect the above declared percentage of the total rewards assigned to each specific forger to the smart contract (if specified). This will include all the existing reward components (forger’s tip, forger’s base fee pool, 5% coinbase from the mainchain). Note there is a delay of two epochs from when ZEN is staked until it is included in the calculation.
  • Modify the stakes behavior from an “UTXO-like” to an “account-like” representation: each delegate and withdrawal operation will cause to increment/decrement a total stake balance assigned to the specific key delegator+forger. This will eliminate the notion of “stakeid”, allowing delegators to withdraw funds more easily (the additional signature will no longer be required for withdrawals) and also (optionally) to perform only partial withdrawals of previously staked amounts.
  • Add additional methods on the stake native smart contract to allow a fair distribution from a smart contract. These will include methods to return:
    • Current consensus epoch.
    • Total rewards assigned to the smart contract at a specific consensus epoch.
    • Total stakes present at a specific consensus epoch, optionally filtered by stake owner and/or by forger.
    • List of all registered forgers.

Rationale

  • This new method was chosen to allow forgers to develop their own strategy for distributing rewards to delegators.
  • Technical approach was chosen to reduce the need for hardforks if reward mechanics need to change.
  • Creating a minimum staking threshold reduces the chance of attacks.
  • The inability for forgers to change both the contract address and rewards amount will not allow for forgers to change staking mechanics before rewards are distributed.
8 Likes
2

I have no idea whether it is possible and if there is the time but it would be useful for the delegator to decide (optional) also a different address for the rewards.
It gives the possibility in this way of applying for example an “automatic” compound (currently I offer it as optional for those delegated on my forgers nodes).

3

Would you mind explaining how you would use a separate rewards address for auto-compounding?

Agreed though that the ability to set one as a delegator would be nice.

2 Likes
4

I’m a huge fan of this and think it’s super important for stakes on EON. Right now delegated stake needs to rely on forgers to honesty distribute funds. This needs to be automated and I’m glad there’s a plan. I’m all for it.

3 Likes
5

Many users forget (for various reasons) to make the claim of the rewards on Monday and then restake them again.
By sending the rewards to my address (hosting service) instead of the stake address, I could continue as now, that is, as soon as the rewards are paid to the forger, I sent they immediately (at least for users who have selected the compound option) to the forger.
Not having the opportunity to select an address other than that of the stake, the same users with version 1.4 will not have this possibility
Obviously only users who trust hosting will do so ^^ it should be just optional

2 Likes
6

Sodiomayor is right, I as an investor can get lazy or unable to monitor every week so adding this as an option for those running a staking service may be a nice feature.

1 Like
7

For auto-compounding (I’ll let the engineers verify what I state here), but one of the nice features of this update is that forgers can customize claiming mechanics however they like.

For instance, the smart contract used by the forger could include auto-compounding methods or some other special algorithm to those users who dont claim rewards on a weekly basis.

Any custom dApp could really be built with the way we are implementing this update. It was actually the intention to build it this way so that those of you who might want specific features could employ it without the need to continually update code on the protocol layer.

The responsibility of the protocol is to reward forgers, the forger can develop whatever mechanics it wants to support those delegating to their node.

1 Like
8

I understood that the rewards will be credited directly to the delegator stake (currently to the forger), so the owner of the forger is excluded from this step (excluding fee), if instead it’s possible to do it through the Smart Contract then no need (optional) address for the rewards :slight_smile:

9

hi @Sodiomayor
you will have the possibility to keep the same behaviour as now by specifing a “reward share” = 0 and no smart contract address. in this way you can continue to manage the rewards offchain.
Otherwise as already said you will have the possibility to add more complex solutions by designing a custom smart contract, that if open-sourced may be seen as more secure by your delegators and help to attract more users.

10

Ok then the reewards will in fact be managed by the Smart Contract (not in the example above), thanks also for the suggestion :slight_smile:

1 Like