---
title: "Attacchi agli oracoli"
description: "Un attacco a un oracolo sfrutta dati esterni manipolabili, obsoleti, scalati in modo errato o mal configurati affinché un protocollo conceda prestiti, emetta, rimborsi, regoli o liquidi a un valore non sicuro."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Attacchi agli oracoli

> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

<a id="answer"></a>

## Risposta diretta

Un attacco a un oracolo sfrutta il confine di fiducia dei dati di un protocollo affinché un prezzo, tasso di cambio, indice, valore patrimoniale netto o indicatore di stato determini un'azione economicamente non sicura. L'attaccante può manipolare una sede poco liquida, compromettere reporter o chiavi, sfruttare le regole di aggregazione o aggiornamento oppure combinare l'assenza, nel consumer, di controlli su freschezza, unità, intervallo e fallback con capitale preso in prestito. Un feed obsoleto o mal configurato può causare la stessa perdita senza che l'operatore dell'oracolo sia malevolo; l'analisi dell'incidente deve quindi distinguere il percorso di attacco dalla modalità di guasto.

Il confronto decisivo non riguarda l'ampiezza del movimento di un prezzo visualizzato. Occorre stabilire se il costo e il rischio di influenzare l'esatto valore consumato dal contratto siano inferiori al valore eseguibile ottenibile tramite prestito, emissione, rimborso, regolamento o liquidazione. La liquidità flash può finanziare un percorso atomico, ma non crea il confine di fiducia difettoso né è necessaria per sfruttarlo.

Il valore di un oracolo non è inoltre necessariamente un prezzo di mercato eseguibile. Ogni verifica deve collegarlo a chain, blocco, indirizzo del feed o del pool, orientamento tra attività base e quotata, decimali, timestamp, metodo di aggregazione, dimensione del mercato e funzione consumer. Una firma valida prova chi ha comunicato i dati secondo uno schema; da sola non prova freschezza, indipendenza delle fonti, profondità del mercato o correttezza economica.

<a id="mechanism"></a>

## Come funziona

1. Fissare il deployment: chain, blocco, contratto e funzione consumer, contratti degli asset, proxy del feed o pool, aggregatore, attività base e quotata, decimali, amministratori e stato dell'upgrade.
2. Mappare l'intero percorso di fiducia da exchange, pool o reporter, attraverso aggregazione, firme, proxy o adapter e fallback, fino alla logica consumer; registrare sedi, operatori, chiavi e governance condivisi, anziché contare etichette diverse come fonti indipendenti.
3. Riprodurre esattamente la lettura onchain: risposta, metadati del round, timestamp, confidenza o stato ove applicabile, normalizzazione decimale, inversione della quotazione, stato del sequencer e periodo di grazia, età massima, limiti di deviazione e trattamento dei valori nulli o negativi.
4. Costruire il registro dell'esposizione del consumer: fattore di garanzia, soglia di liquidazione, limiti di prestito e offerta, liquidità disponibile, debito, limiti di emissione o rimborso, close factor, bonus di liquidazione e ogni azione abilitata dal valore.
5. Modellare la manipolazione a dimensione eseguibile utilizzando riserve, liquidità attiva, osservazioni, finestra e convenzione di ponderazione, commissioni, arbitraggio, ordinamento dei blocchi, capitale flash o proprio, perdite in chiusura, gas, MEV e liquidatori concorrenti.
6. Verificare controlli e stati di guasto: fonti indipendenti, cardinalità del TWAP, limiti, circuit breaker, autorità di pausa, timelock, fallback obsoleto o divergente, perdita di reporter o chiavi, indisponibilità del sequencer L2, gap di prezzo legittimi e comportamento fail-open rispetto a fail-closed.
7. Monitorare e riconciliare round canonici, modifiche di proxy e configurazione, divergenza tra fonti, azioni del protocollo, liquidazioni, crediti inesigibili e decisioni di pausa e ripristino; ripetere l'analisi dopo cambiamenti di liquidità, quotazione, upgrade o regime di mercato.

