Карта участников экосистемы
(Раздел: Экосистема и Сеть)
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` (KYC/KYB/аудит), `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 (время с последней проверки KYB/аудита).
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: сроки ревизий, просроченные KYB/аудиты, санкционные хиты.
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-шифрование для чувствительных тем (платежи/KYC).
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, быстрый онбординг и управляемые риски. С этой основой сеть проще масштабировать, мониторить и развивать — без сюрпризов и с максимальной пользой для всех сторон.