GH GambleHub

Análisis entre cadenas

(Sección: Ecosistema y Red)

1) Qué es la analítica entre cadenas y por qué es necesaria

La analítica entre cadenas (cross-chain analytics) es una metodología y acoplamiento que combina telemetría y eventos de múltiples circuitos, puentes, proveedores y aplicaciones en un único modelo de datos. Objetivos:
  • Contabilidad unificada de valor y actividad: volúmenes, liquidez, comisiones, retén.
  • Observabilidad de puentes y enlaces P2P: finalización, lags, evento reorg/challenge.
  • Atribución de tráfico y conversiones: cheyn→cheyn, kanal→produkt.
  • Riesgo y cumplimiento: AML, sanciones, feudo conductual, identificación de entidades.
  • Toma de decisiones: OKR/presupuestos, límites, reglamentos de actualización y liquidez.

2) Fuentes de datos y eventos (lista canónica)

1. Circuitos/registros: bloques, transacciones, registros de eventos, estados de contratos inteligentes.
2. Puentes: solicitudes, recibos, pruebas (light/optimistic/ZK), estados de finalización.
3. Proveedores de pago/CUS: paso de comprobaciones, límites, estados de pago.
4. Eventos de productos: onboarding, depósitos/apuestas/retiros, juegos y métricas de comportamiento.
5. Transporte P2P: recibos Pub/Sub, éxito RPC, latency.
6. Referencias: redes, activos, decimals, chainId, direcciones de contratos, versiones SDK.

💡 Para cada fuente, asegúrese de: diagrama, archivo de actualización, «ventana de finalización», propietario, SLO.

3) Arquitectura de datos (flujos y almacenamiento)

Ingest (streaming): conectores a nodos/indexadores, puentes de webhooks, CDC desde los DB operativos.
Capas crudas (Bronze/Raw): lotes inmutables con la etiqueta 'observed _ at' y metadatos de origen.
Limpieza/normalización (Silver): dedoop, enriquecimiento semántico, alineación de tiempo, mapping de activos.
Modelos de núcleo (Gold/Core): hechos unificados 'transfers',' bridges ',' onchain _ events', 'kyc _ status', 'payouts'.
Vitrinas (Marts): finanzas (GTV/TVL/Take Rate), producto (retén/embudo), riesgo (puntuación), operación (SLO).
Caché/Servidor: OLAP/HTAP para dashboards y API, y una búsqueda separada por direcciones/tx.

Transporte: Kafka/Pulsar (exactly-once semantics sobre la idempotencia), almacenamiento de objetos para materias primas, parquet/formatos de columna para análisis.

4) Finalización, reorgía e idempotencia

Estados de eventos: 'observed' → 'confirmed (k)' → 'finalized' → 'invalidated (reorg)'.
Regla de confirmación (K-confirmations): se configura a través de la red/tipo de activo.
Optimistic/Challenge de la ventana: soporte del estado «disputado» para los puentes.
Idempotencia: 'idempotency _ key = chainId' block 'tx' logIndex 'topic' (o hash de carga útil).
Reproducción de pere (replay): backfill planificado y recuperación al cambiar el índice.

5) Modelo de identidades y entidades (solución de entidad)

Dirección → Actor: direcciones, llaves, carteras ↔ cuenta/organización/proveedor.
Grafo de cadena cruzada: conexiones de direcciones por un solo propietario (heurísticas, firmas, datos de onboarding).
Niveles de confianza: hard-link (KYC, firma en cadena), soft-link (correlaciones de comportamiento).
Pseudonimización: almacena identificadores estables (PID) en lugar de PII en la analítica.

6) Esquema de eventos unificado (simplificado)

yaml event:
id: string # global UUID observed_at: timestamp # when they saw chain_id: string # 'eth-mainnet', 'solana-mainnet',...
block_height: long tx_hash: string log_index: int event_type: string    # transfer    bridge. lock    bridge. mint    kyc. pass    payout. done...
status: string      # observed    confirmed    finalized    invalid actor_src: string # address/peer-id/source organization actor_dst: string # address/peer-id/destination organization asset: string # canonical symbol (e. g., USDC), + decimals amount: decimal usd_value: decimal # rate normalization at the observed_at bridge_ref: string # link with the application/receipt of the metadata bridge: object # network/contract/version/gac/fee, etc.
idempotency_key: string

7) Normalización de activos y precios

