Provably Fair erklärt: So prüfst du ein Krypto-Spiel selbst

Du hast eine Runde gespielt: Provably Fair ist ein kryptografisches Verfahren, mit dem du nachträglich prüfen kannst, wie das Spielergebnis entstanden ist. Dafür müssen die nötigen Prüfdaten und der verwendete Algorithmus zugänglich sein. Du vergleichst dabei, ob sich das angezeigte Ergebnis aus den festgelegten Eingaben tatsächlich berechnen lässt.

Diese Kontrolle hat klare Grenzen: Ein überprüfbares Ergebnis sagt nichts über die Auszahlungspraxis, die Lizenz oder deine Gewinnwahrscheinlichkeit aus. Auch ein korrekt berechnetes Spiel kann einen Hausvorteil haben. Wir erklären dir zuerst Server Seed, Client Seed und Nonce, zeigen anschließend, welche Daten du sichern solltest, und führen dich dann durch das Nachrechnen einer gespielten Runde.

Kurz erklärt: Bei Provably Fair legt sich das Casino vor deiner Runde per Hash auf einen geheimen Server Seed fest und deckt ihn später auf. Mit Server Seed, Client Seed und Nonce rechnest du das Ergebnis dann selbst nach.

Provably Fair macht bestimmte Spielergebnisse nachprüfbar

Provably Fair macht nachvollziehbar, wie ein bestimmtes Spielergebnis aus festgelegten Eingaben berechnet wurde. Bei einem verbreiteten Verfahren erhältst du vor der Runde einen kryptografischen Prüfwert; später werden die zunächst geheimen Daten offengelegt. Mit diesen Daten und dem dokumentierten Rechenverfahren kannst du das Ergebnis selbst reproduzieren.

Vorab festlegen, später offenlegen

Vor deinem Einsatz stellt dir der Anbieter den Hash seines geheimen Server Seeds bereit. Dieser Hash dient als Commitment, also als kryptografische Festlegung: Sobald der Server Seed offengelegt wird, berechnest du dessen Hash erneut und vergleichst ihn mit dem zuvor gespeicherten Wert. Stimmen beide überein, spricht das dafür, dass der Anbieter denselben Seed verwendet hat, auf den er sich vorab festgelegt hatte.

Eine kryptografische Hashfunktion ist keine Verschlüsselung, die du mit einem Schlüssel rückgängig machst. Sie erzeugt aus einer Eingabe einen Prüfwert fester Länge; aus diesem den geheimen Seed zu ermitteln, ist bei geeigneten Verfahren und ausreichend unvorhersehbaren Seeds praktisch nicht machbar.

Der Unterschied zu einem gewöhnlichen Zufallszahlengenerator

Ein gewöhnlicher Zufallszahlengenerator kann beispielsweise eine Zahl zwischen 0 und 99 liefern. Allein diese Zahl erlaubt dir aber nicht, ihre Entstehung nachzurechnen. Provably Fair ergänzt einen überprüfbaren Ablauf, beweist jedoch nicht automatisch, dass die verwendeten Seeds tatsächlich zufällig gewählt wurden.

Eine Blockchain ist dafür nicht erforderlich: Hashvergleich und Ergebnisberechnung können außerhalb einer Blockchain stattfinden. Auch eine Einzahlung in Bitcoin liefert keinen Fairnessnachweis für das Spiel. Zahlungsweg und Ergebnisprüfung sind getrennte Themen; technische Grundlagen zum Zahlungsweg findest du unter Krypto-Zahlungen verstehen.

Server Seed, Client Seed und Nonce bilden die Grundlage

Für die Prüfung brauchst du die Eingaben der gespielten Runde und die genaue Berechnungsvorschrift. Server Seed, Client Seed und Nonce wirken dabei zusammen: Sie liefern die Ausgangsdaten, aus denen der Spielalgorithmus beispielsweise einen Würfelwert berechnet.

Welche Eingaben du für die Prüfung brauchst

Der Server Seed ist eine zunächst geheime Eingabe des Anbieters. Vor dem Spiel erhältst du üblicherweise nur seinen Hash als digitale Festlegung, das sogenannte Commitment; den offengelegten Seed brauchst du später zur Kontrolle.

