Test tokenized deposit issuance and stablecoin minting locally
Clone Formance Ledger from GitHub, run it locally, and post the $5,000,000 tokenized deposit issuance from @customers:acme:deposits. Then post the stablecoin mint against a funded @platform:reserves:pending account.
Banks and fintech teams that issue both tokenized deposits and stablecoins must decide whether a single ledger can record both. It can, but only with separate code paths. The two issuance postings look similar, but the liability, finality gate, and reconciliation proof differ. Both instruments can share one core ledger.
A tokenized deposit is the bank's own liability. A stablecoin is the issuer's liability, backed by reserves held by a custodian. A tokenized deposit becomes final at a legally agreed trigger, while a stablecoin becomes available on the ledger at a chain-specific confirmation depth; legal settlement finality of the underlying funds is a separate question. Reconciliation differs too: ledger-to-core for deposits, reserves-to-circulation and omnibus-to-sub-ledger for stablecoins.
In October 2025, an internal transfer error at Paxos, the PYUSD issuer, minted $300 trillion of the token with no reserves behind it, and the issuer reversed it after about 20 minutes. A mint without confirmed reserve funding leaves a mismatch between reserves and tokens in circulation. A platform update without a matching core booking leaves a mismatch between token balances and core deposit sub-balances. Reconciliation exposes both mismatches. Reusing the payment stablecoin issuance code path for a tokenized deposit produces both.
Treating the two instruments as one posting problem leaves tokens circulating without proven backing and deposit balances drifting from the core books. When a regulator asks which record is the source of truth, the team cannot answer from a single reconciled view.
A tokenized deposit is the issuing bank's own account-based liability recorded on a programmable platform, so the system of record stays on the bank's books and interbank settlement runs through central bank accounts.
Two ledger consequences follow:
In the account hierarchy, every @customers:*:tokens account is a deposit liability at a different customer address, and each transfer is one double-entry posting inside the bank's own chart of accounts.
Formance Ledger is an open-source, programmable core ledger that unifies fiat and digital assets with regulatory-grade traceability. Its multi-asset model keeps both instruments in one ledger without netting them into one balance line.
A tokenized deposit issuance posts as one double-entry transfer between two of the bank's own accounts, and redemption reverses it.
Consider a corporate customer, Acme, tokenizing $5,000,000. The posting is written in Numscript, Formance's purpose-built language for describing financial transactions.
Acme's conventional deposit account, @customers:acme:deposits, already holds the amount, and @customers:acme:tokens holds its tokenized deposit balance. The posting moves USD/2 500000000, integer cents, from the conventional account to the tokenized account, using the same asset:
// TOKENIZED_DEPOSIT_ISSUANCE
// Event: Acme tokenizes an existing $5,000,000 deposit
send [USD/2 500000000] (
source = @customers:acme:deposits
destination = @customers:acme:tokens
)
set_tx_meta("event_type", "tokenized_deposit_issuance")
set_tx_meta("issuance_id", "acme")
Redemption is the inverse send: from the token account back to the deposit account, for whatever amount the customer burns.
@customers:acme:deposits plus @customers:acme:tokens equals the bank's liability to Acme before and after either posting. Your test suite should assert this liability invariant on every issuance and redemption.
The core system books the transaction after the platform update, so the ledger posting and the platform state change are the two updates to reconcile. A failed callback or replayed message can leave the two layers out of step.
A tokenized deposit transfer is final at a legally agreed trigger on the settlement platform. The core booking comes later and records a settlement that has already happened, so a missing or late booking is a reconciliation break.
In a two-layer design, the trigger may be a platform event or a contractually agreed moment that both the bank and customer treat as irrevocable.
Gate the pending-to-available transition on the legally agreed finality event and nothing else. Credit @customers:acme:tokens:pending when the platform accepts the instruction, move the balance to @customers:acme:tokens:available when the finality event arrives, and treat the core booking as a downstream consequence.
A late core booking does not block availability; it is a reconciliation break that pages on-call.
Tokenized deposits reconcile ledger-to-core. At each cut-off, the sum of every customer's tokenized deposit balance, including pending and available sub-accounts under @customers:*:tokens, must equal the tokenized portion of core deposits. A break means the platform and the core booking diverged.
Compare the ledger total for the token accounts at the cut-off timestamp against the core system's tokenized sub-balance at the same timestamp. A mismatch means one system updated without the other, and the timestamp bounds show where to look.
The core must expose its sub-balance at a stable cut-off, because a core that reports end-of-day totals cannot answer an intraday parity question.
If end-of-day is all the core provides, run the check at end-of-day and record pending items at the boundary explicitly to ensure ledger integrity.
A fiat-backed stablecoin is a claim on its issuer, whether a non-bank or a bank subsidiary, backed by reserves, that passes from holder to holder. Ownership is recorded on-chain or, for custodial structures, in an internal ledger.
A payment moves the issuer's liability from one holder to another without touching the issuer's balance sheet or any central bank's.
In the account hierarchy:
Keeping holdings and reserves in separate account trees lets the ledger show circulation and backing as two independent figures you can compare at any cut-off.
A stablecoin mint posts as one atomic ledger transaction with two sends, a reserve leg and a token leg, so both ledger entries succeed or fail together. The issuance workflow must verify reserve funding before submitting the transaction. A mint posting without the reserve leg cannot prove backing for the tokens it creates.
The $5,000,000 mint to Acme is one transaction with two transfers, expressed as Numscript send instructions. The issuer owns the reserves, and Acme holds the tokens. The reserve leg is denominated in USD/2 because the custodian holds dollars, and the token leg is denominated in USDC/6 because the chain records the token.
Both represent the same $5,000,000 at 1:1. The reserve transfer moves USD/2 500000000 from the funded @platform:reserves:pending account to @platform:reserves:banks:bankA, the sub-account for the custodian bank holding the cash.
The token transfer moves USDC/6 5000000000000 from the issuance boundary @world to Acme's @customers:acme:wallet:
// STABLECOIN_MINT
// Event: Record Acme's $5,000,000 mint and allocate confirmed reserves
send [USD/2 500000000] (
source = @platform:reserves:pending
destination = @platform:reserves:banks:bankA
)
send [USDC/6 5000000000000] (
source = @world
destination = @customers:acme:wallet
)
set_tx_meta("event_type", "stablecoin_mint")
set_tx_meta("mint_id", "acme")
In the mint posting, @platform:reserves:pending cannot go below zero and must be credited through a named bank boundary only when a confirmed bank receipt arrives. @world is the issuance boundary and carries no meaningful balance. Reconcile circulation against recorded token holdings and chain data.
Formance Ledger records issuance and reserve movements, and its atomicity covers only ledger entries. It doesn't hold funds, move money, or mint tokens on-chain; a connected custodian, bank, or chain does. The token credit to @customers:acme:wallet records tokens in the ledger. The ledger does not verify external reserve funding or prevent an on-chain mint outside the issuance workflow.
Handle retries separately in the issuance workflow: use the mint_id as an idempotency key, a unique identifier that ensures a retried submission does not post the same mint twice.
The 300 trillion minting error shows why an issuance workflow needs a funded-reserve control. A workflow that checks confirmed reserves rejects an unfunded request, and a ledger that records chain state after the fact exposes the parity break between reserves and circulation.
A stablecoin transfer becomes available on the ledger at a chain-specific confirmation depth. The legal settlement finality of the underlying funds is a separate question.
Technical finality depends on the chain, and the base layer provides no native reversal mechanism. Corrections use subsequent transactions or ledger entries, and issuers add freeze controls at the token and application layer.
The stablecoin availability gate is the chain's confirmation depth, set per chain. Tokenized deposits use the legally agreed finality event instead. Credit @customers:acme:wallet:pending at first inclusion and move the balance to @customers:acme:wallet:available once the required depth is reached. On-chain confirmation covers the difference between confirmed and settled.
Stablecoin reconciliation runs two parity checks at a timestamp: reserves match tokens in circulation, and the on-chain omnibus balance matches the sum of sub-ledger holdings. Both must hold before you can call the instrument backed.
The first control is reserves ≥ tokens in circulation at any timestamp, attributed by custodian. Each custodian has its own sub-account, such as @platform:reserves:banks:bankA, so the ledger can attribute reserves by custodian.
The second control is omnibus-to-sub-ledger: the on-chain balance of the issuer's omnibus wallet must equal the sum of customer holdings under @customers:*:wallet, including pending and available sub-accounts, that the ledger attributes to the wallet.
A delta is either an unrecorded chain movement or a ledger posting with no on-chain counterpart, and the break's timestamp bounds the search.
Formance Reconciliation, an Enterprise feature, uses policy-based matching rules to pair ledger records with external statements, detects drift, and alerts on settlement errors at configurable intervals. Ledger's bi-temporality and point-in-time views give Reconciliation precise cut-offs.
A tokenized deposit is a bank liability backed by the bank's balance sheet, and a stablecoin is an issuer liability backed by reserves. The table compares the two across seven dimensions.
| Dimension | Tokenized deposit | Stablecoin |
| Liability owner | Issuing bank | Stablecoin issuer (non-bank or bank subsidiary) |
| Authoritative record | Bank's core books | Chain plus issuer reserve |
| Posting shape at issuance | One liability, two bank accounts | Reserve leg + token leg, atomic ledger transaction |
| Credit originates from | Customer's conventional deposit account | Issuance boundary @world |
| Finality event | Platform or agreed trigger (legal) | Chain confirmation depth (ledger availability gate); legal settlement finality is separate |
| Reconciliation proof | Ledger-to-core parity | Reserves-to-circulation + omnibus-to-sub-ledger |
| Reserve requirement | No issuer reserve (bank balance sheet) | Requires reserves backing every token in circulation |
To separate restricted from unrestricted balances within one currency, use Formance's Assets Coloring. It tags units of the same asset with distinct provenance or ownership constraints without creating a new asset type.
Run the checklist below before the first dual-instrument posting reaches production. Each item names an owner, a test to write, or a break signal to alert on.
These seven checks keep the two instruments separable in production.
Write the rejected-mint test first, because an unfunded mint puts tokens in circulation with no reserves behind them, as the PYUSD incident showed. The finality-gate test comes second, and it needs a core system that exposes an intraday sub-balance.