Community Trust ScoreVerified
A quiet feature buried in the XRP Ledger’s code has been catching developers off guard. Hussein Zangana, known in the community as Vet, flagged the issue publicly — warning that the partial payment feature can be exploited to trick exchanges and new projects into crediting more funds than were actually received.
The mechanics here aren’t complicated, but they’re easy to miss. On the XRP Ledger, a partial payment lets a transaction be marked as successful even when it delivers less than the stated amount. That’s not a bug. It’s intentional design — useful, actually, for returning payments without racking up extra costs. But if a platform assumes the full stated amount landed in their wallet, they’re basically handing bad actors a free pass to claim credit for money that never arrived.
Not a new problem. Not a solved one either.
The “Amount” Field Trap
The XRP Ledger has two relevant fields in transaction metadata: the “Amount” field and the “delivered_amount” field. The “Amount” field shows what the sender claimed to send. The “delivered_amount” field shows what actually moved. Those two numbers can be very different, and that gap is where the exploit lives.
Vet’s point was pretty direct: anyone building on the XRP Ledger needs to pull the “delivered_amount” field to confirm what really hit their account. Relying on “Amount” alone is basically trusting the sender to be honest — which, in a permissionless financial network, isn’t a great assumption.
The XRPL documentation spells this out. It says to use “delivered_amount” to verify the actual amount received, not “Amount.” That’s not a subtle footnote. It’s a core security practice. But new teams, moving fast, integrating quickly, often skip past it.
And fees don’t help clarify things. Transaction costs on the XRP Ledger get deducted from the sender’s account regardless of how the payment resolves. They’re not bundled into the stated payment amount. So a project that’s already confused about “Amount” versus “delivered_amount” now has an extra variable muddying the accounting. The numbers can look fine on the surface and still be completely wrong.
Why New Projects Are the Weak Link
Large exchanges probably have this handled. They’ve been around long enough, seen enough edge cases, and have engineering teams that actually read the documentation before shipping. It’s the newer platforms where things get dicey — startups building wallets, DeFi integrations, payment gateways, anything that touches XRP inflows without a deep institutional knowledge base.
Vet specifically called out the risk for new projects, and it’s a fair concern. The partial payment flag is something the sender enables. The receiver doesn’t control it. So a project could be doing everything right on their end and still get hit if their system isn’t set up to catch the discrepancy between what was claimed and what was delivered.
That’s the uncomfortable part. It’s not even a sophisticated attack. Someone sends a partial payment, the receiving platform credits the full “Amount,” and the attacker walks away with more credit than they funded. Rinse, repeat. Small amounts, multiple accounts, and it adds up fast before anyone notices.
Rigorous software development practices matter here more than people tend to admit. Parsing transaction metadata correctly isn’t glamorous work. It doesn’t make a product launch announcement. But getting it wrong can mean real financial losses, and in crypto, those losses are usually irreversible.
The XRP Ledger documentation is detailed on this. It’s there. The guidance exists. Following it consistently — not just at launch but through every integration update — is what separates platforms that stay secure from ones that become cautionary tales.
What Needs to Happen
New platforms integrating with the XRP Ledger need to build their payment processing around “delivered_amount” from day one. Not as an afterthought, not as a patch after something goes wrong. From day one. Every credit to a user account should be based on what was actually delivered, full stop.
Vet’s warning isn’t exactly breaking news in XRPL developer circles, but it keeps coming up because new teams keep making the same mistake. The XRP Ledger is a popular infrastructure choice for financial applications — fast, relatively cheap, well-documented. But popular infrastructure still bites you if you don’t read the manual.
The partial payment feature, used correctly, is genuinely useful. Returning funds without extra cost is a real practical benefit. But that same flexibility is a liability when the receiving side doesn’t account for it properly.
The “delivered_amount” field is the answer. It’s been there the whole time.
Hub: XRP price, news, and analysis
Frequently Asked Questions
What is the XRP Ledger partial payment feature?
It’s a feature that lets a transaction be marked as successful even if it delivers less than the stated amount, which can be useful for returning payments but risky if receivers don’t verify the actual delivered amount.
Which metadata field should developers use to verify XRP payments?
Developers should use the “delivered_amount” field, not the “Amount” field, to confirm how much XRP was actually received in a transaction.
