Avatar
Friedger | Blog
February 01, 2023
·
8 min read

Testing Stacking Pool 2.1

Testing Stacking Pool 2.1

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:

From cycle 5, 820m STX were stacked so that PoX consensus is active. There are two pool members:

Actions by Users

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.

Step 1: Get Pool Members

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.

Step 2: Stacking

First time members

This works as in Stacks 2.0. Depending on the user’s balance and the minimum requirements, the appropriate stacking amount is locked using delegate-stacks-stx.

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.

Member wants to add more — increase

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).

No more cool down cycles — extend

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,

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.

Step 3: Finalize 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 3.

  • 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 3.

  • 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.

Step 4: Payout

During the tests, we didn’t distribute rewards. However, the bitcoin explore shows that we have received some tBTC for 1 slot as expected.

Learnings

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 allow-contract-caller.

  • 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 (err none).

(header image by caroline voelker on Unsplash)