Pyth è un oracle “first-party”: i dati di prezzo originali sono pubblicati autonomamente sulla rete da exchange, market makers, istituzioni finanziarie… e poi sintetizzati e distribuiti multi-chain secondo il modello pull oracle (applicazione per recuperare i prezzi quando necessario). A partire da luglio 2025, Pyth ha annunciato 125+ fornitori di dati, 1.930+ price feeds, 107+ blockchain collegate, ~6,95M richieste di Entropy, $20,9B+ TVS e 946M+ PYTH in staking per OIS (Oracle Integrity Staking).
Nota sulla frase “non è necessario un intermediario”: Pyth elimina i “nodi” che raccolgono dati di terze parti alla fonte dei dati (poiché sono gli stessi fornitori a pubblicare i prezzi). Tuttavia, il sistema ha ancora strati di infrastruttura intermedia come Pythnet (appchain stile Solana) e Wormhole per firmare e trasferire dati multi-chain.
⸻
Architettura & componenti principali
• Publisher (Fornitori di Dati): exchange CEX/DEX, MMs, istituzioni finanziarie (ad esempio Wintermute, Jane Street, Revolut…). Pubblicano i propri prezzi su Pyth.
• Pythnet (appchain): chain dedicata (stile Solana) dove i prezzi sono raccolti & standardizzati; ogni feed ha prezzo, affidabilità (intervallo di confidenza), timestamp, ecc.
• Sintesi & firma: Pyth utilizza un modello di sintesi che tiene conto dell'affidabilità/peso di molte fonti e crea un prezzo sintetico insieme a un intervallo di confidenza.
• Wormhole + Hermes (Servizio Prezzi): i prezzi firmati su Pythnet sono impacchettati in attestazioni (VAA). Le applicazioni su EVM/SVM/... recuperano questi aggiornamenti (tramite Hermes) e aggiornano on-chain al momento della transazione necessaria.
• Contratti di consumo: il tuo contratto chiama updatePriceFeeds + paga la fee di aggiornamento e poi legge il prezzo tramite API come getPriceNoOlderThan.
⸻
Flusso di dati “pull oracle” (5 passaggi)
1. I publisher inviano i prezzi grezzi a Pythnet.
2. Pythnet sintetizza → crea prezzo + confidenza e firma.
3. Hermes serve gli “aggiornamenti di prezzo” firmati.
4. Nella transazione, dApp recupera i byte di aggiornamento da Hermes → invia al contratto Pyth sulla chain di destinazione (paga la fee di aggiornamento).
5. dApp legge il prezzo subito dopo l'aggiornamento (controlla “nuovo abbastanza” & confidenza).
Vantaggi:
• Bassa latenza, aggiornamenti super veloci (sub-secondo; alcuni documenti indicano fino a ~400ms/volta).
• Pagare quando usato (non tutti i blocchi inviano prezzi).
• Scegliere il momento dell'aggiornamento nella logica di transazione, utile per derivati/AMM rapidi.
Compromesso:
• dApp deve orchestrare il passo di aggiornamento nella transazione (se non lo fa, il prezzo potrebbe diventare “stale”). Pyth fornisce Scheduler per automatizzare.
⸻
Modello di dati & sicurezza
• Prezzo + Confidenza: Ogni feed restituisce prezzo e incertezza (intervallo di confidenza) — “intervallo” utilizzato per gestire il rischio, ad esempio ampliando il margine durante alta volatilità (liquidazione, protezione oracle…).
• Stato del prezzo: Usare solo quando lo stato = trading; se è Halted/Auction/Unknown non dovrebbe essere usato direttamente.
• Sicurezza cross-chain: Aggiornamenti dei prezzi con firma/attestazione tramite Wormhole; il contratto Pyth sulla chain di destinazione verifica l'origine prima di registrare.
• Oracle Integrity Staking (OIS): meccanismo di stake/slash per vincolare il comportamento corretto del sistema oracle; diritti di governance & distribuzione delle fee sono decisi dalla DAO. (La distribuzione dei token e il meccanismo OIS sono pubblicamente descritti).
• Bug bounty: programma di bounty su larga scala per incentivare la scoperta di vulnerabilità di sicurezza.
⸻
Performance & copertura (al 07/2025)
• 1.930+ price feeds, 107+ chains, 125+ fornitori di dati; aggiornamenti sub-secondo, e un Insights Hub/KPI dashboard per osservare le performance & la copertura in tempo reale.
⸻
Costi & economia dei dati
• Update Fee: il contratto quando chiama l'aggiornamento del prezzo paga una fee di aggiornamento (compensa i costi di trasferimento dati & infrastruttura).
• Data Fees: il protocollo di utilizzo dei dati potrebbe dover pagare data fees (designato per compensare i fornitori di dati e finanziare le operazioni della rete). I parametri sono regolati dalla governance DAO.
• Token PYTH: per governance, staking OIS e processi di distribuzione economica. Il documento di distribuzione del token ufficiale specifica il programma & gli obiettivi di distribuzione.
⸻
Prodotto complementare di Pyth
• Benchmarks (dati storici): interrogazione dei prezzi storici firmati (standardizzati) per backtest, risolvere contratti, report…
• Entropia (RNG on-chain): servizio di randomness veloce & economico con callback conveniente per giochi/NFT/lotterie… (documenti + blog & guida all'integrazione).
• Express Relay: meccanismo per trasferire i prezzi nel blocco prioritario & prevenire MEV per app sensibili alla latenza.
⸻
Confronto veloce: Pyth vs “push oracle” tradizionale
• Fonti di dati: Pyth: first-party (publisher autonomamente registrato); tradizionale: gli operatori di nodo raccolgono da API/gateway di dati.
• Meccanismo di distribuzione: Pyth: pull on-demand → paga solo quando utilizzato, ottimale per casi d'uso che richiedono prezzi “tempestivi”; push: i prezzi vengono inviati secondo il programma ogni blocco/epoca (più facili da usare ma a volte meno flessibili/costi di base).
• Latenza: Pyth mira a sub-secondo / ~400ms; il push è generalmente più lento a causa del programma di aggiornamento. (Il numero ~400ms è menzionato nei documenti di integrazione della chain).
⸻
Nota tecnica & migliori pratiche per l'integrazione
• Controllo della “staleness”: utilizzare API getPriceNoOlderThan/“no older than X” per garantire che il prezzo sia sufficientemente recente; fallire la transazione se troppo vecchio.
• Usare la confidenza in modo appropriato: impostare una soglia massima per confidenza/prezzo o utilizzare prezzo ± k*confidenza per liquidazione/trigger per evitare manipolazioni oracle durante forti fluttuazioni.
• Gestione dello stato del feed: ignorare quando lo stato != trading (ad esempio Halted/Auction).
• Automazione degli aggiornamenti: con casi d'uso che richiedono aggiornamenti continui, utilizzare Scheduler o il servizio di lavoro per inviare VAAs regolarmente.
• Multi-sorgente di backup: anche se è first-party, dovresti sempre avere un fallback (ad esempio feed secondari o regole di congelamento della posizione) per aumentare la liveness.
⸻
Conclusione
Pyth mostra un approccio first-party + pull oracle: bassa latenza, costi su richiesta, intervallo di confidenza trasparente, insieme a un'infrastruttura multi-chain ampia. In cambio, dApp deve attivamente recuperare i prezzi e gestire i rischi in modo appropriato (staleness, stato, confidenza). Con Benchmarks, Entropy ed Express Relay, Pyth sta espandendo da “prezzo in tempo reale” a un livello di dati/utilità completo per la finanza on-chain.
@Pyth Network hashtag #PythRoadmap e $PYTH
