Tokenisation and RWA With KXCO: ML-DSA-87 on Chain, Verifiable by Anyone

Armature, KXCO's chain, has verified ML-DSA-87, the highest security category in NIST FIPS 204, natively on chain since block 4,951,111 on 6 October 2026, per the chain's public record. KXCO's platform signing keys moved to ML-DSA-87 on 6 and 7 October 2026, per its published key list, and anyone can call the check.

That is the base KXCO builds tokenisation on. A tokenised asset is a signed record, and the record has to stay provable for as long as the asset lives. A 30-year bond issued this year has to prove who issued it, and to whom it moved, in 2056. A signature a quantum computer can forge does not pass that test. ML-DSA-87 does, and on Armature the chain itself checks it, so nobody has to take a vendor's word for it.

Regulators have now made tokenisation a supervisory subject, and their resilience rules already ask for cryptography that can change as the threat changes. This piece sets out what an institution should test before it trusts a tokenisation platform, how KXCO answers each test, and where a reader can check the answer. Every claim about KXCO below points at a public page or a public endpoint. The tests, in the order this piece takes them:

• The register. Whether the ledger is the register, and when a transfer is final.

• The cryptography. Whether a signature will outlast the asset it proves, and whether the cryptography can change.

• Admission. Who may hold a unit, and who decides.

• Transparency. Who can check a record, and who can read it.

• Control. Who approves an action, and where the model sits.

• The whole system. Whether the platform can see every party a tokenised asset depends on.

Exhibit 1. Each question is quoted or drawn from a dated regulatory text. Each answer points at a live KXCO page or endpoint.

Regulators now ask the register question

The Central Bank of Ireland's Governor Makhlouf told the Irish Funds conference on 1 October 2026 that "tokenisation of fund units could deliver efficiencies in settlement, improve transparency, and broaden access to investment products", per the Central Bank. He added a condition: "tokenising one aspect of the system is not enough". The same speech noted that "the Eurosystem has just enabled transactions on DLT platforms to settle in central bank money".

ESMA went further on 23 September 2026. It announced a new Union Strategic Supervisory Priority on digital innovation from 2027 and said "our initial focus will be on how supervised entities use artificial intelligence and tokenisation", per ESMA. A strategic priority directs supervisory resources across every member state. Tokenisation is now on that list by name.

ESMA's Chair, Verena Ross, framed the question every institution will be asked. Speaking to EFAMA on 12 June 2026, she asked: "is the DLT record the official register, or only an operational layer?" She also asked whether transfers are final on chain, or only once the transfer agent's books reflect them, per ESMA.

The Central Bank's own Discussion Paper 12, published on 5 March 2026, sketched what a good answer looks like for a money market fund. Its units "would be issued as tokens on a permissioned ledger operated by regulated entities, including the fund administrator and transfer agent". The paper went on: "The ledger serves as the primary record of investor ownership, with token transfers subject to embedded eligibility and compliance rules."

It also set a floor that no technical design removes: "Fund-level tokenisation does not alter the need for independent valuation, liquidity management, depositary oversight and investor disclosure obligations". A tokenisation platform that serves institutions has to fit under that floor, not replace it.

The market is already moving. Aviva Investors launched a tokenised share class of its US Dollar Liquidity Fund on 29 July 2026, approved by the Central Bank of Ireland, per Aviva Investors. Schroders secured the same regulator's approval for its first tokenised share class, of a US dollar money market fund, per Markets Media in August. Approvals are being granted. The questions above are the ones every next approval will turn on.

The quantum deadline is already written down

The cryptography question is not waiting for a tokenisation rulebook. DORA, the EU's Digital Operational Resilience Act, has applied since 17 January 2025, per EUR-Lex. Its technical standard on ICT risk, Delegated Regulation 2024/1774, requires a financial entity's encryption policy to include "provisions for updating or changing, where necessary, the cryptographic technology on the basis of developments in cryptanalysis". Its recitals name the threat outright, "including threats from quantum advancements".

