KXCO Armature

1.  Introduction

Distributed ledger technology has demonstrated genuine utility for financial settlement, asset tokenisation, and programmable compliance. Permissioned blockchain networks now underpin pilot programmes and production infrastructure at central banks, custodians, and asset managers across multiple jurisdictions. Yet virtually all of this infrastructure — public and private — rests on the same cryptographic assumption: that factoring large integers and computing discrete logarithms remains computationally infeasible for any adversary operating within the laws of classical physics.

That assumption is time-limited. The National Institute of Standards and Technology finalised its first post-quantum cryptographic standards in 2024 — FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) — in direct response to demonstrated and anticipated progress in quantum computing hardware. The implication for financial infrastructure is unambiguous: assets and transaction histories secured exclusively by classical cryptography must be considered at risk on a sufficiently long time horizon, and the timeline for quantum capability is measured in years, not decades.

KXCO Armature is a direct response to that risk. It is a private, permissioned Layer 1 blockchain designed from the outset as quantum-resistant settlement infrastructure for institutional participants. It is not a retrofit of an existing public chain and it is not a theoretical proposal. Every architectural decision — consensus mechanism, key management, transport security, smart contract authorisation model, and external auditability — is made with the post-quantum threat model as a first-order constraint.

This paper describes the technical architecture of KXCO Armature, the specific mitigations deployed against each identified attack surface, and the chain's design as a settlement layer for two of the most consequential institutional use cases in digital assets: stablecoin issuance and real world asset tokenisation.

2.  The Quantum Threat to Financial Cryptography

2.1  Shor's Algorithm and Elliptic Curve Cryptography

Every Ethereum-compatible blockchain, including all Hyperledger Besu deployments, uses secp256k1 elliptic curve cryptography for account key pairs and transaction signatures. The security of secp256k1 rests on the elliptic curve discrete logarithm problem: deriving a private key from its corresponding public key requires solving this problem, which no known classical algorithm can do in polynomial time.

Shor's algorithm, running on a fault-tolerant quantum computer with a sufficient number of logical qubits, solves the elliptic curve discrete logarithm problem in polynomial time. Any address that has published its public key — by sending at least one transaction — is in principle vulnerable to private key derivation by a quantum adversary with adequate hardware. Current cryptographic consensus is that approximately 2,048 logical qubits are required to break a 256-bit elliptic curve key. Estimates for when fault-tolerant quantum computers at this scale will be available range broadly, but the uncertainty in that range is itself the institutional risk: infrastructure designed for a 15-year asset life and deployed today must be assumed to operate within the post-quantum era.

2.2  The Harvest Now, Decrypt Later Threat

The quantum threat is not confined to future capability. Adversarial actors — including state-level actors — are plausibly already capturing and archiving encrypted network traffic, signed messages, and key exchange records from financial networks. When quantum capability matures, this archived data can be decrypted and analysed retrospectively. For financial institutions, this means that transaction confidentiality, custody proof records, and key material transmitted today may be compromised on a future date. Migration to post-quantum cryptography therefore cannot be deferred until quantum computers are available; the window for effective migration has already opened.

2.3  The NIST Post-Quantum Standards

Following an eight-year public standardisation process, NIST published its first post-quantum cryptographic standards in August 2024. KXCO Armature uses exclusively algorithms drawn from this standardised suite.

ML-DSA and ML-KEM are based on the hardness of lattice problems — specifically the Module Learning With Errors problem. SLH-DSA rests exclusively on the collision resistance of hash functions. KXCO Armature deploys both ML-DSA-65 and SLH-DSA-SHAKE-128s for transaction signing to achieve algorithm diversity: if lattice cryptography were ever broken, the hash-based signature would remain secure. NIST selected all three algorithms following extensive third-party cryptanalysis. KXCO Armature does not deploy experimental or non-standardised post-quantum schemes.

3.  KXCO Armature Architecture

3.1  Foundation: Hyperledger Besu

KXCO Armature is built on Hyperledger Besu 26.4.0, an enterprise-grade, Apache 2.0-licensed Ethereum client maintained under the Linux Foundation. Besu was selected for its full EVM compatibility — enabling deployment of standard Solidity smart contracts without modification — its support for permissioned network topologies, its implementation of the QBFT consensus algorithm, and its production track record in enterprise and central bank digital currency deployments.

