DEV Community: Blog Post

How to Verify a Provably Fair Game Result Yourself

Blog Post — Thu, 01 Oct 2026 13:25:33 +0000

You can check a provably fair result by hand with three inputs: the server seed the site revealed after your bets, the client seed you supplied, and the nonce, a counter that numbers each bet made under that pair of seeds. The check has two parts. First, the SHA-256 hash of the revealed server seed has to equal the one the site published before you played. Second, all three values go through HMAC-SHA256, and the first bytes of the output, converted to a number, have to reproduce the game result.

The worked example below uses invented seeds and the common SHA-256 and HMAC-SHA256 construction rather than any one site's specification, and Python's standard library and Node's crypto module cover it. The proof is also narrower than its name suggests: it shows where a result came from and leaves the odds where the paytable put them.

The hash shown before play locks in one server seed

Every seed pair starts with the site. It generates a server seed, keeps it secret and shows you only its SHA-256 hash, 64 hexadecimal characters that stand for 256 bits. Nobody can work backward from that hash to a properly random seed, which is why the site can afford to publish it ahead of your first bet.

Publishing that hash first commits the site to one seed, since editing the seed would, in practice, change the hash as well. FIPS 180-4, the NIST standard whose August 2015 edition defines SHA-256, puts the property this way: "Any change to a message will, with a very high probability, result in a different message digest." A site that swapped in a friendlier seed after seeing your bets would have to reveal one whose hash no longer matched the hash it had shown you.

One habit follows from that. Copy the hash somewhere of your own before you bet, because a verifier that fetches the original hash from the site at checking time trusts the site's memory of its own promise. On Ethereum, the chain keeps that copy for everyone. The Speedrun Ethereum guide, which lists sealed-bid auctions and voting among the scheme's uses, builds its base contract to store each commitment on-chain and reject a second one from the same address.

A client seed only protects you if it arrives after the hash

The server seed alone would let the site settle everything in advance, so the scheme adds a value from your side. A site that knew your client seed when it committed could, in principle, have generated a great many server seeds, computed your first results under each and kept the one it liked. A client seed entered after the new hash appears closes that door.

So change the default, and change it again each time you retire a pair. A client seed the site generated for you may have been known to it at commit time, and so may one you reused from an earlier pair. It doesn't need to be long or secret, and no value is luckier than another; its only job is to be something the site couldn't have predicted.

The nonce does the rest, rising by one with each bet under the same pair, so one pair of seeds yields a fresh message every round, devto-reader:1 and then devto-reader:2. The server seed stays hidden while the pair is in use, and it has to, since anyone holding it could compute the next result early. Verification is therefore retrospective. You retire the pair, the site reveals the old server seed and commits to a new one, and only then can you check.

Six steps and two library calls rebuild the result

Each step below is a plain operation in any language with a hash library, and none of them needs another value from the site beyond the four in step 1.

Collect four values from the retired pair: the hash you saved before betting, the seed the site revealed afterward, the client seed you set, and the nonce of the round you want to check.
Compute the SHA-256 hash of the revealed server seed and compare it with the saved hash, character by character. If they differ, stop, because nothing after this step can be trusted.
Build the message by joining the client seed, a colon and the nonce, which gives devto-reader:1 for the first bet in the example.
Compute HMAC-SHA256 with the server seed as the key and the message as the data, and write the result out as 64 hexadecimal characters.
Take the first eight of those characters, the first 32 bits, read them as an unsigned integer and divide by 4,294,967,296, which is 2 to the power of 32, to get a fraction from 0 up to, but never reaching, 1.
Multiply the fraction by the number of possible outcomes, 37 for a single-zero roulette wheel, and round down. The whole number you get is the pocket.

In Python, step 2 is one call to hashlib.sha256 and step 4 one call to hmac.new, which takes the key as bytes and, since version 3.8, insists that you name the digest. Node's crypto.createHmac takes the algorithm name and the key. The rest is string handling and arithmetic.

Every input moves the pocket, but only one breaks the commitment

Here are the steps run on seeds short enough to type, where a real server seed would be a long random string. The server seed is orchard-lamp-5521, the client seed devto-reader and the nonce 1. The server seed's hash begins with d9e7e144. The HMAC output begins at 60626324, the integer 1,617,060,644, and dividing by 4,294,967,296 gives 0.3765. Times 37 that is 13.93, so the ball lands in pocket 13. Each later row changes one thing.

