Teilnehmerkarte des Ökosystems

(Abschnitt: Ökosystem und Netzwerk)

1) Warum Sie eine Teilnehmerkarte benötigen

Die Teilnehmerkarte ist ein allgemeines Who-is-who-Modell im Ökosystem: Rollen, Beziehungen, Rechte, Haftungsgrenzen und Compliance-Konturen. Es beseitigt die Vielfalt der Begriffe, beschleunigt das Onboarding von Partnern, vereinfacht die Verfolgung von Vorfällen und erhöht die Verwaltbarkeit des Netzwerks (Governance, Risiko, Sicherheit, Entwicklung).

2) Taxonomie der Rollen (obere Ebene)

1. Betreiber sind Marken/Plattformen, die die Kundenerfahrung besitzen.
2. Content Provider (Studios/Content Provider) - Slots, Live-Spiele, Sport-Feeds, Mini-Spiele.
3. Payment Provider (PSP/On-Off Ramp) - Karten, APM, Stables, Krypto-Wallets.
4. Identifikation und Risiko (KYC/KYB/AML/Trust) - Verifizierung, Scoring, Sanktionsfilter.
5. Infrastruktur/Netzwerk (Nodes/Relays/Edge/CDN/Bridges) - Transport, Routing, Cross-Chain-Kommunikation.
6. Affiliates/Aggregatoren/Traffic - Lead-Quellen, Schaufenster, Mediennetzwerke.
7. Analytik und Daten (DWH/BI/Anti-Fraud) - Beobachtbarkeit, Reporting, Simulation.
8. Communities und DevRel sind Entwickler, Integratoren, Partnerteams.
9. Aufsichtsbehörden und Auditoren (B2G) - Lizenzen, Inspektionen, Berichte.
10. Governance und Treasury - Regeln, Budgets, Zuschüsse.
11. Affiliate Broker/Market Places - Austausch von Verkehr, Liquidität, Integrationen.

3) Unterrollen und Objekte (Detail)

Betreiber: B2C-Marke, White-Label, regionaler Sub-Betreiber, PSP-Router.
Studios/Anbieter: RGS, Live-Studio, Turnier- „Läufer“, Sport-Feed-Anbieter.
PSP: Karten-Acquiring, lokales APM (Papara, Mefete, etc.), Krypto-Processing, Risikoregel-Anbieter.
KYC/KYB/AML: KYC-Anbieter, Sanktionslistenquelle, PEP/Adverse Media-Anbieter, Behavioral Scoring.
Infrastruktur: Validator/Node, Super-Node/Relay, Bridge (light/optimistic/ZK), CDN/Edge-Cache.
Verkehr/Medien: Schaufenster, Arbitrage, Influencer-Netzwerk, Retargeting-DSP, CRM-Partner.
Daten: Blockchain-Indexer, CDC-Konnektor, Anti-Betrug DSS, BI.
Community: SDK contributor, integrator, local representative/ambassador.
B2G: Regulierungsbehörde, Steuerberichterstattung, Wirtschaftsprüfung (extern/intern).
Governans/Treasury: Protokollrat, Delegierte, Zuschussausschuss.
Broker: Aggregator von Integrationen (API-Markt), Austausch von Verkehr/Liquidität.

4) Vertrauens- und Identitätsmodelle

Rechtliche Identität: KYB (reg. Nummer, Land, Begünstigte), Lizenzen/Genehmigungen.
Technische Identität: 'org _ id', 'peer _ id' (ed25519/secp256k1), X.509 (mTLS), Adressen/Wallets.
Vertrauensstufen (Trust Tiers): T0 (öffentlich), T1 (mit Basiszertifizierung), T2 (erweiterte Verifizierung + Einzahlungen), T3 (kritische Rollen/Brücken).
Schlüsselrichtlinie: Organisationsstammschlüssel + Sitzungsschlüssel; Rotation/Widerruf, Protokoll der vertrauenswürdigen Schlüssel.

5) Interaktionsmatrix (B2B/B2C/B2G)

