Provably Fair RNG erklärt: Technischer Leitfaden (2026)

Provably Fair Zufallszahlengenerierung erklärt (2026)

Du hast gerade 0,5 BTC auf ein Krypto-Würfelspiel gesetzt. Der Bildschirm zeigt 37,42 und du verlierst. Du öffnest das Fairness-Panel und siehst einen Server-Seed-Hash, deinen Client-Seed und einen Nonce — vier Werte, die angeblich beweisen, dass nichts manipuliert wurde. Aber wie wurden aus diesen vier Werten eigentlich 37,42? Was hat zufällige Hex-Zeichen in einen spezifischen Würfelwurf verwandelt?

Hier ist das Ding: Das ganze „Provably Fair"-Versprechen hängt von einem spezifischen Prozess ab — der Umwandlung von kryptografischer Hash-Ausgabe in Spielergebnisse. Wenn du nicht verstehst, wie diese Umwandlung funktioniert, wirkt Provably Fair wie Marketing-Magie. Wenn du es verstehst, kannst du jedes PF-Casino in etwa 60 Sekunden prüfen, Fake-Implementierungen auf den ersten Blick erkennen und genau wissen, welche Angriffe das Protokoll verhindert und welche nicht.

Dieser Leitfaden führt dich durch Provably Fair Zufallszahlengenerierung so, wie es ein Entwickler 2026 implementieren würde — die CSPRNG-Grundlagen unter der Haube, die HMAC-SHA256-Formel, die Seeds in Zahlen verwandelt, die verschiedenen Mapping-Schemata für Würfel, Crash und Karten, und die Angriffsfläche, die selbst dann bestehen bleibt, wenn die Mathematik perfekt ist. Am Ende wirst du wissen, warum PF-RNGs kryptografisch unzerbrechlich sind, welche Implementierungsfehler sie trotzdem ruinieren, und wann Blockchain-Zufälligkeit (Chainlink VRF) stattdessen eingesetzt wird.

Kurzfassung — Wie PF-RNGs tatsächlich Zahlen generieren

Jedes Provably Fair-Spiel verwendet den gleichen RNG-Kern, nur die Ausgabe-Mapping unterscheidet sich. Hier ist die 60-Sekunden-Version.

Die Mathematik ist:

$\text{outcome} = f\big(\text{HMAC-SHA256}(\text{server\_seed},\; \text{client\_seed} : \text{nonce})\big)$

Wobei f eine spielspezifische Mapping-Funktion ist — f_dice gibt 0-99,99 zurück, f_crash gibt einen Multiplikator zurück, f_cards gibt Kartendeck-Positionen zurück. Der HMAC-Teil ist identisch bei jedem PF-Casino der Welt.

Wichtige Zahlen, die du kennen solltest

• 3 Eingaben: Server-Seed + Client-Seed + Nonce erzeugen jedes Ergebnis
• 64 Hex-Zeichen: Länge einer SHA-256 / HMAC-SHA256-Ausgabe
• 128 Hex-Zeichen: Länge von HMAC-SHA512 (verwendet von BC.Game und PF Blackjack)
• ~2^256 Operationen: Was es bräuchte, um HMAC-SHA256 zu knacken — astronomisch unerreichbar
• 0,00-99,99: Standardwürfelbereich nach Mapping
• 1,00x bis ∞: Standardbereich für Crash-Multiplikator (in der Praxis durch Float-Genauigkeit begrenzt)

Fair ≠ Profitabel

Dass der RNG Provably Fair ist, sagt dir, dass das Casino das Ergebnis nach deiner Wette nicht manipulieren konnte. Es sagt dir nicht:

• Ob der Hausvorteil angemessen ist (überprüfe RTP separat)
• Ob das Casino Auszahlungen ehrt
• Ob Boni und Umsatzbedingungen ehrlich sind
• Ob der Server-Seed-Pool vor seiner Bestätigung unbefangen war

