PATH SETTLEMENT

The governing idea

Finality is a verifiable state, not a promise.

"It's paid" means different things on-chain, on an instant rail and in a mobile-money ledger. Each has its own proof, its own format and its own horizon, and none of them reconcile with the others. So reconciliation gets done by hand, in spreadsheets, at month end.

A signed receipt over a mobile-money transfer is worth exactly as much as an on-chain proof — provided the format is the same and the reconciliation agrees. That equivalence is what lets a protocol span rails that have nothing else in common.

The receipt

{
  "kind": "settlement_receipt",
  "reference": "rcpt_9a41c8f2b731",
  "request": "7fk2m9pq3vx8",
  "payer_member": "member-b",
  "payee_member": "member-a",
  "amount": "5000",
  "currency": "XOF",
  "rail": "mobile_money",
  "source_tx_hash": null,
  "source_reference": "MM-8891-2231",
  "attestations": [],
  "route": null,
  "protocol_version": "0.1.0",
  "signed_at": "2026-09-09T10:04:12Z",
  "kid": "op_example_2026_01",
  "signature": "…"
}

source_tx_hash for rails that have one, source_reference for those that do not. Both may be present; at least one must be.

request links back to the payment request when there was one. Spontaneous payments have none, and that is normal rather than an omission.

Publicly readable

Like a payment request, and for the same reason. A receipt is only useful if a third party can check it — a supplier, an auditor, a customs officer, the payer's own institution. Putting it behind a credential means the only people who can verify a settlement are the two who already agree about it.

const { valid, reason } = await verifyAgainstIssuer(receipt, 'https://api.other-member.com');

The verifier fetches the issuer's key from the issuer's discovery document. Not from whoever served the receipt, and not from a central authority: an operator vouching for another operator's key rebuilds the hierarchy the protocol avoids.

Lifecycle

reversed is separate from failed on purpose. A failure never moved value; a reversal moved it and moved it back, and the difference matters to an auditor, to a dispute, and to anyone reading a ledger six months later.

Reconciliation

Three views of the same event, which must agree:

{
  "receipt": "rcpt_9a41c8f2b731",
  "observations": [
    { "source": "provider", "observed": "5000", "observed_at": "2026-09-09T10:04:12Z" },
    { "source": "statement", "observed": "4975", "observed_at": "2026-09-10T02:00:00Z", "discrepancy": "25" }
  ]
}

Discrepancies are recorded, not silently corrected. A system that quietly reconciles differences away is a system where nobody notices the fee that was never disclosed, or the rail that rounds in one direction.

The reserved field

route is declared on every receipt and never populated in v0.1.

"route": null

When liquidity routing is specified, it will hold the legs, the providers, their shares and an expected duration. It exists now so that arrives as an extension. A field added later would be a migration for everyone who had already shipped, and this is the cheapest possible insurance against that.

That is what RESERVED means throughout the specification: not forgotten — declared, documented, deliberately empty.

Presenting a receipt

A receipt can be carried as a receipt URI, so it can be shown as a QR code and verified by someone with no API access at all.

That is what makes settlement tangible rather than theoretical: a supplier scans a code and knows they were paid, without an account anywhere and without trusting the person holding the phone.

What is out of scope

No settlement token, no escrow, no collateral, no guarantee of funds. Those are regulated activities and a protocol that specified them would need a licence in every jurisdiction it touched.

PATH specifies the proof, not the rail — and the proof is the part that has to be portable.