> ## 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. # Dice-Fairness > Warum kein Geheimnis des Betreibers nötig ist – und die vollständige Herleitung aus öffentlichen Eingaben. Ein Dice-Wurf verwendet überhaupt kein Geheimnis des Betreibers. Er wird on-chain aus einem Solana-Slot-Hash hergeleitet, der erfasst wird, wenn deine Wette ausgeführt wird, aus deiner Kontoadresse und aus deinem persönlichen Wettzähler – und dann in derselben Transaktion abgerechnet, die die Wette platziert hat. Es gibt keinen Seed, den der Betreiber wählen könnte, und nichts, was hinterher aufgedeckt werden müsste. Diese Seite beschreibt den genauen Mechanismus hinter jedem [Dice](/de/docs/games/dice)-Wurf. Dice ist der einfachste Fall des [Provably-Fair-Verfahrens](/de/docs/provably-fair/overview): Es gibt **überhaupt kein Geheimnis des Betreibers**. Der Wurf wird aus öffentlichen Eingaben hergeleitet und on-chain in derselben Transaktion abgerechnet, die die Wette platziert.

Warum gibt es bei Dice keinen Commit-Schritt?

Crash braucht ein festgelegtes Geheimnis, weil sein Ergebnis *feststehen, aber verborgen bleiben* muss, während die Runde läuft. Ein Würfelwurf hat keine solche Phase: Das Ergebnis wird in derselben Instruktion verwendet, in der es gezogen wird. Statt sich auf ein Geheimnis festzulegen, verwendet die Herleitung deshalb einfach **keinerlei Eingabe des Betreibers**: Es gibt nichts zu committen, nichts aufzudecken und keinen Seed, den der Betreiber zu seinen Gunsten wählen könnte. Die Entropie stammt aus dem Solana-Netzwerk selbst und wird mit Werten gemischt, die deine Wette identifizieren: * **`slothash`**: der neueste Eintrag der Solana-Sysvar `SlotHashes` in dem Moment, in dem deine Wett-Transaktion ausgeführt wird. Das ist vom Netzwerk erzeugte Entropie, die beim Erstellen der Transaktion noch nicht bekannt ist (der Absender kann nicht genau wissen, in welchem Slot eine Transaktion landet). * **`user`**: die 32-Byte-Adresse deines On-Chain-Nutzerkontos (ein Konto, das das Programm aus deiner Wallet herleitet). Dadurch sind Würfe verschiedener Spieler voneinander unabhängig: Zwei Wetten, die im selben Slot landen, bekommen unterschiedliche Würfe. * **`nonce`**: dein persönlicher Wettzähler, on-chain gespeichert und bei jedem Spiel erhöht. Dadurch sind auch deine eigenen aufeinanderfolgenden Wetten unabhängig voneinander, selbst im selben Slot, und er schützt zugleich vor doppeltem Absenden.

Wie lautet die genaue Formel für den Dice-Wurf?

