GH GambleHub

Analisi intercorrenti

(Sezione Ecosistema e Rete)

1) Cosa sono gli analisti intercorrenti e perché sono necessari

L'analista intercontinentale (cross-chain analytics) è una metodologia e uno stack che uniscono la telemetria e gli eventi di una serie di catene, ponti, provider e applicazioni in un unico modello di dati. Obiettivi:
  • Conteggio unico del valore e dell'attività: quantità, liquidità, commissioni, retensioni.
  • Osservabilità ponti e collegamenti P2P: finalizzazione, laghe, reorg/challenge eventi.
  • L'attribuzione del traffico e delle conversioni è cheyn→cheyn, kanal→produkt.
  • Rischio e compilazione: AML, sanzioni, frode comportamentale, identificazione delle entità.
  • Decisione: OKR/budget, limiti, regolamenti di aggiornamento e liquidità.

2) Origini dati ed eventi (elenco canonico)

1. Catene/registri: blocchi, transazioni, logici di eventi, stato dei contratti smart.
2. Ponti: richieste, ricevute, prove (light/ottimistico/ZK), stati di finalizzazione.
3. Provider di pagamento/CUS: controllo, limiti, stato dei pagamenti.
4. Eventi alimentari: onboarding, depositi/scommesse/conclusioni, metriche di gioco e comportamento.
5. Trasporto P2P: ricevute pub/sub, successo RPC, latency.
6. Linee guida: reti, risorse, decimals, chainId, indirizzi contrattuali, versioni SDK.

💡 Per ogni origine, fissare: schema, layout di aggiornamento, finestra di finalizzazione, proprietario, SLO.

3) Architettura dei dati (flussi e storage)

Engest - Connettori a nodi/indicizzatori, webhooks ponti, CDC da database operativi.
Livelli crudi (Bronze/Raw) - Partizioni invariate con l'etichetta «observed _ at» e i metadati della sorgente.
Pulizia/normalizzazione (Silver) - Deduplicazione, arricchimento semantico, allineamento timsone, mapping delle risorse.
Modelli core (Gold/Core): fatti unificati «transfers», «bridges», «onchain _ events», «kyc _ status», «payouts».
Vetrine (Marts): finanza (GTV/TVL/Take Rate), prodotto (retenschn/vortici), rischio (screen), operazione (SLO).
Kesh/Serve: OLAP/HTAP per dashboard e API, e ricerca separata per indirizzo/tx.

Trasporti: Kafka/Pulsar (exactly-once semantics sopra l'idampotenza), deposito oggetti per le materie prime, parquet/formati di colinvertebrato per gli analisti.

4) Finalizzazione, reorghi e idampotenza

Stati eventi: "osserved" "confirmed (k)" "finalizzated" invalidated (reorg) ".
Regola di conferma - Consente di configurare la rete/il tipo di risorsa.
Ottimistic/Challenge finestre - Supporta lo status «contestato» per i ponti.
Idempotenza: 'idempotency _ key = chainId'block'tx'logIndex'topic' (o hash di carico utile).
Replay - Backfill pianificato e ripristino durante il cambio dell'indice.

5) Modello di identità e entità (entity resolution)

L'indirizzo di → ↔ è indirizzi, chiavi, portafogli, account/organizzazione/provider.
Grafico a catena crociata - Collegamenti indirizzi da un solo proprietario (euristica, firma, dati onboarding).
I livelli di sicurezza sono hard-link (KYC, on-chain), soft-link (correlazioni comportamentali).
Alias - Memorizza gli ID stabili (PID) al posto di PII nell'analisi.

6) Schema di eventi unificato (semplificato)

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) Normalizzazione degli asset e dei prezzi

Elenco canonico dei beni: carattere, decimals, chain mapping, indirizzi contrattuali.
FX normalizzazione - Corsi storici e prezzi degli asset per time'observed _ at '.
Bandi multi-attivi: raggruppa beni avvolti e nativi.

8) Metriche chiave e vetrine

8. 1 Finanza e liquidità

GTV (Grosse Communications Volume) per reti/risorse/ponti.
TVL e Net Flow per ponti e pool.
Take Rate/commissione per volume; Cost-to-Serve per il trasferimento.
Payout SLA Hit Rate, Finality p50/p95, Pending Backlog.

8. 2 Prodotto e utente

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

Retention D1/D7/D30 in base all'attività multi-touch,

Funnel - La rete di input del ponte il prodotto di destinazione.
QoT (qualità del traffico) - una valanga di traffico dopo l'anti-frodo.

8. 3 Rischi e compliance

Fraud/Dispute Rate, High-Risk Score%, Sanctions Hit%.
Anataly rate su pattern traduzioni, velocity-scontrino, clustering.
KYB/KYC Pass% e timing.

8. 4 Operatore e SLO

Bridge Success-Rate, p95 Finality, Relay Availability,

Reorg/Challenge events, Error budget burn.

9) Casi SQL/pseudo-query

GTV per coppie di catene

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;

Vetrina per ponte 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) Attribuzione e percorso multi-canale

Modello last-touch/position-based con pesi per la rete, il ponte e il prodotto.
UTM→On-chain: collegare click/refurtiva a un indirizzo onchain a un onboording (con il consenso).
Modelli associativi: Shapley/Markov per i percorsi complessi «set→most→produkt».

11) Anti-frode e segnali comportamentali

