Introducing the Bitcoin Staking SIP v1 Draft

[alexlmiller]

Hi all, a few updates

First, the 500 STX boost, we’ve reviewed the options for alternative funding of the coinbase boost based on your feedback, and have decided to eliminate the additional 500 STX boost in each block and just keep the long term adjustment of the coinbase reward back to 1000 STX.

In the case that we do end up wanting to do a boost at some point to help the growth of the program, it would be funded directly by the Endowment. Thanks to some suggestions plus insights from the core devs and the Endowment team, we were able to identify a way to handle the concept of the boost in a more targeted and on demand way by actually feeding sBTC directly into the PoX-5 contract as needed - allowing us to be conservative with the Endowment’s growth budget while still getting the boost if/when we need it.

Along these same lines and re the questions about dynamic issuance, we’ll use PoX 5 to gather data about this, but we are not going to propose including that for PoX 5 as we can handle a similar capability via the above mechanism without introducing the technical and economic complexity of actually building it into consensus.

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)

Most importantly though, before we open the PR, we’ve still got the community SIP office hours this Friday (link). Please join or share thoughts below this forum post if you have any remaining feedback or concerns. We’d appreciate talking this through directly before the PR is up (but of course more discussion and updates continue to happen through that process).

Thank you to everyone who dug into the draft and pushed on questions. The feedback on funding the boost directly shaped the changes above. We’re excited to move forward on Bitcoin Staking and start attracting more Bitcoin capital to the ecosystem.

[Algorithm]

Thank you for the feedback and update.

This is the best outcome I believe.

[axopoa]

Great update! It’s awesome to see community feedback actually being included.

I wanted to add one thought about what really motivates STX miners. Do we know exactly how they operate and what their main incentive is?

Are they mining to:

A. Hold STX long-term because they think it has more upside than BTC?
B. Flip it immediately for a quick profit to grow their BTC bag?

If it’s B, what happens if mining profits drop below regular BTC staking yields? Wouldn’t these profit-driven miners just stop mining entirely and stake their BTC instead?

[friedger]

So we should assume that miners mine above the btc yield, e.g. 5%. That should be considered in the maths

[axopoa]

I wanted to share a quick piece of on-chain analysis regarding mining on the Stacks network and where those block rewards are ultimately heading.

Based on the data from jBTC, the undisputed top miner is currently this address: SP30ZB6GC6D95BF9QV9CB43TZCAJ70SWYW08YZEZA

