Bitcoin Staking SIP: Community Engagement, Proposal Adjustments, and What's Next
The forum-based feedback phase for the Bitcoin Staking SIP is wrapping up (you can still ask questions on the forum!) and the proposal has been formally submitted as a GitHub PR — PR #270 in the stacksgov/sips repo. Once editors review for formatting alignment, a SIP number will be assigned and the proposal will remain under open review leading up to CAB voting, which is tentatively slated for June 25-29.
Community engagement
Questions and ideas came in through the forum, on X, and in last week's office hours with Alex and Muneeb. Topics ranged from monetary policy credibility and miner sell pressure to the long-term sustainability of emissions-funded staking rewards. You can read feedback, questions, and responses from Alex in the forum thread.
A note on Endowment-related questions

Several community members asked whether the Endowment should fund the proposed boost rather than minting new tokens. It's a fair question, and worth a quick clarification on what the Endowment is actually designed to do.

Per SIP-031, the Endowment is a treasury management and capital deployment entity that funds ecosystem growth through grants, marketing, business development, liquidity programs, and engineering support. It does not vote in SIP votes, run day-to-day operations, or govern the protocol.

Questions about the boost did impact the new SIP draft materially, and those changes are captured below.

Key changes in the proposal
Thanks to the engagement driven by the community and the SIP authors, a few noteworthy changes were made to the proposal and are now reflected in the new draft on Github:

Updates to the boost proposal. The original draft included a temporary 500 STX per block boost for the first six months of the program, funded through new emissions. A number of community members pushed back on this, arguing the boost created unnecessary dilution and that the Endowment was a more appropriate funding source for a growth incentive of this kind. After reviewing the options, SIP authors decided to remove the boost from the emissions schedule entirely. The proposal now moves forward with just the long-term adjustment: restoring the block reward to 1,000 STX. If a boost is needed to support the program's growth at some point, it would be funded directly by the Endowment through sBTC fed into the PoX-5 contract, providing a more targeted and on-demand approach that avoids permanent protocol changes or unnecessary dilution.

New hard fork clause added. In the new draft, the reserve fund is built as accrue-only -there's no public spend function, and the only path to draw on it is through a consensus change, which means a hard fork. This keeps the contract's attack surface minimal, prevents any party from having unilateral access, and reflects the reality that a draw isn't expected to be needed during the bootstrap phase at all.

But if circumstances did require it, getting there would mean re-coordinating the full community around a vote they've already effectively taken by approving this SIP. The pre-authorized hard fork procedure removes that friction. STX holders can signal advance consent to a future reserve-access hard fork now and revoke it at any time. A sufficient pre-authorization threshold means coordination can begin quickly if needed, without relitigating a principle the community has already endorsed.
Summary of changes in the new draft
  • 500 STX boost removed (§3.2.2) — v1 proposed 1,500 STX/block for 6 months as new issuance; v2 restores 1,000 STX only, with any future launch incentive to be Endowment-funded via sBTC
  • Yield Capacity section updated (§3.2.3.1) —Boost justification paragraph removed; replaced with note that any additional incentive would come from the Endowment in sBTC
  • Inflation framing updated (§3.2.3.4) — v1 acknowledged the peak rate "sits near the median" (because of the boost); v2 states the rate stays "below the five-year median across the whole schedule" (no boost peak)
  • New Section 3.3.2 added: Pre-Authorized Hard Fork Procedure — entirely new; covers reserve fund access rationale, pre-authorized vote mechanism, and sunset at PoX-6
  • sBTC signer set row added to trust table (§8.1) — v2 adds the signer set dependency explicitly
  • Document structure reordered — Related Work moved from Section 7 to Section 4; Activation moved from Section 4 to Section 6
  • Appendices consolidated — v1 had 5 appendices and v2 has 4, with renumbering
What comes next
The PR remains open for review. Once the SIP number is assigned, the proposal moves to the CAB for formal consideration and vote. The forum thread remains open for any outstanding questions. Below are expected SIP phase timelines, but these could change if further community review is needed or other factors arise.
Links
Learn more about the Stacks governance process here.