Stacking pool operation in Stacks 2.1

[jcnelson]

I had a question from @hstove about the possibility of adding a multi-stack operation in pox-2. Essentially, the function would permit stacking a given amount of uSTX to a list of PoX addresses on one go. I'm making my assessment public, since it's pertinent to the community.

The proposed interface is

(define-public (multi-stack-stx
(pox-addrs (list 4000 { version: (buff 1), hashbytes: (buff 20), amount-ustx: uint }))
(start-burn-ht uint)))

This was a topic we talked about in person at Bitcoin Unleashed 2022. The purpose of a multi-stack operation is to make it so a stacking pool operator can rent out their reward slots to users, and stack the pool's STX to its users' PoX addresses. Having had time to digest the proposal, I'm writing my thoughts down here.

---

So, the challenge with doing something like (multi-stack-stx) natively is that there doesn't seem to be a good way to deal with the (very likely) case of when the reward slot size changes at the last minute.  I can think of different conflicting ways to handle this case, but none appear to be the right thing to do 100% of the time.

For example, suppose I have 10 million STX I'm stacking, and the reward slot minimum is 100,000 STX.  So, I'd expect to get 100 reward slots at the time I send my transaction, which means I'd supply a 100-item list for pox-addrs to have them each stack 100,000 STX.  But then suppose at the last minute, the stacking minimum gets bumped to 110,000 STX.  What's supposed to happen?

• Does the whole operation fail to lock any STX?  Each address's amount-ustx could be beneath the stacking threshold if it were applied, so this is a plausible behavior.

• Does the whole operation succeed, but lock the STX in a useless way?  100 addresses with 100,000 STX locked into them will receive zero BTC yield. It's not clear who would have the right to call (stacks-unlock) in this case.

• Does the operation partially succeed?  Suppose that the act of stacking the caller's STX is what pushes the stacking minimum to 110,000 STX (like, what if the 50th item in the list of 100 addresses is what pushes the global threshold over). Do some entries in the list clinch a reward slot, and others not?

My counter-proposal to this was to implement the pool as a set of contracts: one contract to manage rentals, and a set of sub-contracts to perform the stacking with the pool's STX. The sub-contracts can only be called by the manager contract, and are indirectly called by the renter to stack the pool's STX. The flow would look like this:

• Make the user rent the STX, not the reward slot. Then, it's up to the user how much STX they think will be needed to secure the desired number of reward slots. The management contract sets a per-STX rental fee (e.g. pay 1 STX to rent 100 STX or something).

• When the user secures the right to borrow the STX from the pool contract (i.e. pays the rental fee; is the highest bidder; etc. -- however this works), the user calls a function in the pool contract that does the following:

  • Authenticates the user by verifying that they paid the rental fee for the STX they want to use in this upcoming cycle.

  • Reclaims the requisite STX from "fallow" sub-contracts that hold STX from a previous renter, but are not stacked (such as by a (stacks-unlock) call or a (stx-transfer?) call that transfers the STX from the sub-contract back to the management contract).

  • Find and allocate an unused sub-contract to the user

  • Moves the requisite STX from the management contract to the sub-contract

  • Calls a function in the sub-contract to stack the STX. The sub-contract does the call to (stack-stx) via (as-contract) so it, not the user, is the stacker. Note that this function is only accessible from within the management contract -- the user can't call this directly.

