Mapa de los participantes del ecosistema

(Sección: Ecosistema y Red)

1) Por qué se necesita una tarjeta de participantes

El mapa de participantes es un modelo común de «quién es quién» en el ecosistema: roles, actitudes, derechos, límites de responsabilidad y contornos de cumplimiento. Elimina la diversidad de términos, acelera el acoplamiento de socios, simplifica el rastreo de incidentes y mejora la capacidad de gestión de la red (gobierno, riesgo, seguridad, desarrollo).

2) Taxonomía de roles (nivel superior)

1. Operadores (Operators) son marcas/plataformas que poseen la experiencia del cliente.
2. Proveedores de contenido (Studios/Content Providers) - tragamonedas, juegos en vivo, deportes fides, minijuegos.
3. Proveedores de pago (PSP/On-Off Ramp): tarjetas, APM, stables, carteras criptográficas.
4. Identificación y riesgo (KYC/KYB/AML/Trust) - verificación, puntuación, filtros de sanciones.
5. Infraestructura/Red (Nodes/Relays/Edge/CDN/Bridges) - Transporte, enrutamiento, comunicaciones cruzadas.
6. Afiliados/Agregadores/Tráfico - Fuentes de leads, escaparates, redes de medios.
7. Análisis y datos (DWH/BI/Anti-Fraud): observación, presentación de informes, simulación.
8. Comunidades y DevRel - desarrolladores, integradores, equipos de afiliados.
9. Reguladores y auditores (B2G) - licencias, auditorías, informes.
10. Gobierno y Hacienda - reglas, presupuestos, subvenciones.
11. Brókers afiliados/Market Plays - Intercambio de tráfico, liquidez, integraciones.

3) Sub-roles y objetos (detalle)

Operadores: marca B2C, marca blanca, sub-operador regional, enrutador PSP.
Estudios/proveedores: RGS, estudio en vivo, torneos «ranner», proveedor de deportes fid.
PSP: mapa de adquisición, APM local (Papara, Mefete, etc.), procesamiento de cifrado, vendedor de reglas de riesgo.
KYC/KYB/AML: proveedor de KYC, fuente de listas de sanciones, proveedor de PEP/Adverse Media, puntuación de comportamiento.
Infraestructura: validador/nodo, super-nodo/relay, puente (light/optimistic/ZK), caché CDN/edge.
Tráfico/medios: escaparate, arbitrista, red de influencers, retargeting-DSP, socio de armas CRM.
Datos: índice blockchain, conector CDC, anti-frod DSS, BI.
Comunicaciones: Contributor SDK, Integrador, Representante Local/Ambassador.
B2G: regulador, informes fiscales, auditoría (externa/interna).
Gobierno/Tesorería: junta de protocolo, delegados, comité de subvenciones.
Corredores: agregador de integraciones (mercado API), intercambio de tráfico/liquidez.

4) Modelos de confianza e identidad

Identidad jurídica: KYB (reg. número, país, beneficiarios), licencias/permisos.
Identidad técnica: 'org _ id', 'peer _ id' (ed25519/secp256k1), X.509 (mTLS), direcciones/carteras.
Niveles de confianza (Trust Tiers): T0 (público), T1 (con certificación básica), T2 (verificación avanzada + depósitos), T3 (funciones/puentes críticos).
Política de claves: claves raíz de la organización + sesión; rotación/revocación, registro de claves de confianza.

5) Matriz de interacciones (B2B/B2C/B2G)

Operador ↔ Proveedor: contenido, límites, torneos, facturación, SLA.
Operador ↔ PSP/KYC: depósitos, pagos, verificación, charjbeki.
Operador ↔ Afiliados: leads, atribución, pagos, QoT.
Provider ↔ Network/Infra: distribución, retrasos, finalización.
Gobierno ↔ Todo: reglas, votos, subvenciones.
Regulator/Audit ↔ Operator/PSP: informes, verificaciones, incidentes.
Data/BI ↔ Todo: esquemas de eventos, escaparates, privacidad.

