Bo's Lab

XRP's 1 XRP Minimum Reserve: Why Your Address Must Hold a Balance

A Curious Discovery

While testing XRP deposits and withdrawals, I noticed something interesting: XRP addresses must hold at least 1 XRP, or transactions will fail.

This isn’t a bug — it’s a core design feature of the XRP Ledger (XRPL).

If you try to send all XRP from an address, the transaction fails. That 1 XRP is “locked” — you can’t spend it.

Why This Design?

In one sentence: To prevent spam accounts.

XRPL is a shared global ledger where every address’s data lives in validators’ memory. Without a cost to create accounts, attackers could spam unlimited accounts and bloat the ledger until nodes can’t handle it.

The reserve mechanism sets an economic barrier: If you want to “occupy space” on-chain, you must stake some funds.

This approach is clever — instead of limiting transactions via Gas Fees, it limits state bloat via reserves.

Two Types of Reserves

XRPL reserves come in two parts:

Base Reserve = 1 XRP

  • Minimum XRP every address must hold
  • The cost of an account’s “existence”
  • Required to activate the account and permit transactions

Owner Reserve = 0.2 XRP per object

  • Each on-chain object (Trust Line, Offer, Escrow, etc.) requires an additional 0.2 XRP lockup
  • Want to hold USDT? You need a Trust Line → lock 0.2 XRP more
  • XRP is released when objects are deleted

Example: An address holding 3 tokens (3 Trust Lines) needs:

1 + 0.2 × 3 = 1.6 XRP minimum

Historical Changes

Reserve requirements aren’t static — validators can vote to adjust them:

  • Originally: Base reserve was 200 XRP (when XRP was worth pennies)
  • Later: Reduced to 20 XRP, then 10 XRP
  • December 2024: Latest vote reduced it to 1 XRP

The reason is simple — XRP’s price increased. Requiring 10 XRP (~$25 at the time) was too high a barrier for account creation.

Impact on Testing

As a QA engineer, this mechanism means:

Deposit Testing

  • First deposit to a new address must be ≥ 1 XRP, otherwise the transaction fails
  • If a user deposits 0.5 XRP, the funds “disappear” (actually returned)

Withdrawal Testing

  • Users can never withdraw their full balance; maximum is balance - 1 - (objects × 0.2) XRP
  • UI must correctly display “available balance” vs “locked balance”

Edge Cases

  • Account has Trust Lines but insufficient XRP for object reserves → can’t create new objects
  • Deleting Trust Lines releases reserves → available balance increases
  • Reserves can only be used to pay transaction fees, not transferred to others

Comparison with Other Chains

This design isn’t mainstream among public chains, but similar mechanisms exist:

  • Stellar (XLM) — Also has a minimum reserve requirement (1 XLM)
  • EOS — Requires RAM resources for account data storage
  • Polkadot (DOT) — Has an Existential Deposit (minimum 1 DOT)

Most EVM chains (ETH, BSC, etc.) don’t have this concept — accounts can have zero balance.

Takeaway

XRP’s reserve mechanism is essentially state rent — occupying storage on-chain comes at a cost. It’s effective at preventing state bloat, but creates UX challenges (like “why can’t I withdraw everything?”).

For QA engineers testing chains with minimum reserve requirements, focus on:

  1. Minimum amount for first deposit
  2. Available balance calculation logic
  3. Edge cases for full withdrawal
  4. UI display of locked amounts

Reference: XRPL Official Documentation - Reserves