API3

Informazioni su API3 (API3)

Che cos'è API3 (API3)?

API3 è un progetto di oracolo costruito su un'unica idea controcorrente: l'azienda che possiede i dati dovrebbe essere quella che li porta on-chain. Invece di pagare una rete di operatori di nodi terzi per recuperare dati da un'API e inoltrarli, API3 fa firmare i propri dati direttamente al fornitore dell'API stesso. Il progetto chiama questo un oracolo di prima parte (first-party oracle), termine introdotto dallo stesso whitepaper di API3.

La seconda idea è più recente ed è quella con cui il progetto si presenta oggi. Ogni aggiornamento di un oracolo crea un valore che qualcuno può catturare, di solito un bot searcher che corre per liquidare una posizione nel momento esatto in cui un prezzo si muove. API3 chiama questo Oracle Extractable Value, vende il diritto di eseguire quegli aggiornamenti e restituisce l'80 per cento dei ricavi risultanti all'applicazione il cui feed ha creato l'opportunità. La formula stessa del progetto è "oracoli che ti pagano".

API3 è il token di governance e staking della API3 DAO, che controlla i parametri e la tesoreria del progetto.

Fonti ufficiali:

• Api3
• Documentazione Api3
• Whitepaper di API3
• api3dao su GitHub
• API3 su Etherscan

Chi ha fondato API3? (Storia)

API3 è stata lanciata alla fine del 2020 da Heikki Vanttinen, Burak Benligiray e Sasa Milic, con il token operativo da dicembre 2020. Nel luglio 2021 il progetto ha lanciato la sua DAO autorevole insieme allo staking, cosicché i possessori di token che facevano staking nel pool della DAO ricevevano un peso di governance proporzionale alla loro quota del pool.

La base tecnica era Airnode, un nodo oracolo serverless che un fornitore di API poteva distribuire senza gestire infrastrutture blockchain o detenere criptovalute, il che ha reso praticabile il modello di prima parte. Da lì API3 ha costruito le dAPI, feed di dati aggregati assemblati da più fonti di prima parte, e poi l'Api3 Market, una vetrina self-service dove uno sviluppatore può acquistare un feed con i parametri di aggiornamento di cui ha bisogno e integrarlo senza contattare nessuno.

L'OEV è arrivato dopo. API3 ha costruito la OEV Network, un rollup Arbitrum Nitro che gestiva aste pubbliche per i diritti di aggiornamento degli oracoli. Quella catena di aste pubbliche e il suo banditore sono stati ritirati, con i fondi trasferiti fuori entro la fine di novembre 2025, e API3 è passata a un modello a due binari: aste private condotte con searcher partner su dati non ritardati, ed endpoint pubblici di dati firmati su dati ritardati contro cui chiunque può competere. Il meccanismo on-chain sottostante, il contratto Api3ServerV1OevExtension, è rimasto.

Vale la pena conoscere due sviluppi più recenti. API3 ora agisce come curatore di vault su Morpho, gestendo propri mercati di prestito, e ha introdotto AirnodeHub, un marketplace ad accesso anticipato in cui agenti autonomi scoprono, chiamano e pagano per le API, con la fonte dati pagata per ogni risposta.

Come funziona API3

Il sistema ha tre componenti mobili che si collegano in modo pulito.

1. I dati di prima parte raggiungono la chain Ogni fornitore di API esegue il software Airnode feed, che interroga continuamente la propria API e firma il risultato con il proprio wallet Airnode. Quei dati firmati vengono inviati a una Signed API, che li serve pubblicamente. Poiché i dati sono firmati alla fonte, chiunque può verificare chi li ha prodotti, e nessun intermediario deve essere considerato affidabile per averli inoltrati fedelmente.

2. I feed vengono aggregati on-chain Ogni fornitore alimenta un feed a fonte singola, identificato da un beacon ID derivato dal suo indirizzo Airnode e da un template ID. Più beacon vengono combinati in un beacon set, e il valore letto da un'applicazione è la mediana on-chain dei feed contribuenti, con il timestamp pari alla mediana dei loro timestamp. L'aggregazione avviene on-chain anziché fuori catena, una scelta di sicurezza deliberata. Le applicazioni leggono il risultato tramite un contratto Api3ReaderProxyV1, che implementa anche un'interfaccia aggregatore ampiamente usata, così da poter essere inserito in contratti scritti per un altro oracolo.

3. Gli aggiornamenti vengono innescati e messi all'asta I feed si aggiornano in base a due condizioni: una soglia di deviazione, cioè il valore off-chain si è mosso oltre una percentuale configurata rispetto a quello on-chain, e un intervallo di heartbeat, offerto sull'Api3 Market come un gap massimo di un giorno tra gli aggiornamenti e avviato due minuti prima per ridurre la probabilità di revert al limite. Oltre a ciò, API3 vende il diritto esclusivo di eseguire aggiornamenti di valore. Un searcher che vince può aggiornare il feed e agire sull'opportunità risultante in modo atomico, senza un'asta di gas contro rivali, e l'applicazione riceve l'80 per cento di quanto pagato dal searcher.

