30 Aug 2026

Tokenisation Is Becoming Market Infrastructure, Not a Digital Wrapper

India’s reported first tokenised corporate-bond pilot connects issuance, securities ownership, wholesale-CBDC payment and a planned secondary market inside one new infrastructure stack. The important lesson is not that a bond can be represented on a blockchain. It is that tokenisation starts to matter when the securities register, cash leg, participant access, settlement finality and asset lifecycle are designed together.

Create a structured bond record

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

Asset manager Learn

For years, tokenisation has been described as a new wrapper for an old asset.

Take a bond.

Create a digital token representing it.

Put the token on a blockchain.

Call the result a tokenised bond.

That description is becoming too shallow.

On 24 August 2026, Reuters reported that India is preparing its first tokenised corporate-bond issuance for September. State-owned power financier REC is expected to issue less than ₹5 billion, or roughly $57 million, in a pilot involving India’s central bank and securities regulator. Investors would reportedly use two digital accounts: a wholesale central-bank-digital-currency wallet for the cash leg and a new DEMAT 2.0 securities wallet being developed by Indian depositories for the bond leg. Secondary trading is expected to follow in December after an initial three-month lock-in. Reuters: India plans first tokenised bond issue in September

The details remain important to qualify.

Reuters attributed the plan to sources familiar with ongoing discussions. RBI, SEBI, REC, NSDL and CDSL had not publicly confirmed the reported framework at the time of the report.

But the direction is not coming from nowhere.

In May 2026, SEBI publicly said it was examining the potential for bond tokenisation, particularly around online bond platforms, with the aim of improving accessibility, transparency and efficiency in the bond market. SEBI: Speaking Notes at the 25th FIMMDA–PDAI Annual Conference

India has also been operating a wholesale digital-rupee pilot since 2022. RBI’s first use case was settlement of secondary-market transactions in government securities, and later wholesale-CBDC use cases expanded to interbank lending and borrowing. RBI has described wholesale CBDC as infrastructure intended to improve the efficiency and security of wholesale settlement and reduce settlement risk. RBI: Operationalisation of CBDC-Wholesale Pilot RBI: Digital Rupee FAQs

The reported REC pilot therefore matters for a reason that has little to do with whether the bond has a token icon.

India is reportedly trying to connect the security, the ownership record, the payment asset and the secondary-market workflow inside one coordinated infrastructure.

That is much closer to market redesign than document digitisation.

The important innovation is the stack, not the token

A conventional bond transaction already contains several systems.

There is:

an issuer;
an instrument and its legal terms;
an issuance process;
investor eligibility;
a securities account;
a depository or registry;
a trading venue or bilateral execution process;
a cash account;
clearing where relevant;
settlement;
custody;
corporate actions;
coupon payments;
maturity or redemption; and
regulatory reporting.

The bond itself is only one object inside that stack.

If the bond is tokenised but everything else remains disconnected, the market may simply create another reconciliation problem.

The token says one thing.

The depository says another.

The bank account says something else.

The trading venue maintains its own order and execution records.

The issuer maintains another register.

Operations teams then spend their time proving that all of those systems refer to the same transaction.

That is not transformation.

It is another database.

The reported Indian architecture is interesting because the experiment appears to go further.

The securities side would have a dedicated digital wallet.

The cash side would use wholesale central-bank money.

Subsequent transfers would reportedly require compatible securities and CBDC wallets.

And the secondary market would be built specifically for the new form rather than routed through the conventional electronic book-provider platform.

In simplified form:

Bond issuance
    ->
DEMAT 2.0 securities record
    ->
Investor securities wallet
    <->
Wholesale CBDC wallet
    ->
Delivery-versus-payment settlement
    ->
Secondary transfer
    ->
Updated ownership record

That is not merely a digital certificate.

It is an attempt to make the bond an executable market object.

Tokenisation is different from dematerialisation

India already has dematerialised securities.

That distinction matters.

A paper share or bond certificate can be replaced by an electronic book-entry record without requiring blockchain or tokenisation.

Depositories have been doing that for decades.

India’s Depositories Act framework, as summarised by NSDL, already distinguishes between the depository as the registered owner for purposes of effecting transfers and the investor as the beneficial owner entitled to the rights and benefits of the securities. NSDL: Capital Markets and NSDL Overview

So the question is not:

Can a bond exist without paper?

It already can.

The more difficult questions are:

