Stacks 2.1 brings some changes to stacking, in particular it is possible to avoid cool down cycles and to increase stacking amount during locking periods. Here is a description of all the tests for these features when used with a stacking pool.
For the tests with use the 2.1 testnet maintained by Hiro Systems. Make sure to set the correct network in the explorer.
The testing pool use the following settings:
The pool stacking address is ST21815DY1QZWV6NAPCDE54BMHE10WK8HB2QXBNDT.
The pool rewards address is a native segwit address (supported since 2.1): https://mempool.space/testnet/address/tb1qs2qft0sdllxe424nrt3fzaytsg8y6y2cplaylj
All stacks are locked for only 1 cycle at a time and re-stacked until pool membership is revoked.
From cycle 5, 820m STX were stacked so that PoX consensus is active. There are two pool members:
Alice: ST3GKDW24KN9KVY49DG20MJ39DQMH1Z4DJT7C7MFT (5.2m STX)
Bob: ST1BY17KAGWQYYZ3TST4CANW0AJFN80YY931DJTK2 (100+ STX)
During cycle 4, Alice and Bob delegated to the pool as usual before the start of cycle 5. Alice delegated 5.2m STX, Bob 100 STX in a first transaction. Later, Bob delegated 105 STX.
For cycle 6, Bob uses a helper function to revoke and delegate in one transaction. NOTE, that Bob needs to call
allow-contract-caller first to enable delegation through the helper contract.
To find pool members, we need to check calls to
delegate-stx on contract
pox-2. The delegation state can be looked up using the delegation map as in Stacks 2.0.
An improvement is under development that would result in specific events for when a user delegates stx using any contract call or even a specially crafted bitcoin transaction. During the tests, this feature was not yet available.
This works as in Stacks 2.0. Depending on the user’s balance and the minimum requirements, the appropriate stacking amount is locked using
For cycle 5,
we locked 5.2m STX for Alice for 1 cycle.
we locked 100 STX for Bob for 1 cycle. (Note, that this happened after a first stack-aggregation-commit call. See Step 3.)
For cycle 6, no new members were added.
After Bob’s STX were locked, he noticed that there are more liquid STX. He asked to lock more for cycle 5. In Stacks 2.1, it is now possible!
For cycle 5, we increased the locked amount for Bob by 5 STX (
delegate-stack-increase) after the delegated more STX.
For cycle 6, Bob has increased the delegation to 106 STX. We locked the amount during the extend call (see below).
For cycle 6, we want to lock the same amount for Alice and Bob again. In Stacks 2.0, there would be a cool down cycle. In Stacks 2.1, we can extend the locking period during cycle 5.
For cycle 6,
we extended the locking period for Alice by 1 cycle (
delegate-stack-extend). The stacking amount is unchanged (5.2m STX).
we extended the locking period by 1 cycle for Bob and increased the locking amount by 1 STX in one transaction using a helper contract
pox-2-pool-admin-helper-2 that combines the extend and increase calls.
NOTE: The helper contract makes first a calls to
delegate-stack-extend and then to
delegate-stack-increase. With the 1 cycle locking period, the increase call would fail with
err 2 due to the unlock height in the next cycle.
With Stacks 2.1, we add members to the pool even after we have already finalized a first batch. There is now the function
stack-aggregation-commit-indexed that returns an index of the pool slots. This index can be used for adding more STX to the pool for the next cycle.
For cycle 5,
we finalized the first batch with Alice as we hit the minimum locked STX of 5.2m STX. We used the new function and received as result value the pool’s index
we finalized the next batch by increasing the locking amount by all the newly added STX from Bob for cycle 5 using function
stack-aggregation-increase with the pool’s index
the total amount stacked was 5,200,105.00 STX.
For cycle 6, we finalized the cycle as usual using function
stack-aggregation-commit. Therefore, we were not able to add more STX to the cycle at a later time. The total of 5,200,106.00 STX were stacked for cycle 6.
During the tests, we didn’t distribute rewards. However, the bitcoin explore shows that we have received some tBTC for 1 slot as expected.
We managed to use the new scripts for two pool members. The scripts are not yet optimized for thousands of users.
Reasons why contract calls failed:
the chain was not live, the single miner ran out of tBTC and stopped mining. This was not immediately noticed by us and we sent transactions that failed due to wrong block heights.
helper contracts were not enabled through
delegate-stack-increase was called for users in their last locking cycle. With the 1-cycle model of most stacking pools,
delegate-stack-extend needs to be called first for existing pool members.
the call was made to
pox instead of
pox-2. The error is shown as