Operator ↔ Provider: Inhalte, Limits, Turniere, Abrechnung, SLA.
Operator ↔ PSP/KYC: Einzahlungen, Auszahlungen, Verifizierung, Chargebacks.
Operator ↔ Affiliates: Leads, Zuschreibungen, Auszahlungen, QoT.
Provider ↔ Network/Infra: Verteilung, Verzögerungen, Finalisierung.
Governance ↔ Alles: Regeln, Abstimmungen, Zuschüsse.
Regulator/Audit ↔ Operator/PSP: Berichte, Inspektionen, Vorfälle.
Data/BI ↔ Alles: Ereignisdiagramme, Schaufenster, Privatsphäre.

Verknüpfungstypen: Daten (Ereignisse), Aufrufe (RPC/API), Wert (Zahlungen/Vermögenswerte), Vertrauen (Schlüssel/Signaturen), Management (Proposal/Lösungen).

6) Teilnehmer-Lebenszyklus (Lifecycle)

1. Onboarding: Registrierung, KYB, Lizenzprüfung, Hochladen von Dokumenten, Generierung von 'org _ id', Schlüsselfreigabe.
2. Technische Integration: Sandbox → Bühne → Canary → Produktion, Testfälle, Signatur der ersten Ereignisse.
3. Aktivierung: SLO-Ziele, Quoten/Limits, Aufnahme in Pools (Verkehr/Liquidität).
4. Wachstum: Erweiterung der Regionen/Methoden, Zuschüsse/Marketing, SDK-Updates.
5. Compliance: Periodische Reviews, Schlüsselaudits, Rotation, DR-Tests.
6. Entwicklung/Kündigung: Vertragsmigration, Auszahlungen, Archiv, Schlüsselentzug.

7) Teilnehmerregister und Zugänge (Referenzmodell)

• 'org' (Organisation), 'role _ binding' (Rolle und Skope), 'credential' (Schlüssel/Zertifikat), 'capability' (Berechtigungssatz), 'limit' (Quoten), 'compliance _ record' (KUS/KUV/Audit), 'contact' (operativ).

Beispieldiagramm (Pseudo-SQL)

sql
CREATE TABLE orgs (
org_id TEXT PRIMARY KEY,
legal_name TEXT, country TEXT, regulator TEXT,
trust_tier SMALLINT, status TEXT, created_at TIMESTAMPTZ
);

CREATE TABLE role_bindings (
org_id TEXT REFERENCES orgs(org_id),
role TEXT,     -- operator    provider    psp    kyc    relay    bridge    affiliate...
scope JSONB, -- regions/networks/products
PRIMARY KEY (org_id, role)
);

CREATE TABLE credentials (
org_id TEXT REFERENCES orgs(org_id),
peer_id TEXT, type TEXT, public_key TEXT, valid_to TIMESTAMPTZ,
revoked BOOLEAN DEFAULT FALSE,
PRIMARY KEY (org_id, peer_id)
);

CREATE TABLE capabilities (
org_id TEXT REFERENCES orgs(org_id),
capability TEXT,  -- payouts. write, events. publish, traffic. receive, bridge. sign,...
conditions JSONB, -- limits/hours/countries/assets
PRIMARY KEY (org_id, capability)
);

CREATE TABLE compliance_records (
org_id TEXT REFERENCES orgs(org_id),
kyb_status TEXT, licenses JSONB, sanctions_check TEXT,
last_audit TIMESTAMPTZ, next_review TIMESTAMPTZ
);

Beispielrichtlinie (YAML)

yaml access:
tiers:
T1: { max_regions: 2, payouts_daily_usd: 100000, assets: [USDC, EUR] }
T2: { max_regions: 6, payouts_daily_usd: 1000000, assets: [USDC, EUR, TRY] }
T3: { max_regions: 32, unlimited: true, bridge_sign: true }
roles:
operator:
caps: [events. publish, payouts. write, users. read]
provider:
caps: [content. serve, limits. read, events. publish]
psp:
caps: [payments. process, payouts. execute]

8) Verknüpfungsgraph und Beobachtungsschleife

Teilnehmergraph: Die Eckpunkte sind 'org _ id', die Kanten sind 'relation (type, scope, slas, limits)'.
Rippenkategorien: „content“, „payments“, „bridge“, „traffic“, „data“, „governance“.
Beobachtbarkeit: P2P-Hop-Trace, Trust Log (Signaturen), SLI/SLO für jeden Kantentyp.

Beispiel für ein Rippenmodell (Pseudo-SQL)

