La documentazione ufficiale dell'XRP Ledger (XRPL) consiglia ai titolari di account di non delegare il permesso PaymentBurn fino all'attivazione sulla rete di un emendamento chiamato fixCleanup3_4_0. L'avvertimento riguarda un difetto situato al confine tra burn e mint di token — un difetto che, in determinate circostanze, permetteva a un delegate con solo permesso di burn di emettere nuovi token invece di distruggerli. Il difetto non può creare nuovo XRP, ma tocca l'unica attività che la delega di permessi era progettata per tenere dietro a chiavi offline.

A Cosa Serviva un Delegate con Solo Permesso di Burn

La delega di permessi consente a un account di affidare compiti specifici a un secondo account, che firma con le proprie chiavi. La documentazione XRPL è esplicita riguardo allo scopo: le operazioni di routine girano su chiavi mantenute online, mentre le chiavi con controllo completo restano offline per attività speciali come l'emissione di token. La guida di Coindoo ai controlli di account delegati di XRPL spiega come le istituzioni potrebbero dividere questi ruoli.

Due dei dodici permessi granulari del ledger riguardano l'offerta di token. PaymentMint copre i pagamenti che creano token fungibili o Multi-Purpose Token (MPT). PaymentBurn copre i pagamenti che li distruggono, e la documentazione ne definisce con precisione il limite: il burn si ferma a saldo zero.

Il difetto si trova proprio su quel confine. Prima della correzione, un pagamento inviato sotto PaymentBurn poteva, in determinate circostanze, superare lo zero ed emettere nuovi trust-line token o MPT. fixCleanup3_4_0 respinge qualsiasi pagamento delegato di solo burn il cui importo supererebbe il confine verso il mint, a meno che lo stesso delegate non detenga anche PaymentMint. Gli altri undici permessi granulari non sono interessati.

Questo rende il bug di portata ristretta ma tocca qualcosa di delicato. Solo un account che un emittente ha già scelto come delegate può usarlo, ma ciò che sblocca è l'emissione — proprio l'attività che la delega doveva tenere dietro a chiavi offline.

Il Cold Storage Non Copre le Chiavi di un Delegate

Le transazioni delegate sono firmate con la master key del delegate, la regular key o la lista multi-firma. Un emittente può mantenere le proprie credenziali principali completamente offline ed essere comunque esposto se un delegate che detiene PaymentBurn viene compromesso, è mal configurato o agisce oltre il proprio mandato.

Per un token garantito da valuta fiat, il rischio economico è dato da unità in circolazione senza riserve corrispondenti. Un'attestazione di riserva mostra le attività detenute a fronte dei token in circolazione in una data di riferimento. Non dice nulla su quali account potrebbero modificare tale cifra tra le varie verifiche — ed è proprio quel controllo che questo difetto indebolisce.

La Delegata è Stata Lanciata Prima che la Sua Correzione Avesse i Voti

Questo è il secondo difetto trovato nella funzionalità di delega di XRPL. La versione originale fu ritirata nel 2025 dopo che un tester della community scoprì su devnet che poteva addebitare commissioni di transazione ad account che non avevano firmato, e la divulgazione ufficiale conferma che non raggiunse mai il Mainnet. Il suo sostituto, PermissionDelegationV1_1, è diventato operativo l'8 ottobre, secondo la dashboard degli emendamenti di XRPL, mentre la correzione per PaymentBurn st ancora raccogliendo il supporto dei validator.

L'esposizione è quindi account per account: sono interessati solo gli emittenti che hanno concesso PaymentBurn dal lancio. Ogni concessione è pubblica, perché le voci Delegate del ledger registrano l'account concedente, il delegate e la sua lista di permessi. Al momento della scrittura, né la documentazione XRPL né le pubblicazioni di settore identificano un emittente interessato o un uso improprio.

Un aumento dell'offerta da solo non proverebbe nulla, poiché un emittente può aver concesso PaymentMint deliberatamente. Ciò che richiederebbe una spiegazione è un delegate che detiene solo PaymentBurn i cui pagamenti hanno aggiunto token.

Cosa Possono Verificare gli Emittenti Prima di Mercoledì

Il consiglio pubblicato da XRPL è di smettere di delegare PaymentBurn fino all'attivazione della correzione. Per gli emittenti che l'hanno già concessa, il lavoro procede in questo ordine:

1. Estrarre ogni voce Delegate dell'account emittente e segnalare qualsiasi lista di permessi contenente PaymentBurn.
2. Reinvia DelegateSet con la lista completa dei permessi da mantenere. Una nuova lista sostituisce quella precedente, quindi tutto ciò che viene omesso viene rimosso.
3. Considerare una concessione revocata solo quando la modifica appare in un ledger validato.
4. Verificare separatamente i pagamenti passati del delegate, perché la revoca dell'autorità impedisce usi futuri senza annullare le transazioni precedenti.
5. Delegare nuovamente PaymentBurn solo dopo che fixCleanup3_4_0 risulta attivato sul Mainnet.

Perché il Voto Può Ancora Slittare

Secondo le regole ufficiali sugli emendamenti, una modifica richiede una supermaggioranza di validator fidati mantenuta per due settimane ininterrotte. Con 35 validator nell'insieme monitorato, la soglia è 29, e scendere al di sotto di essa azzera il timer. Tale azzeramento si è già verificato una volta; il supporto attualmente si attesta su 33 dei 35 validator fidati che sostengono la correzione.

Anche con il supporto intatto, le 14:46 UTC segnano l'apertura della finestra di due settimane. L'attivazione avviene in corrispondenza di un checkpoint di voto del ledger, quindi la modifica può entrare in vigore qualche tempo dopo.

I validator stanno votando anche su molto più di questa singola correzione. fixCleanup3_4_0 raggruppa 25 modifiche relative a vault, prestiti, market maker automatizzati, NFT, escrow e sponsorizzazione, e la correzione per PaymentBurn è l'ultimo elemento della lista. Corregge il codice dei prestiti senza attivare il Lending Protocol stesso, che ha un proprio emendamento ancora in votazione.

Per gli emittenti, la conferma che conta è fixCleanup3_4_0 elencato come attivato sul Mainnet. Fino ad allora, una concessione PaymentBurn porta con sé un'autorità superiore a quella che il suo nome suggerisce.

Questo articolo è apparso originariamente su Coindoo.