How to Tokenize Real-World Assets: Smart Contract Architecture, Oracle Design, and MiFID II Compliance

Tokenizing a real-world asset on blockchain involves four steps,
1. Wrap the asset in a legal entity (SPV)

2. Deploy a permissioned smart contract (ERC-3643 or ERC-1400) that enforces investor eligibility

3. Wire an oracle to bring off-chain valuations on-chain,

4. Bind the legal documents on-chain via document hash. 

A white-label RWA tokenization platform can be delivered in 7–10 days. A custom build RWA tokenization platform takes 25–30 days. An RWA tokenization platform differs from a security token platform in one critical way. An RWA platform binds the token to a real-world legal ownership claim (SPV, title deed, loan agreement) and requires an oracle layer to keep valuations accurate. 

A security token platform issues the token but often relies on off-chain legal enforcement. The architecture and the compliance obligations are different from day one.

The tokenization process also differs by asset class. Real estate requires an SPV and title registry oracle. Private credit requires repayment logic and borrower default triggers. Commodities require custodian attestation and reserve proof. Art and collectibles require provenance chains and physical custody oracles. 

The components are always: smart contract + oracle + KYC/compliance registry + SPV legal wrapper, but how they’re wired changes by asset.

The tokenized RWA market crossed $15B in 2024 and grew 260% in Q1 2025.

BlackRock, Franklin Templeton, and JPMorgan are in production. Most tokenization attempts still fail not at the technology, but at the gap between the token and the legal ownership it’s supposed to represent.

This guide covers the complete architecture: ERC-3643/ERC-1400 token standards, oracle design with manipulation circuit breakers, MiFID II compliance at the contract layer, and SPV binding. For EU platforms, MiFID II governs regulated RWA tokens from day one.

What is real world asset tokenization?

Real World Asset Tokenization is the process of breaking an owned asset into tokens to sell on the blockchain, completely or partially. As a person, you own a building, vehicle, or commodity that is tangible and can be tokenized using the blockchain network.

When you tokenize in blockchain, you can make your token sale globally and share ownership with people from various countries(accredited investors). And the great boon of this concept is that all these occur automatically and securely through smart contracts(conditions written in code).

Let’s see what drives us to tokenize our RWAs.

Why tokenize real world assets?

Tokenization unlocks multiple value paths for real-world assets. Fractional sale, collateralization, yield distribution, compliance automation, and global settlement, all without the delays and friction of traditional asset transfer systems.

It takes a large amount of time, cost, and energy to sell a single asset. We all have endured two main issues. One is finding the buyer, and the other is the registration procedures. And geography also plays a role in it.

RWA tokenization brings

• Fractionalization – Anyone can own the asset with a minimum share
• Programmable Compliance – Rules are enforced by the code and not by the people
• Automated Distributions – Smart contracts automate fund distribution to the investors
• Global Distribution – Can integrate any jurisdiction with proper compliance rules
• Secondary Liquidity – Can sell token on marketplaces(exchanges) instead of bilateral OTC deals

These are the general benefits you get while tokenizing your RWAs. If we go deeper, every feature of the RWA tokenization platform will amaze you.

Well, you may be wondering which of the assets would qualify to get tokenized. Let’s see the assets that can be tokenized.

What type of assets can be tokenized?

Multiple assets come under tokenization. When it comes to real world assets, these are the ones that qualify. Here are the asset classes and how they can be tokenized.

• Real Estate(house/land) — Property transferred into SPV*(Special Purpose Vehicle) and then tokenized with jurisdictions
• Private Credit — Borrower’s loan agreement assigned to SPV, and it issues the tokens that represent the right to receive payments
• Vehicles & Fleet(car/truck/aircraft) — Represents shares in lease income with Oracle’s price accuracy; SPV is not mandatory 
• Art & Collectibles — Securely stored and represent fractional and sole ownership with automated royalty payments
• Commodities(gold/oil) — SPV is not mandatory, tokens represent ownership of a fixed quantity of the commodity
• Invoices — Represent fractional ownership in receivables & when the invoice is paid, profits are automatically distributed to investors
• Infrastructure & funds — SPV is usually mandatory and represents revenue-generating infrastructure assets/fund interests

