> ## 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. # Crash-Fairness > Was festgelegt wird, wann das Ergebnis feststeht, die Formel und die Grenzen des Verfahrens. Der Multiplikator einer Crash-Runde wird entschieden, bevor die Wetten schließen, und lässt sich danach nicht mehr ändern. Das Backend veröffentlicht den SHA-256-Hash eines zufälligen Geheimnisses on-chain, bevor die Wetten öffnen, das Programm mischt beim Rundenstart einen Solana-Slot-Hash hinzu, und das Geheimnis wird bei der Abrechnung enthüllt, damit jeder den Crash-Punkt nachrechnen und prüfen kann. Diese Seite beschreibt den genauen Mechanismus hinter jeder [Crash](/de/docs/games/crash)-Runde: was festgelegt wird, wann das Ergebnis feststeht, die exakte Formel und die ehrlichen Grenzen des Verfahrens. Falls noch nicht geschehen, lies zuerst den [Provably-Fair-Überblick](/de/docs/provably-fair/overview); dort wird Commit-Reveal in einfachen Worten erklärt.

Was passiert on-chain während einer Crash-Runde?

Jede Crash-Runde besteht aus drei On-Chain-Transaktionen, in dieser Reihenfolge: 1. **Commit**: Bevor die Wetten öffnen, erzeugt das Backend ein zufälliges 32-Byte-Geheimnis und veröffentlicht dessen SHA-256-Hash on-chain (die Instruktion `start_new_round`). Das ist der Commit: Ab diesem Moment kann nur noch genau dieses Geheimnis die Runde abrechnen. Der Commit ist im `CrashRoundPrepared`-Event der Transaktion öffentlich einsehbar. 2. **Wetten**: Die Spieler platzieren ihre Wetten. Das Geheimnis bleibt verborgen; der Commit garantiert, dass es nicht ausgetauscht werden kann. 3. **Rundenstart / Erfassung der Entropie**: Wenn die Runde beginnt (die Instruktion `start_game`), liest das Programm den **aktuellsten Slot-Hash** aus Solanas `SlotHashes`-Sysvar und speichert ihn in der Runde. Die App nennt diesen Wert den *Block-Hash* der Runde. **Der Crash-Punkt steht jetzt vollständig fest** (er ist eine reine Funktion aus dem gespeicherten Slot-Hash und dem festgelegten Geheimnis), aber wer das Geheimnis nicht kennt, kann ihn noch nicht berechnen. Der Wert ist im `CrashGameStarted`-Event öffentlich einsehbar. 4. **Die Runde läuft**: Der Multiplikator steigt, und die Spieler cashen aus. 5. **Reveal**: Das Backend übermittelt das Geheimnis (die Instruktion `crash`). Das Programm **prüft on-chain**, ob `sha256(secret)` dem Commit entspricht (bei Abweichung schlägt die Transaktion fehl), berechnet dann selbst den Crash-Punkt und schließt die Runde ab. Das `CrashRoundFinalized`-Event veröffentlicht das Geheimnis, den Slot-Hash und den endgültigen Crash-Punkt.

Wie lautet die exakte Formel für den Crash-Punkt?

