Hey again everyone, as you may have seen on Github and Discord, the community and various developers in the ecosystem have been working hard to assess potential solutions to the bug related to the stacks-increase function. Again, I’m offering an attempt to summarize these efforts and make it fairly easy to digest in the interest of transparency and community awareness.
It seems discussions around potential solutions are converging on the idea that resetting the PoX state and letting everyone Stack again once the issue is resolved, is the cleanest path forward. This approach also has the added benefit of allowing core developers and the community more time to test solutions during the upcoming cycle.
Broadly speaking, the options that were recently evaluated can be put into one of two buckets:
a) Implement a fork that attempts to fix the incorrect PoX state caused by the bug.
b) Implement a fork that resets the PoX state and allows users to stack again.
Fixing the incorrect PoX state (Option A) caused by the bug is much more complex and doesn’t appear technically feasible to pursue within the short time frame before the beginning of the next cycle. A hasty solution could have unintended consequences and the Stacks ecosystem prides itself on security and a methodical approach to everything from upgrades to bug triage.
This leaves Option B.
What Option B would mean:
- The network would move forward by reverting to Proof-of-burn instead of PoX while a fix is further tested. This means no Stacker will receive BTC rewards for at least the upcoming cycle. It is possible that depending on technical progress and testing, a solution takes longer than one cycle. In that case, the network will continue running Proof-of-burn until a solution is implemented.
- Pending the fork, all Stacker’s tokens will be unlocked regardless of how long they had delegated or pooled for. This enables a clean state so people can lock again later.
- Core developers will continue working on and testing the pox3 contract with community to replace pox2, ideally during the next cycle.
Why Proof-of-burn?
To offer my own imperfect analogy, Proof-of-burn is effectively a ‘safe mode’. Further, it’s already ‘built-in’, and is a proven, established part of normal Stacks consensus. Reverting to Proof-of-burn allows the network to serve users somewhat as normal (sans the Stacking reward element for Stackers) while developers write a new version of pox3.
As a reminder, PoX on the network is activated by Stackers when more than 5% of liquid supply lock their STX in consensus. Otherwise, the protocol automatically reverts to Proof-of-burn under which no STX holder gets the BTC rewards (and mining works by sending miner bids to a burn Bitcoin address). There is even some BTC burned during normal protocol operations as well e.g., during the switch from one reward cycle to the next.
Given the bug is resulting in an incorrect PoX state where some participants can earn more rewards than STX they locked, the fairest and most decentralized option is to reset the PoX state, push the version that fixes the bug, and let everyone lock again later. The established rule of thumb from a protocol fairness perspective is that whenever there are any safety concerns over which addresses the BTC rewards from Stacking should go to, BTC rewards default to being burned so no party can have a claim on them, and the protocol can remain neutral and decentralized.
Next steps
- An emergency SIP (SIP-022) has been drafted and is being reviewed by CABs. Final approval is expected by the end of day 4/26/2023. This will approve two forks. The first will reset the PoX network state and revert the network to Proof-of-burn consensus while a fix is further developed. The second fork would introduce the new PoX (pox-3) contract, fixing the function causing the issue and reenabling PoX/Stacking.
- Core developers will continue working on an updated PoX contract and address the underlying issues with the
stacks-increasefunction. This will be deployed via the second fork noted above.