Instruments and tokenised deposits

What your bank is issuing

A tokenised deposit represents a deposit held by your bank. Quant Flow records its token form on the configured network; your core banking system continues to record the cash deposit. The bank sets the product's legal terms, accounting treatment and backing arrangement.

Each supported currency needs a token contract before customers can use accounts in that currency. A smart contract is the software on the ledger that records token balances and applies the authorised token movements and locks. Quant Flow coordinates those movements through its API and configured custody service.

Product and treasury teams agree the currency and deposit model. The deployment operator and authorised administrators prepare the network, signing authority and contract. Confirm the contract is ready before opening accounts. The contract and API detail below is for the team implementing that setup.

What an instrument is

On Quant Flow Platform an instrument is one currency's tokenised deposit. It is represented by a token contract registered against an asset.

The asset is identified by assetId. Token operations require assetId to be a recognised ISO 4217 currency code, such as GBP, EUR or USD. assetId is case-insensitive.
Each asset in your organisation has one registered contract. Deployment is refused while that contract is PENDING, ACTIVE or INACTIVE. A failed deployment can be retried with a new instruction and a new idempotency key.
An asset must have an ACTIVE contract before an account can be opened for it or a token operation raised against it.

The token is the on-chain representation of a deposit your bank holds. The deposit stays on your balance sheet, and your core banking system remains the book of record for it. Your bank mints tokens only against deposits it has booked, so the tokens in issue correspond one for one to those deposits. The token is not a stablecoin issued by Quant Network.

Each token contract implements QRC-20, Quant's fungible-token standard. QRC-20 is compatible with ERC-20 and adds locking, so part of a balance can be held on-chain without being destroyed. See Supported networks.

The token API describes technical value representation and movement. Your bank's legal and accounting teams must establish the deposit terms and ledger treatment for the product and jurisdiction; the API contract does not establish them.

What the smart contract contributes

The currency contract holds the settled token balances and applies on-chain rules to movements. Your integration calls Quant Flow's HTTP API; the platform prepares the corresponding contract call, obtains a signature through custody, broadcasts it and reports the result. You do not send Solidity, an ABI or a private key in a mint request.

The source contract reference describes supply controls, account freezes, token-wide pause, allowlisting, locks and role-gated transfers. These controls sit below API permissions and business-policy approval. An approved instruction can still fail at signing or on-chain if its authority or contract conditions are wrong.

Contract concept	Meaning for your integration
Mint and burn	Increase and decrease token supply. The bank remains responsible for the corresponding booked deposit and cash leg.
Agent transfer	The platform's transfer pipeline uses contract authority to move the named account's tokens; the organisation's signing address is not necessarily the debited holder.
Locks	Hold part of an account's balance; only available funds can be spent. A beneficiary is fixed at lock creation.
Freeze and pause	Can prevent ordinary movements. A contract-level burn has deliberate exceptions, but cannot consume locked funds.
On-chain roles	Authorise the signing address. They are separate from a user's API role and approval-group membership.
Upgradeable implementation	The contract reference describes logic upgrades at a stable address. This is an operator-governed capability, not an external API workflow.

The external API provides deployment, contract listing and registration-status changes, plus the documented token operations and account controls. It does not expose arbitrary contract calls, role grants, token-wide pause, allowlist management or an FXSwap submission endpoint. The repository's FXSwap contract reference establishes contract behaviour, not availability of a customer REST integration. Arrange additional capabilities through onboarding rather than constructing an undocumented request.

Continue with Issue and redeem, Transfers, locks and releases, and Security and key management.

The contract registration

POST /api/contracts deploys and registers the token contract in one asynchronous operation.

Field	Required	What it holds
`assetId`	Yes	A recognised ISO 4217 currency code, such as `GBP`.
`tokenName`	Yes	The token's display name.
`tokenSymbol`	Yes	The token's symbol.
`adminAddress`	Yes	The 20-byte hexadecimal address that will administer the token. Supply an address whose signing key your organisation controls.

The request requires an Idempotency-Key. The first response is 202 Accepted with a DEPLOY operation's transactionId, state, assetId, contractAddress, contractStatus, createdAt and updatedAt. Read the operation with GET /api/transactions/{transactionId} and the registration with GET /api/contracts.

Token precision is fixed at 18 decimals. Do not supply decimals, contractAddress, ownerKeyReference or custody fields in the deployment request. These fields belonged to the former registration endpoint. Currency amounts still follow ISO 4217 minor units, so sterling requests allow two decimal places.

Who deploys the contract. The platform deploys it through the API using the factory and signing configuration prepared for your environment. Confirm the target network, factory configuration and controlled adminAddress during onboarding. There is no client API for registering a hand-deployed contract.

Who holds on-chain authority. Authority over the contract, including the right to mint, is held by addresses whose signing keys sit with the custody provider. The platform never holds these keys. Confirm the deployed contract's role assignments and custody-controlled addresses before enabling minting. Platform user roles and on-chain contract roles are separate controls.

