PROPELOO

REAL ESTATE TOKENIZATION / RWA

Tokenize property ownership with the legal and technical infrastructure that makes it actually work.

PROPELOO engineers real estate tokenization platforms — from SPV legal wrapper design and ERC-3643 compliance token architecture through investor onboarding, primary issuance, rental income distribution and secondary market infrastructure. A property token that cannot legally transfer between investors is not a product.

The token is easy. The legal structure, the transfer restrictions, and the income distribution are where most real estate tokenization projects fail.

Real estate tokenization is not an NFT of a building. A tokenized property interest is a fractional ownership claim in a legal entity — typically an SPV — that holds the property. The token must represent that ownership correctly, enforce transfer restrictions under securities law, carry KYC state at the token level so compliant transfers happen on-chain without intervention, distribute rental income proportionally and automatically, and support a secondary market where investors can exit. Most projects discover these requirements after the token is deployed — when their first investor tries to sell and finds no legal mechanism to transfer ownership. PROPELOO designs the legal-technical architecture first: SPV structure, token standard selection, investor identity registry, transfer restriction logic, income distribution contract and secondary market mechanics — before a line of code is written.

The full stack of a real estate tokenization platform.

A tokenized property platform is six distinct systems — legal, compliance, issuance, token, income and secondary market — that must work together correctly for a single investor transaction to complete.

System Layers

  • Legal & Wrapper Layer: SPV formation, property title transfer into SPV, offering document structure, jurisdiction-specific securities exemption (Reg D, Reg S, SEBI, DFSA)
  • Compliance & Identity Layer: ONCHAINID identity registry, investor accreditation verification, KYC/AML provider integration, sanctions screening, whitelist management
  • Token & Smart Contract Layer: ERC-3643 token deployment, transfer restriction module, compliance module hooks, dividend distribution contract, forced transfer mechanism
  • Issuance & Investor Portal: Primary raise mechanics, investor onboarding, subscription agreement signing, allocation and cap table management, payment processing (fiat and crypto)
  • Secondary Market & Liquidity: OTC matching, regulated secondary trading venue integration, AMM liquidity module for permissioned pools, transfer settlement

Core Technical Capabilities

  • SPV & Legal Architecture

    Special Purpose Vehicle structuring for property ownership — jurisdiction selection, ownership transfer, regulatory framework (Reg D/S, MiCA, VARA, DFSA) and offering document architecture that determines what the token legally represents.

  • ERC-3643 Token Engineering

    T-REX protocol implementation — on-chain identity registry (ONCHAINID), compliance module configuration, transfer restriction enforcement at the contract level, forced transfer for compliance actions and modular token architecture.

  • Investor Onboarding & KYC

    Tiered investor onboarding — identity verification, accreditation checking, jurisdiction screening, document signing (eSign) and automated whitelist updates on the ONCHAINID registry when KYC status changes.

  • Primary Issuance Platform

    Fundraising mechanics — SPV cap table management, subscription agreement processing, allocation engine, minimum/maximum investment enforcement, soft cap logic and investor dashboard showing holdings and returns.

  • Rental Income Distribution

    Automated on-chain income distribution proportional to token holdings — triggered by off-chain rental income events, stablecoin (USDC/USDT) distribution to investor wallets, distribution history and tax reporting export.

  • Secondary Market Infrastructure

    Permissioned secondary trading — OTC order matching between whitelisted investors, integration with regulated secondary venues (tZERO, ADDX), or AMM-based liquidity pools with KYC transfer hook enforcement on every swap.

How we think about real estate tokenization.

Real estate tokenization is a legal problem that requires a technical solution. Most teams build the technical solution first and discover the legal problem after deployment.

  • The SPV structure determines what the token is

    A token that represents a direct ownership fraction of a property title requires property law to transfer. A token that represents membership interest in an SPV that holds the property title can transfer via smart contract. The legal wrapper is not a post-hoc detail — it is the foundational architecture decision. Every subsequent technical decision follows from it.

    Axiom: LEGAL WRAPPER FIRST

  • Transfer restrictions must be on-chain, not off-chain

    Off-chain compliance gates can be bypassed by transferring tokens directly at the contract level. ERC-3643 enforces KYC status on every transfer at the contract level — the token cannot be sent to a non-whitelisted address regardless of what the front-end says. For regulated securities, off-chain compliance is not compliance.

    Axiom: ON-CHAIN ENFORCEMENT ONLY

  • Income distribution is an engineering problem, not a promise

    Rental income arrives as fiat into an SPV bank account. Converting it to on-chain distribution requires a bridge: oracle-triggered distribution contract, stablecoin treasury management, pro-rata calculation against live token holdings and a distribution event that cannot be intercepted. The promise of "earn rental income" must be backed by an auditable, automated system.

    Axiom: AUTOMATION OVER MANUAL PROCESS

  • Secondary market liquidity must be designed, not assumed

    Token holders who cannot exit their investment in a reasonable timeframe will not invest again and will not refer others. Secondary market infrastructure — OTC matching, venue integration or AMM pools — must be part of the platform design, not a roadmap item. The liquidity story must be credible before the first investor commits.

    Axiom: EXIT MECHANISM AT LAUNCH

