FinishAfter uses seconds since the Ripple Epoch.
Timed XRP Escrow Guide
Time-locked XRP escrow makes time an immutable gate on the payment.
Time-locked XRP escrow prevents funds from being finished before a specified XRP Ledger time. If CancelAfter is also defined, it creates a separate expiration boundary after which completion is forbidden and cancellation can return the locked funds.
FinishAfter
Maturity is the earliest time the escrow can complete.
Before FinishAfter, an EscrowFinish transaction fails. After that time, the escrow is ready to finish unless it has already crossed an applicable CancelAfter expiration.
It is immutable after creation.
Ledger close time controls the comparison.
Actual timing follows validated ledger closes.
Ready state
Mature does not mean automatically delivered.
Once FinishAfter passes, someone still submits EscrowFinish. If the transaction is valid and the escrow has not expired, successful validation delivers the funds to the destination.
No automatic payment occurs at maturity.
Anyone may submit the finish transaction.
The destination is fixed at creation.
Successful completion removes the Escrow object.
CancelAfter
Expiration ends the window for successful completion.
When CancelAfter has passed, EscrowFinish fails. The expired object remains until an EscrowCancel transaction successfully returns the funds to the sender.
Expiration and refund are separate events.
Cancellation is unavailable before expiration.
Anyone may submit the cancellation.
The return goes to the original sender.
Operational use
Timed escrow works for objective ledger-time rules.
It can lock funds until a future time, but it cannot independently determine whether off-chain work was delivered. Applications must coordinate any human review before triggering ledger actions.
Use exact UTC and Ripple Epoch conversions.
Leave room for ledger-close timing.
Monitor open escrows after expiration.
Explain who is responsible for finishing or cancelling.
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.
Two clocks
FinishAfter and CancelAfter do different jobs.
In a time-locked XRP escrow, FinishAfter defines the earliest permitted completion time. CancelAfter defines when the escrow expires and becomes cancellable. A safe design leaves enough time between them for the intended party to finish the escrow after maturity; collapsing the window can create needless operational risk.
FinishAfter is the maturity gate.
CancelAfter is the expiration gate.
The fields are set at creation.
Time values use the Ripple Epoch representation.
Maturity
Ready does not mean automatically delivered.
After FinishAfter passes, a valid EscrowFinish transaction must still resolve the time-locked XRP escrow. Applications should monitor validated ledger close time rather than a phone clock, then confirm the finish transaction succeeded before reporting payment as complete.
Ledger time determines eligibility.
A finish transaction still must be submitted.
Transaction fees and sequence rules still apply.
Validated metadata confirms delivery.
Expiration
Expired funds do not teleport back to the sender.
Once CancelAfter passes, the escrow can no longer finish. An EscrowCancel transaction must remove the expired object and return the amount. This distinction matters for dashboards: expired, cancelled and refunded are not the same state.
Expired means completion is no longer valid.
Cancelled means the return transaction succeeded.
Refunded should point to ledger evidence.
State labels must not hide unresolved funds.
Operational checks
Design the time-locked XRP escrow around real execution delays.
Allow for ledger closes, monitoring, wallet signing and human response. Decide who is responsible for finishing or cancelling, and alert before the relevant boundary. For work payments, connect the native time gate to clear contract rules rather than pretending time alone proves performance.
Assign finish and cancellation responsibility.
Alert before maturity and expiration.
Use UTC and ledger-derived times consistently.
Never use time as a substitute for acceptance criteria.
Timeline example
Draw maturity, action window and expiration as separate moments.
Suppose a time-locked XRP escrow matures at 12:00 UTC and expires at 18:00 UTC. The funds cannot finish before noon. Between noon and 18:00, a valid finish can deliver them. After 18:00, finishing is forbidden and cancellation becomes the valid return path. Nothing moves merely because either clock passes. Transactions must still be submitted, validated and checked. This timeline prevents applications from calling an escrow paid at maturity or refunded at expiration before ledger settlement occurs. Alerts should lead the responsible signer toward action without misrepresenting eligibility as completed payment.
Before 12:00: held.
12:00–18:00: eligible to finish.
After 18:00: eligible to cancel.
After transaction validation: actually settled.
Frequently asked questions
Time-Locked XRP Escrow: The Clock Can Protect the Deal—or Trap Funds in Bad Rules
What does FinishAfter mean?
It is the earliest ledger time after which an escrow may be successfully finished.
What does CancelAfter mean?
It is the expiration time after which the escrow can no longer finish and becomes eligible for cancellation.
Does XRP release automatically after FinishAfter?
No. An EscrowFinish transaction must still be submitted and validated successfully.
Can a time-locked escrow omit expiration?
Some XRP escrows can omit CancelAfter, in which case they do not expire and cannot be cancelled through expiration.
Explore XRPL Infrastructure →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.