The EU's coordinated roadmap for post-quantum cryptography, published on 23 June 2025, sets the dates. By 31 December 2026, member states should have started transition planning and pilots for high-risk and medium-risk use cases. High-risk use cases should move "no later than the end of 2030", and medium-risk ones by 2035. For confidentiality, the roadmap treats a use case as high-risk when a compromise 10 years or more later would still cause significant damage. It cites the German BSI's assessment that a quantum computer able to break today's public-key cryptography is likely to be feasible by 2040 or earlier.

NIST approved the three standards on 13 August 2024, per NIST: FIPS 203 for establishing encryption keys, and FIPS 204 and FIPS 205 for digital signatures. ML-DSA is the signature scheme FIPS 204 defines. Europol's Quantum Safe Financial Forum put it plainly on 7 February 2025: it "implores the financial sector to act now to combat the quantum related threat", per Europol.

For a register, the quantum risk is forgery more than eavesdropping. A machine that can derive a signing key from a public key can sign a transfer the holder never made, and the forgery looks exactly like the real thing. Encrypted data can be re-encrypted later. A signature on an issuance or a transfer is part of the history of title, and history cannot be re-signed after the fact without someone asking which version is true. The defence has to be in place when the record is written.

Set the cryptography texts next to the tokenisation texts and a gap shows. The word quantum does not appear in Discussion Paper 12, in either speech, in ESMA's notice of its 2027 priority, or in the two fund reports above, per a text search of each saved document on 7 October 2026. Supervisors are asking how tokenised registers work. Their resilience rules already ask whether the cryptography can change. A platform has to answer both, and KXCO built for both from the first block.

ML-DSA-87 on chain since block 4,951,111

FIPS 204 defines three parameter sets for ML-DSA. ML-DSA-44 claims security category 2, ML-DSA-65 category 3 and ML-DSA-87 category 5, per Table 1 of the standard. Category 5 is the top of the scale. It is the level an institution chooses when a signature has to outlast the asset it proves.

On Armature, the check is a precompiled contract, a verifier built into the chain itself, at address 0x4b58434f00000000000000000000000000000087. It has been live since block 4,951,111, at 08:37:11 UTC on 6 October 2026, per KXCO's developer note. Any smart contract can call it, and so can anyone with an internet connection. The caller sends a public key, a signature and a message to the chain's public RPC endpoint. The chain answers 1 for a valid signature and 0 for anything else. A read call costs nothing and changes nothing.

KXCO made that call on 7 October 2026 at block 5,010,242, per the public endpoint. A fresh ML-DSA-87 signature returned 1. The same signature over a message with one bit flipped returned 0. The same input sent to the chain's ML-DSA-65 precompile, at address 0x0b, also returned 0, so the two levels never cross.

The keys moved with the chain. Seven KXCO platform signing keys are now ML-DSA-87, per the published key list: the institution key of Round Table, the platform key of Meridian, the KXCO platform identity, the root key for KXCO's post-quantum evidence, the pqc.kxco.ai API, KXCO Mail and the key that signs Live Trading News articles. The evidence key moved on 6 October, and the other six moved on 7 October. Each ML-DSA-65 key they replaced stays on the list, marked superseded, so every signature made before the switch still checks out against a published key.

That is the capability Article 6(4) of the DORA standard asks for: change the cryptographic technology when the analysis moves, and lose nothing that was signed before. KXCO moved seven keys in two days.

The validators are moving the same way. Every finalised block is independently attested with each validator's ML-DSA key, per the chain's validator page. Those attestation keys are moving to ML-DSA-87 one validator at a time, and node4 switched first, from block 4,993,304, per the same page.

Built post-quantum from genesis

Post-quantum was not bolted on to Armature. ML-DSA has been in production from the first block, per KXCO's corporate page, and the chain's quantum page records the migration path as pre-planned and pre-tested. The chain describes itself as "post-quantum from genesis, permissioned for regulated finance, instant-final and identity-native", per its home page.

