Amendment XLS: Post-Dated Checks

[bigcjat]

XLS-XXd: Post-Dated Checks (DeliverAfter Execution Window for XRPL Checks)

Title:       Post-Dated Checks for Subscriptions & Deferred Settlement
Author:      Chris Thompson
Status:      Draft
Type:        Standards Track (Amendment)
Created:     2026-08-06
Amendment:   featurePostDatedChecks

---

Abstract

This proposal introduces an optional DeliverAfter timestamp field to the existing CheckCreate transaction on the XRP Ledger. By enforcing an on-chain start time before which a check cannot be cashed, this amendment enables Post-Dated Checks.

This provides a lightweight, user-sovereign alternative to heavy recurring subscription proposals (such as XLS-78) by reusing the battle-tested XRPL Check ledger engine (ltCHECK). Users can issue a series of post-dated checks in a single atomic batch transaction (up to the current XLS-56d protocol limit of 8 checks per batch, or 12 if the batch limit is expanded by a future amendment) while retaining full unilateral cancellation rights via CheckCancel.

---

Motivation

The Problem with Complex Subscription Amendments

Proposals like XLS-78 attempt to solve recurring payments by introducing an entire new subscription ledger engine (ltSUBSCRIPTION), along with custom claim loops, specialized period counters, and new transaction types (SubscriptionCreate, SubscriptionClaim, SubscriptionCancel).

This approach adds significant protocol complexity, increases ledger state bloat, and forces validators to maintain complex state machines for a feature that can be achieved with existing primitives.

The Post-Dated Check Solution

The XRP Ledger already possesses a robust, secure Check primitive (ltCHECK). However, CheckCreate currently only supports an Expiration timestamp (the cutoff after which a check can no longer be cashed). It lacks a DeliverAfter timestamp (the start time before which a check cannot be cashed).

By adding DeliverAfter to CheckCreate:

1. Zero New Ledger Object Types: Reuses existing ltCHECK objects.
2. User Sovereignty & Security: The user maintains total custody. If a user wishes to cancel a subscription, they simply submit a CheckCancel transaction for remaining un-cashed checks.
3. Batching Efficiency: Under current XRPL Batch rules (XLS-56d), a user can sign up to 8 post-dated checks in a single batch transaction (e.g. 8 billing cycles). If the batch size limit is later amended to 12, full annual 12-month coverage is unlocked automatically.
4. Natural Renewal Bounds: Forcing a re-authorization boundary every 8 billing periods prevents forgotten "zombie" subscriptions from draining user funds indefinitely.

---

Specification

1. Transaction Field Modification: CheckCreate

Add an optional DeliverAfter field to the CheckCreate transaction format.

Field	JSON Type	Internal Type	Required?	Description
DeliverAfter	Number	STUInt32	Optional	Time in seconds since the Ripple Epoch after which this check becomes cashable.

Field Constraints:

• If both DeliverAfter and Expiration are specified, validation MUST enforce DeliverAfter < Expiration. Otherwise, the transaction fails with temBAD_EXPIRATION.

---

2. Ledger Object Modification: Check (ltCHECK)

Update the Check ledger entry structure to store the optional DeliverAfter field.

Field	JSON Type	Internal Type	Required?	Description
DeliverAfter	Number	STUInt32	Optional	The timestamp before which this check cannot be cashed.

---

3. Execution & Validation Rules

CheckCash Validation Logic

When a payee submits a CheckCash transaction referencing a Check object:

1. If the Check contains a DeliverAfter field:
   • The engine checks the current parent ledger close time (parent_close_time).
   • If parent_close_time < Check.DeliverAfter, the transaction MUST fail with error code tecTOO_EARLY (or tecEXPIRED).
2. If parent_close_time >= Check.DeliverAfter, the transaction proceeds to normal balance and trustline settlement.

---

4. Subscription Cancellation & Reserve Recovery

When a user decides to cancel a subscription, the cancellation mechanism relies on the existing CheckCancel primitive:

1. Unilateral User Revocation: The subscriber can submit CheckCancel for any or all un-cashed post-dated checks at any time. The payee/merchant cannot block or delay this action.
2. Atomic Batch Cancellation: Using a single atomic batch transaction (XLS-56d), a user can cancel all remaining post-dated checks (e.g., Checks 4 through 8) in 1 single wallet signature.
3. Instant Reserve Refund: Submitting CheckCancel immediately deletes the ltCHECK ledger objects and refunds 100% of the associated account owner reserves back to the subscriber.

---

Standard Subscription Workflow Example

Recurring SaaS Subscription (8-Check Batch Example)

1. Subscriber Initiates: Subscriber wants an 8-period recurring subscription at 15 XRP / period.
2. Single Batch Issuance: The subscriber signs a single batch transaction containing 8 CheckCreate items (respecting the current 8-item batch limit):
   • Check 1: DeliverAfter = Day 0, Expiration = Day 30
   • Check 2: DeliverAfter = Day 30, Expiration = Day 60
   • Check 3: DeliverAfter = Day 60, Expiration = Day 90
   • ...
   • Check 8: DeliverAfter = Day 210, Expiration = Day 240
3. Payee Cashing: On Day 30, the merchant's automated worker submits CheckCash for Check 2. The ledger verifies parent_close_time >= Day 30 and settles 15 XRP.
4. Subscription Cancellation: If the subscriber cancels after Month 2, their wallet app submits a single batch transaction containing CheckCancel for Checks 3 through 8. Future payments are revoked on-chain instantly, and all remaining reserves are refunded.

---

Advantages Over XLS-78

Feature	XLS-78 Subscriptions	XLS-XXd Post-Dated Checks
New Ledger Object	Requires new ltSUBSCRIPTION object	Zero new objects (uses ltCHECK)
Protocol Footprint	Large (4 new transaction types)	Minimal (1 field added to CheckCreate)
User Control	Complex cancellation / pause states	Instant CheckCancel batch revocation
Merchant Risk	Subject to balance failure at claim	Identified immediately upon cashing attempt
Re-Authorization Boundary	Can run indefinitely	Enforces explicit 8-check user review (or 12 if batch size amended)

---

Backwards Compatibility

This amendment is fully backwards compatible:

• Existing CheckCreate transactions without DeliverAfter continue to function identically.
• Clients and wallets that do not support DeliverAfter simply ignore the field.
• Amendments required: featurePostDatedChecks.

---

Security Considerations

1. No Reserve Exhaustion: Checks consume standard ltCHECK reserve. Batching up to 8 checks requires standard ledger reserves, which are fully returned upon cashing or cancellation.
2. Replay Protection: Each check possesses a unique CheckID generated on creation, making replay attacks impossible.
3. Time Sync: Uses the immutable parent_close_time of validated ledgers to ensure deterministic execution across all validators.

@bigcjat I fixed your preamble to match the expected format.

[mvadari]

DeliverAfter is definitely better naming, NotBefore is a bit awkward grammatically/doesn't fit with standard XRPL field naming/might be tough for non-native English speakers.

[bigcjat]

I agree, I have never been accused of having good grammar