What is conditional escrow on XRPL?

Conditional escrows on the XRP Ledger use cryptographic conditions (hash-locked contracts) to release XRP only when a specific secret is revealed, enabling trust-minimized atomic swaps, payment routing, and sophisticated smart contract patterns. Conditional escrows combine time locks with cryptographic proofs, providing programmable payment release beyond simple time delays.

Conditional escrows use the Condition and Fulfillment fields in escrow transactions. The Condition is a cryptographic hash (SHA-256) of a secret value. The Fulfillment is the secret itself. When creating an escrow, you specify the Condition. To finish the escrow, someone must provide the matching Fulfillment. The protocol verifies that the Fulfillment hashes to the Condition before releasing funds.

Creating a conditional escrow requires generating a condition-fulfillment pair. First, create a random secret (the fulfillment). Then, hash it using SHA-256 to create the condition. The EscrowCreate transaction includes the condition but not the fulfillment. Anyone who later learns the fulfillment can finish the escrow, regardless of who they are.

The cryptographic security ensures only someone with the fulfillment can release funds. Without the secret that hashes to the specified condition, the escrow cannot be finished. This creates trustless agreements: you can prove you'll pay someone if they reveal specific information, without requiring them to trust you to pay after revealing it.

Atomic swaps between different cryptocurrencies use conditional escrows. Alice wants Bob's Bitcoin for her XRP. They agree on an exchange. Alice creates a conditional escrow on XRPL with a secret condition. Bob creates a conditional escrow on Bitcoin with the same condition. Alice reveals the secret to claim Bob's Bitcoin, which simultaneously allows Bob to use that same secret to claim Alice's XRP escrow. Both complete or both fail - atomicity.

Payment routing applications use conditional escrows for multi-hop payments. Each intermediary creates a conditional escrow to the next hop with the same condition. When the final recipient reveals the secret to claim their payment, all previous escrows can be claimed in reverse order, ensuring all intermediaries are paid for routing.

Combining conditions with time locks creates sophisticated contracts. The FinishAfter and CancelAfter fields still apply: the condition must be satisfied AND the FinishAfter time must pass before the escrow can be finished. If CancelAfter passes without the condition being fulfilled, the escrow expires and returns funds to the sender.

Hashed Time-Locked Contracts (HTLCs) combine hash locks (conditions) with time locks (FinishAfter/CancelAfter). These are fundamental to atomic swaps and payment channels. The hash lock ensures only the intended recipient can claim funds (by revealing the secret), while the time lock provides expiration and refund mechanisms if the secret is never revealed.

Finishing a conditional escrow requires submitting an EscrowFinish transaction including the Fulfillment field. The protocol hashes the provided fulfillment and verifies it matches the escrow's condition. If verified and timing conditions are met, the XRP releases to the destination. If the fulfillment is incorrect, the transaction fails.

Condition and fulfillment formats follow the Interledger Protocol's crypto-conditions specification (RFC draft). The condition is a 32-byte SHA-256 hash hex-encoded. The fulfillment is the preimage that hashes to the condition, also hex-encoded. Interoperability with other systems using the same specification enables cross-platform escrows.

Security considerations: the fulfillment must be kept secret until you're ready to claim the escrow. Once revealed (by finishing an escrow), everyone can see it in the validated ledger. If using the same condition for multiple escrows, finishing one reveals the fulfillment for all others. For independent escrows, use different conditions.

Generating secure fulfillments requires cryptographically secure random data. Use proper random number generators to create fulfillments, not predictable values. If an attacker can guess your fulfillment before you reveal it, they could finish escrows intended for you.

Querying conditional escrows shows their conditions but not fulfillments (until revealed). The account_objects method returns escrow objects including Condition fields. Wallet software can display pending conditional escrows and allow users to finish them by providing fulfillments.

Practical challenges with conditional escrows include: managing condition-fulfillment pairs securely, coordinating conditions across different blockchain systems for atomic swaps, handling cases where fulfillments are never revealed (requiring CancelAfter for refunds), and educating users about more complex mechanics than simple time locks.

Error handling: finishing an escrow with an incorrect fulfillment fails with an error but consumes a transaction fee. Applications should verify locally that fulfillments match conditions before submitting transactions. Attempting to finish escrows without providing fulfillments when required also fails.

Conditional escrows enable trustless reputation systems. For example, a dispute resolution service could be the only party knowing the fulfillment for an escrow. If they determine the service was properly delivered, they reveal the fulfillment allowing payment. If not, they let the escrow expire and cancel.

Contract-based automation uses conditional escrows for event-triggered payments. An oracle service could generate the fulfillment only when external conditions are met (like weather data for crop insurance). Revealing the fulfillment triggers payment, creating smart contracts that respond to real-world events.

Limitations of XRPL conditional escrows include: supporting only SHA-256 hash conditions (not complex logic or multiple conditions), requiring someone to submit finish transactions manually (not automatically executing), and needing CancelAfter for refund paths (no automatic refunds).

Developers implementing conditional escrows should provide UI for condition-fulfillment management, automate escrow monitoring and finishing when fulfillments become available, implement secure random fulfillment generation, and clearly communicate the cryptographic nature of these contracts to users.