Referencia canónica de activos: símbolo, decimals, cadena mapping, direcciones contractuales.
Normalización de FX: tasas históricas y precios de activos según el temporizador 'observed _ at'.
Bandas multi-activas: agrupar los activos «envueltos» y nativos.

8) Métricas y escaparates clave

8. 1 Finanzas y liquidez

GTV (Gross Transaction Volume) por redes/activos/puentes.
TVL y Net Flow en puentes y piscinas.
Take Rate/comisión por volumen; Costo-a-Serve para el traslado.
Payout SLA Hit Rate, Finality p50/p95, Pending Backlog.

8. 2 Producto y usuario

Cross-chain MAU/DAU (dedup по PID),

Retention D1/D7/D30 teniendo en cuenta la actividad multi-line,

Funnel: red de entrada → puente → producto objetivo → acción.
QoT (calidad del tráfico): valida del tráfico después del anti-frod.

8. 3 Riesgo y cumplimiento

Fraud/Dispute Rate, High-Risk Score%, Sanctions Hit%.
Anomaly rate por patrones de traducción, velocity check, clustering.
KYB/KYC Pass% y tiempos de espera.

8. 4 Operación y SLO

Bridge Success-Rate, p95 Finality, Relay Availability,

Reorg/Challenge events, Error budget burn.

9) Ejemplos de consultas SQL/pseudo

GTV por pares de cadenas

sql
SELECT src. chain_id AS src_chain,
dst. chain_id AS dst_chain,
date_trunc('day', e. observed_at) AS d,
SUM(e. usd_value) AS gtv_usd
FROM events e
JOIN bridges b ON e. bridge_ref = b. id
JOIN networks src ON b. src_chain_id = src. id
JOIN networks dst ON b. dst_chain_id = dst. id
WHERE e. status = 'finalized' AND e. event_type IN ('bridge. lock','bridge. mint','transfer')
GROUP BY 1,2,3;

Cross-chain retention D7

sql
WITH first_touch AS (
SELECT pid, MIN(observed_at) AS t0
FROM product_events
WHERE event IN ('signup','first_deposit')
GROUP BY pid
),
week_activity AS (
SELECT DISTINCT pid
FROM product_events pe
JOIN first_touch ft USING(pid)
WHERE pe. observed_at BETWEEN ft.t0 + INTERVAL '1 day'
AND ft.t0 + INTERVAL '7 day'
)
SELECT 100. 0 COUNT() / (SELECT COUNT() FROM first_touch) AS d7_retention_pct
FROM week_activity;

Escaparate para puente SLO

sql
SELECT date_trunc('hour', observed_at) AS h,
100. 0 SUM(CASE WHEN status='finalized' THEN 1 END)/COUNT() AS success_rate,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY (finalized_at - observed_at)) AS p95_finality_min,
SUM(CASE WHEN challenge_event THEN 1 END) AS challenges
FROM bridge_events
WHERE observed_at >= now() - INTERVAL '7 days'
GROUP BY 1;

10) Atribución y vía multicanal

Modelo last-touch/position-based con pesos para la fuente de la red, el puente y el producto.
UTM→On -chain: vincule los clics/referencias a la dirección onchain al hacer onboarding (con consentimiento).
Modelos asociativos: Shapley/Markov para caminos complejos de «set→most→produkt».

11) Antifraude y señales de comportamiento

Señales gráficas: contrapartes comunes, traducciones circulares, volumen de negocios rápido.
Velocity-limites y anomalías: ráfagas, «aplastamiento» de sumas, agrupaciones nocturnas.
Esquemas de fraude en puentes: reabastecimiento, intentos de elusión de KYC, patrones de sándwich con liquidez.
Modelos: boosting degradado/graph-embeddings; enseñe a marcar incidentes.

12) Privacidad y cumplimiento (privacy-by-design)

PII minimización: PID en lugar de identificadores directos, tokenización.
Residencia de datos: partición por región, cifrado «en reposo/en tránsito».
Derecho de eliminación: tombstone/redaction-evento con probabilidad.
Acceso y auditoría: LCAs de rol, registros de lectura, informes firmados para revisiones.

13) SLI/SLO para pipelines analíticos

SLI (ejemplo):
  • Freshness (mediana de la laguna desde 'observed _ at' hasta su aparición en Gold),
  • Completeness (% de eventos sin agujeros según las expectativas de K-confirmations),
  • Corrección (% de los eventos que han pasado validaciones de esquemas/reglas),
  • Reorg handling success (% correctamente discapacitados/repeticiones),
  • Serve latency (p95 consultas a escaparates/dashboards).