Can issuance be represented in a programmable state?
Can ownership transfer update without multiple manual reconciliations?
Can payment and delivery execute conditionally against each other?
Can the new record coexist with the legal depository framework?
Can the secondary market use the same authoritative asset identity?
Can corporate actions follow the same lifecycle?
Can regulators and market operators see the evidence they need?

Tokenisation becomes meaningful when it changes how those functions interact.

Otherwise, the market has simply changed the database technology underneath an existing process.

The securities wallet is potentially more important than the blockchain label

The reported DEMAT 2.0 wallet deserves more attention than the phrase “tokenised bond”.

A securities wallet is not useful simply because it contains a cryptographic balance.

A real market needs to know what that balance means.

Suppose a wallet displays:

REC Tokenised Bond
Quantity: 10,000

That creates several questions.

Who is the legal investor?

Is the wallet holder the beneficial owner?

Is the wallet itself merely a technical interface to a depository record?

Which record prevails if the wallet state and another registry disagree?

Can a participant lose access to the wallet without losing the legal entitlement?

Can the depository reverse or correct an erroneous state?

How are court orders, freezes, pledges and succession handled?

What happens if keys are compromised?

How are beneficial-owner details reconciled with KYC records?

Can the same investor hold conventional and tokenised positions in the same security class?

The legal answer cannot be inferred from the cryptography.

A wallet is a control interface.

Ownership is a legal and market-infrastructure state.

The two can be tightly connected.

They should not be silently treated as the same thing.

The cash leg is where many tokenisation experiments become real

A securities trade contains two promises.

The seller promises to deliver the asset.

The buyer promises to pay.

If those events happen separately, principal risk can arise.

The seller may deliver but not receive cash.

The buyer may pay but not receive the security.

Delivery versus payment—DvP—links the two sides so that delivery occurs if and only if payment occurs.

The Bank for International Settlements has repeatedly identified DvP as a central use case for tokenised financial infrastructure. It has also highlighted the benefit of bringing central-bank money and tokenised assets into coordinated settlement arrangements. BIS: Tokenisation for the real world BIS: The next-generation monetary and financial system

That is why the reported use of India’s wholesale CBDC matters.

A tokenised security paid for through an ordinary external bank-payment process may still require:

payment messaging;
confirmation;
reconciliation;
settlement coordination;
intraday credit arrangements; and
exception handling between separate systems.

A wholesale-CBDC cash leg can potentially make the payment itself part of the executable settlement process.

The conceptual model becomes:

IF securities delivery is valid
AND cash is available
AND both participants are eligible
THEN transfer security and cash together
ELSE do not settle

That is a much stronger proposition than:

Transfer token now
Reconcile payment later

Instant settlement removes one risk and can increase another requirement

The phrase instant settlement sounds universally beneficial.

It is more complicated.

Shortening the time between trade and settlement can reduce counterparty exposure and reconciliation risk.

It can also reduce the opportunity to net obligations.

If every transaction settles individually and immediately, a buyer may need cash at the exact moment of execution and a seller may need the security available at the exact moment of sale.

That can increase the importance of intraday liquidity and inventory management.

The BIS has noted this trade-off in analysis of tokenised securities settlement: moving toward transaction-by-transaction DvP can reduce principal risk but may increase liquidity needs compared with netted settlement arrangements. BIS: On the future of securities settlement

So tokenisation does not eliminate market design.

It changes the questions.

A market moving from T+1 or another deferred cycle toward near-instant settlement needs to consider:

prefunding;
liquidity buffers;
securities availability;
failed transactions;
cut-off rules;
collateral mobility;
queue management;
participant limits;
operational outages; and
how exceptions are unwound.

The ledger can execute quickly.

The market still needs rules for when it should execute at all.

Settlement finality is not the same as database immutability

Blockchain discussions often use the word final loosely.

A transaction can be technically difficult to reverse.

That does not automatically make it legally final.

Legal finality depends on the governing framework.

A market needs to know:

when the transfer becomes legally effective;
whether a later insolvency can affect it;
which system record is authoritative;
what happens after fraud;
how erroneous transfers are handled;
whether a court or regulator can freeze or reverse an interest;
whether a transaction can be cancelled before finality; and
whether different systems recognise the same moment of completion.

This distinction is fundamental.

A distributed ledger can produce strong evidence that a state transition occurred.

The law determines what that state transition means.

That is one reason regulated depositories remain important in tokenised-market design.

The technology does not remove the need for an authoritative legal framework.

It makes the mapping between technical state and legal state more important.

The depository is not necessarily being disintermediated