The decisions that define a real estate tokenization platform.

These choices have legal, operational and technical implications that cannot easily be changed after investor capital is committed.

  • Token standard: ERC-3643 vs ERC-1400 vs ERC-20 with off-chain compliance?

    Impact: For regulated property tokens (securities), on-chain transfer restriction enforcement is the only architecture that satisfies most legal structures. Off-chain compliance is bypassable.

    • ERC-3643 (T-REX) — on-chain identity registry, transfer restrictions enforced at contract level, ONCHAINID standard, Tokeny reference implementation
    • ERC-1400 — modular partition-based security token, ERC-1594 for issuance, less ecosystem adoption than ERC-3643
    • ERC-20 + off-chain compliance gate — simpler contract, restrictions bypassable via direct contract call, not suitable for regulated securities
  • Legal structure: SPV per property vs fund structure vs DAO?

    Impact: SPV per property gives the clearest legal ownership structure and the cleanest token-to-property mapping. Fund structures suit diversified offerings. DAOs introduce regulatory risk that most institutional investors will not accept.

    • SPV per property — clean isolation, separate ownership, each tokenization is a standalone offering, most common for institutional property
    • Fund structure — single vehicle holds multiple properties, single token with proportional exposure, simpler for investors, pooled risk
    • DAO structure — on-chain governance for property decisions, high complexity, regulatory uncertainty in most jurisdictions
  • Income distribution: stablecoin vs wrapped fiat vs off-chain?

    Impact: On-chain stablecoin distribution is the most defensible architecture — automated, auditable and composable with DeFi yield strategies for investors who want it.

    • USDC/USDT distribution on-chain — automated, auditable, requires stablecoin treasury management
    • Wrapped fiat (EURS, GBPT) — native currency distribution, limited liquidity for large distributions
    • Off-chain bank transfer — simplest, no on-chain settlement, loses the trustlessness argument
  • Secondary market: OTC vs regulated venue vs permissioned AMM?

    Impact: Launch with OTC matching and/or a regulated venue integration. Add permissioned AMM liquidity after achieving TVL that justifies the capital commitment from LPs.

    • OTC matching engine — highest control, requires counterparty matching, no continuous liquidity
    • Regulated secondary venue (ADDX, tZERO, Archax) — existing investor base, venue takes a cut, faster to market
    • Permissioned AMM (Balancer with KYC hook) — continuous liquidity, capital efficiency, gas cost per trade
    • No secondary market at launch — fastest, reduces investor appeal significantly
  • Jurisdiction for the offering?

    Impact: Jurisdiction selection determines which investors can participate, what compliance infrastructure is required and what secondary trading is permissible. Choose the primary jurisdiction before designing the compliance layer.

    • UAE (DFSA/VARA) — strong regulatory framework, institutional investor base, no capital gains tax
    • EU (MiCA + national securities laws) — large investor pool, complex multi-jurisdiction compliance
    • Singapore (MAS) — institutional credibility, sophisticated investor requirements
    • US (Reg D / Reg S) — largest capital pool, OFAC screening complexity, accredited investor only
  • Investor identity: centralised registry vs decentralised identity?

    Impact: ONCHAINID gives the most composability — verified investor identity is portable across ERC-3643 platforms, reducing re-KYC friction for investors who want to hold tokens from multiple issuers.

    • ONCHAINID (ERC-3643 standard) — on-chain identity claims, interoperable across compliant platforms, Tokeny standard
    • Centralised KYC database + contract whitelist — simpler, single point of failure, not composable
    • W3C DIDs — decentralised identity standard, limited adoption in regulated tokenization platforms

What PROPELOO builds.

  • Residential Property Tokenization

    Fractional ownership platform for residential properties — SPV formation, ERC-3643 tokens, investor portal, rental income distribution and secondary OTC market.

  • Commercial Real Estate Tokenization

    Institutional-grade tokenization of commercial property — higher minimum investment, accredited investor restrictions, quarterly income distribution and regulated secondary venue integration.

  • Real Estate Fund Token

    Single token representing a diversified real estate portfolio — fund structure, NAV-based pricing, automated rebalancing and investor reporting dashboard.

  • Property Development Financing Token

    Debt or equity token financing a development project — milestone-based drawdown, investor reporting on project progress, capital return on completion or exit.

  • REIT Tokenization

    Digital token representation of REIT shares — compliance with existing REIT regulations, automated dividend distribution, secondary liquidity via regulated venue.

  • Cross-border Property Investment Platform

    Multi-jurisdiction platform enabling investors in one country to hold tokenized property interests in another — jurisdiction-specific KYC, FX distribution and tax reporting export.

