All'8 settembre 2026 i validatori della XRP Ledger hanno mantenuto l'emendamento BatchV1_1 a 24 voti su 35, pari al 68,57% di consenso, lasciandolo ben lontano dalla supermaggioranza superiore all'80% richiesta per avviare la finestra di attivazione di due settimane. Sebbene BatchV1_1 sia incluso nel software rippled, ciò non significa che sia attivo sulla XRP Ledger, e i vantaggi in termini di DeFi e funzionalità spesso associati all'aggiornamento restano non confermati finché i validatori non superano quella soglia.

L'emendamento Batch della XRP Ledger è ora al 68% di consenso. Potremmo vedere Batch attivo entro la fine del mese. Batch sbloccherà molti nuovi casi d'uso per l'ecosistema XRP. Puoi seguire i progressi qui pic.twitter.com/uoo2Q5kf0X — moonkie (@xmoonkie), 7 settembre 2026

BatchV1_1 resta sotto la soglia di attivazione

BatchV1_1 è arrivato all'interno di rippled 3.3.0, rilasciato il 6 agosto 2026, ma l'inclusione nel codice e l'attivazione sulla mainnet sono eventi distinti sulla XRP Ledger. A differenza delle reti che distribuiscono le modifiche di protocollo tramite hard fork o votazioni di governance off-chain, le modifiche su XRPL entrano in funzione automaticamente tramite il consenso dei validatori: una volta che un emendamento mantiene la maggioranza per il periodo richiesto, si attiva su ogni server che esegue software compatibile, senza alcuna scissione coordinata della chain. Alla fotografia dell'8 settembre, l'emendamento si attestava al 68,57% di consenso nella Unique Node List predefinita, secondo i dati di XRPScan.

L'attivazione richiede più dell'80% di approvazione mantenuta per 14 giorni consecutivi, e quel conto alla rovescia non è ancora iniziato. Con l'attuale configurazione a 35 validatori, servono almeno 29 voti favorevoli per superare la soglia, anche se il numero esatto può variare se cambia l'insieme dei validatori partecipanti. Il consenso può anche riscendere sotto l'80% durante il conto alla rovescia, azzerando completamente il timer.

La versione 3.3.0 non è stata un rilascio monofunzione – ha introdotto anche ConfidentialTransfer, DynamicMPT, Sponsor e PermissionDelegationV1_1, inserendo BatchV1_1 in un pacchetto più ampio di aggiornamenti orientati al mondo istituzionale. Gli investitori che monitorano la crescita della XRP Ledger e i flussi in entrata legati agli ETF dovrebbero considerare questi emendamenti come narrazioni parallele, ciascuna delle quali richiede la propria supermaggioranza di validatori prima che qualsiasi funzionalità diventi operativa.

Cosa potrebbero abilitare le transazioni Batch se attivate

Una volta attive, una transazione Batch potrebbe raggruppare fino a otto transazioni interne in un'unica transazione esterna, con quattro modalità di esecuzione: "Tutto o niente", che richiede che ogni transazione interna abbia successo; "Solo una", che applica la prima operazione riuscita; "fino al fallimento", che elabora le transazioni finché una non fallisce; e "Indipendente", che tenta ogni transazione inclusa indipendentemente dall'esito.

I potenziali casi d'uso includono swap atomici di token, conio di NFT abbinato a un'offerta, commissioni di piattaforma raggruppate e azioni coordinate su più account – a condizione che ogni account partecipante autorizzi l'intera raccolta. Ogni transazione interna eseguita con successo conserverebbe i propri metadati più un riferimento al batch genitore, una struttura pensata per ridurre l'infrastruttura di coordinamento esterno che le applicazioni attualmente necessitano per le azioni in più passaggi.

Restano però capacità progettate e non risultati operativi. I guadagni di efficienza (e qualsiasi conseguente aumento dell'attività su casi d'uso come i settlement in RLUSD e i flussi di finanza tokenizzata su XRPL) dipendono sia dall'attivazione da parte dei validatori sia dal successivo supporto di wallet e SDK.

La storia di sicurezza dietro l'emendamento sostitutivo

BatchV1_1 non è il codice Batch originale: è una riscrittura. Gli sviluppatori hanno disattivato l'emendamento originale a febbraio 2026 dopo che Pranamya Keshkamat e lo strumento di sicurezza Apex di Cantina AI hanno identificato una grave falla nella logica di verifica dei firmatari del batch. Il bug avrebbe potuto consentire a un attaccante di saltare i controlli di autorizzazione per alcuni partecipanti e inviare transazioni non autorizzate dall'account di una vittima.

In modo cruciale, la versione vulnerabile non è mai stata attivata sulla mainnet, e XRPL Labs ha dichiarato che nessun fondo utente è stato messo a rischio. Rippled 3.1.1 ha marcato l'emendamento Batch originale come non supportato, e il suo sostituto elimina l'errore di uscita anticipata, aggiunge tutele di autorizzazione e restringe i controlli sui firmatari, con un audit indipendente che ha esaminato BatchV1_1 prima della sua inclusione nella 3.3.0.

Perché questa non è ancora un catalizzatore del prezzo di XRP

Questa notizia non ha prodotto un movimento di prezzo significativo, ed è improbabile che cambi finché il consenso resta al 68,57%. L'emendamento modifica le funzionalità transazionali del ledger, non le regole di offerta o emissione di XRP, quindi non presenta alcun diretto angolo di politica monetaria per i trader che valutano il potenziale breakout di XRP nel breve termine.

Qualsiasi incremento del volume di transazioni XRPL, dell'attività DeFi o della domanda di token legato a Batch resta prospettico, subordinato al superamento della supermaggiorità in fase di attivazione e poi all'effettiva integrazione della funzione da parte di wallet, exchange e protocolli DeFi. Fino ad allora, Batch funge da storia di infrastruttura più che da catalizzatore di valutazione confermato.

Il prossimo traguardo è una supermaggioranza di validatori sostenuta

Il prossimo punto di controllo confermato per i validatori XRPL è il superamento dell'80% di consenso. Solo dopo che ciò accadrà il ledger inizierà a registrare il periodo obbligatorio di 14 giorni di maggioranza continua. Il consenso deve rimanere sopra la soglia per l'intero periodo, altrimenti l'orologio si azzera.

Un'attivazione a fine settembre era matematicamente possibile alla fotografia dell'8 settembre, ma nulla è programmato. Gli operatori di nodo devono prima eseguire software che supporti BatchV1_1 prima di poter votare, e XRPL ha separatamente avvertito gli operatori Clio di aggiornare alla versione 2.8.0 affinché l'infrastruttura API possa elaborare i nuovi formati di transazione e di ledger se l'emendamento si attiva.

Fonte: https://icobench.com/news/xrp-news-batchv1-1-xrp-ledger-vote/