Gli asset manager si preparano al Batch dell'XRP Ledger mentre la correzione di sicurezza sposta l'attivazione al 9 ottobre
Punti chiave
- •La funzionalità Batch dell'XRP Ledger raggruppa da due a otto transazioni interne in una singola transazione esterna, con quattro modalità di esecuzione — ALLORNOTHING, ONLYONE, UNTILFAILURE e INDEPENDENT — che determinano come vengono gestiti i fallimenti.
- •Un rilascio d'emergenza della versione 3.4.1 di rippled ha aggiunto l'emendamento di sicurezza fixBatchV1_2, spostando l'attivazione prevista di Batch dal 29 settembre al 9 ottobre, a condizione del mantenimento del supporto dei validatori.
- •Una transazione Batch esterna può riport tesSUCCESS anche quando le transazioni interne falliscono, richiedendo ai sistemi di back office di esaminare ogni codice di risultato interno per evitare registri di regolamento disallineati.
- •RippleX afferma che asset manager e progetti commerciali si stanno preparando alla funzionalità, ma nessun asset manager in produzione con transazioni Batch live sulla mainnet è stato pubblicamente nominato.
- •I server con software inferiore alla versione 3.4.1 andrebbero in amendment blocked se la correzione si attiva prima dell'aggiornamento, rendendo gli aggiornamenti tempestivi dei nodi essenziali per l'accesso continuativo alla rete.

