What the house edge actually is on a provably fair game
Verifiable does not mean free. Here is what the edge is, where it lives in the contract, and how to read it yourself.
"Provably fair" and "no house edge" are two different claims, and only one of them is true about Lemon Jet. Conflating them is the single most common misreading of on-chain games, so it is worth separating carefully.
Two independent questions
When you place a prediction, two things determine what happens to your money.
The first is whether the random number was honest. That question is settled by Chainlink VRF: the contract verifies a cryptographic proof before it accepts a value, so the number cannot have been chosen to hurt you. This is what "provably fair" means, and it is fully verifiable by anyone.
The second is what the payout schedule looks like. If you pick a multiplier, the contract has to decide how often that multiplier should win in order for the game to remain solvent. That relationship — win probability against payout — is the house edge. It is a design parameter, not a property of the randomness.
A game can have honest randomness and an edge. A game can also have a dishonest generator and advertise no edge at all. The two axes are independent, and only the first one is something cryptography can answer.
Where the edge lives
The edge is not applied by a server, and it is not adjusted per player. The contract calculates and stores the winning threshold when it accepts the bet. When randomness arrives, the round wins if the mapped random value is at or below that threshold. The threshold gives a lower probability than the break-even point for the selected multiplier.
This has two consequences worth stating plainly.
It is public. The exact parameters are readable in the deployed contract on BaseScan, which is linked from every post on this blog. You do not need us to tell you what the edge is; you can read it. If a number in our interface ever disagreed with the number in the contract, the contract is the one that decides what happens to your funds.
The current deployment uses a nominal 1% house-edge parameter. Its integer arithmetic determines the exact probability for a particular multiplier; rounding can make the effective edge slightly higher. Network gas and the randomness-request cost are additional expenses paid separately.
The verified game implementation does not expose a setting that changes the odds for an individual wallet, session or losing streak. The whitepaper gives the formula and distinguishes the deployed contract's rules from the interface around it.
Why an edge exists at all
Someone has to be on the other side of your prediction, and that side needs capital to pay out when you win. Over a large number of rounds, the edge is what funds that capital and keeps the game able to settle.
A zero-edge game would have no expected gaming margin before operating costs, but its solvency would still depend on its capital, payout limits and actual results. An edge does not guarantee solvency either. Both the probability model and the available backing matter.
In Lemon Jet, the vault also supports referral and reserve share allocations. The full nominal edge is therefore not a promised return to depositors. The vault guide explains that position.
What this means for a single round
The edge affects the probability of every round. What it does not do is tell you which result that round will have.
At a 2x target, the current contract's winning threshold gives a 49.5% chance under its uniform-roll model. A win returns twice the stake in total; a loss returns none of it. That produces a theoretical gross return of 99% of the stake before separate native-token costs, not a promise to recover 99% of what you spend in a session.
A run of wins does not remove the edge, and a run of losses does not by itself establish manipulation. The next result still depends on its own verified random value.
The honest summary: the randomness is verifiable, the payout schedule is public and unfavourable by a documented margin, and both of those facts are readable on-chain. That is a narrower promise than "fair" usually implies, and it is the one we can actually keep.