All three NIST standards run in production, each where it does the most work:

• FIPS 204, ML-DSA. The chain checks ML-DSA-87 and ML-DSA-65 signatures natively, and a smart contract can require a valid post-quantum signature before it acts, per the quantum page.

• FIPS 203, ML-KEM. Connections to the chain's public site use hybrid key exchange, X25519 with ML-KEM-768. Traffic between nodes runs over a WireGuard overlay with preshared keys derived from ML-KEM-768, per the same page.

• FIPS 205, SLH-DSA. Every encrypted backup file carries a hash-based signature made with SLH-DSA-SHAKE-128s. That scheme does not depend on lattice mathematics, so the backup's proof stands even if lattice cryptography were ever broken, per the same page.

The point for an institution is agility as much as strength. The chain runs two ML-DSA levels side by side and a hash-based scheme beside them. Moving a key from one level to another is a rotation, with the old key kept on the public list, and 6 and 7 October showed how fast that runs.

Permissioned: admission closed, checks open to all

Armature is a permissioned, EVM-compatible chain, per its home page. Admission is closed: a participant cannot hold or move a unit without being admitted by the institution that runs the environment. Checking is open to all. The RPC endpoint and the explorer are public, and nobody needs an account to read the record or test a signature.

The consensus is QBFT with 4 validators, so 3 of 4 must sign each block and the network tolerates one faulty or malicious node, per the governance page. Blocks come every 2 seconds. Finality is deterministic, with no forks and no reorgs. Once a block is final, the transfers in it are final, and nothing reorganises them afterwards.

That settles the technical half of Ross's second question. A transfer on Armature does not sit in a probabilistic settlement window waiting to be confirmed. The fund's documents then say which record is legal title, and on KXCO that record is the register, which evaluated the transfer rule before the unit moved.

Permissioned also means predictable. Fees on Armature are near-zero and predictable, per its home page, so the cost of moving a unit does not jump because some other market got busy. The chain is EVM-compatible, so an institution's engineers build with the tools they already know, and every contract they deploy can call the ML-DSA-87 check described above.

Today the 4 validators are run by Knightsbridge Group, KXCO's group, and the set is public, per the governance page. Changing it takes 3 of 4 on-chain votes, with no admin keys and no multisig. The published roadmap moves to institutional co-validation, where onboarded institutions and custodians run validators under a published admission policy. For customers, KXCO recommends co-validation, an independent validator, or both.

Permissioned is the shape the regulator described. Discussion Paper 12's money market use case is a permissioned ledger operated by regulated entities. The same paper says the Central Bank's stance, "while being technology neutral, this should not be perceived as being technology agnostic". Design choices matter to the supervisor. A chain anyone can join cannot hand a supervisor a list of who runs it. Armature can, and it publishes one.

Wallets that know who holds them

Treasury wallets are self-custody and multi-chain, identity-aware and compliance-enabled, with Travel Rule support built in, per KXCO Treasury. They run on web, on mobile and as a browser extension, and they are live today. The Travel Rule requires the details of the sender and the receiver to travel with a transfer of crypto-assets. In a Treasury wallet those details move with the transfer, so a compliance team is not left chasing them afterwards.

KYC stays with the licensed institution. It runs know-your-customer and know-your-business checks on its own licence and under its own procedures, and its reviewer approves each holder by name. The institution's checks cover sanctions and politically exposed status before any credential issues. KXCO's software turns the institution's decision into a signed ML-DSA credential. Anonymous addresses, unverified wallets and unattributed AI agents are never admitted, so they cannot hold a position at all, rather than being blocked after the fact. Each new identity receives a marker wallet on Armature, so every credentialed party has an on-chain presence from the day it is admitted. The credential is what the register reads when a unit is about to move.