sql
CREATE TABLE edges (
src_org TEXT, dst_org TEXT, edge_type TEXT, -- payments    content    traffic    bridge    data    gov slas JSONB, limits JSONB, status TEXT, since TIMESTAMPTZ,
PRIMARY KEY (src_org, dst_org, edge_type)
);

9) Mapping auf Prozesse und Daten

Veranstaltungsmodell: 'signup/kyc/pass', 'deposit/payout', 'game _ start/event', 'bridge. lock/mint`, `traffic. view/click 'ist ein einheitliches Schema und idempotency-Schlüssel.
Die Kataloge: die Netze/Aktiva/Methoden der Bezahlung/Version die SDK/Regler/Länder.
Logging und Audit: unveränderliche Logs (Hash-Ketten), Verknüpfung mit 'proposal _ id' (Governance) und 'org _ id'.

10) Gesundheitsmetriken der „Karte“ (KPI/SLO)

Abdeckung und Vollständigkeit

Coverage% nach Rollen (Anteil der von den Teilnehmern geschlossenen Ökosystemfunktionen).
Region Coverage% (Länder × Methoden × Anbieter).
Version Coverage% (SDK/Protokoll).

Qualität und Risiko

Compliance Freshness (Zeit seit letzter KUV-Prüfung/Audit).
Key Hygiene (Rotation auf Zeit, Anteil fauler Schlüssel).
Incident Rate nach Rollen/Kanten; MTTA/MTTR.

Wirtschaft und Wachstum

Neue Partner/Monat, Activation Velocity (vom Onboarding bis zu den ersten Events), Net Contribution (Mitgliedsbeitrag zu GTV/MAU/Liquidität).
Partner Churn%.

Beispiele für SLOs

KYB Review ≤ 5 Werktage Schlüssel T3 Rotation ≤ 90 Tage; Incident SEV-1 MTTR ≤ 30 min Post-mortem ≤ 72 ч.

11) Dashboards (Layouts)

Atlas (Gesamtkarte): interaktiver Graph: Rollen, Links, Status (zel/yellow/red), Filter nach Land/Kante.
Compliance: Prüfungstermine, abgelaufene KUV/Audits, Sanktionshits.
Konnektivität: p95 Latenz und Erfolg nach Kanten, Anteil der direkten P2P, Relay-Prozentsatz.
Wirtschaft: Beitrag der Teilnehmer (GTV/MAU/Take Rate), Top-Wachstum/-Rückgang.
Risiko: Vorfälle nach Klassen, Burn-Rate SLO, Exposés nach Kontrahenten.
Governance: Aktivität der Vorschläge, Verteilung der Stimmen, Zuschüsse.

12) Onboarding des Teilnehmers: Checkliste

1. Rechtsfragebogen + Dokumente (KYB, Lizenzen, Begünstigte).
2. Technische Registrierung 'org _ id', Freigabe/Download der Schlüssel, Aufbau des mTLS.
3. Auswahl von Rollen und Skopas, Zuweisung von 'capabilities' und Limits.
4. Anschluss an Sandbox, Testsuiten (Events, Payouts, Limits, Bridge).
5. Konfiguration von SLO/Alert und Contact Line (24/7 für kritische Rollen).
6. Genehmigung von SLA/Regularien, Veröffentlichung im Register.
7. Kanarische Periode (1-2 Wochen), dann Erweiterung der Quoten.

13) Änderungsmanagement und Kompatibilität

API/Event/Schema-Versionierung: Richtlinie „nur hinzufügen“, Deprecate-Fenster ≥ 90 Tage.
Capability negotiation: Deklaration der unterstützten Fähigkeiten bei handshake.
Rollen-/Scope-Migrationen: Anwendungen durch Governance, Timelock, Audit.

14) Sicherheit und Privatsphäre

Erforderliche Mindestrechte (PoLP) nach Rollen und Kanten.
E2E-Verschlüsselung für sensible Themen (Payments/CUS).
DLP/PII-Steuerung: Tokenisierung, Pseudonymisierung, regionale Schaufenster.
Anti-Sybil für kritische Rollen: Einlagen/Versicherung, Proof-of-Authority.
Rotation/Schlüsselrückruf: „Doppelschlüssel“, Schichtprotokoll, Benachrichtigungen an Partner.

15) Playbook der Vorfälle (nach „Kante“ und „Rolle“)

