Lottery software
built on provable trust.

Trust is the product in lottery

Players and regulators need to believe every draw is honest. We build provably-fair draw mechanics with signed, tamper-evident records, so every result can be independently verified.

From national-scale draws to instant scratchcards, it runs on the same wallet and compliance stack as the rest of your offering.

A draw is only as good as the evidence it leaves behind

Every lottery dispute ends at the same question: prove the numbers were not chosen after you saw the tickets. Producing a draw is easy. Producing one still provable months later, to an auditor who was not in the room, is the engineering problem.

The mechanism is commitment. Before the entry window closes, the platform generates the draw seed, publishes the hash of it, and keeps the seed sealed. The result releases the seed. Anyone can then hash it, match it to the published commitment, and re-run the deterministic function that turned it into numbers. Swap the seed to dodge a large win and the hash no longer matches. That only holds if the commitment was published before sales closed. Published after, it proves nothing.

Certified RNG draws and live-ball draws are different problems

Most operators run both, and one code path will not serve them.

An RNG draw is a software event; the evidence is cryptographic. A test house certifies the generator and the code path consuming it — an uncertified consumer can quietly discard outputs it dislikes while the generator alone still passes. RNG certification for casino games works the same way, but a lottery draw produces one output per period rather than millions per hour, so each draw carries far more weight.

A live-ball draw is physical. The software does not choose the numbers — it witnesses them. Its job is capture and custody: who entered the result, from which terminal, under whose dual authorisation, against which camera feed, with which machine and ball-set serial recorded on the draw. The risk moves from the generator to the entry point. A platform treating a live-ball result as an ordinary API write has no defence when someone alleges the numbers changed in transit.

An audit trail is a replay, not a report

Regulators do not want a document asserting the draw was fine. They want to reconstruct it. So the draw record is append-only and hash-chained — each entry carries the digest of the one before it, and editing a row breaks the chain and shows where. Configuration is versioned with the draw: prize tiers, ball set, cut-off time, the rule set live at that moment. Change a prize table six months later and it must not rewrite what an old draw paid.

Build the replay first. Retrofitting evidence into a platform that logged only outcomes is close to impossible — the data that would have proved the case was never written.

In a pari-mutuel game the prize pool is a share of what was sold: take sales, deduct the operator's share, split the remainder across winning tiers, divide each tier by the number of winners in it. Nobody knows what a prize is worth until sales close and the draw runs. Liability is arithmetically bounded — you cannot pay out more than you took in. That is why national-scale draw games survive jackpots that would bankrupt a fixed-odds book.

In a fixed-odds game — most instant-win products and number betting — you promise the prize before you know how many will win it. Sell more tickets and exposure grows with them. The tail is yours. That is why the software must model exposure per draw and per tier in real time, cap it, and stop selling a tier when the cap is hit. A pari-mutuel platform needs none of that machinery; a fixed-odds platform without it finds out on the wrong night. That exposure engine is closer to sportsbook risk management than to anything else in a draw game.

Jackpot seeding and rollover are a state machine

A rollover is not a marketing line. If nobody hits the top tier, that pool carries into the next draw, and the platform now holds money from a closed draw alongside money from a draw still selling. Different draws, different ledger balances, one advertised figure. Keep them separate or the reconciliation will not close.

Seeding complicates it: the operator injects cash to make an early draw worth playing, so the pool is part sales-funded and part operator-funded — and only the sales-funded portion behaves pari-mutuel. Rollover caps ("must be won by draw N") force a defined fallback, and that fallback belongs in the sealed configuration before the draw. Decide it afterwards and you are rewriting rules with money on the table — the fact pattern a regulator looks for.

Why a per-ticket revenue share hurts most here

Lottery economics are thin and volume-driven. Margin lives in the operator's share of each ticket, and that share is constrained by a prize structure the market expects — cut the prize fund to widen your margin and the game stops selling. So a supplier taking a percentage of turnover is not a fee. It is a permanent deduction from the only margin the product has, and it scales precisely with the volume you spent years building.

That is the case for owning the platform outright — source, IP and infrastructure, no revenue share, no per-brand licence tax. It converts an uncapped variable cost into a one-time development cost. White-label is genuinely faster and cheaper to get live, and for one small game it may be the right call; we say so on custom development versus white-label. Custom wins on volume, multiple games or markets, or an intention to sell — owned IP is the asset.

Where lottery platforms actually fail their audits

Not on the draw. The draw is the part everyone watches. Platforms fail on the accounting either side of it.

Instant-win: pre-generated pools or on-demand outcomes

A digital scratchcard can be built two ways, and the choice is not cosmetic.

Pre-generation mirrors the paper world. You create the whole ticket pool up front with a defined prize distribution, shuffle it, seal a manifest, and sell out of it. The distribution is provable because it was fixed before the first sale — an auditor can verify the pool held exactly the prizes advertised. The cost is that you are inventory-bound: the top prize may sell on day one or not at all. Exhaustion is a real state the software must handle by ending the game, not by quietly minting more tickets — the shortcut that voids the proof.

On-demand generation decides the outcome when the player scratches. No inventory, no exhaustion, easier operations. But "one in four tickets wins" is now a probability statement, not a fact about a pool: over a short run the realised distribution drifts from the advertised one, and your proof is statistical rather than a sealed manifest. Both models are defensible — not in the same way, so the code should not blur them.

Unsold inventory is the part teams forget. Closing a pre-generated game is a reconciliation, not a switch: tickets generated, tickets sold, prizes claimed, prizes that died unsold in the pool, and the delivered odds against the sealed manifest. A fairness claim with no closing statement is just a claim.

Syndicates are an accounting problem wearing a social feature

Group play looks like UI. It is ledger. Ten people buy shares of fifty tickets. One joins late. One's payment fails after the entry window. One leaves the group between purchase and draw. Then a ticket wins, and every one of those events becomes a legal question about who owns what fraction of it.

The rule that survives a dispute: a share is a claim on a specific ticket in a specific draw, recorded at purchase and immutable afterwards. Not a claim on the group. Not a percentage recalculated at payout. If a member's holding changes, that changes their claim on tickets bought from then on, and nothing before it. Prize splitting becomes arithmetic against a fixed record, not a reconstruction of history from event logs. The remainder — a prize that will not divide evenly — needs a rule fixed in advance, not a decision made while ten people watch.

Reconciliation: one ticket, one draw, one tier, one outcome

This is the test a lottery platform passes or fails. Every ticket sold must reconcile to a draw, to a prize tier — including "no prize" — and to a payout, a claim in progress, or an expiry. Sales must reconcile to the pool computed from them. Pools must reconcile to what was paid, what is unclaimed, and what has passed its claim window. Voided tickets must be traceable to who voided them and why.

The gaps are always the same. Tickets sold in the seconds around cut-off. Payments that settle after the draw has run. A wallet credit with no ticket behind it. An unclaimed prize with no expiry rule. None of it is hard engineering, but all of it has to be designed in — a reconciliation you did not build is one you cannot produce when an auditor asks, and by then the draw is a year old.

These records feed the rest of the platform. A large prize claim needs identity, source-of-funds handling and reporting under your KYC and AML controls, and a syndicate win multiplies that across every member. What the reconciliation must produce is set by the regulations you build under — which is why the reporting model is designed in from the first sprint, not assembled before certification.