XRP Ledger-voorstel koppelt valutacodes direct aan uitgevers voor wallets
USD is op de XRP Ledger geen unieke asset. Meerdere uitgevers kunnen dezelfde code gebruiken, terwijl wallets en exchanges nu niet direct zien welk token wordt bedoeld.
Een nieuw voorstel voor rippled moet dat gat dichten. De API kan dan naast de valutacode ook het issueradres en de beschikbare hoeveelheid tonen.
Eén ticker kan meerdere assets verbergen
XRP is de eigen munt van de XRP Ledger. Andere tokens worden uitgegeven door accounts en bestaan als combinatie van een valutacode en een issueradres.
Twee partijen kunnen daardoor allebei een token met de code USD aanbieden. Voor het netwerk blijven dit verschillende assets, omdat de uitgevers niet hetzelfde zijn.
Dat onderscheid is vooral belangrijk bij stablecoins, getokeniseerde valuta en andere financiële producten. Alleen een ticker tonen is daar simpelweg te weinig.
De officiële XRPL-documentatie bevestigt dat tokens met dezelfde code maar verschillende uitgevers apart kunnen worden verhandeld. Iedere trustline is gekoppeld aan een account en een specifieke valutacode.
Huidige API geeft slechts een lijst met codes
De methode account_currencies toont welke valuta een account volgens zijn trustlines kan verzenden of ontvangen.
De huidige response bestaat uit eenvoudige lijsten:
{ "receive_currencies": ["EUR", "USD"],
"send_currencies": ["USD"]
}
Daarmee weet een wallet dat het account een USD-token kan gebruiken. De API vertelt echter niet welke partij dat token heeft uitgegeven.
XRPL waarschuwt zelf dat deze methode geen volledig bevestigde lijst oplevert. Ze is vooral bedoeld om gebruikersinterfaces te vullen.
Developers moeten nu vaak een tweede verzoek via account_lines uitvoeren. Daarna reconstrueren zij zelf welke trustline, issuer en hoeveelheid bij iedere valutacode hoort.
Nieuwe parameter maakt de asset zichtbaar
Pull request #7829 voegt de optionele parameter expanded toe. De ontwikkelaar diende het voorstel op 20 juli 2026 in bij de openbare rippled-repository.
Met expanded: true verandert de response van losse codes naar objecten met drie velden:
{
"currency": "USD",
"issuer": "rIssuerA...",
"value": "50"
}
Twee USD-tokens van verschillende uitgevers verschijnen daardoor als afzonderlijke regels. Een wallet kan vervolgens de juiste naam, uitgever en waarschuwing aan de juiste asset koppelen.
Een ticker is marketing. De combinatie van valutacode en issueradres bepaalt om welke XRPL-asset het werkelijk gaat.
De voorgestelde value is geen dollarprijs of marktwaarde. Bij verzenden toont deze waarde het beschikbare saldo. Bij ontvangen gaat het om de resterende ruimte binnen de trustline.
Uitgevers krijgen geen duizenden dubbele regels
Een account dat zelf tokens uitgeeft, kan trustlines met duizenden houders hebben. Een afzonderlijke API-regel voor iedere houder zou de response onnodig groot maken.
Het voorstel voegt zulke posities daarom samen tot één vermelding per valutacode. Het issueradres wordt dan het adres van het opgevraagde account.
Bij deze samengevoegde vermelding ontbreekt het veld value. De uitgever heeft immers niet één normale ontvangstruimte zoals een houder die heeft.
Minder API-verzoeken, maar geen volledige veiligheidscontrole
De indiener stelt dat de extra informatie tijdens dezelfde verwerking van trustlines kan worden berekend. De server hoeft daarvoor geen aanvullende ledgergegevens op te halen.
Dat kan wallets en crypto-exchanges werk besparen. Zij hoeven niet langer standaard een tweede API-methode aan te roepen om twee identiek genoemde tokens uit elkaar te houden.
Toch vervangt de uitbreiding account_lines niet volledig. De nieuwe response houdt geen rekening met bevriezing of verplichte autorisatie van een trustline.
Een asset kan dus in de uitgebreide lijst verschijnen, terwijl de bijbehorende lijn bevroren is. Ook kan een uitgever eerst toestemming moeten geven voordat het account het token werkelijk mag gebruiken.
De bestaande account_lines-methode rapporteert velden als authorized, peer_authorized, freeze en freeze_peer. Applicaties moeten die gegevens blijven controleren voordat zij een storting of betaling als uitvoerbaar behandelen.
RLUSD toont waarom de issuer telt
RLUSD gebruikt de native functionaliteit voor uitgegeven tokens op de XRP Ledger. Een account moet eerst een trustline met de officiële RLUSD-uitgever openen voordat het de munt kan ontvangen.
Een willekeurig ander account kan technisch ook een asset met dezelfde valutacode uitgeven. Die token is daarmee nog geen officiële RLUSD.
Ripple publiceert daarom het officiële issueradres. Wallets moeten die identificatie controleren in plaats van alleen op de zichtbare naam of ticker te vertrouwen.
Dat probleem wordt groter wanneer meer tokenisatie naar de XRP Ledger komt. Banken, fondsen en betalingsbedrijven kunnen vergelijkbare valutacodes gebruiken voor juridisch totaal verschillende producten.
Een duidelijk issueradres helpt dan voorkomen dat een interface twee assets onterecht als hetzelfde product presenteert.
Bestaande integraties blijven werken
De parameter is optioneel. Zonder expanded, of met expanded: false, blijft de huidige response met losse valutacodes bestaan.
Dat maakt het voorstel achterwaarts compatibel. Bestaande applicaties hoeven hun code niet direct aan te passen wanneer een toekomstige rippled-versie de functie ondersteunt.
Een verkeerde waarde voor expanded, zoals tekst in plaats van true of false, moet een invalidParams-fout opleveren.
Nog geen functie van het live netwerk
Pull request 7829 staat nog open. Er zijn op het meetmoment geen reviewers, geen toegewezen beheerder en geen geplande release.
De ontwikkelaar meldt dat de lokale tests zonder fouten zijn afgerond. Een automatische GitHub-controle waarschuwt wel dat de commit nog niet is ondertekend. Dat moet worden opgelost voordat samenvoeging mogelijk is.
Ook na goedkeuring verschijnt de uitbreiding niet direct op iedere server. Nodebeheerders moeten eerst een rippled-versie installeren waarin de code is opgenomen.
Validators hoeven niet over deze wijziging te stemmen. Het voorstel verandert geen transactieregels, saldi of consensus op de blockchain.
Het verandert alleen hoe servers bestaande trustlinegegevens via hun openbare API presenteren.
Kleine codewijziging pakt een groter probleem aan
De pull request voegt geen nieuwe tokenstandaard toe. Er ontstaat ook geen directe verandering voor XRP-houders.
De winst zit bij applicaties die uitgegeven assets moeten herkennen. Een exchange kan stortingsopties scherper tonen en een wallet kan twee gelijknamige tokens beter uit elkaar houden.
Dat klinkt als een kleine verbetering. Toch ontstaan juist bij namen, adressen en verkeerde tokenselecties dure fouten.
XRPL laat iedereen een USD-token uitgeven. Pull request 7829 probeert vooral te voorkomen dat een wallet vervolgens doet alsof iedere USD hetzelfde is.
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
