Aggiornamento del 22 ottobre 2026, 05:30 UTC: fixCleanup3_4_0 non si attiverà blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il 23 ottobre. Il suo sostegno è sceso a 26 dei 35 validatori fidati al flag ledger delle 12:54 UTC del 21 ottobre, sotto i 29 ora necessari, ed è tornato a 29 alle 14:46 UTC, facendo ripartire il conto alla rovescia di due settimane. L’attivazione è ora attesa intorno alle 14:46 UTC del 4 novembre, se la maggioranza regge; alle 04:38 UTC del 22 ottobre aveva 31 voti su 35, secondo i tracker XRPL Dashboard e XRPLWin, cifre riportate anche da CoinDesk. Gli emendamenti sul prestito non hanno ancora la maggioranza, con 19 voti su 35 ciascuno.
Il 17 ottobre l’XRP Ledger sembrava a meno di sei giorni dall’attivazione del suo ultimo pacchetto di correzioni, mentre la funzione di prestito nativa, quella che quest’anno ha attirato più attenzione, non aveva ancora i voti per andare in produzione. L’emendamento dell’XRP Ledger chiamato fixCleanup3_4_0 aveva il sostegno di 26 dei 32 validatori fidati contati sugli ultimi ledger, cioè l’81,25%, secondo XRPScan alle 19:27 UTC del 17 ottobre. Manteneva questa maggioranza dalle 09:34 UTC del 9 ottobre, il che allora portava la sua attivazione a circa le 09:34 UTC di venerdì 23 ottobre. Un calo di meno di due ore, il 21 ottobre, ha poi spostato la data al 4 novembre.
I due emendamenti sul prestito, LendingProtocol e la sua versione rivista LendingProtocolV1_1, avevano ciascuno 17 voti su 32 (53,1%) nello stesso momento, sugli stessi dati. SingleAssetVault, lo standard dei vault su cui poggia il prestito, ne aveva 19 (59,4%). Nessuno dei tre ha la maggioranza, quindi nessuno ha una data.
Bitcoin.com News ha riportato la stessa spaccatura il 17 ottobre, con conteggi leggermente diversi perché il numero di validatori che votano cambia da un ledger all’altro. Bitcoin.com ha indicato fixCleanup3_4_0 tra 26 e 29 sostenitori su 32-35 negli ultimi giorni. Salvo diversa indicazione, i conteggi vengono da XRPScan e sono fermi alle 19:27 UTC del 17 ottobre.
Emendamento XRP Ledger: come si attiva, 80% per due settimane
L’XRP Ledger non ha miner né un voto on-chain basato sul token. Le modifiche alle regole che ogni server applica, da un nuovo tipo di transazione a una correzione di arrotondamento, arrivano sotto forma di emendamenti, e sono i validatori della rete a decidere quando entrano in vigore. Ogni validatore segnala ogni emendamento che conosce con un sì o un no, e i server contano questi segnali a ogni flag ledger, uno ogni 256, cioè circa ogni 15 minuti.
Il conteggio che conta non riguarda tutti i validatori della rete, ma l’insieme di cui si fida la maggior parte dei server, la lista predefinita nota come UNL. XRPScan ne contava 32 sugli ultimi ledger alle 19:27 UTC del 17 ottobre.
La regola è breve. La pagina degli emendamenti noti su XRPL.org dice che gli emendamenti «possono essere attivati se mantengono una supermaggioranza per almeno due settimane». La pagina di XRPL.org su come funzionano gli emendamenti fissa quella supermaggioranza a più dell’80% dei validatori fidati. L’80% esatto non basta. Una correzione attivata nell’aprile 2021, fixAmendmentMajorityCalc, ha chiuso un varco di arrotondamento che una volta permise a un emendamento di passare con 28 validatori su 36 (77,8%); da allora il minimo non scende mai sotto l’80% della lista fidata.
Se in un qualsiasi momento di queste due settimane il sostegno scende all’80% o meno, l’emendamento perde la maggioranza e il conto alla rovescia si ferma. Quando la recupera, parte da zero un nuovo conto alla rovescia di 14 giorni.
Il 17 ottobre fixCleanup3_4_0 teneva la maggioranza per un solo voto
L’ottanta per cento di 32 validatori è 25,6. XRPScan indica una soglia di 25 per ogni emendamento votato da quei 32: è l’80% arrotondato per difetto, la cifra che il sostegno deve superare. Poiché la regola chiede più dell’80%, il minimo è 26 voti favorevoli. fixCleanup3_4_0 ne aveva esattamente 26 alle 19:27 UTC del 17 ottobre.
Restava quindi un margine di uno. Se un solo validatore favorevole fosse passato al no, l’emendamento sarebbe sceso a 25 su 32 (78,1%) e la data del 23 ottobre sarebbe saltata. Lo stesso poteva accadere se fosse cambiata la dimensione della lista fidata: con 33 validatori contati, l’80% sarebbe 26,4 e il minimo salirebbe a 27.
È andata così. Il 21 ottobre i tracker contavano 35 validatori fidati, il che portava il minimo a 29, e al flag ledger delle 12:54 UTC il sostegno era sceso a 26 voti. Non si sa se il calo sia dipeso dall’allungamento della lista, da un cambio di voto o da validatori offline (un validatore offline conta come un no): né XRPL Dashboard né XRPLWin indicano quali validatori si siano sfilati.
Il 17 ottobre non c’era alcun segnale di un cambio di voto: la maggioranza reggeva senza interruzioni dal 9 ottobre. Sei validatori nel conteggio non votavano sì alle 19:27 UTC di quel giorno, e le loro ragioni non sono pubbliche.
Contano anche le impostazioni predefinite. Secondo XRPL.org, l’ultima versione stabile di xrpld distribuisce fixCleanup3_4_0 impostato su «No» per default, quindi i 26 operatori che lo sostenevano il 17 ottobre l’hanno attivato di propria iniziativa.
I voti del 17 ottobre, emendamento per emendamento
La tabella qui sotto mostra gli emendamenti ancora aperti sull’XRP Ledger, con i voti registrati da XRPScan alle 19:27 UTC del 17 ottobre. Il numero XLS indica l’XRP Ledger Standard che descrive ciascuna funzione.
| Emendamento | Standard XLS | Voti | Quota | Stato |
|---|---|---|---|---|
| fixCleanup3_4_0 | Nessuno (raccolta di correzioni) | 26 su 32 | 81,25% | Maggioranza dal 9 ott., 09:34 UTC (allora prevista il 23 ott.; persa il 21 ott., ora prevista il 4 nov.) |
| SingleAssetVault | XLS-65 | 19 su 32 | 59,4% | Nessuna maggioranza |
| ConfidentialTransfer | XLS-96 | 19 su 32 | 59,4% | Nessuna maggioranza |
| LendingProtocol | XLS-66 | 17 su 32 | 53,1% | Nessuna maggioranza |
| LendingProtocolV1_1 | XLS-66 | 17 su 32 | 53,1% | Nessuna maggioranza |
| DynamicMPT | XLS-94 | 15 su 32 | 46,9% | Nessuna maggioranza |
| Sponsor | XLS-68 | 9 su 32 | 28,1% | Nessuna maggioranza |
Fonte: dati sugli emendamenti di XRPScan, 17 ottobre 2026, 19:27 UTC. Una vecchia correzione, fixBatchInnerSigs, che XRPScan segna come deprecata, aveva 10 voti su 35 in un’istantanea più vecchia della lista dei validatori nello stesso momento.
Diversi emendamenti sono già passati nelle ultime settimane. PermissionDelegationV1_1 (XLS-75) è stato attivato alle 21:29 UTC dell’8 ottobre con 28 voti su 33. Il giorno dopo fixBatchV1_2 è stato attivato alle 14:15 UTC con tutti i 32 voti, seguito da BatchV1_1 (XLS-56) alle 14:47 UTC con 27 su 32.
Quelle date mostrano anche come avviene il passaggio. BatchV1_1 ha ottenuto la maggioranza alle 14:46 UTC del 25 settembre ed è entrato in vigore alle 14:47 UTC del 9 ottobre, due settimane e meno di due minuti dopo. La modifica scatta sul primo flag ledger successivo alle due settimane, quindi con il primo conto alla rovescia le 09:34 UTC del 23 ottobre erano l’orario più anticipato possibile. Con il nuovo sono le 14:46 UTC del 4 novembre, e XRPL Dashboard prevede che i passaggi sul ledger si chiudano verso le 15:03 UTC.
Cosa cambia sul ledger con le correzioni di fixCleanup3_4_0
fixCleanup3_4_0 non aggiunge una funzione. È una raccolta di correzioni a codice già presente sul ledger, o in attesa di essere attivato, ed è arrivata con xrpld 3.4.0, la versione del server annunciata da XRPL.org il 16 settembre.
XRPL.org elenca correzioni in un’ampia gamma di ambiti: Single Asset Vault, Lending Protocol, market maker automatici (AMM), exchange decentralizzato con permessi, trust line, NFT, token multiuso (MPT), escrow, sponsorizzazione, firma delle transazioni e delega dei permessi. Alcune modifiche danno un’idea della portata.
- Un conto senza trust line non può più usare un’offerta per ricevere token da un emittente che ha attivato il flag che blocca le trust line in entrata.
- Le regole di clawback per i pool AMM sono più strette, compreso il trattamento dell’ultimo detentore dei token di un pool, e i clawback dei vault ricevono una correzione di arrotondamento.
- Le firme della controparte e dello sponsor ottengono prefissi di firma separati, in modo che un tipo di firma non possa essere riusato come l’altro.
- Completare o annullare un escrow libera prima la riserva del proprietario, così la restituzione di token al limite della riserva non fallisce più.
- I prelievi dai vault accettano gli ID delle credenziali, e depositi, prelievi e clawback arrotondano con maggiore precisione.
- Un default su un prestito è esentato da blocchi e lock degli MPT nel trasferimento dal broker al vault.
A parte, la versione 3.4.0 ritira un emendamento più vecchio, fixAMMOverflowOffer, il cui comportamento diventa parte permanente del protocollo.
Perché gli emittenti di token aspettano la correzione di PaymentBurn
Una correzione ha un uso pratico diretto. PermissionDelegationV1_1, attivo dall’8 ottobre, permette a un conto di cedere poteri specifici a un altro conto. Uno di questi poteri, il permesso PaymentBurn, serve a distruggere token. XRPL.org avverte che, prima della correzione, un delegato che lo detiene «può anche coniare nuovi token fungibili» in certe circostanze, e raccomanda di non delegare PaymentBurn finché fixCleanup3_4_0 non è attivo. La correzione fa sì che il ledger respinga un pagamento di solo burn che attraverserebbe un saldo pari a zero trasformandosi in un conio, a meno che il delegato non detenga anche il permesso PaymentMint.
Il problema riguarda i token emessi sul ledger, come i token su trust line e gli MPT, e XRPL.org afferma che gli altri permessi non sono toccati. Non riguarda l’offerta di XRP, l’asset nativo del ledger. Emittenti e custodian che hanno configurato la delega dovrebbero tenere PaymentBurn fuori da essa finché l’emendamento non è attivo, e verificare che lo sia.
Nodo xrpld e amendment blocked: cosa devono fare gli operatori prima del 4 novembre
Per la maggior parte degli operatori la risposta è: niente di nuovo. Un server deve conoscere un emendamento prima che la rete lo attivi; se non lo conosce, diventa amendment blocked. Un server bloccato non può applicare le nuove regole, quindi smette di seguire la rete e non può più validare né servire dati correnti del ledger. I fondi sul ledger non sono a rischio. Lo è il servizio che il nodo offre a un wallet, a un exchange o a un’applicazione.
Il codice di fixCleanup3_4_0 è in xrpld dalla versione 3.4.0. In pratica, però, la scadenza che contava è già passata il 9 ottobre. La versione di emergenza xrpld 3.4.1, annunciata il 25 settembre e taggata su GitHub il 10 ottobre, che ha rafforzato il motore dei pagamenti contro il difetto descritto nel nostro articolo sul bug di overflow dell’XRP Ledger, conteneva anche fixBatchV1_2, e quell’emendamento è stato attivato il 9 ottobre. XRPL.org aveva avvertito che i server non aggiornati alla 3.4.1 sarebbero diventati amendment blocked e «incapaci di restare sincronizzati con il resto della rete».
Restano tre casi:
- I server con xrpld 3.4.1 o successivo contengono già il codice di fixCleanup3_4_0 e non richiedono azioni per questo emendamento.
- I server ancora alla 3.4.0 sono amendment blocked da quando fixBatchV1_2 è entrato in vigore il 9 ottobre, e i loro operatori hanno bisogno della 3.4.1 per rientrare nella rete.
- Tutto ciò che gira sulla 3.3.x o su versioni precedenti è bloccato per la stessa ragione, e non avrebbe nemmeno fixCleanup3_4_0.
Chi installa da pacchetti deve tenere conto di un cambiamento arrivato con la 3.4.0: i pacchetti DEB e RPM sono ora distribuiti da packages.xrplf.org e firmati con una chiave della XRPL Foundation, quindi i sistemi configurati per il vecchio repository richiedono la nuova sorgente e la nuova chiave.
Gli emendamenti di pulizia sono arrivati a ritmo costante quest’anno. fixCleanup3_1_3 è stato attivato il 27 maggio, fixCleanup3_2_0 il 29 luglio e fixCleanup3_3_0 l’11 settembre. Se fixCleanup3_4_0 entra in vigore il 4 novembre, l’intervallo sarà di quasi otto settimane, tra le nove e le sei dei due precedenti.
Protocollo di prestito XRP Ledger: cosa aggiungerebbero XLS-65 e XLS-66
Il prestito è la storia più grande, e la più lenta. Poggia su due standard entrati nel codice del server con xrpld 3.1.0.
Il primo, XLS-65, crea il Single Asset Vault. Gli utenti depositano un solo asset in un vault condiviso, per esempio XRP o un token emesso sul ledger, e ricevono quote che rappresentano la loro parte del pool. Il vault è il serbatoio di denaro; da solo non presta nulla.
Il secondo, XLS-66, aggiunge il Lending Protocol. Un loan broker attinge a un vault per concedere prestiti a termine fisso. XRPL.org li descrive come non garantiti: nulla viene bloccato a garanzia, a differenza della maggior parte del prestito DeFi, in cui chi prende in prestito deposita prima una garanzia negli smart contract. Le verifiche di credito avvengono fuori dal ledger, tramite sottoscrizione e gestione del rischio, mentre rimborsi, interessi e insolvenze sono registrati sul ledger.
La versione rivista, LendingProtocolV1_1, è arrivata con xrpld 3.4.0 e cambia il progetto in due punti. Introduce vault a chiusura definita che funzionano in tre fasi: sottoscrizione, quando arrivano i depositi, poi investimento, poi rimborso. Una volta attivato, i nuovi loan broker potranno essere creati solo su vault a chiusura definita. Sposta inoltre la contabilità dei vault su base di cassa, così gli interessi contano come reddito solo quando chi ha preso il prestito li paga davvero.
Questo disegno guarda alle istituzioni più che ai trader retail: un fondo o una banca potrebbe raccogliere un pool per un periodo stabilito, prestarlo a debitori selezionati e restituirlo con gli interessi, il tutto registrato su un ledger pubblico. Si accorderebbe con la spinta di Ripple a far usare a società professionali XRP e la sua stablecoin RLUSD, come nell’accordo sulle garanzie in RLUSD di Ripple Prime. Nulla di tutto ciò può girare sulla mainnet dell’XRP Ledger finché gli emendamenti non passano.
Perché i validatori frenano sul prestito
Il sostegno al prestito è cresciuto, ma lentamente. A inizio luglio, Digital Today riportava che XLS-66 aveva circa il 20% dei voti dei validatori e XLS-65 il 22,86%. Al 17 ottobre, entrambi gli emendamenti sul prestito erano al 53,1% e il vault al 59,4%.
Nello stesso articolo di Digital Today, datato 1° luglio, Mayukha Vadari, ingegnere software di RippleX, diceva che i validatori aspettavano le correzioni del successivo emendamento di pulizia, aggiungendo: «Safety first» (la sicurezza prima di tutto). Il pacchetto a cui si riferiva era fixCleanup3_2_0, attivato il 29 luglio. Graffe, un operatore di validatori citato dalla testata a partire da un post su X, diceva che i progressi su XLS-65 e XLS-66 erano molto lenti e che i numeri dei voti erano cambiati a fatica per molto tempo.
La nostra lettura, che nessun validatore ha confermato per questa versione, è che la stessa logica valga ora per fixCleanup3_4_0. Il pacchetto corregge direttamente il codice dei vault e del prestito, e un operatore che vuole quelle correzioni attive prima di accendere il prestito aspetterebbe l’attivazione del pacchetto, ora attesa per il 4 novembre. Lo spavento per l’overflow di ottobre ha dato agli operatori un motivo in più per muoversi con cautela.
Il divario resta ampio. Con 32 validatori contati, LendingProtocolV1_1 aveva bisogno di altri nove voti favorevoli alle 19:27 UTC del 17 ottobre per arrivare a 26, e SingleAssetVault di sette. Alle 04:38 UTC del 22 ottobre i due emendamenti sul prestito avevano 19 voti su 35 ciascuno, dieci in meno dei 29 ora richiesti, secondo XRPL Dashboard e XRPLWin; SingleAssetVault ne aveva 21, secondo XRPLWin. Anche se arrivassero domani, ogni emendamento avrebbe poi bisogno di altre due settimane di sostegno stabile. Bitcoin.com osserva che tutti e tre gli emendamenti necessari al prestito completo sono sotto la supermaggioranza, senza data di attivazione. Né RippleX né la XRPL Foundation hanno pubblicato, per quanto abbiamo potuto verificare, una tempistica per il prestito.
Cosa seguire fino al 4 novembre e dopo
La prima data è fissata dalle regole. Se fixCleanup3_4_0 mantiene più dell’80% dei validatori fidati (29 su 35 al conteggio del 22 ottobre) a ogni flag ledger fino a circa le 14:46 UTC di mercoledì 4 novembre, si attiva al flag ledger successivo e l’avvertimento su PaymentBurn potrà essere tolto. È già successo una volta: un calo di meno di due ore il 21 ottobre gli è costato 12 giorni. Ogni nuovo calo farebbe ripartire il conteggio.
Dopo, i numeri da seguire sono i voti su SingleAssetVault e sui due emendamenti del prestito, su XRPScan o su XRPL.org. Un balzo del sostegno nei giorni successivi al 4 novembre sarebbe coerente con la lettura sopra; nessun cambiamento suggerirebbe che i validatori vogliano prima qualcos’altro. Non è stata annunciata alcuna nuova versione di xrpld né alcun nuovo emendamento.
I mercati non hanno reagito al voto. XRP scambiava intorno a 1,30 dollari alle 19:10 UTC del 17 ottobre, in calo del 7,5% in sette giorni secondo i dati di mercato di Coindaro, e nulla collega quel movimento al calendario degli emendamenti. Chi è nuovo al modo in cui validatori e ledger si incastrano può cominciare dalla nostra guida a cos’è una blockchain.