The form has been successfully submitted.
Please find further information in your mailbox.
Hire us Select language
About us Technologies Industries Portfolio 
Companies actively use real-world asset tokenization on assets such as real estate, bonds, commodities, invoices, and fund shares, and here’s their “why”: as of March 2026, tokenized real-world assets on public blockchains hit $27.4 billion, up from $6.7 billion a year before. US Treasuries alone account for $13.53 billion of that. The infrastructure exists, regulations are catching up faster than we might have expected, and institutional money has started moving. And the numbers show it.
The question isn’t whether tokenization works anymore, because it does. The harder problem is knowing how.
So, what does it actually take to tokenize a real-world asset? Let’s go step by step.
A textbook definition of tokenization would be this: it’s a blockchain-based representation of ownership rights.
Put simply, a digital token is just… code.
However, digital tokens don’t carry any legal meaning by themselves. So what stops anyone from creating a token that claims to be worth millions? Nothing, technically. You can create a token saying that “This token represents 1% ownership of my property,” for however long you want, but it doesn’t mean that a court will treat it as such. It doesn’t even mean that you have any enforceable rights.
We must understand that there’s a difference between what the token represents and the ownership of that asset. There are also economic rights associated with this, for example, earning rental income from the property. The key here is to make sure that all these aspects are connected through a legal framework. And they can be, often through a special purpose vehicle (SPV), where the actual asset is held by the SPV, and the tokens represent shares or other defined rights in it. It’s quite tricky, but it works.
The point of tokenizing assets is that while you can create meaningless tokens of any kind, proper tokenization involves making sure the digital token is legally valid and connected to real rights. This means setting up custody, compliance, and using smart contracts correctly. I’ve seen those pieces tripped up projects that looked bulletproof on a whiteboard. So, I will cover them further.
Almost anything of value can be tokenized. We can categorize real-world assets into four main buckets: physical assets, digital assets, financial assets, and intangible assets.
This list could go on because if something has measurable value and clear ownership, someone is probably already trying to tokenize it. When I first started mapping this out, I was genuinely surprised by how far it stretches: racehorses, carbon credits, celebrity earnings, and so on.
The breadth of this spectrum is part of what makes this space so difficult. Each category of assets brings a whole different set of issues, such as legal nuances, compliance requirements, and tech considerations. One can’t apply real estate laws, for example, to a digital file or a financial instrument.
“The technology problem of tokenization is largely solved. What we’re still working through is the trust layer, meaning that when someone holds a token, they hold something with real value. Legal structures, compliant custody, and smart contracts that automatically enforce rules are all part of this layer. They need to be set up correctly, so people who have never had a seat at the table before can access the investments.”
Head of Blockchain R&D & Senior Solution Architect
Let’s move from theory to a more practical part and walk through the process. Here is a seven-step answer to the question of how to tokenize real-world assets. I will walk you through the main steps and explain how to select an asset, structure it legally, set up the infrastructure, manage it post-issuance, etc.
You can’t tokenize an asset you don’t legally own or control. It sounds obvious, but I know the deals that reached the legal structuring phase before someone discovered a co-owner who hadn’t signed off. Months of technical work, paused. Obvious in hindsight. Professional appraisers, auditors, and legal experts need to verify ownership and assess any potential risks, liens, restrictions, or encumbrances. For real estate, that means title searches. For fine art, it means provenance documentation. For intellectual property, it means checking patent registries and licensing agreements.
In addition, the asset’s value needs to be assessed and documented in accordance with standard financial practices. The valuation helps determine how many tokens to issue and at what price. If the valuation is wrong, we’re either overpricing or underpricing. Both are scenarios we don’t want.
There’s nuance, though: valuations change. For example, the value of a tokenized building can shift. Markets don’t hold still. Tokenized assets may need ongoing valuation, and you need a process for updating and communicating changes.
Once the asset is selected, the next question is how to structure it legally: direct asset tokenization or an SPV. This is where it starts getting interesting.
Direct tokenization means the token represents a direct claim on the asset itself. Let’s say you tokenize a building. The token would represent a direct claim to part of that specific property. Even though it sounds clean, in practice, it may challenge the regulatory clarity and fungibility.
Most jurisdictions don’t have clear frameworks for blockchain-based property ownership.
SPV structures are often the more practical solution. The asset is held by a legal entity (a private limited company or trust), and tokens represent shares or other defined rights in that entity. Regulators, lawyers, and courts are more familiar with this structure, which can make it easier to document and defend legally.
Before you pick a blockchain, before you talk to a developer, answer this: is your token a security?
In most jurisdictions, if the token represents ownership, profit-sharing, or investment returns, it’s likely to be treated as a security. Tokens classified as securities require investor registration and KYC/AML checks. That means all securities regulations apply.
Another important and tricky point: your token’s jurisdiction isn’t where you’re located. It can also depend on where your investors are, where the asset is located, and where you’re conducting the offering. Each jurisdiction has different requirements for investor protections, disclosure obligations, and tax treatments. I don’t support the “issue tokens globally” approach because it’s likely to be followed by unwelcome letters from regulators. If you think the “we’ll sort the jurisdiction later” approach, you need to remember that the regulator letters aren’t hypothetical.
Also, the jurisdiction you pick determines which licenses you need. Each tokenization structure comes with different licensing requirements. An SPV approach may require a securities dealer, broker-dealer, fund manager, or other regulated intermediary, while direct tokenization may require different authorizations.
Not everyone can buy your tokens. This needs to be reflected in your smart contracts and built into the token logic.
Smart contracts can handle investor whitelisting, transfer rules, and jurisdiction-based restrictions. You can’t just issue tokens and hope people follow the rules. The technology has to prevent non-qualified investors from buying or receiving restricted tokens.
Here we arrive at the moment when “smart contracts enforce investor whitelisting” must be solved technologically.
Since we identified whether your token is a security that falls under security tokens subject to investor restrictions, the next step is to enforce these rules in a network whose native protocol knows nothing about identities and jurisdictions.
On-chain identity standards have the answer for this question. Let me walk you through the standards that matter in production systems.
ERC-3643 (T-REX protocol) is a standard for permissioned tokens. It checks whether investors meet the required criteria, such as KYC, investor eligibility, and jurisdictional requirements, and blocks transfers if they do not.
ERC-1400 (security token standard) adds broader security token features, such as transfer restrictions, partitioned balances for different rights or tranches, document handling, and controlled or forced transfers for compliance.
ERC-734/735 (claims-based identity) are older claims-based identity standards. They use identity contracts and signed claims from trusted issuers to show that a wallet or identity meets certain requirements. However, to use them in real tokenization systems, you will have to customize them.
Decentralized identifiers (DIDs) and verifiable credentials (VCs) offer a more privacy-focused approach. This can keep KYC data off-chain while allowing credentials or proofs to be verified cryptographically.
They’re not interchangeable. Each solves a different slice of the compliance problem.
But who verifies investors on-chain?
Standards are infrastructure. Providers are the services that verify real-world identity and issue on-chain credentials.
This is especially true for privacy-related implementations or regions where you have to follow stringent data-protection laws.
In this setup, the token transfer logic of your implementation doesn’t simply move tokens from Address A to Address B. It first invokes the identity registry logic or compliance logic:
Upon success, the transfer executes, but if not, the transaction reverts with a specific error code.
However, production systems usually use a hybrid model that looks like this:
Here’s how it works: an investor completes KYC with an approved provider. That provider issues an on-chain credential, attestation, or verification status. The tokenization platform’s smart contracts recognize the credential before allowing transfers. The full KYC documents remain with the provider, encrypted, and only authorized parties can access them upon request.
This balances transparency (on-chain compliance checks) with privacy (off-chain personal data storage).
Compliance does not stop at investor checks. Once tokens can represent regulated assets, the platform also needs a plan for what happens when access is lost, ownership changes, or a legally required transfer needs to happen. This is where key recovery and transfer agent controls become important.
Everything can happen in life, and if you’re tokenizing securities, you need to plan for key loss. Regulated securities aren’t pure bearer instruments, so they can’t function like many cryptocurrencies, where losing access means permanently losing the asset. The safest approach is to design recovery mechanisms before anything goes wrong:
ERC-1400 includes built-in functions for this purpose. Every override action gets recorded on the blockchain and requires supporting legal documentation before execution.
Yes, transfer agent override introduces some centralization into an otherwise decentralized system. But this compromise is necessary to make tokenized securities work for institutional investors and meet current regulatory expectations. Pure self-custody without recovery options won’t satisfy most compliance frameworks or attract serious institutional capital.
When you’re setting up your tokenization platform, discuss recovery mechanisms with your legal counsel and technology partner early in the process. The architecture decisions you make at the beginning determine what options you’ll have if a key loss occurs later.
You need to source this identity infrastructure somewhere. There are two paths:
Most projects choose integration because the standards are mature and battle-tested. Building from scratch only makes sense if you have extremely specific compliance requirements that no provider supports.
The very first question you have to answer is related to the fungibility of your token. Fungible or non-fungible may sound like a silly check box at first, but in reality, it isn’t.
Fungible tokens are interchangeable because one token is the same as another. The ERC-20 protocol is one example of such tokens. They work well in case you want to tokenize an asset where each token should represent something equal in terms of both value and rights that go with the ownership. Examples could include REIT shares, tokens in a commodities fund, or even debt securities.
Non-fungible tokens like ERC-721 make sense for unique assets: a specific piece of art, a particular property, an individual intellectual property right.
It will not surprise you that investors care about what they get. Depending on the structure, your rights could include:
All of these rights must be spelled out in legal documents and reflected correctly in the smart contract. They can’t contradict each other.
The ERC-1400 standard supports this through partitioned balances, which means you can represent different token classes with different rights within the same token contract. For example:
Next, you need to figure out the token math. The lower the token price is, the more available it becomes to retail investors. Higher token prices increase the likelihood of attracting institutional investors. For instance, if you’re tokenizing a $10 million property, you will need to decide on 10,000 tokens at $1,000 each, or 10 million tokens at $1 each.
Your smart contracts are capable of applying trading rules, but you need to set them first. Can tokens be instantly sold to anyone? Or do you, the issuer, need to approve every trade? Are there lock-up periods where investors can’t sell? Are there maximum holding limits per investor?
Whatever rules you set must follow securities laws in every jurisdiction where your token is offered or traded.
The compliance standards I have mentioned above become important at this point. Depending on the structure, the token contract needs to enforce:
The blockchain choice affects cost, privacy, interoperability, and regulatory compliance. Pick the wrong blockchain, and you’ll spend months explaining to institutional investors why their holdings aren’t auditable.
Public blockchains like Ethereum are open networks, which means anyone can view transactions and interact with supported applications. The advantages include higher interoperability, allowing for transactions between the token and other digital currencies, including stablecoins, NFTs, and DeFi protocols. In some structures, a tokenized real estate position could be used as collateral in lending protocols. Investors may be able to trade tokens outside traditional market hours, but only on venues that support the required compliance checks.
Public blockchains can support 24/7 access to compliant secondary markets, regulated exchanges, and approved liquidity pools.
The main downside of public chains is visibility: transaction amounts, wallet addresses, and trading patterns are public. For some institutional investors, this is a dealbreaker.
In permissioned blockchains, you have more freedom. Though such blockchains may offer more privacy and security, they tend to work in their own bubbles, which reduces interoperability. That can make it harder to connect with external wallets, exchanges, DeFi protocols, or liquidity venues.
In many projects, I see hybrid architectures become the go-to option:
Then comes custody. There are two different custody questions here:
Asset custody answers where the physical asset is. For tangible movable assets like whiskey barrels or gold, you may need qualified custodians, trustees, or licensed managers to store and manage them according to the security measures. For real estate, “custody” might mean a trustee holding legal title. For fine art, it’s a secure storage facility with insurance and climate control.
Token custody answers where the digital tokens are held. It may be self-custody wallets, licensed digital asset custodians, or both. Self-custody means investors control their own private keys. For institutional investors or high-net-worth individuals, licensed digital asset custodians may be a better fit because they are subject to stringent requirements for security, operational integrity, and compliance. If you’re trying to attract serious capital, your custody infrastructure needs to match institutional standards.
Many platforms integrate with multiple custody providers so investors can choose a preferred option. Custody answers where the assets and tokens are held, but there are also oracles that answer a different question: how does your smart contract know what’s happening in the real world?
Your tokenized real estate system needs to know:
Your tokenized treasury bill system needs to know:
Oracles are services that feed external data to smart contracts in a verifiable way. In cases of RWA tokenization, they offer important real-world data that cannot be accessed by the smart contracts independently. Without it, smart contracts can only process information already recorded on-chain.
Chainlink Proof of Reserve provides cryptographic proof that off-chain reserves — gold in a vault, dollars in a bank account, real estate title — match or exceed the on-chain token supply. The oracle periodically checks the asset’s status with trusted data providers and updates an on-chain reference that smart contracts can query.
Price feed oracles like Pyth and RedStone provide real-time pricing for financial assets, commodities, and securities that need continuous pricing updates.
Custom asset valuation oracles handle unique assets like real estate or art through licensed appraisers submitting valuations, multisig verification from multiple sources, and time-weighted average pricing to prevent manipulation.
Once the legal structure, token design, compliance rules, and infrastructure are ready, the tokens can be offered through a primary marketplace or issuance platform. The basic workflow typically looks like this:
Every step relies on the identity infrastructure we discussed and built in Step 3.
If an investor tries to buy some tokens, there is a check if there is a valid identity certificate in their wallet. In case such an identity certificate is not found, the investor will be referred to go through KYC and obtain an identity certificate from the selected IDP.
When this procedure has been completed, the investor will receive the certificate, which has only compliance information recorded within it, namely: verification status, accreditation level, jurisdiction code, and expiration date. The personal information is kept in the off-chain storage provided by the KYC vendor.
We can choose from three main payment methods for purchasing tokenized assets:
Traditional wire transfers are well-known to most of us, but can be slow and take 2-5 business days, especially for international payments. Fees may also be high, and some banks block crypto-related transactions.
Stablecoin rails offer near-instant settlement, work 24/7, and bypass traditional parts of the banking infrastructure. They require investors to have stablecoins and a crypto wallet setup. However, I’d like to draw your attention to the fact that some jurisdictions restrict stablecoin usage.
Hybrid platforms support both banking infrastructure for wire transfers and stablecoin rails for crypto-native investors, while handling conversion, reconciliation, and accounting in the background.
For institutional investors, traditional wire transfer support is often essential. For DeFi-native users, stablecoin rails are expected. Most successful platforms support both options.
Distribution does not end the compliance process. Identity credentials can expire, and investor status can change. For example, accreditation may expire, investors may move to restricted jurisdictions, wallets can be flagged in sanctions screening updates, and KYC providers may revoke credentials due to suspicious activity.
The platform needs a process for updating investor status after tokens are issued. Depending on the setup, this may block a wallet from receiving new tokens, restrict transfers, or freeze tokens until the issue is resolved.
Tokenization is a goal but not the end. When you possess your RWA token, you need to manage its lifecycle over the long term. That lifecycle breaks into six distinct zones: ownership reconciliation, income distribution, tax compliance, corporate actions, secondary market liquidity, and ongoing regulatory reporting. Knowing how each zone works on its own is important to prevent legal and administrative issues later.
Lifecycle management is not as simple as the blockchain ledger telling you who holds the tokens. Legal factors may change, and blockchain does not automatically reflect them.
Because of these scenarios, you need systems that continuously reconcile the digital ledger with actual, legally binding ownership records. Usually, you can do regular attestation from transfer agents, set Oracle feeds to update beneficial ownership data, or implement admin functions in the token contract for forced transfers under legal authority.
Distributions are not as automated as they sound. Smart contracts can execute distributions automatically, but production systems require verification steps:
Most production tokenized real estate systems use admin-triggered distributions, not fully autonomous time-based ones. Here’s why: The property manager receives rent, deducts operating expenses, pays taxes and insurance, and then deposits the net distributable income into the distribution account. An authorized admin then triggers the smart contract’s distribution function.
Fully autonomous time-based distributions without verification are rare in production because the system needs to confirm funds are available, deductions have been made, and tax withholding is calculated correctly before executing the distribution.
More sophisticated systems use oracles that verify rent payment received, operating expenses paid, and net distributable amount calculated through off-chain accounting systems before triggering the on-chain distribution function.
But paying income is only part of the process. The platform also has to account for tax withholding and reporting before money reaches investors.
Pure on-chain Solidity contracts alone cannot handle the full complexity of multi-jurisdiction tax withholding. But some production systems handle withholding logic through:
So it’s not that smart contracts can’t handle tax compliance; you just need specialized compliance modules and oracle data feeds.
Distributions and taxes are recurring events. Other events are less frequent, but more complex. These are corporate actions.
Corporate actions include stock splits, reverse splits, mergers and acquisitions, dividend reinvestment, conversions, and mandatory redemptions. Traditional securities have well-established processes for these. Tokenized securities need to replicate them on-chain.
Stock splits. Multiply everyone’s token balance while proportionally decreasing the value per token. Requires handling fractional shares, in-flight transfers, and coordination across custody providers.
Dividend reinvestment. Investors can opt to automatically reinvest dividends into new shares. This requires capturing the payment, converting to stable value, purchasing new shares at current NAV, and maintaining compliance checks for the reinvestment purchase.
Conversions and redemptions. Convertible securities (like bonds converting to equity) need trigger conditions, conversion ratio calculations, and burning old tokens while minting new ones. Mandatory redemptions require calculating the redemption price, burning tokens, and distributing payment.
Mergers and acquisitions. Old tokens must be exchanged for new tokens or cash, with exchange ratios calculated, approval voting conducted on-chain, and dissenting shareholder rights honored.
The ERC-1400 standard includes functions for corporate actions, but to implement them correctly, you need to understand both corporate law and smart contract security. Most platforms handle M&A through off-chain legal processes with on-chain execution of the final result.
Once the token is operating correctly, investors may also want a way to exit. That brings us to secondary market trading.
After the initial offering, RWA tokens may be traded on secondary markets through:
However, many tokenized real-world assets still lack liquid secondary markets.
You might issue tokens, and investors might want to sell, but if there aren’t active buyers, liquidity is theoretical. You could have a perfectly functioning token with excellent compliance infrastructure, and it still might trade once a month at 20% below NAV because there’s no market depth.
Building liquidity requires:
Some platforms, such as tZERO and INX, operate regulated secondary markets specifically for security tokens. Integrating with them significantly improves liquidity prospects.
Institutional investors care not only about finding buyers but also about how the trade settles.
For institutional-grade secondary market trading, atomic delivery-versus-payment is essential. DvP means the token transfer and the payment transfer happen simultaneously and atomically: either both succeed, or both fail. No counterparty risk. Traditional securities markets have settlement risk: you might deliver shares today and not receive payment for T+2 days. Or you pay today and receive shares two days later. During that window, counterparty default is possible.
This is one of the main operational benefits of tokenization for institutional investors. J.P. Morgan’s Kinexys, Broadridge’s Distributed Ledger Repo (DLR), and Fnality’s payment system all implement atomic DvP.
When evaluating tokenization platforms, ask: “Do you support atomic DvP for secondary market trades?” If the platform cannot explain how settlement works, it may not be ready for institutional use.
Trades settle, and the ongoing legal and reporting obligations are what’s left to deal with.
When you launch a token, there remain some ongoing legal and administrative responsibilities:
This is one of the more demanding ongoing commitments in tokenization, but knowing it up front makes it manageable.
Many platforms provide compliance dashboards that automate report generation, but you’ll still need legal and compliance professionals reviewing everything.
For the investor’s experience, the platform works as a single continuous path. Money goes in, gets converted into a tokenized position, earns income while it’s held, and eventually comes back out as cash. To make it usable, every step in between, such as on-ramping, KYC, custody, distributions, secondary sales, off-ramping, and tax reporting, has to work together.
This diagram demonstrates the full path. Click through each step to see the proccess and where it runs.
The full path your investor walks — fiat in, buy, earn, optionally DeFi, sell, cash out and pay tax. Tap any step to see what happens under the hood: the process, the vendors, where it runs.
The tokenization of a real-world asset, first and foremost, is a complex task in terms of regulation and law. We know how to create a token using blockchain technology, but it’s actually putting in place that trust layer, the one that ensures the legality of the token, compliance in multiple jurisdictions, and post-tokenization management mechanisms in such areas as taxation, corporate actions, and liquidity. It all comes down to transitioning from an idea and theoretical approach to a tried and tested compliance production solution. Hence, the importance of having competent legal consultants at the very start of the process.
If you’re looking into tokenizing assets and want to figure out which path makes the most sense for your project, we’re here to help you weigh the options and share what we’ve learned along the way.
Not necessarily. A token is just code. It only has legal force when it's tied to a legal structure that gives it enforceable rights. In most cases, an SPV holds the asset, and the tokens represent specific rights in that entity. Without that setup, you may have a token that claims to represent an asset, but there's no guarantee a court will treat it that way.
Direct tokenization means the token itself represents a claim on the asset. The idea seems simple, but the legal side is often not. There are still jurisdictions that don't have well-defined rules for blockchain-based ownership of real-world property. With an SPV structure, the asset sits inside a legal entity such as a company or trust, and the tokens represent shares or other defined rights in that entity.
There's no single right blockchain, but there are wrong ones for specific situations. Public blockchains offer interoperability, round-the-clock market access, and a mature ecosystem. Your compromise is that transaction data is visible, which some institutional investors view as a problem. Permissioned blockchains provide more privacy and control, but they can make liquidity and interoperability harder. Some larger projects prefer a hybrid model. They issue assets on a permissioned layer, then connect to public chains.
That depends on both the asset and the jurisdiction. Many tokenized assets are treated as securities, which means access is often limited to accredited or qualified investors. Even so, tokenization has already lowered minimum investment sizes. Broader retail participation is possible, but availability comes down to the structure of the offering and the investor's location. Having said this, eligibility rules are enforced directly through the smart contract, not just through terms and conditions.
In many cases, yes. If a token represents ownership, profit participation, or investment returns, regulators are likely to classify it as a security.
If you're using existing platforms and proven identity systems, a straightforward asset with a clean legal structure can often be tokenized in a few months. If you're building custom compliance systems, six to twelve months is a more realistic starting point, and that's before the offering begins.
Liquidity is frequently underestimated. You can launch a compliant token with strong technology and still end up with an asset that trades rarely and at a meaningful discount to NAV because there aren't enough buyers and sellers. Regulatory risk is another major consideration. The rules are still developing, and a structure that works now may face new requirements later.
Blockchain Expert & DeFi Analyst
Andrew translates decentralized concepts into secure, functional financial tools. He navigates the volatile DeFi landscape to build scalable blockchain infrastructures that address real-world utility, moving past the buzzwords to deliver technical value.
