GH GambleHub

Gesamtliquidität im Netz

(Abschnitt: Ökosystem und Netzwerk)

1) Was ist „Gesamtliquidität“ und warum wird sie benötigt

Die Gesamtliquidität ist die Gesamtheit der über Knoten/Ketten/Zahlungsschienen verteilten monetären und tokenisierten Vermögenswerte, die den Netzteilnehmern (Betreiber, Anbieter, Studios, Zahlungs-/KUS-Anbieter, Affiliates) nach vorhersehbaren Regeln zur Verfügung stehen. Die Ziele sind:
  • Geschwindigkeit und Vorhersagbarkeit von Auszahlungen/Überweisungen bei minimalem RTO/RPO.
  • Effizienter Kapitaleinsatz: weniger „Totalguthaben“ und Doppelrückstellung.
  • Interoperabilität zwischen Domänen: Brücken, Banken, PSPs, Stables, On/Off-Ramp.
  • Kontrollierte Risiken: Grenzen, Puffer, Versicherung, Überwachung.

2) Liquiditätsmodelle

2. 1 Zentralisiert (custodial hub)

Ein einziger „Liquidity Hub“ hält Pools nach Region/Währung/Kette. Einfach zu implementieren, aber höhere Kontrahentenrisiken und SPOF-Risiken. Geeignet für Start/kleine Netzwerke.

2. 2 Dezentral (Pools nach Domains)

Die Liquidität wird von vielen Anbietern/Market Makern (MMs) gehalten, der Austausch erfolgt über Smart Contracts/Channels. Höhere Nachhaltigkeit, wir brauchen fortgeschrittenes Routing und On-Chain-Regeln.

2. 3 Hybrid (empfohlen)

Hubs für kritische Währungen/Auszahlungen + externe MM/Brücken zur Skalierung. Management - durch die Politik der Grenzen, Sicherheiten und Versicherungsfonds.

3) Topologie und Objekte

Liquiditätspools (LP): 'LP {Domain, Currency/Asset}' mit den Attributen: Saldo, Puffer, Limits, Kapitalkosten (CoC), Provision.
Kreditlinien (CL): bilaterale/multilaterale Grenzen mit Sicherheiten und Preis pro Nutzung.
Bridges: Mechanik lock/mint/burn/release oder messaging-only + netting.
Routing-Kanten: Gültige Transferpfade (on-us, zwischen LP, über Bridge/Bank/PSP).
Versicherungsfonds: Deckt Defizite innerhalb der Politik ab.

4) Schlüsselmetriken und Formeln

Liquidity Depth (LD) - verfügbares Volumen im Pool am Horizont 'T':
  • `LD_T = Balance_T - Reserved_T`
  • Utilization (U) - Pool-Auslastung:'U = Used/( Balance) '
Coverage Ratio (CR) - Abdeckung des 95. Perzentils der Nachfrage:
  • „CR = Available/ P95 (Demand_T)“ (Ziel ≥ 1. 5×)
Buffer% (BUF) - Versicherungspuffer zum Tagesnettofluss:
  • `BUF = Buffer / P95(NetFlow_daily)`
  • Rebalance MTTR - Median der Schließzeit des Ungleichgewichts nach dem Auslöser.
  • Cost-to-Serve (CTS pro $) - Gesamtgebühr/Gas/Spread pro $ Transfer.
  • Payout SLA Hit Rate - Anteil der Auszahlungen ≤ Zielminute/Blöcke.
Slippage/Quote Error —Zitat − tatsächlicher Preis/ Zitat.

SLO (Benchmarks): Payout SLA Hit ≥ 98-99%; CR ≥ 1. 5×; Rebalance MTTR ≤ 30 min; CTS per $ ↓ QoQ um 10-15%.

5) Routing (SOR - Smart Order Routing)

5. 1 Ziel

Wählen Sie einen Weg mit minimalen Gesamtkosten und Risiko, während Sie SLA/Limits einhalten.

5. 2 Wegekosten

`TotalCost = Fee + Gas + Slippage + LiquidityPenalty + TimePenalty + RiskAdj`

LiquidityPenalty: Strafe für U> 70% oder CR <Ziel.
TimePenalty: für die prognostizierte Finalisierung/das Fenster des Streits.
RiskAdj: Sanktions-/Landes- und Gegenparteirisiken.

5. 3 Taktik

Split Routing: Teilen Sie große Übersetzungen über mehrere LPs/Brücken auf.
Pre-funding: LP-Vorladung in Spitzenzeiten.
Quote Locking: Fixieren Sie den Preis für ein kurzes Fenster mit einem dynamischen Aufschlag bei niedrigem CR.
Retry/alt-path: Idempotente Wiederholungen entlang redundanter Pfade bei Degradation.

6) Provisionen und Preisgestaltung

