InDEX: Il Modello di Intenti Multi-chain

Introduzione

Il concetto di “intento” nel web3 è un’idea nuova e in evoluzione, attualmente priva di una definizione univoca. Questa innovazione in fase iniziale è rilevante per Phala Network, che guida lo sviluppo di inDEX, una piattaforma progettata per interpretare e realizzare questi intenti in un ambiente decentralizzato.

Questo articolo esplorerà come inDEX, all’avanguardia in questa tecnologia, stia navigando nelle acque inesplorate delle soluzioni basate sugli intenti. Un’infrastruttura incentrata sugli intenti nell’ecosistema blockchain, che identifica i migliori prezzi di negoziazione tra pool di liquidità su più catene, garantendo la protezione dei MEV e preservando la privacy degli utenti.

Intento: Cos’è e perché è importante

Un Nuovo Paradigma oltre le Transazioni

Tradizionalmente, una transazione rappresenta i requisiti dell’utente — ad esempio, quando un utente trasferisce 1 USDC a un altro utente, costruiamo i dati di trasferimento e li trasmettiamo alla blockchain. Tuttavia, catene diverse e dApp uniche comportano diverse specifiche di dati di transazione, tipi di firma, logica di convalida e interfacce: una sfida enorme sia per gli utenti che per le applicazioni come i portafogli.

Le applicazioni di intento offrono quindi un approccio innovativo per rappresentare i requisiti degli utenti nel settore della blockchain. Esse consentono agli utenti di non doversi preoccupare delle complessità sottostanti, come la scelta di un DEX per scambiare ETH in BTC o la determinazione del ponte adatto per spostare BTC dalle reti Ethereum a Bitcoin.

Intento in azione: Un esempio semplificato

Un semplice `Intento` è tipicamente rappresentato come segue:

L’intento ha valore solo quando può essere efficacemente eseguito da qualsiasi entità (nota come solutore). Questa compatibilità consente un sistema di solutori aperto, in grado di risolvere l’`Intento’ in base agli interessi individuali. È da notare che l’`Intento` non richiede necessariamente soluzioni convenzionali. Ad esempio, un altro utente potrebbe avere il seguente `Intento`, presumendo che 1 ETH equivalga a 0,1 BTC:

Questi due Intenti possono essere allineati in modo tale da facilitare una corrispondenza diretta tra loro, portando potenzialmente a un risultato più vantaggioso rispetto all’esecuzione dell’operazione singolarmente su un DEX.

Strategie On-chain & Off-chain

La risposta all’intento di questi due utenti può essere attuata in vari modi, principalmente classificati come strategie on-chain e off-chain:

1) On-chain: questo metodo è il percorso tradizionale e rispecchia essenzialmente il processo che un utente dovrebbe intraprendere manualmente. Per questo approccio, i passaggi probabili sono:

Pur essendo logico, questo metodo manca di efficienza del capitale. Gli utenti devono pagare una commissione aggiuntiva per lo swap e possono anche soffrire di slippage.

2) Off-chain: una strategia alternativa e più efficace prevede la corrispondenza off-chain dell’Intento degli utenti, trasformando il piano in:

In particolare, le fasi sopra descritte potrebbero avvenire in modo sincrono all’interno di una singola transazione su entrambe le catene. Questo introduce una maggiore complessità in uno scenario cross-chain, che approfondiremo nelle sezioni successive.

Complessità off-chain: Fiducia e correttezza

Anche il trasferimento della corrispondenza degli `Intenti’ off-chain presenta problemi difficili da affrontare. Nonostante il presupposto che lo smart contract sia equo, il coinvolgimento di un conto di garanzia solleva problemi di fiducia.

Inoltre, come possiamo determinare se il motore di abbinamento degli ordini off-chain sta fornendo i prezzi migliori per entrambe le parti? Alcuni progetti attuali gestiscono la corrispondenza degli ordini off-chain in modo centralizzato. Tuttavia, questo aspetto richiede fiducia, trasparenza e protezione della privacy. Questa è una delle aree chiave in cui inDEX eccelle e si distingue.

