case study: real estate tokenization

Project Overview

The client came to us with a specific problem: real estate investment is structurally inaccessible to most people. Large down payments, geographic restrictions, legal complexity, broker fees — all of these sit between a retail investor and the asset class. The client's thesis was that blockchain removes these barriers, but only if the platform handles the hard parts invisibly: legal structure, compliance, payment rails, and token mechanics.

The platform we built lets any investor buy fractional ownership of rental properties as ERC-1155 tokens, earn monthly rental income in USDC, and eventually trade those tokens on a secondary market. The minimum investment is $100. Target yield: 6–12% per year on fully rented properties, paid monthly. The platform operates across the US, Indonesia, and Mexico — which added meaningful complexity around address handling, currency flows, and jurisdictional compliance.

The Architectural Challenge: Four Problems We Had to Solve Simultaneously

Building a real estate tokenization platform is not just a blockchain project. It's a financial product that sits at the intersection of property law, securities regulation, fiat payment processing, and DeFi infrastructure — all of which have conflicting requirements. These are the four core problems we solved in parallel.

Legal Architecture: Serial LLC per Property

The client consulted attorneys before starting development and arrived with a clear legal framework. We built the platform to enforce it programmatically. The structure works like this:

At the top level, a Delaware-registered master holding company (BrickFi Holding Series LLC) owns nothing directly. Its sole purpose is to simplify the legal compliance process for tokenized investment offerings. For each rental property listed on the platform, the company opens a separate Series LLC under the master's umbrella. That Series LLC owns exactly one property. It has no cross-collateralization with any other series — meaning a default on property #3 cannot touch investors in property #1.

The tokens issued for each property are legally equivalent to membership interests (equity shares) in that property's Series LLC. Holding 10% of the tokens = holding 10% membership interest in the LLC = 10% claim on rental income and asset appreciation. This is also why the client flagged SEC registration as a requirement from day one: in the US, these tokens qualify as securities under the Howey Test.

If you want to understand the broader mechanics of how this legal-plus-technical model works before building, our guide on how to tokenize real estate covers the SPV structure, jurisdiction selection, and token standard trade-offs in detail.

Token Standard: Why ERC-1155 Over ERC-721

We evaluated three implementation options for the token contract:

We chose ERC-1155. Each property gets a unique token ID within a single contract. All tokens for a given property are fungible with each other (investor A and investor B hold identical tokens for Property #5), which makes secondary market matching straightforward. Batch transfer support reduces gas costs when the admin distributes dividends across many token holders simultaneously. The contract deploys on Binance Smart Chain — lower fees and faster confirmation times than Ethereum mainnet, which matters for monthly dividend distribution at scale.

The token standard discussion was substantive. The client initially leaned toward ERC-721 for OpenSea compatibility — they wanted token holders to be able to list on external marketplaces. We built a secondary market natively into the platform instead, which gives full control over KYC gating on resales (a regulatory requirement: buyers on the secondary market must also pass accredited investor verification). The secondary trading panel was built but kept disabled until the platform received SEC committee clearance. That's not a technical limitation — it's a compliance-first design decision. For teams comparing internal marketplace builds against OpenSea-compatible approaches, our NFT real estate marketplace development guide covers both architectures and their compliance implications.

For a deeper look at how different smart contract types handle ownership and revenue distribution, see our breakdown of the three main smart contract types and when each makes sense.

Dual-Currency Wallet Architecture

Most tokenization platforms pick a lane: either crypto-native (USDC only) or fiat-first (USD only). This platform had to serve both types of investors — traditional retail who deposits via bank wire, and crypto-native users who deposit USDC directly. That required two independent accounting systems sharing a single UI.

The wallet architecture has three distinct balance types:

USD Balance (fiat). Funded via bank wire transfer or credit card through Stripe. Deposits arrive manually — an admin confirms receipt and credits the user's account. This was a deliberate MVP decision: the client wanted to verify the fiat flow worked correctly before connecting automated card processing at full scale. The USDC deposit button was built but set inactive in production for the same reason — Circle integration was ready, but the client wanted manual confirmation for the first cohort of investors.

USDC Balance (stablecoin). Native crypto deposits and dividend payouts. Users who prefer on-chain transparency receive their monthly rental income in USDC. The conversion module (USDC ↔ USD) routes through KuCoin's API and is visible only to logged-in users.

BrickFi Token Balance (ERC-1155). Separate from both fiat and USDC. Displays token holdings per property, transaction history, and trading status. Tokens carry a timelock: until an admin sets the "token unblock date" for a property, tokens remain locked and the secondary market panel stays inactive. This maps directly to the SEC lock-up requirements for early-stage security offerings.

This is a fundamentally different architecture from standard fiat-to-crypto exchange platforms, where fiat and crypto are interchangeable on the same accounting ledger. Here, USD and USDC must remain logically separate because they have different legal treatment, different withdrawal mechanics, and different compliance implications.

Compliance Layer: 4-Step Accredited Investor Onboarding

For US investors specifically, the platform enforces a 4-step onboarding sequence before any investment action is possible. We built this as a state machine — each step is a distinct verification state in the backend with its own completion condition.

Step 1 — Email registration and confirmation. Standard. Email link valid for 24 hours. Mobile registration had a specific bug here: the calendar for date of birth would crash the app on second tap — we caught and fixed this during the QA cycle before launch.

Step 2 — Accredited investor qualification. US investors see a mandatory questionnaire with three acceptance criteria (any one qualifies): net worth exceeding $1M excluding primary residence; individual annual income above $200k for two consecutive years; joint income with spouse above $300k for two years. Selecting "None of the above" triggers a hard block with a message explaining the SEC restriction and an estimated date for when non-accredited investors would be permitted. This isn't a UX decision — it's a regulatory requirement.

Step 3 — KYC via Ondata. Document upload (driver's license, national ID, passport, or permanent resident card). The integration uses Ondata's webhook-based verification flow. The KYC state in the backend updates asynchronously — the user sees a pending state until Ondata confirms. We also added a Дія-compatible verification path for Ukrainian users, though this wasn't in the original scope.

Step 4 — DocuSign customer agreement. Before the investor reaches the marketplace, they sign an electronic customer agreement through DocuSign. Dynamic fields (name, signature) populate from the user's verified KYC data. The signed document stores in the user's "My Documents" section for their records. This step runs after KYC and before the marketplace — no exceptions.

After all four steps complete, the user lands on the marketplace with "Invest Now" active. Users who haven't completed the sequence see "Submit Interest" instead — which adds them to a waitlist without triggering any financial commitment. The admin sees waitlist submissions per property in a separate panel.

For product teams evaluating how KYC architecture affects both compliance coverage and user conversion, our analysis of blockchain-based KYC use cases covers dual-path verification flows and their tradeoffs in production.

Property Listing and Admin Panel

The admin panel does more than content management — it drives the platform's financial logic. Here's what the property workflow looks like from the admin side:

An admin creates a property card with required fields (address, purchase price, token quantity, expected return, property type, photos) and optional fields (launch date, token unblock date, estimated first dividend date). If launch date is empty, the system sets the listing to "Coming Soon" status automatically and stores "TBA" in the database — the frontend displays this to users. Properties can be saved in draft without publishing, allowing partial completion across sessions.

The dividend distribution works as follows: each month, the admin opens the property card, enters the rental income amount for that period, and triggers distribution. The system calculates each token holder's proportional share and credits their USDC balance. This is an off-chain trigger → on-chain distribution model — not fully automated smart contract logic. The admin acts as the trusted intermediary, which was the client's explicit preference for the MVP phase.

The admin also controls token lock status per property. Until the admin sets a "token unblock date", all tokens for that property remain in locked status and secondary trading stays inactive. The frontend displays a notice: "We will notify you when secondary trading is available (estimated date: [date])". This lets the platform manage its SEC compliance posture without redeploying the smart contract.

Multi-Platform Scope: Web + iOS + Android

The project shipped four surfaces: web platform, web admin panel, iOS native app, and Android native app. This was the full scope from day one — the client's target audience of retail investors requires mobile-first access. The 3-month timeline covered all four.

Mobile introduced specific bugs that didn't appear in web testing. The calendar crash on date-of-birth re-tap (Android) only surfaced during device testing. The "Join Waitlist" modal clipping below the screen fold on smaller iOS devices required a specific scroll-to-bottom fix. The marketplaces's horizontal property scroll had oversized margins on mobile that obscured the scroll affordance — investors couldn't tell the list was scrollable. Each of these required separate test cases and explicit device-level QA before release.

For teams evaluating the architecture of a cross-platform Web3 product with on-chain components, our guide on building a Web3 mobile app covers the state management and wallet connection patterns that work in production.

Userflow and Information Architecture

Before writing a line of code, we mapped the full information architecture as a visual system diagram — every screen, every navigation path, every data dependency. This isn't documentation for its own sake. It's the tool that lets the design, backend, and blockchain teams share a single mental model of what they're building.

The information architecture also forced early decisions on state transitions: what happens when a "Coming Soon" property goes "Live"? When a "Live" property sells out? When an admin unpublishes a live listing? Each transition has different behavior for the investor-facing UI, the waitlist system, and the admin panel. Getting these transitions wrong at the design stage would have caused inconsistent states in production — we caught several of these during the architecture phase before they became code problems.

UI Design Approach

The client's design reference was Airbnb — not because it's a fintech product, but because of what it represents: a complex marketplace that feels simple to first-time users. The client explicitly did not want the platform to look like a crypto exchange. The target investor is a retail user who may never have held cryptocurrency before.

We used a minimalist white background with bright red CTAs. High contrast between action elements and the page background reduces cognitive load and directs attention to the investment action. Every compliance step (accreditation questionnaire, KYC upload, agreement signature) uses the same calm, form-based UI — no alarming language, no intimidating legal headers. "Investment Commitment" became "Order Details." "Deposit" became "Buying Power." These rewrites came from the client's feedback and measurably reduce drop-off in onboarding flows.

Development Process and Methodology

The team ran a hybrid Scrum + Kanban process across 3 months. Scrum sprints governed planned feature work; Kanban handled the continuous stream of client feedback and change requests — which, on this project, was substantial. The client's feature log grew to 57 numbered items by the end of the project, covering everything from token lock logic to ZIP code validation across jurisdictions.

Several scope additions mid-development required architectural changes rather than just UI adjustments. Adding commercial real estate support (in addition to residential) required new property type fields in both the data model and the admin panel. Adding multi-country support (US, Indonesia, Mexico) exposed address formatting assumptions in the backend — the Indonesia and Mexico listings showed malformed location strings until we refactored the address component to handle non-US formats explicitly.

One non-obvious lesson from this project: the accreditation flow for US investors added a country-check branch at registration that affects every other onboarding screen. Non-US users skip steps 2–4 entirely. Building this branch late in development would have required significant rework — we integrated it early after the client clarified the US regulatory requirement, and that saved us from a structural rewrite in the final sprint.

Release and Post-Launch Support

The release phase ran for two weeks of continuous bug-fixing after feature-complete. The issues were concentrated in three areas: mobile-specific rendering bugs (photo gallery, modal sizing, scroll behavior), edge cases in the onboarding state machine (re-entry after failed KYC, re-login after password reset), and admin panel data validation (year-built field rejecting valid input, unpublish function not available for live listings with active waitlist entries).

After launch, we handled a further month of minor support requests — text corrections, bank wire details updates, minor UX adjustments based on the first cohort of real users. This post-launch period is standard on any financial platform: real users find edge cases that internal testing doesn't.

Results

The platform solved its core problem: it made real estate investment accessible at $100 per entry while maintaining full SEC compliance for US investors. The architecture scales — adding a new property means opening a new Series LLC and minting a new ERC-1155 token ID, without touching existing contracts. The compliance layer is modular: the accreditation questionnaire and secondary trading gate are independent from the core investment flow and can be updated as regulations evolve. For context on how this model compares to commercial-grade implementations, our breakdown of how commercial real estate tokenization works covers platform tiers, legal structure variants, and cost ranges.

If you're evaluating a similar build, our service page on real estate tokenization development covers current pricing, typical timelines, and what a production-ready scope looks like across different platform tiers.

Frequently Asked Questions