1.1 What Is Asset Tokenisation? An Operational Definition
Asset tokenisation is the process of converting an enforceable economic or legal right or claim into a transferable, recordable and executable digital object on a distributed ledger (DLT). Contrary to common market perception, a token is not the asset itself; it is a conditional digital representation that must be linked to a right, obligation, ownership interest, benefit, access right or verifiable claim in the external world.
Core formula (book definition):
Components:
- D (Underlying Asset) — the base asset: real estate, bond, fund unit, IP, cash-flow stream, commodity, etc.
- R (Legal/Contractual Right) — the legal or contractual right associated with D.
- Rules — transfer restrictions, income distribution, redemption, waterfall, pause and recovery logic.
- Identity — holder identity and eligibility (KYC, investor class, jurisdiction).
- Evidence — legal documents, official registers, independent valuation, oracle data and audit trail.
The formula deliberately does not assume absolute ownership. The holder of T may be:
| Holder Status | Legal Nature | Practical Consequence |
|---|---|---|
| SPV shareholder | Equity ownership in the company | Voting, dividends, corporate tax, liquidation rights |
| Fund unit holder | Beneficial interest in fund assets | NAV, redemption under fund rules |
| Contractual creditor | Right to a defined cash flow | Issuer credit risk, income tax |
| Usage / access right holder | Limited non-ownership right | No claim on the underlying asset itself |
1.2 Systematically Separate the Three Layers
A costly structural mistake is to treat the technical layer as identical to the legal layer. Holding an NFT or an ERC-20 token does not, by itself, create copyright, commercial exploitation rights or physical ownership.
Economic Layer — What value is being transferred? (return, risk, liquidity)
Source of truth: financial model + independent valuation
Legal Layer — Exactly what right does the holder have, and against whom?
Source of truth: legal documents + official registers + Offering Terms
Technical Layer — What is recorded and executed on-chain?
Source of truth: smart contract + Oracle + Identity Registry
Figure 1.1 — Three independent layers that must be designed simultaneously
1.3 Comparative Numerical Example: €10 m Building
Assume a building with a market value of €10 million and an SPV that is the legal owner of the title. If 10,000 tokens are issued, three fundamentally different models are possible:
| Model | Each token represents | Approximate classification | Primary risk for holder |
|---|---|---|---|
| A – SPV equity | 0.01 % of company shares | Equity / Security | Corporate + liquidation risk |
| B – Rental income share | Right to 0.01 % of net rental income | Income claim / Contractual | Property operational + SPV risk |
| C – Fixed amount right | Right to a defined annual amount | Debt-like instrument | Issuer credit risk |
Analytical conclusion: These three models are not equivalent from an economic, legal, tax, accounting or risk perspective. Choosing the wrong model at the design stage exposes the project to regulatory rejection, double taxation or litigation.
1.4 Operational Definition of Project Success
According to this book, a tokenisation project is successful if and only if the following five conditions hold simultaneously:
- An enforceable and provable legal right exists.
- The link between token and right (legal link) is documented, verifiable and reconstructible.
- Holder identity and eligibility are controlled where required.
- Custody of the underlying asset and data (oracle) are trustworthy and independent.
- Settlement, redemption, corporate actions and reporting processes are operational.
Before choosing a blockchain, token standard or development team, first design “rights + cash-flow + custody + identity + settlement + regulation”. Technology comes afterwards. Reversing this order is a primary cause of failure in many RWA projects.