InDEX: Cos’è? Perché Costruirlo?

InDEX: Il Protocollo e l’App

1) InDEX Protocol: una piattaforma intent-centrica (ancora in fase beta) che comprende e soddisfa le esigenze degli utenti. Gli utenti possono inviare i loro intenti o creare applicazioni incentrate sugli intenti utilizzando la sua infrastruttura. Per ulteriori informazioni sull’utilizzo del protocollo InDEX, consultare la sezione “Casi d’uso potenziali con InDEX”.

2) InDEX App: un’applicazione front-end (la cui anteprima è ora disponibile) che consente agli utenti di interagire senza soluzione di continuità con il protocollo inDEX. Attraverso questa applicazione, gli utenti possono esprimere chiaramente le loro intenzioni, inducendo il protocollo inDEX a creare un piano di esecuzione su misura. Per una prima panoramica è disponibile una demo concisa; per una comprensione più completa, vi invitiamo ad approfondire sul sito web di inDEX.

Ottimizzazione del trading incentrato sull’intento

InDEX trova i migliori prezzi di scambio tra pool di liquidità multi-catena, aumentando l’efficienza degli scambi e i potenziali profitti grazie all’ottimizzazione dei valori delle transazioni. Inoltre, fornisce una forte protezione MEV e mantiene la privacy degli utenti. InDEX gestisce anche transazioni su più blockchain.

Phala Network: La Forza Dietro InDEX

La complessità e l’esperienza utente inferiore a quella spesso riscontrata nella blockchain, in particolare nelle operazioni cross-chain, sono problemi ben noti. Phala Network è stata all’avanguardia nello sfruttare la tecnologia off-chain per risolvere intricati problemi on-chain. Integrando Phat Contract in inDEX, Phala ha creato il primo livello di esecuzione degli intenti senza fiducia, risolvendo gli intenti senza dipendere da alcuna entità particolare e aumentando così la sicurezza.

InDEX & Phat Contract

InDEX garantisce la fiducia e preserva la privacy utilizzando l’innovativo modello di programmazione off-chain Phat Contract di Phala Network. Sebbene Phat Contract condivida alcune somiglianze con altri modelli di contratti intelligenti come Solidity, si distingue per due vantaggi chiave:

1. Richieste Http: gli smart contract, attraverso Phat Contract, possono ora connettersi a Internet per le trasmissioni RPC della blockchain e per le richieste HTTP esterne, come l’acquisizione dei prezzi dei token. Queste connessioni sono protette da lavoratori dotati di hardware SGX registrati sulla rete Phala, che mantengono la riservatezza delle loro chiavi private all’interno dell’ambiente SGX. Il diagramma seguente illustra i processi “E” per la crittografia e “D” per la decrittografia.

2. Computazione off-chain: lo smart contract opera off-chain, eseguito ogni volta da un singolo lavoratore, a differenza dell’approccio tipico in cui tutti i lavoratori sono coinvolti. Coinvolge tutti i validatori delle paracatene solo per i cambiamenti di stato del contratto. Per una spiegazione dettagliata del funzionamento di Phat Contract, consultare la nostra ultima documentazione.

Pertanto, grazie a Phat Contract, inDEX sarà il primo protocollo a funzionare senza problemi come livello di esecuzione degli intenti indipendente dalla catena. Prevediamo un futuro prossimo in cui gli utenti dell’App inDEX potranno realizzare senza sforzo i loro intenti Web3, proprio come se utilizzassero la ricerca di Google per navigare nel mondo Web2.

Superare gli Ostacoli Multi-Catena e i Limiti della Liquidità

InDEX: Ottimizzazione delle Operazioni Cross-Chain

Nell’attuale panorama crittografico, ogni ecosistema blockchain opera in modo isolato, come un’isola solitaria. Ogni blockchain ha i suoi protocolli di consenso, i suoi metodi di convalida delle transazioni e le sue interfacce API. La liquidità esiste all’interno di questi ecosistemi distinti, rendendo la circolazione senza soluzione di continuità una sfida.

