Keno Development on Blockchain: Where Round Fairness Breaks
The classic failure mode looks like this: the numbers for a Keno round are generated by the operator's server-side generator, and the player sees only the finished result.
Manipulating the result is technically possible, and verification of the drawn numbers is unavailable to either the player or an independent party — there is simply nothing to publish for verification, because the round's source data remains inside the system.
The cost of such an arrangement is not just one disputed bet. Any streak of matches raises suspicion, complaints are handled manually using internal logs, and player trust disappears after the first public conflict.
In reporting, this shows as growth in the share of disputed rounds and refunds "as an exception" that the operator processes outside policy.
When developing Keno on blockchain, the scheme flips: randomness is fixed before bets are accepted or taken from a public source, and the round result is written to an immutable log.
Round fairness stops being an operator's promise and becomes a verifiable property of the contract — using the round number, the player reconstructs the input data and the final set of numbers without contacting support. Retroactively changing the set or rebuilding the round is no longer possible: any edit is visible.
Such an on-chain draw also removes operational load: disputes are closed by reference to the round record, not correspondence. We explain how it works and what changes in payouts, support, and reporting.
What Moving Game Logic into Smart Contracts Provides
Randomness in Keno determines winnings, so its source must be verifiable.
If the numbers are generated by a server-side generator, the operator has both the sequence and the ability to influence the result before bets are revealed — a dispute with the player is settled by words, not proof.
The external oracle Chainlink VRF returns a number together with cryptographic proof: it cannot be predicted before the round is fixed and cannot be substituted after — any participant verifies the result on-chain independently.
The second layer is the Keno smart contract as the settlement core.
Payout tables, bet limits, combination rules, and crediting order are described in code and identical for all rounds; after bets are accepted and randomness is revealed, the payout goes to wallets automatically in one operation.
The manual reconciliation and transfer stage disappears from the process — and with it, the withdrawal queue.
This is visible in metrics: round settlement shrinks from minutes to seconds, the share of automatic payouts reaches almost 100%, and a whole class of failures disappears — forgotten, duplicated, and incorrectly calculated credits. Round history remains public, and audit does not require exports from internal databases.
A separate issue is network operation cost as bet flow grows. It depends on the volume of writes to contract state, so payouts are sent in batches, round history is written to events rather than storage, and intermediate computations are not stored at all.
As a result, the cost of processing one bet stops growing linearly with the number of players, and load scales predictably.
Randomness Modes: Network, Hybrid, External Source
Keno outcome is a derivative of a random number, so the mode of obtaining it determines both round speed and how much trust in the operator is built into the game.
Schemes differ not by "quality of entropy" but by where the value is fixed on-chain and how the player verifies it later. Below are three modes as they are actually chosen for a scenario.
Round latency is the main differentiator here: the network source gives full transparency but ties round closure to block confirmation. Hybrid and external source remove this dependency at the cost of reveal and generator audit obligations.
| Mode | When chosen | Limitations | Round latency |
|---|---|---|---|
| Network source (verifiable random function) | Public verifiability is needed: the player verifies the result themselves, the operator decides nothing | Depends on network load, cost of request per round, round cannot be closed before confirmation | Tied to block confirmation |
| Hybrid scheme | High round frequency while preserving verifiability | More complex audit: hash of source value must be published in advance and revealed after the round | Fixed, set by policy |
| External randomness source | Non-standard ranges, own entropy generator, integration with an already running service | Trust in provider, source failure stops rounds, generator audit required | Depends on service availability |
Mode selection is best driven by scenario: live frequent rounds — hybrid scheme; focus on provability — network source; non-standard ranges — external randomness source.
One common requirement: the reveal and verification mechanism is fixed before launch, otherwise post-factum generator audit proves nothing.
Game Development Stages: From Round Scheme to Handover
The order of work is determined by the fact that round logic lives in the contract: a payout error cannot be closed by an interface update, and a fix requires deploying a new contract and migrating state.
Therefore we go from formalizing rules to checks and only then to handover — each stage relies on the confirmed result of the previous one.
- Rules analysis and game logic audit. We fix the payout table, outcome probabilities, bet limits, and system behavior on randomness source failure. The output is a specification that the client confirms before the first line of code.
- Round scheme. We describe the lifecycle: bet acceptance, window closing, randomness request, settlement, payout or refund. For each phase we set duration, role permissions, and stop conditions so no states remain from which the round cannot exit.
- Contract development. We separate bet storage, settlement, and payout reserve: failure of one module does not block fund withdrawal. We take randomness from a verifiable source, and the round result can be rechecked by proof.
- Testnet testing. We run scenarios: simultaneous bets, cancellation, contract pause, repeated randomness request, withdrawal with partial reserve. We separately measure call cost so the bet size is not eaten by network fee.
- Contract audit and acceptance. Auditors examine payout logic, admin rights, and withdrawal paths. We close discrepancies before mainnet deployment; acceptance is recorded by a checklist with a list of tested scenarios.
- Documentation handover. We provide the round scheme, deployed contract addresses, maintenance procedure and incident actions, train the client's team, and stay in touch for logic changes.
Implementation Artifacts: Code, Payout Schemes, Launch Policies
We hand over the project not as a running service under our supervision, but as a package your team can maintain and develop independently.
Everything that determines game behavior — from generating round numbers to crediting winnings — is fixed in files and checked by tests, not living in correspondence.
- Source code — round, bet acceptance, and payout calculation contracts in your repository, with build scripts and tests covering all branches of win calculation, including disputed ones.
- Round scheme — lifecycle diagram: bet acceptance, closing, randomness generation with published proof, settlement, payout. Deadlines for each step and points where the round can be paused are marked.
- Payout policy — odds table, limits per round and per player, withdrawal procedure, and rules for automatic payout stop when deviating from the expected profile.
- Access policies — role matrix: who changes odds, who funds the reserve, who stops the round. For critical operations — multisignature with a confirmation threshold.
- Launch and operation manual — deployment to testnet and mainnet, procedure for updating contracts without losing round history, rollback to the previous version.
- Monitoring policy — set of round metrics (closing time, payout share, operation cost), thresholds, and on-duty actions when triggered.
- Fairness verification methodology — how to independently recalculate the outcome of any round from published data, without access to your infrastructure.
The package is delivered with acceptance: you run the tests and the full round cycle in testnet yourself before signing. Describe the task — we will return with an estimate and handover plan.
Case Study: Moving the Draw On-Chain — Metrics Before and After
Before migration, the draw generator lived on a server, and only the round result was recorded on-chain: with 800–1200 concurrent players, settlement took 4–6 seconds. Randomness was unverifiable — the player saw the result but could not be sure it was not substituted.
The share of disputed rounds held at 0.4%, and each investigation went into manual log reconciliation, which took from several hours to several days.
What Changed
Round logic was moved into a smart contract on Polygon: bet acceptance, winner determination, and payouts are performed in one transaction, randomness comes from a verifiable randomness scheme, and the result is written to an event.
Gas cost per round was reduced sixfold — batch bet of several players in one call, odds in constants, packed structs instead of separate fields.
Metrics After
Round settlement takes 1–2 seconds regardless of participant count. Disputed payouts — zero across more than 12,000 rounds: the player verifies the result themselves via the event and open contract code.
The network withstood a peak of 40 transactions per second without missed rounds or manual fixes — previously, under such a load profile, payouts queued; now they are processed normally.
How Does Verifiable Randomness Differ from a Server-Side Generator?
A server-side generator is a closed computation: the number is born on your side, and the player sees only the result.
Provable randomness is built differently — the number is created by a cryptographic scheme with a verifiable result, usually Chainlink VRF, and together with the number a proof is published that a participant can recalculate themselves.
The difference is not in operator honesty, but in who could influence the outcome.
In a closed scheme, the number is predictable for whoever owns the server and knows its state at request time; in provable randomness, the outcome is rigidly tied to a specific request, and secretly substituting it for the desired result is impossible.
| Comparison axis | Server-side generator | Provable randomness |
|---|---|---|
| Who forms the number | Your server | Cryptographic scheme and publishing node |
| Who can predict | Server owner who knows the state | No one before proof publication |
| How it is verified | Logs and operator assurances | Open proof verification by any participant |
| What happens on failure | Manual round restart, outcome unprovable | Cancellation by contract rule, bet refund |
The cost of such a scheme is confirmation latency: the number must enter a block and receive confirmations, so a Keno round does not start instantly, as with a server-side generator.
In return, the player retains open verification of every outcome — this is no longer a question of trust in the operator.
Practical conclusion: a closed generator deploys faster and is simpler to maintain, but in a dispute there is nothing to present. Provable randomness leaves a verifiable trace on blockchain, independent of you.
Common Technical Objections and How We Address Them
Objections concern not the game itself but operations: how much the network will cost as flow grows, whether the service must be stopped during migration, whether payout rules can be changed after launch. We answer each.
Will operation cost grow with player flow?
Cost is set not by the number of players but by the number of writes to the network. The round result is packed into one record regardless of the number of bets, and result confirmation is batched across several rounds.
With tenfold flow growth, the number of operations per round does not grow, and the share of service records decreases.
Do we need to stop the service during migration?
We migrate via a proxy contract: new logic is published next to the old one, the entry point keeps its address, and switching takes seconds. The previous version remains deployed for rollback, both read state, so bet history and active sessions are not lost.
Can payout rules be changed after launch?
Rates, odds, and limits are stored as parameters, not in code. An edit takes effect from the specified round, and every change record remains on-chain — the decision is verifiable.
Invariants are immutable: maximum payout and built-in margin; changing them requires a new contract version and repeated audit.
We address scaling and audit similarly: load runs on the flow model, external review of contract logic and role model before launch, invariant monitoring after. Describe the task — we will return with an estimate and plan.Let's Discuss the Task: What Is Needed to Start Work
For the estimate to be substantive rather than "by eye", at the start we need your game rules and current round scheme: how the number sequence is formed, how the bet and payout are calculated.
With this we break the task into smart contracts, randomness source, and interface — and return with an estimate and work plan.
- Round rules and math — number generation, bets, payout table, table limits: these drive contract logic design and testing on test runs.
- Current round scheme — how the round starts, until what moment the player can cancel a bet, what happens on connection loss: this determines how logic is split into transactions.
- Randomness requirements — whether a publicly verifiable number source is needed, who and how can challenge it: this determines the generation scheme and on-chain computation cost.
- Roles and access — who on your side decides on payouts and parameters, what access we need to code, testnet, and admin panel.
- Materials — interface mockups, texts, test scenarios, and if the game is already launched — deployed contract addresses and round statistics.
- Acceptance and launch — when launch is planned, who signs off the result, whether old bet support is needed during the transition period.
Describe the task and send what you already have, even if it is free-form notes. We will return with an estimate, plan, and work order, and after approval we start immediately.