Regardless of outcome it is really awesome to see the community rally around improving stacks and build dashboards etc. This is great energy and very good for our project. Will be curious to see with the data the actual scale of the problem and whether it’s worth taking next steps.
2 Likes
One really important point I want to make so that people fully understand the implications of the floating slot minimum.
There may be a floating minimum of 130,000 right now, but the effective minimum is the one where you can expect to not lose a large % of your rewards due to an increase in the slot minimum.
Thus, if you’re willing to take a 5% loss on a slot change over your 12-cycles (slot changes over that period are very likely), then the effective minimum for efficient stacking is actually 1,300,000 STX. And it’s 5x higher than that if you’re only willing to take a 1% loss on the average cycle change.
Thus, I want to frame this proposal as a way to increase the effective minimum.
If we were to increase the minimum to 200K, we’d be decreasing the effective minimum from several million STX to 200K because with a static minimum, the stacker wouldn’t incur loss due to any slot variability.
Yeah really amazing to see the community step up to help. I’m super excited for the dashboard.
3 Likes
So you’re saying a simple fix is just to increase the minimum to a level where it can be completely static so Stackers are unlikely to ever lose rewards from the shift?
Yea exactly
Just a general comment here that it’s great to see so much discussion on this topic!
There are several good ideas here. I’d just pass along some feedback I’ve received over the last year (from exchanges, pool participants etc). By far the biggest UX issue people have is the “cool down period” and missing stacking cycles. My input would be to treat that as the #1 problem to solve first (I think the continuous stacking work does this but hasn’t been pushed live for a while now).
Ryan’s idea of increasing minimum is interesting because we know what the STX supply is going to be in the coming years, so if we just increase the minimum once to a high enough number then we reduce the cycle-to-cycle variability (for several years to come) and people below the minimum would just go to a pool. I think that’s a small change with great UX benefits.
1 Like
This is already fixed in the next branch, which will become Stacks 2.1.
1 Like
In a bid to reduce confusion and the associated acrimony, I have changed the title of this thread to Brainstorming: Improving Stacking UX to better reflect the nature of the conversation.
This also means that as long as the floating minimum is less than 200k STX, this proposal is taking away reward slots from everyone. Why should we expect users to be happy about this?
Jude see this below. The effective slot minimum (where you can stack economically) is 1 million STX+. The proposal would essentially be reducing the effective slot minimum from 1M STX to 200K STX.
Nobody can stack with 130K STX without expecting massive losses due to slot minimum changes within a 12 cycle period.
Yes, missing Stacks cycles is probably the biggest issue.
As @jude said it sounds like that is being addressed in 2.1. Is that with indefinite stacking? Or the ability to extend beyond 12 cycles?
Yes, exactly. We could increase the minimum to 200K STX and have 4 outputs per transaction and it would be high enough such that it would never need to be changed. 100% of the 2B STX in existence could Stack and the minimum wouldn’t need to change.
Yes, agreed. We’re fixing that in 2.1 by updating the .pox contract so that users can unlock the STX that aren’t being put to use acquiring a reward slot. I’m not saying that that’s the perfect solution, but it does decrease the impact somewhat.
It’s the ability to re-up your stacking while you’re still stacked. You’d still be extending only up to 12 cycles, but you’d be able to do so on your already-stacked tokens (so in the limit, you could re-stack for 1 cycle, once per cycle). The limit on 12 cycles is in place because the act of stacking provides a signal to nodes that the STX-holders believe that the network is stable (so we need people to re-stack periodically).
OK, this helps a bit, but why not just make it so much simpler and forget the 12-cycle maximum and extending and all that?
You can just have two actions: “start stacking” and “stop stacking”.
It would greatly simplify the system and greatly improve the UX.
At some point, it was decided that the act of receiving PoX rewards had to be treated as payment for performing some kind of active work for the network, instead of just being passive income. I think there was a legal reason for it.
OK that may be but this doesn’t sound like it makes any sense. Ethereum and Solana and all the other chains have fluid, on-demand locks and unlocks. And this is a big part of why they have better Staking UX than Stacks does with Stacking.
True, but if there was a legal reason for it, then I don’t know how much we can do about it at this time.
I would revisit it and ask who and where this rationale came from because it doesn’t fit with everything else / all the other legal opinions we’re seeing in the space.
I think it had to do with how the token was sold in the US, but I’m not really sure – I wasn’t part of any of those decisions. I’m probably not the person to ask to revisit them either, since I’m not a lawyer, and I don’t know the legal implications of trying to change the way the system behaves in this capacity (like, even if we could get a SIP ratified to change it, it might make the resulting system illegal to operate in the US). I just don’t have the background to build confidence in a decision to remove it yet.
1 Like
Considering that:
- There is precedent for this exact UX across other blockchains
- This is a decentralized network and there isn’t a single company whose counsel matters here
…it makes sense to me to move on from any hearsay about legal blockages about fluid lock-and-unlocking, and consider it seriously as a proposal. It doesn’t need to be approved, but just not shut down.
I’m not trying to shut it down 
I’m merely relaying what I know about why the system works this way, and explaining why that creates enough ambiguity around it for me that I’m not 100% on board with it right now (but that’s not to say I’m against it either – I’m neither).