3.2  Consensus: QBFT

KXCO Armature uses QBFT (Quorum Byzantine Fault Tolerant) consensus. QBFT is a variant of the PBFT family that provides immediate, deterministic finality: a block confirmed by QBFT consensus is final upon confirmation, with no probabilistic depth requirement and no possibility of reorganisation. This property is a prerequisite for financial settlement infrastructure. A transaction included in a finalised QBFT block cannot be reversed by any subsequent chain activity.

The network currently operates four validator nodes. QBFT tolerates up to f Byzantine faults in a network of 3f + 1 validators. With four validators, the network tolerates one Byzantine fault and maintains liveness with three honest participants — appropriate for a controlled institutional deployment with known, vetted validator operators.

3.3  Network Topology and Security Perimeter

The network operates on a private Docker bridge subnet (172.20.0.0/24). All validator P2P and RPC ports are bound exclusively to the loopback interface (127.0.0.1). No validator, consensus, or P2P traffic is exposed to the public internet. External access is mediated exclusively through a TLS-terminating nginx reverse proxy with HTTP Basic Authentication. A dedicated observer node, carrying no validator key material, serves as the public JSON-RPC endpoint and block explorer backend.

3.4  EVM Compatibility

KXCO Armature runs a standard Ethereum Virtual Machine. All Solidity contracts compiled for Ethereum mainnet or any EVM-compatible network deploy and execute on KXCO Armature without modification. Token standards including ERC-20, ERC-721, ERC-1155, and regulated security token standards including ERC-1400 and ERC-3643 are natively supported. The full Ethereum JSON-RPC API is implemented, allowing Hardhat, Foundry, ethers.js, and Web3.js to interact with the network directly.

4.  Post-Quantum Hardening Framework

KXCO Armature identifies and addresses four distinct post-quantum attack surfaces, plus several ancillary cryptographic surfaces. Each represents a path by which a quantum-capable adversary could compromise the integrity, confidentiality, or correctness of the chain. All surfaces are addressed by mitigations deployed in the current build. In addition to the four primary attack surfaces, the platform deploys: SLH-DSA-SHAKE-128s (FIPS 205) as a second PQ transaction signature providing hash-based algorithm diversity; Argon2id v3 (memory-hard KDF) for wallet private key protection; ML-KEM-768 encrypted on-chain payment memos; and ML-DSA-65 per-request institutional API authentication.

4.1  Surface 1 — Validator Consensus Keys

Threat. Each validator holds a secp256k1 key pair used to sign QBFT consensus messages. Quantum-derived recovery of a validator's private key would allow an adversary to impersonate that validator, equivocate in the consensus process, or participate in an attempted double-spend or finality attack.

Mitigation A — Network Isolation. All validator P2P ports are bound to 127.0.0.1. Consensus key material is never transmitted over a network accessible to an external adversary. The secp256k1 public key is not published to the internet.

Mitigation B — ML-DSA-65 Block Attestation. Each validator runs a dedicated attestation sidecar that independently signs every finalised block using its ML-DSA-65 (Dilithium3) private key. The canonical attestation message is:

This creates an independent, post-quantum record of validator participation for every block. A consensus attack conducted using a quantum-derived secp256k1 key cannot produce valid Dilithium3 attestations, making the attack immediately detectable against the external attestation record. Each attestation container mounts only its own key pair; compromise of one container does not expose the key material of other validators.

4.2  Surface 2 — Peer-to-Peer Transport Layer

Threat. The devp2p peer-to-peer protocol used by Besu for inter-node communication employs classical elliptic curve Diffie-Hellman key exchange, which is vulnerable to Shor's algorithm. Adversaries recording inter-node traffic today can retrospectively decrypt all session content once quantum capability is available.

Mitigation A. All P2P traffic is confined to the Docker bridge network, bound to 127.0.0.1. No inter-node traffic traverses any public or third-party network in the current deployment configuration.

Mitigation B — ML-KEM-768 Pre-Shared Keys. ML-KEM-768 pre-shared keys have been generated for all validator pairs using NIST FIPS 203 encapsulation. These keys are designed for deployment as WireGuard pre-shared keys, providing a hybrid quantum-resistant encryption layer for inter-node tunnels when the network expands to multi-host topology. The PSK material is generated and available for activation at that point.