SLO (puntos de referencia):
  • Freshness p95 ≤ 3 min (streaming), ≤ 15 min (batch).
  • Completeness ≥ 99. 7%, Correctness ≥ 99. 9%.
  • Reorg handling success ≥ 99. 9%.
  • Serve p95 ≤ 500 ms (escaparates principales).

14) Observabilidad de los datos y lineage

Data Lineage: desde el dashboard hasta el evento crudo (column-level).
Señales de calidad: completeness, uniqueness, referential integrity, schema drift.
Alertas: «fallos silenciosos» (no hay datos nuevos), saltos de distribución, crecimiento de los campos 'desconocidos'.

15) Dashboards (plantillas)

A. Cross-Chain Ops (tiempo real/hora):
  • Success-Rate, p95 Finality, Relay Availability, Challenge/Reorg, backlog, error budget burn.
B. Liquidity & Cost (día/semana):
  • TVL, Net Flow per chain, costa-per-transfer, utilización, fondo de seguros.
C. Product & Growth (semana/mes):
  • MAU/DAU (dedup), retención de cadena cruzada, embudos de canal, QoT.
D. Risk & Compliance (semana):
  • Fraud/Dispute Rate, sanctions hits, high-risk share, velocidad de los procedimientos.

16) Reglamentos operativos y playbook

Incidente: trago de frescura> SLO

Comprobar los conectores/indexadores, cambiar a la reserva, activar el modo de degradación (las vitrinas muestran «último finalizado»), eskalate al propietario de la fuente.

Incidente: ráfaga de reorg/challenge

Aumentar K-confirmations/ventana de disputa, habilitar «delayed finalization» para grandes sumas, alertar al puente/operadores.

Incidente: divergencia de monedas/activos

Congelar los pares afectados, revertir el directorio, volver a calcular la normalización del USD, publicar el informe.

Incidente: salto de Fraud/Dispute

Aprieta los límites/puntuación, activa el rugido manual de alto riesgo, aprende el modelo en un patrón fresco.

17) Configuraciones de ejemplo (pseudo-YAML)

Ventanas de finalización por red

yaml finality:
eth-mainnet: 12  # блоков polygon: 256 solana: "optimistic: 32 slots"
optimistic-bridge: { challenge_minutes: 20 }
zk-bridge: { proof_time_sla: 180 }

Reglas de idempotencia y dedup

yaml dedup:
key_template: "${chain_id}    ${block_height}    ${tx_hash}    ${log_index}    ${event_type}"
ttl_hours: 48

SLO pipelines

yaml pipelines:
ingest_stream:
freshness_p95_min: 3 completeness_min_pct: 99. 7 gold_build:
correctness_min_pct: 99. 9 reorg_success_min_pct: 99. 9

18) Lista de verificación de implementación

1. Fije las fuentes, esquemas, ventanas de finalización y propietarios.
2. Incluya idempotencia y reorg-handling (estados + respuesta).
3. Construya el núcleo de los modelos (transfers/bridges/onchain_events/kyc/payouts).
4. Configure las guías de activos y la normalización de FX.
5. Identificar SLI/SLO de pipelines y dashboards.
6. Implemente la solución de la entidad y la privacidad por diseño.
7. Incluya las calificaciones antifraude y el reglamento de incidentes.
8. Realice backfill y pruebas en casos históricos de reorg/challenge.
9. Revise regularmente los esquemas, el peso de las métricas y las fuentes.

19) Glosario

Finalidad - irreversibilidad del estado/evento.
Reorg es una recomposición de la cadena que resulta en la anulación de parte de las unidades.
Challenge period es una ventana de disputa en modelos optimistas.
Solución de entidad: correlación de direcciones/cuentas de una sola entidad.
GTV/TVL - volumen de transacciones/valor bloqueado.
Completeness/Freshness/Correctness: métricas básicas de calidad de datos.

En resumen: la analítica entre cadenas no es solo un resumen de métricas, sino una disciplina manejable: un único esquema de eventos, una correcta finalización, paiplines sostenibles, privacidad, antifraude y escaparates comprensibles. Siguiendo este marco, el ecosistema obtiene una visión verdaderamente «transversal» del valor, los riesgos y el crecimiento, desde el bloque crudo hasta la solución empresarial.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Telegram
@Gamble_GC
Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.