Basisgebühr (bps) + Prioritätsgebühr bei hohen SLAs.
Dynamische Verbreitung: wächst bei U> 80% oder hoher Volatilität.
Tiering: unten für „gute Bürger“ -Netzwerke (geringes Risiko, stabile Umsätze).
Negative fee promo: um eine Richtung mit Liquiditätsengpässen zu stimulieren (rebalance by demand).

7) Liquiditätsrebalance

7. 1 Auslöser

Schwellenwert: "U> 80%" oder "CR <1. 2`.
Prognose: Spitzen der erwarteten Nachfrage (ML/Saisonalität).
Event: Sperren/Gabeln/Provisionswachstum in der Zieldomäne.

7. 2 Strategien

TWAP/VWAP-Überläufe: gleichmäßig über Zeit/Volumen.
Atomic Swap über Bridge/DEX (für Token).
Netting: Clearing der gegenseitigen Verpflichtungen am Ende des Fensters (Stunde/Tag).
Rebalance-Auktionen: Externe MMs schließen die Unwucht zum Auktionspreis.
Cross-currency hedge: Absicherungsgeschäfte zur Stabilisierung des USD-Äquivalents.

7. 3 Prioritätspolitik

Geld/Auszahlungen> kritische Betriebsüberweisungen> Sonstige.

8) Risikomanagement

Run-Risiken: Anstieg der Anträge auf Auszahlung → Geschwindigkeitsbegrenzungen, dynamischer Spread, vorübergehende Verlängerung des SLA.
Konzentration: Expositionslimit pro Kontrahent/Kette/Bank.
Jurisdiktionen und Sanktionen: Listen, Geo-Beschränkungen, Off-Ramp mit KYC/KYB.
Technologisch: Brückenausfall/PSP, steigende Gaspreise, Rückstände/Streitfenster.
Operativ: Schlüssellecks, fehlerhafte Asset-Mappings, falsche Zitate.
Versicherung: Risikofonds + Rückversicherung; transparente Beschichtungspolitik.

9) Inter-Chain-Liquidität und Brücken

Vertrauensmodell: vorzugsweise Light-Client/ZK für Geld; optimistic - mit vergrößertem Fenster.
Liquidity Networks: Kanäle/MM mit HTLC/garantierten Quittungen.
Stable-Pooling: ein einheitliches kanonisches Register von Vermögenswerten, Bilanzierung von Entscheidungen, Adressen, Kursen.
Brücken-Netting: Batch-Clearing zur Reduzierung von Gaskosten und Zeit.

10) Compliance und Audit

KYC/KYB für Einflussrollen und große Limits.
AML/Sanktionen vor und nach der Übersetzung (Velocity/Verhaltensfilter).
Prüfung von Logs und Config: Signaturen, unveränderliche Entscheidungsregister.
Datenresidenz/PII: Verschlüsselung, Pseudonymisierung, getrennte Schaufenster.

11) Beobachtbarkeit, SLO und Dashboards

SLI (Beispiel):
  • p50/p95 Time-to-Payout, Success-Rate, CTS per $, Utilization%, CR, Backlog, Rebalance MTTR, Quote Error, Liquidity Utilization of pool.
SLO (Beispiel):
  • Payout p95 ≤ 5 min (Internet - ≤ des Finalisierungsfensters), Success-Rate ≥ 99. 5%, CR ≥ 1. 5×, Relay/Bridge availability ≥ 99. 9%.
Dashboards:
  • Ops (час): Success-Rate, p95 TTP, U%, CR, backlog, burn-rate SLO.
  • Liquidität & Kosten (Tag): TVL/Net-flow nach Domains, CTS pro $, Honorareinnahmen, Versicherung.
  • Risiko (Woche): Expositionen, Sanktionshits, Near-Run-Indikatoren, Brückenausfall.

12) Beispielkonfigurationen (Pseudo-YAML)

Richtlinien für Pools und Limits

yaml liquidity:
pools:
- id: "LP:EU:EUR"
min_buffer_pct: 60 max_utilization_pct: 85 rebalance_threshold:
cr_min: 1. 3 utilization_max: 0. 80 fees_bps:
base: 8 priority: 5
- id: "LP:TR:TRY"
min_buffer_pct: 70 max_utilization_pct: 80 credit_lines:
- from: "LP:EU:EUR"
to:  "LP:TR:TRY"
limit: 2_000_000 collateral: "USDC"
rate_bps_daily: 1. 5 bridges:
- pair: ["ETH", "Polygon"]
finality:
mode: light_client confirmations: 20 rate_limits:
per_minute: 300 per_hour: 12000

SOR-Optionen

yaml routing:
split_max_parts: 4 risk_adjustments:
utilization_penalty_bps: 25 # for every% over 70%
cr_penalty_bps: 50       # за CR<1. 2 time_penalty_ms_per_min: 5 prefer_paths: ["on-us", "light-client", "mm-auction"]

