Il design dell'oracolo di Pyth segue l'argomentazione secondo cui i dati finanziari di prima parte non sono intrinsecamente aperti, ma sono di proprietà dei loro creatori; I dati finanziari sono generati da transazioni di mercato aperto in un’ampia gamma di sedi di scambio CeFi, piuttosto che aggregati, e queste sedi e i gruppi che più frequentemente negoziano su di esse sono le migliori fonti di dati. Pertanto, Pyth lavora direttamente con partner di dati di prima parte (market maker, trading desk, scambi, ecc.) piuttosto che con aggregatori di terze parti per fornire aggiornamenti di prezzo diretti e a bassa latenza sulla catena.

Pyth è stato lanciato per la prima volta nel 2021 e da allora ha collaborato con CBOE, Wintermute, Two Sigma, Cumberland e altri 90 market maker, scambi e altri partner di dati di prima parte. Oggi, Pyth fornisce prezzi medi di mercato e intervalli credibili per oltre 400 azioni (ad esempio BTC, TSLA, EUR/USD, criptovalute, azioni, FX, materie prime, attività con tassi di interesse, ecc.) e fornisce supporto a oltre 45 società diverse La catena fornisce dati ad alta fedeltà garantendo al contempo un valore di oltre 1,7 miliardi di dollari attraverso alcuni dei più grandi protocolli di criptovaluta, tra cui MarginFi, Drift, Helium, Jupiter, Synthetix e Hashflow, oltre ad altri 90.

Oltre ad essere pioniere del modello di contributore di dati di prima parte nello spazio delle criptovalute, Pyth è stato anche pioniere del modello di pubblicazione dei prezzi basato su pull. Invece di inviare costantemente dati alla catena in un intervallo di tempo definito (ad esempio, ogni volta che si verifica una deviazione del prezzo di 50 punti base o un oracolo come Chainlink fornisce dati ogni ora), Pyth consente ai contratti intelligenti di inviare dati alla catena quando tempo necessario per estrarre dati accurati. Si tratta di un design completamente nuovo che produce prezzi più nuovi e più accurati rispetto agli oracoli che si aggiornano solo su base periodica e arbitraria. Riduce inoltre strutturalmente il costo dei contratti e delle applicazioni degli utenti perché non devono pagare costantemente per aggiornamenti non necessari. Questo design consente inoltre a Pyth di espandere intrinsecamente la copertura delle risorse e della catena pubblica più rapidamente, poiché il meccanismo di pull elimina la necessità di distribuzioni Oracle separate. Ad esempio, le applicazioni basate su Base e Mantle sono in grado di integrare Pyth immediatamente perché Pyth non richiede la scrittura di codice personalizzato.

Sono primitive fondamentali per lo sviluppo di applicazioni crittografiche e fungono da ponte tra gli stati off-chain e on-chain. Il loro compito principale è mantenere i prezzi coerenti tra le diverse sedi di liquidità; tuttavia, dietro le quinte, c’è un enorme spazio di progettazione per catturare e ridistribuire il valore delle transizioni di emergenza. Nella ricerca, i modelli di Pyth sono attualmente i più adatti a cogliere questa opportunità e aprire la strada a protocolli e applicazioni per sbloccare nuovi flussi di entrate attraverso Oracle Extractable Value (OEV).

Due esempi di opportunità MEV basate su transizioni statali: uno senza OEV e uno con OEV.

1. MEV (indipendente da oracolo): lo stato dell'applicazione è organico o disconnesso dallo stato esterno attraverso alcune operazioni sulla catena. Ad esempio, se un commerciante di balene esegue un gran numero di ordini di acquisto contro uno scambio AMM costante, causando quotazioni incoerenti con il prezzo esterno, il bot può catturare il MEV correggendo la differenza e chiudendo l'arbitraggio senza utilizzare direttamente il protocollo che deve essere aggiornato.

