New ZenIP - Delegated Staking on EON


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.

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.

The distribution of rewards from the delegator’s partition will be handled by a smart contract on the EON chain. When setting up a node forgers will be able to choose a contract that will handle distribution for the delegator’s partition. Horizen will provide a standard contract for forgers to use, however any contract can be used. Horizen’s contract will distribute rewards according to the percentage of stake users contribute to a single forger. Any user will be able to claim rewards after it is distributed to a forger for staking on the network.

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

Technical Updates

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.


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.

Looking forward to hearing everyone’s thoughts about this update.


This is the best part:

  • Provide an easy way to distribute rewards to delegators, without forgers needing to take responsibility for distribution.

THE big change, the most important perhaps, excited to be able to launch many forge nodes


A valid point actually

Great, as a node operator this is exactly what I have been waiting for!

I would like to see a Cap on the Total Amount of Staked ZEN allowed on 1 EON Forger Node.
This would allow for more distribution across Forger Nodes and increase the decentralization and possibility of attack. Also make the Distributions of rewards fairer across the nodes.


yes for sure! whatever we can do to make forger node participation higher and easier onboarding for delegators

1 Like

This all sounds great for minimizing issues and boosting efficiency in staking setup and rewards. Thanks for your efforts on this!

1 Like

This wouldn’t really increases decentralization, it would just cause larger node operators to have to run more nodes. And the rewards distribution would still be the same - a small node operator would still have the same % of the total staked ZEN on the network.

1 Like

? Large operators running more nodes is increasing Decentralization, more nodes distributed more decentralization, so I don’t understand your first statement. Seem to be conflicting opinions on rewards, some say the more ZEN the more probability of Rewards, then some seem to go complete percentage based. The rewards on my nodes are definitely not even and their all over the place so I am not going with your % based Rewards as a truth.

Yes, more nodes would decrease the attack vector of a single node being attacked, but it is still one centralized party operating the same amount of stake on the network.

As for my rewards statement, I’m just going off the existing docs. The VRF used for forger selection should select forgers at a rate approximately equivalent to their percentage of stake. What do you mean by “complete percentage based”?

By Complete percentage Based, I mean just that, you can calculate your rewards by your % of the Total Stake. I know this is not the case as I can see it first hand on my Node. Yes it is one centralized party having more nodes, but this is the idea. What stops a Network getting attacked when it comes right down to it? Cost, Cost for Stake, cost of Infrastructure and running that infrastructure. Therefore if a Large operators has to run more nodes, this increases the Cost to mount an Attack. You need more than 50% of the Nodes and there are more nodes, increasing costs to perform an attack making the network more secure.

hello! an hypothetical max cap on the total amount of staked ZEN could be introduced/verified only by looking at the key pairs (vrfkey, signPubKey): they are currently the only on-chain info that identify univokely a specific forger.
But a single node could have in the local wallet more than one pair of keys, so a node operator could bypass the limit very easily without having to spin-up more nodes => no real benefits on decentralization

1 Like

I think the same as you , it’s a very good way for the forger nodes administrators

1 Like