Partial Payments

A native XRPL payment feature that has also historically been a source of a well-documented exchange integration exploit.

What a partial payment is

Normally, an XRP Ledger payment either delivers the full specified amount or fails entirely. A partial payment is a specific payment mode (enabled by setting the tfPartialPayment flag) that instead allows a payment to deliver less than the requested amount and still succeed — useful in legitimate cases such as cross-currency payments where available liquidity might not support the full requested amount, letting the payment deliver whatever it can rather than failing outright.

Why this feature exists

Without partial payments, a cross-currency payment routed through a thin market could fail entirely if liquidity shifted even slightly between when the payment was submitted and when it settled. Partial payments let applications choose to accept "deliver as much as currently possible" instead, which is genuinely useful for certain payment-routing use cases.

The historical exploit pattern

This flexibility became a well-documented attack vector against exchanges and services that didn't carefully account for it. The exploit pattern worked roughly like this:

1. An attacker deposits XRP to an exchange's address, using a transaction flagged as a partial payment, but requesting a much larger amount than they actually send.
2. A vulnerable exchange's deposit-processing system checks the requested/intended amount field on the transaction — rather than the delivered_amount field, which reflects what was actually delivered — and credits the customer's account based on the larger, incorrect figure.
3. The attacker ends up credited for far more than they actually deposited.

Why this matters even if you're not building exchange software

Understanding this history is useful context for two reasons:

• It's a concrete illustration of a broader lesson in blockchain application security: always verify the actual, delivered result of a transaction, not just the parameters the sender claims, a principle that generalizes well beyond the XRPL specifically.
• It explains why legitimate deposit-processing systems specifically check the delivered_amount field (reported directly by validated ledger data, not attacker-controlled) rather than the payment's requested amount — a detail that's now standard practice across mature XRPL-integrated exchanges and services.

Current state

This is a known, well-understood integration pitfall rather than a live protocol vulnerability — the XRP Ledger itself behaves exactly as designed; the risk lies entirely in how a receiving application chooses to interpret transaction data. Modern, correctly implemented deposit-processing systems check delivered_amount and are not exposed to this pattern. It remains a frequently cited case study, though, in discussions of blockchain integration security more broadly — see Smart Contract and Sidechain Risks for other categories of application-level (rather than protocol-level) risk.