*SPV – The legal entity that sets the rules for that company. The physical asset cannot be directly converted into a token. So, the asset is first registered in a company name, and that company is represented by blockchain tokens. Without an SPV agreement, the token is just a digital file. It stands as the legal connection to the real world asset and the blockchain network.

Now we can get to know what it takes to tokenize these real-world assets.

How to tokenize Real-world Assets

As we said, SPV is the gateway to enter into RWA tokenization. But beyond that, there lies the automation logic that brings all the ideas to life.

These 3 logics are integral for most of the tokenizing real world assets.

1. Smart contract architecture
2. Oracle design
3. Compliance at the contract level

In these cases, Oracle is mandatory for asset types like commodities, vehicles, and fleets that require price accuracy. And the compliance structure varies according to the jurisdiction in which you are going to start your RWA tokenization platform. For platforms targeting EU investors or operating under EU jurisdiction, MiFID is not a separate compliance step. It determines which contract-level functions are mandatory across all three layers above, from day one of your build.

But the smart contract framework remains the mandate for any asset to tokenize. Using the relevant ERC standards, Smart contracts hold the entire logic to execute the entire operations automatically and preserve the ownership with compliance. In short, these contracts are the ones that tie every layer together, making the RWA tokenization live.

Now let me decode the layers for you.

Smart Contract Architecture

Smart contracts(SCs) are the self-executing contracts that are the conditions on what, how, where, and when the transactions/actions occur in programmed code. These are written mostly in Solidity, and they might vary on the blockchain network you choose.

Here are the four sub-layers that complete the SC architecture.

#1 Token Standard Decision

First, you need to select the blockchain network and the token standard. Ethereum, Binance Smart Chain(BSC), Solana, and Polygon are the networks that have been utilized for most of the RWA projects. 

When we talk about the standard, many are aware of the ERC-20 standards, which are for fungible tokens. It’s designed for unrestricted crypto assets. And it doesn’t cover any KYC/AML enforcement, investor whitelisting, etc. But RWAs operate under strict financial regulations. So, we can’t rely only on this standard as it creates a huge compliance gap for launching institutional-grade RWA platforms.

So, which ERC standard do I need to rely upon???

ERC-3643 is the security token standard that is specifically built for regulated assets. It’s often called the T-REX protocol(Token for Regulated Exchanges).

ERC-3643 standard supports over $32 billion in tokenized assets to date.

The ERC-3643 ecosystem is commonly distributed under the GNU GPL v3.0 license, meaning derivative modifications to the core framework may also need to remain open-source under the same license terms. This becomes important when extending compliance modules, modifying protocol logic, or separating proprietary infrastructure from the base implementation.

It ensures the KYC/AML procedures by allowing only verified and eligible identities to hold or transfer tokens. This makes a programmable compliance all written in the code.

It’s commonly used for 

• Real Estate Tokenization
• Private Securities
• Institutional Investment Platforms

OnchainID is the identity layer that makes the claim-based model work. It is a blockchain-based identity contract permanently linked to each investor’s wallet. No personal data is stored on-chain. Instead, it holds cryptographic claims issued by trusted third parties like your KYC provider, confirming that the wallet owner passed the required checks. When a transfer is attempted, the ERC-3643 contract queries the receiver’s OnchainID for valid, active claims before the transaction executes. One OnchainID carries across multiple platforms, so an investor verified for one regulated token can reuse that same identity for any other compliant offering, no re-verification required. OnchainID handles the identity side. But identity verification alone doesn’t complete the compliance picture.

ERC-1400 is a security token framework that focuses on partitioned ownership, transfer validation, etc. It gives flexibility for complex financial instruments. However, the implementation complexity is typically higher than ERC-3643.

Despite these, some platforms use ERC-20 with a legal wrapper. That is ERC20 standard for handling token transfers and balances, and separate SCs for enforcing the KYC/AML procedures, whitelisting, and restrictions. 

Just remember that both are not mandatory. Choosing the right token standard depends on the asset class, jurisdiction, and investor eligibility enforcement needs.

