> ## 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. # Mines-Fairness > Wann das Spielfeld festgelegt wird, wie es abgeleitet wird und was das Programm beim Abrechnen erneut prüft. Ein Mines-Spielfeld steht fest, bevor du auch nur ein einziges Feld wählst. Die Eröffnungstransaktion legt sich per Commit auf den SHA-256-Hash eines zufälligen Server-Seeds fest und erfasst einen Solana-Slot-Hash – und das Spielfeld ist eine reine Funktion aus beidem. Bei der Abrechnung leitet das Programm das gesamte Spielfeld on-chain neu ab und lehnt jede Abrechnung ab, die nicht dazu passt. Diese Seite erklärt den genauen Mechanismus hinter jedem [Mines](/de/docs/games/mines)-Spielfeld: was wann per Commit festgelegt wird, wie das Spielfeld exakt abgeleitet wird, was das Programm bei der Abrechnung erneut prüft und wo die ehrlichen Grenzen des Verfahrens liegen. Hintergrund: [Provably Fair – Überblick](/de/docs/provably-fair/overview). ## Was wann festgelegt wird Ein Mines-Spiel beginnt mit einer einzigen On-Chain-Transaktion (`mines_start`), die drei Dinge gleichzeitig erledigt – **bevor du irgendein Feld wählst**: 1. **Sie legt den Beitrag des Betreibers per Commit fest.** Das Backend erzeugt einen zufälligen 32-Byte-`server_seed`, und die Transaktion speichert dessen SHA-256-Hash – den Commit. Der Seed selbst bleibt bis zum Spielende verborgen. 2. **Sie erfasst Entropie aus der Chain.** Das Programm liest den neuesten Slot-Hash aus Solanas `SlotHashes`-Sysvar und speichert ihn im Spiel. 3. **Sie friert die Konditionen ein.** Hausvorteil, Auszahlungsobergrenze und Rückerstattungs-Timeout werden als Snapshot in deinem Spiel gespeichert; nichts kann ein Spielfeld neu bepreisen, auf dem du bereits spielst. Das Spielfeld ist eine reine Funktion aus dem festgelegten Seed, dem gespeicherten Slot-Hash, deinem Konto und deinem Spielzähler. **Ab diesem Moment steht das Spielfeld fest**: Die Minen können sich nicht als Reaktion auf deine Züge verschieben. Während des Spiels werden aufgedeckte Felder off-chain ausgeliefert (genau das macht sie so schnell); am Ende deckt die Abrechnungstransaktion den Seed auf, und das Programm **leitet das gesamte Spielfeld on-chain neu ab** und lehnt jede Abrechnung ab, die nicht dazu passt.

Wie wird das Mines-Spielfeld abgeleitet?

Die 25 Felder sind von 0 bis 24 durchnummeriert, Zeile für Zeile im 5×5-Raster (`index = row × 5 + column`). Das Spielfeld ist eine 25-Bit-Maske: Ist Bit `t` gesetzt, verbirgt Feld `t` eine Mine. ```text theme={null} Eingaben server_seed 32 Bytes Seed des Betreibers, bei Spielstart als sha256(server_seed) festgelegt slothash 32 Bytes neuester Solana-Slot-Hash, wenn die Start-Transaktion ausgeführt wird user 32 Bytes die Adresse deines On-Chain-Nutzerkontos nonce 8 Bytes dein Mines-Spielzähler, Little-Endian mines_count 1..24 die Anzahl der Minen, die du gewählt hast Zufallsstrom: SHA-256-Blöcke, je 4 Bytes auf einmal verbraucht block(k) = sha256( server_seed ‖ slothash ‖ user ‖ nonce ‖ "mines" ‖ k ) // "mines" = 5 ASCII-Bytes; k = Blockzähler 0, 1, 2, … als 8 Bytes Little-Endian next_u32() = die nächsten ungelesenen 4 Bytes des aktuellen Blocks, Big-Endian; ist ein Block aufgebraucht, weiter mit block(k+1) unverzerrte Ziehung in 0..bound (Rejection Sampling, keine Modulo-Verzerrung) draw(bound): zone = 4294967295 − (4294967295 mod bound) wiederhole v = next_u32() bis v < zone gib v mod bound zurück Spielfeld: partieller Fisher–Yates-Shuffle tiles = [0, 1, …, 24] mine_mask = 0 for i in 0..mines_count: j = i + draw(25 − i) tausche tiles[i] und tiles[j] mine_mask = mine_mask OR (1 << tiles[i]) ``` Details, auf die es beim Nachrechnen ankommt: * Die Reihenfolge der Hash-Eingaben ist exakt: Seed, Slot-Hash, Adresse des Nutzerkontos, Nonce (**8 Bytes Little-Endian**), der ASCII-Tag `"mines"`, dann der Blockzähler (**8 Bytes Little-Endian**, beginnend bei 0). * Jeder 4-Byte-Abschnitt wird **Big-Endian** gelesen. Ein Block liefert höchstens 8 Ziehungen; bei Bedarf wird der Strom mit dem nächsten Zählerwert nachgefüllt. * Die Rejection-Sampling-Schleife macht jede Ziehung exakt gleichverteilt: Am Shuffle gibt es keine Verzerrung, über die man streiten könnte.

