Amendment XLS: DriftVault — Slippage Rebates for XRP Settlement

[jamestwilkinson]

---

title: DriftVault description: A slippage rebate mechanism for XRP settlement author: Jimbo category: Amendment status: Draft requires: Escrow, XLS-30 (AMM), XLS-100 (Smart Escrow) created: 2026-08-22

Amendment XLS: "DriftVault" — Slippage Rebates for XRP Settlement on the XRP Ledger

Abstract

DriftVault introduces a native ledger primitive that compensates counterparties for adverse XRP price movement (drift) occurring between the time a payment obligation is quoted/locked and the time it settles. It does this utilising a reserve pool (DriftVault) that pays a partial, slippage-linked rebate to a claimant when XRP has depreciated against a reference currency over the holding window of a locked payment.

The DriftVault needs to be funded, so a small fee is proposed on transactions benefitting from the feature:

• a Payment with XRP as the delivered asset
• an EscrowFinish delivering XRP
• an AMM swap where the output is XRP
• a DEX trade where the output is XRP
• an OfferCreate that results in XRP being delivered
• an NFT buy where the buyer pays in XRP
• an IOU redemption where the issuer pays out XRP

The mechanism is designed to lower the effective volatility cost of settling in XRP across any payment with a gap between price commitment and settlement — including but not limited to time-boxed, delegated, or agent-initiated payments — without pegging XRP itself, minting a synthetic stable-asset, or requiring off-ledger intermediaries.

Motivation

Any XRP-denominated payment that has a gap between when the price is agreed and when the payment actually settles carries volatility risk that a stablecoin-denominated payment does not. During that gap, XRP's price can move — so the amount committed to no longer matches the amount actually owed by settlement time. A stablecoin payment doesn't have this problem, because its value doesn't move.

This is a general feature of XRP settlement, it applies to routine commerce, business invoicing, and any payment that isn't instantaneously agreed and settled in the same moment — and it may be especially pronounced for AI agents making payments under a budget or spending limit set in advance (e.g. "book this trip, but keep it under $2,000, and you have a few hours to decide"), where the commitment-to-settlement window is explicit and often longer.

That makes XRP a less attractive choice across this whole range of payments, and speeding up settlement doesn't fix it — even a fast settlement still leaves a window where the price can drift before the payment closes out.

Today, participants who want price-stable settlement default to stablecoins (e.g. RLUSD), subordinating XRP primarily to a bridge/liquidity role rather than as a direct settlement medium for commerce generally. This runs against the principle that a blockchain's native asset should be the default choice for mediating core transactions on-chain, rather than routing users toward secondary assets like stablecoins.

The motivation for this amendment is to reinforce native settlement as the preferred mechanism ahead of synthetic settlement. XRP settlement carries properties a stablecoin does not:

• deep, protocol-native liquidity, not dependent on an issuer's market-making
• deterministic transaction rules
• protocol-level fee mechanics
• no freeze capability
• no issuer default risk
• universal acceptance across all XRPL nodes, with no trust-line requirement
• a counterparty-free asset

This proposal aims to restore XRP's original design intent as the preeminent settlement asset on the chain — without forcing payers to use XRP, and while making native settlement a more competitive choice against the risks and frictions of synthetic settlement.

DriftVault aims to narrow the gap by utilising smart escrow functionality to make XRP settlement risk partially self-insuring at the protocol level, funded by the ecosystem's own transaction volume rather than by a third-party underwriter.

This is deliberately not a proposal to stabilize XRP's price, peg it, or create a synthetic dollar token. It is a compensation mechanism scoped to a bounded holding window, funded by a transparent, auditable on-ledger reserve sufficient to redress the balance and protect this aspect of XRP's utility.

Specification

Overview of flow