InDEX interviene per costruire un livello indipendente dalla catena che fornisce interfacce unificate per utenti e applicazioni per esprimere l’intento. A questo scopo, abbiamo astratto le rappresentazioni del conto, dell’asset e della catena stessa, consentendo l’identificazione cross-chain.

Informazioni sulla Chain

Una `Chain` in inDEX consiste nelle seguenti informazioni:

1. Nome: riconosciuto anche come ID, viene utilizzato quando il solutore genera una soluzione.
2. BalanceFetcher: questo modulo recupera il bilancio delle attività dalla blockchain. Piattaforme blockchain diverse possono avere interfacce RPC diverse.
3. Gateway/EntryPoint: questo smart contract viene distribuito su ogni blockchain che supportiamo, fungendo da punto di ingresso per creare e regolare gli Intenti degli utenti.
4. TxIndexer: questo indicizzatore off-chain tiene traccia dei risultati delle transazioni inviate dall’Esecutore inDEX.

Il contratto Gateway ha due scopi principali:

1. Intenzioni inviate dagli utenti: fornisce un’interfaccia agli utenti per creare il loro `Intento` sulla catena. Le risorse dell’utente sono temporaneamente trasferite dal loro conto al contratto.

2. Liquidazione degli intenti: regola ogni operazione all’interno dell’Intent Step che si verifica sulla catena. L’operazione può essere una swap call su un DEX o una bridge call con uno specifico contratto bridge. Maggiori dettagli saranno forniti nella sezione Esecuzione dell’intento.

Account e Attività su più Chain, Bridge e DEX

Le rappresentazioni degli account variano da una catena all’altra. In sostanza, nel regno della blockchain, gli account utente derivano da una coppia di chiavi, con indirizzi codificati utilizzando meccanismi diversi dalla chiave pubblica. Ad esempio, un account Ethereum ha una lunghezza fissa di 20 byte, mentre su una catena basata su Substrate potrebbe essere una chiave pubblica sr25519 a 32 byte o altre.

InDEX astrae il conto come byte dinamico, convertito in base al contesto della blockchain corrente. È vantaggioso quando i lavoratori inDEX (un conto derivato in Phat Contract, non il lavoratore SGX in Phala Network) inviano transazioni su catene diverse utilizzando la stessa chiave privata per conto.

Pertanto, l’indirizzamento degli asset rappresenta una sfida diversa. Non è possibile utilizzare un unico formato per rappresentare le attività su più blockchain. Una risorsa è solitamente rappresentata attraverso un indirizzo di risorsa, come l’indirizzo di un contratto ERC20 distribuito sulle catene EVM.

Tuttavia, l’interazione con la blockchain richiede la considerazione di informazioni aggiuntive sul bene, come simboli e decimali. Inoltre, un asset deve essere legato a una specifica blockchain. Ad esempio, `USDC` su Ethereum e `USDC` su Moonbeam sono asset diversi, nonostante appaiano identici agli utenti e possano avere gli stessi indirizzi di contratto sulla catena. Questa differenziazione è necessaria per identificare quali asset sono supportati da un bridge.

Sulla base di questo principio, un’operazione di bridge in inDEX può essere rappresentata come:

Cosa sono le Azioni e le Soluzioni?

In inDEX, un’azione si riferisce all’implementazione di una specifica operazione sulla catena. Questa operazione può essere un’operazione di swap su Uniswap o un’operazione di bridge con un bridge. Un’azione contiene un nome, usato come ID in `Solution`. L’azione accetta una serie di argomenti come input, costruendo i dati di chiamata che saranno inviati alla blockchain per l’esecuzione quando l’intento viene eseguito.

Ora, creiamo una `Soluzione` che rappresenti l’`Intento` di scambiare inizialmente WETH in USDC su Ethereum, e poi di collegare USDC da Ethereum a Moonbeam. Seguendo i principi delineati in precedenza, la soluzione avrebbe il seguente aspetto se rappresentata come oggetto JSON:

