Skip to main content
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. Dice est le cas le plus simple du mécanisme Provably Fair : 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 ?

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

La chance de gain que vous choisissez doit être comprise entre 2 % et 98 %. Avec l’avantage actuel de 1,5 % (edge_bps = 150) : 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.

​
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 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.