Open-source provably fair iGaming platform – looking for industry feedback

[vfairgames]

Introducing vFair, an open-source provably fair iGaming platform built for developers, operators, and anyone interested in transparent casino game mechanics.

The platform currently includes Dice, Mines, Limbo, Plinko, and Keno, with:

• Provably fair verification
• Configurable RTP
• Multi-currency support
• Partner wallet integration
• Admin and reporting tools
• API + iframe integration

The complete source code is publicly available:


Feedback, suggestions, and contributions from the iGaming community are welcome.

 

[vfairgames]

Appreciate this — wallet/settlement is exactly the layer we spent the most time on.

We call the operator wallet (debit/credit) with a deterministic requestId so retries don’t double-apply, and we write a pending local transaction before the partner call so a timeout is still reconcilable. Instant games settle in the same request; Mines keeps the round ACTIVE on disconnect and restores it on reconnect (no auto-cash-out). If debit/settle/credit fails after the round exists, we mark it FAILED with a stage and reconcile against the operator by requestId rather than auto-reversing. Manual adjustment required.

Happy to walk through the Mines reconnect path if that’s the interesting bit.

You can explore source code in github project vfairgames/vfair-games.

 

[iGamingB2B]

sup, we’re ready to feature you for free on our platform: https://igamingb2b.net/casino-platform/

gotta support our own from AGD

 

[vfairgames]

@iGamingB2B was not able to list.
If there is contact who can help me, share please.

 

[jonahill]

I’d be interested in how the provably fair system is implemented. Can players independently verify every result, and has the code or RNG logic been audited by anyone outside the project?

 

[vfairgames]

It follows a standard provably fair model. Before a game round, the platform exposes the SHA-256 hash of the server seed, while the player provides a client seed. A nonce is incremented for each bet.
The outcome is derived using HMAC-SHA256(serverSeed, "clientSeed:nonce:cursor"), providing a deterministic and independently reproducible result.
The entire verification process runs locally in the player's browser, without relying on server-side verification, making the process fully transparent and independently verifiable. An example shows at in the github project.

The RNG implementation has not yet undergone an independent third-party audit. There is test coverage that verifies probabilit, but would be happy if anyone will do audit.

 

[jonahill]

Thanks for clarifying. When is the server seed revealed so players can reproduce each result? Publishing the protocol and test vectors would also make community auditing easier. An independent audit would be a valuable next step.

It follows a standard provably fair model. Before a game round, the platform exposes the SHA-256 hash of the server seed, while the player provides a client seed. A nonce is incremented for each bet.
The outcome is derived using HMAC-SHA256(serverSeed, "clientSeed:nonce:cursor"), providing a deterministic and independently reproducible result.
The entire verification process runs locally in the player's browser, without relying on server-side verification, making the process fully transparent and independently verifiable. An example shows at in the github project.

The RNG implementation has not yet undergone an independent third-party audit. There is test coverage that verifies probabilit, but would be happy if anyone will do audit.

 

[vfairgames]

@jonahill so this is also classic scenario. Server seed is revealed whenever user requesting new seed pair.
Again everything is transparently visible in github sourcecode. If anyone interested to audit project or to see demo contact me info@vfair.games . Thank you.

 

[jonahill]

I d

@jonahill so this is also classic scenario. Server seed is revealed whenever user requesting new seed pair.
Again everything is transparently visible in github sourcecode. If anyone interested to audit project or to see demo contact me info@vfair.games . Thank you.

I don't know if its cos I'm tired but I don't quite understand what you just said. CCould you be a bit clearer!

 

[david7777]

How much do you expect?
Please give me your demo link.

 

[vfairgames]

You can find everything here vfair.games

 

[TheJema]

Interesting project. A few thoughts from the affiliate side:

1. On jonahill's seed question, as I understand the usual model: the hash of the server seed is shown before you play, and every bet uses that seed with your client seed and an increasing nonce. When you rotate to a new seed pair, the old server seed is revealed, and you can then re-check every bet made with it. It might help to say this in exactly these words on the site, with a step-by-step example and published test vectors (seeds, nonce, expected result) so anyone can reproduce it without reading the code.

2. Please name the license (MIT, GPL, AGPL…). "Source is public" and "open source" mean very different things to an operator who wants to build on it.

3. For affiliates to promote any brand running on it, operators will need tracking: passing a click ID or btag through registration and sending deposit/FTD postbacks. If the platform made that easy, it would be a real selling point for B2B.

4. Provably fair builds trust with crypto players, but it doesn't replace a lab certificate in regulated markets, and with configurable RTP operators will need certified RTP settings. Worth stating clearly who the platform is for.

A public play-money demo would get you much more feedback here than a repo link.

 

[jonahill]

Interesting project. A few thoughts from the affiliate side:

1. On jonahill's seed question, as I understand the usual model: the hash of the server seed is shown before you play, and every bet uses that seed with your client seed and an increasing nonce. When you rotate to a new seed pair, the old server seed is revealed, and you can then re-check every bet made with it. It might help to say this in exactly these words on the site, with a step-by-step example and published test vectors (seeds, nonce, expected result) so anyone can reproduce it without reading the code.

2. Please name the license (MIT, GPL, AGPL…). "Source is public" and "open source" mean very different things to an operator who wants to build on it.

3. For affiliates to promote any brand running on it, operators will need tracking: passing a click ID or btag through registration and sending deposit/FTD postbacks. If the platform made that easy, it would be a real selling point for B2B.

4. Provably fair builds trust with crypto players, but it doesn't replace a lab certificate in regulated markets, and with configurable RTP operators will need certified RTP settings. Worth stating clearly who the platform is for.

A public play-money demo would get you much more feedback here than a repo link.

I think I get it now. Not fully but the bulk of it