Batch settlement is planned. It is not implemented in the current facilitator release. This page describes the design so integrators know what to expect and what not to rely on.
The problem
Stellar settlement is cheap and fast, but not free of latency. For workloads where a single caller makes many sub-cent requests per second (streaming data, per-token metering, high-frequency scraping), per-call settlement adds unnecessary round-trip time and consumes RPC bandwidth.
The plan
A batch scheme where the client authorizes a rolling ceiling and the facilitator settles the aggregate periodically:
- Client signs a
batch authorization with amount (ceiling), windowSeconds, and payTo.
- Each request against the batch is verified locally by the facilitator (no on-chain call).
- At the end of the window, or when the accumulated total reaches a threshold, the facilitator settles once for the accumulated amount.
- Any unused ceiling expires without moving funds.
Trade-offs the design has to answer
- Trust window. A seller carries counterparty risk for the duration of the batch. Shorter windows reduce risk; longer windows reduce settlement overhead.
- Refund semantics. With aggregation, an over-count is possible. The design will require a scheme-level cap and rejection reason to keep this from being an off-chain accounting problem.
- Discovery. Batch-eligible endpoints will need a distinct capability flag in
describe so buyers can find them explicitly.
What to do today
Use upto with a long maxTimeoutSeconds if you need something in the neighborhood of batching. It is not the same thing, but it covers the metered-work case until batch ships.
