The randomness problem on a deterministic chain
A Solidity casino game is a set of instructions stored on a blockchain. The chain itself is deterministic: every node that runs the same transaction must arrive at the same result. That design creates an immediate tension. A slot spin or a card draw needs an unpredictable input, but a deterministic network has no built-in source of surprise. The game contract therefore has to import randomness from somewhere else, and where it imports it from shapes what the player is trusting.
There are three common approaches. The first is a commit-reveal pattern, where the player and the operator each submit a hashed value, then reveal the values, and the game combines them to produce an outcome. The second is an external randomness oracle or verifiable random function service that signs a random number off-chain and delivers it to the contract. The third, used mainly in low-stakes or casual games, derives a pseudo-random result from block data such as the block hash or timestamp. Each approach has a different failure mode, and understanding that failure mode is more useful than knowing which library the contract imported.
| Approach | Where the randomness comes from | What the player must trust | Main weakness |
|---|---|---|---|
| Commit-reveal | Combination of player and operator secrets | Neither side colluded or withheld a reveal | Operator can abort after seeing the player's value |
| External oracle or VRF | Signed random number from an off-chain service | The oracle service and its key management | Oracle compromise or delayed callback |
| Block-data derivation | Block hash, timestamp, or similar chain data | No miner or validator manipulates the block | Predictable or influenceable by block producers |
None of these methods makes a game fair by itself. They make an outcome verifiable after the fact, or resistant to a specific kind of tampering, or simply convenient. Fairness is a separate question from randomness, and it is answered by inspecting what the contract publishes before the bet and what it reveals after.
What the smart contract can prove
A Solidity game can publish the logic that turns a random input into a result. If the contract is verified and its source is readable, a player can check the payout table, the bet limits, and the function that maps the random number onto a game outcome. That is a real property, and it is different from what a traditional online casino offers. In a conventional game, the player trusts the operator's server and the testing laboratory's report. In a Solidity game, the player can read the code directly.
What the code cannot prove is solvency, and what it cannot remove is the house edge. A contract can be perfectly random and perfectly transparent while still returning less than it takes, because the edge is written into the payout arithmetic. The random input decides which outcome occurs; the payout table decides what that outcome is worth. Those are two separate layers, and a player reading a contract should look at the second layer just as closely as the first.
Provably fair schemes are a subset of this. A hashed server seed published before play and revealed afterwards lets a player verify that the outcome was not altered after their bet. That verifies individual round integrity. It does not verify that the game's return rate is favourable, that the operator can pay large wins, or that the contract has no other withdrawal restriction. Integrity of the random draw and generosity of the payout table are independent properties.
Where the house edge lives in a Solidity game
Every negative-expectation game, on-chain or off, works the same way at the arithmetic level. The contract accepts a wager, resolves a random outcome, and pays according to a table whose expected payout is less than the wager. The gap between what goes in and what comes back, averaged over an enormous number of rounds, is the house edge. Return to Player, or RTP, is the same relationship stated from the player's side. For the same bet under the same rule set, house edge and RTP sum to 100%.
Suppose a game pays 2x on a win and the random input gives a win with probability p. The expected return per unit wagered is 2p. If p is less than 0.5, the expected return is below 1, and the shortfall is the edge. Nothing about the randomness changes that arithmetic. A perfectly unpredictable random source with a payout table that returns less than the wager is still a negative-expectation game. A predictable or manipulable random source with the same table is a negative-expectation game with an additional risk on top.
That distinction matters when reading Solidity code. A player who finds a weakness in the randomness has not found a way to beat the game; they have found a way to know the outcome in advance, which is a different and usually forbidden thing. A player who finds a payout table that returns less than the wager has found the ordinary business model of the game. The second discovery is not a bug.
Why short sessions look nothing like the long-run average
RTP and house edge are statements about a very large number of rounds. They say nothing about what happens in a hundred spins or a thousand hands. In a short session, the actual return can be far above or far below the theoretical figure, because the variance of the game dominates the small sample. A high-volatility game pays rarely but pays large amounts, so a player can be ahead for a long time and then give it back in one sequence, or vice versa. A low-volatility game pays often but in small amounts, so the balance drifts down more steadily. Volatility does not change the RTP; it changes how the path to the long-run average looks.
Suppose a game has a theoretical return of 97% and a player wagers 1,000 units over a session. The expected loss is 30 units. The actual result could easily be a win of several hundred units or a loss of several hundred, because the standard deviation of a short sequence is large relative to the expected loss. The player who wins did not beat the edge. They experienced a favourable draw from a distribution whose mean is still negative. The player who loses heavily did not encounter a rigged game. They experienced the other tail of the same distribution.
Decisions per hour magnify this. A game that resolves quickly exposes more wagers to the edge in the same time period. Total expected loss is the product of the edge, the average wager, and the number of rounds. A player who speeds up play is not changing the edge; they are increasing the number of times it is applied. That is a choice about session length and pace, not a strategy for changing the outcome.
Why progression systems redistribute outcomes
A progression system changes the size of the wager after wins or losses. Doubling after a loss is the most famous example. The arithmetic of a progression is straightforward: it does not change the probability of any individual outcome, and it does not change the expected return per unit wagered. What it changes is the shape of the distribution. Most sessions end with a small win, and a small number of sessions end with a very large loss. The expected value of the combined strategy is the same as the expected value of flat betting, minus the same house edge applied to a larger total amount wagered.
The reason progressions feel effective is that they convert frequent small wins into rare large losses. A player who doubles after every loss will usually recover the previous losses and finish slightly ahead, until the sequence of losses grows long enough that the required wager exceeds the table limit or the player's balance. At that point the accumulated loss is large. The system has not removed the edge; it has concentrated it into a tail event. The player has traded a steady, predictable loss rate for a lottery-like distribution with the same negative mean.
In a Solidity game, the same logic applies. The contract enforces the bet limits and the payout table. A progression is just a sequence of wagers whose sizes follow a rule. The contract does not know the rule and does not care. The random source produces outcomes independently, and the edge is applied to each wager. No ordering of wager sizes changes the expected value of the sequence.
What a player can control
What varies under a player's control in a Solidity casino game is the same set of choices that exists in any negative-expectation game. The player chooses which game to play, and different games carry different edges. The player chooses which bet within a game to make, and different bets on the same table carry materially different edges. The player chooses the pace of play, which determines how many times the edge is applied per hour. The player chooses the session length and the stopping rule. The player chooses the wager size relative to the balance, which determines how long the balance can survive a losing sequence.
None of those choices turns a negative-expectation game into a positive one. They change the rate of loss, the variance of the session, and the probability of walking away at a given moment with a given balance. A player who wants to understand a Solidity game should read the payout table, identify the bet with the lowest edge, and treat the randomness as a solved problem: it produces an unpredictable outcome, and the payout table decides what that outcome is worth. The interesting question is never whether the game is random. It is what the game pays when the random number lands.
FAQ
Can a Solidity game be provably fair and still have a house edge?
Yes. Provably fair verifies that the outcome was not altered after the bet was placed. It says nothing about the payout table. A game can be cryptographically verifiable and still return less than it takes over the long run, because the edge is written into the payout arithmetic, not into the randomness.
Does reading the smart contract tell me the RTP of the game?
It can, if the contract is verified and the payout table is readable. The RTP is a property of the payout table and the probabilities it assigns to each outcome. A player who can read the contract can compute the expected return for a given bet. A player who cannot read the code is relying on whatever figure the operator publishes, and should treat that figure as a claim rather than a verified fact.
Why do some Solidity games use an external oracle for randomness?
Because the blockchain itself has no native source of unpredictable data. An external oracle or verifiable random function service signs a random number off-chain and delivers it to the contract. That solves the predictability problem but introduces a trust assumption: the player must trust that the oracle service is not compromised and that its key management is sound. The trade-off is between on-chain verifiability and off-chain trust.
Play responsibly
Gambling should be treated as paid entertainment, never as a way to earn income or recover losses. 1-800-MY-RESET (1-800-697-3738)
18+ or 21+ depending on where you are; follow the minimum age that applies to you.
This article is general information about how these mechanics work. It is not legal advice and not a recommendation to gamble or to use any particular operator. Availability and legality differ by jurisdiction — check the rules that apply where you are.