Scenario	What changed	Seed hash begins	HMAC begins	As an integer	Fraction	Pocket
Reference Round	Nothing: orchard-lamp-5521, devto-reader, nonce 1	d9e7e144 (matches)	60626324	1,617,060,644	0.3765	13
Next Nonce	Nonce 2, the following bet	d9e7e144 (matches)	e00ba11b	3,758,858,523	0.8752	32
Edited Client Seed	Client seed devto-readers	d9e7e144 (matches)	a531a965	2,771,495,269	0.6453	23
Swapped Key Order	Verifier used the message as the key	d9e7e144 (matches)	3e0b9ccc	1,040,948,428	0.2424	8
Replaced Server Seed	Server seed orchard-lamp-5522	8e69f737 (fails)	972f1261	2,536,444,513	0.5906	21

Run the reference round twice, or in two languages, and it lands on 13 every time, which is what makes an outside check possible at all. Change any input by one character and you get what amounts to a fresh draw. Adding an s to the client seed moves the ball from 13 to 23, not to 12 or 14.

The last two rows fail in different places. The swapped-key row still passes the hash check and lands on 8, an error that lives entirely inside the verifier. Changing the server seed's final digit gives a hash beginning 8e69f737 instead of d9e7e144, so that round fails at step 2, before its pocket means anything.

When the numbers disagree, suspect the verifier first

Before blaming a site, test the HMAC function itself. RFC 4231, a standards-track document from December 2005, publishes test vectors for HMAC-SHA-256 that it says "have been cross-verified by three independent implementations." Its second test case uses the key "Jefe" and the message "what do ya want for nothing?", and the correct output begins 5bdcc146. Any other answer means the bug is in your code.

Past that test, look for input slips. Two of them move the reference round straight off pocket 13. A newline copied from a terminal onto the end of the message sends it to 31, and counting nonces from 0 when the site counts from 1 gives pocket 0 for what you think is the first bet.

The key can go wrong too. A server seed written as 64 hexadecimal characters is a 64-byte key when passed as text, exactly SHA-256's block size by RFC 4231's count, and a 32-byte key when decoded from hex first. Both are valid keys, and they produce different digests.

Unicode is the quietest trap. The client seed café can be five bytes, with a composed é, or six, with a plain e and a combining accent, and with the example's server seed at nonce 1 the two versions land on pockets 34 and 22. Node's documentation warns that it "does not normalize character representations," so stick to plain ASCII letters and digits.

The 4,294,967,296 possible values don't divide evenly by 37

Step 6 hides a small unevenness that no seed can remove. Thirty-two bits give 4,294,967,296 possible integers, and 37 doesn't divide that number, which leaves a quotient of 116,080,197.19. Share the integers among 37 pockets as evenly as arithmetic allows and seven pockets get 116,080,198 while the other 30 get 116,080,197.

The remainder operator makes the effect easy to see. Payam Bijeh's DEV post on modulo bias, from February 2026, shows it at toy scale, where 16 possible outputs squeezed into six outcomes give four of them three chances each and the other two only two. Taking the integer modulo 37 hands the seven extra values to pockets 0 through 6, while step 6's multiply-and-round-down spreads them to pockets 0, 5, 10, 15, 21, 26 and 31.

Either way the unevenness is about one part in 116 million, against a house edge of one part in 37 on a single-zero wheel, far too small to change anything at the table. It still matters to a verifier, because the two methods disagree about individual rounds. The reference integer, 1,617,060,644, lands on 13 by scaling and on 27 by remainder, so whichever method a site documents is the one to copy.

A verified round still pays 35 to 1 on 37 pockets

Suppose the reference round had been a real bet on 13. A straight-up bet on a single-zero wheel pays 35 to 1 against 37 pockets, so the expected return is 36/37 of the stake, or 97.30%. That return only shows up across a very large number of bets and promises nothing about one session, while the house keeps its 2.70% however many rounds check out.

The seeds can't vouch for games they don't feed, so the scheme matters most for games an operator builds itself, where its own server decides each result and no outside studio's certification stands behind the draw. Shuffle, a crypto casino that holds its gaming license in Curacao, draws the line in that same place: its homepage at https://shuffle.com/ attaches a provably fair algorithm and a built-in round checker to the in-house Originals, Crash, Plinko, Mines and Dice among them, and says outside studios' games are tested and certified by external bodies instead.

Its terms bar anyone located or living in the US, the UK, a dozen other named places or anywhere its service isn't permitted by law or would need a local license, and nothing in this tutorial depends on an account there. A clean check says nothing about what your money is worth, either, since a crypto balance can fall against the dollar between deposit and withdrawal while every round in between verifies perfectly.

