Settlement Process

Obligations are recorded throughout the settlement window, compressed through four layers of netting (bilateral, per-corridor multilateral, cross-corridor, and residual carry-forward), priced at oracle-determined FX rates, and settled as consolidated net positions.

Netting Flow

Record

Via API / ISO 20022

→

Bilateral

Per-pair pre-netting

→

Multilateral

Per-corridor + cross-corridor

→

Price

Institutional FX reference rates

→

Settle

Net positions only

Configurable carry-forward of sub-threshold residuals, on the CHIPS model, expands the netting pool across windows for additional compression.

Chain Architecture

The Settlement Computer runs on a dedicated settlement network with permissioned validators. All settlement logic is implemented as consensus-level native precompiles, not smart contracts. This provides deterministic execution cost, guaranteed execution, and no ordering advantage: reference rates are fixed at window open.

Chain
Dedicated permissioned settlement network (Avalanche-based)
Finality
Ledger determination: under one second. Legal finality: subject to per-corridor legal opinions.
Execution cost
Deterministic; no token is issued or planned
Precompiles
11 consensus-level native precompiles
Validators
Permissioned validator set
Corridors
11 on testnet
Compression
Up to 95% multilateral compression exercised on testnet (corridor- and flow-dependent)

All figures are from the Lagrange testnet on generated test flow, as at September 2026. Participant profiles are synthetic. No production traffic.

Native Precompiles

All settlement logic runs at the consensus layer as consensus-level settlement logic — not EVM smart contracts. This provides deterministic execution cost, no ordering advantage (reference rates are fixed at window open), and enables cryptographic operations that would be prohibitively expensive in the EVM.

Eleven native precompiles cover netting, FX reference pricing, compliance hooks, settlement claims, cross-corridor netting, token controls, counter-attestation, corridor management, validator management, post-quantum authentication and privacy.

Privacy — Powered by Qedis

Qedis

Privacy by Qedis — the cryptographic privacy and post-quantum runtime, owned by Digitalyze Labs Ltd and perpetually licensed to the NETTA group. Verifiable confidentiality with no single-party key, no trusted hardware, and no trusted setup.

Qedis provides a substrate-agnostic privacy architecture with no single-party key, no trusted hardware and no trusted setup. Supervisory visibility is reconstructed only under threshold, multi-party control, with every reconstruction and delegated access recorded on-chain. Obligation amounts are netted homomorphically on committed values; metadata is encrypted; proofs are transparent and post-quantum ready; counterparty addressing is unlinkable; key custody is distributed.

Confidentiality
Homomorphic netting on committed values — amounts never disclosed to the chain
Verifiability
Transparent proofs with no trusted setup; post-quantum proof backend
Supervisory access
Tiered view keys — from full supervisory visibility to aggregate-only
Delegation
Participant-controlled, scoped, time-limited, revocable, with an on-chain audit trail

Participants control who sees their data. Corridor privacy configuration and the full cryptographic specification are documented for qualified institutions under NDA.

Post-Quantum Cryptography

ML-DSA (FIPS 204) signatures and ML-KEM (FIPS 203) key encapsulation, hybrid with ECDSA for migration. Deployed on testnet through a FIPS-validated library.

Multi-Tenancy

All Settlement Computer products coexist on a single chain with per-corridor isolation. Each corridor has independent configuration, settlement windows, privacy levels, and compliance rules.

Access Control
Per-corridor role-based access control with a tiered supervisory view
Corridor Isolation
Idempotent creation, independent config, failure isolation
Products
Settlement, PayNet, RiskNet, AssetNet, StableNet
Jurisdiction
Per-corridor compliance rules and privacy levels

ISO 20022 CBPR+

Born-native ISO 20022 CBPR+ — not a translation layer. Native generation of pacs.008 and pacs.009 at the settlement layer; pain.001, pacs.002, camt.053 and camt.054 via the institutional API; CBPR+ Level 1 (schema) and Level 2 (usage guideline) validation passed — validated against the official ISO 20022 schemas and the CBPR+ usage guidelines in automated testing; Swift conformance testing is a pre-pilot step and no Swift certification is claimed. Settlement instructions are generated natively and deterministically at the settlement layer. Machine-assisted translation is used only to normalise inbound payment-provider message formats into canonical obligations, with amounts and identifiers tokenised before processing and results cached deterministically; an untranslatable message is held and flagged, never settled.

pacs.009
FI to FI Financial Institution Credit Transfer — net settlement instruction
pain.001
Customer Credit Transfer Initiation
pacs.008
FI to FI Customer Credit Transfer
pacs.002
Payment Status Report
camt.054
Bank to Customer Debit/Credit Notification
camt.053
Bank to Customer Statement
FX Oracle
Institutional FX reference rates, fixed at window open

Design Principles

Intellectual Property

Twenty US provisional patent applications on file: sixteen held by FiatRails Foundation Ltd; four covering the Qedis privacy and post-quantum runtime, owned by Digitalyze Labs Ltd and licensed perpetually to the group.

Full documentation under NDA

Detailed API specifications, integration guides, precompile documentation, and compliance materials are available for qualified institutional participants.

Request Briefing