```text theme={null} Eingaben slothash 32 Bytes neuester Solana-Slot-Hash, wenn die Wett-Transaktion ausgeführt wird user 32 Bytes die Adresse deines On-Chain-Nutzerkontos nonce 8 Bytes dein Wettzähler, Little-Endian Herleitung hash = sha256( "dice" ‖ slothash ‖ user ‖ nonce ) // "dice" = die 4 ASCII-Bytes 0x64 0x69 0x63 0x65 roll = u128_be( hash[0..16] ) mod 10000 // erste 16 Bytes, Big-Endian, vorzeichenlos 128 Bit Ergebnis roll ist eine ganze Zahl in 0..9999, zwei Nachkommastellen über 0.00–99.99 ``` Details, auf die es beim Nachrechnen ankommt: * Die Hash-Eingabe ist die Verkettung in genau dieser Reihenfolge: das ASCII-Tag `"dice"`, der Slot-Hash, die Adresse des Nutzerkontos, dann die Nonce, kodiert als **8 Bytes Little-Endian**. * Die Stichprobe sind die **ersten 16 Bytes** der SHA-256-Ausgabe, gelesen als **Big-Endian**-Ganzzahl ohne Vorzeichen mit 128 Bit, reduziert modulo 10,000. * Die Reduktion einer 128-Bit-Stichprobe modulo 10,000 hat eine theoretische Verzerrung unter 2⁻¹¹⁴ – Dutzende Größenordnungen kleiner als der Hausvorteil. Deshalb wird sie dokumentiert statt korrigiert. ## Gewinnbedingung und Auszahlung ```text theme={null} Unter Ziel : du gewinnst, wenn roll < target Gewinnchance = target von 10000 Ergebnissen Über Ziel : du gewinnst, wenn roll > target Gewinnchance = 9999 − target von 10000 Ergebnissen multiplier_bps = floor( (10000 − edge_bps) × 10000 / win_chance_bps ) ``` Die gewählte Gewinnchance muss zwischen 2% und 98% liegen. Beim aktuellen Hausvorteil von 1.5% (`edge_bps = 150`): | Wette | Gewinnchance | Multiplikator | | - | - | - | | Unter 5000 | 50% | 1.97x | | Unter 200 | 2% | 49.25x | | Unter 9800 | 98% | 1.0051x | Die erwartete Rückzahlung ist für jeden Zielwert gleich: `Chance × Multiplikator ≈ 98.5%` des Einsatzes (das Abrunden begünstigt das Haus um höchstens einen Basispunkt). Der aktuelle Hausvorteil und die Limits stehen unter [Gebühren und Limits](/de/docs/fees-and-limits). ## Was garantiert ist – und was nicht **Vom Programm durchgesetzt:** * Der Wurf wird innerhalb einer einzigen On-Chain-Instruktion hergeleitet **und** abgerechnet, aus Eingaben, die das Programm selbst liest. Das Backend liefert den Wurf nicht und kann ihn nicht falsch melden. * Der Betreiber steuert **keine Eingabe** zur Herleitung bei: Es gibt keinen Server-Seed, den man durchprobieren könnte, bis ein günstiges Ergebnis herauskommt. * Deine Nonce muss exakt zurückgegeben werden, damit dieselbe Wette nicht versehentlich (oder böswillig) zweimal gespielt werden kann. * Jedes Spiel veröffentlicht alle Eingaben der Herleitung und das Ergebnis, sodass jeder jeden Wurf der Geschichte nachrechnen kann. **Der ehrliche Vorbehalt: der Zeitpunkt des Absendens.** Dice-Wetten sind gasless: Das Backend von MCC signiert die Transaktion für dich und sendet sie ab, der Betreiber bestimmt also, *wann* sie abgesendet wird. Der Hash von Slot `N−1` wird zu Beginn von Slot `N` öffentlich. Ein Betreiber mit sehr geringer Latenz könnte daher abschätzen, welchen Wurf eine Wette bekäme, *falls* sie im aktuellen Slot landet, und das Absenden verzögern, um neu zu ziehen. Das Verfahren nimmt das in Kauf, statt so zu tun, als gäbe es das nicht (es zu beseitigen würde ein VRF-Orakel erfordern, dessen Kosten pro Wette bei kleinen Wetten den Erwartungswert des Hauses übersteigen). Was es begrenzt: * Die Aufnahme in einen Block ist nicht vollständig steuerbar: Das Netzwerk, nicht der Absender, entscheidet, in welchem Slot eine Transaktion genau landet. * Jede Eingabe wird veröffentlicht, sodass Muster bei verzögertem Absenden und jede Abweichung der Gesamt-Gewinnquoten von den angegebenen Chancen **für jeden messbar** sind – anhand öffentlicher Daten. Systematischer Missbrauch kann nicht verborgen bleiben.

Wie überprüfst du einen Dice-Wurf?

Jedes Spiel sendet in der Transaktion der Wette selbst ein Event `DiceBetSettled` aus, das alles enthält, was du brauchst: `slothash`, `user`, `nonce`, `target_bps`, `direction`, `win_chance_bps`, `roll`, `multiplier_bps` und `is_win`, dazu die vollständige Aufschlüsselung der Abrechnung. So überprüfst du ihn: 1. Öffne die Transaktion der Wette in einem Solana-Explorer und lies die Event-Felder ab (der Dice-Bildschirm in der App zeigt die Fairness-Eingaben deiner Session, und dein Wettverlauf verlinkt auf die Transaktion). 2. Berechne `sha256("dice" ‖ slothash ‖ user ‖ nonce)` neu, nimm die ersten 16 Bytes als Big-Endian modulo 10,000 und vergleiche das mit dem `roll` des Events. 3. Prüfe die Entscheidung über Gewinn oder Verlust (`roll < target` bei Unter, `roll > target` bei Über) und den Multiplikator anhand der Formel oben. Unter [Eine Runde überprüfen](/de/docs/provably-fair/verify-a-round) findest du allgemeine Hinweise, wie du Event-Daten in einem Explorer abliest. Wie das Spiel selbst funktioniert, erfährst du in der [Dice-Spielanleitung](/de/docs/games/dice).