Issuance and the settlement legs

Keep the cash and token records in step

Issuance turns a booked deposit into its token representation. Redemption removes that token representation before the corresponding cash is paid back. Minting and burning are the platform's names for those two token operations.

There are two records to coordinate: the bank's cash ledger and the token ledger. The bank owns the cash postings; Quant Flow carries out the requested token movement. Agree the posting sequence and exception procedure with your treasury and accounting owners.

For issuance, set aside the cash backing before requesting tokens. For redemption, confirm the token removal before releasing the cash. If the outcome is uncertain, keep it as an exception and investigate before repeating or reversing work. The detailed sequence and evidence fields follow below.

Issuance and redemption on the platform

Two token operations change the amount of a token in issue.

Both are submitted to POST /api/transactions and are accepted, signed and settled asynchronously. When policy is enabled for MINT and BURN, it can hold them for approval or refuse them; otherwise they start in BATCHED without a policy decision. The tokens exist, or are removed, only once the operation is CONFIRMED. See Operations and their lifecycle.

A BURN for more than the account holds is accepted and then fails during settlement.

The two legs

A tokenised deposit issuance has two sides:

The platform carries out the token leg only. It does not post to your core banking system. Your integration runs the cash leg and sequences the two:

In both directions the token is backed at every point: tokens are issued only after the funds are set aside, and the funds are released only after the tokens are removed.

If evidence establishes that the token leg had no effect, your bank reverses or holds its cash posting under its own procedure. If the outcome is uncertain, hold the exception and reconcile with the operator first. A confirmed token leg cannot be rolled back; it is corrected with the opposite operation. Issue and redeem gives the steps.

• Coordinate both legs in your bank adapter and reconcile them explicitly; the public API does not supply atomic coordination with the bank's cash ledger.
• Agree the general-ledger posting rules with your bank's accounting team before enabling issuance or redemption.

Treat your core banking system as the book of record and the platform's CONFIRMED state as the evidence that the token leg completed.

Evidence the platform records

For each issuance or redemption, the operation record carries:

• transactionId, assigned at submission;
• state, including the terminal CONFIRMED, FAILED or CANCELLED;
• txHash and blockNumber once settled, identifying the ledger transaction;
• failureCode and reasonCode if it failed;
• createdAt and updatedAt.

Operations that failed or could not be found on the ledger appear on the outstanding-breaks queue until resolved. See Reconcile against your core banking.

Reserve attestation

GET /api/reserves/attestation reports, per ISO 4217 currency: the reserve held, the tokens outstanding, the reserve as a percentage of tokens outstanding, whether the latest attestation is verified, and the attestation date.

The figures are currently static. The API Reference states that they are static pending a core banking integration. Do not use them as evidence of backing. GET /api/reserves/attestation/snapshot is also static mock data. See Limitations.

The current reserve endpoints return static figures, not verified live cash-ledger evidence. Use bank-held reserve records for reconciliation.

Worked example

Issue 10.50 GBP in tokens to an active account.

POST /api/transactions HTTP/1.1
Host: api.qfp.quantnetwork.net
Authorization: Bearer <access token>
API-Version: 1.0.0
Content-Type: application/json
Idempotency-Key: 5f0c1c8e-8a0b-4d0e-9a51-2f3b7f1d9c11

{
  "txType": "MINT",
  "assetId": "GBP",
  "accountRef": "ACC-0001",
  "amount": "10.50"
}

HTTP/1.1 202 Accepted
Content-Type: application/json

{
  "transactionId": "3f7c1a90-5d2e-4b08-9a41-6c2b8e5d7f13",
  "txType": "MINT",
  "assetId": "GBP",
  "accountRef": "ACC-0001",
  "customerRef": "CUST-0001",
  "counterpartyRef": null,
  "amount": "10.50",
  "params": {},
  "state": "POLICY_PENDING",
  "createdAt": "2026-08-06T09:29:10.285Z",
  "updatedAt": "2026-08-06T09:29:10.285Z"
}

The tokens are not yet issued. Read the operation with GET /api/transactions/3f7c1a90-5d2e-4b08-9a41-6c2b8e5d7f13 until state is terminal. A failed mint reads back like this:

{
  "transactionId": "3f7c1a90-5d2e-4b08-9a41-6c2b8e5d7f13",
  "txType": "MINT",
  "assetId": "GBP",
  "accountRef": "ACC-0001",
  "customerRef": "CUST-0001",
  "counterpartyRef": null,
  "amount": "10.50",
  "params": {},
  "state": "FAILED",
  "failureCode": "CHAIN_FAILED",
  "reasonCode": "EXECUTION_REVERTED",
  "txHash": "0x4a1b8c7d2e5f309a6b1c4d7e8f0a2b3c5d6e7f8091a2b3c4d5e6f7089a1b2c3d",
  "blockNumber": 18446801,
  "createdAt": "2026-08-06T09:29:10.285Z",
  "updatedAt": "2026-08-06T09:33:12.550Z"
}

View in API Reference

• Submit a token operation · POST
• Get one token operation · GET

Errors and edge cases

Follow a Recipe

Step through the code in JavaScript or Python, inspect illustrative responses, and open the connected endpoint schemas.

• Mint tokens and confirm settlement

API Reference

Open an endpoint for request fields, response examples and the interactive API console.

Related pages

• Instruments and tokenised deposits
• Operations and their lifecycle
• Issue and redeem
• 3. Issue tokens
• Reconcile against your core banking
• Limitations