• As the reward cycle progresses, the user receives BTC if they clinch one or more reward slots. If they don't clinch a reward slot, then they're simply out the rental fee (and that's on them -- they should have rented more STX).

This could work today, and it's all self-service. This is because all STX movement and stacking happens within a contract-call transaction submitted by the user. There's no need for the pool operator to scatter/gather the STX, and no need for the pool operator to stack STX on the users' behalves.

[hstove]

@jcnelson , thanks for putting this together!

So, the challenge with doing something like (multi-stack-stx) natively is that there doesn't seem to be a good way to deal with the (very likely) case of when the reward slot size changes at the last minute.

Totally agreed. The way I would solve is to not rely on any specific slot size, and instead only do this in "chunks" of say 1mm STX. I've done research on the optimal chunk size for economic efficiency based on various slot minimums, and I think it's around 1.5mm. You still end up having complexity regarding how many STX the principal can unlock based on the final slot minimum. In my opinion, it's OK to not allow this STX to be unlockable, because the pool users would need to signal their desire to unlock in the next cycle. I admit having this kind of exception doesn't help with complexity.

I do agree that using sub-contracts is a potential way to solve for this issue, and that this could technically be done today. However, any solution would be best designed for 2.1 (with stack-extend), so that the pool can maximize efficiency.

Following your described solution, you'd still end up needing a fixed "chunk" size of STX per sub-contract. Otherwise, you end up in a scenario where some sub-contract has locked STX, and in the next cycle that sub-contract needs to move some of it's STX to a different contract in order to be stacked. Ex:

1. In cycle 1, renter A rents 1mm STX. The STX are moved to sub-contract A and is stacked for cycle 2.
2. In cycle 2, renters B and C rent 500k STX. But all those STX are locked and cannot be moved until the end of cycle 2 - meaning the pool has to miss a cycle.

I still agree that having sub-contracts is the next best option, if a principal stacking to multiple reward addresses is not an option.

[jcnelson]

Totally agreed. The way I would solve is to not rely on any specific slot size, and instead only do this in "chunks" of say 1mm STX. I've done research on the optimal chunk size for economic efficiency based on various slot minimums, and I think it's around 1.5mm.

While I don't doubt your analysis, does it take into account the inflation of STX due to (a) token unlocks, and (b) token minting? Just curious.

In my opinion, it's OK to not allow this STX to be unlockable, because the pool users would need to signal their desire to unlock in the next cycle. I admit having this kind of exception doesn't help with complexity.

I think the biggest reason I'm against the (multi-stack-stx) API is because I think it's too opinionated in how it handles edge-cases, and those opinions are geared towards a particular service implementation's needs. While I agree that the subcontracts concept has its own problems, the biggest advantage it has over (multi-stack-stx) from a design standpoint is that it does not attempt to change .pox-2 to enable any particular form of pooling. Given that blockchain code is forever, we should be striving to write the least-opinionated, easiest-to-understand APIs as possible. I'm all for making pooling easier and better; I'm just more in favor of conservative API changes as a means to get there.

Following your described solution, you'd still end up needing a fixed "chunk" size of STX per sub-contract. Otherwise, you end up in a scenario where some sub-contract has locked STX, and in the next cycle that sub-contract needs to move some of it's STX to a different contract in order to be stacked.

From this example, it sounds like sub-contracts could be made more viable in 2.1 if there was a .pox-2 function that would transfer and lock the STX for a given recipient and PoX address at the next reward cycle boundary. Something like this:

(define-public (transfer-and-stack-stx
   ;; the new stacker, who will receive the STX when they unlock
   (new-stacker principal)
   ;; the PoX address to use
   (pox-addr { version: (buff 1), hashbytes: (buff 20) })
   ;; the number of uSTX to transfer to `new-stacker`
   (amount-ustx uint)
   ;; the burnchain height at which to lock them
   (burn-ht uint)
   ;; the number of cycles for which to lock them
   (num-cycles uint)
)

The implementation would do the following (among other things):

• Verify that tx-sender is currently stacking
• Verify that burn-ht is in a future reward cycle that tx-sender is not stacking in
• Verify that the new-stacker is not stacking in the next reward cycle after the one burn-ht is in, plus the subsequent num-cycles cycles
• Add pox-addr for amount-ustx to the future reward cycles
• Remove tx-sender from the stacking-state map and add new-stacker to it

The VM would then do the following on successful completion:

• Transfer the requested locked STX balance from tx-sender to new-stacker
• Set the unlock height to the reward cycle after num-cycles have completed since the first cycle after burn-ht

I'm not 100% sold on this either, because it effectively permits stackers to sell their STX while they are locked. But, given the above checks, it would at least require the new-stacker to wait to transfer them again until the next reward cycle at least. The original stacker could transfer STX to as many new-stackers as they want, as long as they have enough STX and as long as they meet the stacking minimum (just like with (stack-stx)).

This new API endpoint wouldn't change anything about the contract's data space, and wouldn't alter the behavior of any of the existing API endpoints. Moreover, it's useful in contexts outside of pooling. For example, this would let you re-key your STX if your key got lost while the STX were stacked.

The way the sub-contracts proposal would work with this is it would permit the pool controller contract to call into sub-contract A via a privileged API to compel it to transfer and stack its STX to B and C while they are stacked for A. As before, the transaction cost for moving the STX to B and C would be borne by renters B and C as part of the self-service interface.

What do you think about this alternative?

[hstove]

Oh, this is really interesting. I had not considered this alternative. Is your assumption that the VM changes ("moving" the locked balance, updating lock state) are a reasonable change to complexity? It does seem like it wouldn't effect the underlying contract state.

I do agree that this is nice in that it has a pretty broad use-case.

[jcnelson]

I spoke more with @kantai about this. If you're still open to the multi-stack-stx approach, you could potentially do so via the delegate interface. Specifically, you could have each entry in the pox-addrs list delegate STX to a contract that stacks them on their behalf. Each delegator can have its own PoX address and lock-up; all that's needed is for the delegate to aggregate and commit them as part of the pool. Would that work?

[hstove]

I think it would - but last I looked into this (granted, a while ago), there was a similar issue where a delegator couldn't change their reward address without missing a cycle. The other option would be to 'rotate' through to delegate to a new contract, but I think the issue was that you couldn't stack-extend and change your delegator. If either of those things are possible, then I think this approach could/would work.

[jcnelson]

I think you can use delegate-stack-extend?

;; As a delegator, extend an active stacking lock, issuing a "partial commitment" for the
;;   extended-to cycles.
;; *New in Stacks 2.1*
;; This method extends `stacker`'s current lockup for an additional `extend-count`
;;    and partially commits those new cycles to `pox-addr`
(define-public (delegate-stack-extend
                    (stacker principal)
                    (pox-addr { version: (buff 1), hashbytes: (buff 20) })
                    (extend-count uint))

So, each entry in pox-addrs calls delegate-stack-extend via as-contract, which (as the delegate) takes care of both setting the caller's PoX address for the next cycle and aggregating and stacking everyone's STX.