21 Sep 2026

The Token Cannot Have Its Own Reality: What the SEC’s New Stock Rules Reveal About Asset Identity

The US Securities and Exchange Commission has created a five-year conditional exemption allowing limited on-chain trading of tokenised NMS stocks on Tokenized Securities Venues. The conditions make the underlying infrastructure lesson unusually explicit: a tokenised stock must provide the same rights and privileges as the equivalent traditional share, issuers can object to unaffiliated third-party tokenisation, smart contracts must be public and auditable, and trading in the tokenised stock...

Create a structured security-rights record

This starts a temporary private draft. It is not public, listed for sale or shared automatically.

General General Learn

Topics tokenised securities Primary shareholder rights issuer consent market infrastructure settlement asset identity state synchronisation

A stock can be represented on a blockchain.

That does not give the blockchain permission to invent a different stock.

This is the most important infrastructure lesson in the US Securities and Exchange Commission’s new Innovation Exemption.

On 17 September 2026, the SEC granted temporary, conditional relief allowing limited trading of tokenised National Market System stocks on new on-chain venues called Tokenized Securities Venues, or TSVs.

SEC: Innovation Exemption for tokenized NMS stock

The exemption is temporary.

It is conditional.

And its conditions are more interesting than the word token.

The SEC requires rights continuity

A TSV must verify that a tokenised NMS stock provides holders with the same rights and privileges as the equivalent traditional NMS stock.

The SEC explicitly refers to rights such as:

dividends; and
voting rights.

That means the tokenised representation cannot simply track the price of the share.

It must remain connected to the underlying shareholder-rights structure.

The key relationship is:

Underlying share
    ->
Tokenised representation

not:

Share price
    ->
Synthetic token

The token is a representation layer

The underlying security already has an identity.

It has:

an issuer;
a class;
shareholder rights;
an authoritative ownership process;
a primary listing;
corporate actions;
trading status; and
regulatory treatment.

Tokenisation adds another layer:

Issuer
    ->
Security
    ->
Authoritative rights
    ->
Token representation
    ->
On-chain venue

The representation must inherit from the security.

It should not become a parallel source of truth.

“Same rights” is more difficult than it sounds

Suppose the traditional share carries:

voting rights;
dividend rights;
rights in a merger;
tender-offer rights;
rights in a split;
rights in a spin-off;
rights on liquidation; and
information rights.

A tokenised version has to map those events into the digital environment.

The system therefore needs to answer:

Which exact share class does the token represent?

How does a token holder exercise voting rights?

How are dividends passed through?

What happens during a stock split?

What happens if the share is suspended?

A token balance is not enough.

The SEC explicitly rejects synthetic substitution

SEC Chairman Paul Atkins described the exemption as allowing tokenised stocks that are tokenised by or on behalf of the issuer, or by an unaffiliated third party, provided the instrument gives holders the same rights and privileges as the traditional security.

SEC Chairman Atkins: Innovation Exemption statement

The distinction is fundamental:

Tokenised security

is not automatically:

Synthetic exposure to security price

A synthetic instrument can be useful.

But it is a different asset.

The data model should say so.

Issuer objection creates an authority relationship

When an unaffiliated third party tokenises a stock, the TSV must provide written notice to the issuer and give the issuer an opportunity to object.

That adds another relationship:

Underlying issuer
    ->
Third-party tokenisation
    ->
Notice
    ->
Issuer objection / no objection

The issuer may not be the tokenisation provider.

But the issuer still matters.

That makes issuer status part of the tokenised asset record.

A digital representation cannot ignore the primary market state

One of the SEC’s clearest conditions is operational.

A TSV must stop trading a tokenised stock concurrently with a trading stoppage in the underlying NMS stock on the primary listing exchange.

That means:

Underlying trading state
    ->
Tokenised trading state

This is state synchronisation.

The tokenised venue cannot say:

Underlying stock halted
Token market continues normally

The digital representation inherits the market event.

“Representation inherits state” is the key rule

This principle goes beyond trading halts.

A serious tokenised-security architecture should be ready for:

