This was pointed out on Discord when cycle 54 started - the data on stacking.club for a Stacks cycle is 100 blocks sooner than a CityCoins cycle.
Using this from the API to get the values directly from the contract for first block in cycle:
https://protocol.citycoins.co/api/ccd007-citycoin-stacking/get-first-block-in-reward-cycle?cycle=54
- CityCoins cycle 54: 779,450
- CityCoins cycle 55: 781,550 (+2,100)
- CityCoins cycle 56: 783,650 (+2,100)
- CityCoins cycle 57: 785,750 (+2,100)
So the cycles are 2,100 blocks long, but they are 100 blocks after what is shown on stacking.club.
We use the same math for determining cycle numbers by BTC block height as the .pox contract, but the difference of 100 blocks on stacking.club comes from how the Prepare Phase is handled in PoX.
https://github.com/stacksgov/sips/blob/main/sips/sip-007/sip-007-stacking-consensus.md#anchor-blocks-and-reward-consensus
This 100 BTC block period is when the anchor block for the reward cycle is chosen by Stacks miners. STX cannot be stacked (on Stacks) during that 100 block window, so the numbers on stacking.club are showing what's available, e.g. Stacks Cycle 54: 779,350 - 781,450.
The CityCoins protocol does not have the 100 block prepare phase, instead it simply monitors the BTC block height to determine what cycle we are in. This shifts our numbers forward by 100 blocks, e.g. CityCoins Cycle 54: 779,450-781,550.
Materially this shouldn't cause a problem - it means that CC cycles will start 100 blocks after a Stacks cycle, which means a little more time to stack before the cycle officially starts.
During that 100 block period no rewards are being paid out, and rewards are paid out after the cycle ends so it doesn't affect that portion.
It does mean that CityCoins will unlock 100 blocks later, but that alignment will matter less with 2.1 and continuous stacking on the Stacks side.
This was pointed out on Discord when cycle 54 started - the data on stacking.club for a Stacks cycle is 100 blocks sooner than a CityCoins cycle.
Using this from the API to get the values directly from the contract for first block in cycle:
https://protocol.citycoins.co/api/ccd007-citycoin-stacking/get-first-block-in-reward-cycle?cycle=54
So the cycles are 2,100 blocks long, but they are 100 blocks after what is shown on stacking.club.
We use the same math for determining cycle numbers by BTC block height as the .pox contract, but the difference of 100 blocks on stacking.club comes from how the Prepare Phase is handled in PoX.
https://github.com/stacksgov/sips/blob/main/sips/sip-007/sip-007-stacking-consensus.md#anchor-blocks-and-reward-consensus
This 100 BTC block period is when the anchor block for the reward cycle is chosen by Stacks miners. STX cannot be stacked (on Stacks) during that 100 block window, so the numbers on stacking.club are showing what's available, e.g. Stacks Cycle 54: 779,350 - 781,450.
The CityCoins protocol does not have the 100 block prepare phase, instead it simply monitors the BTC block height to determine what cycle we are in. This shifts our numbers forward by 100 blocks, e.g. CityCoins Cycle 54: 779,450-781,550.
Materially this shouldn't cause a problem - it means that CC cycles will start 100 blocks after a Stacks cycle, which means a little more time to stack before the cycle officially starts.
During that 100 block period no rewards are being paid out, and rewards are paid out after the cycle ends so it doesn't affect that portion.
It does mean that CityCoins will unlock 100 blocks later, but that alignment will matter less with 2.1 and continuous stacking on the Stacks side.