Come gli oracoli DeFi aggregano e pubblicano i prezzi

L’oracolo collega informazioni esterne alla blockchain con il codice eseguito onchain. Un protocollo di prestito può leggere un feed per valutare le garanzie; un contratto derivato può usare un riferimento per il regolamento o un limite di rischio. Il contratto legge il dato pubblicato sulla chain, ma non consulta da solo tutti i book esterni per scegliere il prezzo equo.

“Prezzo” può indicare una coppia asset/valuta di quotazione, un tasso di rimborso del protocollo o un’altra misura. Non coincide automaticamente con il prezzo ottenibile vendendo una posizione grande. La guida a impatto e slippage degli swap DEX e il confronto tra mark price e ultimo scambio illustrano altre differenze. Questa guida tratta i comuni feed push EVM, non una regola universale DeFi.

Nel modello Offchain Reporting di Chainlink, i nodi oracle si scambiano osservazioni offchain e concordano un report. Un quorum lo firma; un transmitter lo invia in una transazione; l’aggregator verifica le firme ed espone risposta, ID del round e timestamp. La documentazione Offchain Reporting descrive la mediana delle osservazioni resa disponibile da quel disegno.

Il consumer di solito non ripete tutta l’aggregazione: chiama latestRoundData() sull’indirizzo proxy del feed. L’aggregator dietro al proxy può cambiare. Controlla la rete e il feed esatti nella guida EVM e nella API reference. Più nodi non implicano fonti indipendenti; possono dipendere dagli stessi exchange o provider.

Molti feed push combinano soglia di deviazione e heartbeat. Una variazione percentuale definita dal valore pubblicato in precedenza può attivare un nuovo report; l’heartbeat può richiedere un aggiornamento dopo un intervallo anche senza un grande movimento. La directory Data Feeds corrente e la pagina degli indirizzi riportano parametri per asset, rete e feed.

Sono trigger specifici del feed, non la promessa di aggiornare ogni N secondi. Una variazione piccola può non superare la soglia e il report richiesto deve ancora essere raccolto, trasmesso e incluso in un blocco. L’heartbeat quindi non garantisce un orario d’arrivo esatto né impedisce che il dato diventi obsoleto. Il protocollo deve fissare una propria età massima adatta alla velocità dell’asset e all’uso.

latestRoundData() restituisce ID round, answer, startedAt, updatedAt e answeredInRound; la API reference indica che l’ultimo campo è deprecato. answer è un intero in formato fixed-point, non necessariamente un importo in dollari leggibile. Leggi decimals() e la descrizione del feed selezionato. Se un feed BTC/USD ipotetico restituisce 6,725,000,000,000 con 8 decimali, vale 67.250 dollari per BTC.

I decimali del feed non sono quelli del token. Una quantità ERC-20 può avere 18 decimali mentre la risposta prezzo ne ha 8; scala ogni valore secondo la sua unità prima di moltiplicare. BTC/USD significa dollari per bitcoin; USD/BTC inverte l’unità. Per derivare una coppia, scala entrambi i feed e dividi nell’ordine giusto; l’esempio di denominazione ricava BTC/EUR da BTC/USD ed EUR/USD.

updatedAt indica quando è stato aggiornato il round più recente. Il consumer può confrontarlo con il timestamp del blocco corrente e rifiutare valori più vecchi dell’età massima definita dall’applicazione. In base al feed può verificare anche un orario non nullo, un answer positivo per un asset dal prezzo positivo e limiti ragionevoli. Un limite troppo stretto può rifiutare un movimento legittimo.

Immagina un mercato di prestiti ipotetico che accetta quattro unità di garanzia con fattore del 75%. L’ultimo answer è 200,000,000,000 con 8 decimali, cioè $2.000 per unità; il limite di prestito è 4 × $2.000 × 75% = $6.000. Se il mercato scende a $1.820, il calo è del 9%. Con ipotesi di deviazione al 10% e heartbeat a 60 minuti, potrebbe non essere ancora stato richiesto un nuovo report; al prezzo più basso il limite è $5.460.

Se l’applicazione rifiuta prezzi più vecchi di cinque minuti e il round ha venti minuti, può bloccare nuovi prestiti invece di usare $2.000. Il controllo non aggiorna il feed: cambia le operazioni ammesse quando il dato supera l’età consentita. Prestito, prelievo, liquidazione e rimborso possono avere risposte diverse, perché bloccare tutto può creare danni. Numeri e trigger sono ipotetici, non parametri attuali o raccomandazioni.

Su molte L2 gli utenti inviano transazioni tramite un sequencer. Durante un guasto o il ripristino, le transazioni possono ritardare, l’uso normale interrompersi e ordini in attesa eseguirsi dopo un cambiamento di mercato. Una risposta di prezzo apparentemente recente non prova che il percorso di esecuzione fosse disponibile o che tutti potessero agire insieme.

Chainlink documenta un feed separato di uptime del sequencer L2: answer == 0 significa attivo e answer == 1 fermo. startedAt registra il cambio di stato; l’esempio consumer lo verifica e attende un periodo di grazia definito dall’applicazione dopo il ripristino prima di leggere il prezzo. Controlla rete e indirizzo nella guida L2 Sequencer Uptime Feeds. La grazia non garantisce prezzo aggiornato o completamento delle transazioni in coda.

Quorum, mediana, deviazione, heartbeat, limite d’età e stato del sequencer rispondono a domande circoscritte. Non garantiscono liquidità, identità esatta dell’asset, indipendenza dei provider o prezzo eseguibile per una certa quantità. Un timestamp recente può accompagnare un dato sbagliato o manipolato; un dato vecchio può restare vicino al mercato in una fase tranquilla.

Nessun trigger elimina salti di prezzo, congestione o bug in scala, coppia, freschezza e liquidazione. Le indicazioni per selezionare Data Feeds di qualità raccomandano di valutare liquidità e dipendenze e gestire dati obsoleti, ritardati, mancanti o inattesi. Restano rischi di contratto, governance, bridge, garanzia e liquidazione. Il prezzo oracle di una stablecoin non garantisce il rimborso alla pari; leggi la guida al depeg.

Identifica chain, proxy del feed, coppia asset, valuta di quotazione, decimali di answer e indirizzo del contratto. Verifica che la descrizione corrisponda all’asset e non copiare indirizzi da un’altra rete. Se serve, esamina modello delle fonti e cronologia degli aggiornamenti. Chainlink segnala che gli aggregator possono differire tra reti: controlla codice e configurazione.

Poi ricostruisci come il contratto usa la risposta: conversione delle unità, controllo updatedAt, età massima e comportamento con valori non validi. Su L2 verifica feed uptime, orario di ripristino, grazia e transazioni ritardate. Valuta sul contratto reale i casi di feed obsoleto e di guasto/ripresa. Per distinguere i campi prezzo, consulta mark price e ultimo scambio.