Remove Cool Down Cycle in Stacking

Working Groups Proof of Transfer (PoX)
#4

Could you share the original reasoning behind the two-week cooldown period?
I’d love to understand the intention & context behind it.

#5

My impression was that the cooldown cycle was not intentional.

#6

The draft of the SIP can be found here: Add sip to remove cool down cycle by friedger · Pull Request #209 · stacksgov/sips · GitHub

1 Like
#7

Ideally, I like to remove solo stacking and get rid of pool operators, and create a business model for signers in the same SIP.

  • Remove stack-stx, stack-increase, stack-extend
  • Remove delegate-stack-stx and lock stx directly in delegate-stx
  • Rename delegate-stack-increase to delegate-increase
  • Rename delegate-stack-extend to delegate-extend
  • Add parameter of a signer address for locking contract calls.

This simplifies the stacking process and hopefully creates a relationship between signers and stackers. Probably needs more thoughts…

#8

This is a great idea, I need to look into the details of the methods you propose to remove and how this would change PoX, but I agree there needs to be a relationship between signers and stackers, and generally a better (monetary) incentive to run a signer.

I suppose this would be a separate SIP from removing the cooldown?

1 Like
#9

If there’s a way to compress allow-contract-caller and delegate stx into one call that would also be great for native stacking

Plus remove these weird things with delegating an amount of stx and that then the stx stays into the users wallet until the start of the PoX cycle, etc. Let’s use this as an opportunity to harmonise how delegations work with other leading ecosystems like Solana etc @pipje

1 Like
#10

This would remove the delegating staying unlocked.

As a new relationship between signers and stackers would require a new pox contract, it makes sense to put it into one SIP, IMO

#11

The argument from some years back about backwards compatibility is not relevant anymore because solo stackers have to run the signer in the same way as a delegated stacker (Remove solo stacking · Issue #4184 · stacks-network/stacks-core · GitHub)

#12

Thanks for leading this effort @friedger! :raised_hands: I think these are all great ideas. I’ll read through the SIP and add comments on the specifics there.

1 Like
#13

After some discussions, here is an update that does not require a change to the prepare phase

Current situation

  1. We have two groups of stackers: solo stackers and delegated stackers
  2. When using a contract for stacking, we need to add the contract as an allowed pox contract
  3. Solo stackers
    1. do all transactions with their cold wallet holding the whole stx balance
    2. ask a signer for a signature
    3. need to do this at least once every 12 cycles (6 months)
  4. Delegated stackers
    1. fix the max amount that the pool operator can lock
    2. need to do this only once
  5. Pool operators
    1. lock stx tokens of delegated stackers (up to max amount) at least once every 12 cycles, most pools do this every cycle.
    2. ask signers for signature for delegating voting power of all pool members and call stacking-aggregation-commit
    3. need to do this once per cycle
  6. Signers
    1. provide signatures
    2. do signing work during the whole cycle

Simplified stacking protocol

  • There is only one group of stackers (change to 1., remove 3.).
  • Stacking period is 1 cycle, but extends automatically.
  • Stacking amount and delegatee/signer can be changed for the next cycle. Amount can be increased or decreased, pool can be changed.
  • Stackers delegate voting power to signers (remove 5.)
    • Stx tokens are immediately locked during delegation (replaces 5.1)
    • Stackers ask the signer for a signature (new)
    • Stackers can change their stacking settings for the next cycle before the prepare phase.
  • Signers
    • provide a signature to each pool members (requires a public api for public pools).
    • aggregate the delegated voting power of the pool members (similar to 5.2)
  • A new type of post condition for locking removes the need of allow-contract-caller for stacking with contracts.

Considerations

Private Keys

There are three keys involved

  • btc reward pox address, used for reward distribution
  • stacks address, used for stacking amount aggregation over pool members
  • signer key, used for block signing

The keys can be controlled by a single entity or by different entities with off-chain collaboration agreement.

Solo stackers can still use a single private key. Joint-venture pools (like stacking dao) can continue to divide responsibilities.

Functions

delegate-stx is the main function call for stackers. Parameters are

  • amount to lock
  • signer address
  • signature
  • optional until block height when delegation expires
  • optional max amount to lock in the future during auto extend

aggregate-commit is called by the signer to register the delegated voting power. After this call, pool members can’t change their delegation anymore for the next cycle. Signers can use aggregate-increase to add more voting power later, but before the prepare phase.

revoke-delegate-stx can be called by stackers to end delegation.

Changing delegation

Users can change the amount and signer before the aggregate call by the signer. This means that stackers can change pools every cycle and that btc reward pox addresses can be changed every cycle for sbtc payout when the sbtc wallet keys are rotated.

Unlocking

If a signer does not receive at lease one reward slots, the delegated stx of the pool members are unlocked.

To avoid DoS attacks on unlocking small amounts, unlocking is “aggregated” through the aggregate-commit tx.

Post conditions

A new type of post condition is added. This can be specific to locking events or more general for a new type of guarded print event (to be added in Clarity 4)

6 Likes
#14

These are great improvements, thanks for working on this @friedger

Especially “lock once and automatically extend by 1 PoX cycle each time” is important, this way pool operators don’t need to manually extend the lock for each stacker. Also changing delegation to another pool without cooldown will be a big win.

#15

Extremely bullish on this! I’m here to do whatever I can do make sure this gets into the next hardfork

3 Likes
#16

We will be streaming Weekly SIP Call with Friedger on DeOrganized morning show at 10.30am ET to talk to him and learn about Improving Stacking experience proposal.

Watch live: https://x.com/DeOrganizedBTC/status/1915745167123898570

1 Like
#17

This is a great proposal! Like the simplification and efficiency it brings to stacking. I’m a supporter.

2 Likes
#18

The updated simplified stacking protocol sounds like a great UX improvement – and it will define PoX-5!

Would you be open to drafting a SIP with these changes?

1 Like
#19

Hi Aldur welcome,

There is a working in progress SIP from Friedger documented in the SIP Repo: Improved stacking by friedger · Pull Request #211 · stacksgov/sips · GitHub - welcome to review/feedback the SIP and comment there too

Also being included in the future roadmap of Stacks network

1 Like
#20

Thanks for the welcome! :slight_smile: I am aware of the roadmap.

It seems that the simplified stacking protocol has both reached enough informal agreement and crystallized enough that we can move over to the SIP.

@friedger do you want to update the SIP with the simplified stacking protocol discussed here?

1 Like
#21

There are more ideas flying around. I am still trying to catch them all.

Main thing is how to best integrate contributor pool into pox-5

1 Like
#22

The proposed SIP has been updated and is now ready for review:

4 Likes
#23