Tipp: Lege deinen Client Seed erst fest, nachdem du den Server-Seed-Hash gesichert hast. Dann kann der Anbieter seinen Seed nicht gezielt auf deine bereits bekannte Eingabe abstimmen.

Die Nonce trennt aufeinanderfolgende Runden bei ansonsten gleichen Seeds. Sie muss weder bei 0 beginnen noch überall nach demselben Schema steigen: Maßgeblich ist die dokumentierte Zählweise des jeweiligen Spiels.

Wie Hash, HMAC und Spielalgorithmus zusammenspielen

Ein Hash bildet eine Eingabe auf einen Prüfwert ab; mit ihm kontrollierst du die ursprüngliche Festlegung. HMAC ist dagegen eine kryptografische Funktion mit Schlüssel, die Schlüssel und Nachricht verarbeitet. HMAC-SHA256 ist ein mögliches Verfahren, aber kein universeller Standard sämtlicher Spiele.

Entscheidend sind Schlüsselzuordnung, Reihenfolge der Eingaben, Trennzeichen und Zeichenkodierung, etwa UTF-8. Derselbe sichtbare Text kann bei anderer Verarbeitung andere Bytes und damit ein anderes Resultat erzeugen.

Anschließend übersetzt der Spielalgorithmus die Ausgabe in ein Ergebnis, beispielsweise einen Wert zwischen 0 und 9.999. Auch diese Umrechnung musst du nachvollziehen: Ein passender Server-Seed-Hash allein bestätigt noch nicht das angezeigte Spielergebnis.

Vor der ersten Runde sicherst du die Prüfdaten

Ohne den vor der Runde gespeicherten Server-Seed-Hash kannst du anhand deiner eigenen Aufzeichnungen nicht prüfen, ob der Anbieter den zugehörigen Server Seed rechtzeitig festgelegt hatte. Dieser Hash ist das Commitment: Er bindet den Anbieter an einen zunächst geheimen Wert. Sichere ihn deshalb vor dem Spielen, etwa als Screenshot und als kopierbaren Text.

Diese Angaben gehören in deine Aufzeichnung

Lege für jede zu prüfende Runde eine Aufzeichnung mit diesen Angaben an. Die Daten brauchst du, um später nicht nur den Hash, sondern auch die Berechnung des angezeigten Ergebnisses nachzuvollziehen:

• Spiel und Version beziehungsweise Regelstand: Welche Spielregeln und welche Ergebnisberechnung gelten?
• Runden-ID: die eindeutige Kennung der gespielten Runde.
• Server-Seed-Hash: das vorab gesicherte Commitment.
• Client Seed: der für diese Runde tatsächlich verwendete Wert.
• Nonce: der in die Berechnung eingehende Zählerwert.
• Einsatz und angezeigtes Ergebnis: einschließlich Einheit, beispielsweise USDT.
• Dokumentierter Prüfalgorithmus: sichere die Beschreibung einschließlich Eingabeformat und Umwandlung in das Spielergebnis.

Halte die Reihenfolge ein: Zuerst sicherst du das Commitment, danach änderst du gegebenenfalls den Client Seed und hältst dessen endgültigen Wert fest. Nach der Runde ergänzt du Runden-ID, Nonce, Einsatz und Ergebnis; den alten Server Seed prüfst du erst nach seiner Offenlegung.

Seed-Wechsel und Offenlegung richtig einordnen

Kläre vorab, wo und wann der verwendete Server Seed offengelegt wird. Das kann erst nach einer Seed-Rotation geschehen: Ein neuer geheimer Seed übernimmt künftige Runden, während der alte für vergangene Runden offengelegt werden kann. Ob dabei der Nonce zurückgesetzt oder anders weitergeführt wird, hängt von der Implementierung ab.

Achtung: Ein Spiel-Seed ist keine Wallet-Seed-Phrase. Seed Phrase und Private Key gehören niemals in einen Spielprüfer – für die Rechenprüfung brauchst du weder eine Einzahlung noch Wallet-Zugangsdaten.

In sechs Schritten prüfst du eine gespielte Runde