Welche Auszahlungsformel setzt das Programm durch?

Jedes sicher aufgedeckte Feld multipliziert deinen Cashout mit dem exakten Kehrwert deiner Überlebenswahrscheinlichkeit, wobei der Hausvorteil genau einmal angewendet wird: ```text theme={null} k−1 Multiplikator = (1 − Hausvorteil) × product ( (25 − i) / (25 − M − i) ) i=0 M = Anzahl der Minen, k = Anzahl der aufgedeckten sicheren Felder ``` Das Programm berechnet dies mit exakter Ganzzahlarithmetik und einer einzigen abschließenden Abrundungsdivision (die Rundung, höchstens ein Basispunkt, fällt zugunsten des Hauses aus). Beim aktuellen Hausvorteil von 1.5%: | Spielfeld | Multiplikator | | - | - | | 3 Minen, 1 Feld aufgedeckt | 1.1193x | | 3 Minen, 2 Felder aufgedeckt | 1.2792x | | 24 Minen, 1 Feld aufgedeckt | 24.625x | | 1 Mine, alles abgeräumt (24 Felder aufgedeckt) | 24.625x | Die erwartete Rendite beträgt `1 − Hausvorteil` für jede Kombination aus Minen und aufgedeckten Feldern. Die aktuellen Werte findest du unter [Gebühren und Limits](/de/docs/fees-and-limits). ## Was das Programm bei der Abrechnung durchsetzt Die Abrechnungstransaktion (`mines_settle`) deckt den `server_seed` auf und beansprucht ein Ergebnis: einen Cashout mit einer Menge aufgedeckter Felder oder einen Minentreffer auf einem bestimmten Feld. Das Programm prüft dann alles on-chain: * `sha256(server_seed)` muss dem bei Spielstart gespeicherten Commit entsprechen; mit einem anderen Seed lässt sich das Spiel nicht abrechnen. * Das Spielfeld wird mit der obigen Formel **von Grund auf neu abgeleitet**. Ein als aufgedeckt gemeldetes Feld, das tatsächlich eine Mine ist, wird abgelehnt; ein gemeldetes Minenfeld, das keine Mine ist, wird abgelehnt; ein Minenfeld, das zugleich als aufgedeckt gemeldet wurde, wird abgelehnt. * Der Multiplikator wird on-chain aus dem **per Snapshot eingefrorenen** Hausvorteil und deiner tatsächlichen Anzahl aufgedeckter Felder berechnet, sodass die Auszahlung nicht falsch gemeldet werden kann. * Das Abrechnungs-Event veröffentlicht dauerhaft den Seed, den Slot-Hash, die vollständige Minenmaske, deine aufgedeckten Felder und das Ergebnis. ## Was garantiert ist – und was nicht **Vom Programm durchgesetzt:** * Das Spielfeld steht vor deinem ersten Zug fest – durch den Commit plus den gespeicherten Slot-Hash. Minen können sich mitten im Spiel nicht verschieben. * Bei der Abrechnung kann der Betreiber über das Spielfeld nicht lügen: Ein falscher Seed, eine als sicher gemeldete Mine oder ein vorgetäuschter Minentreffer lassen die Transaktion scheitern. * Die Konditionen, mit denen du gestartet bist (Hausvorteil, Auszahlungsobergrenze, Timeout), gelten bis zum Ende des Spiels. * Dein Einsatz kann niemals gesperrt werden: Rechnet der Betreiber nie ab, kann nach dem Timeout des Spiels **jeder** den Abbruch auslösen, der dir deinen Einsatz zurückerstattet. Im Normalbetrieb kommt es nie so weit: Ein verlassenes Spielfeld wird vor dem Timeout zum aktuellen Multiplikator ausgecasht (siehe [Mines](/de/docs/games/mines)), sodass du deine Gewinne behältst und nicht nur deinen Einsatz. Der für jeden aufrufbare Abbruch ist die darunterliegende Garantie für den Fall, dass der Betreiber nicht mehr da ist. **Die ehrlichen Einschränkungen:** * **Der Betreiber kennt das Spielfeld, während du spielst.** Das ist strukturell bedingt und kein Fehler dieses speziellen Designs: Aufgedeckte Felder werden sofort off-chain ausgeliefert, und wer sie ausliefert, muss wissen, wo die Minen liegen. Kein Zufallsverfahren ändert daran etwas: Selbst ein per VRF erzeugtes Spielfeld wäre dem Betreiber in dem Moment bekannt, in dem er dein erstes Feld aufdeckt. Was der Commit garantiert: Dieses Wissen kann weder dazu genutzt werden, das Spielfeld zu *verändern*, noch das Ergebnis *falsch zu melden*. * **Zeitpunkt des Starts.** Das Spielfeld hängt vom Slot-Hash ab, der beim Start deines Spiels erfasst wird, und die Start-Transaktion wird vom Backend eingereicht – dieselbe Timing-Überlegung wie bei den anderen Spielen. Ein Spielfeld im Voraus zu kennen hilft nur, wenn deine Züge vorhersehbar sind; wenn du variierst, wo du klickst, läuft eine timingbasierte Spielfeldauswahl ins Leere. * **Annullierungen.** Der Betreiber kann ein laufendes Spiel abbrechen (grundsätzlich auch eines, das du gerade gewinnst). Ein Abbruch **erstattet den vollen Einsatz zurück** (einen Einbehalt gibt es nicht) und löst immer ein öffentliches Event aus, sodass jeder die Häufigkeit von Annullierungen on-chain nachprüfen kann. * Jedes Spiel muss einen frischen Seed verwenden: Ein aufgedeckter Seed ist öffentlich, und seine Wiederverwendung würde das nächste Spielfeld öffentlich ableitbar machen. Das Programm lehnt eine direkt aufeinanderfolgende Wiederverwendung on-chain ab, und das Backend erzwingt globale Eindeutigkeit.