Wir behandeln die gesamte Angriffsfläche unten. Für einen umfassenderen Vergleich mit traditioneller Zertifizierung siehe unseren Provably Fair vs. RNG-zertifiziert Leitfaden.

Was macht einen RNG „Provably Fair"

Bevor wir zur Formel kommen, hilft es, Provably Fair von der breiteren RNG-Welt zu unterscheiden. PF ist eine spezifische Verbesserung von CSPRNGs, keine Ersetzung.

Das Commit-Reveal-Muster

Der ganze Trick hinter Provably Fair ist ein kryptografisches Muster namens Commit-Reveal.

Bevor die Runde beginnt, legt sich das Casino auf einen spezifischen Server-Seed fest, indem es seinen SHA-256-Hash veröffentlicht. Der Hash ist ein 64-stelliger Fingerabdruck, der den Seed eindeutig identifiziert, ohne ihn preiszugeben. Da SHA-256 keine praktischen Kollisionsangriffe hat, kann das Casino später keinen anderen Seed finden, der den gleichen Hash erzeugt — sie sind gebunden.

Nach der Runde (oder nachdem du Seeds rotierst), wird der Raw-Server-Seed offengelegt. Du hashst ihn selbst. Wenn dein berechneter Hash dem entspricht, was vor der Runde veröffentlicht wurde, hat das Casino bewiesen, dass es Seeds nicht mid-round getauscht hat. Kombiniert mit deinem Client-Seed (den sie vorher nicht kannten), macht dies Ergebnis-Manipulation pro Runde kryptografisch unmöglich.

Die Commit-Reveal-Schicht ist das, was PF von jedem anderen CSPRNG unterscheidet. Ein traditionelles RNG-zertifiziertes Casino verwendet auch einen CSPRNG — aber nichts hindert sie daran, es in der Produktion auszutauschen, wie iTech Labs-Audits nur statistische Eigenschaften überprüfen, nicht Runtime-Identität.

HMAC als RNG-Primitiv

HMAC-SHA256 ist der eigentliche Zufallszahlengenerator in jeder PF-Runde. Hier ist, warum es funktioniert:

• Deterministisch: Bei den gleichen Eingaben erzeugt HMAC immer die gleiche Ausgabe. Das ist, was dir die Überprüfung ermöglicht.
• Einweg: Aus der Ausgabe kannst du den Server-Seed (den Schlüssel) nicht wiederherstellen. Das ist, was das Ergebnis unvorhersehbar macht.
• Uniform: HMAC-Ausgaben sind nicht vom Zufall zu unterscheiden — 256-Bit-Zeichenketten. Das ist, was das Spiel unvoreingenommen hält.
• Verschlüsselt: Der Server-Seed fungiert als Geheimnis, das bekannt sein muss, um die Ausgabe zu reproduzieren. Das ist, was Manipulation verhindert.

Technisch gesehen ist HMAC-SHA256 von sich aus kein CSPRNG — es ist ein Message Authentication Code. Aber wenn der Schlüssel (Server-Seed) aus einer echten Entropiequelle generiert wird, ist die Konstruktion für alle praktischen Zwecke gleichwertig mit einem CSPRNG. NIST formalisierte dies als HMAC_DRBG in SP 800-90A Rev 1, und PF-Casinos implementieren im Wesentlichen diesen Standard mit zusätzlicher öffentlicher Seed-Bestätigung neu.

Warum CSPRNGs wichtig sind (nicht Math.random)

Jedes legitime PF-Casino generiert seinen Server-Seed mit einem kryptografisch sicheren RNG — nicht mit JavaScripts Math.random(). Der Unterschied ist wichtiger als den meisten Spielern bewusst ist:

Wenn ein Casino seinen Server heimlich mit Math.random() seeded, könnte ein ausgeklügelter Angreifer den Seed aus genügend öffentlichen Ausgaben rekonstruieren und jede zukünftige Runde vorhersagen — selbst wenn die HMAC-Mathematik fehlerfrei ist. Deshalb ist es wichtig zu überprüfen, ob dein Casino tatsächlich crypto.randomBytes oder Äquivalentes verwendet; der Was ist Provably Fair Glücksspiel Erklärtext behandelt die vollständige Vertrauenskette.