1. Payer decides to send a transaction.
2. DriftVault checks the price oracle.
3. DriftVault calculates the required XRP, plus a buffer, plus the DV fee.
4. Payer locks XRP into a DVLock — a smart escrow object that covers the future payment, recording the reference price (ReferencePrice) at lock time (t0).
5. The future payment event occurs (e.g. a time condition or a mandate-defined trigger is met).
6. DriftVault re-checks the price oracle at settlement time (t1).
7. DriftVault converts the locked XRP to the target currency value, with settlement still executed in XRP.
8. The recipient receives the XRP settlement, including any slippage-linked rebate owed from the DriftVault pool.
9. Any excess XRP is returned to the payer.
10. DriftVault retains the DV fee for pool sustainability.

Settlement (steps 5–10) is triggered automatically once the payment condition is met, rather than requiring the destination account to actively submit a claim. This "push" model — where any account (payer, recipient, or a relayer/keeper) can submit the settlement transaction once the condition is satisfied — mirrors how EscrowFinish can already be called by any account, not only the destination, once a time or crypto-condition is met. This suits unattended, agent-initiated payments, where no human is necessarily present to trigger a manual claim.

New ledger entry types

DriftVault Represents a compensation reserve pool. Fields:

Field	Type	Description
Owner	AccountID	Account (protocol/treasury) controlling pool parameters
Balance	Amount	Current XRP or token balance available for payout
CompensationRate	UInt16 (basis points)	Current payout rate applied to realized losses, e.g. 7000 = 70%
TrailingPayout30d	Amount	Rolling 30-day payout total, used to compute solvency ratio
ReserveRatioFloor	UInt16	Minimum acceptable (Balance ÷ TrailingPayout30d) before CompensationRate begins decaying
MaxClaimPerTx	Amount	Per-transaction payout cap
MaxClaimPerAccount	Amount	Rolling-window payout cap per claimant account

New transaction types

DriftVaultFund Deposits the DV fee into a DriftVault as part of transaction processing. Rather than being a standalone user-submitted transaction, this is a protocol-level side effect: the DV fee is assessed on qualifying transactions (per the fee model in the Abstract) and routed into the associated DriftVault.Balance at the same time the transaction is processed.

DVLockCreate Creates a DVLock, analogous to EscrowCreate. Requires Amount, Destination, VaultID, Expiration, and reads ReferencePrice from the specified Oracle at execution time.

DVSettle Analogous to EscrowFinish, but callable by any account (payer, recipient, or a relayer/keeper) once the payment condition is met — not destination-only. On execution:

• Reads current price from OracleID using a time-weighted average (TWAP) over a short window (e.g. last 3–5 ledger closes) rather than a single spot read, to reduce timing-manipulation risk.
• Computes loss = max(0, (ReferencePrice - CurrentPrice) × Amount).
• Computes payout = min(loss × CompensationRate, MaxClaimPerTx, remaining MaxClaimPerAccount headroom).
• Transfers Amount (the underlying locked XRP) to Destination.
• Transfers payout from DriftVault.Balance to Destination, if Balance is sufficient; otherwise pays out the available remainder and the settlement partially fails-soft (no full transaction failure, since the underlying payment must still complete).
• Returns any excess locked XRP to the payer.

DVLockCancel Analogous to EscrowCancel. Returns locked XRP to the payer if Expiration has passed and no settlement was submitted.

DriftVaultVote (optional, governance extension) Allows accounts holding a stake in the vault (if implemented as a share-based pool similar to Vault/LoanBroker LP mechanics) to vote on CompensationRate and ReserveRatioFloor parameters, paralleling AMMVote.

CompensationRate decay

CompensationRate is not static. It is recalculated periodically (e.g. once per N ledgers) as a function of the pool's solvency ratio:

solvency_ratio = DriftVault.Balance / DriftVault.TrailingPayout30d

If solvency_ratio falls below ReserveRatioFloor, CompensationRate decays smoothly toward a floor (e.g. 10%) rather than dropping abruptly to zero, using a bonding-curve-style function. This avoids a hard cliff in payout expectations during sustained XRP downtrends.

