case study: real estate tokenization
Case Study: How We Tokenized Real Estate Through NFTs
A practical example of developing an NFT marketplace with real estate tokenization by Merehead
Built over 30 crypto platforms across 12 countries 
The platform we describe in this case took 3 months to build across 4 surfaces (web platform, web admin, iOS app, Android app) by a team of 8. Tech stack: Solidity + Binance Smart Chain for the token contract, PHP + PostgreSQL for backend logic, React for frontend, Stripe for fiat deposits, Circle for USDC processing, Ondata for KYC, DocuSign for e-signatures. Secondary trading was intentionally disabled pending SEC committee approval — a design decision, not an oversight.
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.
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.
Problem 2 — Token standard selection. Different token standards carry different compliance burdens and secondary market implications. The choice affects every downstream architectural decision.
Problem 3 — Dual currency accounting. The platform must handle both USD (fiat, from bank wires and card payments) and USDC (stablecoin), maintain separate balances, and allow conversion between them — without conflating the two in the accounting layer.
Problem 4 — US securities law compliance. For US investors, property-backed tokens are investment securities. The platform must verify accredited investor status before any transaction — not just at registration, but as a gating condition for every investment action.
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.
We evaluated three implementation options for the token contract:
| Option | Standard | Gas efficiency | Secondary market | Fractional by default |
| Single NFT per property | ERC-721 | Low (1 transfer = 1 tx) | OpenSea-compatible | No — requires wrapper contract |
| Fractional NFTs (1 token = 1 sq.m.) | ERC-721 fractional | Medium | Complex routing | Partial — needs additional logic |
| Multi-token contract per property | ERC-1155 | High (batch transfers) | Natively fungible within property | Yes — natively |
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.
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.
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.
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.
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.
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.
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.
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.
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.
| Parameter | Value |
| Development timeline | 3 months |
| Platforms delivered | 4 (web, web admin, iOS, Android) |
| Team size | 8 (2 BE, 2 FE, 1 QA, 1 Designer, 1 DevOps, 1 PM) |
| Token standard | ERC-1155 on Binance Smart Chain |
| Legal entity per property | Delaware Series LLC (isolated, non-cross-collateralized) |
| Minimum investment | $100 |
| Target annual yield | 6–12% on fully rented properties |
| Dividend frequency | Monthly (USDC or USD) |
| Onboarding steps (US investors) | 4 (registration → accreditation → KYC → DocuSign) |
| Jurisdictions supported | US, Indonesia, Mexico |
| Secondary trading | Built, disabled pending SEC approval |
| Project complexity | 3/5 |
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.
It depends on your fee tolerance and transaction volume. For this platform, we used Binance Smart Chain — lower per-transaction fees than Ethereum mainnet, sub-5 second finality, and sufficient tooling for ERC-1155 contracts. Polygon is a common alternative for teams that need Ethereum-compatible tooling with cheaper gas. Ethereum mainnet makes sense when institutional credibility and DeFi composability outweigh gas costs.
In most real estate tokenization structures — including this one — yes. Tokens that represent fractional ownership in a property-holding LLC, where investors expect profit from the management efforts of others, meet the Howey Test criteria for securities. This means the platform must either register the offering with the SEC or qualify for an exemption (Reg D 506(b) or 506(c) are the most common for accredited investor offerings). We're not lawyers and this isn't legal advice — but the compliance architecture of any serious US-market platform needs to account for this from day one.
Secondary trading of security tokens in the US requires a separate regulatory approval process — you're operating a securities marketplace, not just an investment platform. The client built the secondary market module (order book, buy/sell flow, token matching logic) but kept it disabled pending clearance from the Securities Committee. This is the correct sequencing: build the infrastructure, get regulatory approval, then activate. Launching secondary trading without approval would expose the platform to significant regulatory risk.
In this implementation, dividend distribution is a hybrid model: off-chain trigger, on-chain accounting. The admin enters the rental income amount for a property in the admin panel and initiates distribution. The backend calculates each token holder's proportional share based on their ERC-1155 balance, then credits USDC to their platform wallet. This is not a fully automated smart contract — it requires an admin action each distribution cycle. A fully on-chain model (automated via smart contract) is possible but adds oracle complexity and is harder to audit for compliance purposes.
At minimum: a smart contract for token minting and transfers, a property listing system (admin panel), an investor wallet with deposit/withdrawal flows, a compliance layer (KYC + accreditation for US), and a dividend distribution mechanism. Mobile apps are not MVP — but they significantly affect retail investor acquisition. Our recommendation: launch web first, ship mobile in the second iteration once the core investment flows are validated with real users.
This build took 3 months for web platform + web admin + iOS + Android with a team of 8. Web-only (platform + admin) typically runs 6–8 weeks at similar team size. The main timeline variable is compliance complexity: adding US accredited investor onboarding, DocuSign integration, and multi-jurisdiction KYC adds 2–4 weeks over a non-US-market build. Secondary trading adds another 3–6 weeks on top of that.