4.3  Surface 3 — EVM Account Model

Threat. The Ethereum account model binds every address to a secp256k1 key pair. Any address that has sent a transaction has published its public key on-chain. Quantum-derived private key recovery would give an adversary complete control of that address and all assets it holds.

Mitigation — PQCWallet.sol. KXCO Armature deploys a smart contract wallet governed exclusively by an ML-DSA-65 key. All fund operations — transfers, contract calls, token movements — require a valid Dilithium3 signature over a domain-separated digest incorporating the chain ID, contract address, target address, value, calldata hash, and nonce:

The secp256k1 key used to pay gas has no authority over wallet assets. A quantum adversary who recovers the secp256k1 private key gains the ability to pay gas — nothing more. The wallet contract ignores it for all authorisation purposes.

PQCWallet supports a two-phase migration path. In the pre-Phase 3 trusted-verifier mode, an authorised off-chain service validates the owner's Dilithium3 signature and submits the transaction on-chain. In Phase 3+, an on-chain ML-DSA-65 verification precompile at address 0x0000000000000000000000000000000000000009 eliminates the trusted intermediary, placing signature verification directly in the EVM. Migration between modes is atomic; no funds move.

4.4  Surface 4 — Historical Data Integrity

Threat. For a private chain with a small validator set, the assumption that historical blocks cannot be silently rewritten has weaker guarantees than for a large public network. A quantum adversary who recovers multiple validator keys could attempt to rewrite history without immediate detection.

Mitigation — External Attestation and Checkpointing. Two independent external records are maintained. Block hash checkpoints are appended to a public GitHub Gist every five minutes, providing a time-stamped external reference for chain state that is independent of the chain infrastructure. Separately, each validator's attestation sidecar publishes its complete ML-DSA-65 signed block attestation log to an external Gist after every block. Any third party can independently verify that a given block was attested by a specific validator using only the public log, the validator manifest, and the open-source verification utility. Retroactive modification of chain history would be immediately detectable against either external record.

Mitigation — SLH-DSA Backup Integrity Signing. Every encrypted wallet database backup is signed with SLH-DSA-SHAKE-128s (NIST FIPS 205) using a dedicated signing key held in the server environment. The signature is stored alongside the encrypted backup and can be independently verified by any third party holding the published public key. Hash-based signatures provide a second independent proof that the backup originated from KXCO infrastructure — if ML-DSA were somehow broken, SLH-DSA verification would remain valid.

5.  Stablecoin Infrastructure

5.1  Permissioned Architecture and Regulatory Suitability

Institutional stablecoin issuance — whether fiat-backed, commodity-backed, or central-bank-issued — operates within a regulated environment that public permissionless chains do not naturally accommodate. Issuers require the ability to enforce transfer restrictions, freeze addresses for compliance purposes, execute forced redemptions under applicable law, and maintain an authoritative and auditable record of supply. These capabilities exist in the smart contract layer, but the underlying chain must provide the performance, finality, and access control properties that regulators and institutional counterparties require.

KXCO Armature's QBFT consensus provides immediate, deterministic finality. A stablecoin redemption or mint confirmed in a KXCO Armature block is final, unconditionally. This eliminates the reconciliation ambiguity that arises on probabilistic chains where a "confirmed" transaction may subsequently be reorganised. For regulated settlement systems, this property is not a convenience — it is a compliance requirement.

5.2  Quantum-Resistant Custody

The private keys controlling a stablecoin contract — authorising mint, burn, freeze, and upgrade operations — represent the highest-value target on any stablecoin infrastructure. On a classical chain, these are secp256k1 keys, vulnerable to quantum-derived key recovery. An issuer deploying a PQCWallet as the controller of a stablecoin contract ensures that all such operations require a valid ML-DSA-65 signature. The secp256k1 gas-payer key is operationally inert with respect to the stablecoin contract. Quantum recovery of the gas-payer key yields no capability to manipulate the stablecoin supply, modify access controls, or access reserve operations.

5.3  Reserve Proof Architecture