That split is deliberate, and it is the one supervisors expect. The Central Bank's anti-money laundering guidelines say that where an agent or service provider gathers the evidence on a customer, "the Firm remains responsible". A platform that ran KYC on its own account would blur that line. KXCO keeps it sharp: the institution decides who is admitted, and the software enforces that decision wherever the unit goes inside the environment.

The register decides before a unit moves

Tokenisation sits inside KXCO Treasury, the layer for any store or movement of value. Treasury already runs wallets, exchanges and settlement engines for FX, securities, futures, options, bonds, tokens, stablecoins and cash, per KXCO Treasury. A tokenised fund unit, a bond or a share in a building is one more kind of value moving under the same rules.

The register is where the rule lives. Before a unit moves, the register evaluates the transfer rule: who holds this, are they permitted to hold it, and is this transfer allowed. A transfer that fails the rule is refused before it clears, not investigated after it settles. The register and capital machinery behind it is in production, with effective-dated capital tables, capital calls split as at the call date, value-dated payments and waterfall distributions.

So KXCO's answer to the register question is plain. On KXCO the register evaluates the transfer rule and the chain carries the signed proof. The administrator, the transfer agent and the depositary keep their roles. Discussion Paper 12's floor stays where it is, and valuation, liquidity management, depositary oversight and investor disclosure are still done by the people regulated to do them. The software makes each of those steps provable. It does not take them over.

CareCredits is the live example. "CareCredits is live and in use now, with two pilots running, one in the EU and one in the UK", per KXCO Treasury. It settles provider payments, insurance, patient funding and healthcare credits on Treasury rails, with Armature as the record.

The licence line is simple and it does not move. "KXCO provides the software; the licensed institution holds the assets", per KXCO Treasury. The licensed institution operates the environment. KXCO holds no custody, no client assets and no financial licences.

A tokenised fund on KXCO, start to finish

Take a fund manager that wants a tokenised share class of an existing fund. The licensed institution, which can be a bank, an administrator or the manager's own regulated entity, deploys KXCO's software in its own estate under its own brand. It sets the class up in the Treasury register with the eligibility rules the prospectus already contains.

An investor applies. The institution runs KYC on its own licence and approves the investor by name. KXCO's software issues a signed ML-DSA credential and a marker wallet on Armature, and the investor's identity-aware wallet now carries a credential the register can read.

The investor subscribes. The administrator values the fund and strikes the price as it does today. Units go to the investor's wallet, the register records the holding with its effective date, and the chain anchors the signed record.

Months later the investor sells part of the holding to another investor. The register evaluates the transfer rule before anything moves. The buyer is admitted, the credential is live and the class allows the transfer, so it proceeds and settles in a 2-second block with deterministic finality. Had the buyer not been admitted, the transfer would have been refused before it cleared, and nothing would need unwinding.

At the year end the depositary reconciles custody and cash as it always has. The auditor checks the anchors against the published keys, without an account and without reading any document it is not entitled to see. If the supervisor asks who held the class on a given date, the register answers from its effective-dated record. The chain shows that the answer has not changed since it was signed.

Nobody in that sequence gave up a role. The manager, the administrator, the transfer agent, the depositary and the auditor each do what they are regulated to do. The difference is that every step is checked before it happens and provable afterwards, on a chain that checks ML-DSA-87 natively.

Exhibit 2. Each step shows its holder. The institution decides, KXCO's software enforces and proves, and anyone can check.

Transparency: verifiable by anyone, readable by those entitled

Transparency on KXCO means a stranger can check a record, not that a stranger can read it. "Anyone can verify a record against a published public key, with no account and no trust in KXCO required", per KXCO Treasury. KXCO's verification service makes the same promise in its own words: "KXCO's servers are not in the verification path", per verify.kxco.ai.

What goes on the public record is a digest, a signature and an anchor. The document, the holder's details and the position stay off it, readable only by the parties the institution entitles, such as its own staff, its auditor and its supervisor. An auditor can confirm that a record existed at a given block, unchanged and signed by a named key, without seeing what it says.

