Fout op de XRP Ledger in exchangecode kan duur komen te staan
Een XRP-transactie kan slagen en tóch minder afleveren dan een platform denkt. Precies daar zit het risico voor nieuwe XRPL-integraties.
XRPL-validator Vet waarschuwt dat aanvallers opnieuw lijken te testen of exchanges het verkeerde veld uitlezen. Wie alleen naar Amount kijkt, kan meer saldo bijschrijven dan er echt is ontvangen.
Dat is geen hack van de XRP Ledger. Het is een boekhoudfout buiten de ledger.
Partial Payments zijn geen bug
Partial Payments zijn een normale functie van de XRP Ledger. De afzender kan met de vlag tfPartialPayment aangeven dat een betaling mag slagen, ook als minder dan het maximale bedrag wordt afgeleverd.
Dat kan nuttig zijn bij wisselkoersen, transferkosten of beperkte liquiditeit. De transactie hoeft dan niet meteen te falen wanneer het volledige bedrag niet haalbaar is.
De officiële XRPL-documentatie over Partial Payments waarschuwt tegelijk voor verkeerde integraties. Een platform dat Amount leest als werkelijk ontvangen bedrag, kan zichzelf geld kosten.
In rippled API v2 is dat veld daarom hernoemd naar DeliverMax. Die naam zegt beter wat het is: het maximale bedrag dat mag worden afgeleverd.
Hoe de fout werkt
De aanval is simpel. Een gebruiker stuurt een Payment-transactie met een hoog maximum, maar levert door de Partial Payment-instellingen slechts een klein bedrag af.
De XRP Ledger verwerkt die betaling correct. De transactie kan de status tesSUCCESS krijgen.
Daarna gaat het mis bij het ontvangende platform. Als een exchange alleen ziet dat de transactie succesvol was en daarna het oude Amount-veld bijschrijft, krijgt de klant intern te veel saldo.
Een voorbeeld maakt het scherp. Een transactie vermeldt 10.000 eenheden als maximum, maar levert 1 eenheid af. Een goede integratie schrijft 1 bij. Een slechte integratie schrijft 10.000 bij.
De aanvaller probeert dat saldo daarna snel op te nemen, te ruilen of naar een andere asset te sturen.
delivered_amount is het veld dat telt
De XRPL-documentatie is op dit punt duidelijk. Ontvangende partijen moeten bij Payment-transacties kijken naar delivered_amount in de transactiemetadata.
Dat veld toont hoeveel waarde echt bij het bestemmingsadres is aangekomen.
Bij normale betalingen komt dat meestal overeen met het opgegeven bedrag. Bij Partial Payments kan het lager zijn. Bij tokens kunnen ook kleine afrondingsverschillen ontstaan.
Daarom moet een exchange niet eerst raden of Partial Payments actief zijn. De veilige route is simpeler: gebruik standaard delivered_amount.
Een succesvolle transactie vertelt dát er iets is gebeurd. delivered_amount vertelt hoeveel er echt is aangekomen.
Geen nieuwe XRP-hack
De waarschuwing betekent niet dat iemand XRP kan bijmaken. Er worden ook geen tokens uit het niets gecreëerd.
De blockchain doet wat hij moet doen. De fout ontstaat pas wanneer een bedrijf de data verkeerd vertaalt naar klantensaldi.
Dat verschil is belangrijk. Een kwetsbare exchange kan in zijn eigen database te veel saldo toekennen. De schade zit dan bij het platform, niet in de XRPL-consensus.
Voor gewone gebruikers van een goed gebouwde exchange verandert er weinig. Zij hoeven Partial Payments niet uit te schakelen. De functie is niet op zichzelf gevaarlijk.
Voor nieuwe projecten is dit wel een harde test. Wie XRPL-stortingen verwerkt, moet de protocolvelden begrijpen.
Vooral nieuwe platformen lopen risico
Grote exchanges draaien vaak al jaren XRP-stortingen en opnames. Die teams kennen de valkuil meestal.
Het risico zit vooral bij nieuwe wallets, betaalapps, gateways en tokenprojecten. Een ontwikkelaar kan denken dat één zichtbaar bedrag altijd gelijk is aan het ontvangen bedrag.
Dat klopt niet op XRPL.
Ook gekopieerde voorbeeldcode kan gevaarlijk zijn. Een systeem kan technisch verbinding maken met een node en transacties herkennen, maar financieel toch verkeerd boeken.
Een test met een gewone betaling bewijst dus weinig. Het systeem moet ook Partial Payments, destination tags, gevalideerde ledgers en foutcodes goed verwerken.
Minimale controles voor exchanges
Een robuuste XRPL-integratie controleert minimaal drie dingen:
- Staat de transactie in een gevalideerd ledger?
- Is het resultaat echt succesvol?
- Kloppen destination address, destination tag en delivered_amount?
Pas daarna mag een intern saldo worden verhoogd.
Destination tags zijn vooral relevant voor exchanges. Eén stortingsadres kan dan voor veel klanten worden gebruikt, terwijl de tag bepaalt welke klant het geld krijgt.
Daarna blijft interne controle nodig. Het totaal van klantensaldi moet regelmatig worden vergeleken met de werkelijke onchainbalansen.
Als die twee uit elkaar lopen, moeten stortingen en opnames niet door blijven draaien alsof er niets aan de hand is.
Kleine fout, groot gat
Partial Payments laten zien dat cryptobeveiliging niet stopt bij private keys of wallets. De software achter stortingen en opnames is net zo gevoelig.
Een verkeerd veld kan genoeg zijn.
Voor XRPL zelf is dit oude, gedocumenteerde functionaliteit. Voor nieuwe platforms blijft het een valkuil met echte financiële gevolgen.
Vet’s waarschuwing is daarom vooral een ontwikkelaarsalarm. Niet omdat de ledger stuk is. Wel omdat een slordige exchange-integratie een succesvolle transactie kan verwarren met het verkeerde bedrag.
Bij XRPL-stortingen is de regel kort: tesSUCCESS is niet genoeg. delivered_amount beslist.
Stop met te veel betalen voor je crypto. Bij de Amsterdamse exchange Finst handel je tegen de laagste tarieven van Nederland, zonder verborgen kosten.
👀 Bekijk Finst nu ›Let op: Beleggen in crypto brengt risico’s met zich mee. Handel alleen met geld dat u kunt missen.
Ga verder met lezen
Dit vind je misschien ook leuk
Laat mensen jouw mening weten
Lees ook
Populair Nieuws
Loading