Wie die Zahl tatsächlich generiert wird

Jetzt zur eigentlichen Formel. Dies ist der Abschnitt zum Speichern — alles oben war Kontext.

Drei Eingaben, Eine Formel

Jede Provably Fair-Runde berechnet:

$\text{hex\_output} = \text{HMAC-SHA256}(\text{server\_seed},\; \text{client\_seed} \; : \; \text{nonce})$

Im Pseudocode:

function pfHmac(serverSeed, clientSeed, nonce) {
  const message = clientSeed + ':' + nonce
  const hex = hmacSha256(serverSeed, message)  // 64-stellige Hex-Zeichenkette
  return hex
}

Der : Doppelpunkt ist das kanonische Trennzeichen bei Stake, Primedice, Rainbet und den meisten PF-Casinos. Einige wenige (BC.Game, Roobet) verwenden unterschiedliche Trennzeichen — überprüfen Sie immer die Fairness-Dokumentation des Casinos auf das genaue Format.

Die Ausgabe ist eine 64-stellige Hexadezimalzeichenkette wie 8b2d4a1f9c6e7b3d5a8f2c9e4b1d7a6f3e8c5b2d9a4f7e1c8b3d6a2f9e5c4b7d. Dieses Hex ist die Rohzufälligkeit — 256 Bit Unvorhersehbarkeit, statistisch nicht zu unterscheiden von 256 fairen Münzwürfen.

Schritt für Schritt: Von der HMAC-Ausgabe zum Würfelwurf

Lassen Sie uns eine komplette Runde durchgehen.

Gegebene Werte:

• server_seed = f4a9c2e1b7d8e3c5a1b9f6d2e8c4a7b3e9d1c6a2b5f8e4c7a3b6e1d9c2a5b8f4
• client_seed = player-xyz-42
• nonce = 7

Schritt 1 — HMAC berechnen:

HMAC-SHA256(server_seed, "player-xyz-42:7")
= 8b2d4a1f9c6e7b3d5a8f2c9e4b1d7a6f3e8c5b2d9a4f7e1c8b3d6a2f9e5c4b7d

Schritt 2 — Erste 5 Hex-Zeichen auswählen:

8b2d4 → in Dezimalzahl konvertieren → 569.300

Schritt 3 — Auf 0-99,9999 abbilden:

dice = (569_300 % 1_000_000) / 10_000
     = 569_300 / 10_000
     = 56,93

Schritt 4 — Wettlogik anwenden:

Wenn Sie „unter 50 würfeln" wetten → Sie verlieren (56,93 > 50). Wenn Sie „unter 60 würfeln" wetten → Sie gewinnen. Der exakte Wurf wurde in dem Moment festgelegt, als diese drei Eingaben kombiniert wurden, bevor eine UI-Animation ablief.

Schritt 5 — Verifizieren:

Nach der Runde erhalten Sie den offengelegten server_seed. Sie hashen ihn — SHA-256 entspricht dem vorgefertigten Hash? Gut. Sie führen die Schritte 1-3 erneut durch — reproduziert 56,93? Gut. Die Runde ist kryptographisch Provably Fair.

Für eine vollständige Anleitung mit kopier-einfügen-Werten und Screenshots siehe wie man eine Provably Fair-Runde verifiziert.

Verschiedene Spiele, Verschiedene Abbildungen

Der HMAC-Aufruf ist immer identisch. Was sich ändert, ist Schritt 3 — wie die Hex-Zahl zu einem spezifischen Spielergebnis abgebildet wird.