Many early tokenisation narratives imagined that distributed ledgers would remove central securities depositories.

The reported Indian model points in another direction.

Indian depositories are reportedly developing the new securities wallet.

If that design proceeds, the depository does not disappear.

It becomes part of the tokenised architecture.

That is significant.

A depository already performs functions that a serious securities market cannot ignore:

maintaining book-entry records;
supporting ownership transfers;
connecting issuers and intermediaries;
managing participant access;
supporting corporate actions;
imposing operating rules;
reconciling positions; and
providing an authoritative market record within the legal framework.

Putting some of those functions on DLT does not make governance unnecessary.

It may make governance more explicit.

Someone still decides:

who can write to the ledger;
who can validate state changes;
which identities correspond to accounts;
how errors are corrected;
how forks or inconsistent states are prevented;
what happens during outages;
who administers upgrades;
how records are retained; and
which party bears responsibility for operational failures.

A permissioned securities ledger is still market infrastructure.

The word distributed does not mean ungoverned.

Participant access becomes part of the settlement model

Reuters reported that subsequent trades would require participants to hold both compatible CBDC and securities wallets.

That sounds like a technical detail.

It is actually a market-structure rule.

Access determines who can participate.

A traditional bond market may separate:

trading access;
clearing membership;
settlement-bank access;
custody access; and
beneficial ownership.

A tokenised market can recombine some of those roles.

That raises practical questions.

Can an asset manager participate directly?

Must it act through a bank?

Can a custodian hold the wallet while the fund remains beneficial owner?

Can foreign investors obtain compatible settlement access?

Can brokers submit trades without controlling settlement wallets?

Can one institution sponsor access for another?

How are AML, sanctions, KYC and eligibility controls applied?

What happens when a participant loses eligibility while still holding assets?

These questions determine whether a tokenised market becomes broader than the existing market or simply creates a new closed network for the same institutions.

A secondary market is more than a transfer function

The reported plan anticipates secondary-market capability after the initial lock-in.

That is the point where a tokenised issuance becomes a market-infrastructure experiment rather than a primary-issuance demonstration.

A secondary market needs more than a function called:

transfer(token, buyer)

It needs to manage:

instrument eligibility;
participant eligibility;
order entry;
price formation;
trade timestamps;
market surveillance;
trade reporting;
settlement instructions;
settlement failure;
position limits where relevant;
custody and account structure;
corporate-action entitlements;
record retention; and
regulatory oversight.

If a transfer occurs outside the conventional electronic-book-provider platform, as Reuters reported is planned for the pilot, the new infrastructure must perform or connect to functions that the conventional infrastructure previously provided.

That is why the secondary-market layer matters so much.

The token is not replacing one PDF.

It may be replacing several coordinated institutional processes.

Issuance and secondary ownership need the same asset identity

A common weakness in financial infrastructure is that the same instrument acquires multiple identities as it moves through its lifecycle.

The issuer has one reference.

The depository has another.

The exchange has another.

The custodian has another.

A portfolio manager has an internal security ID.

A token platform adds a smart-contract address or token identifier.

None of those references is necessarily wrong.

The danger is losing the relationship among them.

A tokenised-bond record should be able to connect:

issuer;
legal instrument name;
ISIN or other conventional identifier where applicable;
issuance programme;
tranche;
token or ledger identifier;
depository identifier;
wallet position;
governing documents;
outstanding principal;
coupon terms;
maturity;
current holder or beneficial-owner record; and
transaction history.

The token ID should not become a substitute for instrument identity.

It should become another authoritative reference within that identity.

A bond is more than a balance

A token can represent a quantity.

A bond has terms.

Those terms create a lifecycle.

A typical bond may involve:

issue date;
settlement date;
interest-accrual periods;
coupon record dates;
coupon payment dates;
business-day conventions;
optional redemption;
mandatory redemption;
covenant events;
rating changes;
amendments;
defaults;
acceleration;
maturity; and
final redemption.

A tokenised position that shows only:

Balance: 1,000

is not sufficient market infrastructure.

The system must know what those 1,000 units are entitled to receive and under which conditions.

That means linking the ledger state to the legal instrument terms.

It also means recording changes.

If a bond is amended, the historical state should not disappear.

If an issuer partially redeems the instrument, the outstanding amount changes.

If a coupon is paid, the entitlement and payment event should be traceable.

If a court stays payments or a regulator freezes an account, the technical system needs a lawful operating response.

A blockchain balance is only one state variable inside a much larger asset lifecycle.

Corporate actions are where tokenisation meets operations

