Gli sviluppatori di XRP Ledger continuano a perfezionare XLS-66, uno standard proposto che introdurrebbe funzionalità di lending nativo su XRPL. Se le specifiche continuano ad avanzare, potrebbe diventare uno degli aggiornamenti in stile DeFi più significativi della rete.

La proposta delinea un lending on-chain a termine fisso e non collateralizzato, costruito attorno ai Single Asset Vault. Utilizza inoltre l'underwriting off-chain da parte dei loan broker, mentre il settlement sarebbe gestito on-chain attraverso l'infrastruttura XRPL.

Questa struttura è centrale nella proposta. XLS-66 non è concepito come un semplice pool di lending DeFi in stile "chiunque prende in prestito da chiunque", simile ai money market di Ethereum pienamente collateralizzati. Presenta invece un modello di lending più strutturato che combina la valutazione del credito off-chain con l'esecuzione basata su blockchain.

La funzionalità è ancora in fase di revisione degli standard e test del codice. Il lending nativo secondo XLS-66 non è attivo sulla mainnet di XRP Ledger.

XRPL si sta espandendo oltre i pagamenti

XRP Ledger è stato a lungo associato a pagamenti, settlement rapido e funzionalità di scambio. Questa storia rimane importante, ma può anche oscurare la più recente direzione di sviluppo della rete.

Gli sviluppatori di XRPL hanno lavorato a funzionalità destinate ad ampliare il ruolo della chain nella finanza on-chain, tra cui vault, funzionalità di automated market maker, credenziali e standard di lending. XLS-66 fa parte di questo più ampio percorso di sviluppo. A differenza delle chain compatibili con EVM in cui i protocolli DeFi vengono tipicamente distribuiti come smart contract da sviluppatori terzi, XRPL implementa le principali funzionalità finanziarie come funzionalità native del protocollo attraverso proposte di standard e emendamenti. Ciò significa che funzionalità come il lending attraversano un formale processo di revisione degli standard prima di poter essere attivate sulla mainnet, motivo per cui proposte come XLS-66 sono indicatori significativi della roadmap della rete.

Un protocollo di lending nativo darebbe a XRPL una connessione più diretta con i mercati del credito. Tuttavia, la proposta non tenta di riprodurre esattamente i modelli DeFi esistenti. Introduce i Single Asset Vault e il lending a termine fisso, mantenendo l'underwriting off-chain come parte fondamentale del processo.

In questo senso, il design assomiglia a un ponte tra i flussi di credito tradizionali e il settlement su blockchain. La valutazione del credito avverrebbe al di fuori della chain, mentre la struttura del prestito risultante potrebbe essere registrata e regolata su XRPL.

Perché l'underwriting off-chain è centrale

La maggior parte del lending DeFi è overcollateralizzata. In quel modello, un utente deposita asset per un valore superiore all'importo che prende in prestito e gli smart contract gestiscono le liquidazioni se il valore della garanzia scende troppo. L'approccio è trasparente e automatizzato, ma anche inefficiente dal punto di vista del capitale, poiché i mutuatari devono generalmente possedere già asset sostanziosi prima di poter accedere al credito. Protocolli come Aave e Compound hanno reso popolare questo modello su Ethereum, che rimane il paradigma dominante nella maggior parte dei mercati di lending DeFi oggi.

Il lending non collateralizzato funziona in modo diverso. Richiede una qualche combinazione di fiducia, identità, valutazione del credito o underwriting. Senza questi elementi, i mutuatari potrebbero ottenere prestiti senza un meccanismo affidabile per consentire ai prestatori di valutare il rischio di rimborso.

XLS-66 introduce i loan broker come parte di questa struttura. Secondo il modello proposto, le decisioni di credito e la valutazione del mutuatario avverrebbero off-chain, mentre i termini del prestito e il settlement risultanti potrebbero essere gestiti on-chain.

Ciò crea un modello di rischio che differisce significativamente dal lending DeFi standard. Potrebbe essere più adatto ad alcuni flussi di lavoro di credito del mondo reale, ma dipende fortemente dalla qualità del processo di underwriting. La blockchain può registrare il settlement, far rispettare determinate condizioni e fornire trasparenza, ma non elimina il rischio di credito del mutuatario.

