XRP Ledger, correzioni al lending dal 23 ottobre ma i prestiti restano bloccati

🛡️ Executive Summary

• XRP Ledger prepara l’attivazione di fixCleanup3_4_0 per il 23 ottobre 2026, con 29 voti su 35 validatori e una maggioranza da mantenere per quattordici giorni consecutivi.
• Il protocollo di lending rimane inattivo: LendingProtocol dispone di 19 voti e SingleAssetVault di 21, entrambi sotto la soglia di 29 necessaria per avviare il conto alla rovescia.
• Le correzioni intervengono su prestiti, vault, autorizzazioni e integrità dei token, ma vanno distinte dalla vulnerabilità critica già risolta con xrpld 3.4.1, che poteva generare XRP attraverso un integer overflow.

XRP Ledger si prepara ad attivare un nuovo pacchetto di correzioni prima ancora che il proprio sistema di prestiti possa entrare in funzione. L’amendment fixCleanup3_4_0, introdotto con la versione 3.4.0 del software xrpld, ha ottenuto i 29 voti necessari tra i 35 validatori di riferimento e potrebbe diventare operativo il 23 ottobre 2026 alle 09:34 UTC, corrispondenti alle 11:34 italiane. Il lending proposto da Ripple per banche e società di pagamento resta invece fermo: le modifiche che dovrebbero abilitarlo non dispongono ancora del consenso sufficiente. La situazione evidenzia una distinzione fondamentale per la sicurezza delle infrastrutture blockchain: distribuire una correzione nel software non equivale ad attivarla sulle regole condivise della rete, soprattutto quando le funzionalità coinvolte devono ancora superare il processo di approvazione dei validatori.

XRP Ledger raggiunge 29 voti per le correzioni ma non ha margine di sicurezza

Il pacchetto fixCleanup3_4_0, documentato nelle note ufficiali di rilascio di xrpld 3.4.0, raccoglie interventi sul funzionamento di token, exchange decentralizzato, pool di liquidità, NFT, escrow e nuove primitive finanziarie. Secondo il monitoraggio delle votazioni pubblicato da XRPL Dashboard, il 19 ottobre l’amendment aveva raggiunto esattamente 29 voti favorevoli su 35, sufficienti per superare la soglia dell’80% richiesta dal protocollo. La maggioranza deve però rimanere valida per quattordici giorni consecutivi: il conto alla rovescia iniziato il 9 ottobre dovrebbe completarsi il 23 ottobre, a condizione che nessun validatore ritiri il sostegno facendo scendere il consenso sotto la soglia necessaria. Il dato è particolarmente delicato perché la patch non dispone di voti aggiuntivi di sicurezza. La differenza tra disponibilità del codice e attivazione sulla mainnet richiama quanto emerso durante il percorso di approvazione degli amendment XRP Ledger dedicati ai pagamenti e alle autorizzazioni, quando l’evoluzione tecnologica della rete dipendeva non soltanto dalla maturità delle implementazioni, ma dalla capacità di ottenere un consenso sufficientemente stabile. Per XRPL il voto non costituisce un passaggio formale: determina il momento in cui le nuove regole diventano effettivamente applicabili alle transazioni.

Leggi anche: XRP Ledger, bug decennale poteva creare XRP dal nulla e aggirare il supply cap

Il lending istituzionale resta senza approvazione: mancano dieci voti

La situazione è differente per il sistema di prestiti destinato a utilizzare XRP Ledger come infrastruttura finanziaria. L’amendment LendingProtocol dispone di 19 voti, mentre SingleAssetVault ne ha 21, rispettivamente dieci e otto in meno della soglia richiesta. Si tratta di due componenti complementari: il primo introduce la gestione dei prestiti a durata determinata, mentre il secondo permette di depositare XRP o altri token in strutture che rappresentano contabilmente la liquidità disponibile. Il modello prevede un intermediario, denominato loan broker, incaricato di gestire i rapporti con i debitori e valutare il rischio creditizio fuori dalla blockchain. I prestiti possono essere concessi senza collaterale depositato direttamente dal debitore, ma questo non significa che il rischio di insolvenza scompaia: la valutazione del merito creditizio rimane responsabilità dell’intermediario. L’architettura si inserisce nell’espansione finanziaria di Ripple, già evidente quando XRP Ledger è stato utilizzato per progetti istituzionali di tokenizzazione e registrazione di quote di fondi. Il problema attuale non riguarda quindi un servizio di prestito già disponibile e colpito da una vulnerabilità operativa, ma una funzionalità ancora inattiva che dovrà ottenere consenso, completare il periodo di attivazione e dimostrare di poter gestire correttamente capitale, rimborsi e insolvenze. Anche un eventuale raggiungimento immediato dei 29 voti non permetterebbe un’attivazione prima dell’inizio di novembre.