Primary issuance attracts attention.

Corporate actions reveal whether the infrastructure actually works.

Consider a coupon payment.

The system needs to know:

who is entitled to receive it;
at which record time ownership is measured;
what happens to pending trades;
which cash account or wallet receives the payment;
how withholding or tax information is handled;
how failed payments are reconciled; and
how the payment is evidenced later.

Now consider an early redemption.

Or a consent solicitation.

Or a covenant waiver.

Or a partial principal repayment.

Or a transfer restriction.

Or an issuer default.

The market cannot solve these events by saying “the token is immutable”.

The token state must respond to legally valid lifecycle events.

That is one reason tokenisation should be viewed as market infrastructure rather than as an asset wrapper.

The difficult work is not minting.

It is maintaining a correct state over time.

The ledger needs provenance, not just history

Blockchains are often praised for providing a transaction history.

History is useful.

Provenance is broader.

Suppose a token record says:

Coupon rate: 7.25%
Maturity: 30 September 2029
Outstanding principal: ₹4.8 billion

A professional investor needs to know where those fields came from.

Was the coupon extracted from the final terms?

Was maturity amended later?

Does outstanding principal reflect a partial redemption?

Which document is controlling?

Who reviewed the field?

When was it last reconciled?

A transaction ledger can prove that a value was recorded at a point in time.

It does not prove that the value was legally correct.

The strongest architecture therefore connects:

Structured field
    ->
Source document or authoritative system
    ->
Version
    ->
Reviewer or validation event
    ->
Current ledger state
    ->
Subsequent lifecycle changes

That is the difference between an auditable asset record and a cryptographic spreadsheet.

On-chain and off-chain evidence will coexist

Not every important fact belongs on a distributed ledger.

A bond transaction can involve:

offering documents;
board resolutions;
legal opinions;
KYC records;
investor representations;
tax documents;
rating materials;
covenant certificates;
notices;
payment evidence; and
regulatory filings.

Some of those documents may contain sensitive information.

Some are too large or too frequently updated to place directly on-chain.

Some are held by external institutions.

Some may need access restrictions.

The practical architecture is therefore likely to combine:

authoritative on-ledger state;
external legal documentation;
off-ledger data repositories;
hashes or references;
identity systems;
depository records;
payment systems; and
audit logs.

That is not a failure of tokenisation.

It is how regulated financial infrastructure usually works.

The key is to preserve the relationship between the token and the evidence supporting it.

Interoperability becomes the next problem after the pilot works

A closed pilot can be elegant.

A market is not closed.

Institutional investors already use:

order-management systems;
portfolio-management systems;
custodians;
accounting systems;
risk engines;
collateral systems;
market-data feeds;
settlement platforms;
reporting systems; and
regulatory infrastructure.

A tokenised bond that cannot move information into those systems may create operational friction even if its internal ledger is efficient.

IOSCO’s work on tokenisation has repeatedly highlighted interoperability between traditional and DLT infrastructure as a major practical issue. IOSCO: Tokenization of Financial Assets

The long-term question is therefore not whether every asset will move to one blockchain.

It is whether different infrastructures can agree on:

identity;
ownership;
transaction state;
settlement state;
cash movement;
asset restrictions;
corporate actions; and
authoritative records.

Interoperability is not only a messaging problem.

It is an agreement about meaning.

Smart contracts can automate rules—but not invent them

A tokenised bond can use programmable logic.

That can be valuable.

A system could potentially automate:

issuance allocations;
transfer eligibility;
DvP settlement;
coupon calculation;
payment scheduling;
maturity redemption;
balance updates; and
reporting events.

But every smart-contract rule begins with a legal or operational rule defined elsewhere.

The code must know:

who is allowed to transfer;
which calendar applies;
what happens on a non-business day;
which rate is used;
whether a payment can be withheld;
how an amendment becomes effective;
who can pause the system;
what constitutes default; and
what authority can override normal execution.

The difficult question is not:

Can this be coded?

It is:

Who has authority to define the rule, and what evidence shows that the code still reflects the governing instrument?

Automation without governance can accelerate an error.

Tokenisation makes exception handling more important, not less

Financial markets are full of exceptional cases.

A security can be frozen.

A holder can die.

A fund can merge.

A custodian can fail.

A court can issue an order.

An issuer can restructure.

A payment can be made in the wrong amount.

A participant can lose access credentials.

A ledger node can fail.

A transaction can be submitted with an incorrect quantity.

A software upgrade can introduce a defect.

