Issue and redeem

Who this is for

Treasury, finance and operations teams coordinating a deposit's cash and token records, and engineers connecting those workflows. Issuance creates the token representation of a booked deposit; redemption removes it before the bank completes the corresponding cash payment.

The bank owns the cash posting and reconciliation. Quant Flow carries out the requested token operation and reports its result. The sequence below explains those responsibilities before the worked API examples.

Understand the supply change

Minting creates new token supply and credits the named token account. Burning removes tokens from the named account and reduces supply. Neither operation moves cash in your core banking system. A transfer is different: it changes the holders' balances without creating or destroying supply.

For example, minting 100.00 GBP against a booked deposit increases the account's tokens by 100.00 GBP once confirmed. A later confirmed burn of 30.00 GBP reduces that holding by 30.00 GBP. Your bank then pays the corresponding cash redemption and reconciles both records. Treat these figures as an example of accounting coordination, not an instruction to submit a second operation before the first has settled.

Your adapter should retain the bank posting reference, amount and asset, account reference, idempotency key, transaction ID and final outcome. That record answers which cash posting backs a mint, whether a redemption is safe to pay, and whether recovery requires investigation or a new instruction.

An illustrative token position

Starting from zero tokens, a confirmed issue of 100.00 GBP creates a holding of 100.00 GBP. A later confirmed redemption of 30.00 GBP leaves 70.00 GBP. These amounts illustrate the supply change; the bank coordinates the corresponding cash postings separately.

%%{init: {"theme": "neutral"}}%%
flowchart TB
    Start["Token holding: 0.00 GBP"] --> Mint["Issue 100.00 GBP / confirm settlement"]
    Mint --> Holding["Token holding: 100.00 GBP"]
    Holding --> Burn["Redeem 30.00 GBP / confirm removal"]
    Burn --> Remaining["Token holding: 70.00 GBP"]

The figures change after confirmation. An accepted request or a pending approval does not establish the new holding. A transfer changes who holds the tokens without increasing or reducing the amount in issue.

View in API Reference

• Submit an issue or redemption
• Check its outcome
• Read the settled balance

Before you start

• The asset has an ACTIVE token contract.
• The customer is registered and ACTIVE.
• The customer's account for the asset is ACTIVE, with a wallet address.

See Create a customer and an account.

Who posts what

Your core banking system remains the book of record. The platform does not post to it. Your integration makes the cash postings, and calls the platform for the token operations.

Call the platform only after the instruction has passed your own checks, such as KYC, AML and sanctions screening. By default the platform does not repeat those checks.

Issue: cash first, then the token

Redeem: token first, then the cash

Pay out only on CONFIRMED. A 202 confirms acceptance only. A BURN for more than the account holds is accepted and then fails during settlement, because balances are not checked at submission.

Issuance and redemption are evaluated by your organisation's policy when it is enabled for MINT and BURN. The shipped settlement configuration has policy disabled; confirm the go-live configuration before relying on approval controls. The example below illustrates the policy-enabled path.

Confirm the caller's entitlement and on-chain contract authority for issuance and redemption with the operator. A valid access token alone does not prove either.

Cash and token ordering

%%{init: {"theme": "neutral"}}%%
flowchart TB
    subgraph Issue["Issue"]
      direction TB
      I1["Bank checks and cash posting"] --> I2["Submit MINT / retain transactionId"]
      I2 --> I3["Track to CONFIRMED"]
      I3 --> I4["Reconcile token issuance with cash posting"]
    end
    subgraph Redeem["Redeem"]
      direction TB
      R1["Submit BURN / retain transactionId"] --> R2["Track to CONFIRMED"]
      R2 --> R3["Bank pays cash to the customer"]
      R3 --> R4["Reconcile both records"]
    end
    Issue ~~~ Redeem

These are two separate flows. A 202 response is acceptance only. If no definitive outcome arrives, investigate before replacing an instruction or paying out.

Submit MINT or BURN · Read outcome

When something fails

Put issuance and redemption into bank operations

For each mint or burn, persist the bank posting reference, account/asset, decimal amount, original idempotency key and returned transaction ID before processing the final outcome. Your adapter performs the bank-side cash workflow; Quant Flow signs and settles the token instruction through the configured pipeline.

Assign an exception owner for rejected, delayed or uncertain instructions. A burn acceptance is not permission to pay redemption cash: follow your agreed cash-leg procedure against the confirmed outcome. After a lost response, recover the same intent using its original identifiers rather than constructing a compensating operation blindly. Include these cases in Production readiness and the maintenance recovery inventory.

Worked example

Issue 10.50 GBP to account ACC-0001, after moving the funds to the control account in core banking:

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: 3f7c1a90-5d2e-4b08-9a41-6c2b8e5d7f13

{
  "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"
}

Track it with GET /api/transactions/3f7c1a90-5d2e-4b08-9a41-6c2b8e5d7f13 or the transaction.confirmed webhook.

Redeem 40.00 GBP from the same account. Pay the fiat out when this operation reaches CONFIRMED:

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: 8e2d4b17-6c0a-4f93-b5e1-2a7c9d3f0b64

{
  "txType": "BURN",
  "assetId": "GBP",
  "accountRef": "ACC-0001",
  "amount": "40.00"
}

The response has the same shape as the MINT response, with txType set to BURN.

View in API Reference

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

Errors and edge cases

• A missing ACTIVE contract is a 400 on submission.
• The account must exist, hold the asset and be ACTIVE. Otherwise the submission is refused.
• Retrying a submission after a timeout: use the same Idempotency-Key. You get the existing operation back as it now stands, with 200, and no second operation.
• Reserve figures: GET /api/reserves/attestation returns static figures today, pending a core banking integration. Do not use them to reconcile. See Limitations. Use bank-held reserve records for reconciliation while this endpoint remains static.

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
• Burn tokens for redemption

API Reference

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

Related pages

• Issuance and the settlement legs
• Operations and their lifecycle
• Handle failures
• Balances
• Reconcile against your core banking