KXCO Armature is designed to support on-chain reserve proof mechanisms in Phase 7.5 of its development roadmap. In this architecture, off-chain reserve attestations from authorised auditors are committed to the chain as Merkle roots. On-chain mint functions verify at execution time that the attempted mint does not cause circulating supply to exceed the attested reserve figure. Reserve proof events are emitted and independently verifiable. The auditor's signing key may itself be an ML-DSA-65 key, making the full reserve attestation chain quantum-resistant from the custodian through to the smart contract.

5.4  ISO 20022 Interoperability

The global transition to ISO 20022 as the universal financial messaging standard — driven by SWIFT, the BIS, and central banks across major payment corridors — creates a direct connection requirement between blockchain settlement systems and traditional payment rails. KXCO Armature's Phase 5 roadmap includes an ISO 20022 bridge supporting a pacs.008 credit transfer round-trip, allowing on-chain stablecoin settlements to be initiated by and reported back into ISO 20022 message flows. This positions KXCO Armature as a settlement layer that operates alongside, rather than in isolation from, existing financial messaging infrastructure.

6.  Real World Asset Tokenisation

6.1  Infrastructure Requirements of Regulated Tokenisation

Real world asset tokenisation — the issuance of digital tokens representing legal or beneficial ownership of physical or financial assets — has emerged as one of the most significant categories of institutional digital asset activity. Estimates from major financial institutions project tens of trillions of dollars in tokenised assets under management within the coming decade, spanning sovereign bonds, private credit, real estate, infrastructure, and commodities.

The infrastructure requirements for regulated tokenised assets are materially different from those for speculative or decentralised finance applications. Tokenised securities require: investor identity verification and permissioned transfer restrictions; unconditional settlement finality for regulatory compliance; a tamper-evident and independently verifiable audit trail; privacy for commercially sensitive transaction terms; and an upgrade and migration path that does not require simultaneous action by all participants.

6.2  How KXCO Armature Addresses These Requirements

Permissioned access. KXCO Armature operates as a permissioned network. Validator participation requires authorisation. Transaction submission is mediated through the observer node, which can enforce allowlisting at the network boundary. This gives issuers and regulated participants control over who can hold and transfer tokenised assets at the protocol level, independent of smart contract logic.

Immediate finality. QBFT consensus provides single-block finality. Tokenised asset transfers confirmed on KXCO Armature are settled immediately, with no exposure to reorganisation risk. This satisfies the T+0 settlement finality requirements that are emerging from securities regulators in multiple jurisdictions as a precondition for blockchain-based securities settlement.

Token standard compatibility. Security token standards including ERC-1400 — which provides partitioned token ownership, forced transfers, issuance controls, and operator permissions — and ERC-3643, the T-REX compliance framework with on-chain identity and eligibility integration, deploy on KXCO Armature without modification. Issuers can use established, audited token contract frameworks rather than bespoke implementations.

Quantum-resistant custody. Tokenised assets with multi-year or multi-decade holding periods — real estate, infrastructure bonds, long-duration private credit — are directly exposed to the post-quantum threat horizon. Assets tokenised today and held through 2040 require custody infrastructure that is resistant to quantum attack over that full holding period. KXCO Armature's PQCWallet ensures that custody authorisation requires ML-DSA-65 signatures for which no quantum attack is known.

Verifiable audit trail. The external attestation layer provides an independently verifiable record of chain state that is not under the control of the issuer, the chain operator, or any single validator. Any regulator, auditor, or counterparty can verify that a specific block was attested by the validator set at a specific time using publicly available data and open-source tooling. This property is available today, in the current deployed build.

6.3  Private Transaction Channels

Commercial RWA transactions typically contain information — counterparty identity, transaction value, pricing, and asset terms — that participants are not willing to publish on a shared ledger. KXCO Armature's Phase 2.6 roadmap includes private transaction channels based on a Tessera-compatible architecture: the public chain records only the transaction hash; full transaction details are exchanged privately between authorised participants. Settlement finality and the external audit properties of the chain are preserved; commercially sensitive details are not disclosed to non-parties.

6.4  Compliance Infrastructure

Phase 7.5 of the KXCO Armature roadmap includes on-chain KYT (Know Your Transaction) and AML infrastructure: a sanctions Merkle root oracle updated by an authorised compliance operator, a precompile that screens incoming transactions against the current sanctions list at admission time, and SAR (Suspicious Activity Report) event emission for integration with compliance monitoring systems. This compliance layer is a native capability of the chain, not an external overlay, ensuring that compliance screening occurs at the protocol level before a transaction can be included in a block.