Traditional infrastructure has procedures for many of these events.

A tokenised system needs them too.

The phrase immutable ledger does not answer:

who corrects an erroneous beneficial-owner record;
how a sanctioned address is handled;
how a stolen credential is replaced;
how a legal injunction is implemented;
how an invalid transaction is quarantined; or
how the market resumes after an operational outage.

A mature tokenised market therefore needs explicit exception states.

For example:

Pending
Validated
Settled
Failed
Frozen
Reversed by authorised process
Cancelled before finality
Under dispute
Redeemed
Closed

That is a lifecycle model.

Not a slogan.

What an Asset Passport should preserve in a tokenised bond

For DaDepo, the most useful response is not to create a field called:

Tokenised: Yes

That tells a reviewer almost nothing.

A tokenised-bond Asset Passport should preserve the relationship between the legal instrument and the market infrastructure through which it moves.

Instrument identity

issuer;
instrument name;
security type;
issuance programme;
tranche;
ISIN or equivalent identifier where applicable;
issue date;
principal amount;
currency;
coupon basis;
maturity;
governing law; and
controlling documents.

Token or ledger representation

ledger or network;
token identifier;
smart-contract or instrument address where relevant;
token quantity convention;
minting or issuance event;
authoritative-record status;
relationship to conventional depository records;
technical administrator; and
current version of relevant contract logic.

Ownership and account structure

registered owner where applicable;
beneficial owner;
securities wallet;
custodian or participant;
nominee arrangement where relevant;
transfer restrictions;
pledge or encumbrance status;
frozen or blocked status; and
source supporting the current position.

Cash and settlement

settlement asset;
CBDC or payment-system reference;
settlement wallet or account;
DvP mechanism;
settlement date and time;
settlement finality status;
failed-settlement history;
payment references; and
reconciliation status.

Trading and market status

eligible trading venue;
participant requirements;
lock-in period;
secondary-market eligibility;
last trade;
current transfer status;
market restrictions; and
reporting requirements.

Lifecycle and corporate actions

coupon schedule;
record dates;
coupon payments;
principal repayments;
amendments;
consents;
defaults;
freezes;
redemptions;
maturity; and
closure.

Provenance

source document for each material term;
authoritative external system;
document version;
extracted field;
user-confirmed field;
externally confirmed field;
reviewer;
review status; and
last reconciliation date.

That is what makes the token understandable as a regulated financial asset.

The Asset Passport and the ledger solve different problems

A tokenised market ledger answers questions such as:

Who holds what right now?

Did the transfer settle?

Which transaction changed the balance?

An Asset Passport answers a broader set of questions:

What is this instrument?

Which documents create the right?

What does the token represent legally?

Which restrictions apply?

Which external records support the state?

What has changed during the lifecycle?

Which facts are verified and which remain assertions?

Those functions complement each other.

The ledger is excellent at state transition.

The Asset Passport is designed for meaning, evidence and context around the state.

A mature market needs both.

AI can reconcile the infrastructure—but it should not decide legal finality

Tokenised securities create an attractive use case for AI-assisted operations.

AI can help compare:

final terms against structured instrument fields;
depository records against wallet positions;
trade records against settlement events;
coupon notices against expected schedules;
payment records against investor entitlements;
amendments against smart-contract parameters;
conventional security identifiers against token identifiers; and
lifecycle events against portfolio records.

AI can flag:

inconsistent principal amounts;
missing corporate-action notices;
a wallet position that does not reconcile to another authoritative record;
a maturity date changed in a later amendment;
a coupon payment without a matching cash event;
a transaction shown as settled in one system but pending in another; or
a token identifier attached to the wrong legal instrument.

That is useful operational intelligence.

It does not mean AI should independently decide:

which record has legal priority;
whether settlement is legally final;
whether a transfer is enforceable;
whether the investor is the beneficial owner;
whether a smart contract complies with securities law;
whether a freeze should be imposed;
whether an erroneous transfer should be reversed; or
whether an investor may legally participate.

Those decisions depend on law, market rules and authorised institutions.

AI can organise evidence.

It should not manufacture authority.

What DaDepo can contribute

DaDepo does not need to become a blockchain network to be relevant to tokenised markets.

The more fundamental problem is that tokenised assets still need understandable identity, evidence, ownership context and lifecycle records.

DaDepo can help connect:

legal instrument documents;
issuer information;
conventional security identifiers;
token identifiers;
depository references;
ownership evidence;
transfer restrictions;
settlement events;
corporate actions;
review status;
provenance; and
known gaps.