Stock split
Dividend
Merger
Tender offer
Spin-off
Delisting
Suspension
Name change
Ticker change
Rights issue
Record date
Voting event

Each event originates in the underlying security.

The representation has to absorb the consequences.

That is a different problem from minting a token.

Corporate actions need event propagation

Suppose an issuer announces a 2-for-1 stock split.

The underlying security changes.

The tokenised representation needs a corresponding state transition.

A possible lifecycle is:

Issuer corporate action
    ->
Authoritative security record updated
    ->
Entitlement calculated
    ->
Token representation adjusted
    ->
Venue balances reconciled

If any layer fails to update, the digital representation can diverge from the asset.

Dividends expose the rights chain

A shareholder may be entitled to a dividend based on a record date.

For a tokenised stock, the infrastructure may need to connect:

Issuer
    ->
Dividend declaration
    ->
Record date
    ->
Authoritative shareholder entitlement
    ->
Token holder mapping
    ->
Distribution

A wallet balance observed after the record date may not, by itself, prove who had the entitlement at the relevant time.

The history matters.

Voting exposes the same problem

The SEC specifically requires the same rights and privileges, including voting rights.

That creates questions such as:

who receives the proxy material;
how a token holder submits instructions;
which record date controls;
how beneficial ownership is mapped;
whether intermediaries aggregate votes;
how duplicate voting is prevented; and
which system is authoritative.

Again:

Token holder

is not enough.

The rights workflow matters.

Ownership and possession can diverge

A token may sit in a wallet.

That wallet state may represent an entitlement.

But securities markets can contain multiple ownership concepts:

registered owner;
beneficial owner;
custodian;
broker;
nominee;
depository position;
token holder; and
economic beneficiary.

A durable asset model needs to preserve the actual structure.

It should not collapse all of them into:

Owner

Transfer agents remain important

Earlier in September 2026, the SEC separately proposed modernising its transfer-agent rules to reflect electronic and blockchain-based recordkeeping and uncertificated securities.

That is relevant context.

Tokenisation does not eliminate the function of authoritative ownership recordkeeping.

It changes how that function can be implemented.

SEC: Proposed Transfer Agent Rule Modernization

A blockchain can participate in the recordkeeping architecture.

It does not automatically become the legally authoritative register.

The smart contract itself becomes infrastructure evidence

The SEC requires smart contracts used by a TSV to be:

auditable;
public; and
deployed on a public, permissionless distributed ledger.

That creates an unusual source of operational evidence.

An institutional asset record may need to connect:

Security
    ->
Token contract
    ->
Contract version
    ->
Audit
    ->
Deployment
    ->
Venue use

The code becomes part of the provenance chain.

Public code does not mean simple rights

Even if the smart contract is visible, legal rights may still depend on:

offering terms;
venue rules;
transfer-agent records;
custody arrangements;
issuer actions;
investor eligibility;
securities law;
corporate law; and
contractual arrangements.

Code transparency is useful.

It does not eliminate legal interpretation.

Venue state is another separate object

The SEC exemption applies to Tokenized Securities Venues using permissioned automated market makers and liquidity pools.

That means the same tokenised stock can have:

underlying security state;
token state;
holder state;
venue state;
liquidity-pool state; and
settlement state.

Those layers need to stay coordinated.

Permissioned access matters

A public blockchain does not necessarily imply permissionless securities trading.

The SEC framework requires TSVs to set access standards for participants.

The structure can therefore be:

Public blockchain
+
Public smart contract
+
Permissioned participant access

This distinction is easy to lose in generic blockchain descriptions.

The network and the market-access regime are different properties.

Trading limits create another market-state field

The SEC exemption imposes limits on the number of symbols and trading volume.

That means a tokenised security can be technically available on a venue while regulatory conditions constrain how much activity may occur.

A structured venue record could include:

permitted symbol;
volume cap;
access status;
suspension;
underlying halt;
venue notice;
current liquidity pool;
reporting state; and
exemption eligibility.

Settlement is not just a blockchain transaction

A token transfer can be technically final on a distributed ledger.

The broader securities transaction may still depend on:

payment;
legal settlement rules;
participant obligations;
recordkeeping;
reconciliation;
corporate-action entitlement;
custody;
regulatory reporting; and
error handling.

