> For the complete documentation index, see [llms.txt](https://bitbook.rwatokens.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bitbook.rwatokens.net/reference/reference/whitepaper-v10.md). # Whitepaper V10 ## Section 1: Executive Summary **RWA Tokens Platform Whitepaper · Version 10.0** **Groovy Company, Inc. · May 2026** **Document Reference:** RWA-WP-001 v10.0 *** ### 1.1 The Platform The RWA Tokens platform is operated by **Groovy Company, Inc.** (Wyoming corporation; OTC: GROO; SEC EDGAR CIK 1499275; principal office 600 W Peachtree St NW, Suite 1700, Atlanta, GA 30308). It provides on-chain infrastructure for tokenizing equity in three asset classes — public and private equity securities, real-property assets, and US strategic-minerals supply-chain assets — under a single SEC Category 1 Model B compliance framework with runtime-enforced controls at the Solana SPL Token-2022 layer. | Identifier | Value | | -------------------- | ------------------------------------------------------------------------------------------------- | | Issuer | Groovy Company, Inc. (Wyoming) | | OTC ticker | GROO | | SEC EDGAR CIK | 1499275 | | Commission File No. | 000-54938 | | Domicile | Wyoming (W\.S. 34-29-101 *et seq.*) | | Principal office | 600 W Peachtree St NW, Suite 1700, Atlanta, GA 30308 | | Platform website | | | Trading venue | | | Custodian | Empire Stock Transfer (SEC §17A-registered) | | Regulatory framework | SEC–CFTC Release No. 33-11412 (March 17, 2026), Category 5 Digital Securities, Category 1 Model B | | Settlement | USDC and PYUSD per GENIUS Act | *** ### 1.2 Three Production Modules — One Architecture The platform's RWA Tokens product line consists of three production modules deployed under a single technical architecture: | Module | Asset Class | Backing Instrument | Asset Identifier | Module-Aware Extension | | -------------------------- | -------------------------------------------------------------------------------- | -------------------------------------- | ---------------- | ----------------------------- | | **Module 1 — Equities** | OTC microcap, NASDAQ, AMEX, TSX, foreign-exchange equity | Common Class B | CUSIP | None (architectural baseline) | | **Module 2 — Real Estate** | Commercial, multi-family, hospitality, mixed-use, land | SAE common stock (Single-Asset Entity) | Property ID | CB-21 NAV-deviation variant | | **Module 3 — CORECM** | Carbon Ore, Rare Earth, Critical Minerals; basin-asset and processing facilities | BAE common stock (Basin-Asset Entity) | Basin ID | REG-42 federal-action variant | All three modules execute through the same 42-control immutable Transfer Hook plus their applicable module-aware extensions. The same Empire Stock Transfer §17A custody and onboarding gate covers all three modules. The same Global Unified Liquidity Pool serves all three modules. The same CEDEX trading venue serves all three modules. This is not three separate products. It is **one runtime-enforced compliance stack** with module-aware extensions that plug into the immutable 42-control surface. *** ### 1.3 The Architectural Distinction — Compliance by Runtime, Not by Convention The SEC Crypto Task Force and the January 28, 2026 Joint Staff Statement on Tokenized Securities draw a binary distinction between: * **Category 1 Model B** — Issuer-Sponsored Tokenization where DLT is the official register, custody is §17A-qualified, and compliance is enforced at the runtime layer * **Category 2** — Third-Party Sponsored Tokenization where compliance is application-layer overlay code that can be bypassed ERC-3643 (the dominant Ethereum tokenization standard, $32B+ tokenized over 8+ years) is a Category 2 architecture. Its `transfer()` function is bypassable; its admin functions (`forceTransfer`, `freezePartialTokens`, `recoveryAddress`) violate Pillar 7 (Token Standard Compliance — immutable, no admin override). ST22 (the platform's tokenization product line, built on SPL Token-2022 Transfer Hook) is a Category 1 Model B architecture. It satisfies all seven pillars natively at the Solana runtime: | # | Category 1 Model B Pillar | ERC-3643 Native | ST22 Native | | - | -------------------------------------------------------- | ----------------------------------------------------------- | --------------------------------------------------------------- | | 1 | Direct Issuer Authorization | ⚠️ off-chain only | ✅ on-chain Empire onboarding gate | | 2 | Official Shareholder Register on DLT | ❌ token ledger is ERC-20 balances; off-chain reconciliation | ✅ Empire MSF + SPL Token-2022 ledger reconciled per Solana slot | | 3 | SEC §17A-Registered Qualified Custody | ⚠️ possible but rare | ✅ Empire architecturally required | | 4 | True Equity Backing 1:1 | ⚠️ off-chain attestation periodic | ✅ Custody Oracle Ed25519 attestation per slot | | 5 | Clear Ownership Chain / Asset ID | ⚠️ off-chain mapping | ✅ on-chain CUSIP (M1) / property ID (M2) / basin ID (M3) | | 6 | Investor Protection (compliance at every transfer) | ⚠️ application-layer | ✅ runtime-enforced 42 controls + module extensions | | 7 | Token Standard Compliance (immutable, no admin override) | ❌ proxy upgrades + admin functions | ✅ Transfer Hook bound at mint creation; Certora E.4, E.6 | **Native score: ST22 = 7/7. ERC-3643 = 3/7.** Section 14 documents the seven-pillar comparison in full. *** ### 1.4 The Three-Token Classification The platform is associated with three distinct token classes with three distinct legal treatments: #### 1.4.1 GROO Utility Token * **Classification:** Release No. 33-11412 Category 1 (Digital Commodity) or Category 3 (Digital Tool) — **not a security** * **Backing:** None * **Function:** Ecosystem utility — staking discounts, governance rights post-graduation (2028+), transaction fee discounts * **Distribution:** Deterministic linear bonding curve starting at 0.000001 SOL; no pre-sale; no founder allocation; no treasury reserve; no ICO until governance-decided Scale phase Dutch auction The GROO Utility Token is **not** an STO, **not** an ICO instrument, and **not** backed by Common Class B shares. The phrase "GROO STO" is categorically wrong. #### 1.4.2 Groovy Security Token (STO) * **Classification:** Release No. 33-11412 Category 5 Digital Security * **Backing:** Common Class B shares of Groovy Company, Inc. itself * **Offering:** $20M Reg D * **Use of proceeds:** Seeds the Global Unified Liquidity Pool via Solana Treasury #### 1.4.3 ST22 Digital Securities * **Classification:** Release No. 33-11412 Category 5 Digital Security * **Backing:** Common Class B (M1) / SAE equity (M2) / BAE equity (M3) * **Function:** Per-issuer per-module equity tokenization product line * **Compliance:** Full ST22 framework — 42 controls + module-aware extensions; HP-24; Empire onboarding; CEDEX-only trading * **Offering exemptions:** Reg D (US accredited), Reg S (non-US), Reg CF (US retail) *** ### 1.5 The Empire Stock Transfer Foundation Empire Stock Transfer is the platform's exclusive SEC §17A-registered transfer agent and qualified custodian. Empire holds the underlying equity (Common Class B for M1, SAE equity for M2, BAE equity for M3) on a 1:1 basis behind every issued ST22 token across all three modules. Empire is the **sole** authority for ST22 investor onboarding (KYC, KYB, AML, OFAC/SDN screening, wallet verification, jurisdiction determination, accreditation under Reg D, Reg CF eligibility under JOBS Act §4(a)(6)). The platform does **not** perform investor onboarding directly. The platform's investor portal routes to Empire's onboarding dashboard. After Empire approves an investor, Empire signs the wallet-verification attestation that Control IV-15 reads on transfer. Empire's per-Solana-slot Ed25519 custody attestation (\~400 ms cadence) is the architectural anchor for Pillar 4 (True Equity Backing, 1:1) — verified on every transfer by Control CV-01. *** ### 1.6 CEDEX as the Only Legitimate ST22 Venue CEDEX Market (cedex.market) is the platform-operated trading venue. It is the **only** venue at which Transfer Hook controls and module-aware extensions execute correctly. External Solana DEXs (Raydium, Orca, Jupiter, Phoenix) cannot host ST22 mints — empirical beta validation in October 2025 confirmed they bypass all 42 controls. CEDEX is purpose-built around Transfer Hook semantics with two-layer architecture (centralized order matching + decentralized Solana settlement), custom Constant Product Market Maker (CPMM), and 5% total fee distributed across issuer (2%), staking rewards (1.5%), protocol (1.06%), and Global Pool permanent lock (0.44%). CEDEX operates 24/7/365. There are no market hours. Settlement is atomic on Solana with \~400 ms finality. *** ### 1.7 The Global Unified Liquidity Pool A single shared CPMM liquidity pool serves all three modules. The pool is initialized at platform genesis with seed liquidity from (1) Groovy Security Token (STO) $20M Reg D proceeds, (2) initial Staking Pool allocation, (3) the 0.44% permanent lock on all CEDEX transaction volume from inception, (4) investor secondary sale proceeds, (5) 2% staking reward reinvestment. **LP tokens representing the protocol's pool position are burned at inception. There is no withdrawal function.** Certora invariant E.3 formally proves no execution path exists by which the pool's reserves can be debited to a withdrawal destination. This is the mathematical guarantee of non-rugpull. Every CEDEX trade contributes 0.44% of trade value to the pool's permanent locked reserve. The pool deepens monotonically with platform volume across all three modules — a self-reinforcing cross-module network effect that no per-mint or per-issuer pool architecture can produce. *** ### 1.8 GENIUS Act Stablecoin Settlement All ST22 purchases and CEDEX trades settle in **USDC** (Circle) or **PYUSD** (Paxos) under the federal GENIUS Act framework. No fiat wires; no native crypto (SOL, BTC, ETH). Stablecoin settlement provides: * Regulatory clarity under the GENIUS Act * Atomic on-chain settlement matched to \~400 ms Solana finality * Elimination of fiat wire-clearance latency (1–3 business days) * No counterparty risk on the settlement leg (USDC and PYUSD are 1:1 USD-backed with monthly reserve attestations) *** ### 1.9 Reg D / Reg S / Reg CF Triple Coverage The platform operates under three offering exemption regimes, all natively enforced at the runtime layer per investor: | Regime | Investor Class | Holding Period | On-Chain Field | | ------ | ---------------------- | ------------------------ | --------------------- | | Reg D | US accredited | 6 months (15,778,800 s) | `Jurisdiction::RegD` | | Reg S | Non-US | 12 months (31,536,000 s) | `Jurisdiction::RegS` | | Reg CF | US retail crowdfunding | 12 months (31,536,000 s) | `Jurisdiction::RegCF` | Holding periods are immutable timers stored in the per-investor-mint `HoldingPeriodAccount` PDA. The `purchase_timestamp` field is set exactly once at token delivery and is never written after. Certora invariant E.5 formally proves the timer cannot be shortened by any execution path. *** ### 1.10 Three-Module Addressable Market | Segment | Estimated Size | Module | | --------------------------------- | ------------------------------------------------------------------------------------------------ | -------- | | OTC microcap equity | $50B+ underserved at the microcap end | Module 1 | | NASDAQ / AMEX / TSX-listed equity | Tens of trillions globally | Module 1 | | Foreign exchange equity | Multi-trillion; tokenization addressable subset growing | Module 1 | | Global real estate | $280T+; tokenization addressable subset emerging | Module 2 | | US critical minerals supply chain | Strategic priority under EO 14017, IRA, Energy Act of 2020; no public-chain platform competitive | Module 3 | *** ### 1.11 Document Roadmap This whitepaper is structured in five parts: | Part | Sections | Coverage | | ------------------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------ | | **Part I — Foundation** | 1–4 | Executive Summary, Nine-Layer Architecture overview, Regulatory Framework, Three-Token Classification | | **Part II — Architecture** | 5–10 | Solana, Transfer Hook, Modules 1/2/3 | | **Part III — Custody, Oracle, Settlement** | 11–15 | Empire Stock Transfer §17A, Oracle Network, CEDEX, Liquidity Pool, GENIUS Act stablecoin settlement | | **Part IV — Intelligence, Governance, Economics** | 16–18 | Layer 9 IDOS, Governance, Tokenomics | | **Part V — Comparison, Security, Roadmap** | 19–23 | ERC-3643 vs ST22, Security and formal verification, Beta validation and Alesia Doctrine, Roadmap, References | Sections 8, 9, and 10 dedicate full technical specifications to Modules 1, 2, and 3 respectively, including Rust/Anchor code, account schemas, oracle architectures, control table breakdowns, and reference use cases. *** *RWA Tokens Whitepaper V10 — Section 1 — Confidential — Groovy Company, Inc.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://bitbook.rwatokens.net/reference/reference/whitepaper-v10.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.