OSNOpen Settlement Network

Clearing facts your counterparty can verify without trusting us.

OSN carries clearing instructions between financial institutions as immutable message objects. The value transfer behind every instruction is anchored on a public ledger with frozen rules, which any party can replay and check independently.

OSNMesObject

Header
cleartext · routing, currencies, QCC anchor
Request
ciphertext · written by the originating institution
Result
ciphertext · appended by the clearing institution
CreationHash = SHA3-256( Request.toByte + Header.toByte )

Neither segment is ever edited. Integrity is proven by hashes, not by a mutable status field.

  • QCC Permissionless public ledger. Protocol rules are frozen at launch; there is no upgrade key and no contract layer that can be changed. Value facts are public and independently verifiable.
  • OSN Operated clearing network. OSN coordinates message routing, synchronisation and exception handling. Member institutions run their own nodes and hold their own customer data and keys.

OSN is an operated network, not a public chain. What is not operated by OSN is the value record itself.

01

Five innovations, each independently checkable

Native Post-Quantum Architecture · ML-DSA-87

Institution node identity, clearing result signatures and value transfer on QCC all use ML-DSA-87 — NIST FIPS 204 security category 5, the highest level the standard defines. Post-quantum signatures are built into the ledger from the first block rather than added by later migration, and no elliptic-curve key exists anywhere in the ownership path.

Regulatory Mirror / Synchronisation Node

A supervisor's mirror node replays the ledger and computes the same execution-layer state hash as every member institution. When the hashes match, the supervisor has verified the record itself, without relying on any report produced by OSN. Access to an institution's cleartext is authorised by that institution, limited to one observer per institution node; OSN cannot open it on anyone's behalf.

100-million-scale Verifiable Compliance State

Transfer restriction is a rule of the ledger itself, not a smart contract, so it cannot be upgraded, bypassed or re-scoped by whoever deployed it. Each whitelisted address maps to a KYC or KYB record held by the issuing institution: customer due diligence becomes an enforced transfer rule, while the ledger stores no identity data. The mechanism has been tested on the QCC testnet with 100 million whitelisted addresses.

Continuous Independent Reserve Verification

Stablecoin reserves are usually checked by periodic attestation: an auditor confirms a balance at one past date, weeks after the fact. OSN makes the check synchronous. Settlement token supply is a public on-chain figure that any node can mirror in real time or rebuild by full replay, and read-only balance access for supervisors and member institutions is a condition OSN sets for selecting any reserve bank. Any of them can compare the two figures at any moment; a mismatch is visible when it happens, not at the next reporting date.

Minute-level Clearing & Settlement

Clearing between any two member institutions, wherever they are located, is designed to complete within three minutes. After a 30-second order collection window, the clearing request, the clearing result and the value transfer on QCC are each sealed and signed in sequence; the message lifecycle itself is designed to take about one minute. Settlement here means the final transfer of settlement tokens between institutions on QCC; payout to the end customer follows the receiving institution's local payment rails. The clearing framework is in testnet; published timings will come from testnet measurements.

On reserves: tokens are minted only after reserve funds have arrived and burned before funds leave, so on-chain supply should never exceed the reserve balance. Periodic audit still covers what a balance cannot show — legal title, encumbrances and custody terms. What changes is that the balance itself no longer has to wait for one.

On scale: the whitelist is designed for institution-issued stablecoins with customer bases in the tens of millions per asset. Per-transaction whitelist updates are bounded, so transaction size and cost stay predictable regardless of total list length. Parameters of the 100-million-address testnet run are available to institutions and their advisers on request; formal benchmark results will be published with the protocol specification at mainnet release.

02

Where trust is required, and where it is not

Most clearing infrastructure asks participants to trust an operator's ledger. OSN does not remove the operator — it removes the operator from the record of value.

Function Where it runs Who must be trusted
Value transfer and settlement token supply QCC No one. Rules are frozen and every transaction is publicly replayable.
Clearing instruction, routing, synchronisation OSN OSN as operator, under its licensing obligations.
Customer identity, KYC, payment execution Member institution Each institution, for its own customers only.

