This is based on the ideas of Loum and Leo from EOS NodeOne. This article will later be submitted to worker proposal.

1. Purpose

We propose a new block producer(BP) reward model based on equipment rewards in order to compensate for the disadvantages of current producer pay model announced by Dawn 4.0 of block.one.

Our method can not only maintain a sufficient number of standby BPs and but also reduce the unnecessarily large revenue gap between the highest and the lowest rewarded BP.

2. Problems in the current Producer Pay Model

The producer pay model proposed by block.one in Dawn 4.0 is shown below.

![fig1_4.png](
Figure 1. BP reward method proposed by block.one

Top 21 active BPs divide up the 0.25% per-block rewards proportional to the number of blocks produced by them. All producer candidates also divide up the 0.75% per-vote rewards proportional to the total number of votes they receive, which makes a total of 1% inflation. In this pay model, while the top 21 active BPs receive both the per-vote rewards and the per-block rewards, but the standby BPs get only the per-vote rewards. Furthermore, block.one has set 100 EOS per day (0.48 %) as a cutoff threshold for claiming the per-vote rewards. In other words, standby BPs who got less votes than the cutoff threshold will not be rewarded at all.

Consequentially, the current producer pay model causes following problems:

• 1. The difference in total rewards between the top rank and the lower end can be extremely huge by voting result. According to our calculation, the top 1 producer is rewarded about 20 to 30 times more than the last rewarded producer. See Figure 2.
• 1. The total number of the rewarded producers can be quite small by the cutoff threshold. Our calculations indicate that the total number of BPs meeting the minimum reward criteria can be less than 50 or even 30. Besides, the number of standby BPs is solely determined by a voting result with the cutoff threshold.

The following table shows the BP rewards and the last rewarded producer rank by six scenarios including the Pareto distribution scenarios.

Figure 2. the BP rewards and the total number of rewarded BPs by six scenarios including three Pareto distributions scenarios.

Table link1: EOS NodeOne - BP Revenue Analysis (Version 1.1) (Only for reference)

3. Equipment Rewards and Essentials of BP rewards

We introduce the equipment reward and explain following essentials of BP rewards. We also provide an simple illustrative example of BP pay model below.

3.1 Equipment rewards

Standby BPs are literally supposed to stand by active BPs and replace them when they are in trouble. In order to make this process possible without any technical problems, they need to maintain such equipments equivalent to the active BPs.

For this reasons, we propose the equipment rewards as a new part of the producer pay model. Equipment rewards are literally to reward BPs for maintaining their equipments. Thus, with the equipment rewards, standby BPs ought to be prepared with adequate equipments for replacing active BPs in emergencies without any functional issues. Equipment rewards can be accepted as a minimum revenue guarantee for BP operation.

Since BPs receive the equipment rewards, the community have the right to ask standby BPs to have adequate equipment similar to the active BPs. Standby BPs can be required to publish their own equipments in public, which can hold them responsible for their words.

3.2 Per-Vote rewards

Now, let's look at the implications of per-vote rewards. All producers strive to get more votes from the EOS community because they are basically rewarded based on the votes they received. One of main role of active BPs is to provide appropriate computing resources for dApps. If the dApp platform is vigorously activated and so more computing resources are required, then the active BPs must scale their computing resources accordingly.

Since expanding their equipments, however, is costly, they will reluctantly do so. Therefore, they need a motivation. The per-vote rewards is exactly for that. The voting result can give a pressure on the active BPs to provide more computing resources. Otherwise, they will lose their votes which is associated directly with their revenue.

Hence, voters are supposed to use their votes intelligently to put financial pressure on all BPs to expand their equipments/infrastructure. We call this Infrastructure Growth Needs.
However, if it is the case that most votes are casted for the upper ranks of BPs, then the rest standby BPs will be faced with a difficulty in maintaining or upgrading their equipments for standy. In the Scenario 1 in Figure 2, the last rewarded BP is 29th ranked and lower ranked BPs than the rank 29th get nothing at all.

3.3 The number of standby BPs

Due to the cutoff threshold by block.one, the number of standby BPs is not fixed and can be continuously changed according to the vote results. The disadvantage of the current method is that the number of standby BPs can be very small and determined only by vote results.

One solution to this is set the total number of BPs who get paid the equipment rewards in order to fix the number of standby BPs. For example, we can set the equipment rewards for 63 BPs, three times the number of active BPs. In this case, 21 active BPs and 42 standby BPs are paid for their equipments.

3.4 Simple illustrative example of BP pay model with equipment rewards

As mentioned above, including both equipment rewards and per-vote rewards improve the current pay model in many aspects.. Here is a simple illustrative example for a BP pay model with both rewards sections.

Example: 0.5% Equipment Rewards, 0.5% Per-Vote Rewards

We divide the total 1% BP rewards by 0.5% for equipment rewards and 0.5% for per-vote rewards as shown in Figure 3. As a result, all 63 BPs receive equipment rewards and the 21 active BPs receive per-vote rewards too. In other words, active BPs will receive both rewards, while standby BPs will receive only equipment rewards.

Figure 3. Pay model consisting of both equipment rewards and per-vote rewards

However, this example has problems that the revenue difference between the active BPs and the standby BPs can become too large and the standby BPs paid equally in spite of different vote amounts they received which can demotivate lower ranked BPs to get more votes.

4. NEW BP pay model suggestion

We now propose our new practical producer pay model including equipment rewards. This model assures that a certain number of standby BPs can afford to maintain enough resources and the quality of the system for dApps. It also reduces the reward gap between the top rank and the last rewarded BPs.

Example: 0.25% Per-Block Rewards, 0.5% Per-Vote Rewards, 0.25% Equipment Rewards

This BP rewards consist of per-block rewards, per-vote rewards and equipment rewards, as shown in Figure 4. In this pay model, active BPs will receive all three rewards, while standby BPs receive per-vote rewards and equipment rewards. The only difference between this model and the current model is to add equipment rewards and reduce the total per-vote rewards percentage.

The new BP pay model can solve the problem caused by vote results which can make a huge revenue gap between BPs, and guarantee BPs to maintain their equipments properly. Therefore we think our model can solve the said drawbacks of the current method dramatically.

However, the percentages used in the above example are only for illustration. Therefore, we plan to provide the revenue analysis data tool for proper reward percentages of the new BP pay model in our next article.

Figure 4. BP rewards consisting of per-block rewards, per-vote rewards and equipment rewards.

5. Conclusion

We have proposed the new BP reward section, equipment rewards. With the equipment rewards, standby BPs are required to maintain their equipments similar to those of the active BPs. Also this can solve the drawbacks of the current pay mode dramatically, maintain a sufficient number of standby BPs, and reduce the unnecessarily huge reward gap between the highest and the lowest BPs.

However, we still leave how to qualify BPs to get equipment rewards and how to verify their equipments. These will be suggested later and also can be discussed in the community.

This is our second version of BP revenue analysis tool:

EOS NodeOne - BP Revenue Analysis (Version 2)