Once your token standard is locked, the next question is who is actually allowed to hold these tokens? That’s what the Identity and Compliance Registry enforces.

#2 The Identity & Compliance Registry

It starts with On-chain investor whitelisting. It’s the mechanism in the token contract that restricts who can hold or transfer a regulated token through an eligibility process. 

How is it implemented? In the binary yes/no?

At the contract level, whitelisting is binary; that is, a wallet is either approved or it isn’t. But the eligibility check behind that decision is structured – KYC tier, jurisdiction, accreditation status, lock-up period, and maximum holding limits, all evaluated before the binary flag is set.

Why must it live at the contract level?

Off-chain whitelisting protects your platform but not the tokens. In RWA, we can’t leave any loose ends. Token’s security is the primary priority. The contract has no awareness of your database, so anyone can easily bypass every check you built. Contract-level whitelisting checks eligibility before any state change executes. This is what building KYC-compliant token access actually means at the protocol level.

Let’s know which of the KYC data goes On-chain and Off-chain.

KYC Data	Location
Wallet → identity link (hash/claim)	On-chain
KYC status, country, accreditation tier	On-chain
Raw PII: name, passport, address	Off-chain only
Source of funds, AML documentation	Off-chain

Raw whitelisting is static. So if an investor’s KYC expires, jurisdiction restrictions change, the admin has to manually update it. In the claim-based model, the claim issuer(3rd party KYC provider) issues a time-bound claim to the wallet. When the claim expires, the transfer attempt automatically fails.

But whitelisting covers only half the compliance obligation. KYC tells the contract who someone is. AML governs what they do after. Two additional layers apply depending on your asset class: platforms tokenizing high-value art may qualify as Art Market Participants under EU AML directives, triggering enhanced due diligence obligations beyond standard whitelisting. And cross-border transfers fall under the AMLA framework, single-jurisdiction monitoring is not sufficient. Build KYC at the contract level. Build AML off-chain but wire it to your contract.

For EU-based RWA platforms, these are not optional design choices. they are MiFID II requirements at the contract layer.

• Investor eligibility is on-chain and auditable. MiFID II requires suitability and appropriateness assessments. At the contract layer, this means the whitelist flag must encode investor classification tier retail, professional, or eligible counterparty and not just a binary KYC pass.
• Claims are time-bound. MiFID II requires ongoing investor eligibility. Expired credentials must automatically block transfers. A static whitelist flag is insufficient.
• Every transfer traces back to a verified identity. MiFID II transaction reporting obligations require counterparty identification. Off-chain KYC provider stores the PII; the on-chain claim provides the cryptographic link for audit.

Alright, now we can move to the binding agent that connects the asset to the blockchain network.

#3 The Asset Binding Layer

Well, the token on-chain is not the asset when the actual asset exists in the real-world. Smart contracts connect the legal documents of your particular asset through

• A document hash stored in the contract, which is a cryptographic fingerprint of the legal doc.
• An IPFS link pointing to where the document is stored(usually in a decentralized system)
• Metadata fields that identify the asset type, jurisdiction, issuer, legal entity, etc.

Then you need the legal wrapper to represent your asset in global standards.

SPV Structure

We’ve seen the SPV earlier, and it’s the dominant globally because SPV owns the real-world asset. And investors buy tokens that represent shares in the SPV and not the asset directly. This thus creates a legal bridge between the assets and investors.

SPV is irresistible as it usually applies to maximum asset types. Here are the 4 major factors why it dominates globally.

1. Legal clarity
2. Bankruptcy isolation
3. Jurisdiction flexibility
4. Existing investor rights

Fine, what happens if the legal state changes?

3 functions are triggered.

Default — This can freeze transfers, halt distributions, and initiate a recovery or liquidation process automatically, without waiting for a legal ruling to be manually implemented.

Title transfer — This updates the asset reference in the contract that are new legal document hash, new SPV ownership record. Token holders remain in place; what changed is what their token now points to.

Redemption — At maturity or fund closure, calculates each token holder’s proportional value, distributes stablecoins or proceeds, and burns the tokens.

In all cases, 

