Just last week (bitcoin block 668050), the first-ever active reward cycle for Stacking started the two-week process of distributing Bitcoin to stackers participating in consensus by locking up their tokens.
While the PoX protocol and miners are hard at work, it is an excellent time to reflect on the learnings the Hiro team gathered from integrating Stacking into the Stacks Wallet. We are simultaneously working on wallet upgrades to not only provide users with more information on the various Stacking inputs but also to enable delegated stacking.
In this forum post, we are sharing some feedback on the Stacking implementation and potential ideas for future improvements. We hope it can inspire community members to create SIPs or share thoughts and more ideas.
With the current implementation, stackers will miss a cycle in-between commitments. For instance, if you locked STX tokens for 2 cycles, you will miss cycle 3 and then can participate in cycle 4 again.
Let’s assume you make API calls to the PoX endpoint to get the number of Bitcoin blocks to be mined before the next reward phase starts (
next_reward_cycle_in). If this property returns
500, stackers would need to commit to stacking 100 blocks prior, so within the next 400 blocks. In other words, the prepare phase of the next cycle starts in 400 blocks. The challenge, however, is that the current implementation requires STX tokens to stay locked up until after the next cycle’s prepare phase, so until block 500. This dilemma makes it quite challenging to stack continuously.
You can quickly look up the reward blocks and times here: When rewards?
Unlocking tokens that aren’t eligible for reward slots
In various use cases, users can lock up their tokens but might not be eligible for reward slots (multipliers of 70K currently). For instance:
- Stacking a fraction of the reward slot threshold would lock up more tokens than required for the maximum number of eligible reward slots. You can lock up 200K STX but would qualify for 2 reward slots that require only 140K tokens. In that case, 60K would be locked without additional reward allocations
- Stacking less than the minimum threshold. You could use the Stacking contract directly and lock up tokens if you commit over 50K. However, only at the minimum threshold you would be assigned a reward slot. If you locked up tokens for the maximum cycle amount (12), you would have tokens locked for ~6 months without qualifying for rewards.
- Stacking for an extended period and the minimum (individual) threshold increases. The minimum threshold is computed dynamically and changes over time. If a user locked up tokens before the next cycle and the minimum increase right after, the users’ tokens will be locked, but no reward slots will be given.
Multiple stacking commitments per address
The current implementation prohibits multiple stacking commitments from the same STX address. This prevents several use cases, for instance:
- Stackers, eligible for multiple reward slots, would like to use different Bitcoin reward addresses
- Stackers would like to increase their existing commitments to ensure being eligible for increased reward slot thresholds in the future
Stacking commitment threshold
To commit to Stacking, a user would need to cross the threshold of 50K STX. Keep in mind, this is not the threshold for the reward slot allocation, which is at 70K. With additional flexibility in regards to the number of commitments per address, lowering the minimum would enable users to commit in increments, potentially as low as 10K STX. This would enable a user that committed to stacking for 6 cycles to top off their commitments in 10K increments to be eligible for future reward slot thresholds.
Improving Stacking together
In order to improve the current implementation, updates to the Stacking contract are required. These changes are consensus breaking and need to follow the SIP process. The Stacks ecosystem is decentralized and anyone can write a SIP to suggest improvements! Once a SIP is accepted and recommended, it needs to be activated, which would require miners’ votes. More details are outlined in the SIP workflow.
To kickstart the conversations, we created several issues in the Stacksgov repository:
- Enable continuous stacking
- Unlock tokens that aren’t eligible for reward slots
- Enable multiple Stacking commitments per address
- Decrease the minimum commitment threshold
Did you observe any other critical peculiarities that need to be improved? Let us know what you think!