Module 2 — Real Estate

Section 9: Module 2 — Real Estate

RWA Tokens Platform Whitepaper · Version 10.0 Groovy Company, Inc. · May 2026 Document Reference: RWA-M2-SPEC-001 v1.0

Module 2 is the real-estate tokenization module. It addresses equity tokenization of real-property assets through the Single-Asset Entity (SAE) corporate vehicle. Module 2 introduces the first module-aware Transfer Hook extension — Control CB-21 NAV-deviation variant — which enforces NAV-bound pricing tolerance at the runtime layer.

---

9.1 Scope

Asset Category	Examples
Commercial buildings	Office, retail, industrial, mixed-use
Multi-family residential	Apartment complexes, condo developments
Hospitality	Hotels, resorts, short-term rental portfolios
Mixed-use developments	Multi-tenant developments combining commercial and residential
Land holdings	Developable parcels with entitlements
Specialty	Self-storage, marina, parking-asset-backed equity

Module 2 does not address: real-estate debt instruments (those are securitization products outside Module 2 scope), REIT shares (those are tokenized as Module 1 listed equity), and direct property NFTs (whole-property NFTs are outside Module 2's fractionalized-equity model).

---

9.2 The SAE Structure

The Single-Asset Entity (SAE) is the corporate vehicle that holds the real-property asset. The platform standardizes on a Nevada corporation SAE (typically reached via Nevada LLC formation followed by conversion to Nevada corporation). The conversion is required because Empire Stock Transfer custodies corporate equity (common stock) under §17A, not LLC membership interests.

9.2.1 SAE Lifecycle

Stage 1 — Property Identification
  - Property identified
  - Net equity computed: NAV = property fair-market value − outstanding debt
  - Title reviewed; encumbrances assessed
  - Initial appraisal commissioned from authorized appraiser

Stage 2 — Nevada LLC Formation
  - Nevada LLC organized
  - Property conveyed to LLC via deed
  - LLC operating agreement drafted

Stage 3 — Conversion to Nevada Corporation
  - Articles of Conversion filed with Nevada Secretary of State
  - LLC membership interests converted to common stock 1:1 in agreed share count
  - Corporate bylaws adopted
  - Common Class B authorized in Articles
  - Initial directors elected; officers appointed

Stage 4 — Empire Onboarding
  - Empire performs KYB on SAE
  - Director / officer KYC completed
  - SAE corporate structure documented
  - Empire takes custody of all SAE common stock

Stage 5 — Platform Configuration
  - Property ID assigned (asset identifier)
  - NAV Oracle relay authorized appraiser pubkey configured
  - SecurityConfig PDA initialized:
      module = RealEstate (2)
      nav_deviation_max_bps = 2200 (default 22%)
      reappraisal_cadence_secs = 7_776_000 (default 90 days)
      asset_identifier = property_id
  - NAV Oracle PDA initialized with first NAV attestation

Stage 6 — Token Issuance
  - SPL Token-2022 mint created with Transfer Hook registered
  - ST22 Module 2 tokens minted to SAE treasury
  - Initial pricing published (typically NAV × 1.22 = 22% premium ceiling)

Stage 7 — Investor Onboarding
  - Investors onboard via Empire
  - HoldingPeriodAccount PDAs created per Reg D / Reg S / Reg CF
  - Initial offering round opens

Stage 8 — Secondary Trading
  - CEDEX listing active
  - 24/7/365 secondary trading
  - CB-21 NAV-deviation variant enforces ±22% band around NAV
  - Periodic NAV reappraisal (90-day default cadence)

9.2.2 Why Nevada

Nevada is selected for the SAE jurisdiction because:

• Low-friction conversion path — Nevada LLC-to-corporation conversion via Articles of Conversion is straightforward

• Favorable tax treatment — no state corporate income tax in Nevada

• Established corporate practice — Nevada has well-developed corporation law and predictable courts

• Reasonable franchise tax — annual fees are predictable and modest

• Regulatory recognition — Empire Stock Transfer has established §17A custody operations for Nevada-domiciled corporations

The SAE's underlying property can be located in any US state (and in Phase 2 expansion, any jurisdiction where the platform operates). The SAE's domicile is independent of the property's location for §17A custody purposes.

---

9.3 Backing Instrument — SAE Common Stock

Each Module 2 ST22 token is backed 1:1 by common stock of the SAE. The SAE holds direct title to the real-property asset; ST22 tokens represent fractional equity ownership in the SAE, which in turn owns the property. This pass-through structure satisfies Pillar 4 (True Equity Backing) of Category 1 Model B: the on-chain token represents direct equity in the SAE, which directly owns the property.

Investor Wallet (holds ST22 Module 2 tokens)
    ↓ (represents fractional equity in)
SAE Common Stock (held 1:1 by Empire Stock Transfer §17A custody)
    ↓ (issued by)
Single-Asset Entity (Nevada corporation; holds title)
    ↓ (owns)
Real Property (e.g., Commercial Building at 123 Main St)

9.3.1 1:1 Backing Verification (Module 2)

The Custody Oracle PDA per Module 2 mint stores Empire's Ed25519-signed attestation:

custodied_balance = total SAE common shares held in Empire custody
class_label = AssetClass::SAE

Control CV-04 (Backing Class Match) verifies that custodied_balance.class_label == AssetClass::SAE. Control CV-01 verifies the 1:1 supply equality.

---

9.4 Asset Identifier — Property ID

Module 2 mints carry the property ID as the asset identifier. The property ID is a 32-byte stable identifier derived from:

property_id = keccak256(
    state_code            // ISO 3166-2 state code, e.g., "US-NV"
  | county_code           // FIPS county code
  | parcel_number         // County-assigned parcel/APN
  | sae_corporate_id      // Nevada Secretary of State entity ID
)

This composition ensures: (a) globally unique identification, (b) reproducibility from public records, (c) cryptographic integrity — any modification to underlying inputs produces a completely different property_id. Control CV-05 rejects any transfer where the bound property_id does not match the Custody Oracle's reported asset-identifier hash.

---

9.5 The NAV Oracle (Module 2)

The NAV Oracle is the central architectural innovation of Module 2. It surfaces the underlying property's Net Asset Value on-chain via Ed25519-signed appraiser attestations and provides the data input to Control CB-21 NAV-deviation variant.

9.5.1 NAV Oracle PDA Schema

#[account]
pub struct NavOracle {
    pub version:            u8,         // 10
    pub mint:               Pubkey,
    pub nav_per_token:      u64,        // NAV per token, denominated in 1e6 USDC base units
    pub currency:           [u8; 4],    // "USDC" or "PYUS"
    pub last_update_slot:   u64,        // Slot of last on-chain update
    pub last_appraisal_ts:  i64,        // Unix timestamp of underlying appraisal
    pub appraiser_pubkey:   Pubkey,     // Authorized appraiser Ed25519 public key
    pub signature:          [u8; 64],   // Ed25519 over (mint, nav_per_token, last_appraisal_ts, slot)
    pub bump:               u8,
}

// NAV calculation
nav_per_token = (property_fair_market_value − outstanding_debt − ongoing_obligations) / total_token_supply

// Example: $950,000 net equity, 1,000,000 token supply → nav_per_token = 950 (i.e., $0.95 in 1e6 base units, stored as 950_000)

9.5.2 Authorized Appraiser

The NAV Oracle is fed exclusively by an authorized appraiser — a licensed, registered real-estate appraiser whose Ed25519 public key is bound to the NAV Oracle PDA at initialization. The appraiser cannot be changed without tripartite-concurrence governance (SAE issuer + appraiser + Empire). The appraiser performs:

• Initial property appraisal (full appraisal report) at SAE formation

• Periodic reappraisals at the configured cadence (default 90 days)

• Triggered reappraisals on material property events (major capex, casualty loss, tenant change in a single-tenant commercial property, etc.)

• Ed25519-signs each NAV attestation

Appraiser qualifications include:

• State-licensed real-estate appraiser in the property's jurisdiction

• USPAP (Uniform Standards of Professional Appraisal Practice) compliance

• Errors & Omissions insurance at platform-required levels

• KYC and KYB by Empire Stock Transfer

• Wallet verification (control of authorized Ed25519 key)

9.5.3 NAV Oracle Update Flow

Step 1 — Appraisal Event
  Authorized appraiser performs property valuation
  (initial, periodic, or triggered)

Step 2 — Off-Chain Computation
  appraiser_relay computes:
    nav_per_token = (FMV − debt − obligations) / total_supply

Step 3 — Ed25519 Signing
  appraiser signs:
    msg = (mint || nav_per_token || last_appraisal_ts || target_slot)
    signature = Ed25519_sign(appraiser_priv, msg)

Step 4 — On-Chain Submission
  appraiser_relay submits update_nav instruction:
    target NavOracle PDA
    new nav_per_token, last_appraisal_ts
    signature

Step 5 — On-Chain Verification
  NavOracle program verifies:
    Solana Ed25519 native precompile validates signature against bound appraiser_pubkey
    last_appraisal_ts > previous last_appraisal_ts
    nav_per_token within +/- 50% of previous value (anti-fat-finger guard)

Step 6 — Storage
  NavOracle PDA updated with new fields and current slot

Step 7 — Audit Emission
  GA-42 emits audit record for NAV update event

9.5.4 Reappraisal Cadence

SecurityConfig.reappraisal_cadence_secs defines the maximum elapsed time between appraisals. Default is 7,776,000 seconds (90 days). The cadence may be adjusted per mint via tripartite-concurrence governance (SAE issuer + appraiser + Empire). Common configurations:

Cadence	Use Case
90 days (default)	Standard commercial / multi-family
180 days	Stable single-tenant net-lease (long-lease NN/NNN)
30 days	High-volatility hospitality / development
7 days	Extreme cases (active development, material-event-prone)

If the most recent NAV attestation's last_appraisal_ts exceeds the cadence relative to current time, Control CB-21 NAV-deviation variant rejects all transfers with Error 6021-NAV-STALE (NavReappraisalOverdue). Trading resumes immediately upon fresh appraisal submission.

---

9.6 Control CB-21 NAV-Deviation Variant — Technical Specification

CB-21 NAV-deviation variant is Module 2's runtime-enforced module-aware extension. It rejects any transfer where on-chain price deviates from current NAV by more than the configured tolerance, OR where NAV oracle data is stale beyond the reappraisal cadence.

9.6.1 Mathematical Formulation

Given:

• P_t = on-chain trade price at time t (in NAV-currency base units)

• NAV_t = current NavOracle.nav_per_token at time t

• B = SecurityConfig.nav_deviation_max_bps (default 2,200 bps)

CB-21 NAV-deviation variant enforces:

deviation_bps(P_t, NAV_t) = |P_t − NAV_t| × 10_000 / NAV_t

require: deviation_bps ≤ B

If deviation_bps > B, the transfer reverts with Error 6021-NAV (NavDeviationExceeded).

9.6.2 Implementation (u128 Overflow-Safe Arithmetic)

pub fn ext_cb21_nav_deviation(
    ctx: &Context<TransferHook>,
    transfer_price: u64,
) -> Result<()> {
    let cfg = &ctx.accounts.security_config;
    if cfg.module != Module::RealEstate { return Ok(()); }

    let nav_oracle = ctx.accounts.nav_oracle
        .as_ref()
        .ok_or(TransferHookError::NavOracleMissing)?;

    // Reappraisal staleness
    let now_ts = Clock::get()?.unix_timestamp;
    require!(
        now_ts - nav_oracle.last_appraisal_ts <= cfg.reappraisal_cadence_secs,
        TransferHookError::NavReappraisalOverdue  // 6021-NAV-STALE
    );

    // Per-slot freshness
    let now_slot = Clock::get()?.slot;
    require!(
        now_slot - nav_oracle.last_update_slot <= 1,
        TransferHookError::NavOracleStale
    );

    // Ed25519 signature verification via Solana native precompile
    verify_nav_attestation(
        nav_oracle.appraiser_pubkey,
        &nav_oracle.signature,
        &(cfg.mint, nav_oracle.nav_per_token, nav_oracle.last_appraisal_ts, nav_oracle.last_update_slot),
    )?;

    // Deviation math (u128 overflow-safe)
    let nav = nav_oracle.nav_per_token as u128;
    let price = transfer_price as u128;
    require!(nav > 0, TransferHookError::InvalidNAV);

    let deviation_num = if price > nav { price - nav } else { nav - price };
    let deviation_bps_u128 = deviation_num
        .checked_mul(10_000)
        .ok_or(TransferHookError::ArithmeticOverflow)?
        .checked_div(nav)
        .ok_or(TransferHookError::ArithmeticOverflow)?;

    require!(deviation_bps_u128 <= u128::from(u16::MAX), TransferHookError::ArithmeticOverflow);
    let deviation_bps = deviation_bps_u128 as u16;

    require!(
        deviation_bps <= cfg.nav_deviation_max_bps,
        TransferHookError::NavDeviationExceeded  // 6021-NAV
    );
    Ok(())
}

9.6.3 Why 22% Default Tolerance

The 22% (2,200 bps) default nav_deviation_max_bps reflects a deliberate fractionalization-premium pricing model:

Premium Component	Approximate Contribution
Liquidity premium (24/7/365 secondary trading vs traditional private real estate dispositions on multi-month timelines)	~10%
Fractionalization convenience (no whole-property purchase capital requirement)	~5%
Ongoing platform compliance and §17A custody costs	~3%
Protocol fee structure (5% per trade, distributed across trades)	~4%
Approximate ceiling	~22%

The tolerance band is symmetric: a 22%-below-NAV trade is rejected just as a 22%-above-NAV trade is rejected. This protects investors from both undervaluation (potential market manipulation suppressing price below NAV) and overvaluation (price spike without underlying property revaluation). The band can be tightened (to e.g. 10% or 15%) per mint via tripartite-concurrence governance, but not loosened beyond statutory ceilings imposed by Reg D / Reg S / Reg CF anti-manipulation provisions.

9.6.4 Tolerance Adjustment Workflow (Tripartite Concurrence)

Step 1 — Proposal
  Any of {SAE issuer, authorized appraiser, Empire Stock Transfer}
  proposes a change to nav_deviation_max_bps via governance proposal.

Step 2 — Concurrence Required
  All three parties must sign the proposal:
    - SAE issuer: 3-of-5 multi-sig
    - Authorized appraiser: Ed25519 signature
    - Empire Stock Transfer: Ed25519 signature

Step 3 — Timelock
  48-hour timelock per Layer 7 governance.

Step 4 — Execution
  Governance program executes update to SecurityConfig.nav_deviation_max_bps.

Step 5 — Audit
  GA-42 emits audit record of the change.

If any single party refuses to concur, the change does not execute. The platform itself cannot unilaterally modify the parameter — this is the protection against platform-driven NAV-band manipulation.

---

9.7 Reference Use Case — Commercial Building Tokenization

A commercial building located in Reno, Nevada, with $950K net equity (after debt service).

9.7.1 Structuring

Parameter	Value
Property	123 Main St, Reno, NV
Property fair-market value	$1,200,000
Outstanding debt	$250,000
Net equity	$950,000
SAE	Reno SAE Holdings, Inc. (Nevada corporation)
Authorized common stock	1,000,000 shares
Tokenized share count	1,000,000 ST22 Module 2 tokens
nav_per_token (initial)	$0.95 (950,000 in 1e6 base units)
nav_deviation_max_bps	2,200 (22%)
reappraisal_cadence_secs	7,776,000 (90 days)
Initial offering price ceiling	$0.95 × 1.22 = $1.159
max_wallet_percent	999 bps (9.99%)

9.7.2 Onboarding Sequence (Concrete)

1. Property identified at $1.2M fair-market value; $250K debt outstanding; net equity = $950K.

2. Nevada LLC formed; property conveyed to LLC via deed.

3. Articles of Conversion filed with Nevada Secretary of State; LLC converted to Nevada corporation.

4. Articles of Incorporation specify 1,000,000 authorized common shares.

5. Empire Stock Transfer onboards SAE.

6. Empire takes custody of 1,000,000 SAE common shares.

7. Property ID assigned: property_id = keccak256("US-NV" | "FIPS-031" | parcel | sae_id).

8. Authorized appraiser engaged; initial appraisal report produced; appraiser Ed25519 pubkey configured.

9. NAV Oracle PDA initialized with first attestation: nav_per_token = 950_000.

10. SecurityConfig PDA: module = 2, nav_deviation_max_bps = 2200, reappraisal_cadence_secs = 7_776_000, asset_identifier = property_id.

11. SPL Token-2022 mint created with Transfer Hook registered.

12. 1,000,000 ST22 Module 2 tokens minted to SAE treasury.

13. Investors onboard through Empire (Reg D, Reg S, or Reg CF).

14. Initial offering round: tokens issued at $1.159 (22% premium to $0.95 NAV).

15. CEDEX listing active; 24/7/365 secondary trading.

16. After 90 days, appraiser performs first reappraisal; updated NAV submitted to oracle.

9.7.3 Operational Trade Cycle

Day 0  — Initial appraisal: NAV = $0.95
        Initial offering: tokens issued at $1.159
        Trade band: $0.741 to $1.159 (±22%)

Day 30 — Trading at $1.10 (deviation = 15.8%) — within band, no enforcement action
Day 60 — Trade attempt at $1.20 — deviation = 26.3% — REJECTED (6021-NAV)

Day 90 — Reappraisal triggered: new NAV = $1.00 (property appreciated)
        New trade band: $0.78 to $1.22 (±22% of $1.00)
        Same $1.20 trade now within band → would succeed

Day 180 — Reappraisal cadence (next scheduled) due
         If appraiser fails to submit by Day 180:
           CB-21 NAV variant rejects all transfers (6021-NAV-STALE)
           Trading auto-resumes when fresh attestation arrives

---

9.8 Reappraisal Mechanics (Detailed)

9.8.1 Triggered Reappraisals

In addition to the periodic cadence, reappraisals MUST be triggered on:

Event	Notification Path
Major capital expenditure (>5% of FMV)	SAE issuer reports to appraiser within 5 business days
Casualty loss (fire, flood, etc.)	SAE issuer reports immediately; emergency reappraisal within 14 days
Tenant change in single-tenant property	SAE issuer reports within 30 days
Property tax reassessment	SAE issuer reports within 30 days
Refinancing of underlying debt	SAE issuer reports concurrent with closing
Comparable-sales material divergence	Appraiser self-trigger

9.8.2 Anti-Fat-Finger Guard

NAV updates are limited to ±50% of the prior NAV in a single update. Larger NAV revisions require two-step submission with platform compliance review. This protects against:

• Off-by-one decimal errors

• Currency unit confusion (USDC vs PYUSD vs whole-dollar)

• Compromised appraiser key submitting fraudulent valuation

// In NavOracle::update_nav instruction
let prior_nav = nav_oracle.nav_per_token;
let new_nav   = ix_data.nav_per_token;
let max_delta = prior_nav.checked_mul(50).unwrap() / 100; // 50%
require!(
    new_nav >= prior_nav.saturating_sub(max_delta),
    NavOracleError::NAVDecreaseTooLarge
);
require!(
    new_nav <= prior_nav.checked_add(max_delta).ok_or(NavOracleError::ArithmeticOverflow)?,
    NavOracleError::NAVIncreaseTooLarge
);

---

9.9 Module 2 Investor Lifecycle

Identical to Module 1 with three differences:

1. CB-21 NAV-deviation enforcement — every secondary trade must pass NAV-band check.

2. NAV-bound secondary pricing — investors observe both market price and current NAV; pricing has a hard runtime ceiling at NAV × (1 + B/10000) and floor at NAV × (1 − B/10000).

3. Reappraisal awareness — investors observe reappraisal cadence and may anticipate NAV resets.

---

9.10 Cross-Module Coordination

Module 2 shares with Modules 1 and 3:

• Empire Stock Transfer §17A custody (with class_label = SAE)

• Global Unified Liquidity Pool

• CEDEX trading venue

• Custody / OFAC / AML / TWAP oracles

• Reg D / Reg S / Reg CF framework

• USDC / PYUSD GENIUS Act stablecoin settlement

• Layer 9 IDOS compliance intelligence (with Module 2-specific NAV deviation history pipeline)

Module 2 differs from Modules 1 and 3 by adding:

• NAV Oracle (Layer 6 oracle category 6)

• CB-21 NAV-deviation variant (Transfer Hook module-aware extension)

• Tripartite concurrence governance for NAV-band parameter changes

• SAE corporate vehicle (vs operating-company Common Class B for M1; BAE for M3)

• Property ID as asset identifier (vs CUSIP for M1; basin ID for M3)

• Reappraisal cadence as a per-mint configurable parameter

---

RWA Tokens Whitepaper V10 — Section 9 — Confidential — Groovy Company, Inc.