2. OEV (dipendente dall'oracolo): le variazioni di prezzo nei mercati esterni creano opportunità redditizie per ripristinare lo stato dell'applicazione allo stato canonico fuori catena dopo che l'oracolo importa lo stato aggiornato sulla catena. Ad esempio, un bot MEV su un protocollo di prestito potrebbe scegliere di liquidare un conto che era sott’acqua a seguito di un movimento avverso dei prezzi su uno scambio centralizzato di price discovery.

Classifichiamo l'OEV come quest'ultimo, in cui gli aggiornamenti Oracle innescano opportunità per l'acquisizione di valore. Oggi, l’attività di generazione di OEV avvantaggia in modo sproporzionato validatori e stakeholder a scapito dei loro utenti (ovvero, fornitori di liquidità). Se i protocolli e le applicazioni riescono a catturare più OEV, possono ridistribuire questi profitti per incentivare e premiare la fedeltà degli utenti. In definitiva, la capacità di allineare l’OEV con gli utenti rende gli accordi con gli utenti più competitivi. La progettazione dell'applicazione per l'acquisizione di MEV è difficile. Tutte le applicazioni vogliono ridurre al minimo il MEV dell'utente e ridistribuire in modo efficiente il valore rimanente all'utente o interiorizzarlo da sole. Oggi, molti sviluppatori ritengono che l'unico modo per raggiungere questo obiettivo sia distribuire i propri protocolli come catene di applicazioni autonome con l'obiettivo di acquisire valore per il proprio token nativo tramite MEV, ma ciò comporta enormi sfide tecniche, operative e di interoperabilità e complessità sessuale. La prima soluzione corretta per internalizzare il MEV è condurre un'asta del flusso degli ordini (OFA). L'OFA facilita un mercato in cui il lato dell'offerta è costituito da un lotto di transazioni compatibili con MEV aggregate dall'applicazione, e il lato della domanda è costituito da bot MEV o market maker che cercano di inserire o riordinare queste transazioni in un modo che le favorisca. Il ricavato dell'asta va direttamente all'applicazione e rappresenta la quota di MEV netto che l'applicazione può acquisire da sola.

Implementare l'acquisizione OEV

L'approccio apparentemente intuitivo prevede che l'applicazione lanci la propria asta del flusso degli ordini e realizzi profitti dalle offerte che circondano lo spazio del blocco aggiornato dall'oracolo. Tuttavia, ciò richiede molto impegno. Ciascuna applicazione controlla una quantità limitata di flusso di ordini e OFA è fondamentalmente un mercato che fa affidamento su una profonda liquidità sia dal lato del produttore (lotti di negoziazione degli utenti) che da quello dell'acquirente (robot MEV). L'OFA specifico per l'applicazione decentralizza la liquidità e limita la componibilità atomica (ad esempio, se il bot MEV non può garantire che le due fasi della strategia si verifichino esattamente come fanno, in genere è necessario eseguire la liquidazione dopo che la garanzia è stata sequestrata per completare lo scambio di arbitraggio gettoni, possono rifiutare completamente l'opportunità). Il sovraccarico operativo e sociale derivante dalla configurazione di un OFA specifico per l'applicazione potrebbe essere troppo elevato per giustificare la creazione di una soluzione interna.

Un modo migliore per acquisire MEV urgente è esternalizzare l’asta tramite un’asta Global Order Flow (GOFA). Pyth è strutturalmente posizionato per eseguire OFA direttamente per tutte le applicazioni che supporta, poiché queste applicazioni si basano già sugli aggiornamenti Oracle di Pyth per mantenere la funzionalità del sistema. Pertanto, Python ha accesso a uno spazio di blocco di alto valore in un gran numero di applicazioni e il naturale passo successivo è quello di mercificare il complemento intervenendo nello spazio di blocco attorno agli aggiornamenti Oracle (ovvero, estraendo la porzione di blocco di MEV).

Invece di reinventare la ruota per ogni applicazione, è GOFA gestito da oracoli che sfrutta le naturali economie di scala. Una profonda liquidità porta a maggiore liquidità: è più probabile che i bot MEV siano gli acquirenti di flussi di ordini raggruppati su più applicazioni (a causa della componibilità atomica) e quando ci sono acquirenti più competitivi (gli impegni sono più alti delle offerte, il che si traduce direttamente in entrate) , più app sono incentivate a partecipare.

Nuove frontiere per le applicazioni professionali OEV

L'OEV rappresenta un nuovo approccio per acquisire valore per oracoli e applicazioni. L'OFA gestito da Oracle fornisce il valore emergente dell'OEV direttamente all'applicazione, consentendo alle applicazioni di sfruttare i vantaggi di avere un proprio OFA senza alcun sovraccarico. In qualità di terza parte neutrale per lo scambio del flusso di ordini tra applicazioni e robot MEV, Pyth può scegliere di addebitare commissioni di servizio a entrambe le parti, introducendo così nuovi flussi di entrate nella rete senza compromettere la neutralità dell'ecosistema. Siamo entusiasti dei nuovi meccanismi in grado di catturare più strettamente il MEV direttamente a livello di applicazione. #BTC