Where an external depository, CBDC system, custodian, exchange or DLT network is authoritative, the Asset Passport should reference and reconcile with that infrastructure rather than pretending to replace it.

This matters especially during transition periods.

The same issuer may have conventional bonds and tokenised bonds.

The same investor may hold assets through several custody models.

A portfolio system may need to aggregate both.

A legal reviewer may need the governing documents regardless of how the position settles.

An auditor may need to trace a balance back to authoritative evidence.

A future buyer may need to understand restrictions before attempting a transfer.

The token is one part of that record.

What DaDepo does—and does not do

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

issued the bond;
issued a digital token;
determined that a token legally represents a security;
operated a blockchain or distributed ledger;
operated a central securities depository;
acted as registered owner, beneficial owner, nominee or custodian;
opened or controlled a securities wallet;
opened or controlled a wholesale-CBDC wallet;
provided central-bank money;
operated a trading venue or exchange;
executed a securities trade;
cleared or settled a transaction;
established legal settlement finality;
authenticated every ledger entry or external record;
determined investor eligibility;
verified legal ownership or priority;
guaranteed interoperability;
validated smart-contract code as legally correct;
provided investment, custody, legal, settlement or market-infrastructure services; or
guaranteed liquidity, price, payment, redemption or transferability.

Important: DaDepo provides technology and information tools. It does not provide legal, financial, investment, tax, accounting, custody, depository, exchange, clearing, settlement, CBDC, token-issuance, smart-contract-audit or valuation advice or services unless a specific service is expressly identified and lawfully provided. The legal effect of a token, ledger entry, securities wallet or settlement event depends on the applicable instrument documents, market rules and law.

A tokenised-bond infrastructure checklist

Before a tokenised bond is presented to an investor, market participant or reviewer, ask:

Instrument: What exact legal security does the token represent?
Issuer: Is the issuing legal entity unambiguous?
Terms: Are principal, coupon, maturity, currency and governing law supported by controlling documents?
Identifier: How does the token identifier map to the ISIN or other conventional security identity?
Authoritative record: Which system legally determines the current holding?
Ownership: Who is the registered owner and who is the beneficial owner where those concepts differ?
Wallet: What does control of the securities wallet legally mean?
Custody: Is a custodian, nominee or depository participant involved?
Restrictions: Which transfer, lock-in, investor-eligibility or jurisdictional restrictions apply?
Cash leg: Which money or payment system settles the transaction?
DvP: Are security delivery and payment linked conditionally?
Finality: At what point is settlement legally final?
Liquidity: Does near-instant settlement require prefunding or additional intraday liquidity?
Failure: What happens if the security or cash leg is unavailable?
Secondary market: Where and how can the instrument trade after issuance?
Interoperability: How does the tokenised position connect to custody, accounting, risk and portfolio systems?
Corporate actions: How are coupons, redemptions, amendments and defaults reflected?
Exceptions: How are freezes, mistakes, key loss and legally authorised corrections handled?
Provenance: Can each material structured field be traced to the right document or authoritative system?
Lifecycle: Can a reviewer reconstruct every material state change from issuance to redemption?

If the answer to “what does the token legally and operationally represent?” is unclear, the infrastructure is not finished.

The transition is from digital assets to executable financial infrastructure

The most important thing about India’s reported pilot is not that REC may issue a bond on blockchain.

That has precedents elsewhere.

The more important development is the apparent attempt to connect four functions at once:

Issuance
+
Ownership record
+
Central-bank-money settlement
+
Secondary transfer

That changes the conversation.

Tokenisation stops being a cosmetic representation layer.

It becomes a way to redesign how the market records and executes rights.

That also raises the standard for the data around the asset.

If trading becomes faster, identity must be clearer.

If settlement becomes atomic, participant access and liquidity must be controlled.

If ownership moves on a new ledger, the legal authority of that ledger must be explicit.

If secondary trading expands, corporate actions and restrictions must follow the asset.

If smart contracts automate execution, the link between code and governing documents must be auditable.

And if several infrastructures coexist, the market must know which record is authoritative for which purpose.

The future of tokenisation is therefore unlikely to be defined by the number of assets that can be minted.

It will be defined by the number of financial processes that can operate on the same trusted understanding of the asset.

A bond was already digital before blockchain.

What tokenisation can change is not the existence of the bond.

It can change the infrastructure around ownership, payment and transfer.

That is when the token stops being a wrapper.

That is when it starts becoming market infrastructure.