DEV Community: CryptoPlay Guide

Inside a 61-Line JavaScript Provably Fair Verifier

CryptoPlay Guide — Thu, 29 Oct 2026 13:19:29 +0000

A verifier is easier to inspect when the cryptographic operations, input rules, and game mappings fit within a small module. Version 1.1.0 of provably-fair-verifier takes that approach: one 61-line src/index.js, no dependencies, and tests built on Node's own tools.

The useful architectural question is how those pieces connect. A commitment check answers whether a revealed seed hashes to an expected commitment. A deterministic mapping answers which result follows from that seed and the other inputs. The module returns both, leaving callers responsible for interpreting them correctly.

The repository's working parts are small enough to list:

src/index.js          exported ESM implementation
test/index.test.mjs   vectors, reference generator, validation tests
package.json         entry point, test command, Node requirement
README.md            API usage and formula boundaries
CHANGELOG.md         version history
LICENSE              MIT

package.json declares Node >=18, ESM through "type": "module", and src/index.js as both the main entry and export. There are no runtime or development dependencies. The MIT license permits reuse subject to its notice requirements. Version 1.1.0 adds Mines and Plinko plus the stakeFloats, minesFromFloats, and plinkoFromFloats exports.

To clone and run the tests with Node 18 or newer:

git clone https://github.com/cryptoplayguide/provably-fair-verifier.git
cd provably-fair-verifier
npm test

No dependency installation is needed for this checkout. The test script runs node --test test/. For use as a dependency in another project, the documented installation is:

npm install github:cryptoplayguide/provably-fair-verifier

The package's import name is @cryptoplayguide/provably-fair-verifier. The README says it is not yet published to the npm registry; GitHub is the installation source.

For a local verification, save the following as verify.mjs in the cloned repository and run node verify.mjs. The input declaration is copied verbatim from test/index.test.mjs; the calls exercise the same vectors:

import { webcrypto } from 'node:crypto';
import { fairResult } from './src/index.js';

const input = { game:'dice', server:'e3f1b5c2a9d84f6e7b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f60718293a4b5c6', hash:'1c7bc4411405303e0f84ab57dea9691c6376ee6891b289a65edac408519e6009', client:'example-client-seed', nonce:'3', salt:'example-public-salt' };

const dice = await fairResult(input, webcrypto);
console.log(dice.matches, dice.result);
console.log((await fairResult({ ...input, game: 'limbo' }, webcrypto)).result);
console.log((await fairResult({ ...input, game: 'mines', mines: 3 }, webcrypto)).result);
console.log((await fairResult({ ...input, game: 'plinko', rows: 8 }, webcrypto)).result);

The expected values are true and 42.62 for Dice, 2.32 for Limbo, mine positions [10, 14, 7], and Plinko { path: [0,1,0,0,1,0,0,0], slot: 2 }. These are existing assertions, rather than newly generated fixtures. The tests also contain a separate Crash vector yielding 1.44, a 24-mine vector, and a 16-row Plinko vector.

Web Crypto is the boundary between platform services and deterministic mapping. Both asynchronous entry points accept an injectable provider, defaulting to globalThis.crypto. This signature is verbatim:

