> ## 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. # Équité de Mines > Quand la grille est engagée, comment elle est dérivée et ce que le programme revérifie au règlement. Une grille de Mines est fixée avant même que vous choisissiez la moindre case. La transaction d’ouverture enregistre le hash SHA-256 d’un seed serveur aléatoire et capture un hash de slot Solana, et la grille est une fonction pure de ces deux éléments. Au règlement, le programme redérive toute la grille on-chain et rejette tout règlement qui ne lui correspond pas. Cette page détaille le mécanisme exact derrière chaque grille de [Mines](/fr/docs/games/mines) : ce qui est engagé et quand, la dérivation précise de la grille, ce que le programme revérifie au règlement, et les limites réelles du dispositif. Pour le contexte : [Vue d’ensemble du Provably Fair](/fr/docs/provably-fair/overview). ## Ce qui est engagé, et quand Une partie de Mines commence par une seule transaction on-chain (`mines_start`) qui fait trois choses à la fois, **avant que vous choisissiez la moindre case** : 1. **Elle engage la contribution de l’opérateur.** Le backend génère un `server_seed` aléatoire de 32 octets et la transaction enregistre son hash SHA-256 : l’engagement cryptographique (commit). Le seed lui-même reste secret jusqu’à la fin de la partie. 2. **Elle capture l’entropie de la chaîne.** Le programme lit le hash de slot le plus récent dans le sysvar `SlotHashes` de Solana et le stocke dans la partie. 3. **Elle fige les conditions.** L’avantage de la maison, le plafond de gain et le délai de remboursement sont figés dans votre partie : rien ne peut modifier les conditions d’une grille sur laquelle vous jouez déjà. La grille est une fonction pure du seed engagé, du hash de slot stocké, de votre compte et de votre compteur de parties. **À partir de ce moment, la grille est fixée** : les mines ne peuvent pas bouger en fonction de vos choix. Pendant la partie, les cases retournées sont servies off-chain (c’est ce qui les rend instantanées) ; à la fin, la transaction de règlement révèle le seed et le programme **redérive toute la grille on-chain**, en rejetant tout règlement qui ne lui correspond pas.

Comment la grille de Mines est-elle dérivée ?

Les 25 cases sont indexées de 0 à 24, ligne par ligne sur la grille 5×5 (`index = row × 5 + column`). La grille est un masque de 25 bits : si le bit `t` est à 1, la case `t` cache une mine. ```text theme={null} entrées server_seed 32 octets seed de l'opérateur, engagé sous la forme sha256(server_seed) au début de la partie slothash 32 octets dernier hash de slot Solana au moment où la transaction de début s'exécute user 32 octets l'adresse de votre compte utilisateur on-chain nonce 8 octets votre compteur de parties de Mines, little-endian mines_count 1..24 le nombre de mines que vous avez choisi flux aléatoire : blocs SHA-256 consommés 4 octets à la fois block(k) = sha256( server_seed ‖ slothash ‖ user ‖ nonce ‖ "mines" ‖ k ) // "mines" = 5 octets ASCII ; k = compteur de blocs 0, 1, 2, … sur 8 octets little-endian next_u32() = les 4 octets suivants non lus du bloc courant, en big-endian ; quand un bloc est épuisé, on passe à block(k+1) tirage sans biais dans 0..bound (échantillonnage par rejet, pas de biais de modulo) draw(bound): zone = 4294967295 − (4294967295 mod bound) répéter v = next_u32() jusqu'à ce que v < zone renvoyer v mod bound grille : mélange de Fisher–Yates partiel tiles = [0, 1, …, 24] mine_mask = 0 for i in 0..mines_count: j = i + draw(25 − i) échanger tiles[i] et tiles[j] mine_mask = mine_mask OR (1 << tiles[i]) ``` Les détails qui comptent quand vous la recalculez : * L’ordre des entrées du hash est exactement : seed, hash de slot, adresse du compte utilisateur, nonce (**8 octets little-endian**), l’étiquette ASCII `"mines"`, puis le compteur de blocs (**8 octets little-endian**, en partant de 0). * Chaque segment de 4 octets est lu en **big-endian**. Un bloc fournit au plus 8 tirages ; le flux se recharge avec la valeur suivante du compteur si nécessaire. * La boucle d’échantillonnage par rejet rend chaque tirage parfaitement uniforme : le mélange n’a aucun biais à discuter.

Quelle formule de gain le programme applique-t-il ?

