GH GambleHub

Hot/Cold Wallets und Zugriffsrichtlinien

1) Warum in Heiß/Warm/Kalt aufteilen

Ziel ist es, die Zahlungsgeschwindigkeit und die Sicherheit der Vermögenswerte auszugleichen:
  • Hot - operative Einlagen/Auszahlungen (T0/T + 1), minimale Verzögerungen, begrenzter Saldo.
  • Warm - Zwischenpools für Hot Refills und große regelmäßige Auszahlungen.
  • Kalt - langfristige Speicherung (Reserven/Treasury), so weit wie möglich vom Netzwerk isoliert.

Das Ergebnis: weniger Betriebsrisiken und vorhersehbare SLAs bei kontrollierter Exposition.


2) Speicherreferenzarchitektur

Schichten und ihre Rolle

Hot (online, automatisiert): Unterschreibt kleine/mittlere Auszahlungen innerhalb der Tageslimits. Schutz - HSM/KMS, Policy Engine, Alerts.
Warm (teilweise online/Hardware-Modul): Batch-Auszahlungen, Hot-Refill, erhöhte Limits, manuelle Bestätigung.
Kalt (offline/air-gapped): multisig/MRS; seltene Operationen, nach Verfahren mit physischem Zugriff und Protokoll.

Technologien

HSM/KMS für Hot/Warm-Schlüssel und Token;

Multisig m-of-n oder MPC für warm/kalt;

Policy Engine (Limits, 4-Augen, Listen zulässiger Adressen, Zeitfenster);

Private Relay/MEV-Schutz für große Transaktionen.


3) Zugriffsrichtlinie (Access Policy)

3. 1 Grundsätze

Kleinste Privilegien (PoLP): Zugriff exakt nach Rolle und Zone (hot/warm/cold).
Verantwortungsteilung (SoD): Verschiedene Personen/Dienste initiieren, genehmigen, unterschreiben, freigeben.
4-Augen: mindestens zwei unabhängige Genehmigungen für kritische Operationen (Limits, Adresslisten, warm→hot).
Isolierung von Konturen: prod ≠ stage; Netzwerk-ACLs, separate Anmeldeinformationen.

3. 2 Rollen

Operator (Zahlungen): Erstellt Auszahlungen/Batches innerhalb der Limits.
Approver (Treasury/Risk): Genehmigung über Schwellenwerte, Whitelist/Hold.
Custodian (Key Owner): Teilnahme an multisig/MRS für warm/cold.
Compliance: holds/EDD/SAR, Travel Rule/KYT Lösungen.
Sicherheit: HSM/KMS-Management, Schlüsselrotation, Vorfälle.


4) Limits und Guardrails

KonturTransaktionslimitTageslimitDop. Regeln
HotNiedrig/Mittel (X)Niedrig/Mittel (Σ X)Velocity unter Adresse/Netzwerk; Zeitfenster; 2-Faktor für manuelle
WarmMittel/Hoch (Y)Mittel/Hoch (Σ Y)4-Auge, Whitelist-Adressen, Release-Fenster Zeitplan
ColdSehr hoch (Z)Auf Beschluss des RatesPhysikalisches Quorum, Offline-Signatur, „Abklingzeit“

Whitelist/Denylist: Adressbuch mit TTL, KYT-Schwellenwerten und obligatorischem Eigentumsnachweis (für Unhosted).


5) Operative Ströme

5. 1 Nachschub heiß aus warm

1. Die Überwachung von 'hot _ balance <threshold' → einen Refill-Antrag.
2. TAC/Sanktionen an den Zieladressen → Sammlung von Batch.
3. Doppelte Zulassung (4-Augen), Unterschrift (warm multisig/MRS).
4. Übersetzung und Aufnahme in den Träger; alert über die Änderung von Limits.

5. 2 Auszahlungen von hot

Automatisch innerhalb der Per-tx- und Per-Day-Limits.
Bei Überschreitung - Eskalation im warm: Batch/Teilfreigabe + RBA-Check (SoF/KYT/Travel Rule).

5. 3 Rebalance warm↔cold

Periodisch (wöchentlich/nach Schwellenwert) oder auf Beschluss des Finanzministeriums; Offline-Signatur, zwei unabhängige Bestätigungskanäle, Protokoll.


6) Schlüsselsicherheit

Erzeugung und Speicherung: nur auf HSM/air-gapped; Verweigerung des Exports von privaten Schlüsseln.
Rotation: geplant (N Monate), ungeplant im Falle eines Vorfalls; dokumentierte Rückrufverfahren.
Backup/Shard-Management: Verschlüsselte Bälle (MPCs) an verschiedenen Orten/Gerichtsbarkeiten; regelmäßige Wiederherstellungstests.
Netzwerkperimeter: IP allow-list, mTLS, signierte Webhooks, Anomalieüberwachung.
Change-control: RFC zum Ändern von Policies/Limits, Änderungsprotokoll (immutable).


7) Compliance und Kontrolle

TAC/Sanktionen: Pre-Check am Eingang/Ausgang; unterschiedliche Risikoprofile über Netzwerke hinweg.
Travel Rule: Für VASP↔VASP - IVMS101, Replikate von Nachrichten und Lieferergebnisse.
RBA: Limits/Bestätigungen hängen vom Risikosegment und vom Betrag ab.
Audit: vollständiger Fußabdruck: wer/wann/was initiiert/genehmigt/unterzeichnet hat; Version der Regeln zum Zeitpunkt der Operation.
DSGVO/PII: Minimierung, Tokenisierung der ID, getrennte Speicherung von Payment PANs.


