De officiële documentatie van de XRP Ledger (XRPL) raadt account houders aan om de PaymentBurn-permissie niet te delegeren totdat een amendement genaamd fixCleanup3_4_0 op het netwerk is geactiveerd. De waarschuwing draait om een fout op de grens tussen het verbranden en aanmaken van tokens — een fout die in bepaalde omstandigheden een delegate met alleen burn-rechten nieuwe tokens liet uitgeven in plaats van vernietigen. De fout kan zelf geen nieuw XRP creëren, maar raakt juist de enige taak die permissiedelegatie ontworpen is om achter offline sleutels te houden.

Wat een burn-only delegate moest doen

Permissiedelegatie laat een account specifieke taken overdragen aan een tweede account, die ondertekent met zijn eigen sleutels. De documentatie van XRPL is expliciet over het doel: routinewerk draait op sleutels die online worden gehouden, terwijl de sleutels met volledige controle offline blijven voor speciale taken zoals het uitgeven van tokens. De gids van Coindoo over XRPL's gedelegeerde accountcontroles beschrijft hoe instellingen die rollen kunnen verdelen.

Twee van de twaalf gedetailleerde permissies van het ledger hebben betrekking op het tokenaanbod. PaymentMint omvat betalingen die fungibele tokens of Multi-Purpose Tokens (MPT's) creëren. PaymentBurn omvat betalingen die ze vernietigen, en de documentatie stelt de grens precies vast: verbranden stopt bij een saldo van nul.

De fout zit precies op die grens. Vóór de fix kon een betaling onder PaymentBurn in bepaalde omstandigheden voorbij nul gaan en nieuwe trust-line tokens of MPT's uitgeven. fixCleanup3_4_0 verwerpt elke burn-only gedelegeerde betaling waarvan het bedrag in muntatie zou overgaan, tenzij dezelfde delegate ook PaymentMint heeft. De andere elf gedetailleerde permissies zijn niet aangetast.

Dat maakt de bug beperkt in bereik maar onaangenaam in wat hij raakt. Alleen een account dat een issuer al als delegate heeft aangewezen kan hem gebruiken, maar wat hij ontsluit is uitgifte — precies de taak die delegatie achter offline sleutels moest houden.

Cold storage dekt de sleutels van een delegate niet

Gedelegeerde transacties worden ondertekend met de eigen master key, regular key of multi-signing-lijst van de delegate. Een issuer kan zijn hoofdreferenties volledig offline houden en toch blootgesteld zijn als een delegate met PaymentBurn gecompromitteerd wordt, verkeerd geconfigureerd is of buiten zijn mandaat handelt.

Voor een fiat-gedekt token is het economische risico units in omloop zonder matchende reserves. Een reserve-attest toont de activa die op een rapportagedatum tegen uitstaande tokens worden aangehouden. Het zegt niets over welke accounts dat aantal tussen rapportages door kunnen wijzigen — en dat is precies de controle die deze fout verzwakt.

Delegatie ging live voordat de fix de stemmen had

Dit is de tweede fout die in XRPL's delegatiefunctie is gevonden. De oorspronkelijke versie werd in 2025 ingetrokken nadat een community-tester op devnet ontdekte dat hij transactiekosten kon berekenen aan accounts die niet hadden ondertekend, en de officiële openbaarmaking bevestigt dat hij nooit Mainnet bereikte. Zijn vervanger, PermissionDelegationV1_1, ging op 8 oktober live, volgens XRPL's amendementendashboard, terwijl de PaymentBurn-correctie nog validatorsteun verzamelde.

De blootstelling is daarom per account: alleen issuers die sinds de lancering PaymentBurn hebben toegekend zijn getroffen. Elke toekenning is openbaar, omdat Delegate-ledgerentries het toekennende account, de delegate en zijn permissielijst vastleggen. Op het moment van schrijven identificeert noch de XRPL-documentatie noch gepubliceerde berichtgeving een getroffen issuer of enig misbruik.

Een toename van het aanbod bewijst op zichzelf niets, want een issuer kan PaymentMint opzettelijk hebben toegekend. Wat uitgelegd zou moeten worden, is een delegate die alleen PaymentBurn heeft en waarvan de betalingen tokens toevoegden.

Wat issuers vóór woensdag kunnen controleren

Het gepubliceerde advies van XRPL is om PaymentBurn niet meer te delegeren totdat de fix is geactiveerd. Voor issuers die hem al hebben toegekend verloopt het werk in deze volgorde:

1. Haal elke Delegate-entry op het uitgevende account op en markeer elke permissielijst die PaymentBurn bevat.
2. Stuur DelegateSet opnieuw met de volledige lijst van te behouden permissies. Een nieuwe lijst vervangt de oude, dus alles wat wordt weggelaten, komt te vervallen.
3. Behandel een toekenning pas als ingetrokken zodra de wijziging in een gevalideerd ledger verschijnt.
4. Controleer de eerdere betalingen van de delegate afzonderlijk, want het intrekken van bevoegdheden stopt toekomstig gebruik zonder eerdere transacties ongedaan te maken.
5. Delegeer PaymentBurn pas weer nadat fixCleanup3_4_0 als geactiveerd op Mainnet wordt getoond.

Waarom de stemming nog kan mislopen

Volgens de officiële amendementsregels heeft een wijziging een supermeerderheid van vertrouwde validators nodig die twee weken aaneengesloten moet blijven staan. Met 35 validators in de gevolgde set ligt die drempel op 29, en het eronder zakken zet de klok terug. Die reset heeft al een keer plaatsgevonden; momenteel steunen 33 van de 35 vertrouwde validators de fix.

Zelfs met steun intact markeert 14:46 UTC het moment waarop het venster van twee weken opent. Activering gebeurt op een ledger-stemcheckpoint, dus de wijziging kan enige tijd daarna van kracht worden.

Validators stemmen ook over veel meer dan alleen deze correctie. fixCleanup3_4_0 bundelt 25 wijzigingen op het gebied van kluizen, lending, geautomatiseerde market makers, NFT's, escrow en sponsoring, en de PaymentBurn-fix is het laatste item op de lijst. Hij repareert lendingcode zonder de Lending Protocol zelf te activeren, waarvoor een eigen amendement nog openstaat voor stemming.

Voor issuers is de bevestiging die telt dat fixCleanup3_4_0 als geactiveerd op Mainnet wordt vermeld. Tot die tijd draagt een PaymentBurn-toekenning meer bevoegdheid dan de naam doet vermoeden.

Dit artikel verscheen oorspronkelijk op Coindoo.