Für eine vollständige Prüfung brauchst du den vor der Runde gespeicherten Server-Seed-Hash, die Rundendaten und den später offengelegten Server Seed. Solange dieser Seed geheim bleibt, kannst du die Berechnung nicht vollständig nachstellen. Die Prüfansicht eines Anbieters kann beim Einstieg helfen; ein unabhängig ausgeführter Prüfer mit nachvollziehbarem Code ist jedoch die stärkere Gegenkontrolle.

Zuerst das Commitment, dann das Ergebnis prüfen

1. Ordne die gespeicherten Daten der richtigen Runde zu. Lege Runden-ID, ursprünglichen Server-Seed-Hash, Client Seed, Nonce und protokolliertes Spielergebnis bereit. Ergänze weitere Eingaben, falls das Verfahren sie verlangt. Entscheidend ist der Hash, den du bereits vor der Runde gesichert hast: Ein erst nachträglich angezeigter Wert belegt diese vorherige Festlegung, das sogenannte Commitment, nicht.

2. Prüfe den offengelegten Server Seed gegen das Commitment. Verarbeite ihn mit der dokumentierten Hashfunktion und der vorgesehenen Kodierung. Vergleiche anschließend den vollständigen berechneten Hash mit deinem gespeicherten Wert, nicht nur dessen Anfang und Ende. Stimmen beide überein, passt der offengelegte Seed zur vorherigen Festlegung; das Spielergebnis ist damit noch nicht geprüft.

3. Übernimm sämtliche Eingaben exakt. Kopiere Client Seed, Nonce und gegebenenfalls weitere Werte ohne Änderungen. Schon ein zusätzliches Leerzeichen oder ein Großbuchstabe statt eines Kleinbuchstabens kann ein anderes Ergebnis erzeugen. Beachte außerdem Zeichencodierung und Zahlenformat: Die Textfolge „01“ ist beispielsweise nicht dieselbe Eingabe wie „1“.

4. Führe die dokumentierte kryptografische Berechnung aus. Verwendet das Verfahren HMAC, müssen Schlüssel und Nachricht genau an den vorgesehenen Stellen stehen. Auch Trennzeichen und Reihenfolge der Eingaben gehören zur Spezifikation. Server Seed, Client Seed und Nonce nach eigener Wahl aneinanderzuhängen, ersetzt diese Berechnung nicht.

5. Wandle den berechneten Wert in das Spielergebnis um. Nutze dafür die veröffentlichte Umrechnung, etwa in eine Würfelzahl oder Kartenfolge. Prüfe Rundungsregeln und Indexierung: Beginnt die Zählung bei 0 oder bei 1? Falls das Spiel mehrere Zufallswerte oder zusätzliche Ziehungen benötigt, musst du auch diese Schritte vollständig nachvollziehen.

6. Vergleiche das Ergebnis und dokumentiere den Befund. Stelle dein errechnetes Ergebnis dem protokollierten Rundenergebnis gegenüber und speichere Eingaben, Algorithmusversion sowie Prüfausgabe. Eine Übereinstimmung bestätigt die nachvollzogene Berechnung dieser Runde. Sie beweist weder die Korrektheit aller anderen Runden noch die Zuverlässigkeit von Auszahlungen.

Abweichungen systematisch eingrenzen

Bei einer Abweichung kontrollierst du zuerst Runden-Zuordnung, Nonce, Kodierung und Algorithmusversion. Eine veraltete Umrechnungsregel kann ebenso ein anderes Ergebnis liefern wie ein Kopierfehler. Ein Unterschied ist deshalb nicht automatisch ein Betrugsnachweis.

Bleibt die Abweichung bestehen, sichere die Originaldaten und kontaktiere den Support mit Runden-ID, erwarteter Ausgabe und deiner Berechnung. Bis zur Klärung kannst du weitere Einsätze pausieren. Zeigt nur dieselbe Anbieteroberfläche „verifiziert“ an, ist das noch keine unabhängige Gegenkontrolle – auch dann nicht, wenn sie in einem zweiten Browserfenster geöffnet ist.

Ein Rechenbeispiel zeigt die Umwandlung in ein Spielergebnis

