Update 30/6/22: This proposal has been withdrawn. Please see comments section.
Update 29/6/22: updated the language to focus specifically on the passage of PUP-19. The same concept can be applied to future desires to temporarily shorting UnstalingTime via a new PUP on a case-by-case basis.
- Author(s): @msa6867
- Parameter: UnstakingTime
- Current Value: 21 days
- **Related: PUP-19
- New Value: 1 day upon start of desired transition period; revert to 21 days thereafter
This proposal seeks to enable rapid yet stable network transition to a state of consolidation of POKT into fewer nodesr in response to the approval of PUP-19 . Namely it is proposed to temporarily adjust the UnstakingTime parameter to one day to allow node runners who wish to unstake POKT to do so in one day in anticipation that the vast majory purpose of such unstaking would be to add stake to existing nodes to compete for validator slots.UnstakingTime would then rervert to 21 days one week after it being temporarily set to 1 day.
Proposed action:, temporarily set UnstakingTime to 1 day (to allow rapid consolidation to take place in response to approval of PUP-19). Set UnstakingTime back to 21 days following a waiting period of one week counting from when it was set to 1 day
A number of proposals have been discussed in the community with the common goal of reducing infra costs. These include:
Raising minimum POKT staked per node (PUP-17, 20)
Enabling a new category of Lite Nodes (PEP-35)
Weighting servicer selection by staked POKT (PIP-23)
Weighting reward per relay by staked POKT (PIP-22)
Increasing proposer allocation (PUP 15,17,19)
All of these have in common the efect of either requiring or incentiving consolidation of staked POKT into fewer nodes (or fwer “full nodes” in the case of LC).
Of these, PIP-22 and PUP-19 have been approved. While PIP-22 has yet to be implemented, PUP-19 is ready to be put into effect immediately.
This proposal allows rapid consolidation in response to proposer allocation being raised to 5%.
As a general theoretical construct, the best way to set UnstakingTime during the transition period to keep the network stable while allowing as rapid a transition as possible to the final state incentivized by the new implementation.
This is accomplished by keeping the transition period short (of order 5 days) and making UnstatkingTime short compared to the transition period (e.g., 1 day) . UnstakingTime would then be reset to 21 days following the transition.
However, in the case of raising proposer allocation to 5%, it is antic pated that it will lead to a significantly smaller percentage of current nodes desiring to unstake simultaneously than most of the other proposals, therefore making transition time long compared to UnstakingTime is not needed for stability purposes, so the only consideration is making the transition rapid by setting UnstakingTime to 1 day (temporarily) with no need to hold off immediately raising of proposer allocation to 5%
**NOTE: most of the following discussion that has to do with smoothness of transition or stability is not applicable to raising proposer allocation to 5% since that transition should naturally be smooth and stable), but it is left here for completeness because this is all pertinent to when system is ready to turn on PIP-22 implementation. **
There are two motives to this proposal: (1) to keep network behavior smooth by decreasing the likelihood of mass unbonding on a single day in the event that one or more of the above improvement proposals passes and gets implemented, and (2) allow as rapid a transition s possible to the new system state made possible by the improvement proposal
The first motive is accomplished, counter-intuitively, by setting UnstakingTime short compared to countdown until change implementation. The second motive is accomplished by setting the target date to switch to the new allowed behavior as short as possible while still being large compared to UnstakingTime.
Let’s look at the rationale of temporarily setting UnstakingTime to a time short compared to transition time by way of counter-example. Suppose DAO were to announce today the passage of PIP-22 and further announced the dev team had already coded it and was ready to turn it on on July 1 (today’s date being June 20th). The effect would be to drive every validator who could consolidate to unbond roughly 80% of their nodes all on the same day in a mad rush to free up the tokens needed for consolidation. since UnstakingTime is long compared to time until transition, the same immediate action will be taken by all validators.
While the network might handle just fine 80% of nodes getting removed on a single day, why take the chance when it is just as easy to spread the unbonding over several days. If UnstakingTime were temporarily set to 1 day along with the announcement that the transition was taking place July 1, there would be no urgency to unbond the first day, since whether the unbond today or tomorrow or on June 28, their POKT will be free by July 1 to add stake to remaining nodes (or to transition to Lite nodes, as the case may be).
Next, regarding the transition period itself, the desire to keep the time until execution of new state as short as possible once the code is finished and tested is, in general, self evident for those who benefit from the new state. However, it is not self-evident that keeping the transition short is also best for the stability of the system. Consider two scenarios ( in both of which UnstakingTime is temporarily set to 1 day) In the first scenario, transition is announced to take place 1 month from now. In the second scenario, transition is announced to take place 5 days from now… In both scenarios nodes that are most unprofitable are likely to unbond right away, so for them, the time until transition makes no difference. But for all the rest of the nodes who are going to consolidate (or transition to Lite node) and are treading water in terms of profitability, their maximum incentive is to hold off unbonding until the last possible day to take advantage of the boost in relay count caused by the first group to unbond. So the network will see a spike of unbonding on the first day the transition is announced and a spike of unbonding on the last possible day to unbond and still the have tokens ready for consolidating on transition day. Since this profit boost to remaining validators due to the first group unbonding is a cumulative effect, the benefit of pushing off unbonding until the last possible moment is diminished the shorter the transition period is, thus decreasing the height of a last-day spike in unbonding.
Avoiding a last-day spike is also best for creating a seamless transition to the post-transition environment since one ore more of the new parameters that get implemented in the code change may be sensitive to the count of how much unbonding takes place, in which case it is helpful for the DAO to get a good handle on what that count is prior to transition without the surprise of a last day spike of unbonding. (Note that temporarily setting UnstakingTime to 2 or 3 days instead of 1 day may help ensure DAO has accurate count of unbonding if having that count is helpful to set new parameters correctly, but does nothing to help prevent a last-day spike of unbonding in case of very long transition period - it only moves forward the day of that spike by one or two calendar days.)
Copyright and related rights waived via CC0.