Карта учасників екосистеми
(Розділ: Екосистема та Мережа)
1) Навіщо потрібна карта учасників
Карта учасників - це загальна модель «хто є хто» в екосистемі: ролі, відносини, права, межі відповідальності та контури комплаєнсу. Вона усуває різнобій термінів, прискорює онбординг партнерів, спрощує трасування інцидентів і підвищує керованість мережі (governance, ризик, безпека, розвиток).
2) Таксономія ролей (верхній рівень)
1. Оператори (Operators) - бренди/платформи, що володіють клієнтським досвідом.
2. Провайдери контенту (Studios/Content Providers) - слоти, live-ігри, спорт-фіди, міні-ігри.
3. Платіжні провайдери (PSP/On-Off Ramp) - картки, APM, стейбли, крипто-гаманці.
4. Ідентифікація та ризик (KYC/KYB/AML/Trust) - верифікація, скоринги, санкційні фільтри.
5. Інфраструктура/Мережа (Nodes/Relays/Edge/CDN/Мости) - транспорт, маршрутизація, крос-ланцюгові зв'язки.
6. Афіліати/Агрегатори/Трафік - джерела лідів, вітрини, медіа-мережі.
7. Аналітика і дані (DWH/BI/Anti-Fraud) - спостережуваність, звітність, моделювання.
8. Ком'юніті та DevRel - розробники, інтегратори, партнерські команди.
9. Регулятори та аудитори (B2G) - ліцензії, перевірки, звіти.
10. Говернанс і казначейство - правила, бюджети, гранти.
11. Партнерські брокери/Маркет-плейси - обмін трафіком, ліквідністю, інтеграціями.
Кожна роль далі деталізується під-ролями і об'єктами обліку.
3) Під-ролі та об'єкти (деталізація)
Оператори: B2C-бренд, White-Label, регіональний суб-оператор, PSP-маршрутизатор.
Студії/провайдери: RGS, live-студія, «раннер» турнірів, постачальник спорт-фіда.
PSP: еквайринг карти, локальний APM (Papara, Mefete тощо), крипто-процесинг, вендор ризик-правил.
KYC/KYB/AML: постачальник KYC, джерело санкційних списків, провайдер PEP/Adverse Media, поведінковий скоринг.
Інфраструктура: валідатор/нода, супер-вузол/relay, міст (light/optimistic/ZK), CDN/edge-кеш.
Трафік/медіа: вітрина, арбітражник, інфлюенсер-мережа, ретаргетинг-DSP, партнер по CRM-пушам.
Дані: індексер блокчейна, CDC-конектор, анти-фрод DSS, BI.
Ком'юніті: контриб'ютор SDK, інтегратор, локальний представник/амбасадор.
B2G: регулятор, податкова звітність, аудит (зовнішній/внутрішній).
Говернанс/казначейство: рада протоколу, делегати, грантовий комітет.
Брокери: агрегатор інтеграцій (API-маркет), обмін трафіком/ліквідністю.
4) Моделі довіри та ідентичності
Юридична ідентичність: KYB (реєстр. номер, країна, бенефіціари), ліцензії/дозволи.
Технічна ідентичність: 'org _ id','peer _ id'( ed25519/secp256k1), X.509 (mTLS), адреси/гаманці.
Рівні довіри (Trust Tiers): T0 (публічний), T1 (з базовою сертифікацією), T2 (розширена перевірка + депозити), T3 (критичні ролі/мости).
Політика ключів: кореневі ключі організації + сесійні; ротація/відгук, журнал довірених ключів.
5) Матриця взаємодій (B2B/B2C/B2G)
Operator ↔ Provider: контент, ліміти, турніри, білінг, SLA.
Operator ↔ PSP/KYC: депозити, виплати, верифікація, чарджбеки.
Operator ↔ Affiliates: ліди, атрибуція, виплати, QoT.
Provider ↔ Network/Infra: дистрибуція, затримки, фіналізація.
Governance ↔ Все: правила, голосування, гранти.
Regulator/Audit ↔ Operator/PSP: звіти, перевірки, інциденти.
Data/BI ↔ Всі: схеми подій, вітрини, приватність.
Типи зв'язків: дані (events), виклики (RPC/API), цінність (платежі/активи), довіра (ключі/підписи), управління (proposal/рішення).
6) Життєвий цикл учасника (Lifecycle)
1. Онбординг: реєстрація, KYB, перевірка ліцензій, завантаження документів, генерація'org _ id', випуск ключів.
2. Технічна інтеграція: sandbox → stage → canary → production, тест-кейси, підпис перших подій.
3. Активація: SLO-цілі, квоти/ліміти, включення в пули (трафік/ліквідність).
4. Зростання: розширення регіонів/методів, гранти/маркетинг, оновлення SDK.
5. Комплаєнс: періодичні рев'ю, аудит ключів, ротація, тести DR.
6. Еволюція/розірвання: міграція контрактів, виведення коштів, архів, відкликання ключів.
7) Реєстр учасників та доступи (референс-модель)
Сутності:- 'org'( організація),'role _ binding'( роль і скоуп),'credential'( ключ/сертифікат),'capability'( набір дозволів),'limit'( квоти),'compliance _ record'( КУС/КУВ/аудит),'contact'( операційний).
Приклад схеми (псевдо-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
);Приклад політики (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) Граф зв'язків і контур спостережуваності
Граф учасників: вершини -'org _ id', ребра -'relation (type, scope, slas, limits)'.
Категорії ребер: `content`, `payments`, `bridge`, `traffic`, `data`, `governance`.
Спостережуваність: трасування P2P-хопів, журнал довіри (підпису), SLI/SLO по кожному типу ребра.
Приклад моделі ребра (псевдо-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) Маппінг на процеси і дані
Подієва модель: `signup/kyc/pass`, `deposit/payout`, `game_start/event`, `bridge. lock/mint`, `traffic. view/click'- єдина схема і idempotency-ключі.
Каталоги: мережі/активи/методи оплати/версії SDK/регулятори/країни.
Логування та аудит: незмінні журнали (hash-ланцюжки), прив'язка до'proposal _ id'( governance) і'org _ id'.
10) Метрики здоров'я «карти» (KPI/SLO)
Покриття та повнота
Coverage% за ролями (частка екосистемних функцій, закритих учасниками).
Region Coverage% (країни × методи × провайдери).
Version Coverage% (SDK/протокол).
Якість і ризик
Compliance Freshness (час з останньої перевірки КУВ/аудиту).
Key Hygiene (ротація вчасно, частка протухлих ключів).
Incident Rate за ролями/ребрами; MTTA/MTTR.
Економіка і зростання
New Partners/міс, Activation Velocity (від онбордингу до перших подій), Net Contribution (внесок учасника в GTV/MAU/ліквідність).
Partner Churn%.
Приклади SLO
KYB review ≤ 5 робочих днів; ключі T3 ротація ≤ 90 днів; Incident SEV-1 MTTR ≤ 30 хв; Post-mortem ≤ 72 ч.
11) Дашборди (макети)
Atlas (загальна карта): Інтерактивний граф: ролі, зв'язки, статуси (зел/жовт/красн), фільтри по країнах/ребрах.
Compliance: терміни ревізій, прострочені КУВ/аудити, санкційні хіти.
Connectivity: p95 latency і success за ребрами, частка прямих P2P, relay-відсоток.
Economy: внесок учасників (GTV/MAU/Take Rate), топ-зростання/падіння.
Risk: інциденти за класами, burn-rate SLO, експозиції за контрагентами.
Governance: активність пропозицій, розподіл голосів, гранти.
12) Онбординг учасника: чек-лист
1. Юридична анкета + документи (KYB, ліцензії, бенефіціари).
2. Технічна реєстрація'org _ id', випуск/завантаження ключів, налаштування mTLS.
3. Вибір ролей і скоупів, призначення'capabilities'і лімітів.
4. Підключення до sandbox, тест-сьюти (events, payouts, limits, bridge).
5. Налаштування SLO/алертів і контакт-лінійки (24/7 для критичних ролей).
6. Затвердження SLA/регламентів, публікація до реєстру.
7. Канареечний період (1-2 тижні), потім розширення квот.
13) Управління змінами та сумісність
Версіонування API/подій/схем: політика «тільки додавання», депрекейт-вікно ≥ 90 днів.
Capability negotiation: оголошення підтримуваних можливостей при handshake.
Міграції ролей/скоупів: заявки через governance, timelock, аудит.
14) Безпека і приватність
Мінімально необхідні права (PoLP) за ролями і ребрами.
E2E-шифрування для чутливих тем (платежі/КУС).
DLP/PII-контроль: токенізація, псевдонімізація, регіональні вітрини.
Анти-Sybil для критичних ролей: депозити/страхування, proof-of-authority.
Ротація/відгук ключів: «подвійні ключі», журнал змін, повідомлення партнерам.
15) Playbook інцидентів (по «ребру» і «ролі»)
Компрометація ключа учасника (T2/T3):- Негайний відгук, публікація'revoke-event', блок по ACL, ротація залежних ключів, звіт ≤ 24 год.
- Перемикання маршруту, підвищення K-confirmations, throttle обсягів, комунікації, компенсації по SLO.
- Заморожування зв'язків/скоупів, ручний рев'ю, звіт комплаєнсу, оновлення списків.
- Сутичка логів (підписи/квитанції), арбітраж, тимчасовий greylist, коригування виплат.
16) Приклади аналітики «карти» (псевдо-SQL)
Покриття за ролями та країнами
sql
SELECT role, country, COUNT(DISTINCT org_id) AS orgs
FROM role_bindings rb
JOIN orgs o USING (org_id)
GROUP BY role, country;Терміни комплаєнсу (прострочення)
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;Здоров'я ребер (успіх/латентність)
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) Регістри та каталоги (референс-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) Операційні регламенти
Щодня: моніторинг ребер (SLO), перевірка ревоків ключів, звіти статусів онбордингів.
Щотижня: комітет карти - нові ролі/скоупи, прострочення комплаєнсу, рекомендації щодо грантів/MVP інтеграцій.
Щомісяця: аудит каталогу активів/мереж, ревізія версій SDK, звіт по інцидентах і time-to-fix.
Щоквартально: перегляд Trust Tiers, стрес-тест DR і emergency-процедур.
19) Чек-лист впровадження «карти»
1. Узгодити таксономію ролей/під-ролей і схеми даних.
2. Розгорнути реєстр учасників, каталоги, ACL і capability-політику.
3. Включити спостережуваність ребер (SLI/SLO) і алерти burn-rate.
4. Налаштувати онбординг-конвеєр (KYB, ключі, sandbox→prod).
5. Зв'язати карту з governance (proposals, timelock, журнал рішень).
6. Регулярно ревізувати покриття, ризики та прострочення комплаєнсу.
7. Публікувати «атлас екосистеми» для внутрішніх/партнерських користувачів.
20) Глосарій
org_id - унікальна технічна ідентичність організації.
Trust Tier - рівень довіри/сертифікації учасника.
Edge/Ребро - формалізований зв'язок між учасниками з SLO і лімітами.
Capability - дозволена операція/права в конкретному контурі.
Coverage% - частка закритих функцій/регіонів/версій.
Burn-rate SLO - швидкість «спалювання» бюджету помилок.
Підсумок: карта учасників - це «організаційна топологія» екосистеми. Її впровадження дає єдину мову ролей і зв'язків, прозорі межі відповідальності, передбачувані SLO, швидкий онбординг і керовані ризики. З цією основою мережу простіше масштабувати, моніторити і розвивати - без сюрпризів і з максимальною користю для всіх сторін.