The trigger is off-chain (a legal event happens in the real world), 

But the response is on-chain (the contract executes automatically once the authorized party signals it).

So what’s the enforceability limit?

Smart contracts cannot

• Force a court to recognize a token holder’s claim if the SPV is challenged.
• Operate in a jurisdiction that doesn’t recognize blockchain-based ownership.
• Stop a government from seizing the underlying asset. The token survives, but what it represents doesn’t.
• Compel a counterparty to honor a legal agreement. It can withhold payment, but it cannot sue.
• Resolve disputes over whether the referenced legal document is valid, forged, or outdated.

Smart contracts are excellent at automating legal outcomes. They are not capable of creating legal outcomes where the underlying legal structure fails.

This is why the legal instrument and the technical contract must be designed together.

#4 Upgrade & Admin Governance

Upgrades are inevitable. Compliance rules change, KYC/AML thresholds shift, and jurisdiction-specific regulations get updated. At this time, regulators make those changes mandatory post-deployment. 

ERC-1967 solves this by separating the proxy contract(holds token balances, investor registry) and the implementation contract(holds business logic).

With ERC-1967,

• Compliance logic can be updated when regulations change without disrupting existing token holders.
• Custodians, exchanges, and regulators always interact with the same contract address, no re-whitelisting needed.
• ERC-1967 uses fixed storage slots for the upgrade pointer, keeping the contract auditable and predictable.

For governance, multi-sig is usually preferred. We do know the importance of compliance updates being fast and decisive. On-chain governance is slightly delayed. Let’s see the key factors that make multi-sig the best option for governance.

Factors	Multi-Sig	On-Chain Governance
Speed	Fast (hours)	Slow (Days-Weeks)
Transparency	Partial (Off-chain discussion)	Fully on-chain, auditable
Regulatory Fit	Preferred in early-stage / regulated contexts	Better for decentralized community-driven protocols
Complexity	Low	High
Attack Surface	Key Compromise	Flash loan / Governance attacks

Also, if a single private key controls the platform’s upgrade or pause functions, once compromise can freeze or corrupt the entire tokenized fund. This brings technical and regulatory risks. Layered governance is the fix for this problem. 

Multi-sig ensures no single person can act alone. The timelock gives auditors and stakeholders a window to catch malicious changes before they execute.

The four layers above are also the four places where RWA platforms fail security reviews, whitelisting bypass paths, single-admin upgrade proxies, oracle manipulation at low update frequency, and SPV binding that drifts from the live legal instrument. Before investor onboarding begins, the compliance module, Oracle wiring, and governance structure need a dedicated pre-launch review. InnBlockchain’s RWA Platform pre-launch audit covers all four failure points with zero critical exploits across 12+ production deployments.

How to Bring Off-Chain Asset Valuations On-Chain Without Creating Attack Surfaces

Oracle design is where most RWA platforms fail. A single manipulated price feed triggers the wrong redemption. DeFi Oracles and RWA Oracles aren’t the same. They differ by frequency and source. DeFi Oracles pulls market-derived prices and updates by second. RWA gets valuations from appraisers, auditors, and fund admins, which are updated weekly/monthly.

This low updated frequency creates a large space for manipulation, and that’s the core problem every RWA platform developer needs to solve.

3 Oracle models are brought to solve this case.

1. Centralized Push Oracle

The issuer or fund admin pushes NAV and price updates directly. It’s easy to implement and common in tokenized funds, but it’s a single point of failure.

2. Multi-party Attestation Oracle

Multiple independent valuers must each sign off before any state update is accepted. This is the standard used in tokenized real estate and private credit, where valuation disputes are common and regulatory scrutiny is high.

3. On-chain Audit Trail Oracle

The price update is cryptographically signed and paired with an off-chain evidence hash, creating a verifiable paper trail that auditors can inspect at any point.

But choosing the right model solves only half of the problem. The other half is what happens when the oracle misbehaves. So, you need to implement the key design rules.

Key Design Rules

