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 through the Chainlink VRF direct-funding wrapper. The request is included in your bet transaction and carries an identifier that ties it to your round. The Chainlink direct-funding documentation describes the wrapper and callback flow.

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 coordinator verifies that proof on-chain, then the wrapper delivers the random value to the game contract's callback.

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 bet transaction on BaseScan. Find GameStarted in the logs from the game contract and record its requestId, player, bet and chosen multiplier (coef).
2. Find the later fulfilment transaction and its GameReleased event from that same game contract. Match requestId and the player address, then inspect the payout and random number. Submission and settlement normally occur in separate transactions.

event GameStarted(
    uint256 indexed requestId,
    address indexed player,
    uint256 bet,
    uint256 coef
);

event GameReleased(
    uint256 indexed requestId,
    address indexed playerAddress,
    uint256 payout,
    uint256 randomNumber,
    uint256 x
);

These events let you reconcile the result in the interface with the game contract's record. Check the emitting contract as well as the identifiers; matching event names from an unrelated contract is not evidence of your round. If GameStarted exists but GameReleased is still absent, use the transaction status guide to distinguish confirmed submission from pending settlement.

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?

The coordinator verifies the proof before the wrapper delivers the value to the game for settlement. There is no application step 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. The stake has already been committed by the bet transaction, and network and request fees may already have been paid. A confirmed bet transaction alone does not establish that the payout callback succeeded. See the transaction status guide for the checks.

Does verifiable randomness mean there is no house edge?

No. The house 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.