RWA was an important entry point, but not the final destination of tokenisation
Tokenising real-world assets got blockchain into the door of mainstream finance. The harder argument now is that the door was never the destination: the next phase belongs to financial instruments built natively on digital infrastructure, rather than traditional assets given a digital wrapper.
The real-world asset (RWA) narrative earned its place by showing that blockchain need not be confined to cryptocurrencies. Property, receivables, debt securities and fund units were held up as candidates for digitalisation, and institutions began to discuss issuing, distributing, holding, transferring and settling assets in digital environments. But concentrating the debate on representing existing assets led part of the market to treat tokenisation as a new format for record-keeping, without asking whether the underlying processes could be structured differently. If an instrument is still administered entirely in external systems, with parallel controls and constant reconciliation, the technology reproduces much of what it was meant to overcome.
The distinction matters because a natively digital asset is not defined simply by having been born on a blockchain. It must be structured so that its essential functions are executed, recorded or coordinated consistently on digital infrastructure, with legal and operational effects that match the instrument and the applicable regulation. That covers who may acquire it, how ownership is recognised, what restrictions apply to transfers, how interest or amortisation events are processed, and how settlement connects to other market participants. Banks, custodians and registrars are not eliminated where their functions are required; their responsibilities are integrated into less fragmented processes. Executing rules through smart contracts does not by itself satisfy the legal requirements for creating rights or ensuring transfers are effective, and the technology must operate alongside those requirements rather than assume them away.
Much of the effort in tokenisation projects goes into the moment of issuance, because creating a token and demonstrating its transfer is visible and relatively easy to present. The operational cost, however, runs across the whole life of an instrument, which may stay in circulation for months or years while generating interest, amortisation, position changes, court or contractual blocks, eligibility shifts and reporting obligations. In infrastructure designed for native assets, that lifecycle becomes central to the project, with instrument rules guiding programmable events and shared records letting authorised participants track consistent operational states. Not every event can or should run automatically: a payment obligation may depend on available funds, authorised instructions, compliance checks or external settlement systems. The gain lies in structuring those dependencies in an integrated, auditable way.
The economic consequence may matter more than the technological one. Part of the market's products and operations carry relatively fixed costs of structuring, distribution, registration, administration and settlement, which can consume a large share of the return on smaller deals. If much of that work can be standardised and run on shared infrastructure, new structures become economically viable, including smaller issues, collateral operations and specialised credit instruments. But the cost reduction must come with genuine simplification of the process: bolting digital infrastructure onto the traditional operation leaves an institution carrying its old costs plus a new layer. Liquidity still depends on demand, price formation, participants, trading rules and adequate settlement mechanisms; a token does not create buyers by existing.
A digital financial asset also does not operate in isolation. Its transfer may require payment, validation of participants, position updates and integration with institutions responsible for specific functions, which is why moving a token between wallets is not the same as settling a trade. Delivery versus payment mechanisms, which condition delivery of an asset on the corresponding payment, illustrate the point, and their effective operation depends on the legal and operational design of the infrastructures involved, including where different networks or payment systems take part. Interoperability follows the same logic: digital assets are unlikely to reach institutional relevance if they stay confined to platforms that cannot interact with the rest of the market. Regulation does not become less important in this model. Depending on the instrument, issuance, distribution, trading, registration and custody may involve different institutional responsibilities and regulatory requirements, and blockchain does not automatically change an asset's legal classification. The aim is not to turn every contractual clause into code, but to identify which functions can be executed or verified digitally, which depend on institutional decisions, and how those responsibilities connect, with compliance built into the design of the instrument rather than adapted after issuance.
