PUP-4: Adjust DAOAllocation to Limit Service Node Counts

The only thing I’ll add here is that I would expect that node runners will only follow the relays as it’s the only way to maintain profitability. As we have relay diversity across networks, it’ll only make sense to spin up infra for profitable chains.

To your point about node rewards, I’d be hard pressed to keep my nodes running at the ~5000 node validator limit with that sort of POKT reward. I’d focus my nodes on the networks that provided the most profitability.

I fully agree that it is irrational behavior. That is why I pointed it out. We need to get some clear communication out there to stop the rumor reaction.

1 Like

I agree with Ben. We need more clear communication. We also need clarity on:

  • How long this will last?
  • What happens when 5000 validator limit is no longer needed? Do we go back to 89% allocation or some other number?

If you’re asking how long the measures outlined in the finalized proposal will last, assuming the DAO approves them, they’ll last until the DAO passes another proposal to revert them or adopt a new parameter value.

This will be up to the DAO to decide.

Thanks, I understand that. I was asking in terms of a time frame. Next 3 months? Next 6 months? More than a year? Sorry, maybe this is an unfair question, I don’t know the difficulty of the changes needed…

The protocol devs are focused on the upcoming 0.6 release (referenced here) and will be releasing a roadmap addressing these concerns after the release.

I’ve now edited the proposal to incorporate the new solution and attempt to aggregate everyone’s analysis. There are still outstanding arguments for/against different solutions, but we’re at the stage now where we should poll the DAO’s voters to get a more tangible measure of their preferences.

The vote will start tomorrow morning 8am EST and last for 7 days.


This proposal passed with 6 Approvals and 0 Rejections, so I’ll now close the topic.


I’ve opened up this proposal for discussion again, although the proposal has passed per my above message, to allow for more discussion to take place in the same thread.

If someone wants to propose a new parameter change (e.g. to adopt a different strategy or revert this decision), they should publish it separately in the PUP category and link to this thread.

Hello there,

What are the exact parameters that were voted by the proposal ? Is it the parameters that were initially described by @Andrew ?
I’m struggling to synthesize the complete thread. Would it be possible to clarify that so we could communicate on it clearly to our clients and community ?

Thanks :slight_smile:

cc @tdephuoc @Laszlo_Szabo @Gregoire_SkillZ @JackALaing

No. I edited the original proposal with the new parameters as well as synthesizing the complete thread so that you don’t have to.

Here is the comment where I announced that I was doing this

And here is where I left a note that the original proposal had been edited with Andrew’s consent

Your single source of truth is the latest version of the proposal at the top of this thread. It defines the parameters that were approved by the DAO for modification and synthesizes all of the arguments for/against the proposal.

1 Like

Thanks @JackALaing, very clear :pray:


I think we should discuss delaying and/or modifying the actions approved by this proposal.
1.) Shift the curve out by 1,000 (so that reductions begin at 4,000 not 3,000) and…
2.) Modify the MaxValidators param to 4,000 rather than 5000 ( so that nodes become service nodes sooner rather than later.

Reasons why we should consider this change:
1.) Recent changes in the P2P configurations associated with the RC-0.6.0 release have already caused a very noticeable improvement in block propagation and achievement of consensus. In fact, blocks are actually arriving early in many cases rather than late.

2.) The split between validator and service nodes (after 0.6.0 activation block) will -in itself- reduce the overhead associated with additional nodes.

3.) By my estimation based on conversations with persons who have coins that unlock on 5/15. We can reasonably expect 1,000+ nodes to attempt to join the network on or shortly after that date. As things stand right now… we could be in for a really ugly PR issue if 1 or 2 thousand nodes join at approximately the same time that the rewards go to near zero.


Agree with the fact that we should reevaluate this proposal with a new one. We’re currently drafting a position on the subject and will take part in the discussion shortly.

Thanks @BenVan for the initiative!

cc @tdephuoc @Laszlo_Szabo @Gregoire_SkillZ

@BenVan, thanks for opening the debate on updating PUP4

  • understanding your update suggestion, you propose a maximum of 4k validators earning 100% rewards.
  • passing the 4k validators limit; all nodes will be service nodes
  • reaching 5000 nodes (4000 validators + 1000 service nodes) => 49% of rewards

Is it what you had in mind?

@JackALaing, what doesn’t seem clear to me is when and according to which criteria the PUP4 voted will be implemented by the DAO?

1 Like

@Laszlo_Szabo I’m saying shift the curve in the top post out by 1,000 so that the “wall” is at 6,000 not 5,000 .
At that point … yes… there would be 4,000 validators and 2,000 service nodes running.
Hopefully, prior to that point we will have good data on how the growth from current to 5,000 has effected the network and what effect service nodes are having on overall operations. We may be able to abandon or further postpone this process if we are still good @5,000

1 Like

@Laszlo_Szabo see below

We are inside the activation window and the Foundation has already been authorized/instructed to act.
If I am the only one here that wishes to stop this process, that is fine, I will shut up. But I’d like to know that other people besides myself have actually read this and understand what is about to happen.