The token transaction is one settlement event.

It may not be the whole legal settlement story.

Tokenisation creates a reconciliation obligation

When a security has both traditional and tokenised forms, the system needs to prevent divergence.

Relevant reconciliations may include:

Token supply
vs
Underlying authorised position

Token holder records
vs
Authoritative ownership records

Corporate-action entitlement
vs
Token distribution

Trading status
vs
Primary-exchange status

The value of the representation depends on this continuity.

A tokenised security needs two histories

The underlying security has its own lifecycle.

The token representation has another.

For example:

Underlying:
Issue
-> Trade
-> Dividend
-> Split
-> Halt
-> Resume
-> Merger

while the token may have:

Mint
-> Transfer
-> Lock
-> Burn
-> Remint

The histories need to connect.

A single event log is not enough.

The primary security identifier should remain visible

A token contract address is useful.

It should not replace the underlying security identifier.

A structured record may need:

Issuer
Security class
CUSIP / ISIN / other authoritative identifier
Exchange / listing
Token contract
Network
Token symbol
Venue

The token identifier tells us which representation is being used.

The security identifier tells us what is being represented.

Corporate-action mismatch is a material risk

Suppose the underlying share is subject to a tender offer.

A token holder may need to choose whether to participate.

If the token system cannot pass that right through, the representation is no longer economically equivalent.

Likewise, if the underlying share is delisted but the token continues to appear as a normally trading asset, the digital state has broken away from reality.

The infrastructure should detect these mismatches.

Issuer consent and token lifecycle need history

An issuer may:

receive notice;
not object;
later raise concerns;
change corporate structure;
merge;
delist; or
cease to exist.

The token record should therefore preserve issuer-related events over time.

A single boolean such as:

Issuer approved: Yes

may be misleading.

The exact SEC framework is based on notice and opportunity to object for relevant third-party tokenisations.

The data model should preserve what actually happened.

A tokenised-security Asset Passport should connect the layers

Underlying security

issuer;
legal entity identifier;
security class;
authoritative identifier;
primary listing exchange;
ticker;
voting rights;
dividend rights;
other shareholder rights;
current trading status; and
corporate-action history.

Authoritative ownership

transfer agent;
depository;
registered owner;
beneficial-owner structure;
custody chain;
record date;
position source;
reconciliation date; and
current authoritative state.

Token representation

token issuer;
issuer relationship;
token contract;
network;
contract version;
deployment address;
token symbol;
token supply;
minting rules;
burning rules;
transfer restrictions; and
current token state.

Rights mapping

underlying right;
token-holder equivalent right;
dividend mechanism;
voting mechanism;
corporate-action mechanism;
redemption or conversion;
settlement mechanism;
exceptions; and
evidence.

Issuer notice

tokenisation provider;
unaffiliated-party status;
notice date;
notice recipient;
objection period;
issuer response;
objection;
effective status; and
source.

Venue

TSV;
access rules;
permissioned participants;
AMM or liquidity pool;
symbol limit;
volume limit;
trading state;
halt state;
public notice;
transaction-data reporting; and
exemption status.

State synchronisation

underlying halt;
token halt;
halt timestamp;
resume timestamp;
corporate action;
token adjustment;
reconciliation;
exception;
unresolved mismatch; and
reviewer.

Provenance

issuer filing;
exchange notice;
transfer-agent record;
SEC order;
venue disclosure;
smart-contract source;
smart-contract audit;
blockchain transaction;
reconciliation report;
timestamp;
version; and
reviewer.

A mismatch should be a first-class state

A good system should be able to say:

Underlying state: Halted
Token state: Trading
Mismatch: Critical

or:

Dividend entitlement: Declared
Token pass-through: Pending

or:

Issuer notice: Sent
Objection period: Open

The system should not hide operational disagreement behind a green status icon.

AI can monitor synchronisation but should not invent shareholder rights

AI can help:

extract corporate actions;
map issuer filings to token contracts;
detect trading-halt mismatches;
compare token supply with authoritative positions;
identify dividend dates;
compare shareholder-right descriptions;
classify transfer restrictions;
flag stale issuer notices;
monitor smart-contract version changes; and
create a timeline of underlying and token events.

