Nine-Layer Technical Architecture
Section 2: Nine-Layer Technical Architecture
RWA Tokens Platform Whitepaper · Version 10.0 Groovy Company, Inc. · May 2026 Document Reference: RWA-ARCH-001 v2.0
The platform is structured as a nine-layer technology stack. Each layer has a distinct responsibility; layers communicate through documented interfaces. Module-aware extensions in V10 plug into Layer 2 (Transfer Hook) and Layer 6 (Oracle Network) without changing the inter-layer contracts.
2.1 Layer Stack Overview
Layer 1
Solana Blockchain Foundation
Distributed consensus; transaction execution; ~400 ms finality; ~$0.00025 per transaction
Layer 2
SPL Token-2022 Transfer Hook
42 immutable controls + module-aware extensions (CB-21 NAV variant for M2; REG-42 federal variant for M3); runtime-enforced compliance
Layer 3
Core Protocol
SecurityConfig PDA; HoldingPeriodAccount PDA; mint authority; module dispatch; Anchor program structure
Layer 4
Global Unified Liquidity Pool
Single shared CPMM pool serving all three modules; LP burned at inception (Certora E.3)
Layer 5
CEDEX Market
Compliant Exchange for Digital Securities; only legitimate ST22 trading venue; two-layer (off-chain match + on-chain settlement)
Layer 6
Oracle Network
Custody (Empire) · OFAC · AML · TWAP · EDGAR (M1) · NAV (M2) · Classification (M3)
Layer 7
Protocol Governance
On-chain proposals; 3-of-5 multi-sig; 48-hour timelock; tripartite-concurrence governance for module-aware parameters; immutable Transfer Hook out of scope
Layer 8
Wallet Infrastructure
Phantom · Solflare · Backpack · Coinbase Wallet · Ledger; Ledger Enterprise for institutional
Layer 9
IDOS — Issuer Distress and Opportunity Score
Off-chain compliance intelligence; XGBoost ensemble; EDGAR NLP; behavioral profiling
Layer 2 is the architectural keystone. It is the layer at which the SEC Category 1 Model B "compliance enforcement at every transfer" pillar is satisfied. Every other layer either feeds Layer 2 (Layers 1, 6, 8) or operates downstream of Layer 2 (Layers 3, 4, 5, 7, 9).
2.2 Architecture Design Principles
2.2.1 Compliance at the Primitive
Compliance is enforced at the SPL Token-2022 transfer primitive, not at the application layer. There is no path by which a transfer can occur without invoking the registered Transfer Hook. The Solana runtime — not platform code — enforces this: the Token-2022 program refuses to process a transfer instruction on a hook-extended mint without executing the registered hook program.
2.2.2 Module-Aware Without Forking
V10 introduces module-aware behavior without forking the architecture. The 42 core controls are unchanged from V8. Module-aware extensions plug into the existing surface as additive runtime checks that execute conditionally on SecurityConfig.module. A V8 mint with module = 1 (Equities) executes exactly as it did under V8 — the extensions short-circuit to no-op for that module.
2.2.3 Single Shared Liquidity Pool
The Global Unified Liquidity Pool is shared across all three modules. This contradicts conventional AMM design (one pool per token pair) but produces a network effect: every module's volume deepens liquidity for every other module. Certora invariant E.3 proves the pool's reserves are non-extractable; LP tokens are burned at inception.
2.2.4 §17A-Anchored Custody
Empire Stock Transfer is the architectural anchor. Empire's §17A registration, custody operations, and Ed25519 attestation per Solana slot are what allow the platform to satisfy Pillar 3 (SEC §17A-Registered Qualified Custody) and Pillar 4 (True Equity Backing 1:1) as architectural properties rather than process assertions. Empire's role spans all three modules — same custody gate, same onboarding gate, same attestation cadence.
2.2.5 Immutability After Deployment
Once an ST22 mint is deployed, its compliance program (Transfer Hook) cannot be removed, repointed, or weakened. Certora invariants E.4 and E.6 formally prove this. Module-aware extensions are bound at mint creation via SecurityConfig.module and cannot be changed after.
2.3 Layer-by-Layer Technical Detail
2.3.1 Layer 1 — Solana Blockchain Foundation (See Section 6)
Network
Solana Mainnet-Beta
Consensus
Proof-of-History + Proof-of-Stake (Tower BFT)
Block time
~400 ms
Finality
~400 ms (single-block under typical conditions)
Transaction cost
~$0.00025 per transfer
Throughput (compliance-verified)
400–600 TPS
Native cryptography
Ed25519 (signatures); Solana native precompile for verification
Account model
Program Derived Address (PDA); deterministic seed-based derivation
2.3.2 Layer 2 — SPL Token-2022 Transfer Hook (See Section 3)
Standard
SPL Token-2022 with transfer-hook-interface v0.6+ extension
Implementation
Rust / Anchor framework
Core controls
42 (V6 categorized; CV / SX / IV / PL / CB / HP / PC / GA)
Module-aware extensions
2 (CB-21 NAV variant — M2; REG-42 federal variant — M3)
Execution latency target
< 1,000 ms (parallel where possible)
Compute unit budget
M1 ≈ 800 K CU · M2 ≈ 820 K CU · M3 ≈ 830 K CU
Bypass possibility
Zero — runtime-enforced by Token-2022 program
Immutability
Hook program ID bound to mint at creation; Certora E.4, E.6
2.3.3 Layer 3 — Core Protocol
Layer 3 is the protocol's stateful core. It provides:
SecurityConfig PDA
Per-mint security parameters; module classification; module-aware extension fields
HoldingPeriodAccount PDA
Per-investor-mint holding-period state (Reg D / Reg S / Reg CF)
CustodyOracle PDA
Empire's per-slot Ed25519 custody attestation; module-agnostic with class_label (CommonB / SAE / BAE)
NavOracle PDA
Module 2 only — authorized appraiser NAV attestation
ClassificationOracle PDA
Module 3 only — federal-action classification status
OfacOracle, AmlOracle, TwapOracle PDAs
Cross-module compliance and pricing oracles
mint_authority
Issuer multi-sig with timelock controls per module governance
PDA seeds use stable conventions (e.g., [b"security-config", mint.key().as_ref()]) to ensure deterministic resolution by clients and programs.
2.3.4 Layer 4 — Global Unified Liquidity Pool (See Section 14)
Architecture
Single shared CPMM (x · y = k)
Reserves
Stablecoin reserve (USDC + PYUSD aggregate) and ST22 reserve (cross-module token-mix)
LP tokens
Burned at inception
Withdrawal
None — no execution path debits pool reserves to withdrawal destination (Certora E.3)
Self-reinforcement
0.44% of every CEDEX trade adds to permanent locked reserve
Cross-module
All three modules share the same pool
2.3.5 Layer 5 — CEDEX Market (See Section 7)
URL
cedex.market
Architecture
Two-layer: centralized order matching (off-chain) + decentralized Solana settlement (on-chain)
AMM
Custom CPMM purpose-built for Transfer Hook compatibility
Hours
24/7/365
Fee
5% total — 2% issuer / 1.5% staking / 1.06% protocol / 0.44% Global Pool locked
Settlement
USDC / PYUSD only (GENIUS Act); ~400 ms finality
Order types
Market, limit, stop, time-in-force
Slippage default
50 bps (configurable)
2.3.6 Layer 6 — Oracle Network (See Section 12)
Seven oracle categories, all using Ed25519 attestation and Solana native precompile verification:
1
Custody Oracle
Empire Stock Transfer
M1, M2, M3
Per slot (~400 ms)
2
OFAC Oracle
OFAC SDN feed
M1, M2, M3
Hourly
3
AML Oracle
Chainalysis KYT + TRM Labs
M1, M2, M3
Per-wallet on demand
4
TWAP Oracle
Pyth Network
M1, M2, M3
Per slot
5
EDGAR Oracle
SEC EDGAR
M1
Per filing
6
NAV Oracle
Authorized appraiser
M2
Per reappraisal cadence (default 90 days)
7
Classification Oracle
Federal Register, USGS, DOE
M3
Per relay polling cycle (≤ 24 hours)
2.3.7 Layer 7 — Protocol Governance
Governance applies to a defined set of platform parameters. The 42 immutable Transfer Hook controls and the module-aware extensions are explicitly out of governance scope (Certora invariants E.4, E.5, E.6). Governance can modify:
Per-mint NAV-deviation tolerance (M2)
Tripartite concurrence: SAE issuer + appraiser + Empire
Per-mint reappraisal cadence (M2)
Tripartite concurrence
Per-mint Classification staleness (M3)
Tripartite concurrence: BAE issuer + Classification relay + Empire
Per-mint federal-action enable/disable (M3)
Tripartite concurrence
Wallet caps within statutory bounds
Issuer multi-sig
Oracle relay public keys
3-of-5 multi-sig + 48-hour timelock
CEDEX parameters
Platform governance
Fee distribution within fixed 5% total
Platform governance
2.3.8 Layer 8 — Wallet Infrastructure
Phantom
Retail Solana wallet (browser + mobile)
Solflare
Retail / power user; hardware wallet support
Backpack
Multi-chain native; xNFT support
Coinbase Wallet
Coinbase ecosystem integration
Ledger (hardware)
Cold storage / hardware signing
Ledger Enterprise
Institutional key management; multi-user / multi-device coordination; required for all ST22 issuance and platform-side operations
2.3.9 Layer 9 — IDOS (See Section 16)
The Issuer Distress and Opportunity Score is the platform's off-chain compliance intelligence module. IDOS consumes:
EDGAR filing surface (M1 issuer-distress signals)
NAV oracle history (M2 deviation patterns)
Classification oracle history (M3 federal-action frequency)
On-chain trading activity (wash trading, layering, spoofing patterns)
Wallet behavioral signals
IDOS produces per-issuer risk and opportunity scores via XGBoost ensemble. IDOS does not modify on-chain compliance enforcement — the 42 controls + module-aware extensions are immutable. IDOS is analytical and operational intelligence that informs compliance reviewer escalation, regulatory reporting preparation, and Empire onboarding gate enrichment.
2.4 Cross-Layer Communication
2.4.1 Transfer Settlement Path (Critical Path)
A successful trade traverses the layers as follows:
2.4.2 Oracle Update Path
Oracle updates use a separate path that does not involve transfers:
2.4.3 Governance Action Path
Governance actions traverse Layer 7 with multi-sig and timelock:
2.5 V10 Architectural Changes vs V8
Module classification
Single (Equities)
Three (Equities, Real Estate, CORECM)
SecurityConfig schema
V8 fields
V8 fields + module, asset_identifier, NAV-deviation fields, federal-action fields
HoldingPeriodAccount Jurisdiction enum
{US, NonUS}
{RegD, RegS, RegCF}
Backing class
Common Class B (Common B) only
Common B (M1) + SAE (M2) + BAE (M3)
Asset identifier
CUSIP
CUSIP (M1) / property ID (M2) / basin ID (M3)
Oracle categories (Layer 6)
5 (custody, OFAC, AML, TWAP, EDGAR)
7 (added NAV for M2; Classification for M3)
Module-aware extensions
None
CB-21 NAV-deviation variant (M2); REG-42 federal-action variant (M3)
Reg CF support
Not supported
Supported via funding-portal partnership; HP-24 and IV-19 enforce
Tripartite-concurrence governance
Not applicable
Required for M2 NAV-band parameter changes; M3 Classification parameter changes
V8 mints are fully forward-compatible: they default to module = 1, zero-valued module-aware fields, and execute exactly as in V8.
2.6 Architecture and SEC Category 1 Model B Mapping
The architecture maps to SEC Category 1 Model B's seven pillars as follows:
1. Direct Issuer Authorization
Layer 5 (CEDEX listing) + Layer 6 (Custody Oracle)
Empire onboarding gate refuses mint without filed Certificate of Designation / Articles
2. Official Shareholder Register on DLT
Layer 1 (Solana) + Layer 6 (Custody Oracle)
Empire MSF + SPL Token-2022 ledger reconciled per-slot via Ed25519 attestation under W.S. 34-29-101
3. SEC §17A-Registered Qualified Custody
Layer 6 (Custody Oracle) + Layer 11 architectural
Empire Stock Transfer §17A-registered; sole custody and onboarding authority
4. True Equity Backing (1:1)
Layer 2 (Control CV-01) + Layer 6 (Custody Oracle)
Per-slot Ed25519 attestation; CV-01 verifies on every transfer
5. Clear Ownership Chain / Asset ID
Layer 2 (Control CV-05) + Layer 3 (SecurityConfig)
asset_identifier field bound at mint creation; CUSIP (M1) / property ID (M2) / basin ID (M3)
6. Investor Protection (compliance at every transfer)
Layer 2 (Transfer Hook)
42 controls + module-aware extensions; runtime-enforced; no bypass
7. Token Standard Compliance (immutable, no admin override)
Layer 1 + Layer 2
Token-2022 hook extension immutability; Certora E.4, E.6
RWA Tokens Whitepaper V10 — Section 2 — Confidential — Groovy Company, Inc.
Last updated
Was this helpful?