Una lettura spot di un AMM può spesso essere modificata all'interno di una singola transazione. Una media ponderata nel tempo può aumentare il costo imponendo un'influenza su più osservazioni, ma la sua sicurezza dipende dalla convenzione aritmetica o basata sui tick, dalla finestra, dalla cardinalità delle osservazioni, dalla distribuzione della liquidità e dal controllo dei blocchi. Una mediana può escludere alcuni outlier, ma sedi a monte correlate o la perdita del quorum possono comunque compromettere sicurezza o disponibilità. I parametri di heartbeat e deviazione regolano quando alcuni feed pubblicano; i consumer necessitano comunque di una propria politica di freschezza e validità.

<a id="example"></a>

## Esempi svolti

- **Spot a prodotto costante.** Si ignorino le commissioni in un pool con `1,000,000 ABC` e `1,000,000 USDC`, per cui `k = 10^12`. Un prezzo marginale obiettivo di `9 USDC/ABC` richiede riserve di `3,000,000 USDC` e `333,333.333333 ABC`: il trader immette `2,000,000 USDC` e riceve `666,666.666667 ABC`. Il prezzo marginale finale è `3,000,000 / 333,333.333333 = 9`, mentre il prezzo medio di esecuzione è `2,000,000 / 666,666.666667 = 3 USDC/ABC`. Per contro, un input di `5,000,000 USDC` lascia riserve di `6,000,000` e `166,666.666667`, producendo un prezzo marginale di `36`, non `9`. Commissioni effettive, arbitraggio, liquidità concentrata e chiusura modificano il registro.
- **Convenzione TWAP.** In dieci osservazioni uguali di un minuto, nove prezzi sono `100` e uno è `160`. Il TWAP aritmetico didattico è `(9 * 100 + 160) / 10 = 106`, soltanto il `6%` sopra 100, sebbene l'ultimo spot sia superiore del `60%`. Per portare tale media aritmetica a `130` lasciando le altre nove osservazioni a 100, l'osservazione manipolata deve essere `400`. La media dei tick di Uniswap v3 è geometrica, a differenza di questo esempio aritmetico; il consumer deve riprodurre la convenzione effettivamente implementata.
- **Mediana e quorum.** Sette osservazioni normalizzate sono `[99, 100, 100, 101, 101, 500, 600]`; la loro mediana è `101`, perciò due report estremi non spostano il risultato fuori dal gruppo onesto. Se l'accettazione richiede cinque report attivi e tre reporter onesti vanno offline, ne restano soltanto `4 < 5`: la resistenza agli outlier non garantisce disponibilità e il comportamento di fallback diventa parte del modello di sicurezza.
- **Obsolescenza e liquidazione indebita.** Un feed con otto decimali restituisce il valore grezzo `140,000,000,000`, ossia `1,400`, ma ha un'età di `17 minutes` rispetto al massimo di `15 minutes` previsto dal consumer e deve quindi essere respinto. Se il valore obsoleto viene comunque utilizzato per `10 ETH`, una soglia di liquidazione del `75%` e un debito di `12,000`, l'health factor è `10 * 1,400 * 0.75 / 12,000 = 0.875`; con un prezzo aggiornato di `2,000`, è `1.25`. Una successiva correzione del prezzo non annulla una liquidazione già completata.

<a id="risks"></a>

## Rischi

