Post Your First Reserve-Backed Mint
Clone Formance Ledger on GitHub, run it locally, and post the ledger representation of a reserve-backed mint as your first transaction.
Your block explorer shows $50M of tokens outstanding, the custodian reports $49.6M in reserves, and the latest subscription wires haven't hit the bank statement. Reconciling the $400K difference across three feeds on three different schedules is the first job of real-world asset tokenization infrastructure.
Real-world asset tokenization moves fund shares, Treasuries, and bank deposits onto public chains, with an off-chain ledger behind every token contract issuers and transfer agents rely on. Tokenized U.S. Treasuries exceeded $15 billion by late April 2026, and the work behind them has grown with issuance.
Reliable tokenization needs four things: a ledger that serves as the legal record, mint, burn, and transfer postings, reconciliation across chain and custodian on their own schedules, and settlement across rails that holds pending state until both legs clear. The off-chain ledger is where all of it has to be held
The transfer agent's off-chain records are the legal system of record, and the chain is a distribution and settlement rail.
The Securities and Exchange Commission's (SEC's) Division of Trading and Markets confirmed on May 15, 2025, that the transfer agent's records "constitute the official securityholder record" even when distributed ledger technology (DLT) is used. The SEC has also framed a tokenized share as a recordkeeping format for an existing share rather than a new security.
Although regulatory authority is necessary, two properties make the off-chain ledger the system of record: it captures token states the smart contract cannot express, and it enforces the four controls that keep investor balances trustworthy.
The off-chain ledger must record three token states the smart contract cannot express directly: freezes pending sanctions review, reversals awaiting on-chain burn, and pending corrections.
The token contract expresses these states only through an administrative override, if at all. An issuer reading balances from the chain has nowhere to record "frozen pending sanctions review" or "reversed, awaiting on-chain burn." The ledger holds the state and the chain catches up.
The four required ledger controls are double-entry accounting, append-only immutability, integration-enforced write idempotency, and per-investor account isolation.
Double-entry accounting requires a matching debit for every token credit. Append-only immutability means corrections are new postings rather than edits.
Integration-enforced write idempotency uses unique external references and queryable transaction metadata so a replayed event cannot post twice. Per-investor accounts and transaction rules keep one investor's frozen position from leaking into another investor's available balance.
The ledger records three on-chain lifecycle events with balanced off-chain postings: mints for subscriptions, burns for redemptions, and secondary-market transfers between investors. Each event's fiat and token legs are written in the same atomic transaction and tagged with the on-chain transaction hash as metadata.
Actual fiat and blockchain movements happen externally, through connected banks, custodians, or exchanges. The account tree has four branches:
A USD posting against @platform:reserves:custodianA accompanies every change in outstanding supply. Both legs commit, or neither does, written in Numscript, Formance's purpose-built language for describing financial transactions.
A $2,500,000 subscription posts as shown below. Investor 4471 wires cash. The ledger credits the custodian reserve with 250,000,000 cents and mints 2,500,000 units of the fund token into the investor's account.
The on-chain mint hash is written to metadata so a retry cannot post the same mint twice.
// TOKENIZED_FUND_SUBSCRIPTION
// Event: record a $2,500,000 reserve deposit and mint 2,500,000 FUNDA units
send [USD/2 250000000] (
source = @counterparties:custodians:custodianA allowing unbounded overdraft
destination = @platform:reserves:custodianA
)
send [FUNDA/0 2500000] (
source = @world
destination = @customers:4471:positions:available
)
set_tx_meta("event_type", "tokenized_fund_subscription")
set_tx_meta("chain_tx_hash", "0x7c3e19a9f2d4b6c8e0a1f3b5d7c9e2a4f6b8d0c2e4a6f8b0d2c4e6a8f0b2d4c6")
set_tx_meta("subscription_id", "sub_2026_08_14_0093")
A redemption inverts the mint. The token leg flows from @customers:4471:positions:available to @world, the USD leg flows from @platform:reserves:custodianA back to @counterparties:custodians:custodianA, and the on-chain burn hash is written to metadata so a retry cannot burn the same units twice.
The source and destination flip while the metadata convention stays the same.
// TOKENIZED_FUND_REDEMPTION
// Event: burn 2,500,000 FUNDA units and release $2,500,000 from the reserve
send [FUNDA/0 2500000] (
source = @customers:4471:positions:available
destination = @world
)
send [USD/2 250000000] (
source = @platform:reserves:custodianA
destination = @counterparties:custodians:custodianA
)
set_tx_meta("event_type", "tokenized_fund_redemption")
set_tx_meta("chain_tx_hash", "0x8a4f21b3e7c5d9f2a6b4c8e1f0d3a5c7e9b1d4f6a8c2e5b7d0f3a6c9e2b5d8f1")
set_tx_meta("redemption_id", "red_2026_08_15_0042")A secondary-market transfer posts only the token leg, from one investor's available account to another's, with the transfer hash written to metadata.
No fiat leg is needed because outstanding supply and reserve backing are both unchanged.
// SECONDARY_MARKET_TRANSFER
// Event: transfer 500,000 FUNDA units between investors
send [FUNDA/0 500000] (
source = @customers:4471:positions:available
destination = @customers:5892:positions:available
)
set_tx_meta("event_type", "secondary_market_transfer")
set_tx_meta("chain_tx_hash", "0x1e5a9c3f7b2d4e8a6c1f5b9d3e7a2c4f8b6d1e5a9c3f7b2d4e8a6c1f5b9d3e7a")
set_tx_meta("transfer_id", "xfer_2026_08_15_0107")
Each @customers:<id> account carries metadata for KYC status, permitted jurisdictions, and sanctions flags, and the transfer script reads that metadata on both source and destination before the token leg posts. Enforcing eligibility in the ledger means no path, including issuer UI, broker, or direct API, bypasses the check.
Reconciling on-chain token supply against custodian and bank balances rests on running three reconciliation controls per cycle, and on aging any resulting breaks with tiered escalation.
Each control (ledger integrity, external backing, and coverage threshold) runs against its own effective cut-off, because chain state, custodian snapshots, and bank statements arrive on different schedules. A single "as of midnight" cut-off applied to all three feeds compares a chain state from one day to a bank position from another, and reports a break that does not exist, or hides one that does.
Each reconciliation run enforces three controls in order:
Age reconciliation breaks across three tiers: a break under 24 hours is a cadence artifact, a break past a second cut-off gets a named owner, and a break past a third cut-off escalates to whoever can halt minting. Read finalized chain state only, to avoid phantom breaks caused by reorganizations or replaced transactions.
Formance Reconciliation applies cut-off logic after external ingestion. The chain read, custodian snapshot, and bank statement each carry their own effective time inside one run, and reconciliation and drift state stay separate from the ledger.
Settling across fiat and blockchain rails without stranding one leg means designing for three scenarios: hold minted tokens in pending until the fiat leg settles, park settled fiat in pending until the mint confirms, and hold the redemption reserve until the fiat payout clears.
Each needs a pending state on the ledger and a compensating transaction if the second leg fails. Cash and token sit on separate ledgers, so settlement across rails is never atomic in a single commit because the ledger has to carry the intermediate state itself.
When a mint confirms on-chain before fiat settles, hold the tokens in @customers:<id>:positions:pending rather than the investor's available account until the fiat leg settles.
Once a mint reaches finality, compensate with a burn rather than deleting the original record.
On fiat timeout, post tokens from @customers:<id>:positions:pending back to @world. Then submit the on-chain burn keyed by the original mint hash so the integration cannot double-burn.
Never let a token reach an available balance while the reserve leg is in flight. On-chain confirmation means the chain agreed, and the funds may still be absent.
When fiat settles before the mint confirms, park the cash in @platform:reserves:mints:pending rather than @platform:reserves:custodianA. The reserve is real, but no token obligation exists yet.
Re-attempt the mint using the same unique external reference, and query transaction metadata before creating another ledger posting. Once the mint hash returns, move the cash into the custodian reserve account and the tokens into the investor's account in one atomic transaction.
If the mint never succeeds, return the fiat from @platform:reserves:mints:pending to @counterparties:custodians:custodianA and leave the break-log entry pointing at both postings.
When a redemption burn confirms on-chain before the fiat payout clears, park the reserve in @platform:reserves:redemptions:pending rather than releasing it to @counterparties:custodians:custodianA.
The tokens are already destroyed on-chain, so the ledger owes the investor cash it hasn't moved yet. Retry the payout keyed by the burn hash and, on success, move the reserve to the counterparty account in one atomic transaction.
If the payout fails permanently, re-mint using the original burn hash back into the investor's available position. The break-log entry links the burn, the failed payout, and the re-mint.
Five checks map to the infrastructure layers laid out above: ledger controls, mint and burn postings, reconciliation cut-offs, cross-rail settlement with pending state, and on-demand reserve proof. Run each one before the next mint hits the chain.
If all five hold, the ledger, ingestion, and reconciliation together replace the spreadsheet that joins the explorer export, the custodian file, and the bank statement.
Formance Ledger holds the account tree with double-entry enforced per asset, and Reconciliation automates the run after external sources and policies are configured.