Tipos de vínculos: datos (eventos), llamadas (RPC/API), valor (pagos/activos), confianza (claves/firmas), administración (proposal/soluciones).

6) Ciclo de vida del participante (Lifecycle)

1. Onboarding: registro, KYB, verificación de licencias, descarga de documentos, generación de 'org _ id', liberación de claves.
2. Integración técnica: sandbox → stage → canary → production, casos de prueba, firma de los primeros eventos.
3. Activación: objetivos SLO, cuotas/límites, inclusión en los grupos (tráfico/liquidez).
4. Crecimiento: expansión de regiones/métodos, subvenciones/marketing, actualizaciones de SDK.
5. Cumplimiento: rugido periódico, auditoría de claves, rotación, pruebas de RD.
6. Evolución/terminación: migración de contratos, retirada de fondos, archivo, retirada de claves.

7) Registro de participantes y accesos (modelo de referencia)

• 'org' (organización), 'role _ binding' (rol y scop), 'credential' (clave/certificado), 'capability' (conjunto de permisos), 'limit' (cuotas), 'compliance _ record' (CUS/CUV/auditoría), 'contact' (operativo).

Esquema de ejemplo (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
);

Ejemplo de política (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) Gráfico de conexiones y contorno de observación

Gráfico de participantes: vértices - 'org _ id', costillas - 'relación (tipo, scope, slas, limits)'.
Las categorías de costillas son: 'content', 'payments', 'bridge', 'traffic', 'data', 'governance'.
Observabilidad: rastreo de hopas P2P, registro de confianza (firmas), SLI/SLO para cada tipo de costilla.

Ejemplo de modelo de costilla (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 en procesos y datos

Modelo de eventos: 'signup/kyc/pass',' deposite/payout ',' game _ start/event ',' bridge. lock/mint`, `traffic. view/click 'es un circuito único y llaves idempotency.
Catálogos: redes/activos/métodos de pago/versiones de SDK/reguladores/países.
Lógica y auditoría: registros inmutables (hash-chain), referencia a 'proposal _ id' (governance) y 'org _ id'.

10) Métricas de salud «tarjetas» (KPI/SLO)

Cobertura y plenitud

Coverage% por roles (proporción de funciones del ecosistema cerradas por los participantes).
Cobertura de la región% (países × métodos × proveedores).
Version Coverage% (SDK/protocolo).

Calidad y riesgo

Compliance Freshness (tiempo transcurrido desde la última comprobación de la QUV/auditoría).
Key Hygiene (rotación a tiempo, proporción de llaves filtradas).
Tasa de Incident por roles/costillas; MTTA/MTTR.

Economía y crecimiento

New Partners/mes, Activation Velocity (desde onboarding hasta primeros eventos), Net Contribution (contribución del participante a GTV/MAU/liquidez).
Partner Churn%.

Ejemplos de SLO

Revisión KYB ≤ 5 días hábiles; llaves T3 rotación ≤ 90 días; Incident SEV-1 MTTR ≤ 30 minutos; Post-mortem ≤ 72 ч.

11) Dashboards (diseños)

Atlas (mapa general): gráfico interactivo: roles, conexiones, estados (zel/amarillo/rojo), filtros por país/costilla.
Compliance: plazos de las auditorías, QUV/auditorías atrasadas, aciertos sancionadores.
Conectividad: p95 latencia y éxito por costillas, proporción de P2P directo, porcentaje relay.
Economía: contribución de los participantes (GTV/MAU/Take Rate), crecimiento superior/caída.
Risk: incidentes por clase, burn-rate SLO, exposiciones por contraparte.
Gobierno: actividad de propuestas, distribución de votos, subvenciones.

12) Onboarding del participante: lista de cheques

