> ## 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 Dice > Pourquoi aucun secret de l'opérateur n'est nécessaire, et la dérivation complète à partir d'entrées publiques. Un lancer de Dice n'utilise aucun secret de l'opérateur. Il est dérivé on-chain à partir d'un hash de slot Solana capturé au moment où votre mise s'exécute, de l'adresse de votre compte et de votre compteur de mises personnel, puis réglé dans la transaction même qui a placé la mise. Il n'existe aucun seed que l'opérateur pourrait choisir, et rien à révéler après coup. Cette page détaille le mécanisme exact derrière chaque lancer de [Dice](/fr/docs/games/dice). Dice est le cas le plus simple du [mécanisme Provably Fair](/fr/docs/provably-fair/overview) : il n'y a **aucun secret de l'opérateur**. Le lancer est dérivé d'entrées publiques et réglé on-chain dans la transaction même qui place la mise.

Pourquoi n'y a-t-il pas d'étape d'engagement pour Dice ?

Crash a besoin d'un secret engagé à l'avance, car son résultat doit être *fixé mais caché* pendant le déroulement de la manche. Un lancer de dé n'a pas de telle phase : le résultat est consommé dans l'instruction même qui le tire. Plutôt que de s'engager sur un secret, la dérivation n'utilise donc **absolument aucune entrée de l'opérateur** : rien à engager, rien à révéler, et aucun seed que l'opérateur pourrait choisir à son avantage. L'entropie provient du réseau Solana lui-même, mélangée à des valeurs qui identifient votre mise : * **`slothash`** : l'entrée la plus récente du sysvar `SlotHashes` de Solana au moment où votre transaction de mise s'exécute. C'est une entropie produite par le réseau, inconnue au moment où la transaction est construite (l'expéditeur ne peut pas savoir exactement dans quel slot une transaction sera incluse). * **`user`** : l'adresse de 32 octets de votre compte utilisateur on-chain (un compte que le programme dérive de votre wallet). Les lancers sont ainsi indépendants d'un joueur à l'autre : deux mises incluses dans le même slot obtiennent des lancers différents. * **`nonce`** : votre compteur de mises personnel, stocké on-chain et incrémenté à chaque partie. Vos mises successives sont ainsi indépendantes, même au sein d'un même slot, et il sert aussi de protection contre la double soumission.

Quelle est la formule exacte du lancer de Dice ?

```text theme={null} entrées slothash 32 octets hash de slot Solana le plus récent quand la transaction de mise s'exécute user 32 octets l'adresse de votre compte utilisateur on-chain nonce 8 octets votre compteur de mises, little-endian dérivation hash = sha256( "dice" ‖ slothash ‖ user ‖ nonce ) // "dice" = les 4 octets ASCII 0x64 0x69 0x63 0x65 roll = u128_be( hash[0..16] ) mod 10000 // 16 premiers octets, entier non signé 128 bits big-endian résultat roll est un entier dans 0..9999, soit 0.00–99.99 avec deux décimales ``` Les détails qui comptent quand vous le recalculez : * L'entrée du hash est la concaténation, dans cet ordre exact : l'étiquette ASCII `"dice"`, le hash de slot, l'adresse du compte utilisateur, puis le nonce encodé sur **8 octets little-endian**. * L'échantillon correspond aux **16 premiers octets** de la sortie SHA-256, lus comme un entier non signé de 128 bits **big-endian**, réduit modulo 10 000. * Réduire un échantillon de 128 bits modulo 10 000 introduit un biais théorique inférieur à 2⁻¹¹⁴, soit des dizaines d'ordres de grandeur de moins que l'avantage de la maison : c'est pourquoi il est documenté plutôt que corrigé. ## Condition de gain et gain ```text theme={null} En dessous de la cible : vous gagnez si roll < target chance de gain = target issues sur 10000 Au-dessus de la cible : vous gagnez si roll > target chance de gain = 9999 − target issues sur 10000 multiplier_bps = floor( (10000 − edge_bps) × 10000 / win_chance_bps ) ``` La chance de gain que vous choisissez doit être comprise entre 2 % et 98 %. Avec l'avantage actuel de 1,5 % (`edge_bps = 150`) : | Mise | Chance de gain | Multiplicateur | | - | - | - | | En dessous de 5000 | 50 % | 1,97x | | En dessous de 200 | 2 % | 49,25x | | En dessous de 9800 | 98 % | 1,0051x | Le retour attendu est le même pour toutes les cibles : `chance × multiplicateur ≈ 98,5 %` de la mise (l'arrondi à l'inférieur favorise la maison d'au plus un point de base). L'avantage et les limites en vigueur sont indiqués dans [Frais et limites](/fr/docs/fees-and-limits). ## Ce qui est garanti, et ce qui ne l'est pas **Imposé par le programme :** * Le lancer est dérivé **et** réglé dans une seule instruction on-chain, à partir d'entrées que le programme lit lui-même. Le backend ne fournit pas le lancer et ne peut pas le falsifier. * L'opérateur n'apporte **aucune entrée** à la dérivation : il n'existe aucun seed serveur à « forcer » pour obtenir un résultat favorable. * Votre nonce doit être renvoyé à l'identique, si bien que la même mise ne peut pas être jouée deux fois, par accident ou par malveillance. * Chaque partie publie toutes les entrées de la dérivation et le résultat, si bien que n'importe qui peut recalculer chaque lancer de l'historique. **La réserve honnête : le moment de la soumission.** Les mises Dice sont sans frais de gas pour vous : le backend de MCC signe et soumet la transaction à votre place, et l'opérateur contrôle donc *le moment* où elle est soumise. Le hash du slot `N−1` devient public au début du slot `N` : un opérateur disposant d'une latence très faible pourrait donc estimer le lancer qu'obtiendrait une mise *si* elle était incluse dans le slot courant, et retarder la soumission pour obtenir un nouveau tirage. Le mécanisme l'assume plutôt que de prétendre le contraire (l'éliminer exigerait un oracle VRF dont le coût par mise dépasse l'espérance de gain de la maison sur les petites mises). Ce qui le limite : * L'inclusion n'est pas entièrement contrôlable : c'est le réseau, et non l'expéditeur, qui décide du slot exact dans lequel une transaction est incluse. * Chaque entrée est publiée : les schémas de retard de soumission et tout écart des taux de gain agrégés par rapport aux chances annoncées sont donc **mesurables par n'importe qui** à partir des données publiques. Un abus systématique ne peut pas rester caché.

Comment vérifier un lancer de Dice ?

Chaque partie émet un événement `DiceBetSettled` dans la transaction même de la mise, qui contient tout ce dont vous avez besoin : `slothash`, `user`, `nonce`, `target_bps`, `direction`, `win_chance_bps`, `roll`, `multiplier_bps` et `is_win`, ainsi que le détail complet du règlement. Pour vérifier : 1. Ouvrez la transaction de la mise sur un explorateur Solana et lisez les champs de l'événement (l'écran Dice de l'app affiche les entrées d'équité de votre session, et votre historique de mises renvoie vers la transaction). 2. Recalculez `sha256("dice" ‖ slothash ‖ user ‖ nonce)`, prenez les 16 premiers octets en big-endian modulo 10 000, et comparez avec le `roll` de l'événement. 3. Vérifiez l'issue gagnée ou perdue (`roll < target` pour En dessous, `roll > target` pour Au-dessus) ainsi que le multiplicateur, à l'aide de la formule ci-dessus. 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 Dice](/fr/docs/games/dice).