That leaves one decision, and it concerns who runs the arithmetic. A site's built-in checker is convenient, but its code comes from the same operator whose results it checks. The independent version is the few lines you wrote yourself, tested against the Jefe vector and pointed at the reference round until it printed 13.

Can Fable create an entire casino game library as of today?

Blog Post — Mon, 28 Sep 2026 04:57:51 +0000

In June, one DEV author wrote that Fable 5 ran continuously for more than 30 minutes before coming back with a three.js racing game, which then needed a few more iterations to match his design goals. When Anthropic launched Claude Fable 5.1 on September 1, its announcement quoted Canva's head of AI saying the new model had built a rhythm game in Canva Code with real music and on-beat gameplay.

Can a model that turns a brief into a playable game also produce a casino's worth of them? As of September 24, 2026, the answer has two parts. Fable 5.1 can plausibly draft much of one slot's code, maths and documentation. It can't supply what turns that code into a library that Ontario's regulated market will accept.

The province makes a good test case, because its rules for online games are public and detailed. The Registrar's Standards for Internet Gaming, set by the Alcohol and Gaming Commission of Ontario (AGCO), came into force on April 4, 2022, when the province's regulated online market launched. What follows walks a hypothetical AI-built slot through them.

What Fable 5.1 brings to a game build

Anthropic's model page pitches Fable 5.1 at demanding reasoning and long-horizon agentic work, and says it brings stronger long-running agentic coding than Fable 5, which came out on June 9. It reads up to 1M tokens of context, roughly 2.5 million Unicode characters by Anthropic's own conversion, and returns up to 128K tokens of output per request.

One slot's rules module, reel configuration, client and server code, specification and test logs can plausibly fit in that window at once, letting the model check that the paytable in the code still matches the one in the rules text.

Its limits show up at the edges. The model page lists its input and output as text and images in, text out, so a finished slot's symbols, animation and sound come either from code the model writes or from other tools.

A slot is a maths model before it is code

Some of the paperwork Ontario wants for a game is maths. Standard 4.05 requires documented game specifications that state the game's objectives, the wagers a player can make, how it is played, the odds of winning each prize and the operator's advantage on each wager. Standard 4.06 adds that before a bet, players must get enough information to judge their chances of winning and how prizes are paid, with the odds or return to player set out in help pages they can follow.

Generating candidate numbers is the easy half. A model can write reel strips, a paytable and a simulation that plays them a billion times, which reports an estimate of the return to player, with sampling error however long the run. Gaming Laboratories International, one of the labs on the AGCO's list, says return to player can be calculated by a theoretical or a simulated approach depending on the game type.

Exact evaluation is where the maths can get hard. In a 2024 paper on formal modelling of slot machines, Jan Friso Groote, Sander van Heesch and Matthias Volk wrote that determining the return to player can be involved, especially when a player's choices affect the game. They described an actual machine from Errèl Industries as a probabilistic process specification and computed its return to player exactly and automatically.

The words on screen are regulated as well. Standard 4.07 bars game information that suggests an outcome is more likely than it is, and gives "due", "overdue", "ready" and "ready to hit" as examples. A model writing a slot's help screens and win messages has to be held to that rule, not just those four words, as firmly as to the paytable.

Randomness is a standard, not a function call

Randomness gets its own standards, starting with 4.26. It requires a mechanism that randomly selects the game elements behind each outcome, seeded "in a way that ensures the randomness of the resulting game outcomes and avoids any correlation" with other instances of the same mechanism. Outcomes can't be swayed by the size of the wager or the style of play unless the change is clearly disclosed, and 4.24 adds that a slot's result can't depend on its history.

JavaScript's built-in `Math.random()` shows why generated code needs checking against that text. MDN's reference for Math.random() says it "does not provide cryptographically secure random numbers", and that the implementation picks its initial seed, which the user can't choose or reset. That is thin ground for a game server that has to show how its seeding avoids correlation, and 4.26 also wants the mechanism impervious to outside influences, the player and the operator among them.

A model can write a sturdier version around the Web Crypto API's `getRandomValues()`, which MDN points to for anything related to security, or a server-side generator built for the job, plus statistical tests. Standard 4.27 then requires the selection mechanism to be capable of being monitored and inspected, and whether it passes is a finding for someone other than the author of the code.

One more requirement in 4.26 bears directly on code a model writes. Selected outcomes "shall not be altered, discarded or otherwise manipulated through a secondary decision by the game program", so the program can't re-draw or adjust a result it has already selected. The same line adds that they "shall not be impacted by load on the gaming system", which makes a shortcut taken under heavy traffic a fairness question as well as a performance one.

