About the project
About Quantumchain
QuantumChain’s vision is to make digital value easier to move, manage and understand. The design connects payments, assets and records around the people and businesses that use them.
A payment-first architecture, developed through a staged delivery plan.
THE REASON WE BUILD
Make value easier to move.
Make the journey easier to understand.
Practical payment needs are the starting point.
01Our direction
Make the whole journey easier to follow.
Financial activity often crosses several systems. A customer sees a checkout, a merchant sees an order, and an operations team sees a settlement report. When those records do not connect, even a simple payment can become difficult to explain.
QuantumChain is designed around that wider journey. Its draft architecture brings value transfers, asset rules, identity controls and structured records together. The long-term goal is infrastructure that people can use and businesses can account for.
02Design principles
The decisions behind the design.
Start with settlement
A transaction needs a clear, valid result. Settlement integrity comes before impressive performance claims.
Give assets clear rules
Money, memberships and credentials have different needs. The proposed asset model makes their purpose and lifecycle explicit.
Build in accountability
Permissions, records and evidence help explain what happened and who was allowed to act.
03Intended uses
A practical beginning, with room to grow.
- 01
People and merchants
Payment requests, clear wallet reviews, receipts and merchant records form a relatable starting point.
- 02
Payment providers
Checkout, settlement, payout and reconciliation are the proposed first commercial focus.
- 03
Institutional workflows
Controlled assets, treasury operations and cross-border systems form later areas of development.
These are intended use cases. They do not identify existing customers, partnerships or deployed services.
04Connected experiences
Different needs. A shared payment story.
The proposed ecosystem connects people and organizations without treating every participant as the same kind of institution.
For people
Understand a request, authorize a payment and keep a receipt that explains the outcome.
For businesses
Connect invoices, payment status, refunds and settlement records to the work your team already does.
For institutions
Define who can issue assets, approve actions and oversee settlement while preserving distinct institutional obligations.
05Central banks
A sovereign foundation. Connected to the wider economy.
A central bank needs more than a faster transfer. It needs clear issuance authority, settlement rules, oversight and continuity. QuantumChain’s sovereign architecture brings those responsibilities into the design.
Wholesale settlement
The proposed wholesale layer connects reserve-linked transfers, bank liquidity and final settlement records. It is designed to coexist with real-time gross settlement (RTGS) systems rather than assume an immediate replacement.
Two-tier digital currency
A central bank could retain authority over a central bank digital currency (CBDC), while approved banks and payment providers handle distribution and customer services. Issuance and everyday service delivery remain distinct roles.
Public disbursement
Public salaries, grants, subsidies and refunds are intended workflows. Defined approval rules and traceable receipts could help administrators follow a payment from authorization to its outcome.
How would sovereign control coexist with shared infrastructure?
The proposed model separates a permissioned sovereign core, a regulated distribution layer and public-facing access services. The relevant authority would define admission, money rules and oversight. A technical design does not itself establish legal settlement status or authorize issuance.
These are proposed deployment models. No central-bank adoption, CBDC issuance or regulatory endorsement is claimed.
06Private & public banks
Modernize the workflow. Preserve the meaning of the money.
Banks should be able to improve settlement and reconciliation without losing the controls their customers depend on. The architecture allows existing core books and new settlement services to work alongside each other.
Private and commercial banks
Intended workflows include tokenized deposits, escrow, merchant acquiring, payroll and treasury operations. The design keeps issuer identity, redemption terms, account linkage and approval authority attached to the asset and its lifecycle.
Public and development banks
Public-sector banks could use controlled disbursements, restricted balances and evidence-backed reporting for their own programs. Program rules and institutional accountability matter as much as the transfer itself.
Does a bank need to move every account onto a blockchain?
No. The drafts describe mirrored, hybrid and native-money models. A bank could retain core balances in its existing systems while an integration coordinates settlement records and proofs. A bank-issued deposit token would represent that issuer’s defined obligation; it is not interchangeable with QTCN, a CBDC or an insured deposit merely because it is digitally recorded.
07Financial organizations
Different institutions. Clear responsibilities.
Financial infrastructure must accommodate more than one kind of organization. QuantumChain’s intended model gives each participant a defined role instead of treating every institution as the same wallet.
Remittance and e-money providers
Connect customer instructions, payout records, reconciliation and corridor requirements. The aim is a clearer operational history across the services handling a payment.
Custodians and treasury teams
Use policy-controlled approvals, scoped signing authority, key rotation and evidence for asset movements. Custody remains a responsibility with its own controls, not a benefit supplied by a token name.
Microfinance and specialist institutions
The drafts include microfinance, Islamic finance, insurers and securities-service organizations among intended audiences. Their products need their own permissions, asset definitions, reporting and implementation review.
Shared infrastructure does not make different financial products legally or economically equivalent. These are intended integrations, not available regulated services.
08Merchants · PSPs · PSOs
Make a payment useful beyond the checkout.
For a merchant, success means knowing which order was paid, what settled, and what to do if something went wrong. For a payment provider or system operator, it also means keeping every connected participant on the same record.
Merchants and commerce platforms
The proposed gateway connects invoice references, QR or deep-link checkout, payment status, refunds, split payouts and reconciliation. An order and its payment should remain connected after the customer closes the checkout.
Payment service providers (PSPs)
Connect wallets and merchants to gateway, acquirer and processor workflows through defined APIs and events. Retry handling, delayed confirmation and exception reporting are part of the integration—not afterthoughts.
Payment-system operators (PSOs)
The wholesale design addresses participant coordination, settlement queues, liquidity controls, contingency handling and reporting. PSO here describes the payment-system operator role; it is not a statement of licensing status.
What could a connected merchant workflow look like?
A merchant creates an invoice-linked request. The customer reviews it. The network validates and settles under its rules. A receipt and event update the order and the provider’s records. If a refund or payout follows, it keeps a reference to the earlier transaction. This is the intended integration flow, not a live checkout demonstration.
09Cross-border
Connect domains without erasing their independence.
Cross-border payments bring together different currencies, institutions and settlement rules. The proposed corridor model connects sovereign and institutional domains through agreed interfaces, evidence and governance—not one unrestricted bridge with identical rules everywhere.
FX liquidity, collateral, participant eligibility and failure handling belong in that design. Each participating domain could retain its own validators, privacy boundaries and domestic money rules while exchanging the commitments needed for a corridor transaction.
Cross-border corridors are a later architectural direction, not currently available remittance coverage, guaranteed FX pricing or a claim of instant global settlement.
10Explore today
Find the part of the project you need.
Read the network vision here, explore the technology in more depth, or learn how the account platform handles participation and QTCN records.