Le correzioni intervengono su vault, arrotondamenti e autorizzazioni dei token

La versione 3.4.0 introduce modifiche tecniche che diventano importanti proprio per l’affidabilità del futuro sistema di lending. Le correzioni riguardano la precisione dei calcoli utilizzati da VaultDeposit, VaultWithdraw e VaultClawback, per mantenere coerenti il patrimonio totale del vault, le risorse disponibili e le quote che rappresentano i depositi. Il codice interviene inoltre sulle condizioni di congelamento degli asset, sulle autorizzazioni e sul trattamento dei prestiti in default, evitando che determinate restrizioni impediscano la corretta contabilizzazione di un’insolvenza. Un altro intervento riguarda PaymentBurn, che non deve consentire operazioni capaci di attraversare un saldo pari a zero e produrre effetti incompatibili con le regole di gestione dei token. Il pacchetto rafforza anche le invarianti relative ai Multi-Purpose Token, trasformando controlli precedentemente limitati alla registrazione diagnostica in verifiche effettivamente applicate alle transazioni. Non si tratta di semplici miglioramenti cosmetici: quando un protocollo finanziario registra depositi e debiti, arrotondamenti e controlli sui saldi diventano parte integrante della conservazione del valore. Il problema è coerente con i rischi emersi durante la trasformazione della DeFi in infrastruttura finanziaria per banche e strumenti tokenizzati, dove errori anche limitati nella contabilità degli asset possono assumere conseguenze rilevanti quando vengono ripetuti attraverso numerose operazioni.

La patch del 23 ottobre non è il fix d’emergenza che protegge il supply cap

È necessario distinguere fixCleanup3_4_0 dalla successiva versione xrpld 3.4.1, distribuita il 25 settembre per risolvere una vulnerabilità critica scoperta nel payment engine. In quel caso un integer overflow presente dal 2015 poteva consentire, attraverso transazioni costruite deliberatamente, la creazione di XRP non coperti da un saldo corrispondente, mentre anche il controllo incaricato di impedire la generazione indebita di token utilizzava un’aritmetica vulnerabile. La correzione era stata distribuita attraverso un aggiornamento emergenziale senza attendere il consueto processo di amendment, perché la pubblicazione dei dettagli tecnici prima della protezione dei nodi avrebbe potuto aprire una finestra di sfruttamento. Il pacchetto ora in votazione segue invece la governance ordinaria e riguarda un insieme differente di problemi. Non esistono elementi per affermare che il bug del supply cap sia rimasto aperto in attesa del 23 ottobre, né che le correzioni al lending dimostrino prestiti già compromessi sulla mainnet. La distinzione è importante anche per gli utenti e gli operatori che utilizzano la rete per i pagamenti, un settore nel quale XRP Ledger ha già raggiunto volumi consistenti di transazioni automatizzate attribuite agli agenti AI. La sicurezza delle funzionalità già attive e la maturità del futuro mercato creditizio devono essere valutate separatamente, senza trasformare qualsiasi correzione in un incidente finanziario.

Continua con:

Stablecoin, l’Europa chiude il rendimento indiretto: lending e DeFi nel mirino

Stablecoin, tokenizzazione e licenze: la finanza tradizionale assorbe le crypto

Ripple vuole portare il credito sulla blockchain ma deve prima convincere i validatori

L’attivazione attesa per il 23 ottobre costituisce un passaggio tecnico importante, ma non rappresenta il lancio del mercato dei prestiti di Ripple. Il software è stato corretto, il pacchetto di fix ha raggiunto la maggioranza richiesta e il lending rimane privo di approvazione: tre condizioni differenti che descrivono lo stato effettivo del progetto. Per gli intermediari finanziari europei, compresi quelli italiani, il futuro utilizzo di un’infrastruttura simile richiederebbe comunque valutazioni ulteriori su rischio creditizio, responsabilità dell’intermediario, custodia degli asset e conformità normativa. Il fatto che un prestito venga registrato su una blockchain non elimina automaticamente gli obblighi derivanti dall’attività finanziaria sottostante e non trasforma un protocollo tecnicamente approvato in un servizio bancario autorizzato. La nuova generazione di strumenti XRPL potrebbe ridurre la complessità della registrazione e del regolamento delle operazioni, ma la loro maturità dipenderà dalla capacità di combinare consenso dei validatori, correttezza della contabilità e regole di gestione delle insolvenze. La lezione del caso XRP Ledger è che correggere un sistema finanziario prima della sua apertura rappresenta una misura preventiva utile, non la prova che il sistema sia già sicuro in ogni condizione. Il prossimo traguardo non sarà soltanto l’attivazione della patch, ma la capacità di portare il lending dalla proposta tecnica a un’infrastruttura operativa senza confondere la disponibilità del codice con la fiducia necessaria a gestire denaro reale.