Issue tokens

Who this is for

Engineers with an ACTIVE account from 2. Create a customer and an account. By the end of this step ACC-0001 holds 1,000.00 GBP in tokens.

How a token operation settles

Every token operation (mint, burn, transfer, lock, release, cancel) is submitted to POST /api/transactions, with txType naming the operation. A MINT issues tokens to the account named in accountRef.

Before submitting, complete the signing and custody prerequisites. An active account and contract alone do not prove that your organisation can sign the mint.

Accepted is not settled. A 202 means the request was well-formed and the accounts it names are usable. Nothing has moved yet. With policy enabled for MINT, the operation passes through your organisation's policy, which can refuse it or hold it for an approver, and then through settlement. Otherwise it starts in BATCHED without a policy decision. The response example below illustrates the policy-enabled path. Balances change only when the operation reaches CONFIRMED.

RECEIVED is no longer used. Operations submitted before it was retired may still report it.

The outcome is not reported on the submit call. Read the operation back with GET /api/transactions/{transactionId}, or subscribe to the transaction.* webhook events in 6. Receive your first webhook.

For the full lifecycle, see Operations and their lifecycle. For how issuance relates to funds held in your core banking system, see Issuance and the settlement legs.

Worked example

Submit the mint

Illustrative example built from the schema.

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

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

A mint takes no counterpartyRef. amount is a decimal string in currency units, and cannot be finer than the currency's minor unit (two decimal places for GBP).

Illustrative example built from the schema.

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": "1000.00",
  "params": {},
  "state": "POLICY_PENDING",
  "createdAt": "2026-08-06T09:29:10.285Z",
  "updatedAt": "2026-08-06T09:29:10.285Z"
}

Store transactionId. state is the state the operation was accepted in. It has probably moved on by the time you read it.

Follow it to a terminal state

Read the operation until state is CONFIRMED, FAILED or CANCELLED, or wait for the transaction.confirmed or transaction.failed webhook. If the operation stays in a non-terminal state beyond its expected window, which is agreed with Quant Network during onboarding, do not submit a replacement: see Handle failures. Use bounded polling with backoff and a local deadline. An elapsed deadline means the outcome is unknown, not failed; retain the transaction ID and reconcile.

GET /api/transactions/3f7c1a90-5d2e-4b08-9a41-6c2b8e5d7f13 HTTP/1.1
Host: api.qfp.quantnetwork.net
Authorization: Bearer eyJraWQiOiJ...
API-Version: 1.0.0

While it is in flight:

Illustrative example built from the schema.

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

txHash, blockNumber and reasonCode are absent (not null) while the operation is in flight.

Once it has settled:

Illustrative example built from the schema.

{
  "transactionId": "3f7c1a90-5d2e-4b08-9a41-6c2b8e5d7f13",
  "txType": "MINT",
  "assetId": "GBP",
  "accountRef": "ACC-0001",
  "customerRef": "CUST-0001",
  "counterpartyRef": null,
  "amount": "1000.00",
  "params": {},
  "state": "CONFIRMED",
  "txHash": "0x9f2c1d5e4b8a37c06d1e5f9a2b4c7d8e0f1a2b3c4d5e6f708192a3b4c5d6e7f8",
  "blockNumber": 18446744,
  "createdAt": "2026-08-06T09:29:10.285Z",
  "updatedAt": "2026-08-06T09:31:47.902Z"
}

txHash and blockNumber identify the settlement record on the ledger. Keep them with your own posting as audit evidence.

View in API Reference

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

Errors and edge cases

A precision error:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "timestamp": "2026-08-06T09:29:10.285Z",
  "status": 400,
  "error": "Bad Request",
  "message": "Amount '10.505' has 3 decimal places, while GBP allows only 2."
}

A failed operation:

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

The platform does not check your core banking system before issuing. Set aside the matching funds in your control account before you submit a MINT. See Issue and redeem.

Who may mint: Confirm the caller's issuance entitlement, active custody configuration and on-chain mint authority with the operator before running the example.

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

• 2. Create a customer and an account
• 4. Read balances
• Operations and their lifecycle
• Issuance and the settlement legs
• Issue and redeem
• Handle failures