Tokenising a Share in Code: the Register Entry, the Credential and 4 Checks

The SEC wrote the data model down

Tokenising a share is a record-keeping job, and the SEC has now said which record. The staff statement of 28 January 2026 describes an issuer that "integrates DLT into the systems that it uses to record owners of the security". On chain it keeps the "wallet address, quantity of security owned, and issue date". Off chain it keeps the "security holder name and address".

The Innovation Exemption of 17 September 2026, Release No. 34-106402, adds the tests a venue runs against that record:

• Only permissioned participants reach trading. The order's own example of enforcing that is a pool open only to "wallet addresses that meet certain credentialing requirements".

• "A TSV must verify that the Tokenized NMS Stock made available for trading on the TSV provides holders the same rights and privileges as does traditional NMS stock of an equivalent class." The first right it names is "a right to receive the same dividends that the company issues to holders of the underlying NMS stock".

So the engineering problem is four records and a check on each: the register entry, its signature, the credential on the wallet, and the holdings as at a record date. This note builds all four in JavaScript against kxco-post-quantum 1.7.7 from npm and the live Armature L1 RPC. Every block below ran on 30 September 2026, and Exhibit 1 is what each one returned.

Exhibit 1. Each result is the line its code block printed when it ran. The figure refuses to build if that line is not in the captured output.

1. The register entry, signed by the registrar

The registrar is whoever keeps the master securityholder file: the issuer, or its agent. It signs every entry with ML-DSA-65, the NIST FIPS 204 signature.

import { mlDsa, jws, fingerprint } from 'kxco-post-quantum'

const master = crypto.getRandomValues(new Uint8Array(32))   // in production: from your KMS
const registrar = mlDsa.keypairFromMaster(master, 'register-signing-v1')

// the on-chain half of the entry: wallet, quantity, issue date
const entry = {
  shareClass: 'EXAMPLE-ORD',
  event: 'issue',
  seq: 1,
  wallet: '0x5a1c8f0e2b7d4c3a9e6f1b0d8c7a2e4f6b3d9a10',
  quantity: '1000',            // a string: a register never holds a float
  issueDate: '2026-10-01',
  holder: 'cred:holder-0001',  // the off-chain half is reached through a credential
}

const canon = (o) => JSON.stringify(Object.fromEntries(Object.entries(o).sort(([a], [b]) => a.localeCompare(b))))
const sig = mlDsa.sign(registrar.secretKey, canon(entry))

• The quantity is a string. A share count that passes through a float is a register that can disagree with itself.

• The holder is a reference, not a name. The name and address stay in the off-chain half, which is where the staff statement puts them, and they reach the entry through the credential in block 4.

• The bytes are canonical. Keys are sorted before signing, so any verifier rebuilds identical bytes from the same entry, whatever order it received the fields in.

• The sizes are fixed by the standard. The test file asserts a 1,952-byte public key and a 3,309-byte signature, the ML-DSA-65 sizes per FIPS 204 Table 2.

2. A stranger checks it, with the public key and nothing else

mlDsa.verify(registrar.publicKey, canon(entry), sig)                           // true
mlDsa.verify(registrar.publicKey, canon({ ...entry, quantity: '10000' }), sig)  // false

block 2 ok: the entry verifies; a changed quantity does not

This is the property KXCO designs for: "anyone can verify a proof with a published public key and the record. No account, no allowlist, no API key", per KXCO's published architecture. An auditor, a venue or a holder runs the same two lines.

3. The same check on Armature L1, at precompile 0x0b

Armature L1 checks ML-DSA-65 signatures itself, at the precompile address 0x0b. Any caller can ask it through a read-only eth_call, which costs nothing and writes nothing.

const RPC = 'https://chain.kxco.ai/rpc'
const hex = (b) => Buffer.from(b).toString('hex')

async function checkOnChain(publicKey, message, signature) {
  const data = '0x' + hex(publicKey) + signature + hex(new TextEncoder().encode(message))
  const res = await fetch(RPC, {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'eth_call',
      params: [{ to: '0x000000000000000000000000000000000000000b', data }, 'latest'] }),
  })
  return BigInt((await res.json()).result) === 1n
}

await checkOnChain(registrar.publicKey, canon(entry), sig)                           // true
await checkOnChain(registrar.publicKey, canon({ ...entry, quantity: '10000' }), sig)  // false

block 3 ok: 0x0b returns 1 for the entry, 0 for a changed quantity, 0 for a context-signed entry