• Sofortiger Widerruf, Veröffentlichung von 'revoke-event', Block auf ACL, Rotation von abhängigen Schlüsseln, Bericht ≤ 24 Stunden.

• Routenumschaltung, K-Bestätigungen erhöhen, Volumen throttle, Kommunikation, SLO-Kompensation.

• Einfrieren von Links/Scopes, manuelle Überprüfung, Compliance-Bericht, Aktualisierung von Listen.

• Kollidieren von Protokollen (Unterschriften/Quittungen), Arbitrage, temporärer Greylist, Anpassung von Auszahlungen.

16) Beispiele für „Map“ -Analysen (Pseudo-SQL)

Abdeckung nach Rolle und Land

sql
SELECT role, country, COUNT(DISTINCT org_id) AS orgs
FROM role_bindings rb
JOIN orgs o USING (org_id)
GROUP BY role, country;

Fristen für die Einhaltung (Verspätung)

sql
SELECT org_id, last_audit, next_review,
CASE WHEN next_review < now() THEN 'overdue' ELSE 'ok' END AS status
FROM compliance_records
ORDER BY next_review ASC;

Rippengesundheit (Erfolg/Latenz)

sql
SELECT edge_type,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY latency_ms) AS p95_latency,
100. 0 SUM(CASE WHEN status='success' THEN 1 ELSE 0 END)/COUNT() AS success_rate
FROM edge_metrics
WHERE ts >= now() - INTERVAL '7 days'
GROUP BY edge_type;

17) Register und Kataloge (Referenz-YAML)

yaml catalogs:
networks: [eth-mainnet, polygon, solana, tron]
assets:
- { symbol: USDC, decimals: 6, chains: [eth-mainnet, polygon] }
- { symbol: TRYX, decimals: 2, chains: [tron] }
regulators:
- { code: UKGC, country: GB }
- { code: MGA, country: MT }
sdk_versions:
required: { min: "2. 4. x", lts: "2. 6. x" }

18) Betriebsvorschriften

Täglich: Rippenüberwachung (SLO), Überprüfung der Schlüsselrevolver, Onboarding-Statusberichte.
Wöchentlich: Card Committee - neue Rollen/Scopes, Compliance-Überfälligkeiten, Empfehlungen für Zuschüsse/MVP-Integrationen.
Monatlich: Asset/Network Catalog Audit, SDK Version Revision, Incident Report und Time-to-Fix.
Vierteljährlich: Überarbeitung von Trust Tiers, DR-Stresstest und Notfallverfahren.

19) Checkliste zur Einführung der „Karte“

1. Harmonisierung der Taxonomie von Rollen/Unterrollen und Datenschemata.
2. Erweitern Sie die Mitgliederregistrierung, Verzeichnisse, ACLs und Capability-Richtlinien.
3. Aktivieren Sie die Rippenbeobachtbarkeit (SLI/SLO) und Burn-Rate-Alerts.
4. Konfigurieren Sie die Onboarding-Pipeline (KYB, Schlüssel, sandbox→prod).
5. Verknüpfen Sie die Karte mit Governance (Proposals, Timelock, Entscheidungsprotokoll).
6. Revidieren Sie regelmäßig die Deckungen, Risiken und Verzögerungen der Compliance.
7. Veröffentlichen Sie einen „Ökosystematlas“ für interne/Affiliate-Benutzer.

20) Glossar

org_id ist die einzigartige technische Identität der Organisation.
Trust Tier - Vertrauensniveau/Zertifizierung des Teilnehmers.
Edge/Rib ist eine formalisierte Verbindung zwischen Teilnehmern mit SLO und Limits.
Kapazität - Zulässige Operation/Rechte in einer bestimmten Schleife.
Coverage% - Anteil der geschlossenen Funktionen/Regionen/Versionen.
Burn-Rate SLO - die Geschwindigkeit des „Brennens“ des Fehlerbudgets.

Fazit: Die Teilnehmerkarte ist die „Organisationstopologie“ des Ökosystems. Seine Implementierung bietet eine einheitliche Sprache für Rollen und Verbindungen, transparente Haftungsgrenzen, vorhersehbare SLOs, schnelles Onboarding und überschaubare Risiken. Mit dieser Basis lässt sich das Netzwerk einfacher skalieren, überwachen und weiterentwickeln - ohne Überraschungen und mit maximalem Nutzen für alle Seiten.