RFC: Minimum-bid PoX (to thwart Bitcoin MEV)

I made an attempt at back testing various values for how well the minimum-bid logic presented by @jude would work. I would appreciate it if someone can either confirm to have arrived at a similar conclusion or can check my work. Here is the summary of my findings. Attached is a google sheet that has the detailed logic.

Window Size False Positive (Percent of blocks with valid miners
that missed Sortition. Ideally this value would be 0%)
False Negative (Percent of blocks (since row 101896) where malicious miner was awarded the block anyway. We want this to be close to 0%) Malicious Blocks Saved (total of 11.24% of blocks where malicious since row 101896)
3 10.60% 3.82% 66%
4 9.59% 4.79% 57%
5 8.79% 5.63% 50%
6 8.06% 6.26% 44%
7 7.43% 6.90% 39%
8 6.89% 7.36% 35%
9 6.42% 7.66% 32%
10 5.98% 8.08% 28%
11 5.59% 8.46% 25%
12 5.26% 8.75% 22%
13 4.99% 9.03% 20%
14 4.73% 9.36% 17%
15 4.49% 9.57% 15%
16 4.27% 9.72% 14%
17 4.09% 9.93% 12%
18 3.91% 10.06% 10%
19 3.74% 10.16% 10%
20 3.57% 10.29% 8%

Link to spreadsheet: Muthu's Copy of PoX payouts over all time - Google Sheets


This RFC would only add the minimum PoX bid. The L1 speed improvements will take the better part of the year to implement and test, so they belong in a separate SIP.


Thank you @jude for the clarity and assuring the community that this is something that can be addressed in a timely manner. I am in favor.


Looks like a serious issue indeed! I support a resolution. Thanks to everyone involved in bringing this to light :pray:

If we’re going to do a quick fork, it would be wise to also get a resolution to the issue in where it currently takes 2 stacks blocks instead of 1 to fetch the Bitcoin block header (see issue here). Currently Stacks 2.1 doesn’t work as described in SIP-15 which is a problem for governance

@FriendsFerdinand is currently working on a PR. We’ll see if we can get something out by 9am ET today, if not it would make sense to get help from someone from the Core Engineering team here


Given the minimum-bid has a high percentage of false positive (percent of blocks with valid miners that missed sortition) (see message above), I also created an alternate version that defines F(B) as Minimum(Median(last B blocks)). But, this creates an even higher rate of false positives although it vastly reduces false negative.

So, then I tried including a percentage factor P. The idea being we are looking for the bid to be a certain percent of the min of median of last B blocks. Below is the false positive and false negative rates with different values for the percentage factor and window size of 10.

Percentage Factor (window size 10) False Positive False Negative Malicious Blocks Saved
0.1 0.48% 0.11% 99%
0.2 0.97% 0.08% 99%
0.3 1.69% 0.08% 99%
0.4 2.41% 0.08% 99%
0.5 3.23% 0.08% 99%
0.6 4.33% 0.08% 99%
0.7 5.73% 0.08% 99%
0.8 8.75% 0.08% 99%
0.9 13.60% 0.08% 99%
1 17.80% 0.08% 99%

Percentage factor of 0.5 would result in only half of the PoX payout returning while reducing to False Positive rate of 3.23% and achieving False Negative rate to 0.08% (compared to 5.98% false positive 8.08% false negative with a simpler F(B) that looks at minimum aggregate pay out of last 10 blocks).

Spreadsheet here for perusal. Min of Median PoX Bid (with percentage factor) - Google Sheets

Please let me know if there are any errors in my logic or if I have any misunderstanding in my interpretation of the proposal. Thanks.


Thanks for the proposal Jude. And sorry for crushing the party right away.

As some of us know - Stacks is confronted with a critical centralization problem. About half a year ago one mining entity gained >51% of the mining power and is censoring the blockchain. To be clear, at the moment they don´t censor transactions (as far as we know) but they rule out other miners who want to start mining. They simply don´t download their blocks from time to time and initiate siblings/forks. This leads to BTC losses, a centralized mining field and a lower stacking yield.

Since last September they are in control of 70-100% of the mining power most of the time!

Atm 77% due to the fact that the F2Pool miner joined the party with around 15%.

We understand that the actual MEV situation is critical for sBTC but unfortunately the SP2Z miner is the last anchor against a 100% centralized mining field at the moment.

For those who are in disbelief, we published a new stacks dump for 2.1 at: Stacks Dump

Have a look at the red (orphaned) blocks e.g. BTC Block 781607. SP11 won Stacks block 99153 but the entity simply ignored it and created a sibling in BTC Block 781607. No block reward for SP11.

You can find all addresses which belong to the entity at the end of the Dump (one color).

Btw. we had forks >4 blocks deep yesterday due to this issue/behavior. Kraken as an example confirms deposits after 4 blocks.

At the moment the entity earns around ~1BTC per day due to the missing competition. BTC which should partly belong to Stackers. What if they would decide tomorrow to raise the tx fees by let´s say 500%?