Ein passender Seed-Hash allein reicht nicht, um ein Spielergebnis zu prüfen: Auch die Umrechnung der kryptografischen Ausgabe muss stimmen. Wir verwenden dafür ein ausdrücklich didaktisches Beispiel ohne Anbieterbezug. Die Zahl 173 nehmen wir als Byte aus einer kryptografischen Ausgabe an; sie ist hier kein tatsächlich berechneter HMAC aus bestimmten Seeds.

Aus einem Byte wird eine Zahl von 0 bis 99

Ein Byte kann 256 verschiedene Werte annehmen, von 0 bis 255. Unser Beispielspiel soll dagegen genau 100 mögliche Ergebnisse ausgeben: die Zahlen 0 bis 99. Damit diese gleich wahrscheinlich sind, akzeptiert das Beispielverfahren nur Bytewerte von 0 bis 199.

Werte von 200 bis 255 werden verworfen. Der Algorithmus verwendet dann den nächsten Wert nach einer vorher festgelegten Regel und prüft erneut, ob er im erlaubten Bereich liegt. Dieses Verfahren heißt „Rejection Sampling“: Ungeeignete Werte werden aussortiert, statt sie einem Spielergebnis zuzuordnen.

Für einen akzeptierten Wert berechnen wir den Rest bei der Division durch 100. Konkret: 173 mod 100 = 73, denn 173 geteilt durch 100 ergibt 1 mit Rest 73. Das Beispielergebnis lautet deshalb 73.

Unter den 200 akzeptierten Werten kommt jeder Rest von 0 bis 99 genau zweimal vor. Für das Ergebnis 73 sind das die Ausgangswerte 73 und 173, für das Ergebnis 0 die Werte 0 und 100. Sofern die Ausgangsbytes gleichverteilt sind, bleiben dadurch auch die 100 Spielergebnisse gleichverteilt.

Warum die Umrechnung das Ergebnis verzerren kann

Würden wir stattdessen alle 256 Bytewerte einfach modulo 100 rechnen, entstünde eine Verzerrung. Die Ergebnisse 0 bis 55 hätten jeweils drei mögliche Ausgangswerte; beispielsweise würde 0 aus 0, 100 und 200 entstehen. Die Ergebnisse 56 bis 99 hätten dagegen nur zwei.

Für deine Prüfung bedeutet das: Du musst auch nachvollziehen können, welche Bytes das Spiel verwendet, welche es verwirft und wie daraus das Ergebnis entsteht. Diese Umrechnung muss zum dokumentierten Spiel passen. Unser Beispiel erklärt das Prinzip, ersetzt aber keinen spielbezogenen Verifikator.

Provably Fair beseitigt weder Hausvorteil noch Verlustrisiko

Provably Fair macht die Berechnung bestimmter Spielergebnisse nachvollziehbar, nicht das Spielen profitabel. Wenn du eine Würfelrunde korrekt reproduzierst, hast du deren Berechnung geprüft – aber weder günstige Auszahlungsregeln noch die Zahlungsfähigkeit des Anbieters nachgewiesen.

Ein korrektes Ergebnis kann zu einem nachteiligen Spiel gehören

Ein Beispielspiel kostet 10 € Einsatz pro Runde und hat eine Gewinnwahrscheinlichkeit von 49 %. Bei einem Gewinn erhältst du insgesamt 20 € zurück, bei einer Niederlage nichts. Die 20 € Gesamtauszahlung enthalten bereits deinen Einsatz: Dein Nettogewinn beträgt im Gewinnfall also 10 €.

Du bekommst rechnerisch im Mittel 98 % deiner Einsätze zurück, obwohl jedes Ergebnis korrekt überprüfbar sein kann. Bei 100 Runden zu jeweils 10 € wären das 1.000 € Gesamteinsatz und 20 € erwarteter Verlust. Dieser Erwartungswert ist keine Vorhersage für eine einzelne Sitzung: Dein tatsächliches Ergebnis kann erheblich davon abweichen.

Was der Nachweis nicht über den Anbieter aussagt