Si noti che una `soluzione’ completa sarebbe più complessa; l’esempio sopra riportato è inteso solo a scopo illustrativo.

Come Riusciamo a Ottenere i Prezzi Migliori Cross-Chain?

Perseguire il Meglio in Mezzo all’Impossibile

Assicurarsi il prezzo migliore è fondamentale per i trader, soprattutto nelle transazioni a blocchi di grandi dimensioni. Tuttavia, ottenere questo risultato in scenari cross-chain è quasi impossibile a causa della difficoltà intrinseca di specificare la tempistica della transazione (sebbene possa essere condizionata) quando un Intent viene eseguito su più catene.

Se si confronta questa situazione con la risoluzione di un `Intent` su una singola catena, una volta che il prezzo sulla catena di origine soddisfa le condizioni impostate, la transazione può essere eseguita e si ottiene la variazione di liquidità desiderata sul DEX. Tuttavia, nella soluzione cross-chain, non c’è alcuna garanzia su quando l’operazione possa essere eseguita sulla seconda catena. Anche se un bridge può offrire una stima del tempo, non è preciso al 100% e la liquidità potrebbe già essersi spostata sull’altra catena durante questo tempo di attesa.

Nella progettazione del sistema inDEX dobbiamo tenere conto di questi casi estremi. Tuttavia, questo non ci impedisce di affrontare queste sfide.

Cosa abbiamo incorporato nel fornitore di soluzioni predefinito di InDEX?

Ottenere il miglior prezzo in un ecosistema multi-catena è in qualche modo simile ad assicurarsi il miglior prezzo in una singola catena. L’obiettivo è quello di massimizzare l’importo in uscita per ogni singolo passo dell’`Intent`. Per ora, inDEX mira a identificare i migliori prezzi di scambio tra più DEX su numerose catene.

Il diagramma sottostante illustra una configurazione in cui esiste più di un DEX (basato su AMM) su Ethereum, che supporta uno swap dall’asset X all’asset Y, e più di un DEX (basato su AMM) su Moonbeam, che consente uno swap dall’asset Y’ all’asset Z, con un ponte che ha una coppia Y-Y’ tra Ethereum e Moonbeam.

Dato che ogni DEX soffrirà di slippage (inevitabile a causa della formula fondamentale k = a*b utilizzata da AMM), maggiore è l’importo relativo che si negozia con la liquidità, maggiore sarà lo slippage che si subirà. Il diagramma seguente suggerisce che dovremmo puntare a passare dal punto A -> B, invece che da A -> B’. Pertanto, dovremmo suddividere l’importo dello swap tra diversi DEX in base alla liquidità attuale di ciascun DEX.

Ad esempio, se un utente spende 100 X su Ethereum per ottenere Z su Moonbeam, invece di scambiare tutti i 100 X su Ethereum/D1, li divide in base alla liquidità di X, dove D1:D2 è 2:5, quindi D1 riceve 20 da scambiare e D2 50 da scambiare. Applicando lo stesso meccanismo, supponiamo di ottenere 200 Y su Ethereum e di scambiarli con Z su Moonbeam con Y’.

Piani Futuri: Corrispondenza degli Ordini Off-Chain

L’abbinamento decentralizzato degli ordini off-chain non esiste nella versione iniziale di inDEX, ma sarà incorporato nelle versioni future.

Il diagramma seguente illustra una configurazione tipica in cui, invece di effettuare uno swap diretto sul DEX, il market maker fornisce un prezzo corrispondente come controparte dell’ordine dell’utente. Il compito dell’Intent executor si riduce alla costruzione dei dati della transazione e al loro invio per l’esecuzione.

Questo processo è atomico ed evita problemi di slippage, poiché gli asset vengono temporaneamente trasferiti al contratto di regolamento e inviati direttamente alla controparte nell’ambito della stessa transazione. Inoltre, poiché il prezzo è fisso, questo approccio è naturalmente anti-MEV.

Implementare la Corrispondenza degli Ordini Off-Chain in Modo Affidabile

Tuttavia, la realtà è che, a breve termine, è difficile decentralizzare completamente la corrispondenza degli ordini off-chain e garantire l’affidabilità, proteggendo al contempo la privacy degli utenti.

Pertanto, i meccanismi per garantire che ogni parte ottenga un prezzo equo, compreso il market maker, sono fondamentali. Progetti come UniswapX cercano di risolvere questi problemi introducendo l’asta olandese (una soluzione comunemente utilizzata nelle vendite di NFT, nella definizione delle tariffe, ecc.)

Solver & Soluzione

Poiché il concetto di `Intent’ è ancora nelle sue fasi iniziali (al momento della stesura di questo articolo), non esiste uno standard per ciò che un `Solver’ dovrebbe fare o per il formato a cui una `Soluzione’ dovrebbe aderire. Progetti come Essential e Anoma stanno cercando di raggiungere questo obiettivo. Considerando che inDEX è più focalizzato sulla risoluzione di intenti a catena incrociata e si basa sulla tecnologia off-chain di Phala, esistono differenze significative tra questo e altri progetti incentrati sugli intenti.