Der Crash-Punkt wird genau so abgeleitet (das ist die Arithmetik, die das On-Chain-Programm ausführt: Ganzzahlrechnung, keine Überraschungen durch Rundung): ```text theme={null} Eingaben blockhash 32 Bytes der beim Rundenstart gespeicherte Solana-Slot-Hash secret 32 Bytes das am Ende enthüllte Geheimnis des Betreibers (festgelegt als sha256(secret)) edge_bps Ganzzahl Hausvorteil in Basispunkten (siehe Gebühren und Limits; 150 = 1.5%) Ableitung hash = sha256( blockhash ‖ secret ) // 64-Byte-Eingabe: zuerst blockhash, dann secret X = u32_be( hash[0..4] ) // erste 4 Bytes des Hashs, Big-Endian, vorzeichenlos 32 Bit X' = min( X, 2^32 − 1000 ) // Sicherheitsgrenze: der Nenner unten ist nie kleiner als 1000 crash_bps = max( 10000, floor( (10000 − edge_bps) × 2^32 / (2^32 − X') ) ) Ergebnis Crash-Multiplikator = crash_bps / 10000 // z. B. 29948 → 2.9948x ``` Details, auf die es beim Nachrechnen ankommt: * Die Verkettungsreihenfolge ist **zuerst blockhash, dann secret**. * `X` wird **Big-Endian** aus den **ersten 4 Bytes** der SHA-256-Ausgabe gelesen. * Divisionen sind **abgerundete** Ganzzahldivisionen (floor). * Die Untergrenze `max(10000, …)` bedeutet, dass der Multiplikator nie unter 1.00x liegt, und die Begrenzung von `X` verhindert astronomisch kleine Nenner. ### Rechenbeispiel Mit `X = 0xABCD1234` (2,882,343,476) und dem aktuellen Hausvorteil von 1.5% (`edge_bps = 150`): ```text theme={null} Nenner = 2^32 − 2882343476 = 1412623820 crash_bps = floor( 9850 × 2^32 / 1412623820 ) = 29948 crash = 2.9948x ``` ### Wie die Verteilung aussieht Die Formel bildet ein gleichverteiltes `X` auf die klassische Crash-Kurve ab. Die Wahrscheinlichkeit, dass eine Runde mindestens einen Multiplikator `m` erreicht, beträgt ungefähr: ```text theme={null} P(crash ≥ m) ≈ (1 − edge) / m ``` Beim aktuellen Hausvorteil von 1.5% erreichen etwa 49.25% der Runden 2.00x, etwa 9.85% erreichen 10x, und etwa 1.5% der Runden crashen sofort bei 1.00x (genau dort steckt der Hausvorteil). Für jede Runde gilt der Hausvorteil, der zum Zeitpunkt des Reveals on-chain konfiguriert ist; der aktuelle Wert steht unter [Gebühren und Limits](/de/docs/fees-and-limits). ## Was garantiert ist, und was nicht **Vom Programm durchgesetzt:** * Sobald der Commit on-chain ist, kann der Betreiber das Geheimnis der Runde nicht mehr ändern: Die Reveal-Transaktion schlägt bei jedem Geheimnis fehl, dessen Hash nicht passt. * Sobald die Runde gestartet ist (Slot-Hash gespeichert), **steht der Crash-Punkt fest**. Ob früh, spät oder massenhaft ausgecasht wird, ändert nichts: Das Ergebnis stand fest, bevor der Multiplikator zu steigen begann. * Der Crash-Punkt wird vom Programm berechnet, nicht vom Backend gemeldet. Ein falscher Wert kann nicht on-chain geschrieben werden. * Alles, was zur Überprüfung nötig ist (Commit, Slot-Hash, Geheimnis, endgültiger Crash-Punkt), wird dauerhaft in On-Chain-Events veröffentlicht. **Die ehrlichen Einschränkungen** (das ist Commit-Reveal, keine VRF): * **Timing des Starts.** Der Betreiber kennt das Geheimnis, bevor die Runde startet, und sein Backend entscheidet, wann die Start-Transaktion übermittelt wird. Da aktuelle Slot-Hashes öffentlich sind, könnte er theoretisch für mögliche Slots den jeweiligen Multiplikator vorab berechnen und den Start so timen, dass er beeinflusst, welcher Slot-Hash erfasst wird. Das Verfahren verhindert das nicht; es macht es beobachtbar: Das Timing der Rundenstarts ist öffentlich, und jede systematische Verzerrung würde sich in der Statistik der veröffentlichten Crash-Punkte zeigen, die jeder in großem Umfang nachrechnen kann. * **Abbrüche.** Nach dem Rundenstart kennt der Betreiber das Ergebnis vor den Spielern und könnte eine ungünstige Runde abbrechen, statt das Geheimnis zu enthüllen. Dabei gelten zwei harte Grenzen: Ein Abbruch **erstattet jeden Einsatz vollständig** (das Programm hat keinen Weg, etwas einzubehalten), und jeder Abbruch erzeugt ein öffentliches Event; die Häufigkeit von Abbrüchen ist das On-Chain-Indiz. Der Abbruch existiert als Wiederherstellungsweg für ein verlorenes Geheimnis (etwa bei einem Backend-Absturz zwischen Commit und Reveal) und soll praktisch nie zum Einsatz kommen.

Wie überprüfst du eine Crash-Runde?

Die Details jeder beendeten Runde zeigen in der App das enthüllte Geheimnis und den Block-Hash, verlinken alle drei Transaktionen und bieten ein Fairness-Tool, das den Multiplikator für dich nachrechnet. Die vollständige Schritt-für-Schritt-Anleitung, inklusive eines kleinen Skripts, mit dem du den Crash-Punkt selbst nachrechnest, findest du unter [Eine Runde überprüfen](/de/docs/provably-fair/verify-a-round). Wie das Spiel selbst gespielt wird (Cashout, Setzfenster, Limits), steht in der [Crash-Spielanleitung](/de/docs/games/crash).