The real estate tokenization stack.

Each layer has specific requirements driven by compliance, audit trail and investor trust.

  • Smart Contracts

    Stack: Solidity 0.8+, ERC-3643 / T-REX protocol, ONCHAINID, OpenZeppelin, Foundry (testing)

  • Compliance & KYC

    Stack: Sumsub / Jumio (KYC), Chainalysis (AML), ONCHAINID Registry, Sanctions screening (ComplyAdvantage), eSign (DocuSign / HelloSign)

  • Backend & API

    Stack: Node.js (TypeScript), PostgreSQL (cap table, investor records), Redis, AWS, Webhooks for income events

  • Frontend & Investor Portal

    Stack: React / Next.js, TypeScript, Wallet integration (MetaMask, WalletConnect), Investor dashboard, Mobile-responsive

  • Secondary Market

    Stack: OTC matching engine, Balancer (permissioned pools), ADDX / tZERO integration APIs, Settlement smart contracts, Transfer event notifications

Security in real estate tokenization protects investor ownership rights, not just funds.

A tokenization platform that loses investor KYC data, allows unauthorised transfers or distributes income incorrectly destroys legal and financial trust simultaneously.

  • Transfer restriction bypass

    The most critical attack vector. A contract with off-chain compliance gates can have tokens transferred directly at the contract level, bypassing the KYC check entirely. ERC-3643 prevents this by enforcing compliance at the token transfer hook — every transfer calls the compliance module, which queries the ONCHAINID registry. No whitelist entry means no transfer. No exceptions.

  • Income distribution manipulation

    The income distribution contract must be non-reentrant and must calculate pro-rata distribution against a snapshot of token holdings at the distribution block, not real-time balances. An attacker who can flash-mint tokens between the snapshot and distribution can claim disproportionate income. Snapshot-based distribution with reentrancy guard is the required pattern.

  • SPV access control

    The smart contract controlling the SPV digital representation must have strict access control — only authorised agents (the platform operator, compliance officer) can execute forced transfers, freeze investor accounts or update compliance status. Gnosis Safe multisig for all admin operations with minimum 2-of-3 threshold.

  • KYC data breach exposure

    Investor KYC documents (passport copies, proof of address) are highly sensitive PII. They must never be stored on-chain. Backend storage must use field-level encryption, access logging, data retention limits and GDPR/data protection compliance. The on-chain representation is a hashed claim, not the underlying document.

  • Oracle manipulation for NAV pricing

    Platforms using automated NAV-based pricing for redemptions are vulnerable to oracle manipulation if the property valuation source is not sufficiently secured. Property NAV oracles should have multi-party price submission, time delays between updates and circuit breakers that reject anomalous price movements.

  • Regulatory non-compliance risk

    Accidentally allowing investors from restricted jurisdictions (US investors in a non-SEC registered offering, sanctioned country nationals) creates legal liability that outweighs any technical failure. Jurisdiction-based IP blocking, investor self-certification, ongoing sanctions screening and automated account suspension for flagged investors are required controls.

From property to tokenized investment product.

  1. 01. Legal & Structure Design

    SPV design, jurisdiction selection, offering structure, securities exemption framework and token standard selection. Legal counsel coordination.

  2. 02. Compliance Architecture

    KYC provider integration, ONCHAINID registry deployment, accreditation verification workflows, investor whitelist system.

  3. 03. Token & Smart Contracts

    ERC-3643 token deployment, compliance module configuration, income distribution contract, forced transfer and freeze mechanics.

  4. 04. Investor Portal

    Investor onboarding flow, subscription agreement, allocation management, investment dashboard, document signing.

  5. 05. Primary Issuance

    Fundraising infrastructure, soft/hard cap mechanics, payment processing (fiat + crypto), cap table management.

  6. 06. Secondary Market

    OTC matching engine or regulated venue integration, permissioned secondary trading with compliance enforcement.

  7. 07. Income Distribution & Launch

    Automated rental income pipeline, stablecoin distribution contract, investor reporting, monitoring and launch.

Real Estate Tokenization Engagements

