> ## 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 Crash > Ce qui est engagé, quand le résultat est fixé, la formule et les limites du schéma. Le multiplicateur d’une manche de Crash est décidé avant la clôture des mises et ne peut plus être modifié ensuite. Le backend publie on-chain le hash SHA-256 d’un secret aléatoire avant l’ouverture des mises, le programme y intègre un slot hash Solana au démarrage de la manche, et le secret est révélé au règlement pour que chacun puisse recalculer le point de crash et le vérifier. Cette page détaille le mécanisme exact de chaque manche de [Crash](/fr/docs/games/crash) : ce qui est engagé, quand le résultat devient fixe, la formule précise et les limites honnêtes du schéma. Si ce n’est pas déjà fait, lisez d’abord la [Vue d’ensemble du Provably Fair](/fr/docs/provably-fair/overview) ; elle explique simplement le commit-reveal.

Que se passe-t-il on-chain pendant une manche de Crash ?

Chaque manche de Crash repose sur trois transactions on-chain, dans cet ordre : 1. **Engagement (commit)** : avant l’ouverture des mises, le backend génère un secret aléatoire de 32 octets et publie on-chain son hash SHA-256 (l’instruction `start_new_round`). C’est l’engagement : à partir de ce moment, seul ce secret précis pourra régler la manche. L’engagement est public dans l’événement `CrashRoundPrepared` de la transaction. 2. **Mises** : les joueurs placent leurs mises. Le secret reste caché ; l’engagement garantit qu’il ne peut pas être échangé. 3. **Démarrage de la manche / capture de l’entropie** : quand la manche commence (l’instruction `start_game`), le programme lit le **slot hash le plus récent** dans le sysvar `SlotHashes` de Solana et le stocke dans la manche. L’app appelle cette valeur le *block hash* de la manche. **Le point de crash est désormais entièrement déterminé** (c’est une fonction pure du slot hash stocké et du secret engagé), mais personne ne peut encore le calculer sans connaître le secret. La valeur est publique dans l’événement `CrashGameStarted`. 4. **La manche se déroule** : le multiplicateur grimpe et les joueurs encaissent. 5. **Révélation** : le backend soumet le secret (l’instruction `crash`). Le programme **vérifie on-chain** que `sha256(secret)` est égal à l’engagement (en cas de différence, la transaction échoue), puis calcule lui-même le point de crash et clôture la manche. L’événement `CrashRoundFinalized` publie le secret, le slot hash et le point de crash final.

Quelle est la formule exacte du point de crash ?

Le point de crash est dérivé exactement ainsi (c’est l’arithmétique qu’exécute le programme on-chain : calcul entier, aucune surprise d’arrondi) : ```text theme={null} entrées blockhash 32 octets le slot hash Solana stocké au démarrage de la manche secret 32 octets le secret de l'opérateur révélé à la fin (engagé sous la forme sha256(secret)) edge_bps entier avantage de la maison en points de base (voir Frais et limites ; 150 = 1,5 %) dérivation hash = sha256( blockhash ‖ secret ) // entrée de 64 octets : d'abord blockhash, puis le secret X = u32_be( hash[0..4] ) // 4 premiers octets du hash, entier non signé 32 bits big-endian X' = min( X, 2^32 − 1000 ) // plafond de sécurité : le dénominateur ci-dessous n'est jamais inférieur à 1000 crash_bps = max( 10000, floor( (10000 − edge_bps) × 2^32 / (2^32 − X') ) ) résultat multiplicateur de crash = crash_bps / 10000 // ex. 29948 → 2.9948x ``` Détails qui comptent quand vous le recalculez : * L’ordre de concaténation est **d’abord blockhash, puis secret**. * `X` est lu en **big-endian** sur les **4 premiers octets** de la sortie SHA-256. * Les divisions sont des divisions **entières** (arrondies à l’inférieur, floor). * Le plancher `max(10000, …)` garantit que le multiplicateur n’est jamais inférieur à 1,00x, et le plafond appliqué à `X` empêche des dénominateurs infinitésimaux. ### Exemple détaillé Avec `X = 0xABCD1234` (2 882 343 476) et l’avantage actuel de 1,5 % (`edge_bps = 150`) : ```text theme={null} dénominateur = 2^32 − 2882343476 = 1412623820 crash_bps = floor( 9850 × 2^32 / 1412623820 ) = 29948 crash = 2.9948x ``` ### À quoi ressemble la distribution La formule transforme un `X` uniforme en la courbe de crash classique. La probabilité qu’une manche atteigne au moins un multiplicateur `m` est d’environ : ```text theme={null} P(crash ≥ m) ≈ (1 − avantage) / m ``` Avec l’avantage actuel de 1,5 % : environ 49,25 % des manches atteignent 2,00x, environ 9,85 % atteignent 10x, et environ 1,5 % des manches crashent instantanément à 1,00x (c’est là que se loge l’avantage de la maison). L’avantage appliqué à chaque manche est la valeur configurée on-chain au moment de la révélation ; la valeur actuelle figure dans [Frais et limites](/fr/docs/fees-and-limits). ## Ce qui est garanti, et ce qui ne l’est pas **Garanti par le programme :** * Une fois l’engagement on-chain, l’opérateur ne peut plus changer le secret de la manche : la transaction de révélation échoue pour tout secret dont le hash ne correspond pas. * Une fois la manche démarrée (slot hash stocké), **le point de crash est fixé**. Encaisser tôt, tard ou en grand nombre n’y change rien : le résultat était déterminé avant que le multiplicateur ne commence à grimper. * Le point de crash est calculé par le programme, pas déclaré par le backend. Une valeur erronée ne peut pas être écrite on-chain. * Tout ce qui est nécessaire à la vérification (engagement, slot hash, secret, point de crash final) est publié dans des événements on-chain, de façon permanente. **Les réserves honnêtes** (il s’agit d’un commit-reveal, pas d’une VRF) : * **Timing du démarrage.** L’opérateur connaît le secret avant le démarrage de la manche, et son backend décide quand soumettre la transaction de démarrage. Comme les slot hashes récents sont publics, il pourrait en principe précalculer le multiplicateur potentiel pour plusieurs slots candidats et choisir le moment du démarrage pour influer sur le slot hash capturé. Le schéma ne l’empêche pas ; il le rend observable : le timing des démarrages est public, et tout biais systématique apparaîtrait dans les statistiques des points de crash publiés, que chacun peut recalculer en masse. * **Annulations.** Après le démarrage de la manche, l’opérateur connaît le résultat avant les joueurs, et il pourrait annuler une manche défavorable au lieu de la révéler. Deux limites strictes s’appliquent : une annulation **rembourse intégralement chaque mise** (le programme n’a aucune voie de confiscation), et chaque annulation émet un événement public ; la fréquence des annulations est l’indice visible on-chain. L’annulation existe comme voie de secours en cas de perte du secret (par exemple un plantage du backend entre l’engagement et la révélation) et n’est censée servir pratiquement jamais.

Comment vérifier une manche de Crash ?

Dans l’app, les détails de chaque manche terminée affichent le secret révélé et le block hash, avec des liens vers les trois transactions et un outil d’équité qui recalcule le multiplicateur pour vous. Pour la marche à suivre complète, y compris un petit script pour recalculer vous-même le point de crash, voir [Vérifier une manche](/fr/docs/provably-fair/verify-a-round). Pour le fonctionnement du jeu lui-même (encaissement, fenêtres de mise, limites), voir le [guide du jeu Crash](/fr/docs/games/crash).