Tokenized Stock Trading Starts Now. Its Records Must Outlive the Signature.

Tokenized stock trading in the United States is arriving all at once. DTCC switches on its tokenization service this month, Nasdaq has approval to trade tokenized shares on its own order book, and the SEC has opened a five-year path for new venues to trade them on public blockchains. The public worry about quantum computers is whether blockchains survive them, and that problem has years to be solved. A different problem does not. Systems that decide who may trade on these rails need evidence of what was checked and when, some of those records must stay trustworthy for years, and the signature on each one is chosen on the day it is made. For every system being built today, that day has already arrived.

Who is going live

DTCC, this month. On July 15 DTCC processed real production trades using tokenized assets held in its custody, and said they "set the stage for the DTCC Tokenization Service to launch in October 2026." The service covers the Russell 1000, ETFs tracking major indices, and U.S. Treasuries, delivered to participant wallets of choice. More than 50 firms are in the working group, and the SEC authorized the service in a no-action letter in December 2025.

Nasdaq. On March 18 the SEC approved a Nasdaq rule change that lets member firms trade eligible stocks and ETFs in tokenized form on the same order book as traditional shares, with settlement through DTCC.

New venues. On September 17 the SEC granted a five-year exemption that lets Tokenized Securities Venues trade tokenized stocks on public blockchains. Each venue must set standards for who may trade, with allow-listing approved wallet addresses described as one way to enforce them. Coinbase and Robinhood are among the firms reported to be interested.

These are the ones with dates. Others will follow. What they share is the part that matters here: tokenized shares that move to wallets, and firms that must decide, trade by trade, which wallets may take them, and may need to prove later that they did.

The question everyone is asking, and the one nobody is

The quantum debate in crypto is about the chains. Bitcoin, Ethereum and the rest sign transactions with ECDSA, a signature scheme that a large enough quantum computer is expected to break. The worry is real, and it is also a migration problem: protocols can adopt new signature schemes, and holders can move to new addresses before the machine arrives. A chain can fix its future.

A record cannot fix its past. When a broker, venue or transfer agent checks that a wallet was eligible before a trade, the evidence of that check is a signed statement, and it is signed once. If ECDSA is the record's only cryptographic evidence of authenticity, then once ECDSA can be forged, that signature alone can no longer tell the original from a forgery. As we put it to the SEC's Crypto Task Force last week: once a signature algorithm can be broken, a signature made with it can no longer show that a record existed when it claims to. Nobody can repair that after the fact by re-signing old records, because whoever re-signs is asking to be trusted about the past, which is the one thing a signature was supposed to remove.

The arithmetic is already here

NIST's draft transition plan (NIST IR 8547) lists ECDSA as "Disallowed after 2035" because it is expected to be vulnerable to quantum computers. Line that up against how long the rules make firms keep records.

• Customer identification. A broker-dealer keeps a customer's identifying information for five years after the account is closed (31 CFR 1023.220). An account opened this month and held for more than four years has records that must be kept past 2035.
• Derivatives. Most CFTC records are kept for at least five years, and swap records for five years after the swap ends (Rule 1.31). A record made in 2031 must be kept until 2036; a long-dated swap's records, far longer.
• Disputes. Litigation holds and examinations run on their own clocks, and they are exactly when a record has to prove itself.

And 2035 is a policy date, not a forecast. Nobody knows when a machine that breaks ECDSA will exist, which is why the safe assumption for a record is that it must outlive the signature scheme it was born with.

Why this month and not 2030

Because the signature is chosen when the system is built, not when the threat arrives. The eligibility checks behind these launches are being wired as you read this, and every record those systems write will carry whatever signature they were built with, every trade, every day, for as long as the system runs. Financial plumbing is rarely re-plumbed. A venue that launches with classical-only records will be writing them in 2030, and its records from 2030 will still be kept past 2035.

There are ways to rescue old records later, such as re-timestamping an archive under a newer scheme before the old one falls. They cost money, they depend on someone remembering to do it in time, and they are a migration project on top of a compliance obligation. The cheap moment to make a record durable is the moment it is signed. For tokenized securities in the United States, that moment starts now.

What we built

Every attestation InsumerAPI returns carries two signatures over the same statement:

• ECDSA (P-256), the signature every existing verifier checks today, under the key IDs insumer-attest-v2 and insumer-trust-v2.
• ML-DSA-65, the post-quantum signature NIST standardized in FIPS 204, as a companion under insumer-attest-pq1 and insumer-trust-pq1.

The companion is additive: the classical signature is unchanged, so every integration that checks it today keeps working, and a verifier that supports ML-DSA checks both. NIST's draft treats a post-quantum signature paired with a classical one as a supported way through the transition. The two public keys are bound to each other in a signed statement whose digest was recorded on Base at block 50758053 on September 1, 2026, and the binding is published at /.well-known/pq-key-binding.json. Keys are never removed from our published key set, so a record stays checkable for as long as it is kept, offline, with the open-source insumer-verify on npm or PyPI and no call back to us.

What each record says is narrow on purpose: whether a wallet met the venue's condition at a stated moment, yes or no, without the wallet's balances or the owner's identity. The venue sets the condition and makes the decision; the record proves the check ran. This is a statement about architecture, not a guarantee about cryptography: no one can promise what any algorithm will withstand in 2040, but a record with a second, independent signature under the published post-quantum standard does not depend on ECDSA alone.

What we told the regulators

We put this on the record with both agencies last month.

• SEC Crypto Task Force, September 25. Evidence of a verification should remain verifiable for as long as it must be kept, and "the signature or proof system behind a retained record should be expected to remain secure for its retention period." Read it on sec.gov.
• CFTC Innovation Task Force, September 25. A section titled "How long the signature must last," on Rule 1.31 retention against NIST's 2035 date, and signing under FIPS 204 alone or alongside a classical signature. Read our copy; the CFTC had not posted it when we published.
• SEC, September 17 (File No. 4-927). On the tokenized stock exemption: check a wallet's eligibility at the trade, not only at signup, and keep a signed record of each decision. Read it on sec.gov.

The full set, and what each one asked, is in What We Told the SEC and CFTC About Proving Eligibility.

Four questions to ask before you go live

1. What signs the record of each eligibility check? If the answer is ECDSA alone, the record depends on an algorithm NIST already plans to disallow after 2035.
2. How long must that record be kept, and does the signature last that long? Count from the latest record the system will ever write, not the first.
3. Can it be verified without the vendor? Published keys that are never withdrawn, and a verifier you can run yourself, years from now.
4. Does the record carry the answer, or the data? A yes or no against your stated condition is easier to keep, and safer to hold, than a copy of someone's portfolio.

The chains have time to fix their signatures. The records written from this month on do not. They get one chance to establish their authenticity, on the day they are made.

Our interest, stated plainly: we operate InsumerAPI, which checks whether a wallet meets a condition and returns a signed yes or no, and we sell that service.