The certification gate

Standard 4.08 sets it out. Games, random number generators and the parts of a system that accept, process, determine the outcome of, display and log details about player bets, "including any subsequent modifications", must be approved by the Registrar or certified by an independent testing laboratory the Registrar has registered before they reach any gaming site.

As of September 24, the AGCO's list of registered labs had eight names: BMM North America, Eclipse Compliance Testing, eCOGRA, Gaming Associates Europe, Gaming Laboratories International, Global Lab, Quinel and Riskcherry.

The clause about modifications is where an AI workflow meets the process. Under the AGCO's certification policy, the supplier sorts the changes between a certified version and a new one into one of three categories and keeps the records. Cosmetic changes and minor bugs unrelated to the standards need no new certificate. Changes related to the standards, including a game-design change that could affect one, must be certified before deployment. An emergency fix for a live integrity problem can ship first, but it has to reach a lab within five business days.

So a model that regenerates a game's maths quickly doesn't shorten the path to players; it adds builds to the certification queue, and the AGCO says the timing of this step depends on lab capacity and the scope of the certification. Standard 4.11 also requires production, testing and development systems to be logically separated, so an agent working in a development environment isn't meant to have a path to a live game.

Rule	What it asks for	What a model can draft	What it can't supply
Standard 4.05	Documented objectives, wagers, odds of each prize and the operator's advantage	The specification and paytable	Independent confirmation that the numbers are right
Standard 4.26	Seeding that ensures randomness; outcomes untouched by stake (unless disclosed), secondary decisions or load	RNG code and statistical tests	The finding that the generator complies
Standard 4.08	Registrar approval or registered-lab certification of games, RNGs and bet-handling parts, later changes included	Build notes and change logs	The approval or certificate itself
ITL Certification Policy	A recorded category for each set of changes; regulatory changes certified before deployment, emergency fixes sent to a lab within five business days	A proposed category for each diff	The recertification

Launch offers stay with the operator

Say the lab signs off and a registered studio releases the game. It still has to find players. Booming Games, which says it releases four games every month, works with operators on additional activations and promotions once a title is live in their lobbies, aiming for momentum that outlasts the few days around release. A batch of spins on the new title is the natural tool; the trade site NEXT.io called free spins "the most familiar mechanic in iGaming".

Ontario's Standard 2.05 settles where that promotion may appear, and the answer is narrow. Bonus and inducement marketing is barred everywhere except the operator's own gaming site and messages sent to players who opted in to receive them, and the AGCO counts a general nudge to find out about offers on a gaming site as indirect advertising. A launch offer on our hypothetical slot would therefore sit inside the operator's site or app, or in an opted-in player's messages.

That leaves what a public page may show each reader instead, which varies by province and which this article can't keep current. BonusFinder Canada's answer to free spins no deposit ontario depends on where the reader is: the site says local regulations bar it from advertising online casino bonuses in Ontario, where it lists licensed casinos by features, payout speed and number of games among them, while readers elsewhere see the no-deposit spin offers it can show in their province, most with wagering terms in a details panel.

Launch offers are still gambling offers. Online casino play in Ontario is 19+, and since May anyone of that age has been able to use iGaming Ontario's BetGuard portal to exclude themselves from the whole regulated market, OLG's sites among them, for a fixed term of six months, one year or five years, or for a custom period. BetGuard also tells operators to stop direct marketing to anyone who enrols. ConnexOntario's free line, 1-866-531-2600, is open 24/7 and puts callers in touch with gambling support services.

Who gets to press publish

Everything above assumes a company the province lets supply games at all. To supply igaming operators in Ontario, the AGCO's supplier page says, "you need to be registered with the AGCO", and the providers it names as needing registration include "suppliers that manufacture, develop, provide or run games and game systems". A supplier can start running or supplying games once the AGCO confirms its registration.

The application is built for people and companies, not software. Among the documents the AGCO may ask for are financial statements, government-issued identification, personal history forms, tax returns, a diagram of everyone holding 5 per cent or more of the business and a description of its quality assurance process. A supplier that wants to offer more than its application described has to tell the Registrar and be approved.

The lab paperwork points the same way. The certification policy doesn't say who must request a certificate, but it expects that to be the game provider most of the time, and each certificate must name the product, its version number and its manufacturer. So a game library in Ontario needs a registered supplier behind it and an approval or certificate behind each game, and as of today Fable 5.1 can be neither that supplier nor the manufacturer a certificate names.