We appreciate an emergency hard fork but it must include a fix like RFC: L1 Speed Improvements if we want to call Stacks a decentralized blockchain again.

If we add a minimum payout before we solve this centralized situation, we will remove the final obstacle for the controlling entity.

1 Like

The minimum proposed is to be a function of the aggregate bids in the block. Not a minimum for each miner. Can you clarify how you think this provides an unfair advantage ?

The comment is about how removing MEV today effects the current mining landscape, not about technical details.

1 Like

Have a look at BTC Block 781455-781456 (Link). Small miners like SP2P and SPN8 produced correct blocks in an event where the entity was offline. Without these miners 3 out of 5 BTC Blocks (781451-781456) would be empty.
And the controlling entity would win+3000STX on top without a single commit. => It supports centralization.

Pre-Commits like proposed in “RFC: L1 Speed Improvements” could solve this isssue?

Another possible mechanism could use reward weighting. Mining rewards mature after a period of time, and in a weighting scheme, the rewards do not necessarily go directly to the block winner. Instead, the protocol looks at a window of block winners, and splits the reward over that window according to the proportion of funds committed during that bitcoin block.

For example,

Bitcoin block 1 → 3 miners participate, total committed funds are 1 BTC, block A is selected
Bitcoin block 2 → 3 miners participate, total committed funds are 1 BTC, block B is selected
Bitcoin block 3 → 1 miners participate, total committed funds are 0.001 BTC, block C is selected
Bitcoin block 4 → 3 miners participate, total committed funds are 1 BTC, block D is selected
Bitcoin block 5 → 3 miners participate, total committed funds are 1 BTC, block E is selected
Bitcoin block 6 → 3 miners participate, total committed funds are 1 BTC, block F is selected
Bitcoin block 7 → 3 miners participate, total committed funds are 1 BTC, block G is selected

Say the “reward window” is size 5. When Block A’s reward matures, its coinbase reward (let’s use 4 STX as the reward to simplify things) is split amongst the miners of A, B, C, D, E – weighted by the amount of funds committed in their bitcoin blocks. So miners of A, B, D, E get ~1 STX, and the miner of block C gets ~0 STX. When Block B’s reward matures, miners of B, D, E, F get ~1 STX, and the miner of block C gets ~0 STX. When Block C’s reward matures, miners of D, E, F, G get ~1 STX, and the miner of block C gets ~0 STX.

Obviously, this proposal would alter the incentive structure of the protocol (almost any change to the protocol does) and would require further investigation, but it would eliminate the coinbase incentive for MEV.


Another possible mechanism could use reward weighting . Mining rewards mature after a period of time, and in a weighting scheme, the rewards do not necessarily go directly to the block winner. Instead, the protocol looks at a window of block winners, and splits the reward over that window according to the proportion of funds committed during that bitcoin block.

This is interesting and seems more incentive aligned.

Ultimately, I think this is a good thing to happen now and discuss solutions before sBTC goes live. It’s also validating to see major BTC miners participating in STX!

Now that 2.1 is live we should have mining pools live soon so it would good to put extra attention on the efforts the Stacks Degens team is making with that. I can see the launch of these mining pools raising mining participation by at least 100x.


Hey everyone! Thanks for all the comments and suggestions here. @jude and I discussed this issue some weeks ago and in general, we’ve known about this potential MEV vector for a long long time. For example, I even responded to comments by @bergealex4 on Twitter about Bitcoin miners potentially doing this.

We’ve floated the idea of a minimum bid as a clear way to stop MEV from Bitcoin miners. It basically means that Bitcoin miners will have to bid at least a minimum amount of BTC to get the STX rewards (if they don’t bid at least the minimum amount then they get 0 STX even if they try to censor other miners).

The solution Jude proposed above is in-line with this thinking. Jude is debating what would be a good way to calculate the minimum bid. I think aiming for 90th percentile of the bids in the last 1,050 blocks (so approx one week) is one way to do it.

Also, it’s great that Stacks layer is becoming so successful that even Bitcoin miners are looking for MEV. This was only a theoretically thing earlier and now we have some evidence. We could’ve implemented the minimum bid earlier but thought the issue was very theoretical at that time and didn’t prioritize it enough. It can be prioritized now.

In terms of the actual implementation and roll out. I don’t think there is any need to rush the update. This mining pool has been doing this for weeks already. There is no direct impact on the protocol correctness. It’s a question of potentially reduced BTC rewards to stackers but the absolute reward rate is significantly up already from a few months ago. I’d personally treat this as any other upgrade that improves the network. Test it throughly. Also, consider if there are any other small tweaks after the 2.1 launch (like the mempool issue that Aaron discovered recently) that can also be packaged into the same release and then follow the standard upgrade process to put a new binary out.

If a new binary can be out within weeks that’d be amazing!


