Eight stages carry a settlement asset from issuance to reconciliation. The models underneath them are not interchangeable

Before any of the stages below run, the arrangement declares which kind of settlement asset it is moving. Read the last column: two of these five rows have no backing set for a checker to open. A node built on the assumption that a buffer topology always exists is simply wrong for them, which is why the backing check has to treat an empty set as a conformant answer rather than a shortfall or a bad input.

From outside, both look identical: a fungible unit moving between wallets. Only one has a portfolio behind it that can gain, lose, or be mispriced.

Where a backing set does exist, the arrangement holds it across some number of buffers: a reserve account, a partner rail, a treasury sleeve. How many is a property of the arrangement, and the invariant only holds across all of them added together.

A movement can leave the grand total untouched while the composition underneath it breaks. Per-account checks pass; the aggregate check is the one that notices.

Idle, a buffer set costs money. Short, it stalls payments. The computed floor is the line between those two, and nothing more.

Neither zone is advice. A number, an invariant, and no instruction to move anything.

Payers reach the operator over whatever rails an arrangement actually has: a real-time rail, a batch file, an offline tap. Each leg settles once, and the receipt records that verdict rather than which rail carried it.

Where a scheme supports offline transfer, value moves while the ledger is not watching. The leg is provisional until it reconciles, and scoring it as final at the moment of the tap would put a settle-once verdict on an event the ledger has not seen yet.

Where a netting period exists, the small flows collected in stage 4 net over that period first, and only the residual crosses a rail boundary. Some arrangements settle each payment individually by design. Those skip this stage rather than being forced through it.

Salaries, pensions, social transfers and vendor payments go out as one bulk run, and the run has to match its authorisation item by item and in aggregate.

Tiered wallets add a failure the totals cannot show you. A pensioner on a low-KYC wallet is owed a payment that would carry their balance past its cap. The item was authorised. The money was there. It still does not land, and unless this stage recognises a capped wallet as its own outcome, that pensioner reads as paid.

The stated population is compared against what actually happened, over a stated window. Exceptions get named rather than buried in a passing total, and the run itself is attested: that it happened, over which population, with which exceptions.

The last stage evidences the controls around every stage above: a log covering transactions and administrator activity that has no gap, and a check that duties which must stay separate actually are – the person who can post a disbursement is not the same identity who can approve it.

The whole spine, one composed chain

All eight stages above are wired as a single composed OpenChainGraph chain, government-payment-lifecycle: art-521 (backing, with art-06/art-512/art-280 supplying reserve facts only where the settlement asset is issuer-reserve-backed) → art-513 (collect) → art-259/art-368 (net then cross) → art-518 (disburse) → art-516 (reconcile) → art-517 + art-459-sod-matrix-check (controls). The settlement asset is a declared parameter on that chain rather than a second chain: the same wiring runs a centrally-issued asset and a reserve-backed one. What changes is the backing branch, plus whatever the model's limits, offline behaviour and redemption path do to the stages downstream of it.

Four named schemes, across the taxonomy

Four live schemes, named to show how the models actually work. This is illustration and nothing else: no endorsement, no involvement, no procurement. Every fact below carries the date it was read, because limits, tiers and reserve rules all move.

Across the four, the taxonomy's whole span is visible. Sand Dollar has no backing invariant to check, because the instrument already is central bank money. Fnality sits next to it: a private operator's liability, but reconciled against one pooled central-bank account rather than a portfolio. USDC's invariant is a reserve portfolio that moves with market conditions. JPM Coin sits at the other private end: a claim on one bank's own balance sheet, with capital adequacy standing in for a segregated reserve. The four also differ on wallet caps, on whether value can move while the ledger is dark, and on who stands behind a redemption. Calling all four digital money is true and tells you almost nothing.

What this evidences, and what it does not

Every stage above computes over inputs the caller declares. The receipt chain evidences that the computation ran correctly over those declared inputs. It says nothing about whether the declarations were true. Stage 2 is the sharpest case: it evidences that a declared set of balances satisfies a declared invariant. That is not proof of reserves, and nobody should read it as proof that the money is sitting in the accounts named.