AI should not independently decide:

that a token provides legally equivalent shareholder rights;
who is the legal owner;
whether an issuer has validly objected;
whether a transfer is legally final;
whether a venue satisfies the exemption;
whether a corporate action was correctly implemented;
whether a smart contract is legally enforceable; or
whether a token is suitable for an investor.

Those require authoritative records, legal analysis and regulated market processes.

What DaDepo can contribute

DaDepo does not need to operate a tokenised exchange.

The useful role is to preserve continuity between the asset and its representation.

A security Asset Passport can connect:

Issuer
    ->
Underlying security
    ->
Authoritative rights
    ->
Ownership record
    ->
Token representation
    ->
Venue
    ->
Trading state
    ->
Settlement
    ->
Corporate actions

That makes it easier to ask:

what exact security is represented;
what rights the token is supposed to preserve;
where authoritative ownership is recorded;
who created the token;
whether the issuer was notified;
whether the token is currently tradeable;
whether the underlying stock is halted;
whether a corporate action has propagated; and
which evidence supports each state.

The Asset Passport should not replace the market infrastructure.

It should make the relationships visible.

What DaDepo does—and does not do

Creating or reviewing a tokenised-security Asset Passport does not mean that DaDepo has:

issued stock;
tokenised a security;
acted as transfer agent;
maintained the shareholder register;
acted as depository;
provided custody;
operated a TSV or exchange;
provided a liquidity pool;
acted as broker or dealer;
verified regulatory exemption eligibility;
determined shareholder rights;
processed corporate actions;
settled a securities transaction;
determined settlement finality;
guaranteed token-to-security reconciliation;
provided investment advice; or
provided legal, regulatory, tax, accounting, brokerage, custody, clearing, settlement or valuation advice.

Important: DaDepo provides technology and information tools. It does not provide securities issuance, tokenisation, transfer agency, depository, custody, exchange, brokerage, dealing, clearing, settlement, legal, regulatory, tax, accounting, investment or valuation advice or services unless a specific service is expressly identified and lawfully provided. Security ownership, shareholder rights, token equivalence, issuer rights, settlement and regulatory treatment depend on authoritative market infrastructure, governing documents, applicable law and qualified professional review.

A practical tokenised-security checklist

Underlying security: Which exact traditional security is represented?
Issuer: Which legal entity issued it?
Class: Which share class or security class applies?
Identifier: Which authoritative identifier anchors the asset?
Primary market: Where is the underlying security listed or recorded?
Rights: Which dividends, voting and other rights attach to it?
Ownership: Where is authoritative ownership recorded?
Token issuer: Who created the representation?
Token contract: Which smart contract defines it?
Network: On which ledger is it deployed?
Rights equivalence: How are underlying rights passed to token holders?
Issuer notice: Was the issuer notified where required?
Issuer objection: Is any objection active?
Supply: How is token supply reconciled with the underlying position?
Transfer: What legal effect does an on-chain transfer have?
Access: Who is permitted to trade?
Venue: Which TSV or other venue is used?
Trading status: Is the underlying stock trading?
Token trading status: Is the tokenised representation trading?
Halt synchronisation: Do the two states match?
Corporate actions: How are splits, dividends and mergers propagated?
Record dates: Which system determines entitlement?
Voting: How are voting instructions transmitted?
Settlement: Which events establish completion?
Reconciliation: When were token and authoritative records last compared?
Smart-contract audit: Which audit exists and which version did it cover?
Regulatory basis: Which exemption, registration or rule applies?
Provenance: Can every right and state be traced to a source and timestamp?

If the answer to “does this token still represent the same rights and current state as the underlying security?” is unclear, the tokenised asset record is incomplete.

The broader lesson goes beyond equities

The same continuity problem appears in:

tokenised bonds;
tokenised funds;
tokenised money-market instruments;
tokenised private credit;
tokenised receivables;
tokenised commodities; and
other digitally represented real-world assets.

The representation can use a new rail.

The asset still has an authoritative identity and rights structure.