> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mycryptocasino.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Vue d’ensemble du Provably Fair
> Le commit-reveal expliqué simplement, ce qu’apporte l’entropie de la blockchain et ce que vous pouvez vérifier vous-même.
Chaque résultat de jeu sur My Crypto Casino est produit par un **schéma commit-reveal combiné à l’entropie de la blockchain Solana**, exécuté par le programme on-chain. Pour vous, en tant que joueur, cela signifie deux choses :
1. **Le résultat ne peut pas être modifié après coup.** L’opérateur fixe sa contribution (une valeur secrète) *avant* le jeu, en publiant on-chain une empreinte cryptographique de celle-ci. Plus tard, le programme refuse tout règlement si le secret révélé ne correspond pas exactement à cette empreinte.
2. **Vous pouvez tout vérifier vous-même.** Toutes les entrées et la formule exacte sont publiques. Après n’importe quelle manche ou mise, vous pouvez recalculer le résultat à partir des données on-chain et le comparer avec ce que le jeu a payé.
Cette page explique le schéma simplement. Les pages dédiées à chaque jeu donnent les formules exactes, et [Vérifier une manche](/fr/docs/provably-fair/verify-a-round) vous guide pas à pas dans la vérification d’une manche réelle.
De quoi le Provably Fair est-il constitué ?
**Un secret engagé à l’avance.** Lorsqu’un résultat doit rester caché pendant le jeu (Crash, Mines), le backend génère un secret aléatoire de 32 octets et publie on-chain son hash SHA-256 (l’*engagement*, ou commit) avant le début du jeu. Un hash fonctionne comme une enveloppe scellée : il ne révèle rien du secret, mais une fois publié, seul ce secret précis peut lui correspondre. Quand le secret est révélé à la fin, le programme le hache lui-même et rejette la transaction s’il ne correspond pas à l’engagement.
**L’entropie de la blockchain Solana.** Le résultat ne dépend jamais du seul secret. Il y intègre aussi un **slot hash** : le hash d’un slot Solana récent, lu par le programme dans le sysvar `SlotHashes` de Solana à un moment défini. Cette valeur est produite par le réseau Solana, pas par le casino, et n’existe pas encore au moment où l’engagement est publié.
**Une formule publique et déterministe.** Le résultat est une fonction mathématique fixe de ces entrées. Cette même fonction s’exécute dans le programme on-chain (le backend ne peut pas déclarer un faux résultat : c’est le programme qui le calcule), et elle est publiée sur ces pages pour que vous puissiez l’exécuter vous-même.
Comment se déroule une manche, étape par étape ?
```mermaid theme={null}
sequenceDiagram
participant MCC as Backend MCC (opérateur)
participant SOL as Programme Solana
participant You as Joueur
Note over MCC,SOL: 1. Engagement
MCC->>SOL: Publie l’engagement = sha256(secret)
Note over You,SOL: 2. Jeu
You->>SOL: Les mises sont placées on-chain
Note over SOL: 3. Entropie de la blockchain
SOL->>SOL: Capture le dernier slot hash Solana
Note over MCC,SOL: 4. Révélation
MCC->>SOL: Soumet le secret
SOL->>SOL: Vérifie que sha256(secret) correspond à l’engagement
SOL->>SOL: Calcule le résultat avec la formule publique
Note over You: 5. Vérification (à tout moment, plus tard)
You->>SOL: Lit l’engagement, le slot hash et le secret on-chain
You->>You: Recalcule le résultat et compare
```
Dice condense ce déroulé en une seule transaction : il n’a aucun état caché à protéger, donc aucun secret d’opérateur. Le lancer est dérivé du slot hash, de votre compte et de votre compteur de mises, puis réglé dans la même instruction qui le tire.
## Ce que chaque jeu engage, et à quel moment
| Jeu | Secret de l’opérateur | Entropie de la blockchain | Résultat fixé à | Garanti on-chain |
| - | - | - | - | - |
| [Crash](/fr/docs/provably-fair/crash) | Secret de 32 octets, engagé **avant l’ouverture des mises** | Slot hash capturé au démarrage de la manche | Démarrage de la manche | Contrôle de l’engagement + point de crash calculé par le programme à la révélation |
| [Dice](/fr/docs/provably-fair/dice) | Aucun | Slot hash au moment où votre transaction de mise est incluse | Inclusion de la transaction de mise | Lancer dérivé et réglé par le programme en une seule instruction |
| [Mines](/fr/docs/provably-fair/mines) | Seed de 32 octets, engagé **dans la transaction qui démarre votre partie** | Slot hash capturé dans cette même transaction de démarrage | Démarrage de la partie, avant votre premier choix | Contrôle du seed + plateau entier re-dérivé par le programme au règlement |
## Ce que cela garantit, et ce que cela suppose
Ici, l’honnêteté compte plus que le marketing, alors soyons précis. Ce schéma est un **commit-reveal avec entropie publique de la blockchain, pas une VRF** (fonction aléatoire vérifiable). Voici la frontière exacte entre ce qui est *garanti par le code* et ce qui *repose sur le bon comportement de l’opérateur*.
### Garanti par le programme on-chain
* **Aucun échange de résultat après l’engagement.** Le programme hache le secret révélé et rejette tout règlement où il ne correspond pas à l’engagement publié. L’opérateur ne peut pas choisir un autre secret après avoir vu comment se déroule une manche.
* **Une entropie que l’opérateur ne produit pas.** Le slot hash provient du réseau Solana. Il est inconnu au moment où l’engagement est publié, et le casino ne le crée pas.
* **Des résultats calculés on-chain.** Le point de crash, le lancer de dés et le plateau de Mines sont calculés (ou re-dérivés et contrôlés) par le programme lui-même. Le backend ne peut pas déclarer un résultat que la formule ne produit pas.
* **Une auditabilité publique totale.** Chaque manche et chaque mise émettent des événements on-chain contenant toutes les entrées de la dérivation et le résultat. N’importe qui, pas seulement le joueur concerné, peut recalculer chaque résultat passé.
### Ce qui est supposé : les réserves honnêtes
* **Influence sur le timing.** Le backend de l’opérateur choisit *quand* soumettre certaines transactions, ce qui lui donne une influence partielle sur *quel* slot hash est capturé. Chaque page dédiée à un jeu détaille précisément ce que cela pourrait permettre ou non pour ce jeu.
* **Les annulations sont possibles, mais uniquement avec remboursement.** L’opérateur peut annuler une manche de Crash ou une partie de Mines. Une annulation rembourse toujours intégralement chaque mise (le programme n’a aucun moyen de confisquer quoi que ce soit via une annulation), et chaque annulation est journalisée publiquement : la fréquence des annulations est donc auditable par tous. Des annulations fréquentes seraient la signature visible, on-chain, d’un opérateur malhonnête.
* **L’opérateur connaît le plateau de Mines pendant la partie.** C’est structurel : les cases sont retournées instantanément off-chain, et celui qui les sert doit connaître le plateau. L’engagement garantit que le plateau a été fixé avant votre premier choix et ne peut pas être réécrit ensuite. Voir [Équité de Mines](/fr/docs/provably-fair/mines) pour savoir exactement comment c’est garanti.
### Pourquoi accepter ces compromis ?
Parce qu’ils sont le prix d’un jeu instantané et fluide, pas des raccourcis. Chaque jeu se situe exactement là où il le doit sur ce spectre :
* **Mines** : retourner une case en quelques millisecondes exige structurellement une partie qui connaît déjà le plateau. Les alternatives (une transaction on-chain par clic, ou un aller-retour vers un oracle à chaque case) transformeraient chaque case en frais et en attente. Un opérateur qui connaît le plateau est indispensable pour un Mines qui paraît instantané tout en se réglant on-chain ; le schéma d’engagement existe pour encadrer ce que cette connaissance permet de faire.
* **Crash** : une manche partagée en direct a besoin de quelqu’un pour la piloter pour tous les joueurs à la fois. C’est un choix pragmatique plutôt qu’une nécessité structurelle, c’est pourquoi le programme intègre une voie de migration vers un aléa fourni par un oracle (VRF), une phase future qui supprimerait les réserves liées au timing là où l’économie le permet.
* **Dice** : l’autre extrémité du spectre. Il n’y a rien à cacher pendant le jeu, donc aucun secret d’opérateur. Là où supprimer la confiance envers l’opérateur ne coûte rien, la conception la supprime.
En bref : l’opérateur fait tourner les jeux, et la blockchain rend la triche soit **impossible** (tout ce qui suit l’engagement), soit **publiquement détectable** (schémas de timing, fréquence des annulations, statistiques de taux de gain).
**Équité du résultat vs garde des fonds**
Cette section porte sur la façon dont les *résultats* sont générés. La manière dont les dépôts, les soldes et les retraits sont conservés on-chain est un sujet distinct ; voir [Architecture on-chain](/fr/docs/security/on-chain-architecture).
## Vérifiez par vous-même
* Dans l’app, chaque manche de Crash terminée expose ses données d’équité (le secret révélé, le block hash et des liens vers les transactions on-chain) dans les détails de la manche, avec un outil de vérification en un clic.
* Dice et Mines publient chaque entrée de la dérivation dans l’événement de règlement de la transaction même de la mise.
[Vérifier une manche](/fr/docs/provably-fair/verify-a-round) décrit l’ensemble du processus, des données affichées dans l’app jusqu’au recalcul du résultat en quelques lignes de code.