Il compromesso è dichiarato apertamente nella documentazione di API3: le applicazioni che usano questo sistema vedono un ritardo da 0 a 15 secondi nel loro feed base, in cambio dei ricavi OEV che quel ritardo rende catturabili.

Componenti chiave dell'ecosistema

• Airnode e Airnode feed, il software che un fornitore di API esegue per firmare e pubblicare i propri dati
• Le Signed API, gli endpoint pubblici che servono dati firmati dai fornitori
• Beacon e beacon set, i feed a fonte singola e i loro aggregati on-chain
• Api3ReaderProxyV1, il contratto proxy deterministico letto da un'applicazione, distribuito per applicazione quando gli OEV Rewards sono abilitati
• Api3ServerV1OevExtension, il contratto che protegge gli aggiornamenti OEV dietro una firma e un pagamento validi
• Api3 Market, la vetrina self-service per acquistare feed con i parametri di aggiornamento scelti
• OEV Rewards, il pagamento mensile dell'80 per cento dei ricavi OEV alle applicazioni partner, versato nel token di gas nativo della chain su cui gira l'applicazione
• I mercati curati da Api3, dove API3 cura vault di prestito su Morpho e trattiene l'intero OEV generato da quei mercati
• AirnodeHub, il marketplace ad accesso anticipato per agenti che scoprono, chiamano e pagano per le API
• La API3 DAO e il suo pool di staking

Utilità del token API3

Il token API3 presenta un accoppiamento insolitamente stretto tra governance e rischio:

• Lo staking nel pool della DAO è ciò che conferisce il peso di governance, proporzionale alla quota dello staker nel pool
• I token in staking fungono anche da collaterale a garanzia della copertura di servizio del progetto, quindi gli staker portano un'esposizione economica al fallimento di un feed invece di limitarsi a votare a riguardo
• Le ricompense vengono coniate verso il pool, rendendo API3 un token inflazionistico senza tetto fisso
• Il tasso di ricompensa viene adeguato settimanalmente verso una proporzione target di supply in staking, salendo quando il pool è sotto-staked e scendendo quando è ben finanziato
• L'unstaking è soggetto a un periodo di attesa di sette giorni, che esiste per attenuare lo spam di proposte e la cattura della governance dell'ultimo minuto
• I token delle ricompense vengono bloccati per un anno secondo un calendario a rotazione dopo la ricezione

Due sfumature contano per il lettore. Lo staking espone il capitale principale a richieste di copertura, quindi non è un rendimento privo di rischio. E gli OEV Rewards vengono pagati alle applicazioni nel token di gas nativo della loro chain, non in API3, quindi il token non è un diritto su quel flusso di ricavi.

Cosa rende API3 unica?

Eliminare l'intermediario è l'intera tesi. Nel modello di API3 non esiste una classe separata di operatori di nodi tra la fonte dei dati e la chain, il che significa nessun secondo sistema di consenso i cui incentivi possano divergere da quelli dei dati, e nessun operatore che possa essere corrotto indipendentemente dal fornitore. La documentazione di API3 sostiene che i design con intermediari creano due punti di fallimento, i fornitori e i relayer, mentre un design di prima parte ne ha solo uno.

Il lavoro sull'OEV è la parte commercialmente più distintiva. API3 ha trasformato un costo che altre applicazioni perdevano silenziosamente verso i bot in una voce di ricavo per l'applicazione, dichiarando una ripartizione specifica invece di una vaga promessa. Il progetto va oltre e sostiene che i revisori dovrebbero trattare la mancata cattura dell'OEV come un rilievo, una posizione aggressiva ma coerente.

In cosa API3 differisce da oracoli simili

• I dati sono firmati dal fornitore dell'API stesso, non recuperati da operatori di nodi terzi
• L'aggregazione avviene on-chain come mediana dei feed dei fornitori, invece che concordata fuori catena e pubblicata come valore singolo
• I feed si acquistano in self-service tramite un mercato con parametri di deviazione e heartbeat scelti, invece che negoziati per cliente
• Il contratto lettore implementa un'interfaccia aggregatore comune, quindi la migrazione da un altro oracolo di solito non richiede modifiche al contratto
• Il valore estratto attorno agli aggiornamenti viene messo all'asta e restituito all'applicazione, mentre la maggior parte dei design lo lascia trapelare verso searcher e validatori
• Il prezzo di questo modello è un breve ritardo sul feed base, che i design concorrenti non impongono

Casi d'uso di API3

