Hiro’s Feedback on Stacking

[agraebe]

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.

Continuous Stacking

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:

1. Enable continuous stacking
2. Unlock tokens that aren’t eligible for reward slots
3. Enable multiple Stacking commitments per address
4. Decrease the minimum commitment threshold

Did you observe any other critical peculiarities that need to be improved? Let us know what you think!

[blockchain.id]

These are great recommendations for improvements!

[djh]

In terms of user experience continuous stacking seems like the highest priority; users who stack for one cycle don’t have much warning that they won’t be able to stack for the next cycle.

I wonder what the best implementation is – ultimately locked STX need to unlock while commitments are still being accepted. It seems like there could be a “grace period” where no stackers receive rewards and instead any Bitcoin used to mine the blocks is burned?

[larry]

I wonder if the current implementation isn’t better than continuous stacking. With continuous stacking, I can simply stack for 1 period at a time and decide at the end of each period if I want to renew. With the current implementation, I’m incentivized to stack for as long as possible so that I minimize missed reward periods.

[agraebe]

@djh I agree on the priority. Let’s figure out the implementation ideas on the GH issue. Would love to see others chiming in there as well!

@larry yeah, the incentive system for long-term commitments has strong benefits. I think ultimately this is a challenge of finding the right tradeoffs for all parties involved. I personally am looking at Stacking as a defi product. I think most staking products are very comparable and easily replaceable. I’m assuming that the majority of users will decide which solution to go with based on estimated yield. If the yield is outsized, locking up tokens for a long period is probably not going to be an issue. But if the yield is comparable to other solutions, the longer commitment is an additional burden that could impact their decision. I do understand it is beneficial for the ecosystem to have long-term stackers, but the limitation posed on users might reason them to go with a different ecosystem.

I personally am in favor of lowering the barrier to participation. If someone almost finished one cycle and decides to participate in more cycles, a “penalty” seems not beneficial for anyone. It does require a more competitive staked solution and likely warrants more thoughts on differentiation. One idea could be to periodically increase reward slots for folks that commit to more cycles. That could result in more flexibility for the user and an incentive to stack longer.

[djh]

I like this framing – I agree with @larry that the incentives are better for the network in the sense of driving price upward in the current implementation, but it’s more difficult for typical users and might engender some bad feeling. Long term, a better user experience and correspondingly, more users, will drive the network’s health.

[larry]

@agraebe

One idea could be to periodically increase reward slots for folks that commit to more cycles.

Great idea!

@djh

Long term, a better user experience and correspondingly, more users, will drive the network’s health.

Yes!

[jude]

Hi Alex,

Unlocking tokens that aren’t eligible for reward slots

Any solution to Stacking can have at most two of the three properties:

• The amount to lock up per Bitcoin address is static
• Every reward address will get paid per cycle
• Every reward address gets paid in regular intervals

In the interest of minimizing design complexity while keeping users happy (because who doesn’t like getting paid?), we omitted option (1) in favor of (2) and (3). This means that there will always exist the possibility that the number of reward addresses you think you’re going to acquire at the time you lock your STX can shrink – possibly to 0. But, after my own discussion in response to an earlier discussion, the blockchain team came to consensus that option (1) was the “least bad” option we could take, given the available amount of engineering bandwidth. In particular, we convinced ourselves that Stacking is likely going to be a “static” behavior, where most people lock up for a long period of time, and adjust their STX lock-ups accordingly (knowing full well that they aren’t going to be able to spend them).

I think there is room for improvement that at least mitigates the risk of you locking your STX for nothing, but any change to the PoX contract (including this) will have to wait for Stacks 2.1. We’d probably also want to spend some time auditing the incentives going into PoX participation if we’re going to change it at all.

If people really, really, really want the option to sell their STX while they’re locked up, it’s entirely possible to write a smart contract that will Stack your STX for you, and mint you a “STX future” token that can be traded on the secondary market. The bearer of a STX future token can redeem your STX from the smart contract when they unlock from PoX. This wouldn’t require a hard fork.

Multiple stacking commitments per address
Stackers, eligible for multiple reward slots, would like to use different Bitcoin reward addresses

