Incentivized testnet V3

[alonmuroch]

@fod and Ariel thank you for your help in writing this spec.

Summary

This is the 3rd iteration of the incentivized testnet proposal, the original proposal can be found here.

The suggested reward allocation is set to 64K SSV tokens with the expectation that at around 2M SSV tokens staked + 15K validators the incentivization component will reach some equilibrium.

A rewards simulator can be found here.

In respect to the original proposal the following updated mechanics are suggested:

Mechanics

• 64K SSV tokens are to be minted as rewards for this proposal.
• The incentivization program will start at epoch 66,340 on the prater test net (roughly January 12, 2022 noon UTC).
• The program will run for ~4 months, 8 rewards distribution, each 2 weeks apart (3,150 epochs).
• The distributions durations (by which the individual rewards are calculated for):
  • Distribution 1: epochs 66,340-69,490
  • Distribution 2: epochs 69,490-72,640
  • Distribution 3: epochs 72,640-75,790
  • Distribution 4: epochs 75,790-78,940
  • Distribution 5: epochs 78,940-82,090
  • Distribution 6: epochs 82,090-85,240
  • Distribution 7: epochs 85,240-88,390
  • Distribution 8: epochs 88,390-91,540
• Each distribution is 8K SSV tokens
• Each distribution will have the following allocation table:
  • Allocation A: 4K SSV tokens (50%) for validators which registered with an address holding SSV
  • Allocation B: 1,200 SSV tokens (15%) for all validators (registered with addresses holding/ not holding SSV
  • Allocation C: 1,400 SSV tokens (17.5%) for verified operators (including dAppnodes)
  • Allocation D: 1,400 SSV tokens (17.5%) for all operators (verified and not verified)
• Blox’s operator will be excluded from rewards distribution

Validator Eligibility

• Anyone can register a 32 ETH validator.
• Each validator performing with at least 85% average attestation rate the previous 3,150 epochs (~14 days) is eligible.
• Abusive behaviour of the network (e.g. getting a hold of big amounts of goerli to register hundreds or thousands of validators) could result in exclusion from the incentivization program, decided by the community’s ambassadors, DAO and/ or Blox.
• A max of 1 new validator per day is allowed for the registering address to be eligible and not excluded.
• Rewards are claimable to the address that registered the validator from allocation B.
• Rewards per eligible validator is calculated by dividing allocation B by the number of eligible validators.

SSV holder registered validator Eligibility

• All validator eligibility conditions
• Every validator has a registering address, if that same address holds SSV tokens on mainnet then that address is eligible.
• A random snapshot to determine SSV balance is used to discourage manipulation.
• ri (see below) is the reward for a specific address that holds SSV and registered one or more validators.
• Rewards distributed from allocation A

SSV_i - amount of SSV held by registering address
Val_i - amount of validators registered by an address
Wi = SSV_i * Log(C * Val_i+1) - weight the registering address has towards rewards calculation
C - coefficient for validator count
W = ∑wi - Total weight of all eligible addresses
R - allocation A
r i= wi/W*R - rewards for a specific address

SSV Balance Snapshot

• A snapshot of SSV holders will be taken in a specific mainnet ethereum block for each distribution.
• A deterministic method for calculating the snapshot block is used by taking the first 4 bytes of the block root for each distribution’s end epoch (the last slot of that epoch)
• It’s virtually impossible to predict that block root making the snapshot block pseudo-random.

b = time(distributionStart) - timestamp for the closest ethereum block to the distributions start epoch time, rounded down.
twoWeeksSec = 1209600 - two weeks in seconds
blockTimeStamp = b + integer(blockRoot[0:3]) % twoWeeksSec - taking the first 4 bytes of the block root for the end slot of the end epoch for a specific distribution, converting it to a number and adding to distribution start time to get an approximated block time stamp (the closest to it rounded down)
block = block(blockTimeStamp) - a block number given a timestamp.

Operators

• Every operator receives rewards based on the amount of eligible validators it is assigned to and its individual performance (For example, an eligible validator in which the operator has a score of 0 will not reward the operator)
• Operator score is calculated according to this
• Minimum eligibility score is 85% for each distribution duration
• ri(see below) is the reward for a specific operator.
• Rewards are claimable to the address that registered the operator.
• Rewards distributed from allocation D according to the below calculation

Verified Operators

• Same as all operators but with the additional rewards allocation.
• Verified operators include existing operators with the verified/ dAppnodes tag in the testnet web app.
• To become a verified operator please refer to this
• Rewards distributed from allocation C according to the below calculation

val_i - amount of validators the operator is assigned to
score_i- operator’s score for the entire distribution duration (docs)
wi=val_i * score_i - operator’s weight in rewards
W = ∑wi - sum of all operators weight
R- total rewards (allocation D and/ or C)
ri=wi/W*R- operator rewards

Whales and Abusive Behaviour

An abusive behaviour of the testnet can be in the form of a big SSV holder trying to kidnap a big portion of the rewards and/ or someone registering a big amount of validators.

If someone registers a big amount of validators from the same address it will be easy for the community to find it out and exclude that address (and validators).

A more sophisticated approach will be to split the above validators and register them from many different addresses. This will be harder to find though still possible if all those addresses receive goerli from one master address.
This type of abuse can happen but is limited to rewards allocation B.

Another type of abuse is a big SSV holder trying to “kidnap” a big portion of the rewards.

This can happen from a single or multiple addresses like before. This time there is a cost-benefit to it.

Because of the way weights are calculated there is a clear preference (in terms of rewards) to having a single address holding, say, 100K SSV tokens and registering 1K validators than 2 addresses holding, each, 50K SSV tokens and registering 500 validators each.

From an economic point of view that’s what an abuser will tend to do which makes it very easy to spot and exclude.

A more complicated scenario is a whale splitting his tokens and validators into multiple addresses, in which case he suffers a significant decrease in the overall rewards.

Considerations

• It is important to note that the testnet is still in development and could still have stability issues which might affect validator performance and subsequent rewards.
• Rewards calculations will be done in a centralized way by the community ambassadors and/ or Blox. It’s the responsibility of every testnet participant to check for errors and present them to the ambassadors and/ or Blox.
• Abuses of the testnet are not allowed and could result in exclusion from any current and future reward distributions.
• The testnet and rewards are made by and for the community to test out the network as an important step towards mainnet, THIS IS NOT A GET RICH QUICK OPPORTUNITY. If you expect to get rich out of this, we advise NOT to join the testnet.

[Ucodia]

First of all, thank you @alonmuroch, @fod and Ariel for putting the third iteration together. As we say, 3 is a charm

I have noted that the following rule was added to the validator eligibility section:

A max of 1 new validator per day is allowed for the registering address to be eligible and not excluded.

I think this section would deserve some disambiguation. What do we mean by “excluded”? Exclude the address entirely from the incentive program or cap the reward to a maximum of 1 newly created validator per day?

[SpookyG]

Are validators that were registered before incentivization start included in the program, and does the max 1 validator/day requirement also count for validators that were registered before the start date?

[Voss-DAppNode]

I have other comments as well but need more time to make them properly. One of the bigger things that is a major concern is that 65% of all the rewards are now going to validators, which was initially 50% in the first proposal. I don’t think it makes sense to give more rewards to the people who literally had to spend 10 mins or less, depending on their skill level, to spin up a validator which required NO tech savviness (especially for the thousand or so people who’ve watched the " [SSV] Guide - How to Setup a Validator on the SSV Testnet" youtube video I made for you guys. I know I did it for free, but added a tip ENS, and got none, unsurprisingly; however, now the vast majority of rewards will be going to the people I personally walked through how to do what was needed from start to finish in fine detail to setup validators, and I got…nothing. Whoever uploaded it didn’t even put my username in the copy of my video i sent to you and tagged the video with my Discord user number not even my Voss handle, while the SSV network got at a minimum of 1,000 new validators who needed to do absolutely no after care, follow up, feedback or anything else to benefit the network except the validators who also buy SSV, which just pumps the token price artificially.

Running a validator is a set it and forget it thing, recently some operators have been able to be contacted via discord etc, but there’s no feedback that the validators give, or can give for that matter, that helps improve the product, and the lack of needing to provide compute power on a consistent basis, and only needing to get free GoETH, which can be a bit of a struggle sometimes but is also totally free with no work involved aside from entering addresses and clicking send.
I think the operators, especially the verified operators should definitely be getting the majority of the rewards, since they are the ones doing the work of actually using the testnet, finding and reporting bugs, and devoting an ever-increasing amount of compute resources to SSV, 95% of the DAppNode Verified operators doing SSV on the same device that they stake their real mainnet ETH, some people also do Avalanche, Gnosis beacon chain, and other production ready income generating packages, but do so out of the desire to build the community and industry as a whole, and most of them are now facing an increasing opportunity cost of whether they even should continue SSV after almost 3 months of testing, bug hunting and reporting etc, since their other actual income generating services have continued to degrade due to SSV using more CPU RAM and Bandwidth than was initially expected. I find it quite confusing that those who did all the work actually testing the network and running it (for a long time DAppNode Verified Operators outnumbered all other verified operators, we were more than 50% of the verified network operators for a month or so).

I cannot understand how spending 10 mins on making a validator and owning SSV (this is one of the biggest issues I struggle to grasp as being logical or even ethical- it screams Ponzi scheme) and doing the very least to to actually test the testnet, needing to buy SSV tokens beforehand, which evolved from CDT, the previous Blox Staking/CoinDash token, (I won’t go into any details on CDT’s very tumultuous, infamous, strange, and inconsistent history here, though they most certainly don’t invoke any level of trust) or already being a CDT holder. These people are the primary beneficiaries of this testnet incentive, not the ones who are donating compute power to run and secure the network. So I think this is an even worse proposal than the last. The first proposal from late September i think? which never mentioned holding SSV tokens at any point, is the only real solution; it’s not perfect, but I see it as the base model for any real proposal on this that makes sense or even falls in line with ethics or logic, because this one fails miserably. The only part of this proposal I agree with is that the amount of rewards were doubled. I was doing the math last week and was shocked at how few funds were being put into the incentivized testnet from the total 10.5M tokens, especially looking at how few holders there are of SSV 414 at the time of this post, SSV Token (SSV) Token Tracker | Etherscan the holders are incredibly concentrated and it is concerning from an economic perspective.

Also, I’m in 100% agreement with @SpookyG that since the rules weren’t made until very recently and many people likely have “abused” the system based on these new terms, those who did anything well before the time of this OP must be grandfathered in, and cannot be excluded for setting up a lot in a day, or getting a lot from one address, or any of those definitions of “abuse.”

[alonmuroch]

@Ucodia

I think this section would deserve some disambiguation. What do we mean by “excluded”? Exclude the address entirely from the incentive program or cap the reward to a maximum of 1 newly created validator per day?

Good point, I think we need to clarify how we count validators (past or from start of the incentivization program).
I’d very much like to avoid messy calculations per validator so I tend to go for “the whole account excluded” even though it sounds a bit harsh.
What you think?

[alonmuroch]

@SpookyG

Are validators that were registered before incentivization start included in the program, and does the max 1 validator/day requirement also count for validators that were registered before the start date?

I’m for validators registered after a certain date, not sure what the community support is.
WYT?

[alonmuroch]

@Voss-DAppNode

spend 10 mins or less

It is true setting up 1 validator is much much easier than running a node but there are also much less node operators with a significant number of validators than operators and while an operator (with a good enough traction of validators) can stand to earn hundreds of SSV, someone setting up a validator will earn less than 1 (without holding SSV).

@Voss-DAppNode

but added a tip ENS, and got none

Corrected, check your account.

@Voss-DAppNode

Running a validator is a set it and forget it thing, recently some operators have been able to be contacted via discord etc, but there’s no feedback that the validators give, or can give for that matter, that helps improve the product

I disagree here. One of the objectives of this whole thing is to create accountability between validators and operators. If a validator stand to lose rewards because >1 operators don’t do their work then I’d expect that validator to reach out and demand better performance from the operator. If we can get to there it’s an amazing preparation for mainnet.
The current status of the testnet is that most verified operators perform well but some not, most don’t event know that they don’t because there is hardly anyone demanding them to do so.

@Voss-DAppNode

I think the operators, especially the verified operators should definitely be getting the majority of the rewards

I agree, if you look at the current testnet structure + reward allocation you’ll see that verified operators get rewards from both verified and non verified operators, that will mean they will get a very significant cut. Which they should.
Also we raised the rewards from 32K to 64K, overall the rewards pool for operators is greater.

@Voss-DAppNode

and most of them are now facing an increasing opportunity cost of whether they even should continue SSV after almost 3 months of testing, bug hunting and reporting etc

If you’ll take a look at the rewards calculator and adjust the parameters to current network status you’ll find that the rewards are very significant.
If I’ll take your operator, with 300 validators, it will earn close to 500 SSV tokens during the 4 months (~$4,000) which I think is significant.

SSV holders are the governing body of this protocol, saying they just take rewards is the same as saying big ETH holders can take all the staking rewards from ETH.
The goal of this program is not to have as many validators as we can, if that was the case we could have spun 15K of them tomorrow.
The goal of this program is to mimic the relationship between validators who stake capital and operators who provide a service.
The only way to do that is to actually have something at stake because otherwise this relationship doesn’t exits.

Rewards are a really good way to do that but there is nothing preventing someone with a big pile of goerli to steal all the rewards as well. That’s why we introduced holding SSV as medium for both creating the feel you have a “skin in the game” and reduce abuse.
Another point is that you can hold a bunch of SSV but your rewards depend on how many validators you run. If some whale dedicates time and registers a validator per day for the entire duration + continuously monitoring their performance then he should get rewarded. That’s a great community member which will likely be active in other community activities like governance.

This program tries to be balanced between different network actors and the goals of the program, if you disagree with the goal I’d be more than happy you write what you think the goals should be (for example maximizing validator number).

[Ucodia]

Personally I have joined the program as an operator when the V2 proposal was out and it only said:

Abusive behaviour of the network (e.g. getting a hold of big amounts of goerli to register hundreds or thousands of validators) could result in exclusion from the incentivization program

So when I started my operator with a single validator to begin with, I looked into the community to have more validators and test drive the software. Though at the time I had no verification status and could barely get to 6 validators total from other people in the community. So I used the Ethstaker Discord bot and created 20 validators in that way over the course of the next 2 weeks, which mathematically means I have at least setup more than 1 validator on a given day. In regard of the previous sentence, this was not considered an abuse at the time since I was not “getting a hold of big amounts of goerli to register hundreds or thousands of validators”.

Never my goal was to abuse the system, rather to test drive the software and my hardware so that I could help and get SSV to mainnet. I have also spent hours reaching out to dozen of members in the DAppNode community in order to mitigate the network wide issues related to incompatibilities with Prysm 2.0.5 which is now coming to a better state every day. I will also note that in my first week, I got a hold of 1K$ worth of SSV as an investment in a network I truly believed in.

So if you tell me that testers like me will be excluded from the incentive program because I setup more than 1 validator on a given day, then yes, I think this is harsh. Also I wonder if we looked into how many people will be excluded from the incentive based on that new criteria which was not there when it all started?

Though, if I am excluded from the incentive after spending my time and effort in pushing SSV to mainnet as a small node runner I won’t be too mad either because this is just an incentive and this is not reason why I am here. From a morale perspective you will probably punish many legit testers in order to “avoid messy calculations” and this does not look good on SSV DAO in my opinion.

[fod]

I don’t think this was the intention, and I would not worry at all. It sounds like you’re exactly the type of user that this program was made to reward. I think the “1 validator per day” is just a rule of thumb to attempt to define abuse of this program. I believe all of the judgements will be made by people, not a strictly-coded algorithm. So I’m sure there will be leniency for validators that have already been created or for those that might have registered a single validator or two over the limit at some point. I think these rules are to just say don’t register like 20 in a day or hundreds total.

[contraband]

I just want to know if existing validators and operators (me) will be grandfathered into the testnet or will we need to spin up new validators and nodes once the incentivization is live.

I am an independent operator. I dont have the resources of a large company backing my contributions to the network, so I feel as if I am already disadvantaged when the incentive is based on number of validators attached to my node.

Ultimately, I believe that keeping with the ethos of Ethereum, small, independent, distributed operators such as myself are the preferred type of operator. But, based on the reward / ranking system, I am not sure I can be competitive.

I didn’t come onboard for the incentives though. To me, this is about the robustness of the beaconchain, and if I can play some small part in that security, then I will gladly volunteer my time and hardware to that worthwhile effort.

Thanks again for the good work you are doing. I will continue to try to help anyway I can.

Contrabandoperator

[alonmuroch]

@contraband

I am an independent operator. I dont have the resources of a large company backing my contributions to the network, so I feel as if I am already disadvantaged when the incentive is based on number of validators attached to my node.

I welcome a different way of calculating rewards but it seems fair to me that an operator with more validators (considering their performance is good) will earn more rewards.
I will say not all top operators currently in testnet are huge staking services.

Going forward, especially thinking of mainnet, I’m thinking about a type of network fee which will be a function of the number of validators an operator has. Think of it as a centralization penalty.
That will definitely embrace smaller operators.

[alonmuroch]

I think we need to decide if past validators are counted for rewards or not.

Pro:

1. Past users which might spun hundreds of validators (in preparation or not) will need to spin more according to the rules like everyone else
2. resets the playing ground for everyone (might be a con)
3. Smaller operators start anew with the big operators
4. newer operators start anew with older operators (which have more validators)

Con

1. Anyone who put the work in running a few validators will need to start over
2. No real incentive to run “old” validators
3. Some operators are reaching 2K validators which means we will need to cap it somehow and let them run another operator as we haven’t tested out more than that on a single operator
4. Prater has 60K validators today, if we are going to run 10-15K it might effect the network (maybe a good idea is to reach out to the EF about it)

My personal preference, considering the above, is to actually only count new validators.
I think it’s the fairness alternative and one that will happen in the future when new contract versions will be deployed which will need to reset the testnet

[BeeMan]

The testnet has been announced a while ago, and people have staked their GoETH through SSV in anticipation but the network was not stable and the incentivization has not started yet. Now most of that GoETH is gone for good.

Any ideas to compensate for the lost GoETH?

[alonmuroch]

Thinking about it again, I think it’s for the best to leave it as is. Existing validators participate in the rewards.
Whoever invested time (operators and validators) before should rip the benefits now.

[alonmuroch]

We will have a community discussion to finalize opinions on Monday the 3rd at 5PM UTC.
Please DM me for a link to the call.

If you want you voice to be heard this forum and the call are the best places to do so.

[Voss-DAppNode]

Much agreed on behalf of all the DAppNode Community.
And I hope they can be reaped not ripped lol

[Adamefr]

We will do our best to make sure the incentivized testnet recognizes your hard work and contribution. If anything was neglected on our part please dont perceive it as dismissing your efforts. Its a learning process for us as well, we will make sure your and the community’s comments are addressed.

Thanks for your patience

[fod]

I’ve already voiced this opinion elsewhere, but I wanted to write it here too before the upcoming community call. I’d like to see a larger rewards pool for this program. This project is trying to ramp up marketing and outreach efforts, and I think this is an opportunity to attract many new users to SSV and encourage them to participate. Note that my comments are mainly only in regards to the validator and SSV holder rewards, not the operator rewards (I’ll let them speak for themselves).

I think the current amount of 64k SSV is enough to adequately reward the existing community. But if most of the existing users participate, the rewards rate will quickly drop and do little to attract new people. Therefore, I propose increasing the amount at least 3x to 192k SSV, and I would support as high as 5x (320k SSV). I think this would keep the reward rate high enough to encourage new investors to learn about the project, buy the token, and participate. (I think the APR probably needs to be 10%+ for this)

Simplifying the math, a rough estimate of the expected APR for holding SSV (ignoring the non-SSV rewards pool) can be calculated as APR = 3*(Rewards pool)/(SSV participating). If I did my math correctly, with a rewards pool of 32k for SSV holders (64k total for the program), the APR earned on holding SSV will drop below 10% when only about 1 million SSV is participating. I think the existing community would fill this quickly, and the APR would drop to about 5% (I’m estimating about 2 million SSV contributed by the active community).

With 96k SSV (192k total), about 2.9 million SSV can participate before the APR drops below 10%. And with 160k (320k total), we can accommodate about 4.8 million before it hits 10%. This will keep the rewards sufficiently high beyond the participation of the exiting community, which will leave room to incentivize new users to buy and participate.

This would obviously be more expensive, but I’m not too concerned with the cost since it would be minted by the DAO. We’d be inflating the supply slightly, but since the new tokens will be given directly to the active community and investors that contribute, their rewards should far surpass their small loss of value from inflation.

The people that would be negatively affected by an increased cost are the investors that simply own the token but are not following the project or participating. I’m completely fine with reducing their value slightly to attract new people and reward those who actively help the project. Blox would also be a loser in this case, which I’m not thrilled about (they deserve our support). If we care, we could also mint an additional amount of SSV to be given to them to help offset their loss. Partners will also be affected if their locked SSV doesn’t count toward the rewards, so maybe that SSV should be allowed to be used as well.

However, we should be cautious about how this will affect the market since it has the potential to create sell pressure. Personally I’m not worried, but other opinions would be appreciated. I think that for the duration of the rewards program, a significant amount of buying pressure will be created (considering just the APR offered, let alone the effects from new people discovering the project). And although many users will likely sell their rewards as they get them, there would also be a large incentive to hold or buy more to increase their rewards, assuming the rate of return is high enough (I think the market will probably find some equilibrium for this at an APR of 10% or so). There’s also some concern about the market effects when this program ends, but I think this can be offset by future long-term testnet incentivization programs (if intention is to keep it running) or staking mechanisms that are added to the SSV network. And hopefully a lot of this would be offset by simply attracting new users and growing the project anyway.

[JHGrove3]

Here are my thoughts:

TLDR first:

The SSV testnet still feels like it is in Alpha Testing, and it seems premature to roll out the final incentivized testing program.

Why not start with a simpler rewards program for the existing testing base, and plan to ramp up the program later when we get to Beta Testing?

Post Body:

I’ve been a DAppNode SSV tester since shortly after the SSV DApp was released.

I set up my operator node, and I set up 4 validators to run on the network. I chose 4 because of the prohibition of setting up a lot of validators, and I didn’t know just what the limit would be. As it happens, I made all 4 on one day, so I guess I broke the limit anyway.

I’ve participated through problems like the Prysm failure to attest, and the required rollback. As far as I am aware, that bug has not been fixed yet.

There is also the issue of not being able to make Proposals.

And the reporting dashboard, while functional, requires a lot of clicking to find the information you need.

None of this is a big problem – it’s the kind of thing you expect to see while a new product is in development. But it still feels very much like a product that is in development…

Now the Blox team is trying to formulate a rewards plan that discourages gaming the system, while it rewards honest users. That’s hard to balance correctly, even more so when we are trying to launch so many features at one time, and when we don’t have good data on who will be participating.

So here is my suggestion:

1. Postpone the big fancy incentivized testnet
2. Instead, start a small incentive program that rewards the current set of operators who have been participating all along. Most of them are happy to help, and a small tip for each day or week of uptime would make them feel appreciated and keep them motivated.
3. Get the rest of the big bugs worked out.
4. When the time is right, roll out the big fancy incentivized testnet. Use data from the small incentive program to refine the rules for the big one. Find out what the typical SSV holdings are, and the number of validators people run. Maybe even limit some participation to people who were in it all along.

Separately, with regard to the SSV Holders pool:
We are still allocate half of the overall rewards to people who have SSV, and then we weight those rewards towards those who have a LOT of SSV. Honestly, they don’t need more…

Also, I suspect it will still be easier and more profitable to have 2 wallets with 10 validators each than 1 wallet with 50 validators. You might end up with people going to extremes and making 100 wallets with 1 validator each… (I haven’t played with the simulator yet, so I might be wrong…)

But we are really just guessing how this will play out when we don’t have a lot of data to go on, and that seems like a recipe for mistakes.

[arielzimroni]

Running the rewards calculation based on the last weeks of the testnet (just as a references as I’m sure it will change once the incentivized testnet actually goes live) reveals that it’s not worth for a lot of users to claim rewards per round because of the associated costs (e.g. transferring SSV back to Ethereum from xDai in order to increased their stack / realize gains) - which means aggregation of rewards is essential, and as it looks the preferred way is to perform a single distribution (at the end of the testnet), instead of in 8 individual rounds (rewards will be stilled calculated per round as outlined in the proposal).

I will create a separated detailed discussion with the findings and insights regarding how to conduct the actual rewards distribution.