Currently, users have to wait for 1 cycle without rewards when they want to change the pool, decrease the stacking amount or change the PoX reward address. Therefore, it is expensive to do any of these actions. For large stackers or pools, this can cost tens of thousands of dollars. When we don’t have a cool down cycle anymore, there would be also more competition between pools.
We can remove the cool down cycle by the following changes:
fix the pox anchor block in the last 10 blocks, currently, 100 block. The prepare phase would be reduced to 10 blocks.
unlock tokens at the beginning of the current prepare phase (100 last block), currently at block 0 of the next cycle.
That gives users 90 blocks to change any of their stacking settings.
This also has the following impact:
New stackers can join stacking until 10 blocks (currently 100 blocks) before the next cycle.
Burn phase is reduced from 100 to 10 blocks. That would increase the number of rewards slots to 4180 slots and reduce the slot price (minimum stacked stx for 1 slot).
The key change is to unlock stx earlier than currently. We did that for the hard forks already when changing pox contracts: unlocked at the beginning and continued to receive rewards the whole cycle.
I have the feeling that the proposed changes are manageable short term. However, I might be wrong, and it is much harder to implement than I think.
My understanding was that with Nakamoto, pox anchor blocks are immediate. What will happen if miners don’t mine a block in the 10 block prepare phase? Is 50 better?
What would happen today, if there is a stall of 100 blocks during the prepare phase?
To minimize any negative impact, it might make sense to reduce the preparation phase to 50 blocks first. 500 min (0.35 days). I think historically, PoX anchor blocks are mined in this duration.
My understanding is also this will help redirect burn BTC of 50 blocks of the preparation phase to stackers if I’m not mistaken
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?
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
After some discussions, here is an update that does not require a change to the prepare phase
Current situation
We have two groups of stackers: solo stackers and delegated stackers
When using a contract for stacking, we need to add the contract as an allowed pox contract
Solo stackers
do all transactions with their cold wallet holding the whole stx balance
ask a signer for a signature
need to do this at least once every 12 cycles (6 months)
Delegated stackers
fix the max amount that the pool operator can lock
need to do this only once
Pool operators
lock stx tokens of delegated stackers (up to max amount) at least once every 12 cycles, most pools do this every cycle.
ask signers for signature for delegating voting power of all pool members and call stacking-aggregation-commit
need to do this once per cycle
Signers
provide signatures
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)
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.
%
I think these are all great ideas. I’ll read through the SIP and add comments on the specifics there.