On Saturday, Bitcoin block 961,632 kicked off mandatory signalling for BIP-110, a soft fork proposal most of the network wants nothing to do with. Miner support was reported below 3%. The breakaway chain mined two blocks and then more or less stopped, because it inherited Bitcoin’s mining difficulty with a rounding error’s worth of hashpower, leaving blocks landing hours apart instead of every ten minutes. There is now open talk of a hard-fork fallback.
Every write-up framed this as a failure. For BIP-110 it clearly is. But strip out which proposal it was and look at what happened, because crypto gaming has nothing remotely like it.
TL;DR
- BIP-110 entered mandatory signalling with under 3% miner support, mined two blocks, then stalled with hours between blocks after inheriting difficulty it could not sustain.
- How it failed matters more than that it failed. Bitcoin’s rule changes have three properties crypto gaming’s do not: proposed in advance in readable form, refusable by anyone running a node, observable in real time from outside.
- This is the ninth unasked half of fairness: a VRF proof shows the draw was honest under the code that ran, not that it is the same code as last week or that the numbers held between your stake and your settlement.
- Rule changes hide in upgradeable proxies, config setters, off-chain parameters and “we may amend these terms at any time”. The question is not whether rules can change, but how much notice you get and whether you can decline.
A rule change that fails in public is a process working
The change was written down in advance, in a document anyone could read, long before a single block signalled anything. It could be refused unilaterally: not upgrading your node was a vote, and enough people cast it. And the outcome was observable while it happened, with no statement from the proposers required. You could count the signalling yourself, then watch the block timestamps stretch out.
That last detail is the elegant part. A chain inheriting difficulty it cannot sustain is a self-reporting failure: the evidence of its weakness is the gap between its own blocks, with no press office and no disclosure threshold in the way. Now name the equivalent in crypto gaming. When did a platform last publish a change to its game logic in advance and let you keep playing the old version?
The ninth unasked half of fairness
Eight instalments so far on what “provably fair” quietly does not cover: whether they can pay you, whether the payout is ordered honestly, whether randomness arrives, whether the front end matches the contract, what recourse survives finality, what they know about you, whether winning and being paid are one event, and who else is in the draw.
Here is the ninth. A VRF proof establishes that one outcome was derived from verified randomness by a specific piece of code. Its scope begins at the request and ends when the callback fires. It certifies the honesty of a single execution, and nothing about the durability of the rules around it.
So a game can be provably fair on Monday and provably fair on Friday under materially different terms, both proofs verifying perfectly. The payout multiplier, the fee, the ticket price, the win threshold, the contract address the front end points at: none of it is inside the proof. You verified an outcome, not a rulebook.
Where rule changes actually hide
Upgradeable proxies. The address in your bookmark stays the same and the explorer still shows a verified contract, while the implementation deciding your coinflip is swapped in one transaction. The pattern is not dishonest and it is genuinely useful for bug fixes. It is also an admin key wearing a helpful expression, and the same authority that ships a fix ships anything else.
Configuration setters. The contract never changes at all. setFeeBps, setPayoutMultiplier, setMaxStake and their cousins mean the code is permanent and the numbers are not, and depending on the design they can move between the block where you committed and the block where you settled.
Off-chain parameters. If the paying outcome is computed in a server process, the rules are not a deployment, they are a config file. No address to watch, no transaction to see, no diff to produce. A rule change and a Tuesday look identical.
The terms themselves. “We reserve the right to amend these terms at any time” describes a change process where proposal, vote, announcement and effective date are the same instant, frequently retroactive. Not a bad clause because lawyers wrote it. A bad clause because there is no signalling period and no way to decline.
The tell is whether a change has a clock
All of that collapses into one question, and it is not “can the rules change”. Rules should be able to change, and Bitcoin’s can, which is precisely why BIP-110 reached mandatory signalling at all. The question is how long you get, and whether refusal is available.
Bitcoin’s answer is months, and yes. A config setter’s answer is one block, and no. That is not a difference of degree in governance quality, it is the difference between a rule you agreed to and a rule applied to you. Reversibility is a permission, withdrawal delays are a permission, upgradeability is one too, and in each case the platform’s good intentions are irrelevant. What you are assessing is the existence of the capability, not the character of whoever holds it.
What Satoshie claims, stated narrowly
No admin key. No proxy. No setter for any parameter that decides an outcome. The contracts are verified on BaseScan and immutable. A coinflip is one modulo on the VRF word. A raffle is keccak256(VRF word + prior blockhash) % ticketsMinted, with ticketsMinted readable as contract state before you enter. Escrow, resolution and payout happen in one transaction.
The falsifiable version, the only one worth anything: read the bytecode. If a function exists that can change the odds, the fee or the payout, you can find it without our help. If it does not exist, there was never anything to announce.
The honest caveats. Immutability cuts both ways and our own bugs are permanent too, a trade rather than a free win. New logic means a new contract at a new address you must actively choose to use, which is the point rather than a workaround: a change you decline by doing nothing, exactly as node operators declined BIP-110. Our front end is an ordinary web application and stays the least trustworthy thing we ship. Base’s sequencer is operated by Coinbase and ordering is not decentralised today, with data posted to Ethereum mainnet and L1 forced inclusion as the backstop. And on-chain gaming has no consensus process at all: no signalling, no threshold, no coordination. Weaker than Bitcoin in the obvious way, stronger in that nothing new applies to you unless you send a transaction to it.
Three questions to ask before you play
- Is the contract that decided your last result upgradeable, and if so, who holds the key and what is the timelock?
- Can any function change the payout, fee or win condition after you have staked, and how many blocks would that take?
- If the rules changed last month, could you produce the diff without asking the platform for anything?
BIP-110 got two blocks and stopped, and anyone could watch it happen. Bad week for a proposal, very good week for a process. Crypto gaming has no equivalent of those two blocks, and until it does, “provably fair” is a claim about one execution inside a rulebook you were never shown.
📷 Photo by Jens Lelie on Unsplash