1. Cuestionario legal + documentos (KYB, licencias, beneficiarios).
2. Registro técnico de 'org _ id', liberación/descarga de claves, configuración de mTLS.
3. Selección de roles y copos, asignación de 'capabilities' y límites.
4. Conectarse a sandbox, tests (eventos, payouts, limits, bridge).
5. Configuración de SLO/alertas y regla de contacto (24/7 para roles críticos).
6. Aprobación del SLA/Reglamento, publicación en el registro.
7. Periodo canario (1-2 semanas), luego ampliación de cuotas.

13) Administración de cambios e interoperabilidad

Versionar API/eventos/esquemas: política «sólo agregar», ventana de depósito ≥ 90 días.
Capability negotiation: declare capacidades compatibles con handshake.
Migraciones de roles/scop: aplicaciones a través de governance, timelock, auditoría.

14) Seguridad y privacidad

Derechos mínimos requeridos (PoLP) por roles y costillas.
Encriptación E2E para temas sensibles (pagos/CUS).
Control DLP/PII: tokenización, pseudonimización, escaparates regionales.
Anti-Sybil para funciones críticas: depósitos/seguros, proof-of-authority.
Rotación/revocación de claves: «claves dobles», registro de turnos, notificaciones a los socios.

15) Incidentes de Playbook (por «costilla» y «rol»)

• Revocación inmediata, publicación de 'revoke-event', bloque de ACL, rotación de claves dependientes, informe ≤ 24 h.

• Cambiar de ruta, aumentar K-confirmations, throttle volúmenes, comunicaciones, compensación por SLO.

• Congelación de enlaces/escopetas, rugido manual, informe de cumplimiento, actualización de listas.

• Registro de escaramuzas (firmas/recibos), arbitraje, greylist temporal, ajuste de pagos.

16) Ejemplos de análisis de «tarjeta» (pseudo-SQL)

Cobertura por roles y países

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

Plazos de cumplimiento (atrasos)

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;

Salud de costillas (éxito/latencia)

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) Registros y catálogos (referencia-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) Normas de funcionamiento

Diariamente: monitoreo de costillas (SLO), comprobación de rugidos de claves, informes de estado de onboarding.
Semanalmente: Comité del Mapa - nuevos roles/scoops, cumplimiento atrasado, recomendaciones de subvenciones/MVP integraciones.
Mensualmente: auditoría del catálogo de activos/redes, revisión de versiones de SDK, informe de incidentes y tiempo a fijar.
Trimestral: revisión de Trust Tiers, prueba de estrés DR y procedimientos de emergencia.

19) Lista de verificación de la implementación de la «tarjeta»

1. Armonizar la taxonomía de roles/sub-roles y los esquemas de datos.
2. Expanda el registro de miembros, los directorios, la ACL y la política de capacidad.
3. Habilitar la observabilidad de costillas (SLI/SLO) y alertas burn-rate.
4. Configure el transportador de onboarding (KYB, llaves, sandbox→prod).
5. Asociar la tarjeta con el gobierno (proposals, timelock, registro de soluciones).
6. Revisa regularmente las coberturas, los riesgos y los retrasos en el cumplimiento.
7. Publicar un «atlas del ecosistema» para los usuarios internos/asociados.

20) Glosario

org_id es la identidad técnica única de la organización.
Trust Tier - Nivel de confianza/certificación del miembro.
Edge/Rebro es una conexión formalizada entre los miembros con SLO y los límites.
Capability - Operación/derechos permitidos en un bucle específico.
Coverage% es la proporción de funciones/regiones/versiones cerradas.
Burn-rate SLO es la tasa de «quema» del presupuesto de errores.

En pocas palabras: el mapa de participantes es la «topología organizacional» del ecosistema. Su implementación proporciona un lenguaje único de roles y conexiones, límites transparentes de responsabilidad, SLO predecibles, un rápido acoplamiento y riesgos manejables. Con esta base, la red es más fácil de escalar, monitorizar y desarrollar - sin sorpresas y con el máximo beneficio para todas las partes.