13) Beispielabfragen (Pseudo-SQL)

Laden und Abdecken

sql
SELECT pool_id,
AVG(utilization) AS u_avg,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY demand_daily) AS p95_demand,
AVG(available) / NULLIF(PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY demand_daily),0) AS cr
FROM liquidity_snapshots
WHERE ts >= now() - INTERVAL '30 days'
GROUP BY pool_id;

Auszahlungs-SLAs

sql
SELECT date_trunc('hour', finished_at) AS h,
100. 0 AVG(CASE WHEN EXTRACT(EPOCH FROM (finished_at - created_at)) <= sla_sec THEN 1 ELSE 0 END) AS payout_sla_hit
FROM payouts
WHERE created_at >= now() - INTERVAL '7 days'
GROUP BY 1;

CTS per $

sql
SELECT date_trunc('day', ts) AS d,
SUM(fees + gas + slippage_cost) / NULLIF(SUM(amount_usd),0) AS cts_per_usd
FROM transfers_costs
WHERE ts >= current_date - INTERVAL '30 days'
GROUP BY 1;

14) Betriebsvorschriften

Täglich: Abstimmung der LP-Residuen, CR/U/MTTR-Bericht, automatische Rebalance nach Peak-Zeitplan.
Wöchentliches Komitee: Anpassung von Limits, Gebühren, Routen; Analyse von CTS und Fehlern.
SEV-Vorfälle: Ein einziger „Stopp-Kran“ für Domain-Paare, öffentlicher Status, Post-Mortem ≤ 72 Stunden.
Schlüssel- und Config-Rotation: Signaturen, Timelock, Rollbacks.

15) Playbook der Vorfälle

CR sinkt <1. 2 und Backlog wächst

Aufnahme von TWAP-Prioritätsbilanzen, Anhebung der Provisionen/Spreads, Aufnahme von Split-Routing; betroffene Partner mit ETA zu benachrichtigen.

Run-Szenario (Massenergebnisse)

Geschwindigkeits-/Quotenlimits aktivieren, SLA-Fenster vorübergehend vergrößern, Versicherungsfonds und MM-Auktion aktivieren.

Brückenausfall/Wachstum der Finalisierung

Wechseln Sie zu einem alternativen Pfad (messaging-only + netting oder backup bridge), heben Sie K-Bestätigungen an, aktualisieren Sie Zitate.

Sanktionen/AML-Auslöser

Einfrieren der entsprechenden Pools/Destinationen, manuelle Revue, Compliance-Bericht, Aktualisierung der Scoring-Regeln.

Fehler beim Asset/Kurs-Mapping

Handelsstopp für den Vermögenswert, Rollback des Verzeichnisses, Neuberechnung der affektierten Übersetzungen, öffentliche Notiz.

16) Checkliste Umsetzung

1. Beschreiben Sie Pools/Limits/Puffer und minimale CRs nach Domäne.
2. Aktivieren Sie SOR unter Berücksichtigung der vollen Pfadkosten und Risiken.
3. Konfigurieren Sie Rebalance (Schwellenwert + TWAP/VWAP) und Netting.
4. Definieren Sie SLI/SLO (Ausschüttungs-SLA, CR, MTTR, CTS) und Dashboards.
5. Starten Sie einen Versicherungsfonds und MM-Auktionen für Defizite.
6. Genehmigung der Compliance Policy (KYC/KYB/AML/Sanktion).
7. Führen Sie Chaos- und Stresstests durch (Run, Brückenausfall, Gasspritzen).
8. Überprüfen Sie regelmäßig Provisionen, Routen und Limits.

17) Glossar

LP (Liquidity Pool) ist ein Liquiditätspool in einer Domäne/Währung.
CR (Coverage Ratio) ist der Deckungsgrad des Bedarfs durch den Pool.
U (Utilization) ist der Anteil der verwendeten Liquidität.
SOR (Smart Order Routing) - Intelligentes Routing von Zahlungen/Transfers.
TWAP/VWAP - Strategien für einen reibungslosen Überlauf in Zeit/Volumen.
CTS per $ - Kosten für die Übersetzung.
Run-risk - Risiko eines massiven Liquiditätsentzugs.
Netting - Clearing gegenseitiger Verpflichtungen durch Schlachten.

Fazit: Die Gesamtliquidität ist ein verwaltetes System von Regeln, Pools und Routen, bei denen das Kapital effizient arbeitet und Auszahlungen schnell und vorhersehbar erfolgen. Durch die Kombination von hybrider Topologie, SOR, dynamischen Provisionen, strengen SLOs und Rebalance-Disziplin erhält das Ökosystem eine nachhaltige, skalierbare und wirtschaftlich optimale Netzliquidität.

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.