Reserve assets backing settlement tokens are held 1:1 with regulated reserve banks. Issuance and redemption are recorded on QCC, so the token supply and the reserve balance can be compared at any time.

03

What a technology or security team will ask first

Where does our customer data sit?

On your node. Request and Result payloads are encrypted with keys derived from your institution's master key. OSN transports and synchronises ciphertext and holds no capability to decrypt it.

Who holds the private keys?

Your institution, exclusively. Rotation is performed by generating new keys, transferring settlement tokens and updating the whitelisted address — no coordination with OSN's key material is required.

What do we have to deploy?

One institution node, handling only your own traffic and data. It is not a consensus node and does not replicate other institutions' cleartext. Reconnection and resynchronisation after network loss are automatic.

How does a supervisor see this?

Through an observer node that your institution authorises, scoped to your own data. OSN cannot grant that access on a supervisor's behalf, because OSN cannot itself attest that a requesting party is a regulator.

04

The message object is the record

An OSNMesObject is not a status record that moves through states. It is two immutable facts joined by cryptography: what the originator asked for, and what the clearing institution did. Nothing is ever rewritten.

  1. Originator builds the Request Clearing orders are collected into a canonical byte sequence and the Header is completed with the QCC transaction hash and confirmation height.
  2. CreationHash is fixed SHA3-256 over Request and Header. From this point the creation content cannot change without detection.
  3. Clearing institution executes locally A one-time derived key is requested, the Request is decrypted, and clearing runs against the institution's own systems.
  4. Result is appended and signed Per-order clearing facts are written as a new segment and signed with the institution's ML-DSA-87 key. The Request is not modified.
  5. Lifecycle is sealed A completion hash binds the creation hash, the result digest and the clearing institution's signature into one final anchor.

Verification without decryption

A verifying node reads the Header, reads the Request ciphertext, recomputes the hash and compares. It never needs the decryption key to establish that the content is intact. Try it — change any field below and watch the anchor break.

CreationHash = SHA3-256( Request.toByte() + Header.toByte() )
Stored anchor (CreationHash at creation time)
Recomputed from current content

This page runs a self-contained SHA3-256 (FIPS 202) implementation in your browser; nothing is transmitted. Field encoding here is a simplified illustration — production uses the canonical toByte() rules in the OSN V1 specification.

05

Post-quantum from the first block, not by later migration

Every signature in the stack — institution node identity, clearing result signatures, and value transfer on QCC — uses ML-DSA-87, the highest parameter set of the NIST-standardised lattice signature scheme. There is no elliptic-curve key anywhere in the ownership path, so there is no migration to plan and no legacy key material to retire.

06

The company

Open Settlement Network Pte. Ltd. is incorporated in Singapore and has no parent company. Ownership sits directly with its four shareholders, and the technical architecture is designed and implemented in-house.

Item Status
Payment institution licence (MAS) Application in preparation; licence class being confirmed with counsel. Not licensed at this time.
Sandbox Plus participation Application in preparation. Not admitted at this time.
Settlement token reserves 1:1 USD, held with regulated reserve banks across more than one custodian.
Protocol specification and source To be published at mainnet release.

Issuance and redemption of settlement tokens require three separate signatures, held by different parties under different custody arrangements. No single person inside the company can mint or redeem.

Joint validation with MAS Sandbox Plus

OSN intends to apply to the Monetary Authority of Singapore for participation in Sandbox Plus. We are inviting banks and payment institutions to be named as joint validation participants in that application. Registering interest carries no obligation and can be withdrawn at any time before submission.

07

Contact

Registered office

Open Settlement Network Pte. Ltd.
101 Cecil Street #11-02
Tong Eng Building
Singapore 069533

Hanson

+65 9113 8952
Business and institutional partnerships

Technical enquiries

admin@qccio.com
Specification requests and technical sessions