Remove Cool Down Cycle in Stacking

Working Groups Proof of Transfer (PoX)
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)

7 Likes