• The input is raw bytes. Public key, then signature, then message, concatenated. There is no function selector and no ABI encoding. The answer is a 32-byte word ending in 1 or 0.

• One trap, measured. FIPS 204 lets a signer bind a context string, and kxco-post-quantum takes one as { context }. Address 0x0b checks a signature made with an empty context. An entry signed under { context: 'register-v1' } verifies off chain with the same context and returns 0 at 0x0b. Separate purposes by key label, as block 1 does with 'register-signing-v1', and leave the context empty on anything meant for the chain.

• The chain, as measured on 30 September 2026. Chain ID 1111111, client besu/kxco-observer/v26.6, 4 validators returned by qbft_getValidatorsByBlockNumber, and a block every 2 seconds across the 1,000 blocks to that date, per the public RPC at chain.kxco.ai/rpc.

The same signature is checked in the same way on chain and off it. The proof does not depend on where the token trades. KXCO's own platform runs its verification "off chain in the relay with on-chain anchoring", per its published architecture. Address 0x0b is the independent check: anyone can run it against the public RPC, with no account.

4. The credential, and the transfer check that reads it

The order admits only permissioned participants, and leaves the bar to the venue: a TSV "sets standards to allow only permissioned TSV Participants to access trading". A credential here is a compact JWS signed with ML-DSA-65 by the institution that verified the holder, binding one wallet to one holder reference.

const institution = mlDsa.keypairFromMaster(master, 'credential-issuing-v1')

const credential = jws.signJws(
  { sub: 'cred:holder-0001', wallet: entry.wallet, role: 'holder', exp: Date.parse('2027-10-01') / 1000 },
  institution.secretKey,
  { kid: fingerprint(institution.publicKey) },
)

function mayReceive(wallet, token, now = Date.now() / 1000) {
  const r = jws.verifyJws(token, institution.publicKey, { alg: 'ML-DSA-65' })
  if (!r.valid) return false
  const c = JSON.parse(r.text)
  return c.wallet === wallet && c.role === 'holder' && c.exp > now
}

mayReceive(entry.wallet, credential)                                    // true
mayReceive('0x000000000000000000000000000000000000dead', credential)  // false
mayReceive(entry.wallet, credential, Date.parse('2027-11-01') / 1000)   // false, expired

block 4 ok: a credentialed wallet may receive; another wallet, an expired credential and a forged one may not

• The algorithm is pinned at the verifier. verifyJws is told ML-DSA-65, and never reads the algorithm from the token it is checking.

• A forged credential fails. The test file swaps in a payload naming another wallet under the original signature, and mayReceive refuses it.

• The check runs before the transfer. It is the gate a venue or transfer agent applies before an entry is written. KXCO builds to the same order of events: "there is no code path from an unverified party to a held position".

In production the credential comes from KXCO: "Credential issuance is live, with hierarchical ML-DSA-65 credentials issued under a dedicated institution key held on the operating host".

5. The dividend, from the register as at the record date

"The same dividends" means the token holder is paid exactly what a holder of the traditional share is paid. That is a replay of the register to the record date, then an exact split.

const events = [
  { seq: 1, date: '2026-10-01', event: 'issue', to: 'A', quantity: 1000n },
  { seq: 2, date: '2026-10-01', event: 'issue', to: 'B', quantity: 500n },
  { seq: 3, date: '2026-11-20', event: 'transfer', from: 'A', to: 'B', quantity: 200n },
]

function holdingsAt(recordDate) {
  const h = {}
  for (const e of events.filter((e) => e.date <= recordDate).sort((a, b) => a.seq - b.seq)) {
    if (e.from) h[e.from] -= e.quantity
    h[e.to] = (h[e.to] ?? 0n) + e.quantity
  }
  return h
}

function dividend(totalCents, recordDate) {
  const h = holdingsAt(recordDate)
  const shares = Object.values(h).reduce((a, b) => a + b, 0n)
  const rows = Object.entries(h).sort(([a], [b]) => a.localeCompare(b))
    .map(([holder, q]) => ({ holder, cents: (totalCents * q) / shares, rem: (totalCents * q) % shares }))
  let left = totalCents - rows.reduce((a, r) => a + r.cents, 0n)
  for (const r of [...rows].sort((a, b) => (b.rem > a.rem ? 1 : b.rem < a.rem ? -1 : 0))) {
    if (left-- > 0n) r.cents += 1n
  }
  return Object.fromEntries(rows.map((r) => [r.holder, r.cents]))
}