7.  Institutional Trust Architecture

7.1  The Infrastructure Provider Model

KXCO Armature operates a deliberate separation between the software infrastructure layer and the regulated financial services layer. Knightsbridge provides the blockchain protocol, tooling, and infrastructure. The regulated entity — the licensed custodian, stablecoin issuer, or authorised financial institution — operates on the infrastructure and bears the applicable regulatory obligations. This model is analogous to the relationship between a cloud infrastructure provider and a regulated financial service operated on that infrastructure: the infrastructure provider is not itself a regulated entity; the party providing financial services on it is.

This architecture is consistent with regulatory frameworks emerging across multiple jurisdictions that distinguish between DLT infrastructure providers and regulated virtual asset service providers or digital securities issuers.

7.2  Formal Finality Certificates

Phase 2.6 of the roadmap introduces formal finality certificates — aggregated QBFT commit signatures for confirmed blocks, exposed via a dedicated JSON-RPC endpoint and accompanied by legal documentation of the finality guarantee. These certificates are designed for transaction confirmation flows in which regulatory or contractual requirements demand explicit, documented evidence of settlement finality, not merely a confirmation count.

7.3  Validator Governance

Phase 6 of the roadmap formalises validator governance through a published, legally reviewed governance document specifying validator admission and removal procedures, economic arrangements, network upgrade procedures, and dispute resolution. The production validator set targets five to seven nodes with at least one independent operator, providing operational decentralisation consistent with the permissioned character of the network.

7.4  Independent Security Audit

Phase 3 of the roadmap is a dedicated third-party security audit. The audit scope covers the QBFT-PQC consensus integration, hybrid transaction format, ML-DSA-65 implementation, PQC precompile, private transaction channels, finality certificates, devp2p transport layer, and key management procedures. Transition to production infrastructure in Phase 4 is conditional on remediation of all Critical and High findings from the audit and public release of the audit report.

8.  Technical Specifications

8.1  Chain Parameters

8.2  Post-Quantum Cryptographic Parameters

8.3  Cryptographic Libraries

9.  Development Roadmap

Note: the quantum page at chain.kxco.ai/quantum uses higher-level phase groupings (Phase 1 / Phase 2 / Phase 3 / Phase 4) that correspond to clusters of the granular phases listed below. The numbering is different; the scope is the same.

10.  Conclusion

The transition from classical to post-quantum cryptography is an active engineering requirement for financial infrastructure operating on any time horizon beyond the near term. Institutions committing digital assets to blockchain infrastructure today, or deploying settlement systems intended to remain in production across the quantum transition, must make architectural decisions now that will determine their exposure to both current harvest attacks and future decryption capability.

KXCO Armature provides a practical and deployed answer to this requirement. It is not a research prototype. It is an operational blockchain with a hardened network boundary, independent post-quantum attestation of every finalised block, a quantum-resistant smart contract custody layer, and an externally verifiable audit trail that any party can independently verify today using publicly available data and open-source tooling.

The architecture is designed specifically for the institutional use cases in which the quantum threat is most consequential: stablecoin issuance, where reserve custody and mint authorisation represent the highest-value attack targets; and real world asset tokenisation, where multi-year and multi-decade holding periods place tokenised assets directly within the quantum threat horizon.

All post-quantum algorithms deployed on KXCO Armature are drawn exclusively from the NIST-standardised suite: ML-DSA-65 (FIPS 204), SLH-DSA-SHAKE-128s (FIPS 205), and ML-KEM-768 (FIPS 203). The chain maintains full EVM compatibility, ensuring that the established ecosystem of Ethereum development tooling, audited smart contract standards, and institutional integration patterns is available without modification.

The phased development roadmap takes the chain from its current hardened private testnet state through hybrid consensus, ISO 20022 interoperability, independent security audit, production-grade infrastructure, and CBDC readiness — each phase gated on verified completion of the previous one. The architecture is built on the conviction that quantum-resistant financial infrastructure is not optional for institutions operating on a multi-decade horizon. The time to build it is now.