8) Beobachtbarkeit, Logs und Rekonsiliation

Lager: Mapping von 'invoice/withdrawal ↔ txid ↔ wallet (subaccount)' über das Netzwerk/Asset.
Sanierung T + 0/T + 1: Beträge, Provisionen, Kurs (Preisquelle, Zeitstempel), offene Salden.
Überwachung: Hot/Warm/Cold-Balance, Bestätigungsrate, Gebühren, abnormale Auszahlungen, Wechsel zu Backup-Netzwerken.
Alerts: Überschreitung von Limits/Velocity, neue Adressen außerhalb des Whitelists, Abstimmungsabweichungen.


9) Playbooks der Vorfälle

Hot Leak/Kompromittierung: sofortige Aufhebung der Limits auf Null, Übertragung von Salden auf warm/kalt, Schlüsselrotation, Untersuchung, Bericht an Aufsichtsbehörden/Partner.
Auszahlungsanomalien: Batcha-Freeze, KYT-Re-Check, SoF-Anfrage, Teilfreigabe des sicheren Teils.
Network/fee-storm degradation: auto switch-over to backup network/method, ETA update in UI.
Unzugänglichkeit des Custody/RPC-Anbieters: Failover, manuelle Freigabe kritischer Auszahlungen über warm, Post-Incident-Analyse.
Nicht autorisierte Richtlinienänderung: automatisches Rollback, SecOps/Compliance-Benachrichtigung, Prüfbericht.


10) Metriken und OKRs

Sicherheit/Compliance

Anteil der Vermögenswerte in cold/warm/hot (Zielbereiche), Anzahl der Grenzverletzungen.
KYT reject%, sanktionierte Treffer, SAR-Konvertierung (falls zutreffend).
Anzahl der Richtlinienänderungen/Monat, erfolgreiche/abgelehnte Erhöhungsanträge.

Zuverlässigkeit/Betrieb

Time-to-Payout p50/p95 für heiße/warme Routen.
Die Häufigkeit der Auffüllung ist heiß, die durchschnittliche Auffüllungsgröße.
Prozentsatz der Auto-Auszahlungen vs manuell, Vorfälle/Quartal.

Wirtschaft/UX

Kosten per Approved (All-in über das Netzwerk/Asset), Gebührenprozentsatz des Betrags.
Netzwerk-/Memo-/Tag-Fehler, Anzahl der partiellen Freigaben, Zeitverzögerungstickets.


11) Anti-Muster

Überfüllte heiße Geldbörsen ohne harte Tagescaps.
Ein Depotanbieter/ein Netzwerk ohne Reserve → SPOF.
Keine 4-Augen und SoD auf warm/kalt Betrieb.
Schlüssel ohne HSM/KMS, keine regelmäßige Rotation/Recovery-Tests.
Kein Whitelist/TTL und KYT vor dem Rückzug - erhöhtes Risiko.
Limits „per Messenger“ ohne RFC/Audit ändern.
Fehlende Idempotenz und Anti-Takes bei Retrays - doppelte Abschreibungen.


12) Checkliste Umsetzung (kurz)

  • Layer-Matrix: hot/warm/cold mit per-tx/per-day Limits und Asset-Shares.
  • Rollen und SoD: Operator/Approver/Custodian/Compliance/Security, 4-eye.
  • HSM/KMS für heiß/warm, multisig/MRS für warm/kalt, offline signiert.
  • Whitelist/Denylist-Adressen mit TTL, KYT-Schwellen, Eigentumsnachweis.
  • Prozesse: Hot-Nachschub, Batch-Auszahlungen aus warm, Rebalance in cold.
  • Beobachtbarkeit: Leiger, Rekonsilation T + 0/T + 1, Warnhinweise für Überschreitungen.
  • Incident Playbooks: Kompromittierung, Netzwerkdegradation, Anbieterunverfügbarkeit.
  • Travel Rule/IVMS101, RBA-Richtlinien, Audit-Änderungen.
  • Idempotenz, Anti-Takes, Backoff + Jitter; signierte Webhooks.
  • Regelmäßige Schlüsselwiederherstellungstests und Störfallübungen.

13) Zusammenfassung

Die richtige Hot/Warm/Cold-Strategie ist nicht nur eine „Drei-Geldbörse“, sondern ein Risiko- und Zugriffsmanagement-Modus: Limits und 4-Augen, HSM/KMS und Multisig/MRS, KYT/Travel Rule und RBA, klare Auffüllungs- und Auszahlungsverfahren, Beobachtbarkeit und Playbooks. Diese Kontur ermöglicht schnelle Auszahlungen von hot mit minimaler Asset-Exposition und Störfestigkeit - die Grundlage für eine sichere und profitable iGaming-Zahlungsinfrastruktur.

Contact

Kontakt aufnehmen

Kontaktieren Sie uns bei Fragen oder Support.Wir helfen Ihnen jederzeit gerne!

Integration starten

Email ist erforderlich. Telegram oder WhatsApp – optional.

Ihr Name optional
Email optional
Betreff optional
Nachricht optional
Telegram optional
@
Wenn Sie Telegram angeben – antworten wir zusätzlich dort.
WhatsApp optional
Format: +Ländercode und Nummer (z. B. +49XXXXXXXXX).

Mit dem Klicken des Buttons stimmen Sie der Datenverarbeitung zu.