Everyone talks about the token. Almost nobody talks about what sits underneath it.
I've built tokenization architectures across real estate, industrial financing, and securities platforms. The pattern is consistent: the token contract is the simplest layer. What determines whether a project survives — legally, operationally, and economically — is the infrastructure beneath it: custody, compliance, identity, policy enforcement, legal wrappers, and reconciliation between what the blockchain says and what regulators recognize.
The following five layers form that stack. Not as a vendor catalogue, but as a map of what must be true in the production infrastructure for an RWA to actually work.
Layer 1: The Legal Wrapper
The blockchain knows nothing about property deeds, corporate equity, or commodity ownership. Every tokenized asset needs an off-chain legal entity that holds the actual asset and gives the token weight. The legal wrapper is what bridges from code to reality.
Real estate is clearest: an SPV (Special Purpose Vehicle), usually a limited company in the property's jurisdiction, holds the property. Token holders own shares in it. Smart contracts automate distributions — the SPV declares dividends, the contract routes them to wallets.
Securities are more regulated. They require registration as a security (or a valid exemption) in every jurisdiction where they trade. The legal entity behind that registration carries ongoing reporting and compliance obligations.
Industrial financing demands richer architecture. I designed one tokenization spanning three entities across three countries: a local operating company procuring commodities, a digital hub managing the technology layer, and an offshore settlement entity handling stablecoin flows. Each answered to its own regulator. Smart contracts enforced allocation rules written into the underlying legal agreements.
The critical decision: how tightly to couple the smart contract to the legal obligation. A distribution contract only has weight if the SPV is legally bound to fund it. Mismatch happens when the legal agreement says quarterly distributions at board discretion but the contract distributes automatically on oracle data. The contract executes code; the legal entity executes law. Misalign them and the gap becomes a liability.
Layer 2: Custody
Most tokenization whitepapers skip custody. In production systems, it's where projects stall.
Where are the digital assets stored? Who controls the keys? The answer cascades: regulatory compliance, operational security, disaster recovery, and whether institutions will touch it at all.
Two distinct layers exist here, and teams routinely conflate them. The platform-level governance layer is a multisig — multiple authorized signers from the platform's management team approve critical operations: treasury movements, contract upgrades, parameter changes. This is corporate governance written on-chain. Beneath it sits individual key management for users and operational wallets, typically using MPC (Multi-Party Computation) or HSM (Hardware Security Module) infrastructure. The multisig controls what the platform can do. MPC controls how individual keys are stored and used.
MPC works by splitting the signing key into fragments distributed across multiple parties. No single fragment can sign a transaction — typically two of three shares are required. One lives on the client's hardware, one in the custody provider's cloud infrastructure, one on a security module at the client's facility. MPC can also operate as a sub-component within the multisig structure itself — each signer in a multisig wallet holds their key split as MPC fragments rather than a single private key, creating a second layer of compromise resistance.
Deployment model choice matters more than the underlying technology. Hybrid arrangements (some key shares in provider cloud, one co-signer at your facility) are operationally simpler. Full self-custody (all key shares under your control) satisfies regulators demanding complete asset sovereignty — essential when your regulator is a central bank.
Then there's cold storage architecture. Some systems keep a vault permanently air-gapped from the internet — no connectivity during deposits, withdrawals, or operations, with transactions signed via hardware bridge across the gap. Others bring the cold vault online briefly for operations. This distinction is academic until you're explaining to a regulator how a state-level attack on your internet infrastructure affects the assets you hold.
Policy engines enforce governance rules. Mature implementations work at the function level — not "this wallet sends $X" but "this wallet calls distribute() on this address, up to amount Y, requiring two of three signers." A pre-execution callback verifies compliance before any custody operation proceeds: blocking transfers to sanctioned addresses, enforcing central bank transaction limits, requiring multi-approver workflows above thresholds.
For tokenization projects, custody covers the token itself, operational currencies (stablecoins for settlement, fiat-pegged distributions), and any collateral sitting in DeFi. Multi-asset, multi-chain architecture expands the policy surface significantly.
Layer 3: Compliance and Identity
A security token without transfer restrictions isn't compliant — it's regulatory liability.
The minimum stack covers: KYC verification on every holding wallet. AML monitoring on every transfer. Sanctions screening against OFAC, UN, and local watchlists. Travel rule compliance — originator and beneficiary data on every transaction.
Implementation typically uses an off-chain whitelist of approved wallet addresses. Only whitelisted wallets receive the token. Wallet owners pass KYC before whitelisting. When a wallet is removed (investor status change, sanctions flag, whatever the reason), the token becomes non-transferable from that address.
Standards like ERC-1400 embed transfer restrictions directly into the contract logic. The contract queries a compliance module before each transfer — cleaner than a separate whitelist, but requires the module on-chain and responsive in real-time.
SoulBound Tokens emerged for on-chain identity. A non-transferable token issued post-KYC, acting as a portable compliance credential across platforms. Architecturally elegant. Legally unproven. As of this writing, no major regulator has formally confirmed an SBT satisfies KYC requirements. They supplement traditional compliance rather than replace it.
Compliance gets harder across borders. A US-to-EU transfer may need SEC and MiCA clearance. Emerging-market transfers add local watchlist screening. The engine evaluates originator, beneficiary, asset, and jurisdiction pair — then returns yes or no before execution.
Transaction monitoring flags AML red flags in on-chain flows: unusual volumes, rapid inter-wallet movements, structuring to evade thresholds. Chainalysis KYT integrates with custody platforms. Some providers offer native integration; others require custom middleware.
Real talk: tokenized securities compliance works but is immature. The tools function. Integration patterns exist. But regulators are still writing standards for "adequate" compliance. Design for today's requirements with flexibility to adapt as the standards harden.
Layer 4: The Smart Contract Architecture
The smart contract layer gets all the attention and most of the overestimation.
Production systems don't run on one contract. A real estate tokenization typically includes several:
Asset token — ERC-20 for fungible fractional ownership, ERC-721/ERC-1155 for unique assets. If it's a security, ERC-1400 (one of the more widely adopted standards) adds transfer restrictions and compliance hooks. Your choice of standard determines what the DeFi ecosystem can do with it.
Distribution — routing dividend and rental income to holders. Depends on custody (where funds originate) and compliance (confirming recipients are KYC-verified). Tax withholding varies by holder jurisdiction, so "automated distribution" is messier than it sounds.
Governance — voting on property management, renovation budgets, corporate actions. Structures range from simple majority to weighted voting with quorum and time-locks.
Initial sale — primary distribution via fixed-price, Dutch auction, or whitelist. Must verify investor qualification and hook into the compliance whitelist.
Secondary market — where things get economically uncomfortable. Two models, both incomplete.
Option one: DEX pool integration with an AMM. AMMs need liquidity to function at all, but users rarely volunteer capital for niche tokenized assets. The platform itself must seed the pool — capital locked up earning LP fees but exposed to impermanent loss and directly reducing returns from the entire exercise. Separately, AMMs are permissionless by design; securities transfers aren't. Permissioned pools and whitelisted AMM wrappers exist but lack standardization.
Option two: P2P trading through an order book contract. No liquidity pool. The tradeoff: there may be no counterparty for a given trade. Thin order books produce wide spreads, slow execution, or no fill at all. The platform can act as market maker — providing the other side of the trade — but that requires reserved capital and creates conflict-of-interest questions.
Both paths share a structural problem: the pool price or the last OTC trade may not reflect the real-world asset value. A tokenized apartment priced by a thin AMM or single OTC trade has no mechanism to track an independent appraisal. If your business model depends on price accuracy — for collateralization, NAV reporting, or redemptions — you must actively maintain price parity. Oracles, active market-making, arbitrage incentives. Each costs money. None guarantee convergence.
There is no clean secondary market design for tokenized securities. Every approach trades off liquidity cost, price accuracy, regulatory compliance, and capital efficiency against each other.
Oracle — required when on-chain logic depends on real-world data (property valuations, rental income, commodity prices). RWA oracles are less reliable than price feeds: less frequent updates, less standardization, harder to verify on-chain.
Identity — the on-chain compliance layer. Manages whitelists, SBT verification, transfer restriction logic.
These contracts communicate across boundaries. Distribution calls identity to verify recipients. Secondary market checks compliance before approving trades. Governance updates distribution parameters. Oracles feed data into both governance and distribution.
Each contract requires individual audit plus cross-contract interaction audit. The vulnerability surface doesn't live in the contracts themselves — it lives in the paths between them. Cross-chain bridge exploits follow the same pattern: contracts individually audited, but the interaction layer created the attack vector.
In projects I've scoped, audit costs for multi-contract systems — three rounds, tier-one auditor — ran $30,000–$80,000. Not negotiable. Budget it from the start.
Layer 5: Off-Chain / On-Chain Reconciliation
This layer is the most operationally demanding: keeping on-chain state synchronized with off-chain reality.
The shape of the problem: On-chain, wallet 0xABC holds 1,000 tokens representing 10% of Property XYZ, SPV Registration #12345. Off-chain, the SPV's corporate registry lists 0xABC as a 10% shareholder, property appraisal is $2M, rental income last month was $15,000. When the SPV declares dividends, on-chain distributions must match. When an investor sells tokens, the share register updates. When property reappraises, on-chain valuation reflects it.
Traditional finance has back-office operations, custodian banks, and clearinghouses to handle this reconciliation. Tokenized finance assumes it's automated. Reality: automation handles the happy path — standard distributions, clean transfers, uncontested valuations. Edge cases require human judgment — disputed appraisals, investor deaths, regulatory freezes, SPV actions affecting token economics — and manual off-chain/on-chain sync.
I designed one reconciliation service spanning core ledger (SDK.finance), custody layer (GK8), and on-chain contracts, using Kafka for state propagation and webhook settlement confirmations. It tracked obligations across entities, triggered distributions on off-chain events (invoices paid, commodities sold, rent collected), and reconciled ledger balances with blockchain state.
Here's where "blockchain automates everything" collides with the operational world. Automation works for structured, predictable events. Everything else — is this appraisal correct, should this distribution be delayed, is this investor still qualified — demands human judgment integrated with the on-chain system.
What Must Be True
Remove the vendor names and the requirements become clear:
Legal wrapper: an enforceable obligation between off-chain asset and on-chain token. Without it, the token claims nothing.
Custody: regulatory compliance for all involved jurisdictions, multi-asset and multi-chain capability, policy precision matching business rules.
Compliance: transfer restrictions, continuous investor qualification verification, multi-jurisdictional rules applied per transfer in real-time.
Smart contracts: issuance, distribution, governance, trading, valuation, identity — built as interacting systems, not isolated tokens.
Reconciliation: on-chain state kept synchronized with off-chain reality, edge case handling that exceeds automation, regulatory audit trails.
Each layer adds cost, complexity, and operational surface area. Any one can kill a project. Together, they constitute the hidden stack beneath the token — the part nobody discusses and where most projects actually fail.
Key Takeaways
- The token contract is the simplest component of a production tokenization project — the infrastructure beneath it determines success or failure
- Legal wrappers (SPV, regulatory registration) connect the token to enforceable rights — without them, the token is a claim on nothing
- Custody architecture choices (air-gapped vs cloud, hybrid vs self-custody, policy granularity) are driven by regulatory requirements, not just security preferences
- Compliance for tokenized securities requires real-time transfer restrictions, multi-jurisdictional KYC/AML, and sanctions screening on every transfer
- Production tokenization requires 6–7 interacting smart contracts, each audited individually and for cross-contract interactions
- Off-chain/on-chain reconciliation is the most operationally demanding layer — automating the happy path is tractable; handling edge cases requires human judgment integrated with the on-chain system