dividend(123457n, '2026-11-15')   // { A: 82305n, B: 41152n }, the transfer on 20 Nov does not move it

block 5 ok: record date 15 Nov pays A 823.05 and B 411.52, which sum to 1,234.57

• Money is whole cents in a BigInt. No float touches the amount at any step.

• The parts sum to the whole. Each holder takes the floor of their share, and the cents left over go to the largest remainders, so 1,234.57 is paid as 1,234.57, per the output of block 5.

• Order comes from the record, not the database. Holders are sorted by identity before the split, so two runs pay the same cent to the same holder whatever order the rows were read in.

• The record date holds. A's transfer of 200 shares on 20 November leaves the 15 November entitlement untouched, and the test file asserts both dates.

Votes and liquidation shares are the same replay with a different function at the end.

6. Where the register goes next: a tokenised-asset exchange

A listing on a tokenised-asset exchange is an admission file, and the blocks above are what goes in it. Each venue asks for the record in its own words:

• The register, and whose it is. tZERO serves "issuers looking to digitize their capital table through blockchain technology". ADDX runs "checks on the legitimacy of issuers in accordance with our Listing Rules". Block 1 is the signed entry, and block 2 is the check the venue can run with the public key alone.

• The holders, and whether they may hold. A TSV admits "only permissioned TSV Participants", and ADDX admits accredited and institutional investors. Block 4 is the credential and the gate that reads it.

• Corporate actions. The Bank of England's Digital Securities Sandbox wants firms to "demonstrate how they will reflect corporate action events (such as share buybacks) in the tokenised securities holdings". Block 5 is that replay.

• The proof, on any chain. 21X runs issuance "through to listing and trading, all on a single platform", per its site on 30 September 2026, and says it operates "across multiple public chains under EU regulation". A TSV's contracts sit on "a public, permissionless distributed ledger". An ML-DSA-65 signature verifies off chain with the public key, so block 3's check does not depend on which chain the venue uses.

Two limits decide the route before any code runs. A TSV lists nobody: "No primary issuance or initial offerings of securities are permitted on a TSV under the TSV Exemption", so a US share needs its exchange listing first. In the EU, "Article 3 of DLTR caps equity instruments at a EUR 500 million in market capitalisation", per ESMA. Knightsbridge advises issuers on which route fits.

What KXCO runs underneath this

The blocks above are the checks. What an issuer needs in production is the record they run against, kept by a licensed operator. KXCO is not a TSV and does not run one. It builds and runs that record layer:

• The register: "effective-dated capital tables, allocations that reconcile exactly or refuse", in production per KXCO's published architecture.

• Rights at a date: "capital calls split as at the call date, value-dated payments, waterfall distributions", and in KXCO Meridian, "Capital calls, distributions, cap table entries and valuations then run off the same record".

• The claims: in Round Table, the KXCO ontology, "Every edge carries its own source, basis, confidence and the date it was true".

• The chain: "Selective on-chain attestation is live, opt-in per organisation and per event type", on Armature L1, which "runs as a permissioned QBFT chain with named validators and post-quantum signing from genesis".

• The operator: the transfer agent, broker-dealer or custodian runs it on its own licence, and can deploy it under its own name. KXCO is a software company, and "KXCO never takes custody of customer assets or funds".

Write to [email protected] with your share class and where it trades, or start at kxco.ai/contact.

What to watch

DTCC's Tokenization Service is due to launch in October 2026, per its release of 15 July. Under Release No. 34-106402, "at least 30 calendar days before operating, a TSV must publish a copy of a notice". Each notice has to describe how the venue approves wallets and which stocks it lists. Those notices will show what the first venues expect a register and a credential to answer.

Sources

SEC Statement on Tokenized Securities, 28 January 2026. SEC Release No. 34-106402, 17 September 2026. DTCC press release, 15 July 2026. NIST FIPS 204, August 2024. kxco-post-quantum 1.7.7 from the npm registry, and https://chain.kxco.ai/rpc, chain ID 1111111, run on 30 September 2026 with Node 26.1.0. KXCO: the developer blog of 19 August 2026, kxco.ai/meridian, kxco.ai/ontology and kxco.ai/treasury, read 30 September 2026.

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.

This note is commentary. It is not legal advice. Code is shown as it ran on the versions named, with example data; a production register needs its keys in a KMS and its operator on a licence.