I don’t think I know what you mean here, but I’m guessing that you don’t want to reuse the same reward address if you qualify for multiple PoX reward address slots? If so, then I think this can be solved with 3rd party exchange or custody integrations – you’d put your exchange/custody service’s address in, and they’d take care of distributing your BTC to your individual addresses. You could even require that the 3rd party exchange uses a 2-of-2 multisig address, to which you have one private key, so both you and the exchange must first agree on the set of recipient BTC addresses before distributing them.

Stackers would like to increase their existing commitments to ensure being eligible for increased reward slot thresholds in the future

Doing this natively will require a hard fork, or Stacks 2.1 (due at Bitcoin block 700,000). But I think you can work around this, too. I could imagine a service that Stacks a whole bunch of STX, and rents out the locked STX’s reward slots at a fixed rate to Stackers via a smart contract. You put the rental fee into the smart contract (which is held in escrow), and you indicate the already-allocated reward address you want to rent and a target reward address (your address). Then, when the service receives BTC to the rented reward address, it transfers it to your target address.

To obtain the rental fee, the service would need to submit the raw Bitcoin transaction to the Clarity contract along with a Merkle proof that proves that the transaction was mined on the Bitcoin chain (this is a great use-case for Clarity having visibility into the Bitcoin chain, btw!). Now, you’ve got your Bitcoin, and the service only gets your rental fee if they actually deliver the Bitcoin to you. If they fail to do this after an allotted time interval, or you withdraw your rental offer, you get your fee back.

Stacking commitment threshold

See the trilemma discussion above. Also, Stacking has native support for delegation. Users can combine STX holdings that individually total less than one reward address slot, and collectively Stack them to acquire one or more reward addresses. They would use a Bitcoin multisig address to ensure that no one can just run away with the BTC.

[argonau7]

I believe this implementation needs to happen ASAP. It is very bad UX to lose out on a cycle simply because one is worried the minimum threshold might go up significantly. This is especially important for smaller holders, e.g. the “community”. It ought to be implemented as fast as possible. It is frustrating to wait another cycle.

[pb15654]

Continuous Stacking works best for me. I look at my Stacks Investment as what I would have paid for Mining Hardware.

[avik]

There’s clearly a need for improvement. There are several considerations here:

1. UX, as argonau7 says. To yield farmers and others fluent in staking, the one-cycle-off and minimum threshold quirks are not intuitive, and will turn a lot of people off from joining the community.

2. Incentivizing network security & scarcity. On the other hand, the one-cycle-off feature incentivizes long-term stacking, which is good for network security and token value.

It seems to me that there are ways to blend these two objectives, like so:

A. Clear disclosure. The Hiro wallet and other stacking wallets should make very clear that the number of cycles you choose to stack for matters, because you have to take one cycle off before re-stacking. This was not at all clear when I first stacked on the Hiro wallet. Clear disclosure also eliminates the need to fork the protocol to make changes here.

B. Make it easier to top off your stacked wallet. The biggest disincentive for long-term stacking right now is that if I stack 80k STX for 12 cycles, and somewhere in between the minimum threshold changes to 90k, I’m SOL because I have to put in a minimum of 50k to top off the wallet. This minimum should be decreased to 10k, and I should be able to top off in the preparation phase of the cycle so as to prevent discontinuity of my stacking.

C. Semi-official stacking pool. While it’s great that Friedger and OKCoin are sponsoring pooled wallets, it seems to me like it would be beneficial for Hiro or some other non-profit/PBC to sponsor a stacking pool. While stacking pools contribute to centralization, under the current protocol they’re the only way for retail investors to participate in stacking (which is critical to the growth of the community).

[Rapha23]

Feedback from stacking with amazing Friedger pool.

This indefinitely option is misleading IMO

-> so if I decide to stack for 12 cycles and indefinitely, and I don’t revoke, then, 12 rewards + 1 cool down and automatically enroll in another 12 rewards

-> so if I decide to stack for 1 cycle and indefinitely, and I don’t revoke, then, 1 reward + 1 cool down and automatically enroll in another 1 potential reward for 1 cycle

Indefinitely = please enroll me back at same conditions automatically like a subscription

IMO, the FAQ should mention that if you don’t revoke and you’ve chosen indefinitely, you will be enrolled at same conditions automatically and your tokens will be locked / stacking at same conditions (could mean another 12 cycles if that was your subscription).