OK it just sounded that way to me.
All I’m saying is we should explore if and how we can match the UX of Ethereum or Solana staking.
I don’t see any reason why we couldn’t and we should keep this conversation going to push as hard as we can to get it done.
Massive improvement that will bring many new users to Stacks and grow the ecosystem.
I think there was some legal theory behind it which is sort of irrelevant now, given how decentralized the ecosystem is now (vs. for example before the mainnet launch). Also, more importantly Stackers ended up doing work by locking up capital vs actively running nodes and doing some other type of work (like sending validation transactions). The earlier legal theory was applicable to a different situation I think (some features/situation that never went live on the network).
In short, the earlier stuff is not applicable anymore as the actual design that went live and the market reality turned out to be different; we can think outside of the original assumption now 
I agree with @ryan that the simplest UX is “start stacking” and “stop stacking”.
It’d be interesting to brainstorm how close we can get to that UX. The current improvements in 2.1 release still have a concept of cycles for which you’re locking STX.
Yep, and the 4 outputs per transaction should be totally OK as far as Bitcoin fees are concerned.
Ryan, I think to make the proposal more concrete the next step would be to write it up as a formal SIP. Until there is a formal SIP submitted, it sort of remains a brainstorming discussion on the forum.
The ecosystem is expected to come to a cadence of network upgrades every 6 months or so, it takes quite a while to get through the SIP process, do implementation, get code reviews, voting, miner adoption etc so getting a head start on the SIP can be helpful!
Agreed this is the simplest UX. I wanted to add some additional context around questions earlier in the thread about the current design, and call out some things worth thinking about when contemplating any changes to Stacking – there are non-legal factors at play:
Thanks diwaker, great to get your input.
Yeah we indeed. I don’t think these attack vectors are made more easy with such a change, but we can do more analysis to confirm this.
To be clear, I do think that a design without cycles is superior aka one with a continuous rolling window.
That said, I know that is a bigger change and I wasn’t actually suggesting we get rid of the cycles.
I was simply suggesting we simplify the stacking actions / interface to two simple actions: “start stacking” and “stop stacking”.
The stacking would still start at the cycle after the “start” transaction, and it would end after the cycle that contained the “end” transaction.
We can always also explore having a rolling window instead of cycles but I am not proposing or discussing that here. Let’s save that for a different discussion.
I understand this perspective. That said @diwaker what do you think about my claim that the effective minimum to stack today is 1.3M stx?
To me, part of the reason we only have 200 stackers is that it doesn’t become economical until one has 1M+ stx.
So you can’t use the low number of stackers as evidence that few people would be helped.
Everyone is driven into pools or driven away by the weird interface and that’s why we have so few.
If you lower the effective stacking threshold from 1.3M stx to 200k stx you will increase the number of stackers and you will make solo stacking more accessible.
You will also make it so that a 13M stx mining pool doesn’t have a financial disadvantage (via slot rounding) vs a 20M stx stacker.
Two points I want to hammer home:
These points both seem predicated on the absence of the ability to unlock STX that haven’t clinched a reward slot. Is my understanding correct? Asking because this is getting added in 2.1, which I think will reduce much of the pain people currently experience here.
I’d like to understand what the pain level is in the presence of this new feature.
This still doesn’t solve the problem.
Imagine you have 100k stx and then you buy 30k stx so you can solo stake. Now you get kicked when the slot moves up to 140k.
Ok you’re out of money bc of the markets so you decide to enter the pool. Now you have to wait until the next cycle. And you have to go through the pool transactions.
More friction.
Do the fixes in 2.1 allow you to recover when you hit the slot change issue? Yes. Do they remove the problem entirely? No.
To be clear, I’m in support of pushing through improvements like those made in 2.1.
I just don’t think we should say mission accomplished with it and not have a plan for 2.2 when the problem still persists.
Especially when there’s a pretty clear and simple solution with no major downsides.
My two cents as someone working on a project that aims to leverage staking across various chains: as mentioned above, it would be amazing if Stacks could match the UX of Ethereum or Solana staking. A fundamentally different UX on Stacks (such as the non-fixed slot minimum) makes Stacks more complex and less attractive than other chains. As muneeb said: “the simplest UX is “start stacking” and “stop stacking”.” 
Hey everyone,
Thanks a lot for the fruitful discussion and I’m glad that this is taking place.
I would like to share some personal experience regarding Stacking UX. I know most of these issues are already discussed above and some will be addressed in Stacks 2.1 but this is how I’ve been observing PoX and stacking in general over the past year.
Note that, I’ve been actively playing around with other protocols and chains as well and naturally compare them to each other.
1) Stacking vs. Staking
Since I’d already played around with protocols other than Stacks, the term “Stacking” was a bit strange. I dived in technically and understood it and could then differentiate them pretty easily.
I’ve then onboarded several more people in Stacks and guided them to join pools and start Stacking. They never get used to the term Stacking and the keep getting confused which is what. This is particularly the case for those who have experienced DeFi on other chains.
2) Stacking Cycles
I got used to it eventually. However, I did miss a few slots because I forgot to re-stack which was innefficient.
My capital inneficiency was amplified by the fact that I did not want to lock in STX for longer periods as I didn’t want to be illiquid for more than a certain time frame. Therefore I missed out on the several cycles due to cooldown period.
I was also on the edge of the minimum threshold and I was eventually priced out of stacking for a few cycles until I could join a pool once my funds were unlocked.
Finaly, with the pool I once mistakenly stacked for 6 months instead of 3 months (which I intended). Of course that’s a calculation mistake on my part (given that cycles are 2 weeks and not 4) but still I was illiquid on that balance for much longer that I had planned out.
3) Rewards
This didn’t happen to me. However, one person that I onboarded in Stacks, started stacking around 500K STX. He was new to DeFi and wasn’t really looking for yield opportunities elsewhere. He was quite happy with the BTC yield he was getting.
Two things happened:
Which lead him to fully leave and participate in other ecosystems. What visibly triggered him was missing out on rewards for some cycles.
Overal, I believe there is room to improve stacking from a usability perspective particularly compared to other chains. This makes it easier to onboard the users who are already familiar with staking functionality as well.
Yes I would love to see “Start stacking” and “Stop stacking” utility. They can still start and stop with cycles starting and stopping.
I think if we have that we do not need stackers to signal to miners they think the network is reliable for another 12 cycles. The problem with that is that those stackers have no way to signal miners if their idea changes mid commit. What if they think the network is not reliable after 6 cycles? They are locked in…
If it is just a start/stop stacking system everyone on the network will be much faster to respond to changing sentiment.
I also think we do not need to stop using cycles for this but simply starting and stopping with a max delay of finishing the current cycle would suffice.
Continuous stacking for Stacks 2.1 gets us close but it would not be exactly the same because you can lock for 1 cycle and restack without the current cooldown cycle. If pooling with Friedger remains the same, the operator would restack for you automatically as long as you do not revoke the delegation so it would not even require an action when delegating. Stacking on your own though, I expect you’ll have to restake manually every cycle, which is not great UX.
If everyone only starts/stops it would simplify operations for many parties involved (stackers, pool operators, devs). Pool operators do not even offer all number of cycles options (1 through 12), it is simply to cumbersome. For example on Okcoin you can stack for 1 or 12 cycles only. With Xverse you can commit for 6 cycles at most. Does that mean an Xverse user does not trust the network beyond 6 cycles?
Just want to point out that you can outsource the task of re-stacking your STX by delegating to a smart contract to stack on your behalf, and having someone else send the transaction that has this contract invoke stack-stx as your delegate. This itself could just be a cron job, and the contract could act as a delegate for many stackers. You can do all this today without a breaking change. With 2.1, you won’t even have a cool-down cycle – the service can just keep re-stacking your STX as long as it’s authorized.
Then, start/stop stacking is the act of authorizing/revoking the contract as a delegate.
Btw, I think this would be a good candidate for a Stacks Foundation grant.
You’re saying that the typical stacker should just run a cron job?
I’m having a hard time understanding what you’re suggesting here - that bad UX can be overcome by a user being extremely technical and writing their own custom software to make up for the shortcomings in the underlying protocol?
I think you’re actually implying that someone can write the code, like what happened with mining pools, and then others can join. Of course, again, this adds quite a bit of additional friction and UX complexity. Even if wallets can theoretically build in pool support and re-stacking support, I don’t expect this to actually occur or to result in as good of a UX, because of the extra steps required.
That is very much not what I said. Please re-read my comment. Specifically, the very first sentence:
Emphasis mine. Only one technical user needs to do the legwork of setting up the delegate contract and cron job. Everyone else can delegate to that contract to get automatically re-stacked.
You’re in luck: the wallet already supports delegating and revoking delegation, which is all that is required for this to work.
To reiterate, I support the updates in 2.1.
I just do not support a “mission accomplished” attitude.
We can keep improving stacking and we should, and we have some ways to go, even with the 2.1 improvements, before we are at parity with the user experiences of the staking in major chains.
The more I feel like people are pushing a narrative that 2.1 solves the issues or is good enough, the more I feel the need to highlight how large the issues really are and how they will persist with 2.1.
Let’s consider 2.1 a step forward and keep on planning future updates that make stacking even better.
I know that a lot of this is just a conversation right now, and we’ll have more concrete things to critique when they are written up in sips.
I want us culturally on the same page, and I want us to value improving the user experience and not stopping at “good enough.”
In an ideal world, yes – we should write perfect software that perfectly addresses every last facet of every single problem, no matter how small. But that’s also not how software engineering works in practice. Your suggestion that we have a culture of “mission accomplished” and “good enough” feels like a gross misinterpretation of the facts on the ground. The culture we are building is one that prioritizes decentralization.
This is not news to you, but I’ll say this here anyway because not everyone reading this writes software for a living. As with most large-scale multi-stakeholder software projects, there are more things to be done than we have person-hours to do them in. So, we make design trade-offs and prioritize features in order to make the most of the resources we have, and accept that there’s no feasible way to make everyone 100% happy. Complicating matters, we’re building a blockchain, where the act of shipping breaking changes is inherently costly because we have to convince the vast majority of users, miners, exchanges, and wallets to upgrade before they can take effect. We do our best to give every issue due consideration, but that is not a guarantee of implementation.
You might not know this, but most of the person-hours available for blockchain work are being spent on hyperchains. The reason for this is because adding the ability to handle a sudden unbounded volume of transactions (which could hit at any time) is considered to be a far more important thing to do now than improving the stacking UX. You might not know this either, but the person-hours being spent on Stacks 2.1 are aimed at fixing a host of other issues that are also more considered more important, such as unblocking bridges, unblocking oracles, unblocking mining pools, fixing the UX of stacking and transferring STX via the Bitcoin chain, fixing the mining window calculation (which affects profitability), removing the PoX sunset, and adding the requisite support for multiple versions of Clarity. There is some time allocated to improving stacking through the means I have described, but not nearly enough to do what you propose.
You may disagree with this prioritization, but you are not being asked to accept this state of affairs either. As with all open-source projects, the fastest way to get your preferred features shipped is to do it yourself. In fact, you may recall that in some of the advice I give for addressing your issues, I end it with something like “you can do this today” or “no breaking change is required.” That is meant to empower you. I’m telling you that you can do something about it without going through a costly chain upgrade, or even submitting a PR. For example, you do not need to get anyone’s permission or buy-in to add “stack/unstack” functionality if you follow my implementation advice on it above.
I can’t help but think that this is a euphemism for “you all should drop everything you’re doing and work on my preferred UX issues right now!”
No one opposes improving UX in principle. And as you acknowledge, we are making some progress on it in Stacks 2.1. We will make more progress on them in 2.2 as we learn how well (or not well) the improvements in 2.1 are received.
However, the inescapable facts of the matter are that while the issues you raise are important, (1) there are other issues that may be more important, and (2) you do not get to decide what is and is not important when it comes to breaking changes (none of us individually do). To speak to that latter point, the community as a whole decides what breaking changes take effect when they choose whether or not to upgrade their nodes (and the SIP process is designed to help this go smoothly).
These facts should not be confused with opposition, nor with a culture of “good enough; mission accomplished!” nor with a political “vetocracy” as you have suggested elsewhere. The community runs the nodes, and in doing so, the community decides what issues are important enough to warrant a breaking change, and the community decides whether or not a breaking change happens. That is, I believe, the essence of a culture that prioritizes decentralization. The SIP process is merely a tool to help the community make these decisions in an open, public, verifiable manner, and it is not the only such tool.
All that said, I am glad that you took the time to bring this issue and others to the community’s attention on the forum. Now, if you would like to get them shipped sooner rather than later, there are some concrete steps you can take today:
You can start coming to the weekly blockchain engineering call. We do network status updates, issue triage and PR discussion. It’s every Monday at 11am ET (you can get the link on discord).
You can start coming to the bi-monthly blockchain architecture meeting. It’s every other Friday at 2pm ET. This one is better for discussing breaking changes. The link is also available on discord.
You can start coming to the weekly SIPs call that we’re in the process of setting up at the Foundation.
You can start coming to the bi-monthly governance call. You can get the link from discord.
For non-breaking changes, you can implement a prototype. You can spin it up on the public testnet, or even mainnet if you want. You can invite people to try it out. You can submit a PR to the blockchain reference implementation if you think the code belongs there. Or turn it into its own product or service instead if you feel like that’s more appropriate.
For breaking changes, you can take the time to write up a SIP. You can inform the community of the nature and scope of the problem, and motivate its severity with supporting data. You can argue that your proposed solution is the best solution out of all alternatives. You can implement your preferred solution and release it as its own testnet. You can put your SIP through peer review to get it to Recommended status, at which point it can be prioritized for inclusion in the next breaking change release. You can submit a reference implementation PR to the blockchain once it’s ready to be activated.
You can keep the community posted on the forum as to the progress you’re making.
Stacking.club has a lot of this data, can be referenced by going back to other cycles. You can see the number of addresses that missed each cycle due to the minimum.