Brainstorming: Improving Stacking UX

#1

Hey Stackers!

I’d like to propose a second SIP, this time around improving the UX of Stacking.

Stacking is an indispensable part of Stacks. It’s awesome, and I believe it can be improved.

Here are the challenges around Stacking today, as I see them:

1: The variability of the Stacking slot minimum
2: The inability to remain Stacked for an indefinite # of cycles and unstack whenever you want

First, the variability of the Stacking slot minimum is particularly challenging for Stackers. Some Stackers will buy enough Stacks to get just the minimum amount and lock up for the maximum # of cycles (12) and then if the slot minimum goes above the amount they Stacked, they will be priced out of the cycles and lose out on a lot of Stacking rewards. In addition, this is just a confusing process and it seems like it could be simplified. I understand the rationale for a somewhat low number of slots, but it appears that having a floating number of slots is preferable to having a floating slot minimum. Fixing the slot minimum would result in a Stacking experience that is much easier to explain to people and much easier to work with.

Second, the inability to remain Stacked for an indefinite # of cycles is a challenge that results in lost Stacks for the cycle after you unstack. Let’s say you Stack for the maximum # of cycles (12) and then you want to repeat your stacking for another 12 cycles. You’ve now lost out on one of those cycles in between. You also have more work to do to keep your money working for you. There’s increased overhead. There would be a nice simplicity in being able to set your Stacking and forget it.

As a possible solution to these UX issues, I’d like to propose setting the slot minimum at a fixed amount, like 100,000 STX or 200,000 STX, and changing the Stacking rules so that one can start stacking and stop stacking whenever one wants.

With such a change, Stackers would be able to know precisely how many STX they need to lock up to get a full reward slot, and they’ll know how many reward slots they will have in any given cycle. They will also be able to easily enter and exit Stacking and won’t have to miss every 13th cycle.

1 Like
#2

A possible argument against the fluid stacking might be “Isn’t it good to force people to decide ahead of time how many cycles they want to lock up for so that supply can be removed from circulation?”. It may appear so but I would say this isn’t the case. If anything, a more restrictive lockup UX makes Stacks less attractive as a yield-bearing asset. Remember, capital often moves from one blockchain to another looking for the most attractive yield. If the UX is bad, capital will just be deterred from stacking to keep the optionality of selling (which has a quantifiable value based on volatility), and this capital may even move elsewhere if there are more attractive yield options that allow for simple staking and un-staking (on say Ethereum or Solana). Thus, the instinct to try to get people to commit early for as long as possible should actually backfire. Allowing people to voluntarily move in and out of stacking should actually contribute to the amount stacked at any given period of time.

2 Likes
#3

This exists because in general, Stacking can have at most two of the three properties:

  • Everyone who qualifies for a reward slot is guaranteed to be scheduled for a miner payout in the reward cycle
  • Everyone who qualifies for a reward slot will receive payment within a fixed amount of time (i.e. reward cycles have fixed length)
  • The amount of STX to stack to qualify for a reward cycle is fixed

The reasons the system design opts for points 1 and 2 but not 3 are as follows (in no particular order):

  • It was determined that a system with points 1 and 2, instead of 1 and 3 or 2 and 3, would lead to the “least-bad” user experience. A variable-length reward cycle would make it hard for stackers to reason about their yield long-term, and a reward regime that did not guarantee that all recipients who qualified for a payout received one would lead to more resentment than not qualifying at all.
  • Implementing variable-length reward cycles would have been very challenging if there was ever a reorg that required re-considering a reward cycle’s sortitions.
  • Stacking offers native support for pooling, which mitigates the impact of not meeting the minimum stacking threshold.
  • The dynamic minimum stacking threshold would, in practice, be somewhat predictable.
  • Stacking itself provides a use to the system beyond chasing APY: the act of stacking, especially for a long period of time, is a vote of confidence to nodes that the network is stable enough for PoX to occur. If a node (a) sees a lot of STX locked up, but (b) does not see a stable-enough prepare phase for PoX, then the node can deduce that upstream peers are withholding blocks from it (i.e. it’s being eclipsed).

We can of course revisit these decisions in a SIP, but I want you to know that they were not arrived at willy-nilly. There was a lot of public deliberation about them (on the order of months), and of course all of the code that implements it was written and reviewed in public. You can take a look at these github issues for some background if you’re curious:

This is coming in Stacks 2.1. The PR for re-stacking your STX while locked is already merged: https://github.com/stacks-network/stacks-blockchain/pull/2755. The issue for reclaiming your STX that are not contributing to a reward slot is slated for inclusion in 2.1 already: PoX Updates: `stack-unlock` · Issue #2534 · stacks-network/stacks-blockchain · GitHub.

5 Likes
#4

I believe continuous stacking is something that is being worked on for Stacks 2.1:

5 Likes
#5

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
#6

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
#7

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
#8

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
#9

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:

  1. Guaranteed Payouts
  2. Fixed Cycles
  3. 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
#10

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
#11

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
#12

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
#13

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
#14

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
#15

Yes, but of course this also applies to the pools themselves, which can often receive one fewer slot, regardless of how big they are.

#16

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
#17

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.

#18

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
#19

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
#20

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