• Deviation thresholds and circuit breakers ensure that any price update moving beyond a defined percentage gets rejected automatically without explicit governance approval.
• Heartbeat requirements define what the contract does when the Oracle goes silent, whether freezing transfers, halting redemptions, or triggering an alert.
• Who controls the Oracle feed must be visible on-chain. Regulators want to know who has the authority to set asset prices for tokenized funds.

If your oracle uses AI/ML for valuation, the EU AI Act may classify it as high-risk AI. That means immutable audit trails, regulator-readable model documentation, and human oversight become mandatory. A centralized oracle without verifiable evidence trails becomes a compliance risk. The compliant approach is an on-chain audit trail oracle using cryptographic signatures and off-chain evidence hashes. If AI-assisted valuation is part of your platform, this must be designed into the architecture before launch.

Under DORA, oracle providers used by EU-regulated RWA platforms are classified as ICT third-party service providers. Your contracts with oracle providers must include DORA-compliant clauses like audit rights, performance SLAs, incident notification timelines, and exit/substitution plans. A platform that switches oracle providers post-launch without documented substitution procedures is a DORA compliance gap.

It’s time to get jurisdiction-specific. Let’s see how to integrate MiFID at the contract level. I’ve chosen MiFID since it’s the mandatory law for 30 countries.

MiFID II Compliance: What the EU Framework requires at the contract level

MiFID II is your governing framework when your token represents a financial instrument that can be a tokenized bond, fund share, real estate security, or any instrument carrying equity-like return rights, ownership claims, or creditor entitlements. 

Under MiFID II, token classification is determined by the economic substance of the instrument, not its technical format. A token that grants fractional ownership of a real estate SPV, distributes yield from an underlying asset, or confers redemption rights at maturity is a transferable security, regardless of whether it is issued on-chain. That classification triggers the full authorization requirements, investor eligibility framework, and disclosure obligations that MiFID II imposes, none of which can be satisfied by an alternative compliance structure designed for a different instrument class.

How MiFID II classifies your token matters before you write a single line of compliance logic?

Under MiFID II, tokenized RWAs are typically assessed as:

• Transferable Securities — Tokenized bonds, equity-like instruments, fund shares. Full MiFID II obligations apply.
• Units in Collective Investment Undertakings — Tokenized fund interests. Subject to UCITS or AIFMD in addition to MiFID II.
• Other Financial Instruments — Tokenized debt instruments, structured products.

Classification determines which on-chain functions are mandatory. You need to determine your instrument classification before writing your compliance module. Misclassifying as a utility token or ART to avoid MiFID II obligations is an enforcement risk, not a legal workaround.

The four contract-level requirements are listed below.

1. Investor Classification Eligibility Enforcement

MiFID II mandates distinguishing between retail, professional, and eligible counterparty investors. Your contract must enforce eligibility at the transfer level via an on-chain whitelist or identity registry that reflects investor classification tier not just KYC status. Retail investors trigger additional suitability and appropriateness obligations. All eligibility logic must be auditable on-chain.

2. Transfer Restrictions by Authorization Status

Transfers must be restricted to wallets linked to MiFID II-authorized entities or eligible investors. Implement a jurisdiction and authorization registry that maps wallet addresses to investor classification and country codes, and build transfer guards that block non-compliant pairings. Cross-border transfers carry additional obligations under the EU’s settlement framework.

3. Prospectus and Disclosure Requirements

Public offerings of tokenized securities above the MiFID II threshold require a prospectus or Key Information Document (KID). At the contract level, implement a document hash binding the current prospectus version to the token contract. Any material change to the underlying asset or instrument terms must trigger an on-chain disclosure event.

4. Redemption and Settlement Rights

Token holders must have a technical path to redemption aligned with the settlement obligations under MiFID II. Smart contracts must support T+1 or T+2 settlement cycles where applicable, and redemption logic must be non-custodial — a contractual right alone is not sufficient.

EU platforms with secondary marketplace functionality, which is post-issuance trading of tokenized securities, operate under the DLT Pilot Regime (EU Regulation 2022/858). This is the authorised infrastructure path for on-chain securities trading and settlement (DLT MTF / SS / TSS), sitting alongside MiFID II authorization, not replacing it. Design your settlement and matching engine to DLT Pilot specifications from the start.

