Community Staking Pool Delegation Policy

Regen Foundation stewards 30mm REGEN that have been set aside for Community Staking DAOs (if you’d like to learn more about our variant on PoS, please read up here).

We’d like to begin a strategy of staking these tokens, and are going to outline our strategy below. Please use the following two weeks as a public comment period before we implement.

There are a number of factors that we’ve been weighing in considering how to approach this pool. Below I’ll go through, point by point, on a number of factors.

How does the stake status of these tokens affect network security?

Generally, Proof-of-Stake networks target a high ratio of staked to unstaked tokens. The security model of Proof-of-Stake is that an attacker would need to control 33% of the network to halt the network, the thinking being that it would be prohibitively expensive to acquire this kind of stake, or literally impossible if staked tokens move past 67% of the supply.

In the Community Stake governance model, this security analysis doesn’t fully hold for this 30mm REGEN pool, in that the Foundation will never sell these tokens, and once allocated, they will be permanently locked. That said, bonded tokens are fundamentally more secure than unbonded, so dependending on your risk scenarios, you might have a significant preference to stake this pool.

If the Community Stake Pool isn’t staked, won’t it dilute the power of future Community Staking DAOs?

The purpose of these pool is to fund the creation of a variety of Community Staking DAOs (we should be announcing our first enDAOments in coming weeks). At mainnet, this pool represented 30% of the supply. Since we haven’t yet staked these tokens, this pool has already shrunk as a percentage of the supply. By staking some or all of these tokens, we could limit dilution, as long as we allocate staking rewards for this pool (my personal preference—more on that below).

How will you balance the interests of token holders and validators in this decision?

It is in the financial interest of other token holders that these tokens remain unstaked. This is because staking rewards are distributed across staked tokenholders. For example, if inflation is 20%, and 50% of the supply is staked, the APR for staked tokenholders is 40% (20%/50%). As of this writing, about 43mm are staked, giving an APR of 46%. If we were to stake the entirety of the CSDAO pool now, that would drop to 27%, simple because the CSDAO allocation would be soaking up 41% of all rewards issued on the chain. This would also tip the balance above the staking target threshold, which would eventually push the inflation down to 7% (as it is now on Cosmos). That said, 7% is still vastly greater than any conventional financial returns (a significant portion of the global sovereign debt market is actually negatively-yielding right now).

To turn our gaze to the validators: the high percent staked, the better off they are. Even with decreasing inflation rates, they still get to capture a set percentage of assets under management. So if we almost double the number of tokens staked, on average, their yields will almost double (and we do intend to delegate this stake as broadly as possible).

Where does commission enter into all of this, and what kind of provisions are there for validator economics?

Top of mind for me is validator economics; validators won’ t indefinitely validate for a network if they’re perpetually losing money. It’s quite challenging to accurately estimate validator running costs, as there are some many variables (geography, grade of hardware, grade of internet connection, dedicated staff, security protocols, etc.). Also, we want a network that works for all validators, and this means having an equal enough distribution that validators down near the bottom of the rankings can still pay their expenses. Alternately, we don’t want a flat distribution, as it would be extremely difficult for new validators to break into the set.

All of this leads me to believe that whatever formula we adopt should compensate for commission rate. Above a certain commission threshold, this pool shouldn’t be delegated to certain validators. Alternately, if one validator operates at a 10% commission, but another operates at 5%, and they both receive the same stake, the former makes twice as much revenue; this is a scenario we want to avoid, as it incentivizes market inefficiency. On the other hand, validators perform the most fundamental aspect of network security and operability, and we don’t want a race to the lowest fees in a way that drives out small validators for big operations that can subsidize their operations.

What would happen to staking rewards?

It is my personal belief that this pool should be set aside for future Community Staking DAOs. These aren’t Foundation funds, so I don’t think they should be earmarked for anything other than what the pool was initially created for. The Foundation already has 5mm staked tokens, and will be using the staking rewards from those tokens as part of its discretionary spending in support of its mission.

Should uptime and a history of slashing affect delegations?

To my knowledge, this isn’t yet public knowledge (not viewable on the block explorer). Likely a project that would be good to have integrated in the SDK going forward.

How does a validator’s commitment to Regen Network’s regenerative mission play into this?

We would love to be incentivizing validators to become deeply engaged in not just keeping the network running, but also in developing new functionality for our broader community and getting involved in other ways. That said, there’s not currently enough data to go on for this to enter into calculations in a way that wouldn’t simply bias towards projects that mention something about it on the Regen Forum (which we have no way of systematically verifying yet).

Currency Proposal

