In brief
- Movement is the transfer of value; finality is the point after which it can no longer be reversed in the ordinary course.
- Before finality a payment is a promise; after it, a fact.
- Ambiguity about finality pushes risk onto those least able to carry it.
Settlement is the component of S4 responsible for movement and finality. Most people understand the first half. The second half is where trust is decided.
Movement is the transfer of value from one party to another. Finality is the point at which that transfer can no longer be reversed or disputed in the ordinary course. Before finality, a payment is a promise. After finality, it is a fact.
The distinction matters most to the people with the least margin. A large institution can wait for funds or absorb a reversal. An independent creator paying rent often cannot. A settlement system that is ambiguous about when value is final transfers risk to those least able to carry it.
Good settlement design therefore makes finality explicit. Participants should know what state a transfer is in, how long each state normally lasts and what can still change. Interfaces built on S4 should show those states honestly rather than presenting a pending transfer as complete.
| State | What it means | What the interface should say |
|---|---|---|
| Initiated | Requested, not yet processed | “Requested. Not yet sent.” |
| Pending | Moving, can still change | “On its way. This can still change.” |
| Settled | Final | “Complete. This is final.” |
Settlement reliability is also one of the potential underlying indicators of the Trust & Resilience Index. How well settlement works is not only an operational matter; it is part of how the economy measures whether it can be trusted. Finality rules and status definitions are documented in the Developers collection.