How Chainlink VRF resolves every Lemon Jet round

Every Lemon Jet round comes down to one number. You pick a multiplier, sign a transaction, and a smart contract on Base decides the outcome using randomness it cannot influence. This post walks through what actually happens between those two moments, and how to check every step of it yourself.

Where the randomness comes from

When your bet lands on-chain, the game contract requests a random word from the Chainlink VRF coordinator. That request is a transaction like any other: it has a hash, it sits in a block, and it carries an identifier that ties it to your round.

Some time later — usually a handful of blocks — the coordinator answers. It does not simply hand back a number. It returns the number together with a cryptographic proof that the number was derived from a key the coordinator committed to in advance, combined with the seed from your request. The game contract verifies that proof on-chain before it will accept the value.

This ordering is the whole point. The proof cannot be produced for an arbitrary number of someone's choosing, and the contract will not settle a round against a value whose proof does not check out. Nothing in that path can be replayed, reordered or nudged by the house, because the house never holds the number before the proof is verified.

A useful way to think about it: the randomness is not something the game provides. It is something the game asks for and then checks. Those are very different trust models, and only the second one can be audited by a stranger.

Reading the on-chain data

Rounds and payouts are indexed as subgraph entities, which makes distributions straightforward to sanity-check over time rather than one round at a time.

If you only care about a single round, the block explorer is enough. Your bet transaction emits an event carrying the round identifier. The fulfilment transaction from the coordinator carries the matching request identifier. Line those two up and you have the full history of that round: what was asked, what came back, and what the contract did with it.

If you want the aggregate picture instead, query the subgraph. Resolved rounds carry their requested multiplier and their outcome, so you can plot the realised distribution against the theoretical one and see whether they agree. Over a large enough sample they should, and if they ever did not, the data to prove it would be public and permanent.

Verify a round in two steps

1. Open your transaction on BaseScan and find the RoundResolved event.
2. Match its request id against the VRF fulfilment in the same block range.

event RoundResolved(
    uint256 indexed requestId,
    address indexed player,
    uint64  multiplier,
    uint256 payout
);

If both identifiers line up, the outcome you saw in the interface is the outcome the contract computed. Nothing else is needed — no support ticket, no screenshot, no trust in us at all. That is what "provably fair" is supposed to mean, and it is worth being precise about it, because the phrase gets used for a lot of things that are neither provable nor fair.

Note what this does not claim. Verifiable randomness does not mean a game has no house edge, and it does not mean any individual round was in your favour. It means the number was not chosen to hurt you, and that you can demonstrate that yourself rather than taking anyone's word for it.

FAQ

Can the house see the number before I do?

No. The coordinator's answer and its proof arrive in the same transaction, and the contract verifies the proof before it settles. There is no window in which the game holds an unverified number and could decide what to do with it.

What happens if the VRF request is never fulfilled?

The round stays unresolved rather than settling against an arbitrary value. Funds are not moved on an unfulfilled request, because the settlement path runs only after a proof has been verified.

Does verifiable randomness mean there is no house edge?

No, and anyone telling you otherwise is selling something. The edge is a separate, publicly documented parameter applied to each multiplier. Verifiability is about whether the number was honest, not about whether the odds are neutral.