Distinzione tra un Solver InDEX e altri Solver

In genere, un `Solutore` agisce come controparte di un ordine di Intent dell’utente e fornisce la soluzione in accordo con l’Intent dell’utente. In UniswapX, una serie di solutori fa offerte con le loro soluzioni attraverso un’asta olandese e la soluzione del vincitore ottiene il diritto di essere eseguita. Tuttavia, non tutti i progetti offrono un meccanismo d’asta. Alcuni sono centralizzati, con algoritmi in esecuzione sul backend che scelgono il prezzo migliore per gli utenti.

Tuttavia, il concetto di “ Solutore” in inDEX è un po’ diverso. Come accennato in precedenza, l’abbinamento decentralizzato degli ordini off-chain è previsto per il lancio in un secondo momento. Attualmente, l’MVP iniziale di inDEX si concentra sulla ricerca del miglior prezzo di negoziazione tra più DEX su più catene.

In sostanza, si può considerare il solutore di inDEX come composto da

1) InDEX Executor: alimentato da Phat Contract e funzionante nella rete off-chain di Phala, garantisce affidabilità e decentralizzazione.

2) InDEX Solution Provider: un algoritmo che calcola la migliore soluzione di trading e di routing tra più DEX e catene che osserva.

Vale la pena sottolineare che il protocollo inDEX è stato concepito fin dall’inizio come privo di permessi, consentendo a chiunque di eseguire il proprio fornitore di soluzioni e di sottoporre la propria soluzione all’esecutore inDEX per l’esecuzione.

Interfacce Necessarie per un Solver

A livello di base, un solutore dovrebbe fornire due interfacce: una per la presentazione degli intenti e una per la richiesta di soluzioni future.

1) Intent submission: Per questo, un solutore deve fornire un’API POST REST (una sorta di interfaccia di programmazione dell’applicazione) per inviare i dati dell’intento, ad esempio il provider di solutori predefinito di inDEX. I dati dell’intento devono essere passati come argomenti insieme alla richiesta POST e la `Soluzione`, insieme alla firma del solutore, deve essere restituita come parte della risposta.

2) Intent query: il solutore deve fornire interfacce che l’esecutore di inDEX può usare per interrogare i dati della soluzione in base a una determinata identificazione durante l’esecuzione dell’intento. Questo dovrebbe restituire la `Soluzione` e la sua firma.

Specifiche della Soluzione

La soluzione deve descrivere in dettaglio le operazioni da eseguire, l’asset di ingresso e l’asset di uscita. È fondamentale notare che un asset è sempre collegato a una catena specifica.

Inoltre, la soluzione deve includere anche le condizioni. Questo può essere utile per gli utenti per definire le aspettative, come ad esempio l’importo minimo in uscita per un’operazione di swap.

In base a questo principio, la `Soluzione` di base dovrebbe contenere diverse informazioni, come quelle riportate di seguito (che chiamiamo `Step`):

Come InDEX Risolve gli Intenti

InDEX è stato progettato per funzionare come un motore generico di esecuzione di intenti, il che significa che non si limita al trading di asset, ma può eseguire anche operazioni generiche. Attualmente supporta solo operazioni di bridge e swap, ma è destinato ad ampliare la sua gamma.