Does MiFID II specify a token standard, blockchain, or oracle architecture?

MiFID II is not a technical standard. It is an investor protection outcomes framework.

It does not mandate ERC-3643, any specific blockchain, or oracle architecture. What it mandates are outcomes like investor eligibility enforcement, disclosure, settlement rights, and redemption mechanics. How you achieve those outcomes at the contract level is your architectural decision. 

MiFID II is the complete framework for this platform. Instrument classification comes first and everything else in your compliance module follows from it.

You’ve got the blueprint on tokenizing your real world asset, let’s see what’s next.

How architecture differs by asset class

Not all the real-world assets’ tokenization procedures are the same. For some, SPV is mandatory, and for some, it remains optional.

Real Estate	SPV Legal Wrapper Title Registry Oracle Jurisdiction-based Transfer Restrictions
Private Credit	Repayment Logic Borrower Default Triggers Off-chain Loan Agreement Binding
Commodities	Custodian Attestation Oracle Reserve Proof Redemption Mechanics
Vehicle & Fleet	Asset Registry Sync Depreciation Oracle  Multi-owner Fractionalization
Art & Collectibles	Provenance Chain Physical Custody Oracle Resale Royalty Enforcement
Invoices	Payment Contract Invoice Verification Oracle Borrower Default Trigger
Infrastructure & Funds	SPV Mandatory Revenue Oracle Yield Distribution Contract

Where to start? – The First Technical Decision

Real world asset tokenization is a widely adopted concept all over the world. It takes a stringent technical development and auditing process, as it involves legal requirements and standards. Any single failure will cost your whole asset, investors’ funds, and the trust you gained in the market. Smart contracts are fundamental but choosing the right standards and methodologies will enable you to successfully run your business. 

In RWA, success means that you’ve started your RWA platform with 100% compliance. Choosing the right tech partner with deep knowledge and experience is crucial. InnBlockchain builds and audits RWA tokenization platforms from SPV binding and token standard selection to oracle wiring, KYC registry deployment, and pre-launch compliance audit.

Either building from scratch or a white-label solution, scope your token design, identity registry, oracle model, and governance structure with our team and get your platform delivered within 7 days.

FAQs

1. What is tokenization of real assets?

Tokenization converts ownership rights of physical assets like real estate, gold, vehicles, etc, into blockchain-based digital tokens that can be traded, transferred, or fractionalized securely.

2. How does real world asset tokenization work?

Register your asset under a legal wrapper, i.e., SPV, deploy a compliant smart contract with ERC3643/1400. Then link the legal docs on-chain and onboard verified investors through KYC whitelisting.

3. What real-world assets can be tokenized?

Real estate, Private credit, Commodities like gold, oil, Vehicles, Invoices, Art & collectibles, Infrastructure and funds with proper legal structure and verified ownership can be tokenized.

4. What role do smart contracts play in the tokenization of assets?

Smart contracts enforce compliance, automate ownership transfers, distribute revenue, manage investor whitelisting, and bind the token to the underlying legal procedure without human intervention.

5. What is a real-world example of tokenization?

BlackRock’s BUIDL fund tokenizes U.S. Treasury holdings on Ethereum, allowing institutional investors to hold and transfer fund shares on-chain with automated compliance and settlement.

6. What is the difference between MiCA and MiFID II for RWA tokenization?

MiCA governs crypto-assets that are not classified as financial instruments that are utility tokens, asset-referenced tokens, and e-money tokens. MiFID II governs tokenized financial instruments such as bonds, fund shares, and equity-like securities. Most institutional RWA platforms, real estate securities, tokenized funds, and private credit fall under MiFID II, not MiCA. Using the wrong framework as your compliance baseline is an enforcement risk.

7. Which crypto will be used to tokenize real estate?

Ethereum is the dominant network, Polygon and Solana are also used. The token standard (ERC-3643 or ERC-1400) matters more than the chain for regulated real estate tokenization.

8. What is the real-world asset tokenization market size?

The tokenized RWA market crossed $15B in 2024 and grew 260% in H1 2025. And is expected to grow from $2T to $16T by 2030, driven by institutional adoption.