Wie überprüfst du ein Mines-Spiel?

Das Abrechnungs-Event (`MinesGameSettled`) in der letzten Transaktion deines Spiels enthält `server_seed`, `slothash`, `user`, `nonce`, `mines_count`, `mines_mask`, `revealed_mask`, `bust_tile`, `multiplier_bps` und `is_win`. So überprüfst du es: 1. Prüfe den Commit: `sha256(server_seed)` muss dem `commit_hash` entsprechen, der in der Start-Transaktion deines Spiels veröffentlicht wurde (Event `MinesGameStarted`) – das beweist, dass das Spielfeld vor deinem ersten Zug festgelegt war. 2. Leite die Minenmaske mit der obigen Formel neu ab und vergleiche sie mit dem `mines_mask` des Events. 3. Prüfe das Ergebnis anhand der Maske: Jedes Bit von `revealed_mask` muss ein sicheres Feld sein, und ein Minentreffer muss auf einer Mine liegen. 4. Prüfe den Multiplikator mit der Auszahlungsformel. Allgemeine Hinweise zum Auslesen von Event-Daten in einem Explorer findest du unter [Eine Runde überprüfen](/de/docs/provably-fair/verify-a-round). Wie das Spiel selbst gespielt wird, erfährst du in der [Mines-Spielanleitung](/de/docs/games/mines).