The Condition field is hexadecimal.
Conditional XRP Escrow Guide
Conditional XRP escrow turns one secret fulfillment into control over locked value.
Conditional XRP escrow locks funds behind a PREIMAGE-SHA-256 crypto-condition. The escrow can finish only when a submitted fulfillment satisfies that condition while the ledger object remains eligible for completion.
Condition
The escrow stores a cryptographic requirement, not the secret itself.
XRPL escrow supports PREIMAGE-SHA-256 crypto-conditions. The condition is derived from a fulfillment, commonly a secret preimage, and becomes part of the immutable escrow definition.
Only the supported condition type is accepted.
The fulfillment should be protected until release is intended.
A condition cannot evaluate subjective performance.
Fulfillment
EscrowFinish must reveal proof that satisfies the condition.
When finishing a conditional escrow, the transaction includes the original condition and matching fulfillment. The ledger checks the relationship before allowing delivery.
Incorrect fulfillment causes failure.
Anyone holding the fulfillment may be able to submit it.
Fulfillment size affects transaction cost.
Successful validation delivers funds to the fixed destination.
Time and expiration
Conditional rules can be combined with ledger time.
A FinishAfter field can delay when a valid fulfillment becomes usable. CancelAfter limits how long completion remains possible. After expiration, the escrow cannot finish even with the correct fulfillment.
Timed conditional escrow has both kinds of gates.
CancelAfter is required for condition-only XRP escrow.
Expired objects need EscrowCancel.
Time checks use validated ledger close time.
Real-world limits
Cryptographic proof is only as meaningful as the system producing it.
A condition can prove knowledge of a secret. It cannot inherently prove that marketing succeeded, a video met expectations or a freelancer completed acceptable work. Off-chain systems must decide when to reveal or authorize fulfillment.
Define the objective event precisely.
Secure the fulfillment holder.
Plan for expiry and cancellation.
Do not portray an oracle as trust-free judgment.
Official XRPL references
Verify the protocol behavior.
Ledger features and amendments can evolve. Check the current XRP Ledger documentation before implementing or funding a transaction.
Condition design
The ledger stores the condition—not the secret that fulfills it.
At creation, the condition commits to a specific fulfillment without revealing it. A successful EscrowFinish supplies the fulfillment, and the ledger verifies the match. XRPL documentation currently identifies PREIMAGE-SHA-256 as the supported crypto-condition type for this escrow path.
Generate the condition and fulfillment securely.
Store the fulfillment outside public transaction data.
Verify encodings before funding value.
Test the complete lifecycle before production.
Secret handling
Whoever controls the fulfillment may control the release moment.
Conditional XRP escrow is only as sound as its fulfillment custody. If the secret leaks early, the escrow may be finishable earlier than intended. If it is destroyed or withheld until expiration, the recipient may never receive the funds. Define generation, storage, authorization and disclosure responsibilities explicitly.
Do not place the fulfillment in a public memo.
Restrict access to authorized systems.
Plan backup without uncontrolled duplication.
Log disclosure without exposing the secret.
Expiration
Conditional escrow needs a credible failure path.
A conditional escrow includes an expiration boundary so unresolved funds do not remain permanently dependent on a missing fulfillment. After expiration, completion is invalid and cancellation can return the amount. Monitor the actual XRPL escrow state instead of assuming the refund occurred automatically.
Set enough time for legitimate fulfillment.
Alert before expiration.
Cancel the expired ledger object.
Verify the returned amount and destination.
Objective use
Conditional XRP escrow is strongest when the trigger can be proven objectively.
A cryptographic fulfillment can represent an external decision, but the ledger does not know whether a marketing campaign was good or freelance work felt acceptable. Use conditional settlement for objectively controlled events and use milestone review when performance requires human judgment.
Separate objective triggers from subjective quality.
Disclose any oracle or operator dependency.
Do not market a secret holder as automatic truth.
Match enforcement to what can actually be verified.
Threat model
Treat the fulfillment as a release credential with its own attack surface.
Ask who generates it, which system stores it, who can request disclosure and how the release decision is authenticated. Consider early leakage, insider access, accidental logging, backup compromise, permanent loss and an operator refusing to reveal it. Conditional XRP escrow replaces one form of discretion with control over a cryptographic secret; the architecture must expose that dependency rather than hiding it behind automation language.
Prevent early disclosure.
Prevent silent permanent loss.
Authenticate the release decision.
Audit access without logging the fulfillment.
Frequently asked questions
Conditional XRP Escrow: No Matching Fulfillment, No Release
What is a conditional XRP escrow?
It is an XRPL escrow that requires a matching cryptographic fulfillment before the funds can be delivered.
Which crypto-condition does XRPL escrow support?
XRPL documentation specifies PREIMAGE-SHA-256 as the supported crypto-condition type.
Can a correct fulfillment finish an expired escrow?
No. After CancelAfter has passed, EscrowFinish fails and the escrow is eligible for cancellation.
Can conditional escrow verify market capitalization itself?
No. An external system must observe the condition and control the fulfillment or authorized ledger action.
Explore Conditional XRP Escrow →See the commercial solution and payment workflow.Read More Payment Guides →Explore crypto escrow, milestone contracts and safer internet work.Follow the Money →Understand verification, release, refunds and fee routing.Review the Risks →Understand what payment infrastructure can and cannot protect.
Rules before risk
Structure the agreement before money or work changes hands.
Create a wallet-based contract with defined milestones, deadlines, review rules and XRP settlement instructions.