Rationale

• Loss-conditional, not flat, rebate. Compensation is only paid on realized adverse drift, not on every settlement. This is materially more capital-efficient than a flat per-transaction rebate and reduces exposure to wash-trading/farming relative to unconditional payouts.
• Partial (<100%) compensation rate. Leaving some residual risk with the claimant preserves incentive alignment and avoids the vault underwriting unlimited one-sided risk, which would be undercapitalized in any sustained downtrend.
• TWAP over spot oracle reads. A single spot price at settlement is manipulable by whichever account chooses submission timing under the push model; a short TWAP window meaningfully raises the cost of gaming the payout.
• Smart-escrow-derived design. Building on Escrow semantics, extended via XLS-100 Smart Escrow functionality, minimizes protocol surface area and reuses ledger mechanics (reserves, expiration, conditional execution) the network already has security experience with, while enabling the variable, oracle-dependent payout calculation that plain Escrow cannot perform on its own.
• Why not just use a stablecoin (e.g. RLUSD)? DriftVault does not claim to be more capital-efficient than direct stablecoin settlement for pure price-stability purposes. It is a deliberate, transparent, protocol-level mechanism to reinforce XRP as the network's native settlement asset across the general run of on-chain commerce — not only time-boxed or agent-mediated payments — funded by the ecosystem's own transaction volume, not a claim that this design is more capital-efficient than native price stability.

Backwards Compatibility

DriftVault introduces new ledger entry types and transaction types; it does not modify existing Escrow, AMM, or Oracle behaviour. Existing accounts, escrows, and transaction flows are unaffected. Adoption is opt-in: a payer/destination pair must explicitly choose to route a payment through a DVLock rather than a standard Payment or Escrow. The new DV fee, however, is proposed to apply to only qualifying transactions (per the Abstract's fee-scope discussion).

Security Considerations

• Oracle manipulation. TWAP mitigates but does not eliminate oracle-timing risk, particularly for low-liquidity Oracle price feeds. Feeds used for DVLock should meet a minimum liquidity/update-frequency bar (to be defined). Under the push settlement model, this risk extends to any account eligible to submit DVSettle, not only the destination, since any submitter can choose a favorable TWAP window to trigger within.
• Pool insolvency in sustained downtrends. The CompensationRate decay function bounds this but does not eliminate it; a treasury backstop or fixed-supply cap on total outstanding MaxClaimPerAccount exposure across the ecosystem may be needed as an additional safeguard.
• Sybil/wash exposure. Per-account and per-transaction caps reduce, but a full mitigation likely requires binding claims to Credential-verified accounts (per XLS-70) or PermissionedDomain (XLS-80) participation, especially at higher CompensationRate values.
• Fee scope and network-wide impact.The DV fee applies only to qualifying XRP‑settled transactions, as defined in the Abstract (e.g., Payments delivering XRP, EscrowFinish delivering XRP, AMM swaps where the output is XRP). This ensures that only transactions benefiting from DriftVault contribute to its sustainability. Because the fee is scoped and opt‑in at the settlement level, it does not constitute a network‑wide base‑fee change, and does not impose costs on accounts or applications that do not use DVLock or XRP‑settled flows. The fee‑routing logic and DriftVault.Balance must remain fully auditable on‑ledger to maintain trust in the mechanism’s solvency.

Open Questions

• Should the DV fee apply to all XRP-denominated transactions in the suggested list, or otherwise?
• Should DriftVault pools be per-application/per-platform, or a single ecosystem-wide shared pool? A shared pool has deeper reserves but weaker incentive-alignment between the fee source and the payout recipient.
• Should DriftVaultVote (LP-style governance) be in scope for the initial amendment, or deferred to a follow-up XLS once the core lock/settle mechanism has been live and observed?
• Should MaxClaimPerAccount be enforced natively at the protocol level, or left to application-layer enforcement on top of the primitive?