By plugging this address into Clearsight (https://www.clearsight.space/), we can track its transactional footprint. The data reveals massive outflows, specifically a cumulative total of 6.9+ million STX sent directly to this address: SP111MNWTSXGTD0ESMV59WX4KHQA93RTV9F82EK0K

This is kraken deposit address. So we might be in the scenario B.

[codeonedotzero]

Great tool for transparency and analytics.

[aler13]

This means we will never go back to a predictable rewards halving system? Also, how can we prevent from changing the protocol again and again regarding rewards?

Thank you.

[friedger]

We stop changing when it works nicely. “Nicely” is still to be defined

[axopoa]

Yes, If we can survive long enough lol

[zeroauthority]

For the change of emissions, coinbase reward back to 1000 STX, is there a separate report or blog post on the long term halving / emissions schedule to account for the chang @alexlmiller ?

The decision to eliminate the additional 500 STX boost in each block and just keep the long term adjustment of the coinbase reward back to 1000 STX.

Previously, we had a thorough report from the 7th Avenue Group Emissions schedule report January 2025

Stacks Halving Schedule: Reports and Recommendations

Emissions Research and Proposed Adjustment Discussion The Stacks layer’s first token-emissions halving is scheduled for January 2025, so it’s important for the community to review the projected change in advance. These halvings are a key part of tokenomics which plays into miner participation, network growth, and overall token supply. To best understand any changes, we commissioned two research reports to provide the community a more detailed look into the planned token emissions. The Stacks to…

[PeaceLoveMusic.btc]

I want to make a proposal, because I think the disagreement here is narrower than the thread makes it look. The question isn’t whether to launch Bitcoin Staking. It’s whether to bundle a permanent monetary change with a demand thesis that hasn’t been tested yet.

The June 9 update may have already solved this. The Endowment-funded sBTC injection mechanism described for future boosts is a general tool. It adds BTC to the reward pool without touching consensus emissions and that’s the entire stated purpose of the coinbase restoration.

An alternative path could be to launch PoX-5 on the current SIP-029 schedule and cover the Tranche 1 gap with Endowment sBTC during bootstrap. At 500 per block the pool runs around 74 BTC a year at the prices in Appendix A3. A 1,500 BTC launch at 3% needs 45 of that, and getting to the 2x coverage target takes an injection on the order of 15 to 20 BTC a year. Low single-digit millions, well inside the budget @axopoa already laid out. Zero dilution. The partner still earns the same 3% self-custodial yield. And the network has been producing blocks fine at 500 since April, so the security case for restoring 1,000 is really a staking capacity case, which the injection covers.

Then put the permanent emission restoration to its own vote after a bonding period or two, with real data behind it. If the demand shows up, that vote passes easily and I’d support it. If it doesn’t, holders kept the schedule they were promised in SIP-029.

If the authors feel the restoration has to ship in this SIP, then make it provisional rather than permanent, along the lines of @friedger’s soft anchor. Revert automatically to the SIP-029 schedule after a defined number of bonding periods unless the program hits stated milestones. Bonded BTC beyond the whitelist, sustained coverage, fee growth. Emissions that are earned by demand arriving, not spent in anticipation of it.

This also seems strictly better for the proposal’s chances. The mechanism is genuinely novel and deserves a clean launch. Right now the most contested thing in this thread isn’t Bitcoin Staking, it’s the monetary change attached to it. Separate them and the vote gets easier.

@alexlmiller is there a reason the injection mechanism can’t carry the bootstrap?

[alexlmiller]

In terms of whether the injection mechanism could cover the whole bitcoin staking rewards budget: it both understates how much is needed (it assumes only 1,500 at launch and doesn’t account for the future bonding periods that keep going every month), and in either case while the endowment has a very strong supply of STX, it does not have much BTC, so the only way to generate that would be to sell STX far in excess of what we’re comfortable with.

But the great part about this structure is that if the BTC demand isn’t there or we decied to stop issuing bonds, all the yield flows down to the STX only stakers, same as at is for the last few years.

So we either get the demand and associated growth of the ecosystem (which likely generates better rewards for stx only stakers in the long run), or the yield and operation looks like it has for the last few years.

[PeaceLoveMusic.btc]

The BTC constraint makes sense, but it points at a simpler version of the same idea. The program doesn’t need the Endowment to hold BTC. It needs miners to have a reason to bid more BTC, and that reason is denominated in STX, which the Endowment holds in strong supply from the recent SIP 031 issuance.

So fund the increment with the asset the Endowment actually has. Two ways to do it.

Keep the SIP-029 schedule and stream the extra 500 per block to miners from the treasury through a rebate contract, along the lines @axopoa laid out. Miner rewards identical to the SIP. Bids identical. Market flow identical, since the SIP already assumes miners sell their coinbase same day.

Or, if the coinbase has to be the delivery mechanism for simplicity, mint the 1,000 as drafted and have the Endowment burn the 500 increment from treasury each period. That’s the burn-offset you raised yourself on June 5 for the boost, which got mooted when the boost was dropped before it was ever resolved. Net issuance stays on the SIP-029 path. No Endowment selling at all. Nothing about the staking mechanism changes.

On selling STX being beyond what you’re comfortable with: the SIP proposes minting 26M new STX a year for miners who, by its own modeling and the on-chain data upthread, sell it same day. The market absorbs the same flow either way. The only question is whether it comes from treasury supply that already exists or new supply that dilutes every holder. Discomfort with the first while proposing the second is the part I can’t square.

On scale, the rebate or burn only needs to carry the bootstrap. That was the proposal. If demand proves out, the permanent restoration goes to a vote with real data behind it and passes easily. The fixed 1,000 doesn’t scale with demand either. Past bootstrap, fees have to carry this program under both designs.

The failure cases aren’t symmetric. If demand doesn’t come under this path, the Endowment has spent a bounded line of its growth budget, which is what growth budgets are for. If demand doesn’t come under the SIP as drafted, holders carry a permanently doubled schedule with no product to show for it. Same as the last few years, at twice the emission, isn’t the same.

The question from my last post is still open. If the restoration ships in this SIP, is there a reason it can’t revert to the SIP-029 schedule automatically if the program doesn’t hit stated milestones?

[fluidvoice]

+1 I would say Layer-2 chains like Stacks benefit from being more modifiable and fast-changing, compared to L1’s at least while they are have yet to settle on a primary use-case like bitcoin yield. Protocol immutability is an impediment for L2’s. The Stacks protocol should be as mutable as it needs to be to increase TVL and market-cap and make them long-term “sticky”.

Separately, I have seen that many in the community feel that Stacks’ design and team is not supportive of the value of the STX asset. If this is wrong, then there is a disconnect in communication… ie, I think the mechanics of this new Stacks blockchain “flywheel” design works and how it’s supportive of STX value is not very well understood. This, including things like the future possibility of STX token burning via protocol revenue, I think many people don’t know about. I think how this flywheel works, if successful, is obvious or intuitive to many of the Stacks team and institutional investors but less so to many community members and retail investors. And so because of this, they see mostly just the risks and near-term downsides.

[aler13]

My thoughts exactly. Tinkering and tinkering to get it nicely will make that the public doesnt even take Stacks seriously and it will end up failing. It would be better if the changes would be respected. I like Stacks, I have been a long time user and holder. But with this changes, I just say to myself, I will withdraw some funds in case the project “craps out“.

[fluidvoice]

Tinkering is an interesting way to describe blockchain development.
Was Ethereum tinkering when they completely changed their consensus algo from POW to POS? Was Stacks tinkering when v2.0 was released?