On behalf of Regen Foundation—the steward of this 30mm pool—I propose the following delegation strategy for this 30mm REGEN pool:

  • Once a month, 5mm of this supply will be delegated according to the following protocols. The final 5mm will be retained unstaked for us in the enDAOment process.
  • A snapshot of the stake distribution and commission rates is taken.
  • This snapshot is used to determine the distribution of stake.
  • There will be two metrics used to weight delegations: place in the rankings, and commission rate.
  • Validators in the top 5 will receive a prominence weight of 0.25.
  • Validators in rank 6 through 10 will receive a prominence weight of 0.5.
  • Validators from 11 to 35 in the rankings will receive a prominence weight of 1.
  • Validators from 36 to 40 in the rankings will receive a prominence weight of 0.5
  • Validators from 41 to 45 in the rankings will receive a prominence of weight 0.25.
  • Validators from 46th through 50th in the ranking will receive a prominence weight of 0.125.
  • Commission adjustment will simply be the inverse of commission rate (a commission of 10% gives a commission weight of 10; a commision of 5% gives a commission weight of 20). Commissions of zero will be treated as 1%.
  • The supply to be delegated (5mm REGEN) will be split across all 50 validators according to these weights.
  • In the following round, the same process will be performed—taking a snapshot of rankings and commission rate—with the exception that an adjustment will be performed to the delegation numbers to ignore previous REGEN staked in this fashion. In other words, a validator that changed rankings because of this strategy won’t be further penalized or promoted in future rounds because of this change.

See the implications of this policy here.

The numbers used in this snapshot were taken on Monday, April 26th.

During the following two weeks, please submit your comments. I will present this proposal on the community call tomorrow, and we’ll have Discord office hours sometime next week. We’ll be especially attuned to comments regarding principles and mechanisms that can optimize for the health of the network as a whole. Public comment period will end at midnight Eastern on Tuesday, May 11th. A policy revised to incorporate comments will be implemented in the days to follow.

A little background on myself and this proprosal—I’m the President of the Board of Regen Foundation and have been around Regen Network since the early days. This proposal is the product of a Delegation Working Group within the Foundation, and has incorporated input from others in Cosmos space.

7 Likes

Sounds like a sensible strategy to me.
Typically Regenerator is in position 41. :laughing:

“with the exception that an adjustment will be performed to the delegation numbers to ignore previous REGEN staked in this fashion.”
means
“with the exception that an adjustment will be performed to the delegation numbers to ignore previous REGEN staked by the Foundation in this fashion.”

As in, the rank weight will vary, but it ignores the rank changes due to Foundation delegations, right? It is better to be unambiguous.

Also, does it get ignored forever, based on day 0, or only for the next/adjacent round of delegations?


After the first 5 rounds, how often will it be adjusted? Still once a month?


Curious on why weight 0% commission as only 1%, when (although as highlighted the costs vary) 1% is clearly not enough to run a decent operation (unless you are in the top 5 or so, which is to be discouraged for the sake of decentralization). This weight correction is an opportunity to set a soft floor for minimum commission.

Actually, this is visible on the block explorer. However, it’s not visible on Keplr wallet, which is the interface that most delegators actually use to delegate.

To see uptime history on the explorer:

  1. Go to a validator.
  2. Click on “Historical data” next to the Uptime percentage.
  3. This shows downtime, displayed as various charts, lists, and graphs.

To see slashing history on the explorer:

  1. Go to a validator.
  2. Scroll down to Transactions.
  3. Click on Slashing.

While that’s way more accessible than setting up a node and querying it via CLI, it’s still not optimized to display the most relevant information to delegators in a clear way on a single screen.

1 Like

I think the commission weight would make more sense as a 30-day average, not a snapshot of a single moment. If it’s a snapshot, then we could set our commission to zero the day before the snapshot in order to gain more delegation (actually, set it to 1%, since 0% is treated as 1%, we may as well stay at 1%), and then raise it back up. A 30-day average would be more useful. However, that doesn’t determine what happens after delegation, because we could raise our commission after this round of delegations. Which leads to:

How often would redelegation occur? (Same question @gaia asked.)

Will, thanks for this well-considered and thought-through work.

I have a couple of questions?
Do we have enough information about the types of hardware and security measures the various validators are using to bring this into the calculus? I understand that it can be significantly more expensive to run a validator with high levels of security vs running a validator off AWS. Any thoughts on bringing this in as part of the equation?
Question to the community: is there any way to remotely verify someones security measures?

Secondly, As you are delegating all the way down to number 50, it is likely that at least some of your tokens are going to end up outside the 50 active validators. Will you take immediate action to redelegate or wait until the next round? Thoughts on this?

Thanks,
C

1 Like

At this moment, we are at 44.89% staked. Would 50% staked be a good target considering that 30% of the tokens are earmarked in the way that @gaia mentioned above?

That’s a tough one, Christian. While the actual validator IP might not be feasible to be “discovered” because it is behind sentries (and there is nothing wrong with running sentries on providers of varying quality, as long as you have multiple sentries), I am not sure running a validator on bare metal (as we do) is more secure than running it on AWS. AWS/GC/Azure might even be more resilient (if setup with load balancers, etc, and you don’t have them on your bare metal setup).

As for actually running it more securely, for example signing via a YubiHSM (as we do), it can’t be proved - there is currently no way to execute an attestation when you are using this HSM (which is practically the only HSM that can be used for cosmos SDK chains). For this reason the best we can do is post a picture of the YubiHSM we use, and hope that ppl stay honest.