• Mercati di prestito che valutano il collaterale e innescano liquidazioni, guadagnando OEV Rewards sulle liquidazioni che i propri feed rendono possibili
• Protocolli di perpetual, opzioni e asset sintetici che necessitano di aggiornamenti di prezzo frequenti
• Stablecoin e sistemi di asset tokenizzati che fanno riferimento a valori esterni
• Applicazioni che migrano da un altro oracolo senza riscrivere i propri contratti
• Searcher che competono per diritti di aggiornamento esclusivi tramite aste partner o endpoint pubblici firmati
• Agenti autonomi che pagano per chiamata API tramite AirnodeHub
• Possessori di token che fanno staking per governare la DAO e sostenere la sua copertura di servizio

Come è protetta API3

La sicurezza si basa su provenienza, aggregazione ed economia. Ogni valore può essere ricondotto a una firma del wallet Airnode di uno specifico fornitore, e i fornitori ruotano i propri mnemonic Airnode ogni sei mesi come prassi comune, quindi gli indirizzi autorevoli dovrebbero sempre essere letti dal Market o dalla chain invece che tenuti in cache. I feed sono mediane di fonti di prima parte indipendenti, quindi una singola fonte difettosa non muove l'aggregato da sola. Cambiare quali fornitori contribuiscono a un feed richiede le firme di tutti i proprietari della multisig pertinente.

Poiché i feed sono asincroni anziché basati su round, sono progettati per la disponibilità, motivo per cui il contratto lettore non implementa deliberatamente le funzioni basate su round dell'interfaccia aggregatore che altrimenti rispecchia. La documentazione di API3 è esplicita nel dire che gli aggiornamenti OEV offrono le stesse garanzie degli aggiornamenti ordinari, poiché entrambi sono aggregazioni on-chain di dati firmati dai fornitori. Sul lato token, l'API3 in staking funge da collaterale per la copertura di servizio, mettendo gli staker dietro i feed che governano.

Rischi e considerazioni

• Il ritardo del feed base è un vero compromesso. Le applicazioni accettano un ritardo da 0 a 15 secondi in cambio dei ricavi OEV, e non è lo scambio giusto per ogni design.
• I ricavi OEV non vengono pagati ai possessori del token. Vanno alle applicazioni partner nel token di gas della loro chain, quindi il valore del token deve derivare dalla governance e dalla copertura, non da una condivisione diretta dei ricavi.
• Lo staking è collaterale, non solo rendimento. Agli staker può essere chiesto di pagare richieste di copertura.
• API3 è inflazionistica e senza tetto, e le ricompense vengono bloccate per un anno dopo la ricezione, quindi la posizione è illiquida nella pratica oltre che esposta.
• Il rischio di concentrazione è intrinseco al design di prima parte. Fonti meno numerose e di qualità più alta significano anche meno fonti.
• L'architettura OEV è già cambiata una volta, con la OEV Network pubblica e il suo banditore ritirati. Le aste private con searcher partner sono meno aperte di una catena di aste pubblica.
• I mercati di prestito curati sono un business diverso dalla vendita di dati e comportano rischi di prestito, liquidazione e parametri che un oracolo puro non ha.
• Gli oracoli sono un mercato in consolidamento e competitivo in cui le integrazioni, non le funzionalità, decidono gli esiti.

Perché API3 è importante

API3 è uno dei pochi progetti di oracolo ad aver sostenuto un'architettura genuinamente diversa e poi averla effettivamente rilasciata, e il suo lavoro sull'OEV ha ridefinito un costo che le applicazioni avevano accettato come inevitabile. Che il modello di prima parte prevalga o meno, l'idea che un protocollo debba essere pagato per il valore estraibile che creano i propri aggiornamenti di prezzo ha già cambiato il modo in cui il settore discute il design degli oracoli.

Dove si può comprare API3 (API3)?

API3 è un token ERC-20 su Ethereum quotato su un ampio insieme di exchange centralizzati oltre che su piattaforme decentralizzate. Disponibilità e coppie variano in base alla giurisdizione.

Principali exchange centralizzati (CEX)

API3 è comunemente disponibile su:

• Binance
• OKX
• Kraken
• HTX
• Bithumb
• MEXC

Le coppie comuni includono API3 contro le principali stablecoin e, su piattaforme regionali, contro valuta locale.

Opzioni di custodia dopo l'acquisto

API3 può essere conservato:

• Su un exchange, sotto la custodia di quell'exchange
• In qualsiasi wallet di self-custody Ethereum, poiché API3 è un token ERC-20 standard
• Dietro un hardware wallet abbinato a software wallet compatibile

Lo staking si effettua depositando nel contratto del pool della DAO tramite l'interfaccia della DAO, il che significa rinunciare alla liquidità per il periodo di attesa dell'unstaking e accettare il ruolo di collaterale che ne consegue. Verificate la rete e l'indirizzo del contratto prima di qualsiasi deposito o prelievo.

Coin correlate

Potete confrontare API3 con progetti correlati di oracoli e dati su Coinrithm:

• Chainlink (LINK)
• Pyth Network (PYTH)
• Band Protocol (BAND)
• UMA (UMA)
• Tellor (TRB)