Per risolvere un intento, come protocollo, inDEX deve prima essere in grado di interpretare i dati dell’intento dell’utente. Abbiamo progettato una semplice espressione di intento che è adeguata a soddisfare la maggior parte dei nostri casi d’uso prima che venga stabilito uno standard.

Non tutti gli intenti troveranno una soluzione, come non sempre una ricerca su Google produce una risposta. Tuttavia, espandendo il supporto a più catene, DEX e bridge, aumentiamo la nostra capacità di risolvere un maggior numero di intenti.

Rappresentazione dell’Intento

All’inizio di questo articolo, abbiamo detto che un intento può essere semplificato con il seguente JSON:

Questa rappresentazione è adeguata per un utente se non viene impostata alcuna condizione. Tuttavia, nelle applicazioni pratiche, l’efficacia di qualsiasi sistema basato sugli intenti, compreso il suo design complessivo, spesso richiede che un intento comprenda informazioni più dettagliate.

In inDEX, quando si invia un `Intent` al contratto Gateway sulla catena di origine (attualmente supportiamo solo l’invio di `Intent` tramite transazione, la firma off-chain come CowSwap e UniswapX sarà supportata nel prossimo futuro), saranno richieste informazioni aggiuntive. Una versione completa può essere rappresentata come segue (solo asset fungibili, espressi per tipo di campo):

L’impostazione delle condizioni sarà aggiunta una volta che ne avremo il supporto. Questi dati saranno salvati nel contratto Gateway quando un utente crea un `Intento` e saranno eliminati quando il `lavoratore` assegnato all’esecuzione dell’Intento in futuro rivendicherà l’attività `Intento` dal contratto Gateway.

Costruire la Chiamata in Base alla Soluzione

La `Soluzione` contiene diverse `Step`, ognuno dei quali è correlato a una specifica operazione sulla catena. Prendendo come esempio l’implementazione di Solidity nella catena EVM, in altre parole, si tratta di una chiamata a uno smart contract. Qui introduciamo l’oggetto `Call` definito come segue (oggetto Solidity). Oltre alle informazioni di base come `calldata` e l’indirizzo dello smart contract `target`, fondamentali per l’operazione `Call` con le parole chiave del contratto Solidity nel contesto del contratto Gateway, contiene anche altre informazioni necessarie.

Non ci addentreremo in ulteriori dettagli in questo articolo, ma fondamentalmente le informazioni aggiuntive vengono utilizzate per facilitare il regolamento sulla catena.

Esecuzione Parallela da parte di più Lavoratori

Come abbiamo sottolineato in precedenza, quando un utente invia il proprio Intent a inDEX, il worker da assegnare è già specificato nell’Intent. Ogni lavoratore esegue un solo task dell’Intento alla volta. Nel caso in cui siano stati inviati troppi task, il contratto del gateway dispone di una coda di intenti per programmare l’esecuzione dei task in futuro.

InDEX supporta più worker. La chiave privata dell’account `Worker` deriva da Phat Contract, che viene creato al momento della distribuzione di Phat Contract, e non viene mai rivelata all’esterno durante l’intero ciclo di vita, protetto dal sistema di gestione distribuita delle chiavi di Phala. Nella prima versione, prevediamo di impostare fino a 10 lavoratori e, nel prossimo futuro, dovrebbe ospitare un numero maggiore di lavoratori, ad esempio 100, a seconda del livello della domanda. Il numero di lavoratori rappresenta il throughput dell’intero sistema, cioè il numero di `Intents` che possono essere eseguiti simultaneamente.

L’esecuzione di ogni step è identica per facilitare il controllo della concorrenza in un ambiente cross-chain altamente complesso, asincrono e distribuito. Durante l’inizializzazione del task Intent, assegniamo a ogni step un nonce distintivo dell’account sulla blockchain su cui avverrà la transazione. Il nonce è unico per l’account del lavoratore ed è legato allo step. Indipendentemente dal numero di volte in cui il motore invia la transazione per eseguire lo step, il nonce per questo step rimane costante. Questo è il modulo di esecuzione identico.