Fractional real estate platforms, legal SPV smart contracts and secondary liquidity escrow protocols.

  • Fractional Commercial Real Estate Tokenization Platform

    Challenge: Commercial real estate developer needed to fractionalize a $65M commercial office portfolio into compliant digital shares for accredited global investors.

    Architecture: SPV legal structure mapped to ERC-3643 security tokens, smart contracts automating investor KYC/accreditation checks, automated quarterly rental distribution contract via stablecoins, and secondary trading escrow engine.

    Outcome: Fully funded $65M property offering with 850 investors across 14 jurisdictions. Automated rental distributions executed quarterly with zero manual calculation errors.

  • Residential Property Tokenization & Secondary Escrow Marketplace

    Challenge: Real estate marketplace needed peer-to-peer compliant transfer mechanics for tokenized residential luxury villas with legal title deed verification.

    Architecture: Multi-tier token architecture with deed registry oracle verification, compliance-checked P2P order matching, automated transfer restriction enforcement, and real-time cap table updates.

    Outcome: Successfully tokenized 24 residential properties valued at $42M. Reduced legal title transfer settlement time from 45 days to 2 minutes.

  • Real Estate Tokenization Liquidity Pool & Yield Protocol

    Challenge: Property token holders required liquidity mechanisms without selling their underlying property equity at severe discounts.

    Architecture: Collateralized debt protocol allowing property token holders to borrow stablecoins against tokenized real estate equity, automated valuation updates via appraisal oracles, and conservative LTV liquidation thresholds.

    Outcome: Generated $14M in borrowing volume with zero liquidation defaults during volatile market conditions.

Frequently Asked Questions

What legal structure does a tokenized real estate offering use?

Most real estate tokenization uses an SPV (Special Purpose Vehicle) — a new legal entity formed specifically to hold the property. Investors purchase tokens that represent ownership interests (equity) or debt interests in the SPV, not the property directly. This structure allows the ownership to be represented on-chain while keeping property title in a legal entity that can be transferred via standard corporate mechanisms if needed. The exact structure (LLC, LP, SAS) depends on the jurisdiction and the type of offering.

Do real estate tokens count as securities?

In most jurisdictions, yes — tokenized fractional property ownership interests are treated as securities because investors are relying on the efforts of others (the platform operator, property manager) for returns. This means the offering must comply with securities regulations: exemption registration (Reg D/Reg S in the US, prospectus exemption in the EU, accredited investor rules in Singapore). The technical platform must enforce these restrictions. PROPELOO builds compliance-enforced platforms — we do not build workarounds for securities regulations.

How does rental income distribution work on-chain?

Rental income arrives as fiat currency into the SPV bank account. The platform converts this to stablecoin (USDC/USDT), deposits it into the income distribution smart contract, which then distributes pro-rata to all token holders based on a snapshot of holdings at the distribution date. Investors receive USDC directly to their wallet without manual intervention. The distribution is on-chain, auditable and automated. Tax reporting exports are generated separately from the distribution records.

Can tokenized property be traded on secondary markets?

Yes, with important constraints. Transfers must enforce KYC/AML restrictions — the buyer must be a verified, whitelisted investor before the transfer is permitted. ERC-3643 enforces this at the contract level on every transfer. Secondary trading options include: peer-to-peer OTC matching within the platform, regulated secondary trading venues (ADDX in Singapore, tZERO in the US, Archax in the UK), or permissioned AMM liquidity pools where every swap verifies buyer KYC status.

What blockchain should we deploy on?

For institutional real estate tokenization: Ethereum mainnet (highest institutional credibility, highest gas cost), Polygon (lower cost, widely supported, some institutional acceptance), or a permissioned chain (Hyperledger Fabric, Quorum) for deployments where public chain is not acceptable. The ERC-3643 standard is EVM-compatible. Chain selection should align with your target investor base and custody provider preferences. Avoid chains without significant institutional DeFi adoption for regulated securities.

How long does it take to launch a real estate tokenization platform?

A complete platform (SPV structure, ERC-3643 token, KYC/AML integration, investor portal, primary issuance mechanics, OTC secondary market) typically takes 16–28 weeks from architecture to first live offering. The timeline is heavily influenced by legal counsel speed (SPV formation, offering documents), KYC provider integration complexity and jurisdiction-specific compliance requirements. We deliver in milestone phases — the investor portal and token can be demonstrated well before the full platform goes live.

What KYC/AML providers do you integrate with?

Sumsub and Jumio for identity verification (document checking, liveness detection, AML screening). Chainalysis or Elliptic for on-chain transaction monitoring. ComplyAdvantage or Refinitiv for sanctions screening. ONCHAINID for on-chain identity claim management. The specific providers depend on your target markets and budget — we integrate with any provider that exposes a webhooks-based API.

Can you tokenize property in multiple jurisdictions?

Yes, but each jurisdiction adds compliance requirements. Multi-jurisdiction offerings typically use a base exemption (Reg S for non-US investors, local exemption for in-country investors) with jurisdiction-specific restrictions enforced at the platform level through IP blocking, investor self-certification and KYC rules. The token contract itself is jurisdiction-agnostic — compliance logic is in the configurable compliance module, not hard-coded. We have built platforms serving UAE, EU, Singapore and India simultaneously.