Stacks 2.1: Enable multiple Stacking commitments per address

[agraebe]

The current implementation only allows one commitment per address. This prevents users from:

• adding more tokens to stay eligible for future increases of reward slot thresholds
• using different Bitcoin reward addresses, when eligible for a set of reward slots

@hstove to add more 🙏🏼

[314159265359879]

Allowing this would also give the possibility to allow stacking with as much as possible for the maximum number of slots and to delegate the rest of the total commitment to a pool operator. For example if you commit 200k stx, and a slot requires 80k. You would commit 160k to one btc address (for two slots) and 40k stx for pooling (half a slot). Automatically unlocking stx (Issue #7) would nolonger be necessary in this scenario.

An other scenario could be you stacked 50k stx, but the treshold goes up to 80k and you commit an extra 30k tot he same btc address or you add a pooling address to delegate the 50k that was already committed.

(note: I am hoping trusted exchanges will allow the delegated pooling so that btc earned can go to your personal account while stx remains safely in the wallet even for stackers that own less then the minimum for a single slot). Delegated stacking is already covered in the pox contract and Muneeb mentioned it is being worked on for integration in the wallet.)

[jcnelson]

The PoX smart contract already allows for delegated Stacking. I think this problem -- giving a different BTC address to each reward slot you clinch -- could be addressed either with a smart contract that facilitates Stacking, or with a service built for the purpose.

[hstove]

This isn't about different BTC addresses - it's about stacking from the same STX address. Right now if you've stacked 100k STX and want to lock another 200k, you need to send you STX to a different address, and then you can call 'stack-STX' with the same BTC address you used the first time.

Ah, I see that Alex did say multiple BTC addresses originally - I mainly am concerned around multiple STX addresses.

[hstove]

Here is my main use case for allowing the same principal to stack / lock funds multiple times:

Imagine a smart contract that does stacking, based on some logic. The smart contract principal holds STX, and some logic triggers it to actually commit those STX to stacking, with whatever BTC address. This idea runs into issues, because that smart contract can only lock funds exactly one time. It can transfer those funds to a different principal and then stack, but that leads to other issues.

For example, there could be a smart contract that allows fixed income swaps for stacking rewards. Multiple lenders add funds to a smart contract. Then, any borrower can borrow increments of 70k (or whatever) STX from that smart contract, in exchange for an up-front payment. The smart contract then calls stack-stx with the borrower's BTC address. The borrower's payment is paid proportionally to the lending pool. After the stacking cycle, the funds are returned to the smart contract, and then the lenders can get their original STX back from the pool.

The issue today is that the smart contract can only call stack-stx (with itself as tx-sender via as-contract) exactly once. I don't really want to debate exact ways to implement such a concept - there are definitely workarounds. I do believe this limitation is not ideal, and is preventing otherwise legitimate use cases.

[jcnelson]

First, keep in mind that the blockchain is behaving correctly, in accordance with SIP-007. This issue is not a bug, so it's not even worth thinking about changing the consensus rules to address it. The only time we'll be tweaking this is when Stacks 2.1 gets released, which is a point in time that all miners have agreed to already.

Second, I'm skeptical that naively permitting re-locking is a good idea. Allowing multiple re-lockings creates an adaptive adversarial game where once the reward address threshold increases, it triggers a whole round of new re-lockings. In doing so, it creates perverse incentives for miners right around the time when the next reward cycle begins (which is precisely when miners vote to begin PoX, and thus a time we really do not want to disturb them). Specifically, it would encourage Stackers to do things like wait until the last possible minute to Stack (so as to keep the lock-up rate minimal, thereby maximizing the number of slots they'll get), and then bribe miners to prevent other people from Stacking. This is a systemic risk that I'm keen to avoid, especially since there's money involved and there will be no putting that genie back into the bottle.

I don't really want to debate exact ways to implement such a concept - there are definitely workarounds.

Then use them.

Changing the consensus rules of a blockchain is a method of last resort, when all other workarounds have been exhausted. Moreover, it's a legally ambiguous move, because there's an argument to be made that the STX token in the blockchain with new rules is whole new security.

[jcnelson]

I went ahead and tagged this for Stacks 2.1. While the idea is fine, it's not something worth hard-forking the chain over. However, we can add it to the Stacks 2.1 scheduled network upgrade.

[philiphacks]

@jcnelson @hstove is this something that is going to happen in Stacks 2.1, or still just an idea?

I'm asking cause this would be a very valuable feature for implementing Arkadiko. The high-level idea is as follows:

Stablecoin (xUSD) is minted by locking up STX in vaults as collateral. Currently all STX goes to 1 address, namely the smart contract address. In other words: as soon as the minimum stacking amount is reached (e.g. 90K tokens today), the STX will be used to stack so the xUSD becomes interest-bearing. Imagine 90K is reached and we start stacking in cycle X.

Now whenever a new vault gets created, the collateral is sent into that same contract address. Today, I would not be able to add those additional tokens to stack, since you can only call stack-stx once for each principal (until the lock-period is over and all tokens are released). A workaround would be to stack only 1 cycle each time, and call the stack-stx method with the last available supply each time before a new cycle starts. This is inefficient though, since this requires more logic rather than just calling stack-stx again, and it would currently lead to missing every other cycle (because continuous stacking is impossible right now).

[jcnelson]

This is scheduled for implementation: stacks-network/stacks-core#2533

[philiphacks]

Thanks! Looking forward to this.

[kantai]

At a high level, the way that I have been imagining supporting this via the proposal in stacks-network/stacks-core#2539 is through a combination of stack-increase, delegate-stack-increase and *-stack-extend.

stack-increase would allow stackers to increase their currently locked amount (meaning they could issue "multiple" stacking commitments from the same address). stack-increase would not allow changing the reward address. However, the delegation version, delegate-stack-increase would allow delegators to increase the stacked amount, but because the commitment is separated from the lock event, the delegator would be able to stack to a different address after increasing enough to support a second reward address.

*-stack-extend variants would allow using a different reward address for the extended cycles.