Jede Abbildung ist so konzipiert, dass sie über ihren Ausgabebereich gleichmäßig verteilt ist — modulare Arithmetik auf einem gleichmäßig zufälligen Hex-Wert bewahrt Gleichmäßigkeit. Dies ist der Grund, warum PF-Spiele eine ehrliche RTP beanspruchen können, ohne dass das Casino einzelne Runden manipuliert. Es ist die Abbildungsformel, die abgestimmt wird, um die Hausvorteil-Zielquote des Casinos zu erreichen, nicht die Zufallszahl selbst.

Von der Hex-Zeichenkette zum Spielergebnis (Mit Mathematik)

Die Dice-Abbildung lohnt sich zu analysieren, da sie der klarste Fall ist — und weil sie zeigt, warum Provably Fair-Würfelverteilungen bei korrekter Implementierung wirklich gleichmäßig sind.

Dice-Abbildung (0-99,9999)

Stake's Würfelspiel verwendet die ersten 5 Hex-Zeichen, was 20 Bit = 1.048.576 mögliche Werte ergibt. Die Abbildung ist:

$\text{dice} = \frac{(\text{int}(\text{hex}_{0:5}) \; \text{mod} \; 10^6)}{10^4}$

Warum Modulo 1.000.000, wenn die Auswahl bis 1.048.575 reichen kann? Weil ohne das Modulo Werte 1.000.000-1.048.575 zu 100,0000-104,8575 abgebildet würden, außerhalb des Würfelbereichs. Modulo faltet diese zurück — führt aber eine winzige Verzerrung ein (Werte 0-48.575 sind um den Faktor 2/1 wahrscheinlicher als 48.576-99.999). Um die Verzerrung zu beseitigen, lehnen echte Implementierungen Auswahlen über 1.000.000 ab und rücken zum nächsten Hex-Block vor (Zeichen 5-10, dann 10-15, etc.).

Richtig durchgeführt, erzeugt dies eine perfekt gleichmäßige Verteilung über 0,0000-99,9999. Ein 10.000-Wurf-Test zeigt im Wesentlichen eine flache Abdeckung — das Histogramm unten reproduziert das, was Sie mit jeder legitimen PF-Würfel-Implementierung sehen würden.

Crash-Abbildung (Multiplikator)

Crash ist interessanter, weil die Ausgabe nicht gleichmäßig ist — sie ist absichtlich verzerrt, um dramatisches Gameplay zu schaffen und gleichzeitig einen Zielhousvorteil zu bewahren.

$\text{crash} = \frac{\left\lfloor \dfrac{100 \cdot 2^{52} - h}{2^{52} - h} \right\rfloor}{100}$

Wobei h = int(hex[0:8]) (eine 32-Bit-Ganzzahl aus den ersten 8 Hex-Zeichen). Mit einer Änderung: Wenn h mod 33 == 0, ist der Multiplikator 1,00x (sofortiger Crash), was Stake's ~1% Hausvorteil erzeugt. Andere Casinos verwenden unterschiedliche Divisoren — 25 (Rainbet ~4% Edge), 50 (niedrig-Edge-Varianten), 100 (sehr niedrig-Edge).

Führen Sie diese Formel eine Million Mal aus und Sie erhalten eine Verteilung, bei der ~50% der Runden unter 2x crashen, ~10% die 10x überschreiten und etwa 1% die 100x erreichen. Der erwartete Wert beläuft sich auf 0,99 pro 1 Einsatz — die fehlenden 1% sind der Hausvorteil, der in die Konstanten der Formel eingebacken ist, nicht in eine Pro-Runden-Manipulation.

Karten-Abbildung (Deck-Shuffles)

PF-Blackjack, Poker und Baccarat mischen virtuelle Decks mit HMAC-SHA512 (längere Ausgabe = mehr Karten pro Hash-Aufruf). Fisher-Yates-Shuffle ist der Standard:

for i = 51 down to 1:
  j = hmac_int(i) mod (i + 1)
  swap(deck[i], deck[j])

