A technical guide to building an RWA tokenization platform — smart contracts, investor onboarding, KYC, cap table management, distribution engine, and compliance architecture.
Gizmolab Team
·15 min read
Share:
What is an RWA tokenization platform?
An RWA (Real-World Asset) tokenization platform is software that enables the issuance, management, and transfer of blockchain tokens that represent ownership or economic rights in real-world assets — such as real estate, private credit, investment funds, or treasury instruments. The platform handles investor onboarding, token issuance, transfer restriction enforcement, distribution management, and investor reporting.
Tokenization platforms are not just smart contracts — they are full-stack products. The smart contract layer enforces rules on-chain; the platform layer handles compliance, UX, and operational management. This guide covers both layers and the architecture decisions that matter.
Start With the Legal Structure
The answers to these questions directly map to smart contract configuration, KYC requirements, and investor eligibility rules in the platform.
What legal entity holds the asset? (Usually an SPV — Special Purpose Vehicle)
What do tokens represent? (Equity in the SPV, debt, revenue share, or other economic rights)
What securities exemption applies? (Reg D for US accredited investors, Reg S for non-US, or local equivalent)
Who is eligible to hold tokens? (Accredited investors only, institutional investors, retail with restrictions)
What transfer restrictions apply? (No transfer, transfer only to eligible investors, lockup periods)
What jurisdiction governs? (Determines the regulatory framework the platform must enforce)
Token Standards: ERC-1400 and ERC-3643
Standard ERC-20 tokens are unsuitable for security tokens — they can be transferred to any address without restriction, which violates securities law in virtually every jurisdiction. Security token standards add transfer restriction enforcement on-chain.
ERC-1400 (Security Token Standard)
ERC-1400 is a security token standard that extends ERC-20 with: token partitions (tranches for different share classes or lockup periods), transfer restrictions with on-chain validation, forced transfers for regulatory actions, and document attachment (link legal documents to the token).
ERC-1400 is a broad standard — the transfer restriction logic is extensible. Most implementations pair it with a whitelist contract that maps eligible investor addresses.
ERC-3643 (T-REX Protocol)
ERC-3643 (T-REX) is a more opinionated security token standard with built-in identity framework. It uses on-chain identity claims (verified by trusted claim issuers) to gate transfers. An investor's wallet address must have an approved identity claim before receiving tokens.
T-REX is favored by institutional tokenization platforms. The on-chain identity layer provides more sophisticated access control than a simple whitelist.
Which to Use
For most real estate and fund tokenization products, either standard works. ERC-1400 with a whitelist is simpler to implement and audit. ERC-3643 is preferred when on-chain identity composability matters (e.g. tokens usable across multiple platforms with shared identity verification). Both are deployed on Ethereum-compatible chains (Ethereum, Polygon, Base).
Investor Onboarding and KYC
Before an investor can subscribe and receive tokens, the platform must verify their identity and eligibility. The onboarding flow:
01
Account creation: Investor creates an account with email and basic information.
02
KYC verification: Identity document upload and verification via KYC provider (Sumsub, Onfido, or Persona). Typically takes minutes for automated checks; may require manual review.
03
Accreditation check: For Reg D offerings, accreditation status must be verified. This may be self-certification, document review, or third-party verification depending on the offering terms.
04
Wallet address registration: Investor provides a wallet address (or a wallet is created for them by the platform). This address is whitelisted in the smart contract.
05
Eligibility confirmation: Platform confirms the investor meets all eligibility criteria before allowing subscription.
Wallet Options
Investors can use their own external wallet (MetaMask, hardware wallet) or the platform can provision a custodial or smart wallet for them. For institutional investors, self-custody is standard. For retail-oriented platforms, a custodial or embedded wallet reduces friction.
Subscription and Token Issuance
Once an investor is onboarded, the subscription flow proceeds:
01
Offering review: Investor reviews the property or asset page, investment terms, offering documents, and financial projections.
02
Subscription document acknowledgement: Investor acknowledges or signs the subscription agreement (digital signature via DocuSign or equivalent, or on-platform acknowledgement).
03
Payment: Investor sends funds — via bank transfer or stablecoin (USDC/USDT). For stablecoin subscriptions, the gateway matches the incoming transfer to the investor and subscription amount.
04
Admin review (optional): For large investments or admin-configured offerings, a platform admin reviews and approves the subscription before token issuance.
05
Token minting: Smart contract mints the correct token amount to the investor's whitelisted wallet address. Token transfer event is emitted on-chain.
06
Investor portal update: Investor's dashboard shows updated holdings, subscription confirmation, and access to investment documents.
Cap Table Management and Distributions
The cap table tracks who holds what token amount at any point in time. For tokenized assets, the on-chain token registry is the authoritative cap table — every transfer event updates it. The platform's admin dashboard reads from the on-chain state and displays the investor registry.
Distribution Engine
When the asset generates income (rental income, loan repayments, fund distributions), the platform calculates each token holder's entitlement proportional to their holdings and initiates payment.
Distribution workflow: (1) Admin enters the total distribution amount; (2) Platform queries the token contract for current holder balances and calculates each holder's share; (3) Admin reviews the distribution calculation; (4) Distributions are sent — via stablecoin transfer to each investor's wallet address, or via bank wire to investors who prefer fiat.
Secondary Transfers
If the offering permits secondary transfers, investors can transfer tokens to other eligible investors. The smart contract enforces the whitelist check — the receiving address must be an approved investor. The platform records the transfer and updates the off-chain investor registry to match.
Admin and Investor Portals
A tokenization platform requires two distinct interfaces:
Most RWA tokenization platforms deploy on Ethereum or an Ethereum L2 (Polygon, Base, Arbitrum). Ethereum has the most established security token ecosystem and institutional familiarity. Polygon and Base offer lower gas costs for distribution transactions at scale.
Key considerations: gas cost for minting and distributions (relevant when distributing to many investors), token standard library availability (ERC-1400/ERC-3643 implementations are mature on Ethereum/Polygon), institutional wallet support (custody providers support Ethereum and major L2s), and regulatory familiarity (Ethereum is better understood by regulators and legal counsel).
FAQ
How long does it take to build a tokenization platform?
A production-ready platform with investor onboarding, token issuance, cap table management, distribution engine, and investor portal typically takes 14–22 weeks depending on scope. Smart contract development and audit add time. Stablecoin subscription flows, multi-asset support, and secondary transfer capability extend the timeline.
Does the platform need to be audited?
Smart contracts should be audited before going live with investor funds. A reputable audit (Trail of Bits, OpenZeppelin, or similar) typically takes 2–4 weeks and adds meaningful cost to the project. Platform security reviews (authentication, access control, key management) are also important. Gizmolab recommends and coordinates audits as part of project delivery.
Can the platform support multiple asset types?
Yes. The architecture can support multiple asset types — real estate, private credit, funds, treasury instruments — each with separate smart contract instances, different token economics, and independent distribution schedules. A multi-asset platform allows investors to hold a diversified portfolio across different tokenized investments within the same account.
What is Gizmolab's role in a tokenization project?
Gizmolab builds the technology platform — smart contracts, investor onboarding, KYC integration, subscription flows, admin dashboard, investor portal, and distribution engine. We do not provide legal structuring, regulatory advice, investment management services, or custody. The legal structure, securities compliance, and investment terms are defined by the issuer and their qualified legal counsel.
Key Takeaways
Legal structure first — the technology platform is built to support the legal structure, not define it. Work with qualified legal counsel before development.
ERC-1400 or ERC-3643 security token standards enforce transfer restrictions on-chain — plain ERC-20 is not suitable for tokenized securities.
Investor onboarding (KYC, accreditation, wallet whitelisting) must be completed before subscription and token issuance.
The cap table is maintained on-chain — every token transfer updates the authoritative registry.
Smart contract audit is strongly recommended before going live with investor funds.
The platform builder provides the technology layer — not legal, regulatory, investment management, or custody services.