Definition and scope
Timed and Conditional XRP Escrow addresses a distinct part of payments and transfers. Lock XRP until a time passes or a cryptographic condition is successfully fulfilled.
XRPL payments range from direct XRP transfers to routed cross-currency delivery, escrows, checks, and payment channels. This collection focuses on what users and applications must verify before signing and what the validated ledger proves afterward. A payment workflow is complete only after a validated ledger proves the result. Service crediting and recovery remain off-ledger responsibilities.
How it works
EscrowCreate locks XRP until a finish time, cancel time, or supported crypto-condition permits EscrowFinish; EscrowCancel returns eligible funds after cancellation time. The Escrow ledger object holds the protocol state.
- EscrowCreate: verify this field, object, or component against the cited protocol documentation.
- EscrowFinish: verify this field, object, or component against the cited protocol documentation.
- EscrowCancel: verify this field, object, or component against the cited protocol documentation.
- Condition: verify this field, object, or component against the cited protocol documentation.
- Fulfillment: verify this field, object, or component against the cited protocol documentation.
Practical example and checks
For a timed release, choose finish and cancel windows, verify destination and condition bytes if used, submit EscrowCreate, and test the finish workflow on a non-production network.
For production use, preserve the exact signed or queried data, record the network and validated ledger reference, and compare the result with the current primary documentation before changing off-ledger state.
Open the related live demo or evidence lab →Limits, risks, and common confusion
Escrow applies to XRP under the documented feature set, and a malformed condition or lost fulfillment can make funds unavailable until cancellation. Time fields use Ripple Epoch conventions.
A payment workflow is complete only after a validated ledger proves the result. Service crediting and recovery remain off-ledger responsibilities.
Current network status
Enabled on XRPL Mainnet. The underlying protocol capability is available on XRPL Mainnet. Individual services can still impose additional rules, limits, or trust assumptions.
Status reviewed 2026-08-23. Amendment-dependent behavior must be rechecked against the network's live feature state before operational use.