Contratto Gateway e Regolamento On-Chain

Il contratto Gateway del protocollo inDEX funge da contratto di regolamento su ogni blockchain che supportiamo (solo per le blockchain che supportano gli smart contract) ed è responsabile della gestione delle richieste di Intent dell’utente, dell’archiviazione dei dati di Intent e della detenzione temporanea di asset dell’utente.

Casi d’Uso e Ispirazione

Oltre alla DApp ufficiale di cross-chain swap, l’SDK di inDEX consente agli sviluppatori di creare una serie di applicazioni. Qui elenchiamo alcuni potenziali casi d’uso che immaginiamo possano essere realizzati. Siamo inoltre ansiosi di ascoltare altre idee innovative dalla comunità.

1. Cross-chain Swaps Personalizzati

Sebbene il protocollo inDEX fornisca interfacce per l’invio di `Intent` e la loro esecuzione, personalizzando la vostra soluzione invece di utilizzare quella offerta dal nostro provider (un modulo off-chain), potete facilmente creare un’applicazione di cross-chain swap con le vostre preferenze o la vostra logica personalizzata. Per esempio, immaginate di costruire uno scambio cross-chain tra Ethereum e Moonbeam; potreste personalizzare la soluzione con le seguenti azioni (solo a scopo illustrativo):

È possibile inviare questa soluzione all’esecutore inDEX tramite l’SDK.

In questo esempio, è necessario assicurarsi che esista una coppia di trading `SOURCE_ASSET-USDC` su Uniswap e una coppia di trading `USDC-DEST_ASSET` su Stellaswap (un DEX distribuito su Moonbeam).

2. One-click + XYZ

InDEX non si limita alle operazioni di bridge o swap. Offre un quadro di operazioni generico, anche se è necessario tenere conto delle proprie esigenze specifiche, poiché è profondamente legato alle interfacce dei servizi. Ecco alcuni casi d’uso generali:

• Cross-chain Staking: supponiamo che stiate costruendo un servizio di staking su ChainA e che vogliate far salire a bordo gli utenti di ChainB. L’integrazione di inDEX nel vostro flusso di lavoro UX consentirà un’esperienza di onboarding senza problemi, fornendo un pulsante “one-click” sulla vostra interfaccia, che abilita il bridging degli asset dalla ChainB (potete personalizzare la soluzione per combinare swap + bridge).
• Trasferimento di asset nelle app social: la crescente sfera sociale del Web3 richiede agli utenti di inviare asset a chiunque in modo conveniente. Con inDEX, è possibile creare una soluzione on-click per inviare denaro a un amico in un’app di chat, indipendentemente da dove si trovi il token e da dove andrà.

3. Multi-chain Asset Management tools

Gli utenti del Web3 sono sempre alle prese con la frammentazione dei loro asset che possono essere distribuiti in molte catene, e sono desiderosi di avere uno strumento che li aiuti ad aggregare i loro asset in una catena specifica, soprattutto per gli utenti con piccole quantità di token sparsi su varie piattaforme. Nel Web2, innumerevoli strumenti di utilità aiutano gli utenti ad accedere ai dati da Internet senza sforzo. Tuttavia, nel Web3, tali strumenti sono scarsi a causa dell’isolamento tra le catene e della frammentazione della liquidità. Anche i piccoli strumenti utili spesso passano inosservati agli sviluppatori.

Conclusione

Nel panorama in rapida evoluzione della finanza decentralizzata, il raggiungimento dell’esecuzione del miglior prezzo tra catene diverse rappresenta una frontiera impegnativa che molti progetti stanno cercando di conquistare. Come motore di esecuzione Intent robusto e generico, inDEX consente la negoziazione di asset senza soluzione di continuità e una serie di operazioni generiche su più catene, garantendo al contempo un’esecuzione decentralizzata e priva di fiducia.

Esplorate ulteriormente inDEX:

• Website: https://bit.ly/3RvF0C8
• Telegram: https://bit.ly/3tgk5d5
• X: https://bit.ly/3uSFLMK
• Discord: https://bit.ly/4avFkZk