Every provably fair platform makes its promise in the present tense. The draw is verifiable. The proof is on-chain. Go and check it yourself.
All of that is true, and we have written it here more than once. But verification is not a property of a draw, it is an act, and acts happen at a particular time, using particular infrastructure, at somebody’s expense. The moment a winner is picked, the proof is settled. The moment you decide to go and look at it, four months or four years later, you are making a request of a machine that is under no obligation to answer you.
Nobody in crypto gaming talks about that gap, ourselves included, so here is the honest version.
TL;DR
- Settled and retrievable are different properties. A Chainlink VRF proof is verified on-chain at fulfilment time by every node that validated the block. Fetching it back afterwards is a separate problem with separate infrastructure.
- State is mandatory, history is voluntary. Nodes must carry current state to validate the next block. Old transactions, receipts and event logs are kept by whoever chooses to keep them.
- Rollup data has an explicit expiry. Base posts its batch data to Ethereum in blobs, and blobs carry a retention floor of 4,096 epochs, roughly 18 days, after which consensus nodes drop them by design.
- This is not a manipulation risk. Nobody can retroactively change who won a draw. The risk is quieter: an audit you cannot run because no one within reach still serves the data.
- The fix is boring and it is yours. Four fields copied at play time (game transaction hash, requestId, fulfilment transaction hash, random word) turn a future audit from a favour into a comparison.
Where a Satoshie proof actually lives
Run through the mechanics, because the argument depends on them.
Your bet goes in. The contract asks the Chainlink VRF coordinator for randomness and an event goes out with a requestId attached. Some blocks later the oracle comes back with a VRF proof, and the coordinator contract verifies that proof on-chain before it hands the random words to our callback. That verification is not a report, a promise or an attestation. It is a computation that every node validating that block re-ran and agreed with. If the proof had been wrong, the transaction would have reverted and no winner would exist.
Then the transaction ends, and the outcome splits into two very different kinds of data.
The first kind is state: the winner recorded in contract storage, the payout, the balances that moved. State is the part of a chain that every full node must carry, because you cannot validate the next block without it. It is replicated by economic necessity across thousands of machines that did not ask your permission and do not know you exist.
The second kind is history: the request transaction, the fulfilment transaction and its calldata, the receipts, the emitted events. This is the part you actually read when you audit a draw. The random word, the requestId that ties it to your bet, the proof material itself, all of it is history rather than state.
And history is the part chains are most willing to forget.
The obligation nobody has
A node that syncs today does not download every transaction ever executed. Modern sync strategies fetch recent blocks and the current state, which is enough to validate everything from now on and gives you an honest, fully verifying node. Ask that node for event logs from a two-year-old block range and you do not get a wrong answer. You get an error.
Answering historical queries is the job of archive nodes, and archive nodes are a product. They cost storage, bandwidth and operational attention, they are run by explorers, infrastructure vendors and the chain teams themselves, and they are funded because somebody has a commercial reason to fund them. That is a healthy market and it works. It is also, structurally, a service and not a consensus rule. No slashing condition fires when the last archive serving a given range goes offline.
Ethereum’s own roadmap has been explicit about the direction. History expiry, the long-running proposal to let clients drop ancient block bodies and receipts, exists precisely because forcing every node to store everything for ever is a tax on decentralisation. The argument for it is good. The consequence is also real: retention is being pushed from the protocol layer, where it is enforced, to the social and commercial layer, where it is merely likely.
The eighteen-day floor underneath a rollup
Now add the layer Satoshie actually runs on.
Base is a rollup. Its security story is that its data is published to Ethereum, so anyone can reconstruct Base’s state independently and nobody has to take the sequencer’s word for anything. Since the arrival of blob transactions, that data is posted as blobs rather than permanent calldata, which is the upgrade that made L2 fees cheap enough for on-chain gaming to be viable at all. We have cheered for it here.
Blobs come with a stated retention window. Consensus clients are required to keep them for 4,096 epochs, about 18 days, and after that they are free to drop them, and they do. That is not a bug or an oversight, it is the entire economic point: Ethereum sells a guarantee of availability long enough for anyone to copy it, not a guarantee of storage for ever.
So the maximal version of the trustless claim, the one where you reconstruct every Base draw from Ethereum alone, trusting no L2 party whatsoever, has a shelf life measured in weeks. After that, reconstruction depends on archives that were kept because someone chose to keep them. In practice several parties do, independently and redundantly, and the data is out there many times over. But “many independent parties chose to” is a different sentence from “the protocol enforces it”, and if we are going to be pedantic about fairness claims when other operators make them, we have to be pedantic here.
What this is not
Three things, stated plainly, because this argument gets misused.
It is not a claim that your funds or your winnings are at risk. Payouts are state. Nobody reorganises a settled draw by deleting a log file.
It is not a claim that the result could be quietly rewritten. Retrieval and revision are opposites. A missing archive does not let anyone fabricate a different winner, because any fabricated record would fail to match the copies everyone else holds and would not verify against the coordinator’s on-chain logic in the first place.
It is not a warning about a chain shutting down or a validator set rolling back valid history. Those are separate failure modes with separate posts. This one is quieter than all of them: the machinery works perfectly, the proof is exactly where it always was, and the only thing that changed is how many people still find it worth serving.
Self-custody your proof, it takes ten seconds
The useful response is not to panic about archives. It is to stop being a passive reader of someone else’s database.
When you play, copy four things: the transaction hash of your game, the requestId from the randomness request event, the transaction hash of the VRF fulfilment, and the random word it returned. Paste them into a note. That is the whole ritual.
What you have done is turn a future audit from a request into a comparison. In three years, if an explorer still serves the data, you check your copy against it in a minute. If the explorer has changed hands, redesigned its API, or quietly stopped indexing that far back, you still hold the specific values, so you can go to a different archive and ask a narrow question instead of a broad one. And crucially, you hold something that lets you notice a discrepancy at all. Someone with no record cannot detect a wrong answer, only the absence of an answer.
This is the same instinct as running your own node or holding your own keys, scaled down to something you can do from a phone while the draw is still on screen.
The narrow claim, kept narrow
We would rather say the small true thing than the large impressive one.
Chainlink VRF proves that the number which picked the winner was not chosen by us, could not be predicted by us, and was checked by the chain before the contract was allowed to act on it. That guarantee is finished the moment the block is sealed, and no amount of future infrastructure decay reaches back and weakens it.
Retrievability is a different animal. It is not cryptography, it is housekeeping: nodes, indexes, storage bills, someone’s willingness to keep serving a range of blocks that nobody has queried in a year. It can be done well or badly, by us and by everyone else, and the honest thing to say is that it depends on parties rather than on maths.
Most operators never separate the two, because bundling them sounds better. “Provably fair, on-chain, verifiable for ever” is one clean sentence and two distinct promises, one of them enforced by consensus and one of them enforced by goodwill and disk space. Knowing which is which is the difference between trusting a system and understanding it.
Keep your four fields. Verify the arithmetic yourself. And be suspicious of anyone whose fairness claim gets vaguer the further back in time you point it.
📷 Photo by Tyler (@tylergm) on Unsplash
