SIP-045 PoX-5: Bitcoin Staking and Emission Schedule Alignment

[adriano-stacks]

No description provided.

[brice-stacks]

Editors, can we go ahead and assign SIP number 045 for this proposal?

[xyzerobtc]

Editors, can we go ahead and assign SIP number 045 for this proposal?

Please let me know once SIP ID assigned so we can display on the SIP Tracker (https://www.zeroauthoritydao.com/sip) and prepare CAB Group voting (https://www.zeroauthoritydao.com/sip/cab-groups)

[clairetopalian]

Approved - awaiting 2nd review so we can assign SIP #

[314159265359879]

Thank you for submitting such a high quality draft!

Let me start by signing off on using SIP-045 for this.

I would like to see a few changes before moving to editor sign-off. I have added suggestions with my comments I hope they help clarify and resolve.

The section 6 and 3 comments are high priority the rest can be considered medium to low priority.

Section 9: Emissions and total max STX supply at block spreadsheet

I would like to see an updated spreadsheet included with this sip similar to the one with SIP029. Preferably one that includes the Endowment emissions and the emissions per block (and/or per cycle) upto 2050 to reflect total STX supply at certain moments.

The first tab in the spreadsheet can be condensed to show the STX supply at the time of the next 4 bitcoin halvings and on January 2050 as the SIP029 appendix does does (for easy comparison): https://github.com/stacksgov/sips/blob/main/sips/sip-029/sip-029-4.xlsx other tabs can be used to display emisssions per block and/or per stacking cycle.

Supplies would be approximations, there is likely to be some burning of STX for example due to BNS or in case the endowment doesn't need all its funds and burns some, that is fine. We've always called it "maximum expected supply".

[314159265359879]

Question out of curiosity Section 7 mentions SIP-032 but doesn't explicitly mention what was incorporated in PoX-5. My comparison below. Did I understand this correctly?

• Is the 1-cycle-lock-with-auto-extend model still on option for PoX-6?
• What about moving to a shorter prepare phase 20 blocks instead of 100?
  or
• Immediate locking of delegated tokens as a stated semantic?

SIP-032 comparison

Incorporated into PoX-5 from Friedger's earlier SIP-032 for stacking improvements:

• Remove the cooldown cycle — SIP-032's central thesis; surfaces in §3.4 and §5.3.
• Persist a commitment across cycles / drop the per-cycle aggregate — §3.4 (second improvement) and §5.1. Maps to SIP-032 replacing per-cycle stacks-aggregation-commit and per-cycle delegate-stack-extend with automatic continuation.
• One unified flow for solo and delegated stackers — §5.2 "one flow for solo and delegated participation," which is SIP-032's core unification (everyone delegates voting power to signers).

Left out of PoX-5:

• The new LockingLimit post-condition that lets contract-based stacking happen in a single transaction (removing allow-contract-caller). Absent. But we have new staking and PoX post-conditions that were introduced with the SIP044 draft.
• The function rename/semantics set (designate, revoke-designation, update-amount-allowance, signer-accept; voting power = accepted amount). PoX-5 keeps PoX-4 terminology.
• The 1-cycle-lock-with-auto-extend model.
• Immediate locking of delegated tokens as a stated semantic.

[xyzerobtc]

@adriano-stacks and/or @brice-stacks, do you have links to PoX-5 and all of the testing and audits that were done?
can you please share that for the governance CAB review?

[adriano-stacks]

@adriano-stacks and/or @brice-stacks, do you have links to PoX-5 and all of the testing and audits that were done? can you please share that for the governance CAB review?

Hey @xyzerobtc! The audits are in progress and will be complete by end of month. PoX-5 is being implemented here (also reference [5] in the SIP body). Testing is happening on a development testnet where integrators, pool operators, etc are helping on the QA. Be warned, this testnet resets every day.

[brice-stacks]

• Is the 1-cycle-lock-with-auto-extend model still on option for PoX-6?

No, the 1-cycle lock with auto-extend would over-complicate the implementation, so we went with allowing a number of cycles up to 96 (3-4 years), and stakers can unstake at any time (outside of prepare phases) and they will be unlocked in the next cycle.

• What about moving to a shorter prepare phase 20 blocks instead of 100?

The prepare phase is still 100 blocks, but no BTC is burned. It all goes to the pox-5 contract to be distributed!

• Immediate locking of delegated tokens as a stated semantic?

Yes, no more separate delegation step.

• The new LockingLimit post-condition that lets contract-based stacking happen in a single transaction (removing allow-contract-caller). Absent. But we have new staking and PoX post-conditions that were introduced with the SIP044 draft.

Right, these are fulfilling the goal of SIP-032's design

• The function rename/semantics set (designate, revoke-designation, update-amount-allowance, signer-accept; voting power = accepted amount). PoX-5 keeps PoX-4 terminology.

The delegation is handled differently, so I think this renaming is no longer applicable.

[xyzerobtc]

@adriano-stacks and/or @brice-stacks, do you have links to PoX-5 and all of the testing and audits that were done? can you please share that for the governance CAB review?

Hey @xyzerobtc! The audits are in progress and will be complete by end of month. PoX-5 is being implemented here (also reference [5] in the SIP body). Testing is happening on a development testnet where integrators, pool operators, etc are helping on the QA. Be warned, this testnet resets every day.

Thank you @adriano-stacks
Looking at tentative dates, do we need to push dates back to accommodate testing, QA, and migration to mainnet? I know we want to move fast, and we also want the highest possible level of security.

From @alexlmiller post:
The tentative timeline from here, based on the overall feedback from the community, we’re proceeding with formalizing this SIP proposal and adding to Github to begin the formal SIP process. The expected timeline now is

Jun 12 - Open Github PR with updated SIP draft

Jun 15 - Jun 29 - Review period for public, Editors, CABs + CAB Votes

Jul 1 - Jul 10 - Voting window (assuming CAB approval)

Jul 29 - Target hardfork date (assuming vote passes)

[brice-stacks]

I opened a PR in my own fork with some suggested changes on the technical details - brice-stacks#1

EDIT: these are now merged here.

[xyzerobtc]

Hey @brice-stacks I was chatting with @clairetopalian and wanted to ask, if we vote and approve SIP-045, would we need to have emergency fix after the audits are ready and something is needed as a fix?
Can we implement fix without new CAB voting?

Similar to SIP 21, 22, and 23.

SIP-021: Nakamoto: Fast and Reliable Blocks through PoX-assisted Block Propagation
SIP-022: Emergency Fix to PoX Stacking Increases
SIP-023: Emergency Fix to Trait Invocation Behavior

[brice-stacks]

Hey @brice-stacks I was chatting with @clairetopalian and wanted to ask, if we vote and approve SIP-045, would we need to have emergency fix after the audits are ready and something is needed as a fix? Can we implement fix without new CAB voting?

Any fixes would likely be just fixing the implementation, not the concept / design, so I wouldn't expect any SIP changes to be necessary.

[xyzerobtc]

Hey @brice-stacks I was chatting with @clairetopalian and wanted to ask, if we vote and approve SIP-045, would we need to have emergency fix after the audits are ready and something is needed as a fix? Can we implement fix without new CAB voting?

Any fixes would likely be just fixing the implementation, not the concept / design, so I wouldn't expect any SIP changes to be necessary.

That sounds great @brice-stacks , wanted to make sure from a GOV CAB perspective -- if 2 votes were needed back to back, I think it would be best to only do 1 -- however, we don't need to cross that bridge anymore. Thanks

[brice-stacks]

@314159265359879, I'd like to go ahead and get this merged (as Accepted) so that the CAB vote happens against the merged version, not an open PR. Does that sound right to you? Same for #267.

[314159265359879]

Thanks for the updates, congrats on the editor sign-off