export async function stakeFloats(server, client, nonce, count, webCrypto = globalThis.crypto) {

Passing Node's webcrypto explicitly, as above, avoids depending on a global being available. Browser callers can use the default where Web Crypto is available. The implementation delegates SHA-256 and HMAC-SHA256 to subtle.digest, subtle.importKey, and subtle.sign; it does not implement cryptographic primitives itself.

The return objects also support inspection beyond a final number. Dice, Limbo, and Crash expose commitment, matches, bytes, digest, value, and result. Mines and Plinko expose commitment, matches, floats, and result. An integration can therefore inspect the intermediate representation when diagnosing a disagreement, rather than receiving only an opaque success flag. Consumers should account for these different shapes when displaying results.

There is no network request or seed generation in the module. The caller supplies the inputs; the module recomputes their consequences. This keeps browser presentation, storage, and data collection outside the cryptographic code. It also makes the local example reproducible without querying an external service.

Input validation runs before computation in fairResult. It accepts only the five supported game identifiers, requires a 64-character hexadecimal commitment, and additionally requires a hexadecimal server value for Crash. Non-Crash nonces must contain digits and convert to safe integers. Mines accepts counts from 1 through 24; Plinko accepts 8 through 16 rows.

This is validation without input repair: malformed hashes are rejected rather than padded, and invalid counts are rejected rather than clamped. There are explicit conversions, including Number(nonce) when constructing messages and lowercasing the validated hash for comparison. That distinction matters when integrating the API. The validator is not a complete application schema: it does not separately validate every client or salt field, and the exported mapping helpers assume suitable float inputs.

Dice and Limbo use Stake's published formula: HMAC with the server seed as key and clientSeed:nonce:0 as message. Four bytes become a fractional value by summing successive base-256 fractions. Dice maps that value through floor(value * 10001) / 100.

Limbo's reciprocal calculation needs an explicit boundary rule. A zero float would otherwise produce Infinity. The module throws RangeError at zero and also rejects nonnumeric, nonfinite, and out-of-range values. The tests check the dedicated zero message and assert that limboMultiplier(0.5) returns 1.98. This fix predates the new games: the changelog records it under v1.0.1.

Mines and Plinko share the multi-round byte generator. Each HMAC message includes a round counter; each 32-byte digest supplies eight floats, consuming four bytes apiece. More rounds are generated until the requested count is reached. Tests compare this output with a reference implementation using Node's createHmac, providing a separate implementation path for the byte stream.

The suite checks failure behavior alongside known outputs. It rejects malformed Crash seeds, a negative nonce, and an unsupported game. Another assertion supplies an all-zero commitment and expects matches to be false, distinguishing a well-formed mismatch from invalid input. Helper tests exercise tile selection and left/right mapping directly. These checks document the current contract, while the reference generator comparison specifically checks agreement between the two HMAC implementations; it does not independently certify every possible operator's rules.

Mines uses Fisher-Yates selection over 25 tiles. The implementation removes each selected tile from the remaining list, preventing duplicate positions. Here is the complete helper, verbatim:

export function minesFromFloats(floats, mines) {
  const tiles = Array.from({ length: 25 }, (_, i) => i), out = [];
  for (let i = 0; i < mines; i++) out.push(tiles.splice(Math.floor(floats[i] * (25 - i)), 1)[0]);
  return out;
}

fairResult requests 24 floats for Mines regardless of the mine count; the helper consumes the requested number. Tile indices run from 0 through 24, left to right and top to bottom. Keeping float generation separate from selection makes the mapping independently inspectable.

Plinko's helper is equally direct, also quoted verbatim:

export function plinkoFromFloats(floats, rows) {
  const path = floats.slice(0, rows).map(f => Math.floor(f * 2));
  return { path, slot: path.reduce((a, b) => a + b, 0) };
}

Each row consumes one float: 0 means left, 1 means right. Summing right turns gives the landing slot. There are deliberately no multipliers: payout tables depend on risk settings and the operator. A path verifier cannot infer those tables from the random stream alone.

Crash follows bustabit's published formula and has a different byte contract. The server value is decoded from hexadecimal before hashing for the commitment and before use as the HMAC message. The salt is the HMAC key. The first 13 hexadecimal digest characters provide 52 bits; the result uses Math.max(1, Math.floor(99 / (1 - value)) / 100). Treating the seed as UTF-8 text instead would change the calculation.

Finally, matches confirms only that the computed commitment equals the supplied hash. It does not compare the computed result with a separately reported outcome, establish that the commitment was displayed before play, or prove payout reliability. A caller must preserve the original commitment, select the correct documented formula, and compare the returned result independently. Other implementations can use different rules.

The browser verifier provides another interface for checking results. The repository exposes the underlying operations for local inspection: platform cryptography, explicit validation, deterministic mappings, and reproducible vectors.

18+ only. Educational use. Gambling carries financial risk; verification does not remove the house edge. Gamble responsibly.

A Country Checker Is a Terms Lookup: Understanding the Data Boundary

CryptoPlay Guide — Thu, 29 Oct 2026 05:28:58 +0000

A country selector can make a complicated policy question look deceptively simple. Choose a country, receive a result, move on. But the meaning of that result depends on the dataset behind it and the claim the interface actually makes.

CryptoPlay Guide's crypto casino country checker answers a deliberately limited question: does the selected country appear on a restricted-country list maintained for a particular operator? Understanding that boundary matters more than treating the output as a general availability verdict.

For developers and data-minded readers, the useful lessons are about sourcing, labels, dates and exceptions. The tool provides a practical example of why a lookup result needs its context attached.

Start with the exact output labels

The checker reads the restricted-country lists kept for the casinos it covers. Its result is either “On this casino's restricted list” or “Not on this casino's restricted list.”

Those labels describe membership in a list. A missing entry does not establish that gambling is legal in that country. It also does not guarantee that the operator will open an account or allow that account to remain open.

The distinction is central to reading the interface correctly. “Not on the list” describes the available restriction data. Local gambling law, the operator's current terms and identity checks still apply independently.

CryptoPlay Guide does not present the checker as a substitute for those checks. It tells readers to review the casino's own terms before signing up, even after using the tool.

Trace the data back to its stated sources

CryptoPlay Guide maintains lists for Mint, Thrill and Castle. Those lists are based on the operators' published terms and partner documents. The checker also includes lists read from official terms pages for other popular crypto casinos.

For those additional operators, the interface shows a Terms link and the date the information was last checked. Those details help a reader understand where a result came from and when the restriction information was reviewed.

The maintained Thrill list includes a few sanctioned countries as a precaution. That means the stated sourcing includes an editorial precaution, alongside the published documents. A careful explanation of the dataset should retain that qualification rather than imply every maintained entry is simply copied from a single terms page.

The same maintained lists also determine where CryptoPlay Guide switches off its own casino links. That is another use of the restriction data; it does not expand what a country result proves about legality or account approval.

Treat the check date as part of the result

CryptoPlay Guide's checker displays “Last checked 2026-10-29” and warns that terms change. That date belongs to the information reviewed at that time. It is not a promise that an operator's policy will remain unchanged afterward.

A reader needs both the result and the date. Removing the date makes it easier to mistake an earlier review for a current policy guarantee. Removing the terms reference makes it harder to verify the underlying restriction directly.

The sensible reading sequence is therefore straightforward: inspect the result, note when the data was checked, then read the operator's current terms. The checker narrows the lookup work, while the terms remain necessary before any signup decision.

This also explains why different results across operators are not automatically a contradiction. Each operator sets its own restricted-country list. One can restrict a country that another does not list.

Country-level data has regional limits

A country selector cannot express every regional exception in a single broad label. CryptoPlay Guide explicitly says coverage of regions within a country is partial.

For example, Ontario is restricted for Mint and Thrill. Castle's restrictions include Crimea, Sevastopol, Donetsk and Luhansk, while Thrill restricts all of Ukraine.

These examples illustrate why a country result needs a regional check alongside it. They are restrictions to review, not suggestions about where someone should play. CryptoPlay Guide tells readers to consult the relevant terms because the country result cannot show every regional rule.

For anyone interpreting the data, preserving that limitation is essential. A broad country label should not erase the narrower conditions described in the underlying documents.

Understand what the embed carries

The checker is free to embed on another site and displays a “Powered by CryptoPlay Guide” credit link. Its embed address is https://cryptoplay.guide/embed/country-checker/.

Embedding the widget does not change the question it answers. The result still concerns the maintained restriction lists, with the same need to check current terms, regional conditions and local law. A host page should describe it with that scope in mind.

The main tool is available at https://cryptoplay.guide/tools/crypto-casino-by-country/.

Read the result as evidence with limits

The value of this checker lies in making restriction information easier to inspect, not in resolving every condition of participation. Its sources, check dates and regional caveats explain how to use its output responsibly.

Before acting on a result, confirm the operator's current rules and the law where you live. The most useful answer from a data tool is one whose meaning stays clear after the lookup is complete.

Originally published at https://cryptoplay.guide/tools/crypto-casino-by-country/

CryptoPlay Guide, the site this was originally published on, earns affiliate commissions from some casinos it covers. This post contains no affiliate links.

18+ (or the higher legal age where you live). Gambling involves risk of loss; only play where legal, set deposit, loss and time limits, and seek help if gambling causes harm, for example from BeGambleAware.org.

Reproduce a Provably Fair Result with HMAC-SHA256

CryptoPlay Guide — Thu, 29 Oct 2026 05:28:06 +0000

A “provably fair” label becomes useful when you can turn it into a reproducible check. For a developer, the interesting part is the path from a previously published commitment to an exact game result: hash the revealed input, rebuild the HMAC message, then apply the documented byte conversion.

That path has several distinct failure points. Getting the cryptography right is necessary, but the result also depends on the nonce, message format and game formula. A matching digest with the wrong result mapping is an incomplete verification.

The walkthrough below uses example seeds created for the original CryptoPlay Guide article. They are not records of a casino bet. The Dice and Limbo mappings follow the published formulas described in that article; another operator may use different rules.

Treat the commitment as your starting input

Before betting, the operator shows a SHA-256 hash of a secret server seed. Save that hash. The client seed is visible, as is the nonce that identifies the bet within the seed pair. The operator reveals the old server seed after you rotate seeds.

You therefore need the revealed server seed, the hash saved before play, the client seed and the exact nonce. You cannot complete this check while the active server seed remains secret.

Here is the example server seed:

cryptoplayguide-example-server-seed-2026

The pre-bet commitment for this example is:

ea1e9ffa82b568d4ecb93488031e79bfe0cba227dbbe2b134c73e66079e78e91

Use this command to check it:

printf %s "cryptoplayguide-example-server-seed-2026" | sha256sum

Compare the entire output hash with the saved commitment. A mismatch means the revealed seed does not match that commitment; the later result calculation cannot repair that failed check.

Preserve the input exactly. A trailing newline or space changes the hash, which is why the example uses printf %s rather than echo.

Rebuild the HMAC message explicitly

For this Dice and Limbo example, the server seed is the HMAC-SHA256 key. The message has the format client_seed:nonce:round, with round set to 0.

Using client seed my-client-seed and nonce 1, the command is:

printf %s "my-client-seed:1:0" | openssl dgst -sha256 -hmac "cryptoplayguide-example-server-seed-2026"

It produces:

d6e37d4cd754f8752a46ef3f8c7bcd60434a1abe8a9ab09594833e9b21883b86

The placement of each input matters. Do not swap the key and message or silently change the message separators. Likewise, copy the nonce from the bet record: some operators start counting at 0, while others start at 1.

At this stage you have reproduced the digest. You still need to reproduce the game result.

Follow the byte mapping, then the payout mapping

Take the first four bytes of the digest:

d6 e3 7d 4c

Those bytes are 214, 227, 125 and 76. Convert them as follows:

214/256 + 227/256² + 125/256³ + 76/256⁴ = 0.83940871…

For Dice, apply:

floor(value × 10001) / 100

The example result is 83.94.

For Limbo with the example's 1% edge, apply:

max(1, floor(0.99 / value × 100) / 100)

The corresponding result is 1.17×. These are different mappings from the same underlying value. Copying a Dice conversion into a different game does not establish that game's result.

For another useful check, keep the seeds and change the nonce to 2. The message becomes my-client-seed:2:0; the digest begins ad06e622, the value is 0.67588652…, and the Dice result is 67.59.

Inspect the implementation without confusing game models

The open-source verifier is available at:

https://github.com/cryptoplayguide/provably-fair-verifier

Its README describes a dependency-free JavaScript module for browsers or Node.js 18+ using the Web Crypto API. It checks commitments and implements the documented Dice and Limbo mappings. Its Limbo implementation rejects a float of zero, or a value outside (0, 1), with a RangeError rather than returning Infinity.

The repository also supports a Crash model, but its inputs and byte handling differ: salt is the HMAC key, the game hash is the message, and the calculation takes the first 52 bits. That distinction is a reason to read the operator's fairness documentation before choosing a verifier mode.

A browser interface is available at https://cryptoplay.guide/tools/provably-fair-verifier/. CryptoPlay Guide states that verification runs locally in the browser and sends nothing to CryptoPlay Guide. You can first reproduce the example, then use your own revealed inputs.

Keep the conclusion narrow

A successful check establishes that the supplied result matches the committed seed under the formula you used. It does not establish solvency, withdrawal reliability, licensing or an attractive house edge.

Keep result verification and payout analysis as separate checks. Reproducing a roll explains where that roll came from; it does not make a negative expected return disappear.

Originally published at https://cryptoplay.guide/guides/verify-provably-fair-step-by-step/

CryptoPlay Guide, the site this was originally published on, earns affiliate commissions from some casinos it covers. This post contains no affiliate links.