Every provably fair platform on earth ends its fairness page with the same sentence. Do not trust us. Verify it yourself. Here is the link. We have written that sentence ourselves, at length, with screenshots, in a whole post about how to check a Satoshie outcome. It is true and I stand behind it.
It also hides a verb. Verifying a draw means asking. The proof is a mathematical object, but you do not have it. It lives on a chain, and getting a copy of it means sending a request over the internet to a machine owned by a company you did not choose, cannot name and have never had a conversation with. So on 2 October 2026 I went and asked twelve of them the same question, and wrote down what came back.
TL;DR
- I queried twelve public Base RPC endpoints for the same block, 52,088,320, at 18:33:07 UTC on 2 October 2026. Nine returned byte-identical data. Three did not answer at all.
- Agreement is not evidence that the providers are honest. Block data is self-authenticating, so a provider cannot fabricate a result that survives being compared against anyone else’s.
- The real threat model from an RPC is narrow and nameable: it can omit and it can substitute. It cannot forge a VRF proof that verifies.
- Both of those failures are detectable by disagreement, which is why the practical defence is not a trustless endpoint but two endpoints that do not share an owner.
- Three of the twelve endpoints listed in the canonical chain registry answered a machine-readable request with a bot challenge or a redirect. Public infrastructure is not uniformly reachable.
- A second reader catches a lying reader. It does not catch a lying writer. On an L2 that distinction is load-bearing and almost nobody states it.
The verb in “verify” is “ask”
Here is the chain of custody for a fairness claim you check on your phone. A smart contract on Base emitted an event. A node somewhere holds that event. Your wallet, your block explorer tab and the game’s own front end each send a JSON-RPC request to some endpoint to retrieve it. Each of those three has a default compiled in or configured by somebody else, and none of them show you which one they used.
That is not a scandal, it is how reading a blockchain works for everyone not running their own node. What is a bit of a scandal is how rarely anybody finishes the sentence. “Verify it yourself” gets presented as the moment trust ends. It is actually the moment trust changes shape, from trusting an operator to trusting a data provider, and the second is better than the first for reasons worth stating precisely rather than assuming.
So I asked twelve
I took the HTTPS endpoints that the ethereum-lists chain registry publishes for chain ID 8453, the file that chainid.network serves and that Chainlist and a pile of wallets consume, and added the well-known public endpoints that registry does not carry. Twelve in total. To each I sent the same eth_getBlockByNumber request for block 52,088,320, a block that had already settled by the time I started.
Nine of them answered. All nine returned the same block hash, 0x387e023051471c48bc87f6e9847f18ae2d5f7512249ee2a06d44de64adb338d6, the same state root, 0x1724f5bf6cfcab31cc64f8eeefa34a32dcbb07d6d5a33073f298cb0fff2f8d4a, the same timestamp of 1790965987, and the same transaction count of 278. Not similar. Identical, field for field. The nine were mainnet.base.org, developer-access-mainnet.base.org, base-rpc.publicnode.com, base.drpc.org, 1rpc.io/base, base.meowrpc.com, base.gateway.tenderly.co, rpc.baseazul.dev and xrpc.cl/base. For a tenth opinion I asked Blockscout’s REST API, which is different software run by a different company and is not JSON-RPC at all. Same hash, same timestamp.
Three endpoints never answered. base.llamarpc.com returned HTTP 403 and a Cloudflare interstitial, twice, several minutes apart. rpc.satelink.network did the same. rpcfree.com/base-rpc returned an nginx 301. None of those is a wrong answer about the chain. They are an absence of an answer, which is a different thing and, as it turns out, the thing you actually need to watch for.
One detail worth keeping. Asked for the current head rather than a settled block, they did not agree: three said 52,088,376 and two said 52,088,377. That is latency, not contradiction, and a useful reminder that the tip of the chain is a moving claim while a settled block is a fixed object. Each request took a tenth to two tenths of a second. The whole exercise cost nothing.
Why nine strangers agreed, and what that is not evidence of
The nine did not agree because they are trustworthy. They agreed because they could not usefully do anything else. A block hash is a commitment to the block’s contents and a state root is a commitment to the state. An endpoint that wanted to tell you a different story about block 52,088,320 would have to hand you data whose hash does not match the hash every other participant has, which you notice the instant you ask a second party, or produce a hash collision, which it cannot.
That constrains what a hostile or broken RPC can do to you, and the constraint is the most useful thing in this post. It can omit: return nothing, return a stale view, tell you there are no events for that address. It can substitute: answer accurately about a thing that is not the thing you meant, which is devastating and easy if whatever told it which thing to ask about was already compromised. That is the front end problem one floor down the stack, and it is why pinning a contract address from a source that is not the platform’s website matters more than any of this.
What it cannot do is fabricate. It cannot hand you a VRF proof that verifies against the coordinator’s published key but was never produced by the coordinator. Not because the company is nice. Because the proof is checked against a key it does not hold, and the result is committed in a hash thousands of unrelated parties already hold a copy of.
Omission and substitution are both detectable by disagreement. Fabrication is impossible. So the full security requirement for the reading layer collapses to one sentence: ask more than one party that does not share an owner. You do not need a trustless RPC. There is no such thing and chasing one is a waste of a weekend. You need two, and the second one costs nothing.
The green tick is a report, not a proof
While we are being precise about this, the “Contract Source Code Verified” badge on a block explorer deserves the same treatment. That badge is Etherscan telling you that it compiled some source code and obtained bytecode matching what it has on file for that address. Both halves of that are claims made by one company, rendered in one company’s HTML.
The difference between that and an RNG certificate is not that the badge is more honest. It is that the badge is convertible. Fetch the bytecode yourself with eth_getCode from an endpoint that is not Etherscan, compile the published source with the stated compiler version and optimiser settings, compare. It is an afternoon of work and roughly nobody does it, me included. But the underlying object exists and is reachable without anyone’s cooperation. When a casino’s auditor certifies an RNG there is no underlying object: the report is the artefact, and the only path to a second opinion runs through the first party’s permission.
The catch: most people have one source three times
Here is where the advice gets uncomfortable. “Check two sources” assumes you have two. In practice a player has their wallet’s default endpoint, the explorer link the site handed them, and the dApp’s own bundled provider, and there is a decent chance at least two of those terminate at the same infrastructure company. A small number of providers serve an enormous share of all RPC traffic in this ecosystem. You cannot determine any of this from the three interfaces in front of you, because none of them tell you whose machine answered.
Asking one party three times feels like diligence and provides none. I do not have a clean fix beyond the obvious one: pick a second endpoint by hand, once, from the public registry, and keep it in a bookmark.
And note what the three dead endpoints teach. A registry entry is not a promise of reachability, and a 403 from a bot challenge looks very similar to “no data” if you are not reading status codes. If your verification routine treats an empty response as a negative result rather than as a failed request, you will eventually conclude that a draw did not happen because Cloudflare did not like your user agent.
The limit almost nobody states
Nine independent readers agreeing tells you the readers are consistent. It does not tell you the writer is correct. Every one of those nine endpoints on Base is ultimately downstream of a single Coinbase-operated sequencer. They agree because they are all faithfully relaying the same canonical chain, and they would agree just as cheerfully about a bad block, right up until L1 inclusion and the fault-proof machinery did their work.
So the honest version of my measurement is narrow: it demonstrates that the view of the chain is consistent across unrelated parties. It demonstrates nothing about whether the chain itself is being produced correctly. Those are different guarantees with different failure modes and different fixes, and conflating them is how “decentralised” ends up meaning “I asked two websites”.
It is also a different question from the one about who is storing your proof. That one asks whether the data is still retrievable in four years; this one asks who hands it to you today. A proof can be perfectly archived and still reach you through a single party.
What this means for a Satoshie draw
Our draws resolve on Base. The Chainlink VRF coordinator address is fixed in the deployed contract and readable before anyone stakes. The random word arrives carrying a cryptographic proof. The coordinator verifies that proof on-chain before the callback that selects a winner is permitted to execute, which means the check is a precondition of the transaction rather than an audit performed afterwards by anybody’s goodwill.
Follow that through and you get the claim I actually want to make, which is smaller and more defensible than the usual one. When you go and verify a Satoshie draw, you are not the first person to check it. You are the cheapest. Every node that validated that block already executed the same verification as a condition of accepting it, and they did so without knowing who you are or caring what the outcome was. Your check is a re-execution of something already performed by parties with no relationship to each other and no stake in the result.
That is the real content of “verify it yourself”, and it is not a statement about your diligence. It is a statement about the fact that nobody can stop anyone else from looking, and that everyone who looks gets the same answer or is visibly wrong. Our integrity does not depend on you personally doing the work. It depends on the work being available to anyone who wants it, which is a much better property, because it survives you being tired.
Honest limits, because this cuts both ways
Three things that are true and inconvenient.
One: our front end reads the chain through a provider, exactly like yours. We do not run our own node. If our provider returns stale state, our interface shows a wrong number, and we would find out the same way you would. The only thing I can promise is that the interface being wrong cannot change who won, because the selection happened in a transaction that neither we nor our provider participated in.
Two: “use two RPCs” is advice that almost nobody will take. I am not going to pretend a usability problem is solved by telling players to work harder, because that is the oldest dodge in this industry. What we can do is publish our contract addresses and chain ID somewhere that is not our own website, so pinning them does not require trusting us first. What we cannot do is make anybody check, and a verification route that nobody walks is a marketing feature.
Three: the correct answer is to run your own node, and essentially nobody will. Light clients are improving and will eventually make it reasonable on consumer hardware. Until then everyone in crypto, us included, is doing verification by delegation. Delegating to nine parties who do not know each other beats delegating to one party that also owns the game, and that gap is the entire argument, but it is not the absence of delegation and should not be sold as one.
Three questions to ask any platform, including this one
- When you say “verify it yourself”, can I name the company whose server I would be asking? If I cannot, I have not verified anything. I have been reassured, which is the product a casino already sells.
- Do my wallet, your explorer link and your app read the chain from the same provider, and can I determine that from any of the three interfaces?
- If that provider returned an empty result for my draw tomorrow, what is my second source? Having one is a plan. Not having one is a feeling.
The photograph at the top of this post is four public telephones bolted to the same wall. You can ring the same number from any of them, and if one line is dead you walk two metres and use the next. That is the entire guarantee, and it is a good one. It was never that the line is honest. It is that there is more than one line, and nobody gets to tell you which one to use.
Satoshie runs provably fair raffles and coinflip on Base, settled with Chainlink VRF. Come and check our arithmetic, preferably from an endpoint we have never heard of.
📷 Photo by Eduardo Sánchez on Unsplash
