OpenChainGraph · Settlement asset lifecycle

Eight stages. Only one of them is the argument.

Follow a unit of public money from issuance to attested reconciliation. Every stage below is common to a central bank digital currency and a reserve-backed stablecoin, with one exception: what actually backs the holder's claim. This deck is illustration-first – each panel's picture carries the idea, and the animation shows value moving, never decoration.

The thesis: a CBDC and a reserve-backed stablecoin differ in exactly one stage of this lifecycle – backing – and are identical in the other seven. For a direct or two-tier CBDC the backing question is vacuous: the instrument is central bank money, so there is nothing to check. For a reserve-backed stablecoin, backing is a live question about a portfolio’s composition, maturity and custody.

1
Stage 1 · The asset and its backing model

Five ways to back a claim, and one of them is no backing at all

Before any of the stages below run, the arrangement declares which kind of settlement asset it is moving. That declaration decides whether stage 1 checks anything at all.

ModelWhose liabilityWhat backs the claimBacking invariant
Direct / one-tier CBDCCentral bankNothing – it is the moneyVacuous, no set to check
Two-tier / intermediated CBDCCentral bankStill the central bankVacuous; the real controls are distribution and wallet tiering
Synthetic / pooled-accountThe operatorCentral bank money in an omnibus account, 1:1Real, a single reconcilable number
Fiat-reserve-backed stablecoinThe issuerA reserve portfolio (cash, short government paper)Real, but not one number – maturity, credit and custody all bear on it
Tokenized depositA commercial bankThe bank’s balance sheetNot a segregated pool – the question is capital adequacy
CBDC – direct / two-tier nothing to back BACKING_NOT_APPLICABLE Fiat-reserve-backed stablecoin cash · short paper · custody

The two models look the same from outside – both move a fungible unit of value between wallets. Only one of them has a portfolio behind it that can gain, lose, or be mispriced.

2
Stage 2 · Backing invariant

Backing is a property of the whole buffer set, never any one account

Where a backing set exists, the arrangement holds it across some number of buffers – a reserve account, a partner rail, a treasury sleeve. That number is a property of the arrangement, not a fixed count of three: the invariant only holds across all of them added together.

buffer A buffer B buffer C buffer N sum(A..N) checked once, per movement

A movement can leave the buffer set’s grand total unchanged while its composition breaks – that is exactly the failure a per-account check cannot see and an aggregate check can.

art-521 · backing invariant, N buffers
3
Stage 3 · Operating tension

Thin, but never empty

A buffer set is a cost as long as it sits idle, and a stall risk the moment it runs short. The computed floor is the line between the two – above it, capital is parked and earning nothing; below it, an incoming payment has nowhere to settle.

computed floor idle cost stall risk

Neither zone is a recommendation. The panel states an invariant and a computed number; nothing here schedules a sweep or a top-up.

4
Stage 4 · Collect

Collect, settling once across whichever rails exist

Payers reach the operator over whatever rails an arrangement actually has – a real-time rail, a batch file, an offline tap. Each leg settles exactly once; the settle-once verdict is what the receipt records, not which rail carried it.

payer A payer B (offline leg) payer C operator offline leg: provisional until reconciled, never final on the spot
5
Stage 5 · Net then cross

Net first, then cross once

Where a netting period exists, the many small flows collected in stage 4 are netted over that period first, and only the residual crosses a rail boundary. Where no netting period exists – some arrangements settle each payment individually by design – this stage is skipped, not forced.

rail boundary net residual, one crossing crossing count is the cost driver, not a schedule
art-259 · art-368 · net the period, cross the residual
6
Stage 6 · Disburse

Disburse in bulk and match the authorisation

Salaries, pensions, social transfers and vendor payments go out as one bulk run. The run is internally consistent, and its total matches what was authorised, item by item and in aggregate.

authorised wallet cap – cannot land total = authorised

A tiered-wallet arrangement adds a failure mode this stage must recognise: a payment can be authorised, funded, and still unable to land because the receiving wallet is capped.

art-518 · bulk disbursement integrity
7
Stage 7 · Reconcile

Reconcile and attest

The stated population is compared against what actually happened, over a stated window. Exceptions are named, not hidden inside a passing total, and the run itself – that it happened, over which population, with which exceptions – is attested.

declared population actual, over the window exception, named
art-516 · daily reconciliation attestation
8
Stage 8 · Controls

An unbroken trail, duties kept separate

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.

no gap, transactions and admin activity both covered poster approver duties separated, checked by identity
art-517 · audit-trail completeness · art-459-sod-matrix-check · segregation of duties
Chain

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 the same chain, not a second chain – the same wiring runs a centrally-issued asset and a reserve-backed one, and only the backing branch differs.

Worked examples · illustration only, never endorsement

Two named schemes, on opposite ends of the taxonomy

Naming a real scheme here is illustration of how a model actually works, not a claim about any procurement, bidder, or issuer. Every fact below is dated; check the source before relying on it, since limits, tiers and reserve rules change.

Bahamas Sand Dollar two-tier CBDC

  • Backing: a direct liability of the Central Bank of The Bahamas – vacuous by the taxonomy above, nothing to reconcile against a reserve.
  • Wallet tiers: a three-tier structure with rising holding and transaction limits by KYC depth, from a basic no-KYC tier up to unlimited business wallets.
  • Offline capability: designed to keep working across inter-island communication gaps, with a pre-set value ceiling on payments made while offline.
  • Redemption: a direct central bank liability circulating alongside cash, not redeemed through a reserve-portfolio unwind.

As of 2026-08-02, per the Central Bank of The Bahamas and sanddollar.bs.

USDC fiat-reserve-backed stablecoin

  • Backing: a reserve portfolio held in cash at regulated US banks and short-dated US Treasuries inside a registered government money market fund – real backing, and a portfolio question, not a single number.
  • Composition: weighted toward short-dated Treasuries with the remainder in cash, plus overnight Treasury repo capacity.
  • Offline capability: none by design – every transfer is an on-chain, ledger-visible event.
  • Redemption: same-day or next-day, through the issuer's approved institutional channels, not a direct central-bank queue.

As of 2026-08-02, per circle.com/transparency.

Set side by side, the pair shows the whole span the taxonomy covers: one model where the backing invariant does not exist because the instrument is already central bank money, and one where it is a live, portfolio-level question that changes with market conditions.

Honest posture

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. The backing panel is the sharpest case: it evidences that a declared set of balances satisfies a declared invariant, not that the money is actually sitting in the accounts named.

A holding-limit or tiered-wallet arrangement, an offline capability, and a redemption path each change stages beyond backing – a capped wallet can turn a valid disbursement into one that cannot land, and an offline leg is provisional until reconciled, never final the instant it happens.

All content on this page is static and processed locally in your browser. No data is transmitted. Do not enter real personal data into any OpenChainGraph tool. Use synthetic or anonymised inputs only.