1 Like

You mentioned that you would like to consider the difficulty of validators breaking into the set. Currently the validator at number 50 has around 33k REGEN delegated however after the 5 month process, this is likely to be closer to 200k REGEN, however the validator at 51 would remain at or around their current 20k REGEN.

As I understand from the Chainflow post, the maximum number of validators is likely to be increased at some point in the future and if I understand your statement correctly “once allocated, they will be permanently locked” which means that these 5 rounds are final and will stay that way permanently, whenever the network is expanded to more validators, we will see a persisting cliff between 50 and 51 (give or take) purely based on who decided to purchase more in the private sale or could convince others to give delegations in the early months of the network.

Since we already have 12 presumably competent validators in the wings, and more looking at coming to REGEN to be involved in the ecosystem (such as Bliss Dynamics), we recommend to continue adjusting delegations (even over a longer period i.e. quarterly) after the initial 5 periods. This way, competent teams who wish to join the ecosystem may still be able to be incentivised to do so (and more competent teams in the ecosystem has to be a worthy goal).

With your first statement—I guess I should add, in the Community Staking Pool Allocation in this fashion. Existing Foundation delegations (from the 5mm we’ve delegated out of the Foundation’s endowment) will be figured into these calculations.

Plans after five months yet? Delegation adjustments? We don’t have this worked out yet, and prefer to take strategy one step at a time, gather data, and then reassess.

That’s a great question about bottom bound for validator fees. What would you suggest? 3%? Something else?

1 Like

How would a 30-day average be taken? Where is the record of validator commission over time?

I’d love to learn more about how we might approach validator security audits (in a way that validators don’t feel we’re being invasive). If we had an approach that could be scaled out across the set, this could become a third axis in the delegation algorithm.

One thing to reiterate: factoring in commission in the way I’ve done doesn’t actually preference a low commission rate; rather, it equalizes for commission.

Regarding relegation for when we’re outside of the set: I don’t see it as being a substantial issue if a small amount of this pool ends on non-yielding validators because they’re outside of the set. Yes—there should likely be a policy whereby this stake is relegated to the active validator set. Given the logistics of the administration of these funds, I doubt that it could be immediate, and would likely be bundled into calculations for the next round, although I’m open to other opinions on this.

Sorry—these delegations will not be permanent. I’m just saying that every month, another tranche of 5mm is delegated (potentially under a slightly altered formula). We may get to the end of a month, or the end of five months, and notice that tweaks need to be made to the delegations.

So yes, once the 25mm is delegated in this fashion, there will be some method of determining adjustments. A quarterly basis sounds about right. Another factor will be how quickly we’re spinning up DAOs (which will require the unbonding of these tokens). And this gets us into the question of what algorithm we use to unbond (it could be a simple proportional formula, or something more complex).

In conclusion, this policy is looking to address this period of staking the bulk of this pool, and doesn’t address policy from that point forward. That is yet to be developed.

1 Like

At current prices (not liquid, but assumed prices), yes, 3%. this could be lowered later.

BTW, this is a GREAT way to have a soft lower limit for commission fees. A hard limit is a practical impossibility (can be implemented, but would be circumvented).

Additionally, I’d suggest writing in the “rules” that exchanges do not get delegations from the Foundation. Of course they won’t even expect it, but for the sake of completeness, put it in :slight_smile:

3 Likes

Ah, great point about exchanges.

Live via screensharing (privately, only to the foundation, and not recorded):

  1. Run a lynis audit
  2. Show where the validator is ( curl ifconfig.co)
  3. Whether a YubiHSM is in use (show the HSM signing)

You can get deeper into this here The Celo Validator Community: Security Audits and Lessons Learned | by Deepak Nuli | The Celo Blog | Medium

1 Like

BTW, I’d add some soft metrics to the calculation:

  1. Governance participation
  2. Forum participation
  3. Discord participation
  4. Ecosystem participation (whether via your own project or by bringing in more stakeholders to the network)
1 Like

We had a community call today over in Discord. Some of the points we touched on:

  • How to encourage pro-social (or pro-ecological) validator engagement? This could look like engagement up in the application layer.
  • Noting that delegation strategy isn’t the only instrument the Foundation has to work with; we do have a grant application template (although we haven’t yet publicized it), and could open up a grants program
  • Putting a floor on the commission rate (but not an explicit ceiling, as it could encourage people to push commissions up near that level)
  • Some validators intend to put some of their staking rewards back into network development; how can we monitor and incentivize this?
  • With security audits—how not to push certain standards that might create a single point of failure?
  • Commons Stack corollaries: praise, CSTK, Hatch process
  • Opening up bounty programs?
  • Would DAOs ever run their own validator?
  • Where does Yield Farming enter into this on the mechanism design layer—incentivizing liquidity?
1 Like

I like the bullet about DAOs running their own validators. Did you come up with some interesting pro’s and con’s?

Very interested in DAOs and Validators as well. Would be the way to bring Hypha into the game!