Generally speaking, this is a pragmatic approach to solving this issue.
I’ve been debating with @shane on the best path forward. We’ve come to understand that everything will be a tradeoff - there’s no right answer here.
I have a few underlying concerns, which I will address in the following sections. I also have many open questions that I’m sure the community is openly asking.
The benefit of GOOD VIBES (GV) is that we provide a predictable box for node runners and validators to thrive. The question is: do we prefer a “box” or a more laissez faire approach.
My concern is that with a 21% (or 27%) Validator Allocation, node runners will not know the outcome until things shake out. What if the common sentiment is that servicing is still superior in rewards? What if people make the wrong call? Node runners are left with a game of chicken where they are incentivized to sit on the fence. Why would I act until I know the outcome?
The Right Number
I’m concerned that picking a number based on some high level assumptions of how people will act is too risky. The lack of predictability is why GV could be an alternative worth considering. No matter what people do, I, as a node runner, can predict the future with relative certainty. This may provide more confidence to participants.
Servicer vs Validator Economies
This proposal does a better job of discouraging a validator economy. A lack of true validator economy is attractive to some parties. I acknowledge that fact. Do we want validation to be a feature of service providers or an entire product? When we need to switch back to servicing, how painful will that transformation be? It is hard to say at this point, but I trust contributors to do what’s right for the economy.
Further, are whales interested in running service nodes over “easier to do” validation if the rewards are in similar ballparks? When does that begin to eat into the underlying service Pocket provides?
There is a fair bit of feedback on GV that the proposal strengthens the narrative of a “POKT FED”. While the execution of that change is the responsibility of the Foundation, I’m confident that the Foundation will act within the bounds of the proposal. These words may not provide much comfort, but there are checks and balances built in to protect the community from abuse. On a tactical level, I believe after the scariest implementation period, changes to the curve or the GV factor should be DAO decisions.
At that point, the effective difference for GV and this proposal is very little from a governance perspective outside of regular parameter changes that would occur with GV as determined by a DAO voted curve.
This proposal doesn’t properly address the issue of inflation, which Shane is aware of and he is addressing (I believe).
Without a concrete plan, I would have reservations about this proposal.
- Add in a component that addresses inflation without leaving it ambiguous.
- Publish the math of the post-Phase 1 outcomes for servicers and validators
- Delegate the responsibility of a grace period to the Foundation or have a concrete plan to execute on.
- Further define the sub-phases of Phase 1 and 2. Is there a correct order of operations?
- I’d suggest that the validator change should occur before the minimum stake change.
Until we truly get economics and network costs under control and find equilibrium, we will be forced into constant compromises to bootstrap the network to where it needs to be. This may be necessary, but we need to recognize what it means: costs to the holders of the token.
For example, if we’re going to support more nodes than is strictly necessary to run the service, we’re going to have excess inflation and unnecessary market pressure. If we choose to support more than is strictly necessary, we’re all agreeing to bear that cost. In some scenarios this may be worth it and in others it may not be.
In my personal opinion, it’s best to try to get as close as we can to market equilibrium today rather than continuously kicking the can down the road. These changes need to be part economics (inflation) and part costs (light client, node count).
Regardless of GV or Phase Plan, we need to understand that these are near term fixes to long-term problems.