- Chain, asset, feed, proxy, pool o indirizzo del consumer errati.
- Attività base e quotata invertite o denominazione incoerente.
- Normalizzazione errata dei decimali di feed, token e formato fixed-point interno.
- Accettazione di dati obsoleti o confusione tra trigger di heartbeat e deviazione e garanzie di freschezza.
- Accettazione di round incompleti, stato non valido o risposte nulle, negative, limitate o fuori intervallo.
- Un prezzo spot di un'unica sede poco liquida controlla un'ampia esposizione del protocollo.
- Finestra TWAP troppo breve, rada, ponderata in modo errato o letta nella direzione sbagliata.
- Cardinalità, inizializzazione, interpolazione o fallback delle osservazioni fraintesi.
- La liquidità concentrata o just-in-time fa sì che il valore nominale del pool rappresenti in modo errato il costo dell'attacco.
- Più feed condividono exchange, fornitori di dati, operatori, chiavi o piano di controllo.
- Il guasto di reporter, exchange, API, firmatario, rete o quorum elimina freschezza o integrità.
- Indisponibilità del sequencer L2 o periodo di grazia dopo il ripristino assente o errato.
- Fallback obsoleto, circolare, correlato, scalato diversamente o semanticamente incompatibile.
- Liquidità flash e componibilità atomica rendono economicamente sfruttabile un'influenza temporanea.
- Ordinamento degli aggiornamenti, frontrunning, sandwich, backrunning o MEV di liquidazione modifica i pagamenti.
- Fattori di garanzia, soglie, limiti, bonus e liquidità disponibile amplificano un piccolo errore.
- Compromissione di governance, amministratore, guardian, multisig o chiave di firma altera il percorso di fiducia.
- Errori di proxy, aggregatore, adapter, upgrade, storage o configurazione selezionano il valore sbagliato.
- Circuit breaker o logica fail-closed bloccano prestiti, rimborsi o liquidazioni legittimi durante le crisi.
- Pausa, ripristino, riconciliazione dei conti, allocazione dei crediti inesigibili o contenimento tra protocolli falliscono.

<a id="misconceptions"></a>

## Idee errate comuni

- **«Ogni attacco a un oracolo compromette la rete di oracoli».** Molti guasti sfruttano una fonte poco liquida, un valore obsoleto, unità errate, un adapter non sicuro o la logica consumer mentre la rete di reporting opera come configurata.
- **«Più feed o feed decentralizzati garantiscono un prezzo corretto».** Indipendenza, qualità delle fonti, quorum, freschezza, unità, aggregazione e controlli del consumer restano necessari.
- **«Un TWAP rende impossibile la manipolazione».** Ne modifica durata e costo; una finestra debole, poche osservazioni, scarsa liquidità o controllo dei blocchi possono restare sfruttabili.
- **«Vietare i flash loan elimina il rischio dell'oracolo».** I flash loan sono un meccanismo di finanziamento. Capitale proprio, credito, prestiti tra protocolli, compromissione dei reporter ed errori di configurazione restano possibili.
- **«Il recupero del prezzo annulla il danno».** Prestiti, emissioni, rimborsi, regolamenti e liquidazioni canonici persistono, a meno che il protocollo disponga di un processo di ripristino separato e autorizzato.

<a id="related"></a>

## Argomenti correlati

- [Oracolo](/it/crypto/oracle/)
- [Protocollo di prestito](/it/crypto/lending-protocol/)
- [Liquidazione](/it/crypto/liquidation/)

<a id="sources"></a>

## Fonti

- [SC03:2026 Price Oracle Manipulation](https://scs.owasp.org/sctop10/SC03-PriceOracleManipulation/) - OWASP Smart Contract Security (consultato: 2026-08-13)
- [Chainlink Data Feeds](https://docs.chain.link/data-feeds) - Chainlink Documentation (consultato: 2026-08-13)
- [Data Feeds API Reference](https://docs.chain.link/data-feeds/api-reference) - Chainlink Documentation (consultato: 2026-08-13)
- [L2 Sequencer Uptime Feeds](https://docs.chain.link/data-feeds/l2-sequencer-feeds) - Chainlink Documentation (consultato: 2026-08-13)
- [Uniswap v2 Core](https://app.uniswap.org/whitepaper.pdf) - Uniswap Labs (consultato: 2026-08-13)
- [Price Oracles](https://developers.uniswap.org/docs/protocols/v3/concepts/price-oracles) - Uniswap Developers (consultato: 2026-08-13)
- [Oracles](https://aave.com/docs/aave-v3/smart-contracts/oracles) - Aave Protocol Documentation (consultato: 2026-08-13)
- [Flash Loans](https://aave.com/docs/aave-v3/guides/flash-loans) - Aave Protocol Documentation (consultato: 2026-08-13)

Source: https://wiki.fcontext.com/it/crypto/oracle-attack/index.mdx