Per questo motivo, il ruolo del loan broker è un elemento centrale della proposta, non un dettaglio di implementazione minore.

I Single Asset Vault come elemento costitutivo

I Single Asset Vault sono un'altra parte importante del design proposto. Una struttura a vault può aiutare a organizzare i fondi, isolare gli asset e creare un contenitore più chiaro per specifiche attività di lending. Ciò potrebbe rendere il lending basato su XRPL più facile da comprendere e gestire rispetto a un modello di pool meno strutturato.

Per gli sviluppatori, i vault potrebbero anche servire come elementi costitutivi finanziari più ampi. Una volta disponibili le meccaniche dei vault, altri prodotti potrebbero diventare più facili da sviluppare. Lending, prodotti di rendimento, credito strutturato e strumenti di gestione degli asset richiedono tutti metodi affidabili per detenere e contabilizzare gli asset.

Ecco perché le discussioni sugli standard tecnici possono essere importanti prima di un lancio sulla mainnet. I mercati spesso prestano maggiore attenzione una volta che una funzionalità è attiva, ma l'architettura viene definita prima, quando gli standard vengono dibattuti, rivisti e testati. XLS-66 è la fase in cui il design del lending nativo di XRPL viene sviluppato e perfezionato.

Il lending nativo su XRPL non è ancora attivo

La principale avvertenza è che XLS-66 è ancora in fase di revisione e test. Gli utenti non dovrebbero dare per scontato che il lending nativo su XRPL sia attualmente disponibile. Gli sviluppatori stanno ancora lavorando alle specifiche e all'integrazione del codice, incluso il lavoro correlato monitorato nei repository XRPLF.

Questo processo è tipico dello sviluppo dei protocolli, in particolare quando sono coinvolti primitivi finanziari. I sistemi di lending richiedono un'attenta revisione perché gli errori possono essere costosi. Comportano saldi, rimborsi, inadempimenti, contabilità dei vault, autorizzazioni e aspettative degli utenti.

Per i detentori di XRP e gli utenti di XRPL, la proposta è degna di nota perché amplierebbe i potenziali casi d'uso della rete se implementata in modo sicuro. Il lending nativo potrebbe rafforzare il profilo DeFi di XRPL e potrebbe interessare sviluppatori e utenti che cercano prodotti di credito collegati alla velocità e alle funzionalità di settlement del ledger.

Alla fase attuale, tuttavia, la riguarda ancora il design e i test, non l'adozione.

Lo sviluppo DeFi di XRPL diventa più visibile

XLS-66 dimostra che lo sviluppo di XRP Ledger si sta muovendo verso un'infrastruttura finanziaria più avanzata. Ciò non sostituisce il retaggio dei pagamenti della rete; vi aggiunge un altro livello. Pagamenti e lending sono strettamente collegati nella finanza tradizionale, e una blockchain che supporta entrambi può avere un ruolo più ampio rispetto a una utilizzata solo per i trasferimenti.

Diverse questioni rimangono irrisolte. Lo standard dovrebbe essere finalizzato, il codice dovrebbe essere integrato in modo sicuro, gli sviluppatori dovrebbero creare prodotti di lending basati su di esso, gli utenti dovrebbero fidarsi del modello di underwriting off-chain e i loan broker dovrebbero generare domanda reale.

Questi risultati rimangono incerti e richiederanno tempo per essere valutati. Per ora, il punto chiave è che gli sviluppatori di XRPL stanno lavorando al lending nativo in un modo che riflette l'architettura propria della rete, invece di limitarsi a copiare il modello DeFi di un'altra chain.

Se lo sforzo avrà successo, XLS-66 potrebbe contribuire a posizionare XRPL come un livello più ampio di applicazioni finanziarie. Se si ferma, indicherà comunque dove gli sviluppatori stanno cercando di spingere le capacità della rete. In entrambi i casi, lo standard rimane uno degli sforzi di sviluppo XRPL più importanti da monitorare.

Questo articolo si basa sulle discussioni su GitHub di XRPLF per XLS-66 e sulla relativa pull request di rippled. Il report originale è stato scritto dalla News Desk e curato da Samuel Rae. Si basa su informazioni pubblicate in comunicazioni e documentazione delle fonti primarie.