Ripple afferma che gli asset manager si stanno preparando a utilizzare il tipo di transazione Batch dell'XRP Ledger, una funzionalità che può far sì che più azioni sul ledger vadano a buon fine o fallite insieme. Tuttavia, un rilascio software d'emergenza ha spostato l'attenzione da un'attivazione prevista per il 29 settembre a un emendamento di sicurezza previsto per il 9 ottobre. La funzionalità in sé è specifica — e altrettanto specifica è l'evidenza del fatto che l'adozione istituzionale resta prospettica.
La promessa centrale è semplice: far sì che le fasi correlate vengano regolate entro una singola chiusura del ledger. Un asset manager che deve consegnare un token e ricevere un pagamento può preferire uno scambio all-or-nothing invece di inviare prima l'asset sperando che il denaro arrivi. Regolare entrambi i lati di uno scambio in un solo passaggio è la disciplina delivery-versus-payment affermata da tempo nei mercati titolati tradizionali, e Batch è progettato per offrirne una versione nativa del ledger. RippleX ha descritto asset manager e progetti commerciali che si preparano funzionalità, come riportato in un precedente articolo sull'interesse istituzionale. Quel resoconto non ha indicato pubblicamente un asset manager in produzione con una transazione Batch live sulla mainnet.
JUST IN: Brad Garlinghouse highlights why Ripple cannot control the $XRP Ledger Ripple operates only a small share of XRPL validators, and the $150M+ hack involving co-founder Chris Larsen showed that the company cannot reverse transactions or recover lost $XRP . pic.twitter.com/Pt4czYNSf1 — crypto.news (@cryptodotnews) September 27, 2026
Il calendario è cambiato prima della previsione originale di fine settembre. Il comunicato di rilascio della XRPL Foundation definisce la versione 3.4.1 un aggiornamento d'emergenza per questioni sensibili in materia di sicurezza. Aggiunge fixBatchV1_2, chiede ai server di effettuare tempestivamente l'aggiornamento e indica che l'emendamento era atteso per attivarsi il 9 ottobre se il supporto della supermaggioranza si fosse mantenuto. L'attivazione degli emendamenti sull'XRP Ledger dipende dal voto distribuito dei validatori e non da un intervento unilaterale, quindi i tempi seguono gli operatori della rete e non un'unica organizzazione. Si tratta di un'aspettativa condizionale, non di una promessa di lancio fissa.
Batch coordina le azioni all'interno di una singola chiusura del ledger
La specifica XLS-0056 descrive una transazione esterna che contiene da due a otto transazioni interne. Gli account coinvolti approvano la raccolta e una modalità selezionata determina cosa accade quando un'azione interna fallisce. Il ledger elabora la raccolta in una singola chiusura, evitando il divario tra submission non correlate che potrebbe lasciare una controparte con solo metà dell'accordo.
Si supponga che un fondo trasferisca un'istanza di obbligazione tokenizzata e riceva un token in dollari. Due transazioni ordinarie potrebbero essere inviate separatamente; se la prima riesce e la seconda fallisce, le controparti si trovano davanti a una controversia operativa e a una potenziale perdita. Con la modalità all-or-nothing, entrambe le azioni interne devono riuscire affinché lo scambio previsto si completi. Questo è il caso d'uso istituzionale più convincente, a condizione che token, strumento di pagamento, controparti e permessi siano già in essere.
Batch non crea un'obbligazione, non verifica la proprietà off-chain né obbliga una banca a rimborsare il token di pagamento. Coordina le azioni sul ledger. La finalità legale del regolamento, le restrizioni al trasferimento, la custodia e il rimborso dipendono ancora dagli strumenti e dalle istituzioni pertinenti. La distinzione è importante perché un trasferimento tecnicamente atomico è solo una parte della delivery versus payment.
JUST IN: $XRP Ledger's Batch feature passes, set for activation on September 29 The upgrade, which has secured 29 Yes votes, will allow up to 8 XRPL transactions to bundled into one, enabling atomic asset swaps, bundled DEX trades, $NFT -for- $NFT exchanges and single-transaction… pic.twitter.com/7CH34N1Yat — crypto.news (@cryptodotnews) September 15, 2026
Il tutorial per singolo account mostra il caso più semplice: più azioni di un solo account possono essere raggruppate in una modalità specificata. Le transazioni multi-account aggiungono le firme degli account i cui saldi o permessi sono interessati. Il tutorial multi-account descrive tale processo di firma coordinata.
Quattro modalità producono quattro accordi diversi
ALLORNOTHING è lo scambio pulito a due lati: ogni azione interna richiesta deve riuscire, altrimenti il gruppo previsto non si regola. ONLYONE prova alternative e si ferma dopo il primo successo, come ordini a tolleranze diverse. UNTILFAILURE elabora una sequenza fino a un fallimento. INDEPENDENT consente alle azioni nello stesso contenitore di riuscire o fallire indipendentemente. Definire atomiche tutte e quattro le modalità nel senso comune nasconderebbe la possibilità di completamento parziale.
Le modalità incidono sulla progettazione del prodotto. Un fondo che sposta due asset a fronte di un pagamento deve decidere se un singolo trasferimento fallito debba annullare l'intero pacchetto. Un market maker che invia offerte di riserva potrebbe preferire ONLYONE. Un emittente che distribuisce più pagamenti potrebbe tollerare esiti indipendenti, ma il suo team operativo dovrebbe poi riconciliare quali beneficiari sono stati pagati. La modalità è una decisione di rischio, non una scelta di formato.
Il limite di otto azioni è un altro vincolo reale. Un gestore che intende regolare 1.000 trasferimenti a investitori non può racchiudere tutti i 1.000 in un unico Batch secondo la proposta attuale. Al minimo teorico di 125 pacchetti da otto azioni, quei gruppi non sarebbero comunque atomici tra loro. Commissioni, firme, gestione della sequenza degli account e capacità di servizio diventano vincoli pratici ancora prima di considerare il processo aziendale off-chain.
Un precedente rapporto tecnico rilevava il lungo sviluppo e la storia di audit dell'aggiornamento. Tale contesto è rilevante per i tempi, ma non va confuso con un'affermazione secondo cui ogni applicazione costruita sopra sia stata auditata.
Il codice di successo esterno è una trappola contabile
La specifica indica che una transazione Batch esterna può riportare tesSUCCESS anche quando le transazioni interne falliscono; il risultato esterno copre l'elaborazione di sequenza e commissioni. Per sapere se un pagamento o una consegna sono avvenuti, il software deve esaminare i metadati delle transazioni interne e i singoli codici di risultato. Questo è un rischio di integrazione insolitamente concreto per qualsiasi istituzione il cui back office traduce uno stato di successo generico in un movimento di asset contabilizzato.
Si immagini un feed di negoziazione che legge solo il risultato esterno e accredita a un cliente un titolo tokenizzato. Se il trasferimento interno pertin non è andato a buon fine, il feed e il ledger divergono. Il sistema deve associare ogni azione interna al proprio genitore e al proprio risultato. La specifica raccomanda di usare la relazione ParentBatchID negli explorer e negli indicizzatori, e un desk dovrebbe testare i fallimenti in ogni modalità, non solo nel percorso felice.
L'errore può sopravvivere ai controlli ordinari perché la transazione esterna è reale e ha un ID di transazione. Un sistema di riconciliazione costruito sull'assunzione che una transazione equivalga a un'azione aziendale può superare il primo controllo. Il controllo corretto collega l'istruzione aziendale alla modalità, al pacchetto firmato completo, a ogni risultato interno e ai saldi finali degli asset — un lavoro che un asset manager deve svolgere anche se il livello di rete è corretto.
JUST IN: Asset managers are preparing for $XRP Ledger's next payments upgrade Batch V1.1 can bundle up to eight transactions into one operation, with RippleX saying commercial projects are already being built around the feature ahead of activation. pic.twitter.com/DmleX4GBiA — crypto.news (@cryptodotnews) September 20, 2026
L'aritmetica è modesta ma rivelatrice. Un Batch massimo contenente otto transazioni interne è una singola submission esterna, ma può richiedere almeno otto verifiche di esito, oltre alla verifica di commissione e sequenza esterna. Per 125 pacchetti completi che rappresentano 1.000 azioni interne, il back office ha bisogno di 1.000 esiti a livello di azione, non di 125 luci verdi di stato.
La correzione di sicurezza cambia la storia dell'attivazione
Il comunicato del 25 settembre della foundation indica che fixBatchV1_2 respinge le transazioni interne con wrapper errato e include ulteriori correzioni di sicurezza e stabilità. Il codice sorgente viene trattenuto temporaneamente per la natura sensibile alla sicurezza della modifica, con la promessa di pubblicazione e di una retrospettiva successiva. Ciò limita la capacità di terzi di esaminare la patch esatta prima della divulgazione. La trattenuta temporanea del codice di questo tipo è una pratica comune di divulgazione coordinata delle vulnerabilità nell'industria software. È un motivo per un'attribuzione precisa, non un motivo per speculare su un'eventuale sfruttabilità non divulgata.
Secondo il comunicato, i server con versione inferiore alla 3.4.1 andrebbero in amendment blocked se la correzione si attiva prima che abbiano effettuato l'aggiornamento. I voti dei validatori e gli aggiornamenti dei nodi contano quindi per l'accesso in produzione. Un quorum che segnala supporto non equivale al fatto che ogni wallet, custode, provider API e strumento contabile sia pronto per Batch. La precedente copertura degli aggiornamenti dei nodi XRPL illustrava l'effetto operativo di un amendment block in un rilascio precedente.
C'è anche una storia che non può essere omessa. Una divulgazione di vulnerabilità di febbraio descriveva un difetto in un precedente design di Batch che avrebbe potuto saltare i controlli di autorizzazione per altri firmatari quando un firmatario non finanziato compariva per primo; l'emendamento non era andato live. La copertura dell'audit di sicurezza esaminava come la revisione indipendente aveva individuato i problemi prima dell'uso in produzione. La patch di settembre riguarda una questione di wrapper descritta separatamente; nessuno dei due episodi dimostra che il design attuale sia insicuro, ma entrambi spiegano perché i tempi di deployment meritano attenzione.
Cosa potrebbero ottenere le istituzioni e cosa gli serve ancora
La consegna atomica contro pagamento è il caso più forte Un gestore potrebbe coordinare un trasferimento di token con il pagamento sullo stesso ledger, limitando l'esposizione temporanea creata dai trasferimenti sequenziali. Un emittente potrebbe raggruppare le fasi di configurazione dell'account, autorizzazione ed emissione laddove il protocollo consenta quei tipi di transazione. Le società di trading potrebbero usare percorsi di esecuzione alternativi. Si tratta di capacità, non di evidenze di asset e scambi live.
Gli asset tokenizzati richiedono emittenti, transfer agent o altre entità, regole sugli aventi diritto ammessi, procedure di custodia e uno strumento di pagamento con condizioni di rimborso accettabili. Un Batch può far eseguire le gambe on-chain secondo una regola scelta. Non può rendere un titolo giuridicamente valido in un'altra giurisdizione, ottenere il consenso del cliente per un'azione non correlata o garantire una gamba in contanti esterna presso una banca commerciale. Lo sfondo più ampio è la sperimentazione in corso del settore della gestione patrimoniale con fondi e obbligazioni tokenizzati, che mantiene la meccanica di regolamento come una domanda operativa ricorrente anche prima che esistano volumi di produzione.
Il caso di Ripple merita la sua versione più solida. Un meccanismo a livello di ledger può ridurre il lavoro di coordinamento per gli sviluppatori ed eliminare una classe reale di regolamenti parziali. La panoramica delle funzionalità XRPL descriveva Batch insieme ad altre funzionalità istituzionali, sebbene ogni emendamento segua il proprio processo. Se in futuro gestori nominati mostreranno un regolamento live e ripetuto di veri asset tokenizzati con risultati interni correttamente riconciliati, l'affermazione di adozione avrà un'evidenza concreta alle spalle.
Il limite è altrettanto chiaro. Un'azienda che prepara un pilota non è un asset manager che usa Batch in produzione. Nessuna dichiarazione pubblica di preparazione rivela volumi, commissioni risparmiate, controversie di regolamento prevenute o quale istituzione assume obblighi off-chain. Un annuncio può essere veritiero e restare comunque troppo precoce per sostenere conclusioni più ampie.
Il voto del ledger è solo il primo test di prontezza
L'attivazione prevista di fixBatchV1_2 il 9 ottobre dipende da un supporto sostenuto dei validatori. Gli operatori devono eseguire software compatibile. I wallet devono mostrare agli utenti tutte le azioni interne e la modalità selezionata prima di raccogliere una firma, come raccomanda la specifica. Gli indicizzatori devono esporre i risultati genitori e figli. I custodi necessitano di controlli di policy per le firme multi-account. Gli asset manager necessitano di riconciliazione e documentazione legale.
Non esiste una singola percentuale che mostri tutta questa prontezza. Il voto dei validatori misura l'accordo su una modifica del protocollo. Il test di produzione è se gli utenti reali possono preparare, firm, inviare, ispezionare e ripristinare un Batch fallito senza registri disallineati. La domanda commerciale senza risposta è quale istituzione nominata mostrerà un caso d'uso ripetibile una volta che l'emendamento e gli strumenti saranno live.
Cosa monitorare
- Stato dell'emendamento: se fixBatchV1_2 manterrà il supporto e si attiverà nella data prevista del 9 ottobre.
- Aggiornamenti dei server: la quota di operatori che eseguono la 3.4.1 prima che l'emendamento di sicurezza diventi obbligatorio.
- Divulgazione: la pubblicazione del codice sorgente della patch trattenuta e della retrospettiva promessa.
- Esiti interni: supporto di wallet e indicizzatori per la visualizzazione della modalità, dei link genitori e dei risultati a livello di azione.
- Evidenze di produzione: un asset manager nominato che riporti volumi Batch live e i suoi controlli di regolamento.
FAQ
Il Batch XRPL è già live sulla mainnet?
Gli emendamenti pertinenti e il loro stato live devono essere verificati al momento della pubblicazione. Il rilascio del 25 settembre descriveva una correzione di sicurezza attesa per attivarsi il 9 ottobre se il supporto dei validatori si fosse mantenuto.
Quante transazioni può contenere un Batch?
La specifica pubblicata XLS-0056 fissa un minimo di due e un massimo di otto transazioni interne nel design attuale.
Batch garantisce che ogni azione interna riesca?
Solo la modalità all-or-nothing è progettata affinché l'intero gruppo riesca insieme. Le altre modalità consentono deliberatamente un pattern diverso di esecuzione parziale.
Un solo asset manager può firmare per ogni controparte?
No. In un Batch multi-account, gli account interessati devono approvare la raccolta firmata secondo le regole di firma del protocollo.
tesSUCCESS significa che lo scambio è stato regolate?
Non di per sé. Il risultato esterno può riuscire mentre un'azione interna fallisce, quindi i sistemi devono esaminare ogni risultato interno e i saldi risultanti.
Batch renderà legalmente regolate le attività tokenizzate?
Può coordinare le fasi on-chain. I diritti legali, il rimborso e qualsiasi gamba di pagamento esterna dipendono ancora dalle condizioni dell'asset e dall'infrastruttura applicabile.
Cosa è cambiato nella versione 3.4.1?
La foundation ha descritto un rilascio di sicurezza d'emergenza che aggiunge fixBatchV1_2, incluso il rifiuto delle transazioni interne con wrapper errato.
Gli asset manager hanno dimostrato un uso live?
Ripple ha riferito preparativi, ma il resoconto pubblico citato non ha indicato un gestore in produzione con un regolamento Batch live ripetibile.
Questa è un'analisi educativa, non una consulenza sugli investimenti. Questo articolo ha finalità informative ed educative e non costituisce consulenza finanziaria o sugli investimenti. I dati riflettono i documenti normativi e le informazioni disponibili al momento della stesura e cambiano a ogni divulgazione. Nulla di quanto qui riportato è una raccomandazione a comprare, vendere o detenere qualsiasi titolo o asset. Effettuare sempre le proprie ricerche. Le informazioni sono aggiornate al 29 settembre 2026.