A Decrypt op-ed published today makes an argument crypto usually flinches at. Pauline Shangett of ChangeNOW writes that Web3 is building financial freedom only for the people who can afford mistakes, and her sharpest line is not about seed phrases or onboarding at all. It is about attribution. When the same mistake recurs across thousands of users, it stops being client error and becomes product data. Somebody built the thing that keeps producing it.
That is a payments argument. It is also, and almost nobody in crypto gaming is saying this out loud, a fairness argument.
TL;DR
- A Decrypt op-ed argues Web3 works only for users who can absorb the cost of a mistake, and that recurring user error is a design output rather than a user failing.
- Applied to gaming, this exposes the twelfth unasked half of fairness: a game can have a perfectly verifiable outcome and still be unfair in how it distributes the cost of being wrong.
- Provable fairness with Chainlink VRF covers the draw. It says nothing about unlimited token approvals, wrong-chain deposits, tickets bought into a draw already mid-flight, or odds you only learn after paying.
- The centralised answer is a refund button, but discretion that can undo your mistake can also undo your win. That is not safety, it is permission.
- The correct shape is designing errors out in code, not reversing them by favour: bounded approvals, one chain, contract-enforced entry windows, odds published before the ticket sells, and permissionless timeouts.
Fairness has two halves and the industry ships one
Every “provably fair” badge in this industry answers exactly one question: was the winner chosen honestly? It is a good question. Chainlink VRF answers it properly, with a verifiable random value and a proof anyone can check on-chain, and we have spent a lot of words on why that matters.
But it is a claim about a single moment. It covers the instant the random number lands and nothing on either side of it. Everything a player actually does, the approving and bridging and clicking and misreading, sits outside the proof entirely.
That is the gap. Outcome fairness is about whether the house cheated. Cost-of-error fairness is about who pays when nobody cheated and you simply got it wrong. The first is solved. The second is not even measured.
Where a provably fair game still takes your money
It is worth being concrete, because this argument dies in the abstract. Here are the error surfaces around an on-chain raffle or coinflip that no VRF proof touches:
- Unlimited approvals. The standard token approval flow asks you to grant a contract permission to spend an unbounded amount, forever, because it is one click cheaper than asking each time. That is not a fairness property of the game, it is a liability the game handed you to hold.
- Wrong chain, wrong contract. Multi-chain deployment multiplies the number of addresses that look correct and are not. Funds sent to a token contract, or to a deployment on a chain the game no longer supports, are simply gone. No proof will help.
- Entering a draw that has already closed. VRF is asynchronous by design. There is a window between the request and the callback, and if a front end keeps selling tickets into that window, the player pays for an entry that cannot legitimately count.
- Odds discovered after payment. Plenty of games publish the total entrant count only after the draw resolves. You verified the randomness. You never verified what you were buying a share of.
- Failed transactions that still cost. Gas spent on a reverted entry is real money, and the player has no idea whether the revert was their fault or the contract’s.
Run any of those repeatedly across a user base and Shangett’s point lands exactly: it is product data. The pattern is the design.
The refund button is not the answer
Give the centralised operators their due for a moment, because the honest comparison is uncomfortable. A traditional casino, and every large crypto casino, absolutely can fix your mistake. Sent to the wrong deposit address, bet on the wrong table, fat-fingered the stake? Open a ticket. Sometimes they reverse it. Often they do.
And that is precisely the problem. The capability to undo your mistake is the same capability as the capability to undo your win. It is one switch, not two, and the deciding factor in both cases is not code, it is whether reversing you is convenient for them today. Players remember the time support helped. They do not see the times discretion ran the other way, because those look like nothing at all.
So the answer cannot be to import the refund button. Finality is not a bug we are apologising for. It is the thing that makes the win unconfiscatable.
Design the error out, do not reverse it
Which leaves the harder path, and it is the only honest one: if you cannot reverse a mistake, you have to make it structurally difficult to make. That is a contract design problem, not a support policy.
What that looks like in practice. Approvals bounded to the exact stake, expiring, per-entry, so a compromised or malicious contract cannot drain a wallet later. One chain, so there is one canonical address and no bridge in the failure path. An entry window enforced by the contract rather than the interface, so a late ticket reverts rather than quietly taking money for a draw already in flight. Entrant count and prize terms readable on-chain before the ticket clears, so the odds are a fact you can check and not a number you are told afterwards. Refund paths that anyone can trigger after a deadline the contract enforces, rather than an onlyOwner function wearing a helpful expression.
Notice what all of those have in common. None of them requires trusting anybody to be kind. They move the protection from the operator’s discretion into the code, which is the same move provable fairness made for the draw itself. We just never finished applying it to everything around the draw.
Three checks before you buy a ticket
Verifiable in a block explorer, no permission needed:
- What am I approving? Read the approval amount in the transaction before signing. If it is unbounded and the game did not offer you an alternative, that was a choice they made for you.
- Can I see the entrant set before I pay? If total entries are only visible after resolution, you are verifying randomness over a denominator you never saw.
- Who can trigger a refund? Find the recovery function. If only an owner address can call it, the safety net has an owner, and owners have opinions.
Where Satoshie stands
We build raffles and coinflip on Base, with Chainlink VRF, on one chain, with contracts kept deliberately small. The single-chain decision has cost us reach and we keep making it, because every extra deployment is another address a player can lose money to and another dependency between a stake and a payout. Simple contracts are not a modesty flex. They are the only kind whose failure modes a player can actually read.
We have not solved every item on the list above and we are not going to claim otherwise. But the industry standard right now is to treat the moment of the draw as the whole of fairness and everything else as the player’s problem, and that standard is going to look indefensible in about two years. The cost of being wrong is a design decision. Somebody made it. Ask them who.
📷 Photo by Brendan Church on Unsplash