Chaque case sûre retournée multiplie votre montant encaissable par l’inverse exact de vos chances de survie, l’avantage de la maison étant appliqué une seule fois : ```text theme={null} multiplicateur = (1 − avantage) × ∏(i = 0 … k−1) ( (25 − i) / (25 − M − i) ) M = nombre de mines, k = nombre de cases sûres retournées ``` Le programme effectue ce calcul en arithmétique entière exacte, avec une seule division entière finale (l’arrondi, d’au plus un point de base, est en faveur de la maison). Avec l’avantage actuel de 1,5 % : | Grille | Multiplicateur | | - | - | | 3 mines, 1 case retournée | 1,1193x | | 3 mines, 2 cases retournées | 1,2792x | | 24 mines, 1 case retournée | 24,625x | | 1 mine, sans-faute (24 cases retournées) | 24,625x | Le retour attendu est de `1 − avantage` pour toute combinaison de mines et de cases retournées. Les valeurs actuelles sont listées dans [Frais et limites](/fr/docs/fees-and-limits). ## Ce que le programme vérifie au règlement La transaction de règlement (`mines_settle`) révèle le `server_seed` et déclare un résultat : un encaissement avec un ensemble de cases retournées, ou une explosion sur une case précise. Le programme vérifie alors tout on-chain : * `sha256(server_seed)` doit être égal à l’engagement stocké au début de la partie ; un autre seed ne peut pas régler la partie. * La grille est **redérivée de zéro** avec la formule ci-dessus. Toute case déclarée retournée qui est en réalité une mine est rejetée ; une case d’explosion déclarée qui n’est pas une mine est rejetée ; une case d’explosion également déclarée comme retournée est rejetée. * Le multiplicateur est calculé on-chain à partir de l’avantage **figé** et du nombre réel de cases retournées, si bien que le gain ne peut pas être faussé. * L’événement de règlement publie de façon permanente le seed, le hash de slot, le masque complet des mines, vos cases retournées et le résultat. ## Ce qui est garanti, et ce qui ne l’est pas **Garanti par le programme :** * La grille est fixée avant votre premier choix, par l’engagement et le hash de slot stocké. Les mines ne peuvent pas bouger en cours de partie. * Au règlement, l’opérateur ne peut pas mentir sur la grille : un mauvais seed, une mine déclarée sûre ou une fausse explosion font échouer la transaction. * Les conditions de départ (avantage, plafond de gain, délai) s’appliquent jusqu’à la fin de la partie. * Votre mise ne peut jamais être bloquée : si l’opérateur ne règle jamais la partie, l’annulation peut être déclenchée par **n’importe qui** une fois le délai de la partie écoulé, ce qui vous rembourse votre mise. En fonctionnement normal, vous n’en arrivez jamais là : une grille abandonnée est encaissée à son multiplicateur actuel avant l’expiration du délai (voir [Mines](/fr/docs/games/mines)), vous conservez donc vos gains et pas seulement votre mise. L’annulation ouverte à tous est la garantie de fond, pour le cas où l’opérateur aurait disparu. **Les réserves honnêtes :** * **L’opérateur connaît la grille pendant que vous jouez.** C’est structurel, pas un défaut propre à cette conception : les cases retournées sont servies instantanément off-chain, et celui qui les sert doit savoir où se trouvent les mines. Aucun dispositif d’aléa ne supprime cela : même une grille générée par VRF serait connue de l’opérateur dès qu’il sert votre première case. Ce que l’engagement garantit, c’est que cette connaissance ne peut servir ni à *modifier* la grille ni à *fausser* le résultat. * **Moment du démarrage.** La grille dépend du hash de slot capturé au démarrage de votre partie, et la transaction de démarrage est soumise par le backend : c’est la même question de timing que pour les autres jeux. Connaître une grille à l’avance n’est utile que si vos choix sont prévisibles ; varier les cases sur lesquelles vous cliquez neutralise toute sélection de grille fondée sur le timing. * **Annulations.** L’opérateur peut annuler une partie en cours (y compris, en principe, une partie que vous êtes en train de gagner). Une annulation **rembourse l’intégralité de la mise** (il n’existe aucun mécanisme de confiscation) et émet toujours un événement public : la fréquence des annulations est donc vérifiable on-chain par n’importe qui. * Chaque partie doit utiliser un nouveau seed : un seed révélé est public, et le réutiliser rendrait la grille suivante calculable par tous. Le programme rejette on-chain toute réutilisation consécutive, et le backend garantit l’unicité globale.

Comment vérifier une partie de Mines ?

L’événement de règlement (`MinesGameSettled`) de la dernière transaction de votre partie contient `server_seed`, `slothash`, `user`, `nonce`, `mines_count`, `mines_mask`, `revealed_mask`, `bust_tile`, `multiplier_bps` et `is_win`. Pour vérifier : 1. Contrôlez l’engagement : `sha256(server_seed)` doit être égal au `commit_hash` publié dans la transaction de début de votre partie (événement `MinesGameStarted`), ce qui prouve que la grille était verrouillée avant votre premier choix. 2. Redérivez le masque des mines avec la formule ci-dessus et comparez-le au `mines_mask` de l’événement. 3. Contrôlez le résultat par rapport au masque : chaque bit de `revealed_mask` doit correspondre à une case sûre, et une case d’explosion doit être une mine. 4. Contrôlez le multiplicateur avec la formule de gain. Consultez [Vérifier une manche](/fr/docs/provably-fair/verify-a-round) pour des conseils généraux sur la lecture des données d’événement depuis un explorateur. Pour savoir comment se joue le jeu lui-même, consultez le [guide du jeu Mines](/fr/docs/games/mines).