I believe continuous stacking is something that is being worked on for Stacks 2.1:
5 Likes
There’s a comment related to this in another thread that seems to address this point: Proposed SIP: Modify Coinbase Reward Per Block and Halving Schedule - #14 by incite.btc. Making PoX rewards the highest-yield activity you can do with STX could have the disastrous side-effect of choking Stacks defi projects of capital (because why would you put your STX there when PoX has a higher yield?). We’d want to model this of course if this discussion proceeds to a SIP, but it is something to think about. Per my above comment, PoX serves to help nodes deduce when they are eclipsed (i.e. stacking helps the network be stable); the yield is a nice side-effect.
1 Like
Thanks Jude! Great to hear that re-stacking is already being included. And thanks for pointing me to this. I’ll read the rest of your points and address them shortly.
2 Likes
Yes, I’m not arguing that Stacking should be insanely high yield. I’m simply arguing that missing every 13th cycle is unnecessary. Great to hear that continuous stacking is already being incorporated.
1 Like
Yes, thanks for re-surfacing these Jude, I had reviewed some of the discussions but I’ll give these a deeper read.
You say the following in your GitHub post:
To make this the case, one of two things needs to happen:
- A Stacker’s STX automatically unlock if they do not earn any reward address slots. Then, there’s no consequence for Stacking early and getting priced out of all reward address slots by the time the next reward cycle begins. However, if a Stacker manages to acquire at least one reward address slot, then their STX need to remain locked (even if the number of slots is less than what they wanted). This is because we don’t want Stackers to artificially drive the price of Stacking up, either.
- The minimum Stacking limit needs to be static. If this were the case, then there are no games to be played, and everyone who Stacks does so with the full knowledge that they’ll receive BTC (or not).
The former definitely solves the issue of getting your Stacks back if you don’t meet the slot minimum, but it doesn’t address two problems. First, the Stacker still is out of luck on this cycle and doesn’t get the rewards, so it’s a consolation prize but not super satisfying to get the Stacks back but not being able to stack. Second, it still creates a “remainder” problem whereby if you have enough stacks for 2 cycles but then the slot minimum goes up by a bit, you now have only a single slot and you either miss out on the second slot with your stacks locked up or you get a single slot worth of stacks back and still miss out on the rewards. This to me is not a great UX. A better UX would be to make the stacking limit static.
1 Like
Yes, this is indeed the tradeoff, and in my opinion, knowing that you’ll be able to smoothly participate across a long time horizon is way more important than whether or not you get a given amount of stacks in a given period.
Let’s refer to 1, 2 and 3 as:
- Guaranteed Payouts
- Fixed Cycles
- Fixed Thresholds
Prioritizing Fixed Cycles and Fixed Thresholds over Guaranteed Payouts to me is a much better UX.
Why?
Because it still probabilistically guarantees the same payout over a larger # of cycles, and it avoids all of the confusion, UX issues, and refunding required to service a Floating Threshold.
I think we can do even better though.
If we set the Fixed Threshold somewhat high, say 200,000 STX, then we can guarantee that every stacker gets a slot for every cycle as long as the total amount stacked is under 745M STX.
Further, we should research whether it is possible to include more than one slot per Bitcoin block. I believe this is possible, and I’ve postulated a solution to this earlier:
If we can have mining service more than one slot per Bitcoin block, then we could have every Stacking address get paid out more than once per cycle per slot.
Thus, you’d have a floating # of payouts per cycle, that could shift between let’s say 4 and 5.
On average, across enough cycles, everyone would get the same amount paid out, and everyone would get paid each cycle.
1 Like
Stacking pools fix this issue for anyone that has just enough STX for 1-2 slots. For people with more slots it could mean getting 1 fewer slot and just not being as efficient.
2 Likes
Do we know what percentage of stackers are nonpooling? They would be the ones experiencing the inefficiency.
If it’s a large percentage it may also be worth getting a distribution curve of of stacking balances so we can get a rough estimate of whether this is a large percentage of people for whom losing a slot would mean a large drop off of their rewards.
1 Like
As someone who stacks individually I disagree with this. I would rather take a floating minimum with guaranteed payouts every time. What are you basing these UX issues on? I haven’t heard any actual feedback that this is a problem of any meaningful priority, especially with the improvements coming in 2.1.
1 Like
In the current cycle there are 169 non-pooling stackers and ~5000 pool stackers using data from stacking.club Cycle #34 — stacking.club
1 Like
With the current UX, you have to guess how much you need each round, which could change at the last minute. You’re almost guaranteed to have leftovers which reduces you’d yield. And you have to be more actively managing your stacking to maximize the yield and not lose out on whole percentage points of the maximum rewards you could receive. Further, with the refund option if you miss a slot, this is another burden for the stacker.
So yes, I am absolutely saying a “set it and forget it” option with a higher apy across cycles is a much much better UX.
1 Like
Yes, but of course this also applies to the pools themselves, which can often receive one fewer slot, regardless of how big they are.
As I also mentioned above, I think it’s possible to both have a fixed minimum and also have every slot get paid out multiple times per cycle.
1 Like
Pools with 1M stacks experience the same inefficiency as firms or individuals with 1M stacks. So there is no group that is immune to the inefficiencies and slot missing. Plus they may still be refunded from the pool when the pool is refunded. All the same issues apply.
The UX challenge is probably less with the dynamic threshold, and more with committing to a certain number of cycles that aren’t guaranteed. If I commit 100k stacks for 12 cycles, a pleasant experience would be to receive those 12 cycles regardless of the minimum changing.
I commit to you, you commit to me kind of thing. I think that’s probably more in line with what a user’s expectation would be. Without having thought through anything protocol level, it might create interesting game theory when the minimum suddenly drops – more people would rush in and commit to take advantage of the opportunity.
2 Likes
I second this concern. Now that the system is live and carrying hundreds of millions of USD of value, I think we’d want to see some pretty convincing UX studies done that conclusively show that this is indeed a painful enough problem that completely re-doing the consensus algorithm is a worthy solution.
1 Like
Why should someone stack if they’re not even guaranteed to be paid, let alone in a timely manner? This is probably fine for the largest stackers, but it would suck for smaller stackers. Isn’t it important to be able to reason about near-term cash flow? Do you have UX data to suggest that this is what most stackers actually want?
Miners service two slots per Bitcoin block during the reward phase. Not sure if you knew that.
Also, it’s important that the number of slots paid per block be consistent over the course of the reward phase (i.e. independent of stacking), because it means that miners pay the same transaction fees regardless of how much participation there is. If this weren’t the case, then miners would have an incentive to prevent people from stacking because it would make mining cheaper for them. Like, miners even pay to two burn addresses at the end of the reward phase after the reward set has been cycled through.
1 Like
They would be guaranteed to be paid, as I’ve mentioned above.
Keep in mind that with my proposal, everyone’s cash flow would increase by multiple percentage points.
We could collect some UX data for sure.
Yes I know very well and I’m suggesting it be increased beyond that.
Yes it would be in my proposal.
Yes agreed, and there are a few ways to accomplish this.
For me, the simplest way is to have a very basic static minimum of 200K STX and then have 4 payout addresses per block instead of 2 payout addresses per block.
Every address would be paid at least once in every single cycle.
And every stacker would receive an APY boost that is quite significant because they’d have full utilization of funds in the cycle.
I want to stress this more ^ The APY boost for small and large stackers alike is something that everyone should be interested in.
Then you’re giving up fixed-length reward cycles.
I can’t support doing that, because it would prevent us from addressing a far more serious concern having to do with dealing with the fall-out of a PoX anchor block getting mined, but not broadcast to the network until a much later date. Namely, making reward cycles variable-length makes two conflicting histories of reward cycles incomparable, which prevents the system from assessing which reward cycle represents more work. See this issue for details: Absent PoX anchors should be "forkable" · Issue #1805 · stacks-network/stacks-blockchain · GitHub
1 Like