Deploy an asset before opening accounts

%%{init: {"theme": "neutral"}}%%
flowchart TB
    Config["Confirm network, custody and adminAddress"] --> Deploy["POST contracts / new idempotency key"]
    Deploy --> Pending["202 / contract PENDING"]
    Pending --> Track["Read DEPLOY operation and contract"]
    Track --> Confirmed["CONFIRMED / contract ACTIVE"]
    Track --> Failed["Other terminal outcome / FAILED"]
    Confirmed --> Accounts["Register accounts for this asset"]

Contract authority and API permissions are separate controls. Keep the deployment operation ID and confirm ACTIVE before provisioning accounts.

Deploy contract · List contracts · Read deployment operation

Contract status

Status	Effect
`PENDING`	Deployment accepted; the deterministic contract address is registered, but the token is not yet available for account creation or token operations.
`FAILED`	Deployment ended without confirmation. A new deployment can be submitted.
`ACTIVE`	Accounts can be registered and token operations raised for the asset.
`INACTIVE`	No new account or token operation can be raised against the asset.

Contracts are deactivated, never deleted, so an assetId is never released for reuse. The effect of deactivation on operations already in flight is not stated in the API Reference. Do not deactivate a contract as a substitute for cancelling pending instructions. Reconcile in-flight operations and agree a maintenance procedure with the operator first.

Precision: two different limits

Limit	Source	Applies to
Currency minor unit	ISO 4217 (two places for `GBP`, none for `JPY`, three for `BHD`)	Every `amount` you submit. A finer amount is rejected, never rounded.
Token `decimals`	Fixed at 18 for platform-deployed tokens	Conversion of every amount to the token's base units.

Balances are reported exactly as the contract holds them, so a balance can carry more decimal places than the currency allows. See Amounts, currencies and precision.

Maintain the asset registration

The bank chooses the currency and product settings and controls the agreed administrator address; the operator prepares factory/network/custody configuration. Your adapter submits deployment, stores the operation ID and verifies both the deployment outcome and registration status. Treat deployment as a prerequisite for account onboarding, not a payment operation.

Before a release or asset-status change, inventory pending operations and confirm the effect with the operator. Changing registration status does not migrate balances, grant contract roles or settle pending work. Keep the asset-to-contract mapping and deployment evidence in the operating record, and use Maintenance and recovery for coordinated changes.

Worked example

Illustrative example built from the schema.

POST /api/contracts HTTP/1.1
Host: api.qfp.quantnetwork.net
Authorization: Bearer <access token>
API-Version: 1.0.0
Content-Type: application/json
Idempotency-Key: deploy-gbp-1

{
  "assetId": "GBP",
  "tokenName": "QFP Pound Sterling",
  "tokenSymbol": "qGBP",
  "adminAddress": "0xe0575c1841C47aFe3F741CD292015A6484e7BFA2"
}

Illustrative example built from the schema.

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

{
  "transactionId": "036e32bb-a48b-467c-8652-d1fd4916fe90",
  "txType": "DEPLOY",
  "state": "BATCHED",
  "assetId": "GBP",
  "contractAddress": "0xd92e414Bb18f35E03A2eF47CE059e5f2ed75A455",
  "contractStatus": "PENDING",
  "createdAt": "2026-10-02T10:29:14.150Z",
  "updatedAt": "2026-10-02T10:29:14.150Z"
}

This is acceptance, not proof of deployment. The registration becomes ACTIVE only after the DEPLOY operation reaches CONFIRMED; every other terminal ending sets it to FAILED. Replaying the same key returns 200 with the current operation and registration; a changed payload under that key is ignored. Use a new key for a new deployment intent.

View in API Reference

Deploy the token contract for an asset · POST

Errors and edge cases

Situation	Response	What to do
A required field is missing or invalid	`400`	Correct the request.
Status change for an `assetId` with no contract	`404`	Register the contract first.
Account registration against an asset with no `ACTIVE` contract	`404`	Register or reactivate the contract.
Token operation against an asset with no `ACTIVE` contract	`400`	Register or reactivate the contract. The same condition is a `404` on account registration.

Deployment requires an Idempotency-Key. A missing key or deployment configuration, an invalid address, or an existing PENDING, ACTIVE or INACTIVE contract produces 400; correct the cause before retrying.

The API does not overwrite an existing contract with a new address. Agree any migration with Quant Network before changing a deployed asset. Plan asset migration with the operator, including existing balances, outstanding locks, custody permissions and the mapping of bank records. The API does not provide a balance-migration endpoint.

Follow a Recipe

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

Burn tokens for redemption

API Reference

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

Operation	Method
Deploy the token contract for an asset	`POST`
List contracts	`GET`
Activate or deactivate a contract	`PATCH`

Implementation resources

Contracts code recipes.

Use Implement a backend client for request handling, durable idempotency and outcome tracking. The developer integration coverage map links every public operation to its API Reference and contract-derived code recipe. Replace example identifiers with values from your assigned environment.