Test mint and reserve issuance locally
Clone Formance Ledger from GitHub, run it locally, and post the mint-and-reserve transaction above against your own account tree. Then resubmit the same reference and see what the ledger returns.
A regulated entity that issues a stablecoin or holds tokenized deposits selects the tokenization platform. The platform qualifies only if its ledger passes five tests: issuance, reconciliation, owner attribution, provenance, and exportability.
At the daily cutoff, the on-chain supply reads 25,000,000 tokens. The custodian statement shows $24,650,000 in the reserve account. Your core ledger shows a third figure because two redemptions posted after the custodian closed its books and one mint was retried after a gateway timeout.
The mismatch is $350,000, and no engineer or finance lead can say which of the three numbers is the system of record. Listing the owners behind the custodian's balance requires a spreadsheet someone built last quarter, and no vendor demo covers per-owner attribution at a past cutoff. The failure comes later, when someone spends against one number while reporting another.
If the mismatch stays unexplained, your regulated entity cannot support a reserve attestation, and auditors will question the platform choice long after its demo environment is gone.
For a regulated issuer, a tokenization platform is the ledger that records each mint, burn, and reserve movement, and attributes every token to an owner. The token on-chain records a claim on the reserve.
The ledger records who owns that claim, what backs it, and when each change happened. That record is what you are buying, and the five tests are written to check it.
An asset-issuance stack creates real-world-asset tokens representing funds and treasuries. Those tokens fit inside this article only when your ledger, not the chain, must be the system of record for the claim.
Token standards, custody, know-your-customer and anti-money-laundering (KYC/AML) tooling, chain support, wallets, fees, and vendor viability all matter. These topics sit outside the five ledger tests.
The token layer is the contract or permissioned ledger where supply lives. In the core ledger, every mint, burn, transfer, and reserve movement is a posting with a source and a destination. The connectivity layer feeds custodian statements, chain state, and bank balances into reconciliation.
Formance Ledger is an open-source, programmable core ledger that unifies fiat and digital assets with regulatory-grade traceability.
We built the Formance Ledger as the core-ledger layer because the token layer never sees the fiat leg. A contract knows 25,000,000 tokens exist and knows nothing about the $25,000,000 wire that backs them. A component that sees half the transaction cannot serve as the system of record.
Run five tests in your sandbox to check your tokenization platform: one atomic, idempotent mint, pairwise reconciliation across chain, custodian, and ledger, per-owner attribution at any past cutoff, restrictions that survive every transfer, and a platform you can inspect and export.
The mint posting and reserve-credit posting must land in one atomic ledger transaction: both postings succeed or fail together.
Ledger atomicity does not extend to external token issuance and reserve funding. If issuance uses separate reserve and mint API calls, a timeout can leave tokens without backing or backing without tokens. Retrying can then duplicate the call that already succeeded.
Require one transaction that records reserve credit and token issuance in Numscript, Formance’s purpose-built language for money.
The platform's named bank boundary is @platform:banks:reserve:main; its segregated reserve account is @platform:reserves:segregated; its circulating-token treasury is @platform:treasury:circulating.
The transaction records $25,000,000 moving from the bank boundary to reserves and 25,000,000 newly issued USDX tokens moving from @world to the treasury.
The bank boundary may run negative to record incoming cash, with @world being used only to mint the issued token.
An overdraft limit allowing 100,000,000 tokens beyond an account's balance does not limit supply. Verify duplicate handling, supply-limit enforcement, and signer controls separately.
// TOKEN_ISSUANCE
// Event: record reserve funding and issue USDX to the platform treasury
// reference: mint-20260312-0007
send [USD/2 2500000000] (
source = @platform:banks:reserve:main allowing unbounded overdraft
destination = @platform:reserves:segregated
)
send [USDX/6 25000000000000] (
source = @world
destination = @platform:treasury:circulating
)
set_tx_meta("event_type", "token_issuance")
set_tx_meta("mint_id", "mint-20260312-0007")To test duplicate handling, submit the transaction with mint-20260312-0007 as the transaction reference, then resubmit the same reference.
The second call must return the original transaction or a rejection. To test the supply cap, attempt a mint that exceeds the configured limit. The platform must reject it and state which layer enforces the limit (ledger, policy layer, or custody).
To test signer controls, attempt issuance with a single signer. The platform must refuse it and must state which layer.
Disqualify the platform if it produces a second mint, if the mint is a separate API call from the reserve posting, if the mint has no enforced supply limit, or if issuance needs only one signer.
Reconciliation must run as three independent pairwise comparisons: ledger-to-chain, ledger-to-custodian, and chain-to-custodian.
Aggregate totals can agree while individual pairs do not. Suppose the chain has a $200,000 over-mint and your ledger records a $200,000 outgoing wire that the custodian has not yet debited.
Chain supply and custodian backing agree, but the ledger disagrees with both sources. Demand three pairwise reports, each with its own cutoff timestamp. A shared cutoff disguises timing drift as a balance error. The platform must also expose confirmation and settlement as distinct states.
For tokenized deposits, compare chain and ledger balances against the off-chain deposit account rather than the custodian's balance.
Comparing supply with backing surfaces an unbacked-token gap at the next cutoff instead of the next audit. The ledger-to-chain pair flags the over-mint the day it posts because chain supply rises without matching reserve credit.
Disqualify the platform if it compares only aggregate totals or applies one shared cutoff to all three sources.
For any past cutoff, the platform must return an owner list whose balances sum to the custodian's closing balance. A ledger that cannot identify each owner's balance at a past cutoff fails this test.
An omnibus account holds funds for many owners under one balance. Once the issuer mixes customer fiat, it must maintain a per-owner record that ties each part of the balance to its owner.
The Financial Stability Board's (FSB) thematic review states that the “size, quality, and location of reserves are sufficient at all times." Under the FSB's reserve-attestation expectations, the per-owner record becomes the deliverable: you must name the owners behind a reserve balance as of any cutoff.
Protection includes segregating reserves from the issuer's, its group's, and the custodian's assets.
Demand a historical balance query after a backdated correction. Post a correction with an effective date three days in the past, then request the owner list at a cutoff between that date and today.
The result must include the corrected balances at the requested cutoff and show when the correction was recorded. A query for a cutoff before the correction's effective date must exclude the correction. The engineer keeps both query results and their balance sums.
Disqualify the platform if either query returns an owner list that does not sum to the custodian's closing balance.
Formance’s Assets Coloring keeps restricted and unrestricted funds distinguishable within a single asset code. It tags asset units with a provenance or restriction label and leaves the asset code unchanged. A separate asset per restriction adds reconciliation pairs and splits one fungible token into several, so the restriction label must work inside one asset.
Tag $4,100,000 of USD as reserve-colored at deposit, move it through two intermediate accounts, then draw against a rule that requires the reserve color. The draw must succeed only on tagged units, and the same rule applied to an account holding only untagged USD must fail with insufficient funds, even when the untagged balance is larger.
Disqualify the platform if provenance requires minting a separate asset, or if tagged units can be spent as though they were untagged.
You must be able to read the posting engine's source code, run the engine in your own environment, and export the full hash-chained history in a documented format.
A tokenization platform you cannot inspect or leave puts your reserve records under someone else's control. When one platform controls both the token layer and the ledger, moving the token and its record anywhere else becomes a manual project that depends on that platform's cooperation.
In a hash-chained history, each transaction links to the previous transaction. Hash links let a reviewer independently check whether an export is internally consistent.
To detect history rewritten by an untrusted exporter, the reviewer also needs a trusted external anchor: a record kept outside the exported history for comparison.
Disqualify the platform if the posting engine is closed source or the history export is undocumented.
Issuance is where the financial mismatch begins. A retried mint with no matching reserve posting creates tokens that nothing backs, and every later number inherits that error. Run Test 1 first because the other four tests depend on it.