Jeder hmac_int(i)-Aufruf verbraucht 4 Hex-Zeichen der 128-stelligen SHA-512-Ausgabe. Die Karten einer Runde werden vollständig durch einen HMAC-Aufruf bestimmt, weshalb Sie bei PF-Blackjack-Spielen häufig 13+ dezimal konvertierte Ganzzahlen im Verifizierungspanel sehen — eine pro Kartentausch. Für die spezifische Implementierung bei Stake und BC.Game siehe den Provably Fair-Blackjack-Leitfaden.

Traditionelle RNG vs. Provably Fair RNG

Auf der RNG-Ebene speziell (nicht auf dem breiteren Fairness-Stack) ist PF eine strikte Obermenge von zertifiziertem CSPRNG.

Wo traditionelle RNGs zu kurz greifen

Zertifizierte RNGs von eCOGRA, iTech Labs und GLI sind alle kryptografisch sicher — die Mathematik ist genauso stark wie die von PF. Das Problem liegt nicht in der Primitive, sondern im Laufzeit-Vertrauensmodell:

• Der zertifizierte RNG läuft auf dem Server des Casinos, einmalig geprüft
• Du siehst seine Ausgabe nie direkt, nur den Endzustand des Spiels
• Nichts zwingt das Casino, den zertifizierten Code in der Produktion weiter zu nutzen
• Ein Streit pro Runde kann nicht in Echtzeit gelöst werden

Wenn Pragmatic Play's zertifizierter Slot-Engine bei Roobet still einen anderen RNG lädt als den, den eCOGRA getestet hat, fängt keine Zertifikatsprüfung das auf. Die Lücke schließt sich nur durch offene Verifizierung pro Runde.

Was PF zur Primitive hinzufügt

Provably Fair nimmt die gleiche kryptografische Grundlage und macht sie transparent. Konkret:

• Der Server-Seed-Hash wird vor deiner Wette veröffentlicht (Commitment)
• Dein Client-Seed trägt zur HMAC-Eingabe bei (Co-Signatur)
• Der Raw-Server-Seed wird nach der Runde offengelegt (Reveal)
• Die Berechnung ist deterministisch und in jedem Browser reproduzierbar (Verifizierung)

Das ist der ganze Unterschied. Gleiches HMAC, gleiche CSPRNG-Mathematik — mit vier zusätzlichen Transparenz-Schritten überlagert. Einen tieferen Überblick, wie beide Modelle sich vergleichen, findest du unter Provably Fair vs. RNG-zertifiziert.

Blockchain-Randomness — Chainlink VRF und Onchain-Spiele

PF RNG funktioniert gut für zentralisierte Krypto-Casinos. Aber was ist mit vollständig dezentralisierten Anwendungen — Onchain-Lotterien, NFT-Eigenschaftszuweisung, Onchain-Würfelspiele? Dort übernimmt eine andere Lösung.

Warum Blockchains keine sicheren Zufallszahlen generieren können

Jede Blockchain ist absichtlich deterministisch — jeder Validator muss aus den gleichen Eingaben den gleichen Zustand erzeugen, oder der Konsens bricht. Das macht Zufälligkeit strukturell schwierig:

• block.timestamp ist miner-steuerbar in einem Fenster von wenigen Sekunden
• block.blockhash kann von Minern durch Blockeinbehalt manipuliert werden
• block.prevrandao (Post-Merge Ethereum) ist besser, aber immer noch von Validatoren beeinflussbar
• Jede Onchain-Entropiequelle kann vom Smart Contract vor ihrer Nutzung gelesen werden und besiegt damit den Zweck

Naive dApp-Lotterien, die Blockhash nutzen, wurden in der Vergangenheit geleert. Der wirtschaftliche Anreiz, einen 1-Millionen-Dollar-Jackpot zu manipulieren, kann einen Miner rational veranlassen, einen Block einzubehalten.

Wie Chainlink VRF es löst

Chainlink VRF (Verifiable Random Function) generiert Zufälligkeit offchain und liefert sie mit kryptografischem Beweis onchain. Der Ablauf:

1. Der Smart Contract fordert eine Zufallszahl an
2. Der Chainlink-Orakel generiert den Wert offchain mit seinem privaten Schlüssel + Request-Seed
3. Der Beweis ist eine BLS-Signatur, die jeder gegen den öffentlichen Schlüssel des Orakels verifizieren kann
4. Sowohl der Wert als auch der Beweis werden in einer einzigen Transaktion onchain zurückgeposted
5. Der Contract verifiziert den Beweis, bevor er den Wert nutzt

Die kritische Eigenschaft: Weil der Beweis die Zufallszahl an den privaten Schlüssel des Orakels und den Request-Seed bindet, kann das Orakel keine bequemen Werte cherry-picken. Jede Abweichung ist mathematisch nachweisbar.

Wann VRF vs. HMAC-basiertes PF nutzen

Die meisten Krypto-Casinos nutzen 2026 immer noch HMAC-basiertes PF, weil es schnell, günstig und bereits gut verstanden ist. VRF ist, wo Onchain-DeFi, NFTs und vollständig dezentralisierte Gaming glänzen. Unsere Provably Fair Bitcoin-Spiele-Rangliste filtert speziell danach, welche PF-Implementierung jedes Casino nutzt. Wer diese Konzepte an einem echten Casino stresstesten möchte, findet im Provably-Fair-Verzeichnis Implementierungen, die sich ohne Einzahlung prüfen lassen — die meisten geben Server-Seed-Hashes über einen öffentlichen Endpoint preis.

Angriffsfläche von PF-RNGs

Ein kryptografisch perfekter PF-RNG kann durch fehlerhafte Implementierung immer noch kompromittiert werden. Hier ist, was die Mathematik überstehen kann.

Biased-Seed-Pool-Angriff

Der realistischste Angriff — und ein Grund, warum die Client-Seed-Rotation wichtig ist.

Ein unehrliches Casino generiert tausende Kandidaten-Server-Seeds im Voraus. Für jeden berechnet es die Ergebnisse gegen häufige Client-Seed-Muster (Standard-Browser-Formate, häufige Wörter). Es setzt nur Seeds ein, die zufällig mehr Verluste als Gewinne gegen vorhersehbare Client-Seeds produzieren.

Jeder eingesetzte Seed hasht immer noch korrekt zu seinem vorab festgelegten Hash. Die Commit-Reveal-Mathematik passt. Aber der Pool der verfügbaren Seeds wurde vor der Sicht eines Spielers handverlesen, und der langfristige Hausvorteil überschreitet stillschweigend die angegebene RTP.

Warum Rotation Das Besiegt

Biased-Seed-Angriffe erfordern, dass das Casino deinen zukünftigen Client-Seed vor dem Commitment des Server-Seeds kennt. Rotiere deinen Client-Seed alle 50–100 Einsätze und die Vorberechnung des Casinos wird nutzlos — sie committed sich zu einem Server-Seed, bevor sie den neuen Client-Seed kannte, also können sie Ergebnisse nicht steuern.

Deshalb lassen legitime Casinos dich sofort rotieren. Ein PF-Casino, das die Client-Seed-Rotation verweigert (oder den Client-Seed nach eigenem Zeitplan, nicht deinem, automatisch regeneriert), signalisiert, dass die Angriffsfläche offen ist. Der Client-Seed vs Server-Seed-Leitfaden deckt den vollständigen Rotations-Workflow ab.

Schwache Entropiequellen

Wenn die Server-Seed-Generierung vorhersehbare Entropie verwendet, läuft das Commit-Reveal-Protokoll trotzdem, aber der Angreifer kann Seeds vorhersagen.

Die Math.random-Falle

Javas Script Math.random() ist eine Variante eines linearen Kongruenzgenerators. Nach Beobachtung von ~700 aufeinanderfolgenden Ausgaben kann ein Angreifer den vollständigen internen Zustand rekonstruieren und jede nachfolgende Ausgabe vorhersagen. Wenn ein PF-Casino Math.random für die Server-Seed-Generierung verwendet:

1. Angreifer spielt 700+ Runden und sammelt jeden offenbarten Server-Seed
2. Angreifer rekonstruiert den PRNG-Zustand
3. Angreifer sagt den nächsten gehashten Server-Seed vor dem Commitment voraus
4. Angreifer wettet mit vollständiger Kenntnis des Ergebnisses

Prävention: Casinos müssen crypto.randomBytes(32) (Node.js), crypto.getRandomValues(new Uint8Array(32)) (Browser) oder Hardware-RNG verwenden. Der Unterschied ist eine Codezeile, aber die Sicherheitslücke ist total.

Implementation Red Flags

Kurze Checkliste von Signalen, dass ein PF-RNG nicht sicher ist:

• Keine Client-Seed-Rotations-Schaltfläche, oder Rotation dauert >5 Sekunden
• Client-Seed wird vom Casino nach eigenem Zeitplan automatisch regeneriert
• Server-Seed-Verlauf zeigt nicht den Algorithmus oder die Slice-Breite
• Verifikationstool funktioniert nur auf der Website des Casinos selbst (nicht lokal)
• Kein veröffentlichter Hash-Algorithmus — „SHA-256 irgendwo" ist nicht genug; du brauchst die genaue Formel
• Offenbarte Server-Seeds stimmen in keiner Runde mit ihren vorgegebenen Hashes überein

Jedes dieser Signale deutet darauf hin, dass die PF-Behauptung Marketinglack auf einem gewöhnlichen RNG ist. Für einen Vergleich, welche Casinos ihren PF-Code tatsächlich veröffentlichen, siehe die provably-fair-Bitcoin-Spiele-Ranking.

Selbst Ausprobieren — Interaktiver Verifizierer

Die Mathematik hört auf, abstrakt zu sein, sobald du sie auf deinen eigenen Seeds ausführst. Füge beliebige vier Werte aus dem Fairness-Panel deines Casinos in den Verifizierer unten ein — alles wird in deinem Browser über die Web Crypto API ausgeführt, keine Daten werden an unseren Server gesendet.

Ein praktischer Tipp: Wenn du keine echte PF-Casino-Wette zur Hand hast, versuche diese wegwerfbaren Testwerte, um eine verifizierte Runde zu sehen:

• Server-Seed-Hash: bf3c0a9b0f4b3c8e8f4f0c5f0c4e8b7d8f3e2a1c9f6e3b7c4d5a8e2f9b1c6d3a (nur Beispiel — stimmt nicht mit echten Hashes überein)
• Server-Seed: f4a9c2e1b7d8e3c5a1b9f6d2e8c4a7b3e9d1c6a2b5f8e4c7a3b6e1d9c2a5b8f4
• Client-Seed: demo-player
• Nonce: 1

Das Ergebnis zeigt ein PASS/FAIL-Urteil zum Hash-Match sowie die rekonstruierten Dice- und Crash-Ergebnisse. Die gleiche Logik läuft hinter dem Aviator-Provably-Fair-Rechner für Spribes Crash-Style-Spiel und unser vollständiger Verifizierer unter dem Provably-Fair-Hub deckt jedes Mainstream-PF-Casino ab. Um Wetten gegen eine bekannte RTP zu dimensionieren, nachdem du bestätigt hast, dass der RNG legitim ist, kombiniere es mit unserem RTP-Rechner, Hausvorteil-Rechner und Bankroll-Rechner.

Unterm Strich: Die Mathematik ist nur dann wasserdicht, wenn das Casino den Hash tatsächlich vor der Wette veröffentlicht. Prüfen Sie jede Implementierung anhand des Provably-Fair-Hubs — wir halten fest, ob der Seed korrekt festgesetzt wird und wo der Hash einsehbar ist.

Häufig gestellte Fragen