Supported networks

Who this is for

Bank architects and risk teams who need to know what kind of ledger the tokens live on, who can join it, and when an operation counts as final. It covers the network type, consensus and finality, and the token contract standard.

The network

Tokens are issued on a private, permissioned ledger network that is compatible with the Ethereum Virtual Machine (EVM).

Who operates the nodes depends on the deployment model. In a Quant-hosted deployment Quant operates them. In a client-hosted deployment, where the nodes run is agreed with the bank. See Deployment model.

Use the network assigned in your deployment configuration. Confirm whether it is dedicated or shared and which environments it supports before provisioning contracts or accounts.

Finality

Finality on this network is immediate and deterministic. Once a transaction's block is finalised, it is not reversed or reorganised, and a single receipt is final. A finalised block is present on every validator before the platform reports it.

The platform reports an operation as CONFIRMED only after its settling transaction has been mined and finalised. At that point the operation carries txHash and blockNumber, and balances reflect it. See Operations and their lifecycle.

A transaction that reverts on the ledger ends the operation in FAILED. It does not change balances.

Token contract standard

Each asset is represented by a token contract implementing QRC-20, Quant's fungible-token standard. QRC-20 is compatible with ERC-20 and adds locking, so part of an account's balance can be held on-chain without being destroyed. The contract is the record of who holds how many tokens and how many are locked.

The contract is written in a current Solidity version with built-in overflow protection. It includes explicit checks against zero-address, self-transfer and allowance-race errors, and avoids external calls, which removes re-entrancy risk. It is covered by an automated test suite.

Each asset has one registered contract, recorded with its contractAddress and decimals. See Instruments and tokenised deposits.

Signing

The platform holds no blockchain private keys. For each operation it prepares the transaction and asks the configured custody or HSM signing provider to sign the transaction's digest. The platform then assembles the signed transaction and submits it. Changing any field after signing invalidates the signature. See Security and key management.

Worked example

A confirmed operation, read with GET /api/transactions/{transactionId}. txHash identifies the settling transaction on the ledger and blockNumber the finalised block that contains it.

GET /api/transactions/9c4d2f18-73ba-4e6c-8f05-2d17ab903e64 HTTP/1.1
Host: api.qfp.quantnetwork.net
Authorization: Bearer <access token>
API-Version: 1.0.0

HTTP/1.1 200 OK
Content-Type: application/json

{
  "transactionId": "9c4d2f18-73ba-4e6c-8f05-2d17ab903e64",
  "txType": "LOCK",
  "assetId": "GBP",
  "accountRef": "ACC-0001",
  "customerRef": "CUST-0001",
  "counterpartyRef": "ACC-0002",
  "amount": "100.00",
  "params": {
    "expiry": "2027-01-01T00:00:00Z",
    "lockRef": "INV-88421",
    "lockId": "b28f1a4c-9d3e-4f27-8a56-1e0c7b9d42a1",
    "chainLockId": "0x00000000000000000000000000000000b28f1a4c9d3e4f278a561e0c7b9d42a1",
    "destination": "0x8B1cA3D5e07F2b94aC61d8E30f5A7b249C0e6D18"
  },
  "state": "CONFIRMED",
  "txHash": "0x9f2c1d5e4b8a37c06d1e5f9a2b4c7d8e0f1a2b3c4d5e6f708192a3b4c5d6e7f8",
  "blockNumber": 18446744,
  "createdAt": "2026-08-06T09:29:10.285Z",
  "updatedAt": "2026-08-06T09:31:47.902Z"
}

View in API Reference

• Get one token operation · GET

Errors and edge cases

• txHash without blockNumber. The transaction has been submitted and is not yet mined. The operation is still in flight.
• Reverted transaction. The operation ends in FAILED with a failureCode such as CHAIN_FAILED and a specific reasonCode. It carries a txHash and blockNumber, and balances do not change.
• Reading the ledger directly. The network is private. Arrange any read-only node or direct ledger access with the network operator. The public API does not itself provision node access.
• Other networks. Do not design against an unannounced network integration; use the network and settlement capabilities confirmed for your environment.

API Reference

Open an endpoint for request fields, response schemas, examples and documented errors.

Related pages

• Deployment model
• Operations and their lifecycle
• Instruments and tokenised deposits
• Security and key management
• Interoperability