If this was not already implied: A possible approach could be to use the stacks miner Btc pre-commitments described from the rfc L1-speed increase (when live) to judge the difference between the aggregate amount of Btc that was precommited vs actual to determine whether to grant the Coinbase reward.


Agree with Muneeb, I don’t think there’s any rush on this. It’s doesn’t break Stacks and stacking rewards are way up in $$ terms regardless. It was expected this would happen at some point. Many may not agree but I wouldn’t even be worried if all miners started doing this now and PoX rewards went to zero in the short term. It doesn’t even break sBTC fundamentally. While Stacking has Product/Market Fit there will be many other Product/Market Fits from apps built on top of it. It’s validating miners are taking note of STX and there’s several viable ideas on how to counter this we can explore to figure this out and implement before sBTC goes live.

1 Like

I believe stacking yield is one of the most compelling use cases for hodling STX. I fear concentrating too much on the decentralization of mining and/or taking more time to implement a hard fork to correct this issue will be to the detriment of stackers earning their associated yields. I know continuing the network as it currently is doesn’t break the network at the moment but Stackers and the TVL they provide should not be put on the back burner. There are far more stackers than miners yet both are equally as important to the successful operation of the network imo. I’m part of the keep yields high camp as I ultimately believe this is what will also attract the most users to Stacks. We start accepting the fact of lower yields now, regardless of its USD value, stackers will have a hard time getting that value back :weary:

I don’t think anyone is arguing that the update should not go live soon. Technically the change is not very complicated so it can be tested relatively quickly. My comment is more like that instead of doing something within days and rushing, it is OK to take a few weeks and not rush this out. I do not think a few weeks make any meaningful difference if the tradeoff is that developers can do more testing and follow the standard procedure for pushing new upgrades. It will not take months or years to push this live :slight_smile:


We appreciate this proposal and look forward for an implementation. Anyway, we strongly believe that it must go hand in hand with the proposal: “Improve Throughput by Disincentivizing Missed Sortitions”.

Otherwise Stacks won’t get decentralized again - upcoming decentralized mining pools will suffer big losses (like other independent and smaller miners at the moment) and won´t be able to compete.

I like @aaron’s idea with the weighted block rewards. The nice thing with that solution is that the honest miners get to reap the rewards of the miner that censored them, further encouraging honest mining.

The other piece of information that we have that could be useful is miner history. If miner A participates in block N, there is a high probability that they participate in block N+1. This information could be factored into some scoring mechanism, i.e. each miner that participated in block N-1 but did not participate in block N increases the probability that the winner of block N was censoring miner transactions and should be punished. This information could help to target censoring miners, while still allowing honest miners with small commit amounts to sometimes get lucky and win the full block rewards.


This is fascinating. But how do you know it is one entity and not the result of some systemic failure (bug or misconfiguration)? For example, it looks like your node is missing information on lots of blocks that did have PoX bids (e.g. 781165), so perhaps there is some programmatic issue leading to these forks?

I had noticed that the MEV miner’s blocks are almost always forked away except by a couple of other miners. But I was inclined in the other direction to think that maybe those miners are cooperating somehow.

Either way I agree that these forks and missed sortitions are highly problematic and the pre-commits idea seems like a good direction.

1 Like

I’d like to just take a step back here. Is this actually a problem that needs solving? Perhaps this hinting to us the direction of the evolution of Stacks. PoX is a great bootstrapping mechanism, but does it need to persist indefinitely, especially since there is now a new use case for Stacking (controlling the sBTC peg wallet)?

As @jude mentions, this is actually a good development as it means that Stacks is providing real value—enough so to get BTC miners considering it when mining. So while Stacking for PoX yield does indeed have a product market fit, it’s no longer the only reason to Stack as we’ll soon have sBTC.

Stacking plays a central role in sBTC by serving as the ongoing reward to sBTC wallet signers for being available to process sBTC unwrapping without charging the user a basis point fee.

If I understand correctly, there are no fees incurred when unwrapping sBTC? If so, I’d like to challenge that design assumption. If we allow fees for unwrapping then we now longer need PoX to incentivize Stacking as Stackers can now generate fees from unwrapping. Also, allowing a fee market to develop for unwrapping sBTC, can help address the sBTC collateral problem that has been discussed recently. If those that are unwrapping can specify a fee for priority in unwrapping, then it could give potential sBTC users more comfort in knowing that they can get out of sBTC quickly if the collateralization ratio falls too low for their risk tolerance.

If [merge mining is] 100%, then this tactic is unworkable

Agree with this. Once Stacks is 100% merged mined by BTC miners then the proposed solution will no longer work as all miners will just have their own dust bid included in BTC blocks so no amount of looking back at previous blocks will work. Since being 100% merged mined is a desired outcome, as that means Stacks is backed by all of BTC hashpower, then it makes any solution we have to this “problem” moot in the future. Our saving grace for Stackers is that by then we’ll have sBTC, so if we have fee market for sBTC processing then Stacking can transition from getting its yield from PoX to getting its yield from sBTC processing.

1 Like