10. SYSTEM ARCHITECTURE: EIGHT LAYERS EXPLAINED

Why Eight Layers?

The Homeunity ecosystem is complex by design. Each layer serves a specific purpose:

• Asset Layer (Physical hotels)
• Legal Layer (SPV structure, Swiss registry)
• Participation Layer (HPOT series)
• Usage Layer (HRPT, Travel Club)
• Data Layer (Monitoring, oracles, reporting)
• Blockchain Layer (On-chain representation, transfers)
• Access Layer (HAFS, onboarding, compliance)
• Application Layer (User interface, dashboards, booking)

Each layer is isolated (failure in one doesn't cascade to others).

This is enterprise-grade architecture, not a "move fast and break things" startup structure.

Layer 1: Asset Layer (Physical Real Estate)

What Lives Here

Actual hotel buildings:

• Land, structure, fixtures
• Furniture, equipment (FF&E)
• Physical inventory (linens, supplies)

Ownership:

• SPV owns the hotel (legal title recorded in local jurisdiction)
• One SPV per hotel (bankruptcy remoteness)

Operations:

• Hotel operator manages day-to-day (management agreement)
• Staff, guests, revenue, expenses (the actual business)

Why This Layer Is Separate

Physical assets are illiquid and jurisdiction-specific.

Challenges:

• Each country has different property laws
• Real estate title registration varies
• Tax treatment differs by location
• Zoning, permits, compliance (local regulations)

Solution:

• Local subsidiary holds title (e.g., Portuguese entity for Portugal hotel)
• Swiss SPV owns the local subsidiary (clean structure)
• HPOT participation tied to Swiss SPV (governed by Swiss law)

Separation allows:

• International diversification (hotels in multiple countries)
• Legal clarity (participation governed by Swiss law, property by local law)
• Bankruptcy isolation (one hotel's issues don't affect others)

Layer 2: Legal Layer (Contracts & Registry)

What Lives Here

Legal structure:

• SPV formation documents (articles of association, bylaws)
• Participation agreements (HPOT holder contracts)
• Management agreements (operator contracts)
• Fiduciary agreements (administrator contracts)
• Swiss registry (official record of HPOT issuance and holdings)

Key legal concepts:

• Registerwertrechte (contractual rights under Swiss law, Art. 973d CO)
• Bankruptcy remoteness (SPV isolation from other entities)
• Distribution waterfall (contractual priority of payments)

Swiss Registry: The Source of Truth

What it is:

• Official Swiss registry for uncertificated securities
• Maintained by Fuchs Treuhand AG (fiduciary administrator)
• Legal record of who holds what

What it contains:

• Series information: Hotel identifier, total HPOT issued, issuance date
• Holder records: Wallet addresses (or account IDs), HPOT balances
• Transaction history: Issuances, transfers, redemptions
• Snapshots: Record dates for distributions (who held HPOT on specific dates)

Why Swiss registry matters:

• Legal enforceability: Swiss courts recognize Registerwertrechte
• Regulatory compliance: Meets Swiss DLT/securities framework
• Creditor protection: Bankruptcy remoteness doctrine applies
• International recognition: Swiss legal opinions carry weight globally

Registry is the ultimate source of truth. Blockchain is a mirror (convenient for transfers, queries), but registry is authoritative in disputes.

Layer 3: Participation Layer (HPOT Economics)

What Lives Here

Economic participation:

• HPOT series (one per hotel)
• Distribution calculations (pro-rata NOI shares)
• Reserve fund accounting (20% allocations, CapEx spending)
• Waterfall logic (Tiers 1-5, priority payments)

Key mechanisms:

• Quarterly distribution cycle (record dates, payment dates)
• NAV calculations (net asset value per HPOT, updated annually or upon major events)
• Governance triggers (supermajority votes for major decisions)

How This Layer Interacts with Others

Inputs from Asset Layer:

• Hotel NOI (revenue - operating expenses)
• CapEx needs (renovation requirements)
• Performance data (occupancy, ADR)

Inputs from Legal Layer:

• Participation agreement terms (distribution waterfall rules)
• Registry snapshots (who gets paid)

Outputs to Blockchain Layer:

• Distribution events (recorded on-chain for transparency)
• Governance votes (on-chain or off-chain, depending on implementation)

Outputs to Application Layer:

• Dashboard updates (your distribution amounts, yield calculations)
• Tax statements (annual 1099/1042-S equivalents)

Layer 4: Usage Layer (HRPT & Travel Club)

What Lives Here

Travel Club operations:

• Membership tiers (Starter, Explorer, Navigator, Pioneer)
• Internal pricing engine (cost-plus model, tier discounts)
• Booking system (availability, reservations, confirmations)
• AI concierge (recommendations, price monitoring, itinerary planning)

HRPT token:

• Issued as DLT-registered right (Swiss law, utility token classification)
• Membership credential (holding HRPT = Travel Club access)
• Tier determination (real-time balance checks)

Separation from Participation Layer

HRPT ≠ HPOT

Why separate:

• Regulatory: HRPT is utility token (consumptive use), HPOT is asset token (financial participation)
• Access: HRPT potentially available to U.S. retail (where Terms allow), HPOT restricted
• Function: You can travel without participating economically, or vice versa

Interaction:

• Optional bundling: "Buy $10K HPOT, get 1,000 HRPT bonus" (promotional)
• Alignment: More Travel Club usage → higher hotel occupancy → higher NOI → higher HPOT distributions
• But fundamentally independent: Travel Club can operate even if HPOT market crashes (and vice versa)

Layer 5: Data Layer (Monitoring & Oracles)

What Lives Here

Real-time data collection:

• Hotel PMS integration (Property Management System — reservations, check-ins, billing)
• Accounting system integration (expenses, payroll, invoices)
• Market data feeds (comp set pricing, occupancy benchmarks, tourism trends)
• Review aggregation (TripAdvisor, Google, Booking.com scores)

Data transformation:

• Normalization: Different hotels use different PMS systems → standardized data format
• Validation: Detect anomalies (e.g., occupancy >100%, negative expenses)
• Aggregation: Roll up daily data into weekly/monthly summaries

Oracle services:

• Push data to blockchain (on-chain record of key metrics)
• Trigger smart contract events (distribution authorization, governance votes)

Digital Twin Concept

What it is:

• Virtual replica of hotel operations
• Updates in near-real-time (typically every 15 minutes for key metrics)
• Accessible to HPOT holders via dashboard

What you see:

• Today's occupancy: 78% (85 of 100 rooms occupied)
• This week's ADR: $162 (trending up from $155 last week)
• Month-to-date revenue: $487K (on track for $620K monthly target)
• Expense alerts: Utilities +12% vs. last month (investigate)
• Review score: 4.6/5 (dropped from 4.8 — recent negative reviews flagged)

Why it matters:

• Transparency: You see what's happening in real-time (not waiting for quarterly reports)
• Accountability: Operator knows participants are watching
• Early warning: Performance issues detected before they become crises

See §15 for full Digital Twin details.

Oracle Architecture

Data flow:

Key oracles:

1. Occupancy Oracle

• Updates: Daily (midnight UTC)
• Data: Occupancy % by hotel, by series
• On-chain use: Distribution calculations, performance monitoring

2. Revenue Oracle

• Updates: Weekly
• Data: Total revenue (gross), revenue by source (OTA, direct, Travel Club)
• On-chain use: NOI calculations, waterfall inputs

3. NAV Oracle

• Updates: Quarterly (or upon major events like CapEx, disposition)
• Data: Net asset value per HPOT (estimated property value - liabilities / total HPOT)
• On-chain use: Secondary market reference pricing, governance votes (weighted by NAV)

4. Governance Oracle

• Updates: On-demand (when votes called)
• Data: Vote proposals, results, execution status
• On-chain use: Transparency, audit trail

Oracle security:

• Multi-signature: Data must be confirmed by 3+ independent nodes (prevents single point of manipulation)
• Validator network: Decentralized nodes (Homeunity + third-party validators)
• Slashing: Validators who submit false data lose stake (economic incentive for honesty)

Layer 6: Blockchain Layer (On-Chain Representation)

Why Blockchain?

Benefits:

• Transparency: All transactions publicly visible (pseudonymous)
• Immutability: Historical data can't be altered (audit trail)
• Programmability: Smart contracts automate logic (distribution calculations, transfers)
• Composability: Other protocols can integrate (future DeFi use cases)
• Global access: Anyone with internet can view data (no gatekeepers)

Not benefits:

• NOT decentralization of control (governance still requires SPV, fiduciary, legal layer)
• NOT "trustless" (you still trust operator, fiduciary, legal agreements)
• NOT immutable in absolute sense (Swiss registry can override blockchain in disputes)

Blockchain is a tool, not a religion.

Network: Binance Smart Chain (BSC)

Why BSC:

• Low fees: Gas costs ~$0.10-0.50 per transaction (vs. $5-50 on Ethereum)
• Fast: ~3 second block time (vs. 12-15 seconds on Ethereum)
• EVM-compatible: Supports Solidity smart contracts (developer familiarity)
• Liquidity: Large DEX ecosystem (PancakeSwap, etc.) for secondary trading
• Proven: Billions in TVL, established network (since 2020)

Why not Ethereum:

• Too expensive: $20-100 gas fees make small distributions impractical
• L2 fragmentation: Too many Layer 2 options, unclear which will win

Why not Solana/Avalanche/other:

• Lower liquidity: Smaller DEX ecosystems
• Less mature: Newer chains, higher technical risk

BSC is a pragmatic choice (not ideologically pure, but functional).

Smart Contracts

Key contracts:

1. HRPT Token Contract

• Standard: BEP-20 (BSC token standard, equivalent to ERC-20)
• Supply: Fixed total supply
• Functions: Transfer, balance checks, tier determination (reads HRPT balance for Travel Club access)
• Contract address: 0x41bE4f626808C3a56d7C2E66b3e8f106b4a2D832 (example — verify on platform)

2. HPOT Series Contracts

• One contract per series (HPOT-A, HPOT-B, etc.)
• Standard: BEP-20 with extensions (registry sync, distribution tracking)
• Supply: Fixed per series (matches series issuance, e.g., 10M HPOT-A)
• Functions:
• Transfer (with registry notification)
• Distribution claim (when authorized by fiduciary)
• Governance vote (for major decisions)

3. Distribution Manager Contract

• Function: Calculates and processes distributions
• Inputs: NOI (from oracle), reserve allocation, priority fees
• Logic: Implements waterfall (Tiers 1-5)
• Outputs: Distribution amounts per HPOT holder (claimable via HPOT contract)

4. Governance Contract

• Function: Manages votes (operator replacement, disposition, major CapEx)
• Inputs: Proposals (submitted by SPV board or HPOT holders)
• Logic: Voting period (e.g., 7 days), quorum check, supermajority thresholds
• Outputs: Vote results (binding if quorum + threshold met)

5. Registry Sync Contract

• Function: Mirrors Swiss registry on-chain
• Inputs: Registry snapshots (from fiduciary administrator)
• Logic: Validates transfers against registry (ensures blockchain matches official record)
• Outputs: Reconciliation reports (flags discrepancies)

On-Chain Data Availability

What's on-chain:

• HRPT transfers (all transfers publicly visible)
• HPOT transfers (all transfers publicly visible)
• Distribution events (amounts, dates, recipients)
• Governance votes (proposals, votes, results)
• Oracle data (occupancy, revenue, NAV snapshots)

What's NOT on-chain:

• KYC data (privacy, regulatory compliance — stored off-chain by licensed provider)
• Detailed financials (full income statements, expense breakdowns — too much data for blockchain)
• Personal info (names, addresses, passport numbers — GDPR compliance)

Blockchain is for transparency and automation, not data warehouse.

Layer 7: Access Layer (HAFS & Compliance)

What Is HAFS?

HAFS = Homeunity Asset Facilitation System

What it does:

• Onboards new HPOT participants (KYC, suitability, payment processing)
• Issues HPOT (allocates to participants, updates registry)
• Monitors issuance health (ACR — Asset Coverage Ratio)
• Enforces compliance (jurisdiction restrictions, accredited investor verification for U.S.)

HAFS is NOT:

• A retail "buy button" (like Coinbase or Binance)
• An exchange (no secondary market trading in HAFS)
• A wallet (you receive HPOT in your own wallet after onboarding)

HAFS is a gated onboarding portal.

Why HAFS Exists

Regulatory requirements:

• KYC/AML: Must verify identity, check sanctions lists (OFAC, EU, etc.)
• Suitability: Must ensure participant understands risks, can afford loss
• Jurisdiction: Must block restricted regions (U.S. retail, China, sanctioned countries)
• Accredited investor verification: For U.S. participants (if institutional gateway used)

Anti-speculation guardrails:

• No immediate flipping: HAFS allocations may have lock-up (e.g., 90-day minimum hold before transferable)
• Purchase limits: Maximum per participant (prevents whale concentration)
• Gradual issuance: Series doesn't all issue at once (staggered over weeks/months)

Operational efficiency:

• Payment processing: Fiat wires, crypto conversions (USDC/USDT → USD → SPV bank account)
• Series coordination: Matches demand with available supply (waitlist if oversubscribed)

See §12 for full HAFS deep dive.

Layer 8: Application Layer (User Interface)

What Lives Here

Frontend applications:

1. Participant Dashboard (HPOT Holders)

• Portfolio view: All your HPOT holdings across series
• Performance tracking: Distributions received, cumulative yield, NAV updates
• Digital twin access: Real-time hotel monitoring
• Governance: View proposals, cast votes
• Tax documents: Download annual statements

2. Travel Club Portal (HRPT Holders)

• Hotel search: Destinations, dates, filters
• Booking engine: Reservations, payments, confirmations
• AI concierge: Chat interface, recommendations, price alerts
• Tier status: Current tier, benefits, upgrade thresholds
• Trip history: Past stays, receipts, reviews

3. Admin Console (Operators, SPV Board, Fiduciary)

• Hotel management: Update availability, pricing, inventory
• Financial reporting: Upload statements, trigger distributions
• Governance tools: Create proposals, monitor votes
• Compliance dashboards: KYC status, jurisdiction reports, alert management

4. Public Website (Marketing, Education)

• Whitepaper, FAQs, asset factsheets
• Blog, news updates
• Contact, support

Tech Stack (High-Level)

Frontend:

• React (web app framework)
• TypeScript (type safety)
• Tailwind CSS (styling)
• Web3.js / Ethers.js (blockchain interactions)

Backend:

• Node.js (API server)
• PostgreSQL (relational database for off-chain data)
• Redis (caching for performance)
• GraphQL (API query layer)

Blockchain:

• Hardhat (smart contract development, testing)
• OpenZeppelin (security-audited contract libraries)
• Chainlink (oracle infrastructure — if used in addition to custom oracles)

Infrastructure:

• AWS / GCP (cloud hosting)
• CloudFlare (CDN, DDoS protection)
• Docker / Kubernetes (containerization, orchestration)

Security:

• SSL/TLS (encrypted connections)
• 2FA (two-factor authentication for accounts)
• HSM (hardware security modules for key storage)
• Bug bounty program (incentivize white-hat hackers to find vulnerabilities)

How the Layers Work Together: Example Flow

Scenario: You Receive a Quarterly Distribution

Step-by-step through all 8 layers:

Layer 1 (Asset): Hotel Operates

• Hotel generates $1.25M revenue in Q1
• Operating expenses: $700K
• NOI: $550K

Layer 2 (Legal): Participation Agreement Activates

• Participation agreement specifies: 20% reserves, priority fees, then HPOT distribution
• Distributable amount calculated: $550K - $110K (reserves) - $27.5K (fees) = $412.5K

Layer 5 (Data): Oracle Captures Results

• Operator uploads Q1 financials to system
• Data pipeline validates (checks against PMS data, accounting records)
• Oracle pushes NOI data on-chain: $550K confirmed

Layer 6 (Blockchain): Distribution Triggered

• Distribution Manager smart contract reads oracle data
• Calculates: $412.5K distributable / 10M HPOT = $0.04125 per HPOT
• Distribution event emitted (on-chain record)

Layer 2 (Legal): Fiduciary Authorizes

• Fuchs Treuhand AG reviews financials
• Confirms reserves are at target (no need to withhold extra)
• Authorizes distribution: $412.5K approved for payment

Layer 6 (Blockchain): Registry Snapshot

• Smart contract queries Swiss registry (via Registry Sync Contract)
• Record date: March 31, 2027
• Snapshot shows: You held 50,000 HPOT on that date

Layer 3 (Participation): Your Share Calculated

50,000 HPOT × $0.04125 = $2,062.50

Layer 8 (Application): You Claim Distribution

• Dashboard shows: "Q1 Distribution: $2,062.50 available"
• You click "Claim" (or set to auto-claim)
• Choose payment method: USDC to wallet

Layer 6 (Blockchain): Payment Executed

• Distribution Manager contract sends 2,062.50 USDC to your wallet
• Transaction hash: Publicly verifiable on BSC block explorer

Layer 8 (Application): Confirmation

• Dashboard updates: "Payment sent. TX: 0xabc123..."
• Email notification: "You received $2,062.50 for Q1 2027"

All 8 layers worked together to get money from hotel operations into your wallet.

Why Complexity?

Couldn't this be simpler?

Yes — but it would sacrifice:

• Legal clarity: Swiss Registerwertrechte provide regulatory certainty
• Bankruptcy protection: SPV isolation requires separate legal entities
• Transparency: Blockchain + oracles make data publicly verifiable
• Compliance: HAFS enforces KYC/AML, jurisdiction restrictions
• Scalability: Modular layers allow independent upgrades (change PMS without touching blockchain)

Each layer serves a purpose. Remove one, and the system becomes fragile or non-compliant.

This is production-grade infrastructure, not a prototype.

System Resilience: What If a Layer Fails?

Layer 1 (Asset) Failure

Scenario: Hotel destroyed by fire.

Impact:

• NOI goes to zero (until rebuilt or sold)
• Distributions suspended
• Insurance claim filed (covers rebuilding or compensates for loss)

Other layers:

• Unaffected: Other hotels in other SPVs continue operating
• Blockchain, legal, data layers still function (just no NOI to distribute for this series)

Layer 2 (Legal) Failure

Scenario: Fiduciary administrator loses license.

Impact:

• Registry administration pauses (new transactions can't be officially recorded)
• Distributions delayed (until new fiduciary appointed)

Mitigation:

• Succession plan: Participation agreements allow HPOT holders to vote for replacement
• Registry transfer: New fiduciary takes over (continuity maintained)
• Timeline: 30-90 days to transition (distributions backfilled once resolved)

Layer 5 (Data) Failure

Scenario: Oracle malfunction (wrong data pushed on-chain).

Impact:

• Distribution calculation incorrect (e.g., shows $1M NOI when actual was $550K)
• Potential overpayment to HPOT holders (or underpayment)

Mitigation:

• Multi-signature validation: Oracle data must be confirmed by 3+ validators
• Fiduciary review: Fiduciary checks data before authorizing distribution (catches errors)
• Reconciliation: Monthly audits compare on-chain data with SPV financials

If error detected:

• Before distribution: Corrected on-chain, re-calculated
• After distribution: Clawback (future distributions adjusted) or insurance claim

Layer 6 (Blockchain) Failure

Scenario: BSC network down (temporary outage).

Impact:

• On-chain transactions paused (can't transfer HPOT, claim distributions)
• Dashboard may not update (if relies on on-chain queries)

Mitigation:

• Off-chain fallback: Distributions can be processed via manual wire transfer (using registry as source of truth)
• Network redundancy: BSC has validator redundancy (unlikely to have prolonged outage)
• Timeline: Typical outage <1 hour (if longer, fallback procedures activate)

Swiss registry is source of truth, so blockchain downtime doesn't erase your holdings.

Layer 8 (Application) Failure

Scenario: Website/dashboard hacked or down.

Impact:

• Can't access dashboard (can't view data, claim distributions)
• Can't book Travel Club hotels

Mitigation:

• Data still on-chain: You can query blockchain directly (via BSC block explorer or tools like Etherscan)
• Alternative access: Mobile app, API endpoints (if you're technical)
• Manual support: Contact support for manual distribution claims, bookings

Downtime doesn't affect underlying assets (hotels still operate, distributions still calculated).

Summary: Eight Layers, One Ecosystem

Layer 1 (Asset): Physical hotels generate cash flows

Layer 2 (Legal): Swiss law provides structure and enforceability

Layer 3 (Participation): HPOT gives you economic rights

Layer 4 (Usage): HRPT gives you Travel Club access

Layer 5 (Data): Oracles capture and validate performance

Layer 6 (Blockchain): On-chain transparency and automation

Layer 7 (Access): HAFS ensures compliant onboarding

Layer 8 (Application): Dashboards make it usable

Each layer is independent (failure isolated).

Each layer is necessary (removing one breaks functionality or compliance).

This is how you build infrastructure that scales to billions in assets.

Next: Blockchain and data details — BSC, oracles, and system reality.