> ## 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.
# Provably Fair im Überblick
> Commit-Reveal einfach erklärt, was die Chain-Entropie beiträgt und was du selbst überprüfen kannst.
Jedes Spielergebnis bei My Crypto Casino entsteht durch ein **Commit-Reveal-Verfahren in Kombination mit Entropie aus der Solana-Chain**, ausgeführt vom On-Chain-Programm. Für dich als Spieler bedeutet das zweierlei:
1. **Das Ergebnis lässt sich nachträglich nicht ändern.** Der Betreiber legt seinen Beitrag (einen geheimen Wert) *vor* dem Spiel fest, indem er einen kryptografischen Fingerabdruck davon on-chain veröffentlicht. Später verweigert das Programm die Abrechnung, sofern das enthüllte Geheimnis nicht exakt zu diesem Fingerabdruck passt.
2. **Du kannst alles selbst überprüfen.** Alle Eingaben und die genaue Formel sind öffentlich. Nach jeder Runde oder Wette kannst du das Ergebnis aus On-Chain-Daten nachrechnen und mit dem vergleichen, was das Spiel ausgezahlt hat.
Diese Seite erklärt das Verfahren in einfachen Worten. Die Seiten zu den einzelnen Spielen enthalten die genauen Formeln, und [Eine Runde überprüfen](/de/docs/provably-fair/verify-a-round) führt dich Schritt für Schritt durch die Prüfung einer echten Runde.
Woraus besteht Provably Fair?
**Ein festgelegtes Geheimnis.** Wo ein Ergebnis während des Spiels verborgen bleiben muss (Crash, Mines), erzeugt das Backend ein zufälliges 32-Byte-Geheimnis und veröffentlicht dessen SHA-256-Hash (den *Commit*) on-chain, bevor das Spiel beginnt. Ein Hash funktioniert wie ein versiegelter Umschlag: Er verrät nichts über das Geheimnis, aber sobald er veröffentlicht ist, passt nur noch genau dieses eine Geheimnis dazu. Wenn das Geheimnis am Ende enthüllt wird, hasht das Programm es selbst und lehnt die Transaktion ab, falls es nicht zum Commit passt.
**Entropie aus der Solana-Chain.** Das Ergebnis hängt nie allein vom Geheimnis ab. Zusätzlich fließt ein **Slot-Hash** ein: der Hash eines aktuellen Solana-Slots, den das Programm zu einem festgelegten Zeitpunkt aus Solanas `SlotHashes`-Sysvar liest. Dieser Wert wird vom Solana-Netzwerk erzeugt, nicht vom Casino, und existiert zum Zeitpunkt des Commits noch gar nicht.
**Eine öffentliche, deterministische Formel.** Das Ergebnis ist eine feste mathematische Funktion dieser Eingaben. Dieselbe Funktion läuft im On-Chain-Programm (das Backend kann kein falsches Ergebnis melden, denn das Programm berechnet es), und sie ist auf diesen Seiten veröffentlicht, damit du sie selbst ausführen kannst.
Wie läuft eine Runde Schritt für Schritt ab?
```mermaid theme={null}
sequenceDiagram
participant MCC as MCC-Backend (Betreiber)
participant SOL as Solana-Programm
participant You as Spieler
Note over MCC,SOL: 1. Commit
MCC->>SOL: Commit veröffentlichen = sha256(Geheimnis)
Note over You,SOL: 2. Spiel
You->>SOL: Wetten werden on-chain platziert
Note over SOL: 3. Chain-Entropie
SOL->>SOL: Aktuellsten Solana-Slot-Hash erfassen
Note over MCC,SOL: 4. Reveal
MCC->>SOL: Geheimnis übermitteln
SOL->>SOL: Prüfen, ob sha256(Geheimnis) zum Commit passt
SOL->>SOL: Ergebnis mit der öffentlichen Formel berechnen
Note over You: 5. Überprüfen (jederzeit später)
You->>SOL: Commit, Slot-Hash und Geheimnis aus der Chain lesen
You->>You: Ergebnis nachrechnen und vergleichen
```
Dice fasst diesen Ablauf in einer einzigen Transaktion zusammen: Es gibt keinen verborgenen Zustand zu schützen, also auch überhaupt kein Geheimnis des Betreibers. Der Wurf wird aus dem Slot-Hash, deinem Konto und deinem Wettzähler abgeleitet und in derselben Instruktion abgerechnet, die ihn auslost.
## Was jedes Spiel festlegt, und wann
| Spiel | Geheimnis des Betreibers | Chain-Entropie | Ergebnis steht fest bei | On-chain durchgesetzt |
| - | - | - | - | - |
| [Crash](/de/docs/provably-fair/crash) | 32-Byte-Geheimnis, festgelegt **bevor die Wetten öffnen** | Slot-Hash, erfasst beim Rundenstart | Rundenstart | Commit-Prüfung + Crash-Punkt, beim Reveal vom Programm berechnet |
| [Dice](/de/docs/provably-fair/dice) | Keines | Slot-Hash in dem Moment, in dem deine Wett-Transaktion landet | Aufnahme der Wett-Transaktion | Wurf vom Programm in einer Instruktion abgeleitet und abgerechnet |
| [Mines](/de/docs/provably-fair/mines) | 32-Byte-Seed, festgelegt **in der Transaktion, die dein Spiel startet** | Slot-Hash, erfasst in derselben Start-Transaktion | Spielstart, vor deinem ersten Klick | Seed-Prüfung + komplettes Spielfeld bei der Abrechnung vom Programm neu abgeleitet |
## Was das garantiert, und was es voraussetzt
Ehrlichkeit ist hier wichtiger als Marketing, also bleiben wir präzise. Dieses Verfahren ist **Commit-Reveal mit öffentlicher Chain-Entropie, keine VRF** (Verifiable Random Function). Hier ist die genaue Grenze zwischen dem, was *durch Code durchgesetzt* wird, und dem, was *auf korrektem Verhalten des Betreibers beruht*.
### Vom On-Chain-Programm durchgesetzt
* **Kein Austausch des Ergebnisses nach dem Commit.** Das Programm hasht das enthüllte Geheimnis und lehnt jede Abrechnung ab, bei der es nicht zum veröffentlichten Commit passt. Der Betreiber kann kein anderes Geheimnis wählen, nachdem er gesehen hat, wie eine Runde läuft.
* **Entropie, die der Betreiber nicht erzeugt.** Der Slot-Hash stammt aus dem Solana-Netzwerk. Beim Veröffentlichen des Commits ist er unbekannt, und das Casino erzeugt ihn nicht.
* **On-chain berechnete Ergebnisse.** Der Crash-Punkt, der Würfelwurf und das Mines-Spielfeld werden vom Programm selbst berechnet (bzw. neu abgeleitet und geprüft). Das Backend kann kein Ergebnis melden, das die Formel nicht liefert.
* **Vollständige öffentliche Prüfbarkeit.** Jede Runde und jede Wette erzeugt On-Chain-Events, die alle Eingaben der Ableitung und das Ergebnis enthalten. Jeder, nicht nur der beteiligte Spieler, kann jedes historische Ergebnis nachrechnen.
### Vorausgesetzt: die ehrlichen Einschränkungen
* **Einfluss über das Timing.** Das Backend des Betreibers entscheidet, *wann* bestimmte Transaktionen übermittelt werden, und hat damit teilweise Einfluss darauf, *welcher* Slot-Hash erfasst wird. Jede Spielseite beschreibt genau, was sich damit bei diesem Spiel erreichen ließe und was nicht.
* **Abbrüche sind möglich, aber nur mit Rückerstattung.** Der Betreiber kann eine Crash-Runde oder ein Mines-Spiel annullieren. Eine Annullierung erstattet immer jeden Einsatz vollständig (das Programm kann über einen Abbruch nichts einbehalten), und jede Annullierung wird öffentlich protokolliert, sodass jeder die Häufigkeit von Abbrüchen prüfen kann. Häufige Abbrüche wären die sichtbare On-Chain-Signatur eines Betreibers, der sich falsch verhält.
* **Das Mines-Spielfeld ist dem Betreiber während des Spiels bekannt.** Das ist strukturell bedingt: Felder werden sofort off-chain aufgedeckt, und wer sie ausliefert, muss das Spielfeld kennen. Der Commit garantiert, dass das Spielfeld vor deinem ersten Klick feststand und danach nicht umgeschrieben werden kann. Wie genau das durchgesetzt wird, steht unter [Mines-Fairness](/de/docs/provably-fair/mines).
### Warum diese Kompromisse?
Weil sie der Preis für sofortiges, nahtloses Gameplay sind, keine Abkürzungen. Jedes Spiel steht genau dort auf diesem Spektrum, wo es stehen muss:
* **Mines**: Ein Feld in Millisekunden aufzudecken erfordert strukturell eine Partei, die das Spielfeld bereits kennt. Die Alternativen (eine On-Chain-Transaktion pro Klick oder ein Oracle-Roundtrip pro Aufdecken) würden jedes Feld zu einer Gebühr und einer Wartezeit machen. Ein Betreiber, der das Spielfeld kennt, ist unverzichtbar für ein Mines, das sich sofort anfühlt und trotzdem on-chain abgerechnet wird; das Commit-Verfahren existiert, um einzugrenzen, was dieses Wissen bewirken kann.
* **Crash**: Eine gemeinsame Live-Runde braucht jemanden, der sie für alle Spieler gleichzeitig steuert. Das ist eher eine pragmatische Entscheidung als eine strukturelle Notwendigkeit, weshalb das Programm einen eingebauten Migrationspfad zu Oracle-basierter Zufälligkeit (VRF) mitbringt: eine künftige Phase, die die Timing-Einschränkungen dort beseitigen würde, wo es sich wirtschaftlich lohnt.
* **Dice**: das andere Ende des Spektrums. Während des Spiels gibt es nichts zu verbergen, also auch kein Geheimnis des Betreibers. Wo sich Vertrauen in den Betreiber kostenlos beseitigen lässt, beseitigt das Design es.
Kurz gesagt: Der Betreiber führt die Spiele, und die Chain macht Betrug entweder **unmöglich** (alles nach dem Commit) oder **öffentlich erkennbar** (Timing-Muster, Häufigkeit von Abbrüchen, Gewinnquoten-Statistiken).
**Fairness des Ergebnisses vs. Verwahrung der Gelder**
In diesem Abschnitt geht es darum, wie *Ergebnisse* erzeugt werden. Wie Einzahlungen, Guthaben und Abhebungen on-chain verwahrt werden, ist ein eigenes Thema; siehe [On-Chain-Architektur](/de/docs/security/on-chain-architecture).
## Überprüfe es selbst
* In der App zeigt jede beendete Crash-Runde in den Rundendetails ihre Fairness-Daten (das enthüllte Geheimnis, den Block-Hash und Links zu den On-Chain-Transaktionen), dazu ein Fairness-Tool, das mit einem Klick prüft.
* Dice und Mines veröffentlichen jede Eingabe der Ableitung im Abrechnungs-Event der jeweiligen Wett-Transaktion.
[Eine Runde überprüfen](/de/docs/provably-fair/verify-a-round) führt durch den gesamten Ablauf, von den Daten in der App bis zum Nachrechnen des Ergebnisses mit ein paar Zeilen Code.