Provably Fair prüft für sich genommen weder Lizenz noch Bonusbedingungen, KYC-Abläufe oder Auszahlungspraxis. Auch Solvenz und der vollständige Ablauf hinter der Benutzeroberfläche werden dadurch nicht nachgewiesen. Eine korrekt berechnete Runde sagt beispielsweise nichts darüber aus, ob und wann dein Guthaben ausgezahlt wird.

Der Nachweis gilt außerdem nur für das konkrete Spiel und die geprüfte Umsetzung. Ein überprüfbares Würfelspiel belegt nicht automatisch, dass sämtliche Slots, Live-Casino-Spiele oder Sportwetten derselben Plattform auf diese Weise kontrollierbar sind.

Lege deshalb unabhängig von der technischen Prüfung ein festes Verlust- und Zeitlimit fest, etwa höchstens 30 € Verlust und 45 Minuten Spielzeit – und beende die Sitzung, sobald eine Grenze erreicht ist. Auch nach mehreren korrekt verifizierten Runden steigt die Chance auf einen Ausgleich vorheriger Verluste nicht automatisch. Wie du solche Grenzen planst, erklären wir unter Limits und Spielpausen.

Provably-Fair-Spiele in unseren Analysen

Provably Fair findest du fast nur bei hauseigenen Spielen, den sogenannten Originals. Slots und Live-Tische externer Studios laufen dagegen über zertifizierte Zufallsgeneratoren. In unseren Analysen bieten diese Casinos prüfbare Originals:

Tipp: Eine nach Funktionen sortierte Übersicht findest du unter Provably Fair Casinos. Prüfe vor dem ersten Einsatz, ob das Casino Server-Seed-Hash, Client Seed und Nonce pro Runde anzeigt.

Mit dieser Prüfliste beurteilst du die Umsetzung

Ein Provably-Fair-Verfahren ist für dich nur dann unabhängig prüfbar, wenn du den Weg vom vorab veröffentlichten Commitment bis zum Rundenergebnis nachvollziehen kannst. Entscheidend sind fünf Merkmale – nicht das Fairness-Siegel neben dem Spiel.

Merkmale einer nachvollziehbaren Prüfung

• Commitment vor der Runde: Der Hash des Server Seeds ist vor Spielbeginn sichtbar und speicherbar. So kannst du später prüfen, ob der offengelegte Seed zur vorherigen Festlegung passt.
• Nachvollziehbare Eingaben: Client Seed, Nonce und gegebenenfalls weitere Eingaben sind eindeutig der betreffenden Runde zugeordnet.
• Geregelte Offenlegung: Die Dokumentation erklärt, wann und wie du den verwendeten Server Seed erhältst, etwa nach einem Seed-Wechsel.
• Vollständiger Algorithmus: Beschrieben sind sowohl die kryptografische Berechnung als auch die Umrechnung ihres Ergebnisses in Würfelzahl, Kartenfolge oder einen anderen Spielausgang.
• Unabhängige Reproduktion: Mit den gespeicherten Daten kannst du das Ergebnis außerhalb der eingebauten Prüffunktion nachrechnen, beispielsweise mit einem nachvollziehbaren Skript.

Warnzeichen ohne vorschnelles Betrugsurteil

Ein Fairness-Siegel ohne technische Erklärung reicht nicht als Nachweis. Weitere Warnzeichen sind eine fehlende Rundenzuordnung, ein nach dem vorgesehenen Offenlegungszeitpunkt unzugänglicher alter Server Seed oder eine Prüffunktion, die lediglich „fair“ meldet, ohne Eingaben und Berechnung offenzulegen.

„Nicht selbst prüfbar“ bedeutet nicht automatisch „nachweislich manipuliert“. Fehlende Informationen verhindern eine positive Fairnessbestätigung für die betreffende Runde, beweisen allein aber keinen Betrug. Zusätzliche Einsätze liefern die fehlenden Prüfdaten nicht und erhöhen nur dein Verlustrisiko.

Prüfe zuerst die Dokumentation und sichere dann das Commitment vor einer Runde. Rechne anschließend eine bereits gespielte Runde nach; eine Anmeldung oder Einzahlung solltest du dafür nicht eigens vornehmen.