A fully public ledger shows every balance to every competitor. A closed database shows nothing to anyone outside. KXCO gives the institution the audit trail of the first and the confidentiality of the second, which is the property a closed environment needs to satisfy an outside party without leaking anything.

Control stays with the institution

A proposal becomes a recorded action on KXCO only when it is approved by name. Each action is checked against its own preconditions and shown as a preview of exactly what will change before anyone approves it, per KXCO's ontology page. On Round Table, "a passkey lets you sign your own decisions with your own device", per Round Table. The service stores only the public half of each passkey.

Delegation has a ceiling. Authority delegated to an agent "can only ever narrow, never widen, however far down the chain it is passed", per the ontology page. Where a mistake is expensive, the party who decided and the operator who carries it out can be required to be two different parties.

Round Table is the logic between the institution and the LLM. The language model is a reasoning engine that sits outside the record. The rules on thinking, evidence, responsibility and chain of custody sit in Round Table, and the knowledge stays the institution's. In KXCO's own phrase, "the model stays outside the knowledge". It runs "inside your estate, not ours", in the ontology page's words, and the reasoning points at the institution's own inference endpoint, per the ontology page. The same page puts the custody position in four words: "KXCO takes custody of nothing."

The rest of the stack follows the same line. Meridian is the paper: contracts, documents, signatures and evidence. Treasury is the value. Armature is the chain that proves both. The institution holds the licence, the client relationship and the final say, and KXCO holds none of them.

One model. The whole ecosystem.

Tokenisation fails at the joins. Makhlouf's point that "tokenising one aspect of the system is not enough" is a point about the parties nobody mapped: the custodian behind the custodian, the valuation source behind the price, the reconciliation behind the register. KXCO's answer is an ontology, a formal model of every party, asset, obligation and claim, each with its source and the date it was true. Where two parties' records disagree, both accounts are kept side by side and neither is quietly overwritten, per KXCO's products page, so a reconciliation break shows up as a fact with two sources instead of a number someone adjusted.

The engine has been shown at sector scale on public data. Round Table resolved six names into 413 entities and 937 relationships, 883 of them carrying a source anyone can open, as of 7 October 2026, per KXCO's ontology page. The page's line for it is "One model. The whole ecosystem." Pointed at an institution's own books, the same engine maps a tokenised asset's whole circle: issuer, administrator, transfer agent, depositary, custodian, distributor, investor, valuation source and supervisor, with every relationship between them typed, sourced and dated.

Every token on KXCO is a typed claim. The ontology's issuance domain gives each kind the same four edges, "issuer permissioned, holder identified, backing proven, lifecycle recorded", per the ontology page. An RWA token is defined as a claim on a real asset, and it carries its underlying asset and legal wrapper, a named custodian, a provenance chain and a valuation source. The page's twin of a tokenised fund shows the look-through: senior and mezzanine tranches and an RWA sleeve, each traced down to a reserve, a loan pool, a property or a bond.

For a fund administrator that is look-through on demand. For a depositary it is the custody chain in one model. For an issuer it is the record of who held what, on any date. For a supervisor it is Makhlouf's point drawn as a model instead of described in a memo. To test any of it against your own requirements, contact KXCO.

What to watch

Secondary markets are where tokenisation earns its keep, because a unit that cannot trade is a record and not yet a market. Two global, US-licensed exchanges will add KXCO Armature. They will be announced in late 2026; detail is available under NDA.

On the chain, watch the validator page as node1, node2 and node3 move their attestation keys to ML-DSA-87 after node4. On the rulebook, watch 31 December 2026, the EU roadmap's first milestone for post-quantum pilots, and ESMA's supervisory work on tokenisation from 2027.

Shayne Heffernan, Ph.D., is the founder of Live Trading News, the KnightsBridge Group, Knightsbridge Law and the KXCO.ai ecosystem spanning post-quantum cryptography, identity, attestation and enterprise ontology.