Segni grafici: controparti comuni, traduzioni circolari, rotazione rapida.
Limiti Velocity e anomalie: picchi, «frazionamento» delle somme, cluster notturni.
Schemi di frode sui ponti: rifornimento, tentativi di elusione KYC, panini con liquidità.
Modelli: busting gradiente/graph-embeddings; Insegnate a segnare gli incidenti.

12) Privacy e compilazione (privacy-by-design)

Riduzioni PII: PID anziché identificatori diretti, tornitura.
Data residency: partizionamento per regione, crittografia in pace/in viaggio.
Diritto di eliminazione: tombstone/redaction event con prova.
Accesso e controllo: ACL di ruolo, registri di lettura, report firmati per i controlli.

13) SLI/SLO per pipeline analitiche

SLI (esempio):
  • Freshness (mediana della laga da «osserved _ at» fino all'arrivo in Gold),
  • Completeness (% degli eventi senza buchi secondo le aspettative K-confermations),
  • Cortrectness (% degli eventi convalidati da diagrammi/regole),
  • Reorg handling success (% di invalidità/sovraccarico corretto),
  • Serve latency (p95 richieste di vetrine/dashboard).
SLO (punti di riferimento):
  • Freshness p95 ≤ 3 min (≤), 15 min (batch).
  • Completeness ≥ 99. 7%, Correctness ≥ 99. 9%.
  • Reorg handling success ≥ 99. 9%.
  • Serve p95 ≤ 500 ms (vetrine principali).

14) Osservazione dei dati e lineage

Data Lineage - Dal dashbord all'evento crudo (column-level).
Segnali di qualità: completeness, uniqueness, integrity referential, schema draft.
Alert: «guasti silenziosi» (nessun nuovo dato), corse di distribuzione, crescita di campi «unknown».

15) Dashboard (modelli)

A. Cross-Chain Ops (real-time/ora):
  • Success-Rate, p95 Finality, Relay Availability, Challenge/Reorg, backlog, error budget burn.
B. Liquidità & Cost (giorno/settimana):
  • TVL, Net Flow per chain, cost-per-transfer, utilization, assicurazione.
C. Product & Growth (settimana/mese):
  • MAU/DAU (dedup), cross-chain retention, vortici di canale, QoT.
D. Risk & Compliance (settimana):
  • Fraud/Dispute Rate, sanctions hits, high-risk share, velocità di processo.

16) Regolamenti operativi e playbook

Incidente: lega di freschezza> SLO

Controlla connettori/indici, passa alla riserva, attiva la modalità di degrado (le vetrine mostrano «ultimo finalizzato»), eskalate al proprietario della sorgente.

Incidente: picco di reorg/challenge

Aumenta K-confermations/finestra del contenzioso, abilita «delayed finalization» per le somme maggiori, avvisa il ponte/operatori.

Incidente: divario valuta/asset

Congelare le coppie interessate, ripristinare l'elenco, ritoccare la normalizzazione USD e pubblicare il report.

Incidente: salto Fraud/Dispute

Stringere i limiti/scorciatoie, attivare la gelosia manuale high-risk, formattare il modello sul pattern fresco.

17) Esempio di configurazione (pseudo-YAML)

Finestre di finalizzazione per reti

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

Regole di idempotenza e deduplicazione

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

SLO di pipeline

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) Assegno foglio di implementazione

1. Fissare origini, schemi, finestre e proprietari.
2. Attivare Idampotenza e reorg-handling (states + replay).
3. Costruisci un nucleo di modelli (transfers/bridges/onchain _ events/kyc/payouts).
4. Personalizzare le guide delle risorse e la normalizzazione FX.
5. Definire i piplini SLI/SLO e i dashboard.
6. Implementare entity resolution e privacy-by-design.
7. Includere gli screening anti-frod e il regolamento degli incidenti.
8. Eseguire backfill e test su valigette storiche reorg/challenge.
9. Rivedere regolarmente gli schemi, il peso delle metriche e le fonti.

19) Glossario

Finality - Irreversibilità dello stato/evento.
Reorg è l'intersezione della catena che porta all'annullamento di una parte dei blocchi.
Challenge perod è una finestra di contestazione nei modelli ottimistici.
Entity resolution: mappatura indirizzi/account di un'unica entità.
GTV/TVL - volume di transazioni/valore bloccato.
Completeness/Freshness/Corrrectness sono le metriche di base della qualità dei dati.

In sintesi, l'analista a catena non è solo un riepilogo delle metriche, ma una disciplina controllata: un unico schema di eventi, una finalizzazione corretta, pipline sostenibili, privacy, anti-frod e vetrine comprensive. Seguendo questo framework, l'ecosistema ottiene una visione davvero «completa» del valore, dei rischi e della crescita, dal blocco crudo alla soluzione aziendale.

Contact

Mettiti in contatto

Scrivici per qualsiasi domanda o richiesta di supporto.Siamo sempre pronti ad aiutarti!

Telegram
@Gamble_GC
Avvia integrazione

L’Email è obbligatoria. Telegram o WhatsApp — opzionali.

Il tuo nome opzionale
Email opzionale
Oggetto opzionale
Messaggio opzionale
Telegram opzionale
@
Se indichi Telegram — ti risponderemo anche lì, oltre che via Email.
WhatsApp opzionale
Formato: +prefisso internazionale e numero (ad es. +39XXXXXXXXX).

Cliccando sul pulsante, acconsenti al trattamento dei dati.