|
| Platform Website | rwatokens.net |
| Technical Whitepaper (V10.0) | rwatokens.net/whitepaper |
| Issuer Gateway | rwatokens.net/issuers |
| CEDEX Trading Venue | cedex.market |
| Principal Office | 600 W Peachtree St NW, Suite 1700, Atlanta, GA 30308 |
| Domicile | Wyoming |
| SEC EDGAR CIK | 1499275 · OTC Ticker: GROO |
© 2026 Groovy Company, Inc. All rights reserved.
Open Source · Public Domain · Free to Distribute · Version 10.0 · Wyoming Corporation · CIK: 1499275 · OTC: GROO
Disclaimer
This document is for informational purposes only and does not constitute an offer to sell or a solicitation of an offer to buy any securities. Tokens issued through any RWA Tokens module are offered exclusively to verified accredited investors under SEC Reg D and Release No. 33-11412, to non-U.S. investors under Reg S, or to U.S. retail investors under Reg CF subject to per-investor SEC limits. Investment in Digital Securities involves significant risk, including possible loss of the entire investment. Past beta validation results (Module 1) are not indicative of future performance for any module. Real Estate (Module 2) tokens are subject to property-specific risk including market, location, and condition risk; appraised NAV is an estimate and may differ materially from realizable value. CORECM (Module 3) tokens are subject to commodity-price risk, geological reserve-revision risk, regulatory permitting risk, and the inherent uncertainty of reserve estimates even at SPE-PRMS Proved 1P or JORC Measured classifications. Groovy Company, Inc. is a Wyoming Corporation (CIK: 1499275).
# Competitive Analysis
RWA Tokens vs. Securitize and Module-Specific Competitors
Three-Module Digital Securities Landscape · Architecture · Regulatory Compliance
Groovy Company, Inc. · Version 10.0 · May 2026
**Executive Summary**
The tokenized real-world asset market has bifurcated into single-asset-class platforms — Securitize and ERC-3643 derivatives in institutional equities; RealT, Lofty, and Tokeny in real estate; royalty-financing platforms and early-stage mineral-rights tokenization startups in critical minerals. Each category leader rebuilds compliance, custody, and trading infrastructure for a single asset class.
RWA Tokens consolidates three asset-class modules behind a single Solana-native compliance kernel, a single qualified custodian (Empire Stock Transfer), and a single trading venue (CEDEX). The architectural decision is not a feature — it is the central thesis: an issuer who clears compliance for one module clears it for all three; an investor onboarded by Empire for one module is whitelisted across all three; transaction volume from any module deepens shared liquidity for all three.
Securitize remains the institutional-equity benchmark (BlackRock, Apollo, KKR, Hamilton Lane; $4B+ tokenized; $1.25B SPAC valuation). RWA Tokens does not compete with Securitize for BlackRock-style mandates and does not need to. RWA Tokens competes on a different dimension: cross-asset-class infrastructure with mathematically-enforced compliance and permanent shared liquidity. This document maps the competitive landscape across all three modules.
Strategic thesis: Securitize and the single-asset-class incumbents represent the institutional bridge between traditional finance and tokenized RWAs. RWA Tokens represents the destination — a unified compliance kernel that scales across asset classes without rebuilding regulatory and custody infrastructure for each one.
**Part I — Securitize Profile**
Company Overview and Institutional Dominance
Securitize was founded in November 2017 by Carlos Domingo and Jamie Finn to serve as a bridge between traditional capital markets and blockchain-based securities. The company raised approximately $147–200 million across funding rounds, with a pivotal $47 million Series C in May 2024 led by BlackRock. This investment placed Joseph Chalom, BlackRock's Global Head of Strategic Ecosystem Partnerships, on Securitize's board, cementing the institutional relationship that defines the company's market position.
In October 2025, Securitize announced a SPAC merger with Cantor Equity Partners II at a $1.25 billion pre-money valuation, with an expected Nasdaq listing under ticker SECZ in the first half of 2026. The BlackRock relationship represents Securitize's crown jewel. The BUIDL fund (BlackRock USD Institutional Digital Liquidity Fund), launched in March 2024, has grown to more than $2.5 billion in AUM — the world's largest tokenized real-world asset. Beyond BlackRock, Securitize counts Apollo, KKR, Hamilton Lane, and VanEck as institutional clients.
Regulatory Positioning — Issuer-Sponsored Model
In its October 2025 submission to the SEC Crypto Task Force, CEO Carlos Domingo articulated Securitize's core regulatory philosophy: intermediaries should not tokenize public equity without the issuer's direct involvement and assent. The company's SEC-registered digital transfer agent works directly with issuers to natively mint tokenized securities without intermediary layers.
• Permissioned Architecture: All investors are KYC-verified and wallets whitelisted before any transaction can occur
• Rules-Based Smart Contracts: Enforce lawful transfers and AML compliance throughout the asset lifecycle
• Token Recovery: Lost, stolen, or impaired tokens can be burned and reissued by the transfer agent
• Not Bearer Securities: Securitize emphasizes regulatory accountability of token holders
Securitize's SEC submission characterizes competing approaches — including permissionless wrapped tokens and derivative securities — as regulatory arbitrage that creates an uneven playing field. This reflects Securitize's institutional DNA: build within existing frameworks rather than seek exemptions. RWA Tokens shares this philosophical commitment to operating within the federal securities laws, but reaches a different architectural conclusion about how to enforce compliance at the protocol layer.
Technology Architecture — Middleware on Public Chains
Securitize operates as blockchain-agnostic middleware, deploying the ERC-3643 (T-REX) token standard across more than 15 public blockchains including Ethereum, Polygon, Avalanche, and Solana. While this multi-chain approach provides flexibility, Securitize runs no blockchain infrastructure of its own. The platform inherits the limitations of general-purpose chains — gas fee volatility, scalability constraints, and computational limits on complex compliance rules.
Critical Limitations
| Limitation | Detail |
| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| Limited Liquidity | Securitize Markets ATS reports approximately $600,000 in daily trading volume — modest for a platform claiming market leadership |
| Trading Disruptions | User complaints document trading suspended for months due to custodian restructuring — operational dependencies outside Securitize's control |
| Admin Overrides | ERC-3643 includes force transfer, freeze, and recovery functions allowing administrators to override on-chain ownership |
| High Costs | Setup fees exceeding $100,000 and minimum investments of $10,000–$5,000,000 exclude smaller issuers and retail investors |
| External Infrastructure | Relies on external DEXs and bridges (Wormhole) for broader liquidity — counterparty and smart-contract risk outside Securitize's control |
| Single Asset Class | Securitize platform is purpose-built for institutional equity tokenization; real estate and commodities require parallel infrastructure investment |
**Part II — RWA Tokens Advantages**
Complete Infrastructure Control — The Alesia Doctrine
RWA Tokens' architecture reflects a strategic philosophy drawn from Caesar's siege of Alesia: build complete defensive infrastructure rather than rely on external dependencies. Where Securitize deploys on public chains it does not control, RWA Tokens builds proprietary infrastructure on Solana specifically designed for Digital Securities operations across three asset-class modules.
This architectural decision emerged from a critical discovery during development. Major decentralized exchanges including Raydium, Orca, and Meteora cannot support SPL Token-2022 Transfer Hooks, meaning that tokens traded on these platforms would lose all 42 security controls. Rather than compromise compliance to fit existing infrastructure, RWA Tokens built CEDEX — a custom exchange that preserves all 42 Transfer Hook controls on every transaction across all three modules.
Three-Module Architecture — One Compliance Kernel
The single most consequential V10 advancement is module unification. RWA Tokens runs three asset-class modules on identical infrastructure:
| Module | Asset Class | Backing Instrument | Reference Price |
| ------------------------ | ------------------------------------------------------------ | ---------------------------------------------------------------------- | ----------------------------------------- |
| Module 1 — ST22 Equities | OTC microcap, NASDAQ, AMEX, TSX, and all global exchanges | 1:1 Common Class B (Empire custody) | Pyth TWAP |
| Module 2 — Real Estate | Commercial and investment-grade real property | Common Class B in property-holding Nevada corporation (Empire custody) | Independent appraiser NAV (cadence-based) |
| Module 3 — CORECM | Carbon Ore, Rare Earth & Critical Minerals revenue interests | Operator Common Class B or royalty assignment units (Empire custody) | SPE-PRMS reserve attestation |
Module-conditional logic exists only at Layer 6 (Oracle Network — appraisal for Module 2, reserve attestation for Module 3) and Layer 2 (Transfer Hook — module-aware custody verification). The other seven layers operate identically across all three modules. This is the architectural differentiator no single-asset-class competitor can replicate without rebuilding their entire platform.
Regulatory Positioning — Category 1 Model B, Release No. 33-11412
RWA Tokens' regulatory engagement with the SEC Crypto Task Force culminated in full alignment with Release No. 33-11412 (March 17, 2026) and the January 28, 2026 Joint Staff Statement on Tokenized Securities, which together established the binding framework for compliant tokenization.
| SEC Category 1 Model B Requirement | RWA Tokens Implementation | Authority |
| ---------------------------------- | ------------------------------------------------------------------------------------------------- | --------- |
| Issuer Authorization | Board resolution required before any module token minting | Binding |
| Official Shareholder Register | Empire Stock Transfer master file (all three modules) | Binding |
| SEC-Registered Custodian | Empire Stock Transfer — Exchange Act §17A registered | Binding |
| True Equity Backing (Module 1, 2) | 1:1 Common Class B Shares · irrevocable Empire custody | Binding |
| True Asset Backing (Module 3) | 1:1 operator Common Class B or royalty assignment units · irrevocable Empire custody | Binding |
| Digital Securities Classification | All module tokens classified under Release No. 33-11412 | Binding |
| CUSIP Assignment | Common Class B shares receive official CUSIP at issuance | Binding |
| Investor Protections | 42 Transfer Hook controls + module-conditional controls (appraisal currency, reserve attestation) | Binding |
SEC Quote — January 28, 2026 Joint Staff Statement: "Form should be disregarded for substance, and the emphasis should be on economic reality." This principle directly validates the Category 1 Model B architecture across all three RWA Tokens modules: Empire Stock Transfer maintains the authoritative off-chain master securityholder file; the Solana blockchain serves as the operational notification layer.
Part IIa — Token Standard Architecture
Securitize: ERC-3643 on Ethereum and EVM Chains
Securitize builds on ERC-3643 (T-REX), developed by Tokeny Solutions. With more than $28 billion in tokenized assets, ERC-3643 is the dominant standard for institutional security tokens on Ethereum. Its architecture adds compliance functionality through a five-component overlay: T-REX Token contract, ONCHAINID (ERC-734/735), Identity Registry, Compliance Contract, and Trusted Issuers Registry.
• Admin Override Vulnerability: forceTransfer(), freezePartialTokens(), and recoveryAddress() allow administrators to move tokens without holder consent
• Registry Manipulation Risk: Compliance depends on off-chain identity registries that can be modified
• Gas Volatility: Ethereum transaction fees have historically ranged from $1 to more than $40 during network congestion
• Throughput Constraints: Ethereum processes approximately 15 TPS, creating bottlenecks at scale
• Application-Layer Bypass Risk: Compliance checks are application-layer smart contract calls — a caller with direct EVM access can bypass the T-REX overlay entirely
RWA Tokens: SPL Token-2022 (ST22) on Solana
RWA Tokens builds on Solana's Token-2022 program, a native upgrade to Solana's SPL token standard that embeds compliance directly into the protocol layer. Unlike ERC-3643's smart contract overlay, Token-2022 Transfer Hooks execute inside the Solana runtime — there is no bypass path. This single property is why CEDEX is structurally the only venue capable of trading ST22 tokens with compliance preserved.
• Runtime Enforcement: Transfer Hook controls execute inside the Solana runtime — mathematically impossible to bypass regardless of caller
• Atomic Execution: 42 baseline + module-conditional controls execute atomically with the token transfer — any control failure reverts the entire transaction
• No Admin Override: No forceTransfer equivalent exists — immutability is architectural, not policy
• Module-Aware Custody: Empire signs module-discriminated Ed25519 attestations every block — cross-module attestation forgery rejected at runtime (Error 6043)
• Ultra-Low Costs: \~$0.00025 per transaction enables compliance verification on every transfer at any market cap
• Near-Instant Finality: \~400ms vs. Ethereum's 12+ second block times
• Formally Verified: Certora formal verification of mathematical invariants pre-mainnet, including 1:1 module-aware backing across all three modules
Token Standard Comparison
| Dimension | ERC-3643 (Securitize) | ST22 (RWA Tokens) |
| ------------------------- | ------------------------------------ | --------------------------------------------------------------- |
| Blockchain | Ethereum + EVM chains (15+) | Solana — purpose-built infrastructure |
| Architecture | Smart contract overlay on ERC-20 | Native runtime-level Transfer Hooks |
| Compliance Enforcement | Application-layer — bypassable | Runtime-enforced — no bypass path |
| Admin Override | Yes — forceTransfer, freeze, recover | No — mathematically impossible |
| Multi-Asset-Class Support | Single architecture per asset class | One kernel · three modules · module-aware logic at Layers 2 & 6 |
| Transaction Cost | $1–$40+ gas fees | \~$0.00025 |
| Transaction Speed | \~15 TPS, 12+ second blocks | 65,000+ TPS, \~400ms finality |
| Bypass Risk | Possible via direct EVM call | None — runtime enforcement |
| Immutability | Upgradeable proxy contracts | Immutable 42 controls |
| Formal Verification | Audited (no formal proofs) | Certora — formally proved invariants |
Part IIb — Exchange and Liquidity Infrastructure
Securitize — Dependent on External Exchange Infrastructure
Securitize operates Securitize Markets, an SEC-registered ATS, as its primary secondary trading venue. This infrastructure faces significant limitations that constrain liquidity and create operational risks outside Securitize's control.
• Limited Volume: approximately $600,000 daily trading volume on the ATS
• Limited Hours: traditional market hours only — no 24/7 global access
• Trading Suspensions: user reports document suspensions lasting months during custodian restructuring events
• External Dependencies: relies on Wormhole and external DEXs for broader liquidity — third-party failure vectors
• Withdrawal Risk: third-party market makers and liquidity providers can withdraw at any time
RWA Tokens — CEDEX + Global Unified Liquidity Pool
RWA Tokens owns and operates CEDEX — a purpose-built Compliant Exchange for Digital Securities — with the Global Unified CEDEX Liquidity Pool providing permanent, protocol-owned liquidity shared across all three modules.
• Complete Ownership: CEDEX is wholly owned and operated by Groovy Company, Inc. — no external dependencies
• 24/7/365 Operation: global investor participation across all time zones without market hour restrictions
• Integrated Compliance: Transfer Hook controls execute on every CEDEX trade across every module — compliance is the trade, not a pre-trade check
• Cross-Module Liquidity: a single liquidity pool shared across Equities, Real Estate, and CORECM — Module 2 transaction volume deepens Module 1 and Module 3 liquidity, and vice versa
• Permanent Liquidity: Global Pool funded by Groovy Treasury + Staking Pool reinvestment + 0.44% fee lock on every transaction across all modules
• LP Tokens Burned: LP tokens burned at pool initialization — withdrawal mathematically impossible for any party including Groovy Company itself
Global Unified CEDEX Liquidity Pool — V10 Architecture
The pool is funded by three sources: (1) Groovy Treasury — protocol-owned SOL treasury provides initial seeding and ongoing support; (2) Staking Pool — 2% of every staking reward distributed routes to the Global Pool via immutable Transfer Hook before rewards reach staker wallets; (3) 0.44% of every Digital Securities transaction across all three modules — permanently locked by immutable Transfer Hook on both primary offerings and CEDEX secondary trades.
There is no per-module pool architecture. The Global Pool is shared across all ST22 issuers in all three modules. Each new issuer in any module adds transaction volume that deepens liquidity for all issuers across all modules. This is the structural advantage of unified-kernel design over single-asset-class competitors who must build separate liquidity for each asset class they support.
| Exchange Attribute | Securitize | RWA Tokens · CEDEX |
| ----------------------- | ------------------------------------------ | ----------------------------------------------------- |
| Primary Exchange | Securitize Markets ATS (SEC-registered) | CEDEX (proprietary, wholly-owned) |
| Infrastructure Control | External custodians, bridges, DEXs | Complete ownership per Alesia Doctrine |
| Trading Hours | Traditional market hours | 24/7/365 continuous operation |
| Daily Volume | \~$600K/day ATS volume | Continuous via CPMM AMM |
| Asset Classes Served | Institutional equity (single architecture) | Equities · Real Estate · CORECM (single architecture) |
| Liquidity Model | Third-party market makers, external LPs | Global Unified Liquidity Pool · cross-module |
| Liquidity Permanence | Withdrawable by providers at any time | LP tokens burned — mathematically non-withdrawable |
| Trading Disruption Risk | Suspensions during custodian changes | No external dependencies to cause disruption |
| Transparency | Quarterly ATS filings | Real-time on-chain pool verification every \~400ms |
Part IIc — Module-Specific Competitive Landscape
Securitize is the right comparator for Module 1 (institutional equity tokenization), but Modules 2 and 3 operate in different competitive sets. The single-kernel thesis means RWA Tokens does not need to lead in any single category; it needs to be the only platform competitive across all three.
Module 1 — Equities Tokenization Competitive Set
| Competitor | Architecture | Position vs. RWA Tokens Module 1 |
| ---------------------------- | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| Securitize | ERC-3643 middleware on 15+ chains | Institutional-equity leader; cannot economically serve sub-$100M issuers; admin-override architecture; single asset class |
| Tokeny (ERC-3643 stack) | T-REX standard licensor | Standard provider; no exchange or custody infrastructure of its own |
| Ondo Finance | Tokenized Treasuries on Ethereum | Different segment (cash equivalents); no equity issuance pipeline |
| Backed Finance (Switzerland) | EU-regulated tokenized stock wrappers | Wrapped synthetic exposure; not 1:1 share-backed; no US Reg D path |
| Dinari | dShares (NYSE/NASDAQ tokenization) | Large-cap focused; complementary asset coverage; potential partnership target rather than direct competitor |
| INX | FINRA-registered ATS + tokenization platform | Limited issuer pipeline; ERC-3643 derivative architecture |
Module 2 — Real Estate Tokenization Competitive Set
| Competitor | Architecture | Position vs. RWA Tokens Module 2 |
| ---------------------------- | ------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| RealT | ERC-20 wrapper, Gnosis Chain | Retail-focused single-family rental; no SEC-registered transfer agent; no institutional onboarding |
| Lofty.ai | Algorand-native fractional ownership | Single-family rental focus; manual KYC; limited secondary liquidity |
| Securitize Real Estate | ERC-3643 wrapped REIT interests | Institutional REIT-style products; no per-property tokenization |
| RedSwan CRE | Stellar-based commercial real estate tokens | Commercial real estate; pre-issuance broker-dealer dependency; no on-chain appraisal cadence enforcement |
| Tokeny (Real Estate clients) | ERC-3643 deployed by individual issuers | Standard provider; per-property issuer rebuilds compliance from scratch |
Module 2 differentiator: RWA Tokens is the only Real Estate tokenization platform enforcing USPAP appraisal cadence on-chain (90/180/365-day windows by property class) via the Appraisal Oracle. Competitors rely on off-chain appraisal disclosures with no enforcement mechanism — appraisal can become stale without trade halt. The Module 2 architecture treats appraisal currency as a Transfer Hook precondition (Error 6041), not a marketing claim.
Module 3 — CORECM Competitive Set
| Competitor | Architecture | Position vs. RWA Tokens Module 3 |
| ------------------------------------ | --------------------------------------------------- | ---------------------------------------------------------------------------------- |
| Royalty-financing platforms | Off-chain royalty agreements; no tokenization layer | Not on-chain; no continuous secondary market; institutional only |
| Mineral-rights tokenization startups | Various early-stage Ethereum / Polygon deployments | Pre-revenue; no SEC-registered transfer agent; no SPE-PRMS attestation enforcement |
| Energy NFT projects | Memecoin-adjacent energy commodity wrappers | Not security-token compliant; not Reg D / Reg S structured |
| Direct issuer Reg D placements | Traditional offering, no tokenization | No secondary liquidity; manual transfer process |
Module 3 differentiator: RWA Tokens is the only CORECM platform enforcing SPE-PRMS or CRIRSCO-aligned reserve attestation on-chain (90-day cadence), rejecting ineligible reserve classes (only Proved 1P or JORC Measured satisfy Control 1.M3). Module 3 is structurally early-stage in the broader market, but the regulatory architecture (S-K Subpart 1300, USGS Critical Minerals, IRA Section 45X / 30D) is mature enough to support compliant issuance now.
Part IId — Beta Validation Results (Module 1)
Three issuers tokenized Digital Securities through the RWA Tokens platform during the Module 1 beta test:
• $7 million in trading volume within 30 days — immediate institutional and accredited-investor demand for tokenized Digital Securities
• Average daily volume of $200,000 across three issuers — approximately one-third of Securitize's reported $600,000 daily ATS volume from a platform with $4B+ in institutional assets
• All 42 Transfer Hook security controls executed flawlessly — validating SPL Token-2022 Transfer Hook architecture at scale
• Zero custody discrepancy events — Empire-Solana per-block Ed25519 attestation cadence held continuously
Multi-Module Revenue Potential
| Year | M1 Issuers | M2 Properties | M3 Basin-Assets | Total Annual Volume | Protocol Revenue (5%) |
| ------ | ---------- | ------------- | --------------- | ------------------- | --------------------- |
| Year 1 | 50 | 5 | 2 | $200M | $10.0M |
| Year 2 | 200 | 30 | 10 | $850M | $42.5M |
| Year 3 | 500 | 100 | 30 | $2.20B | $110.0M |
| Year 4 | 1,000 | 250 | 75 | $4.60B | $230.0M |
| Year 5 | 2,000 | 500 | 150 | $9.00B | $450.0M |
*All projections are highly speculative and assume the beta-test average daily volume per Module 1 issuer extends to a larger issuer base, with Module 2 and Module 3 ramps following the structural deal-size patterns of commercial real estate tokenization and royalty-rights tokenization respectively. Actual volume varies by issuer market cap, property class, reserve attestation timing, and module-specific market dynamics.*
Part III — Strategic Comparison Matrix
| Dimension | Securitize | RWA Tokens | Advantage |
| ---------------------- | ----------------------------------------------- | ---------------------------------------------------------------------------------------- | ----------------- |
| Token Standard | ERC-3643 on Ethereum | SPL Token-2022 (ST22) on Solana | RWA Tokens |
| Asset-Class Coverage | Institutional equity (single) | Equities + Real Estate + CORECM | RWA Tokens |
| Transaction Cost | $1–$40+ gas fees | \~$0.00025 | RWA Tokens |
| Transaction Speed | \~15 TPS, 12+ second blocks | 65,000+ TPS, \~400ms | RWA Tokens |
| Admin Override | Yes — force transfer, freeze, recover | No — mathematically impossible | RWA Tokens |
| Compliance Enforcement | Application layer — bypassable | Runtime — no bypass path | RWA Tokens |
| Transfer Agent | Securitize Transfer Agent (subsidiary) | Empire Stock Transfer (founder Patrick Mokros = COO) | RWA Tokens |
| Secondary Liquidity | \~$600K/day ATS, market hours only | 24/7 CEDEX + Global Unified Pool (cross-module) | RWA Tokens |
| Liquidity Permanence | Withdrawable by market makers | LP tokens burned — mathematically permanent | RWA Tokens |
| Module-Aware Custody | Not applicable (single asset class) | Module-discriminated Ed25519 attestation per block | RWA Tokens |
| Target Issuer Profile | Institutional ($100K+ setup, $10K–$5M minimums) | Module-dependent ($1K–$25K setup; full institutional and global SME range) | Different markets |
| Regulatory Licenses | Transfer Agent, Broker-Dealer, ATS, EU MiCA | Release No. 33-11412 Category 1 Model B (all modules) · evaluating Reg CF funding portal | Securitize |
| Institutional Partners | BlackRock, Apollo, KKR, Hamilton Lane | Empire Stock Transfer (structural alignment via dual role) | Securitize |
| Valuation | $1.25B SPAC merger | Pre-launch (Q3 2026 mainnet) | Securitize |
| Cross-Asset Strategy | Single architecture per asset class | One compliance kernel · three modules | RWA Tokens |
Part IV — Conclusion
Where Securitize Wins
• First-mover regulatory moat with transfer agent, broker-dealer, ATS, and EU MiCA registrations
• Institutional relationships with BlackRock, Apollo, KKR, and Hamilton Lane — unmatched institutional credibility
• $1.25 billion SPAC valuation validates market acceptance of the institutional-focused approach
• ERC-3643 with $28B+ in tokenized assets establishes the institutional standard on Ethereum
• EU MiCA compatibility — Securitize is licensed in both the United States and the European Union
Where RWA Tokens Wins
• Three-Module Architecture: the only platform serving Equities, Real Estate, and CORECM on a single compliance kernel — competitors must rebuild for each asset class
• Infrastructure Independence: the Alesia Doctrine eliminates third-party failure vectors that cause Securitize trading suspensions
• Mathematical Security: 42 baseline + module-conditional Transfer Hook controls execute inside the Solana runtime — cannot be overridden, cannot enable rugpulls, cannot be bypassed
• Permanent Cross-Module Liquidity: Global Unified CEDEX Liquidity Pool — LP tokens burned — withdrawal mathematically impossible — shared across all three modules
• Module-Aware Custody: Empire signs module-discriminated Ed25519 attestations every Solana block; cross-module attestation forgery rejected at runtime — no competitor has this
• Binding Regulatory Framework: Release No. 33-11412 (March 17, 2026) confirms the architecture under binding federal interpretation, not Staff guidance
• Transaction Economics: \~$0.00025 per transfer vs. $1–$40+ — enables compliance verification on every transfer at any market cap
• Empire Structural Alignment: Empire Stock Transfer's founder (Patrick Mokros) is RWA Tokens' COO — structural alignment, not arms-length partnership
Strategic Positioning
Securitize and RWA Tokens serve different markets with different architectures. Securitize's institutional DNA makes it ideal for BlackRock-style clients who need regulatory comfort and accept centralized control. RWA Tokens' infrastructure independence and three-module compliance kernel make it ideal for the much broader market of asset classes that traditional infrastructure either does not serve or serves only at institutional-tier price points.
The competitive threat is not RWA Tokens taking Securitize's institutional clients. It is RWA Tokens demonstrating that a unified-kernel model exists. When ST22 architecture processes meaningful volume across Equities, Real Estate, and CORECM simultaneously — with zero admin overrides, instant settlement, sub-cent fees, and module-aware custody attestation — the single-asset-class incumbents will appear increasingly architecturally constrained.
The long-term trajectory favors unified-kernel infrastructure. Mathematically-enforced security, runtime-level compliance, cross-asset-class liquidity, and infrastructure independence represent the structural endpoint of tokenized RWA infrastructure. Securitize's middleware-on-Ethereum model and the single-asset-class incumbents in Real Estate and CORECM represent intermediate stations on the path to that endpoint.
Appendix A — Securitize SEC Letter (October 3, 2025)
*Reproduced verbatim for analytical reference. This document was filed by Securitize CEO Carlos Domingo with SEC Chairman Paul S. Atkins on October 3, 2025, and is publicly available at SEC.gov.*
*78 SW 7th Street, Suite 500 · Miami, FL 33130 · October 3, 2025*
Via Electronic Mail — The Honorable Paul S. Atkins, U.S. Securities and Exchange Commission, 100 F Street NE, Washington, D.C. 20549
Re: Securitize's Compliant, Issuer-Sponsored Security Tokenization Model
Dear Chairman Atkins, Securitize appreciates the opportunity to provide a high-level overview of the firm's tokenization model as a contrast to some of the alternative offerings that have recently come to market, specifically as it relates to public equities. Securitize provides highly scalable and compliant tokenization solutions via its regulated subsidiaries that cover issuance, distribution and secondary market trading. The firm has pursued an approach that is innovative, leverages frontier-edge technologies of blockchains and smart contracts, all within a highly compliant model, unlike many other current and potential market entrants. We do not need or seek exemptions with respect to existing securities regulations, although some existing rules need to be modernized to accommodate blockchain solutions. It is our view that some of the 'competing' offerings to our approach represent a regulatory arbitrage and create the potential for an uneven playing field for other compliant ecosystem participants.
I. Tokenization Models
Recent enthusiasm to tokenize public securities has catalyzed a range of offerings that call into question the appropriate form of tokenized assets. Securitize's model is characterized as issuer-sponsored in contrast to some of the other approaches: we do not believe intermediaries should be tokenizing public equity without the issuer's involvement and assent.
A. Issuer-Sponsored.
Securitize Transfer Agent, LLC, an SEC-registered digital transfer agent, works directly with issuers to natively (meaning without intermediary layers) issue or mint a tokenized public equity. The tokenized security is the equivalent of the traditionally issued security. The tokenization process involves converting traditional shares held in book entry form at DTCC to a tokenized form captured on a blockchain-based master security file of the transfer agent. The tokenized security confers the same ownership rights as the traditional security, including voting rights, dividend rights and other corporate actions. Investors are always KYC-verified and their wallets are whitelisted. Whitelisting, coupled with rules-based smart contracts, ensures lawful transfers and AML compliance are always enforced throughout the lifecycle of the asset.
B. Permissionless "Wrapped" Tokens.
SPVs are created to hold the traditional shares, and a token representing an ownership interest in the SPV is issued (a wrapped token) to provide exposure to the stock held in the SPV. This approach introduces additional counterparty risk to the investor as any potential claims would be against the SPV and not the actual issuer of the stock. The wrapped token does not confer any ownership rights equivalent to owning the underlying stock, e.g., voting rights, dividend rights. Other than at the point of purchase or redemption, investors who purchase in the secondary market are not subject to any KYC requirements. After the initial purchase, the wrapped tokens can be freely transferred from wallet to wallet without verifications or sanctions screening.
C. Derivative Securities.
Synthetic products that provide exposure to the underlying stock. This is analogous to a total return swap or security-based swap (SBS) construct and should be deemed to be a security or security-based swap. Exposure is purely economic: the product does not allow redemption for shares or units in the underlying asset and does not offer rights that would attach to a security purchased directly. Investors are exposed to counterparty risk of the token issuer and attendant liquidity pool. If the security is SBS, the full panoply of SBS rules would have to be addressed.
III. Transferability and Token Control: Permissioned vs. Permissionless
Securitize implements smart contracts with rules that govern the transferability of its tokenized securities. Coupled with the KYC verification and whitelisting requirements, this ensures that only eligible and approved investors can engage and transact as smart contracts enforce compliance with suitability, AML and issuer-defined requirements. Moreover, given the smart contract architecture and the existence of an off-chain security master file, any lost, stolen or otherwise impaired tokens can be burned and reissued by the TA (at the direction of the BD or the issuer) such that investors are made whole. These are, therefore, not bearer securities.
IV. Secondary Market Trading
Securitize Markets, LLC is an SEC-registered and FINRA member broker dealer that operates the Securitize Markets ATS and has bilateral relationships with OTC market makers. The firm's ATS provides several options to compliantly trade tokenized securities, including a standard order book and an RFQ option. The firm plans on offering trading in tokenized NMS stocks and will do so within the existing framework of Reg NMS and related regulations for off-chain transactions.
*Sincerely, Carlos Domingo, Chief Executive Officer*
Appendix B — RWA Tokens SEC Crypto Task Force Submission Posture
Overview: Three-Module Digital Securities Infrastructure
RWA Tokens creates SEC-compliant market infrastructure for Digital Securities across three asset-class modules — equities (Module 1), real estate (Module 2), and carbon ore, rare earth and critical minerals (Module 3). The platform addresses asset classes where traditional secondary market infrastructure has historically been fragmented, manual, or inaccessible to the full range of qualified investors.
SEC Category 1 Model B Regulatory Framework
RWA Tokens operates within the SEC's January 28, 2026 Joint Staff Statement on Tokenized Securities and the binding authority of Release No. 33-11412 (March 17, 2026) through full Category 1 (Issuer-Sponsored) compliance across all three modules.
| SEC Category 1 Requirement | RWA Tokens Implementation | Status |
| --------------------------------- | --------------------------------------------------------------------------------------------------------------------- | ------- |
| Direct Issuer Authorization | Board resolution required for module-tagged token creation across all three modules | Binding |
| Transfer Agent Custody | Empire Stock Transfer (SEC §17A registered) maintains custody for all three modules | Binding |
| Digital Securities Classification | All module tokens classified under Release No. 33-11412 | Binding |
| Direct Ownership | Token holders have direct beneficial ownership claims on the underlying backing instrument (Common B / royalty units) | Binding |
| Counterparty Risk Eliminated | No third-party intermediary between holder and underlying instrument across any module | Binding |
| Regulatory Recordkeeping | Rules 17Ad-2 through 17Ad-13 compliance | Binding |
Nine-Layer Platform Architecture · V10.0
| Layer | Component | What It Does |
| ----- | ----------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| L1 | Solana Foundation | 65,000+ TPS, \~$0.00025/tx, \~400ms finality |
| L2 | SPL Token-2022 Transfer Hooks | 42 baseline + module-conditional controls enforced atomically inside the Solana runtime — no bypass path |
| L3 | Global Unified CEDEX Liquidity Pool | Single protocol-owned pool shared across all three modules · LP tokens burned |
| L4 | Custom AMM Engine | Purpose-built CPMM with u128 arithmetic · module-aware pricing |
| L5 | CEDEX | Only trading venue where SPL Token-2022 Transfer Hook compliance is preserved on every trade across all modules |
| L6 | Oracle Network | Custody (all modules) · OFAC · AML · TWAP · Appraisal (M2) · Reserve attestation (M3) · EDGAR (M1) |
| L7 | Protocol Governance | 3-of-5 multi-sig (params) · 5-of-9 multi-sig (upgrades) · 42 controls immutable |
| L8 | Wallet Infrastructure | KYC/AML iOS and Android · Ledger/Trezor support |
| L9 | Predictive AI Module | IDOS scoring across 15,000+ OTC companies · expanding to property and basin-asset opportunity scoring |
Revenue Model — V10 Authoritative
RWA Tokens charges a 5% fee on all Digital Securities transactions across all three modules — applied identically at the primary offering phase (Reg D, Reg S, or Reg CF) and on all secondary market trading on CEDEX.
| Fee Component | Rate | Mechanism |
| ----------------------------------- | ----- | --------------------------------------------------------------------------------------------------------------------- |
| Global Unified CEDEX Liquidity Pool | 0.44% | Permanently locked by immutable Transfer Hook on every transaction across all modules — not withdrawable by any party |
| RWA Tokens platform revenue | 4.56% | Funds infrastructure, compliance, development, and staking reward distributions |
| Issuer secondary fee share | None | Issuers receive 95% of primary raise proceeds only — no ongoing secondary trading share |
Key Policy Recommendations
• Confirm that SEC-registered transfer agents satisfy the regulated custody requirement for Category 1 Digital Securities tokenization across asset classes (equities, real estate, mineral rights)
• Recognize that smart contract-based compliance controls (Transfer Hooks executing inside the Solana runtime) provide investor protection equal to or superior to traditional market mechanisms
• Clarify that public, permissionless blockchains such as Solana may be used for Category 1 Digital Securities when paired with SEC-registered transfer agent custody and 1:1 verifiable backing
• Affirm that module-aware tokenization (Equities, Real Estate, CORECM) operating under unified compliance infrastructure does not create regulatory arbitrage when each module is independently aligned with applicable asset-class disclosure rules (S-K Subpart 1300 for mineral rights; USPAP for real estate appraisal)
• Provide guidance on the use of automated market makers for Category 1 Digital Securities, recognizing their potential to provide continuous liquidity without traditional market maker dependency
*Respectfully submitted, Frank Yglesias, Chairman & Chief Technology Officer, Groovy Company, Inc.*
Confidentiality Notice and Disclaimer
This document is confidential and prepared for internal strategic use only. Distribution limited to authorized personnel. The competitive analysis is based on publicly available information and internal analysis as of May 2026. ST22 Digital Securities are classified under Release No. 33-11412. This document does not constitute an offer to sell or solicitation of an offer to buy any securities. Groovy Company, Inc. is a Wyoming Corporation (CIK: 1499275; OTC: GROO).
# SEC Tokenized Guidance
Strategic Compliance Memo · Three-Module Architecture
Release No. 33-11412 (March 17, 2026) · Joint Staff Statement (January 28, 2026) · Subsequent Authority
Groovy Company, Inc. · Version 10.0 · May 2026
Executive Summary
Release No. 33-11412 (March 17, 2026), jointly issued by the U.S. Securities and Exchange Commission and the U.S. Commodity Futures Trading Commission, is the most legally significant federal guidance on digital asset classification in U.S. regulatory history. Unlike the January 28, 2026 Joint Staff Statement on Tokenized Securities (which carried Staff-level persuasive weight), Release No. 33-11412 is a Final Rule and Interpretation carrying the full legal weight of an official SEC and CFTC interpretation under the Securities Act of 1933 and the Securities Exchange Act of 1934.
The release is highly favorable for RWA Tokens' three-module architecture. Digital Securities issued through Module 1 (Equities), Module 2 (Real Estate), and Module 3 (CORECM) all map cleanly to Category 5 — the only category under SEC jurisdiction. The GROO utility/governance token is classified outside Category 5 entirely. The Category 1 Model B architecture, originally designed for the equity-tokenization use case, applies identically to all three modules and is now backed by binding interpretive authority rather than Staff guidance.
Strategic conclusion: Release No. 33-11412 confirms that the unified-kernel compliance architecture is the correct structure for tokenized real-world assets across asset classes. Each of the three modules sits in the same regulatory home (Category 5 Digital Securities), under the same custodian (Empire Stock Transfer), with the same Transfer Hook controls — and the GROO utility token sits cleanly outside SEC jurisdiction.
Key Findings
| Finding | Impact |
| -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| Module 1, 2, and 3 tokens all classify as Category 5 Digital Securities under Release No. 33-11412 | Confirms unified-kernel architecture across all three modules |
| Category 1 Model B architecture is now backed by binding interpretive authority | Stronger legal footing for all RWA Tokens compliance positions |
| GROO utility token classifies outside Category 5 — Category 1 (Digital Commodity) or Category 3 (Digital Tool) | GROO is not a security; offering structure for the Groovy Security Token (STO) is structurally separate |
| The five-category taxonomy provides a complete federal classification map | Eliminates ambiguity about how the platform's various tokens are classified |
| Nasdaq tokenization approval (Release No. 34-105047) does not extend to CEDEX | CEDEX trading venue path remains on its own track |
| Innovation exemption rulemaking from the SEC is favorable to platforms with mathematically-enforced safeguards | RWA Tokens 42-control Transfer Hook architecture exceeds sandbox safeguard threshold |
Part 1 — The SEC–CFTC Regulatory Framework
Definition of Digital Securities
Per the January 28, 2026 Joint Staff Statement, retained verbatim in Release No. 33-11412:
*"A tokenized security is a financial instrument enumerated in the definition of 'security' under the federal securities laws that is formatted as or represented by a crypto asset, where the record of ownership is maintained in whole or in part on or through one or more crypto networks."*
Fundamental Regulatory Principle — Now Binding
*"The format in which a security is issued or the methods by which holders are recorded (on-chain vs. off-chain) does not affect application of the federal securities laws."*
This technology-neutral principle is binding interpretive authority under Release No. 33-11412 — not Staff guidance. It is the foundational doctrine supporting the Category 1 Model B architecture used across all three RWA Tokens modules: Empire Stock Transfer maintains the authoritative master securityholder file off-chain, while Solana serves as the operational notification layer.
The Five-Category Taxonomy
Release No. 33-11412 establishes five formal categories of crypto assets under U.S. federal law:
| Category | Name | Securities? | RWA Tokens Relevance |
| -------- | -------------------- | ---------------------- | ---------------------------------------------------------------------------------------------------- |
| 1 | Digital Commodities | No — CFTC jurisdiction | GROO utility/governance token may qualify |
| 2 | Digital Collectibles | No | Not applicable to current RWA Tokens products |
| 3 | Digital Tools | No | GROO utility token may alternatively qualify (protocol access credential) |
| 4 | Payment Stablecoins | No — GENIUS Act | Confirms USDC and PYUSD settlement of Digital Securities trades is not a securities transaction |
| 5 | Digital Securities | Yes — SEC jurisdiction | All three RWA Tokens modules — Equities, Real Estate, CORECM — produce Category 5 Digital Securities |
Category 5 Digital Securities — The Three-Module Home
All Digital Securities issued through the RWA Tokens platform are unambiguously Category 5. The backing instrument differs by module but the regulatory classification is identical:
| Module | Backing Instrument | Category 5 Basis |
| -------------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| Module 1 — Equities (ST22) | 1:1 issuer Common Class B shares (Empire custody) | Common stock is a security under Securities Act §2(a)(1) |
| Module 2 — Real Estate | Common Class B shares in property-holding Nevada corporation (Empire custody) | Common stock of an investment-purpose corporation is a security under §2(a)(1) and supplemental SEC guidance on real-estate-holding corporations |
| Module 3 — CORECM | Operator Common Class B shares or royalty assignment units (Empire custody) | Royalty interests in mineral production are investment contracts and / or fractional undivided interests under §2(a)(1) |
*SEC Chair Paul Atkins, March 17, 2026 DC Blockchain Summit: "This distinction returns the Commission to its core mission — and statutory authority — of protecting investors involved in securities transactions. We are not the Securities and Everything Commission, anymore."*
Investment Contract Termination Framework
Release No. 33-11412 introduces a concept absent from the January 28, 2026 Joint Staff Statement: investment contract status can terminate. A non-security crypto asset that was initially distributed under an investment contract ceases to be subject to that investment contract when (1) the issuer fulfills its representations and promises (e.g., the protocol becomes functional), or (2) the issuer demonstrably fails to fulfill those representations.
Application to RWA Tokens: directly applicable to the GROO utility/governance token. The Company should document the specific point at which the Solana program suite became functional (CEDEX mainnet launch, Q3 2026) and that any investment contract obligations attached to GROO at distribution are extinguished as of that operational milestone. This eliminates ongoing securities obligations for the GROO utility token and is independent of the Category 5 Digital Securities obligations applicable to the three module products.
SEC–CFTC Joint Harmonization Initiative
On March 11, 2026, the SEC and CFTC signed a Memorandum of Understanding establishing a Joint Harmonization Initiative co-led by Robert Teply (SEC) and Meghan Tente (CFTC). This initiative coordinates oversight across policymaking, examination, and enforcement, and is intended to reduce frictions for dually regulated entities. RWA Tokens should monitor this initiative for implications affecting the GROO utility token (Category 1 / CFTC jurisdiction) and CEDEX trading venue analysis (Category 5 / SEC jurisdiction).
Part 2 — RWA Tokens Compliance Status
The following compliance positions apply uniformly across all three modules and are backed by binding interpretive authority under Release No. 33-11412.
Core Architecture Compliance Status
| SEC Requirement | RWA Tokens Implementation | Authority |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ---------------------- |
| Issuer authorization | Board resolution required for any module-tagged token minting | Binding interpretation |
| Shareholder register integration | Empire Stock Transfer master file (authoritative for all three modules) | Binding interpretation |
| SEC-registered custody | Empire Stock Transfer (Exchange Act §17A registered) | Binding interpretation |
| True equity / asset backing | 1:1 backing — Common Class B (Modules 1, 2) or operator Common B / royalty units (Module 3) — irrevocable Empire custody | Binding interpretation |
| Token standard | SPL Token-2022 with 42 baseline + module-conditional Transfer Hook controls | Binding interpretation |
| Digital Securities classification | All module tokens classified as Category 5 Digital Securities | Binding interpretation |
| Category 1 Model B architecture | Solana as notification layer; Empire as authoritative master file (all modules) | Binding interpretation |
| CUSIP assignment | Common Class B shares receive official CUSIP at issuance | Binding interpretation |
| Protective conversion triggers | Auto-conversion on specified adverse events (see below) | Binding interpretation |
| Tripartite legal structure | Issuer + Groovy Company, Inc. + Empire Stock Transfer agreement | Binding interpretation |
Protective Conversion Triggers
The protective conversion triggers built into the Common Class B backing instrument across all three modules directly address the counterparty and bankruptcy risk concerns Release No. 33-11412 flags for Category 2 (third-party-mediated) tokenization models. Conversion triggers are not policy — they are share-class terms embedded in the issuer's Certificate of Designation.
| Trigger Event | Investor Protection |
| ----------------------------------------------------- | ---------------------------------------------------------------------- |
| Issuer bankruptcy filing (any chapter) | Auto-conversion of backing Common Class B to common stock |
| SEC enforcement action against the issuer | Auto-conversion to common stock |
| Criminal indictment or conviction of issuer officers | Auto-conversion to common stock |
| Loss of Empire Stock Transfer custody services | Auto-conversion to common stock |
| Material breach of token holder rights by issuer | Auto-conversion to common stock |
| Sustained appraisal cadence failure (Module 2 only) | Auto-conversion to common stock in property-holding Nevada corporation |
| Sustained reserve attestation failure (Module 3 only) | Auto-conversion to common stock in operator entity |
Part 3 — Open Compliance Workstreams
The following workstreams remain open as of May 2026. Each is identified by category, scope, and current status.
1\. GROO Utility Token Formal Classification
Priority: MEDIUM
Release No. 33-11412 establishes the regulatory framework, but formal classification of the GROO utility/governance token under the five-category taxonomy requires legal counsel review. Two viable classifications exist:
• Category 1 — Digital Commodity: if GROO operates as a network-native asset whose value derives from protocol operation. CFTC jurisdiction.
• Category 3 — Digital Tool: if GROO functions as a governance credential and protocol access tool. Outside both SEC and CFTC jurisdiction.
The investment contract termination framework introduced by Release No. 33-11412 may also apply, extinguishing any residual securities obligations attached to GROO at initial distribution once the protocol is functional (CEDEX mainnet launch, Q3 2026).
Required actions:
• Engage securities counsel to formally classify GROO under the five-category taxonomy
• Document investment contract termination analysis tied to CEDEX mainnet launch
• Update GROO disclosures to reflect the distinction between GROO (Category 1 or 3) and Module 1/2/3 Digital Securities (Category 5)
2\. CEDEX Trading Venue Status
Priority: HIGH
The Nasdaq tokenization approval (Release No. 34-105047, March 18, 2026) applies exclusively to DTC Eligible Securities — securities with functioning clearing and settlement infrastructure within the Depository Trust Company. By definition, this framework does not extend to:
• Module 1 OTC microcap issuers without DTC eligibility
• Module 2 property-holding Nevada corporations (privately-held by definition)
• Module 3 operator entities and royalty units (private securities)
CEDEX therefore remains on its own regulatory path. The consolidated no-action letter requesting Staff confirmation that CEDEX does not require ATS registration is the principal pending workstream.
| Option | Description | Current Status |
| ----------------------------------- | -------------------------------------------------------------------------------------- | -------------------------------------------- |
| Consolidated No-Action Letter | Filed with SEC Division of Trading and Markets — requests CEDEX operating confirmation | Pending Staff response |
| ATS Registration | Register CEDEX as an Alternative Trading System under Reg ATS | Evaluate based on no-action response |
| Innovation Exemption | Apply for SEC innovation exemption sandbox upon rulemaking publication | See workstream 4 below |
| Reg D / Reg S / Reg CF Distribution | Maintain offering exemption distribution while CEDEX status is resolved | Currently operative across all three modules |
3\. Module-Specific Issuer Disclosure Standards
Priority: MEDIUM
Release No. 33-11412 does not change disclosure obligations for Digital Securities issuers. Tokenized securities require the same disclosures as traditional securities. The three-module architecture requires module-differentiated disclosure standards because each module's underlying asset class triggers different regulatory disclosure regimes:
| Module | Disclosure Regime | Required Action |
| ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| Module 1 — Equities (SEC-reporting) | Existing 10-K / 10-Q / 8-K filings + token offering disclosure | Token offering documents reference existing periodic filings |
| Module 1 — Equities (non-reporting) | Standardized disclosure package — material business information, risk factors, financials, management, use of proceeds | Standardized package in development |
| Module 2 — Real Estate | Property-specific disclosures + USPAP appraisal report + Nevada corporation governance documents | USPAP appraiser engagement protocol; appraisal cadence enforced on-chain (90/180/365 days by property class) |
| Module 3 — CORECM | S-K Subpart 1300 reserve disclosures + SPE-PRMS or CRIRSCO-aligned reserve report + operator entity disclosures | Qualified petroleum / mining engineer engagement protocol; reserve attestation cadence enforced on-chain (90 days) |
4\. Innovation Exemption Rulemaking
Priority: MEDIUM — Strategic Opportunity
Release No. 33-11412 was explicitly described by SEC Chair Atkins as "a first step rather than a final answer." The innovation exemption rulemaking would allow companies to test novel business models under principles-based safeguards rather than full compliance with existing rules.
Why RWA Tokens Is a Strong Candidate
• Mathematically-enforced safeguards: the 42 baseline + module-conditional Transfer Hook controls execute atomically inside the Solana runtime on every transaction across all three modules — exceeding the safeguard threshold any innovation exemption sandbox would require
• Investor participation limits already satisfied: all Digital Securities offerings are limited to verified investors under Reg D (US accredited), Reg S (non-US), and Reg CF (US retail with per-investor SEC limits)
• Non-custodial CEDEX architecture: Groovy Company, Inc. holds no user funds — Empire Stock Transfer holds all backing instruments; the Global Unified CEDEX Liquidity Pool is protocol-owned with LP tokens burned at initialization
• Real-time regulator visibility: on-chain settlement provides regulators with real-time, immutable transaction visibility superior to the periodic reporting obligations sandbox participants would otherwise need to satisfy
• Cross-module application: any innovation exemption granted to RWA Tokens applies uniformly across all three modules — the unified compliance kernel design is itself an argument for sandbox eligibility
Required actions:
• Monitor SEC rulemaking publication
• Engage securities counsel to evaluate eligibility upon rule publication
• Prepare innovation exemption application in parallel with no-action letter response process
• Position the 42-control Transfer Hook architecture as the operational model for principles-based safeguards
5\. Documentation Updates
Priority: HIGH (regulatory documents) · MEDIUM (marketing materials)
| Document | Required Update | Status |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------ | ------------------- |
| Whitepaper | Five-category taxonomy citation; Release No. 33-11412 throughout; three-module Category 5 framing | Complete (V8 → V10) |
| Lightpaper | Three-module architecture; Common Class B backing; rwatokens.net contact | Complete (V10) |
| Mutual NDA | Wyoming governing law; Atlanta address; three-module Purpose checkboxes | Complete (V10) |
| Competitive Analysis | Module-specific competitor mapping; Securitize ERC-3643 vs ST22 framework | Complete (V10) |
| Issuer Agreements | Module-specific terms; Category 5 Digital Securities classification acknowledgment; Release No. 33-11412 reference | In progress |
| Risk Disclosures | Module-specific risk factors; five-category taxonomy framing | In progress |
| Marketing Materials | Category 5 Digital Securities messaging; remove any obsolete classification language | In progress |
| Technical Specifications | SPL Token-2022 Transfer Hook documentation reflects Release No. 33-11412 Digital Securities requirements | Complete |
Part 4 — Competitive Position Under Release No. 33-11412
The five-category taxonomy strengthens RWA Tokens' competitive position by drawing sharp regulatory lines around competing models that the binding release flags as non-compliant or jurisdictionally incorrect.
Disfavored Models Under the Binding Release
• Synthetic equity products without issuer authorization: Category 2-style products including third-party tokenized stock wrappers are explicitly characterized as security-based swaps that cannot trade off-exchange to retail investors
• Custodial receipt models (ADR-type tokens without direct issuer involvement): investors face counterparty risk, bankruptcy risk, and no direct issuer relationship — all conditions the SEC's taxonomy is designed to flag
• Unclassified tokens claiming non-security status: tokens that do not clearly fit one of the five categories are presumptively investment contracts under Howey
RWA Tokens Position
| Advantage | Basis |
| -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| Regulatory Moat | All three modules align with binding Release No. 33-11412, not Staff guidance |
| Cross-Module Compliance Map | The same five-category taxonomy classifies Module 1 / 2 / 3 tokens (Category 5) and the GROO utility token (Category 1 or 3) cleanly |
| Risk Mitigation | Protective conversion triggers across all three modules specifically address risks flagged in Release No. 33-11412 |
| Institutional Appeal | The taxonomy gives institutional investors a clear compliance map for evaluating each of the three modules |
| Joint Regulatory Clarity | SEC–CFTC harmonization means the GROO utility token has a clean Category 1 (CFTC) or Category 3 (no agency) home — no jurisdictional ambiguity |
| Innovation Exemption Eligibility | 42 Transfer Hook controls + module-conditional logic + non-custodial architecture = best-in-class safeguards across asset classes |
Strategic Messaging Under Release No. 33-11412
| Message | Authority |
| ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------ |
| RWA Tokens Digital Securities are Category 5 under binding Release No. 33-11412 — the only category under SEC jurisdiction | Federal interpretive release |
| The GROO utility/governance token is classified outside SEC jurisdiction — Category 1 (CFTC) or Category 3 (no agency oversight) | Pending counsel-formalized classification |
| The Category 1 Model B architecture applies uniformly to all three asset-class modules — Equities, Real Estate, CORECM | Application of binding architecture to multi-module platform |
| RWA Tokens aligns with binding Release No. 33-11412 — the only comprehensive federal crypto asset classification with full legal authority | Release No. 33-11412 |
Part 5 — Priority Action Plan (May 2026)
The following actions reflect the current open work as of May 2026. Each is ranked by priority, with complexity and timeline estimates.
| Priority | # | Action Item | Complexity | Status |
| -------- | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | ----------- |
| HIGH | 1 | CEDEX no-action letter — pursue Staff response and pre-filing call with Division of Trading and Markets | Medium | Active |
| HIGH | 2 | Module-specific issuer agreements — finalize Module 2 (Real Estate) and Module 3 (CORECM) issuer agreement templates with Category 5 Digital Securities classification language | Medium | In progress |
| HIGH | 3 | Module-specific risk disclosures — finalize Module 2 (USPAP appraisal risk) and Module 3 (SPE-PRMS reserve revision risk) disclosure standards | Medium | In progress |
| MEDIUM | 4 | GROO utility token formal classification under five-category taxonomy — engage securities counsel | Medium | Open |
| MEDIUM | 5 | Innovation exemption rulemaking — monitor publication; prepare RWA Tokens application materials in parallel with no-action process | High | Open |
| MEDIUM | 6 | GROO investment contract termination analysis tied to CEDEX mainnet launch (Q3 2026) | Medium | Open |
| MEDIUM | 7 | Standardized issuer disclosure package — non-reporting issuers across all three modules | Medium | Open |
| LOW | 8 | Empire Stock Transfer blockchain integration documentation — formalize reconciliation procedures between on-chain and off-chain records | Low | Open |
| LOW | 9 | SEC–CFTC Joint Harmonization Initiative — monitor for implications affecting GROO classification and CEDEX jurisdictional analysis | Low | Ongoing |
Conclusion
Release No. 33-11412 is the most consequential federal regulatory development for RWA Tokens since the platform's architectural design phase. The five-category taxonomy resolves the platform's classification map cleanly: all three modules produce Category 5 Digital Securities under SEC jurisdiction; the GROO utility/governance token sits in Category 1 (CFTC) or Category 3 (no agency oversight) outside SEC jurisdiction.
The binding nature of Release No. 33-11412 upgrades the entire RWA Tokens compliance position from "aligned with Staff guidance" to "aligned with binding federal interpretation" — a meaningful difference when speaking with institutional investors, issuers, and regulators across all three modules.
Three Strategic Questions Remain Open
• CEDEX trading venue status: awaiting consolidated no-action letter response and innovation exemption rulemaking publication
• GROO utility token formal classification: requires counsel engagement under the five-category framework, with investment contract termination analysis tied to CEDEX mainnet launch
• Innovation exemption eligibility: RWA Tokens should position proactively for sandbox consideration upon rule publication
On all three open questions, the existing architecture — 42 baseline + module-conditional Transfer Hook controls, Empire Stock Transfer Category 1 Model B custody across all three modules, permanently locked Global Unified CEDEX Liquidity Pool, non-custodial CEDEX exchange — represents the strongest possible starting position.
Compliance Summary
| Binding Release Alignment | In Progress | Adjustments Needed |
| ---------------------------------------------------------------- | --------------------------------------------------------------- | ---------------------------------------- |
| Category 5 Digital Securities classification (all three modules) | CEDEX no-action letter response | GROO utility token formal classification |
| Category 1 Model B architecture (all three modules) | Innovation exemption monitoring | Trading venue path resolution |
| SEC-registered transfer agent custody (Empire Stock Transfer) | Module-specific issuer disclosure standardization | Broker-dealer determination (per-module) |
| 1:1 Common Class B backing (all three modules) | Module 2 USPAP and Module 3 SPE-PRMS attestor network expansion | |
| CUSIP assignment | Issuer agreement templates (Module 2, Module 3) | |
| Protective conversion triggers (all three modules) | | |
| Tripartite legal structure | | |
| 42 Transfer Hook compliance controls + module-conditional logic | | |
| Reg D / Reg S / Reg CF offering structure | | |
| GENIUS Act stablecoin settlement (USDC / PYUSD) | | |
| Non-custodial CEDEX architecture | | |
Key Regulatory References
| Document | Date | Legal Weight |
| --------------------------------------------------------------------------------------------------------------- | ------------------- | ----------------------------------------------------------------- |
| Release Nos. 33-11412; 34-105020 — SEC–CFTC Joint Interpretive Release on Crypto Asset Classification | March 17, 2026 | Binding — Final Rule and Interpretation |
| Release No. 34-105047 — SEC Approval of Nasdaq Tokenized Securities Rule | March 18, 2026 | Binding — Exchange rule approval |
| Joint Staff Statement on Tokenized Securities — Division of Corp. Fin., Div. Inv. Mgmt., Div. Trading & Markets | January 28, 2026 | Persuasive — substantially incorporated into Release No. 33-11412 |
| SEC Staff Statement on Covered User Interface Providers | April 13, 2026 | Staff guidance — relevant to CEDEX user-interface analysis |
| SEC–CFTC Memorandum of Understanding — Joint Harmonization Initiative | March 11, 2026 | Operative agreement |
| Innovation Exemption Rulemaking | Pending publication | Forthcoming |
Disclaimer
This memo is prepared for internal strategic and investor relations use only and does not constitute legal or investment advice. Market participants should consult qualified securities counsel regarding specific compliance requirements. Statements regarding the GROO utility / governance token classification are preliminary and subject to formal counsel determination under the five-category taxonomy. Statements regarding CEDEX trading venue status are subject to the pending consolidated no-action letter response and any forthcoming innovation exemption rulemaking. Groovy Company, Inc. is a Wyoming Corporation (CIK: 1499275; OTC: GROO).
© 2026 Groovy Company, Inc. · All Rights Reserved · Version 10.0 · May 2026 · Internal / Investor Relations
# Mutual Non-Disclosure Agreement
{% file src="/files/UJ0CXzjb7hU2i2s8GAQd" %}
Between Groovy Company, Inc. and ______________________________________
| Document Type | Mutual Non-Disclosure Agreement |
| -------------- | ---------------------------------- |
| Version | V10.0 |
| Effective Date | \_\_\_\_\_\_\_\_\_\_\_\_\_\_, 2026 |
| Prepared By | Groovy Company, Inc. |
| Governing Law | State of Wyoming |
| Classification | CONFIDENTIAL |
1\. PARTIES
This Mutual Non-Disclosure Agreement (the “Agreement”) is entered into on the Effective Date set forth above between:
Groovy Company, Inc. — a Wyoming corporation, principal office located at 600 W Peachtree St NW, Suite 1700, Atlanta, GA 30308 (“RWA Tokens”).
AND
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ (“Counterparty”), with principal address at \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_.
Each party may be referred to individually as a “Party” and collectively as the “Parties.”
2\. PURPOSE
The Parties wish to explore potential business opportunities, partnerships, collaborations, or other commercial relationships (the “Purpose”) relating to one or more of the following (check all that apply):
Module-Specific Tokenization Engagements
☐ Module 1 — Equities: Tokenization of equity securities (OTC microcap, NASDAQ, AMEX, TSX, or other global exchange-listed issuer)
☐ Module 2 — Real Estate: Tokenization of commercial or investment-grade real property via property-holding Nevada corporation
☐ Module 3 — CORECM: Tokenization of carbon ore, rare earth, or critical minerals revenue interests (basin-asset)
Platform & Commercial Engagements
☐ Technology Partnership — Solana-native blockchain integration, ST22 Digital Securities, or CEDEX exchange interoperability
☐ Investment Opportunity — Potential investment in Groovy Company, Inc. or the Groovy Security Token (STO)
☐ Strategic Alliance — Business development, market expansion, or cross-border issuer / investor distribution
☐ Service Provider Agreement — Professional services, custody integration (via Empire Stock Transfer), or platform integration
☐ Joint Venture — Collaborative business development across one or more modules
☐ Employment / Consulting — Potential employment or consulting engagement
☐ Regulatory / Legal Coordination — SEC Crypto Task Force engagement, Reg D / Reg S / Reg CF structuring, or no-action letter coordination
☐ Other: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
In connection with the Purpose, each Party may disclose certain confidential and proprietary information to the other Party. This Agreement sets forth the terms and conditions governing such disclosure and use of confidential information.
3\. DEFINITION OF CONFIDENTIAL INFORMATION
3.1 General Definition
“Confidential Information” means any and all non-public, proprietary, or confidential information, knowledge, data, or know-how disclosed by one Party (the “Disclosing Party”) to the other Party (the “Receiving Party”), whether orally, in writing, electronically, visually, or in any other form, including but not limited to the categories described in Sections 3.2 through 3.5.
3.2 Technical Information
• Blockchain Technology: smart contract code, nine-layer platform architecture, SPL Token-2022 Transfer Hook specifications, oracle systems, and module-aware blockchain integration methodologies
• Platform Technology: software source code, algorithms, APIs, system architecture, and technical specifications for CEDEX, the Custom AMM Engine, the Global Unified CEDEX Liquidity Pool, and the wallet infrastructure
• Cryptographic Methods: private keys, security protocols, encryption methods, Ed25519 signature verification systems, and authentication systems
• Database & Analytics: user data structures, IDOS scoring models, analytics algorithms, and data processing methodologies
• Module-Specific Technical Data: appraisal oracle attestations (Module 2), reserve attestation methodologies (Module 3), and module-discriminator architecture
3.3 Business Information
• Financial Data: financial statements, revenue models, pricing strategies, cost structures, and investment information
• Business Plans: strategic plans, market analysis, business models, growth projections, and expansion strategies across the three modules
• Customer & Counterparty Information: issuer data, investor data, trading patterns, demographic information, and customer acquisition strategies
• Marketing Intelligence: marketing strategies, promotional plans, partnership agreements, and competitive analysis
3.4 Proprietary Information
• Intellectual Property: trade secrets, know-how, inventions, discoveries, patents, patent applications, and proprietary processes
• ST22 Tokenomics & Digital Securities Economics: token distribution models, CPMM algorithms, liquidity pool strategies, fee structures, and economic incentive structures across all three modules
• Platform Operations: operational procedures, compliance protocols, risk management systems, and internal controls
• Legal & Regulatory: legal strategies, regulatory compliance methods, SEC filings, licensing agreements, and regulatory correspondence including SEC Crypto Task Force engagement materials and no-action letter drafts
3.5 Additional Categories
• Personnel Information: employee information, organizational structure, compensation data, and hiring strategies
• Third-Party Information: information received from third parties under confidentiality obligations, including Empire Stock Transfer operational data and qualified-attestor credentials (USPAP appraisers, SPE / SME engineers)
• Future Plans: product roadmaps, feature development plans, technology evolution strategies, cross-chain expansion plans, and module activation schedules
• Analysis & Insights: reports, analyses, evaluations, and insights derived from Confidential Information
3.6 Form of Information
Confidential Information includes information disclosed:
• Orally in meetings, presentations, or conversations
• In Writing through documents, emails, or written communications
• Electronically via digital files, databases, or electronic media
• Visually through demonstrations, prototypes, or visual presentations
• Any Other Form of communication or disclosure
4\. MARKING AND IDENTIFICATION
4.1 Written Information
Written Confidential Information should be clearly marked with one of the following designations:
• “CONFIDENTIAL”
• “PROPRIETARY”
• “RWA TOKENS CONFIDENTIAL”
• “GROOVY COMPANY CONFIDENTIAL”
• “TRADE SECRET”
• Any other similar marking indicating confidential nature
4.2 Oral Information
Information disclosed orally or visually shall be considered Confidential Information if:
• The Disclosing Party identifies it as confidential at the time of disclosure, OR
• The circumstances surrounding the disclosure would reasonably indicate its confidential nature, OR
• The Disclosing Party confirms in writing within thirty (30) days that such information is confidential
4.3 Unmarked Information
Failure to mark information as confidential shall not automatically exclude it from protection under this Agreement if the information would otherwise qualify as Confidential Information under the definitions herein.
5\. OBLIGATIONS OF RECEIVING PARTY
5.1 Non-Disclosure Obligations
The Receiving Party agrees to:
• Maintain Strict Confidentiality: keep all Confidential Information in strict confidence and not disclose it to any third party without the Disclosing Party’s prior written consent
• Use Reasonable Care: exercise at least the same degree of care in protecting Confidential Information as it uses for its own confidential information, but in no event less than reasonable care
• Limit Access: restrict access to Confidential Information to employees, agents, advisors, and representatives who have a legitimate need to know for the Purpose
• Bind Recipients: ensure that all persons with access to Confidential Information are bound by confidentiality obligations at least as restrictive as those contained herein
5.2 Use Restrictions
The Receiving Party shall:
• Use Only for Purpose: use Confidential Information solely for the Purpose and not for any other purpose
• No Reverse Engineering: not reverse engineer, disassemble, decompile, or otherwise attempt to derive the source code or underlying ideas from any Confidential Information, including any Solana program bytecode, Transfer Hook logic, or oracle attestation payloads
• No Competitive Use: not use Confidential Information to compete with the Disclosing Party or to develop competing products or services in any of the three asset-class modules (Equities, Real Estate, CORECM)
• No Unauthorized Copying: not copy, reproduce, or create derivative works from Confidential Information except as necessary for the Purpose
5.3 Security Measures
The Receiving Party shall implement appropriate security measures including:
• Physical Security: secure storage of physical documents and materials
• Digital Security: password protection, encryption (industry-standard at rest and in transit), and secure networks for electronic information
• Access Controls: role-based access controls, multi-factor authentication, and audit logging
• Monitoring: regular monitoring and auditing of access to Confidential Information
6\. EXCEPTIONS TO CONFIDENTIALITY
The obligations set forth in Section 5 shall not apply to information that:
6.1 Public Information
Is or becomes publicly available through no breach of this Agreement by the Receiving Party.
6.2 Independent Development
Is independently developed by the Receiving Party without use of or reference to the Disclosing Party’s Confidential Information, as evidenced by contemporaneous written records.
6.3 Third-Party Disclosure
Is rightfully received by the Receiving Party from a third party without breach of any confidentiality obligation owed to the Disclosing Party.
6.4 Prior Knowledge
Was known to the Receiving Party prior to disclosure by the Disclosing Party, as evidenced by contemporaneous written records.
6.5 Legal Requirements
Is required to be disclosed by law, regulation, court order, or government agency, provided that:
• The Receiving Party gives prompt written notice to the Disclosing Party of such requirement (to the extent permitted by law)
• The Receiving Party cooperates with the Disclosing Party in seeking a protective order or other appropriate remedy
• The disclosure is limited to only that information required to be disclosed
7\. PERMITTED DISCLOSURES
7.1 Internal Team Members
The Receiving Party may disclose Confidential Information to:
• Employees who have a need to know for the Purpose and are bound by employment agreements containing confidentiality provisions
• Legal Counsel bound by attorney-client privilege and professional confidentiality obligations
• Financial Advisors bound by professional confidentiality obligations and who have signed confidentiality agreements at least as restrictive as this Agreement
• Consultants and Contractors who have signed confidentiality agreements at least as restrictive as this Agreement
7.2 Due Diligence Activities
In connection with potential investment, acquisition, financing, or module-onboarding transactions, Confidential Information may be disclosed to:
• Potential Investors who have signed confidentiality agreements
• Investment Banks bound by professional confidentiality obligations
• Accounting and Audit Firms conducting due diligence under confidentiality agreements
• Qualified Attestors (Module 2 / Module 3) such as USPAP-licensed appraisers and SPE / SME credentialed petroleum or mining engineers, where their engagement requires access to specific Confidential Information
• Other Professional Advisors bound by appropriate confidentiality obligations
8\. TERM AND TERMINATION
8.1 Term
This Agreement shall commence on the Effective Date and shall remain in effect for a period of five (5) years, unless terminated earlier in accordance with this Section.
8.2 Termination
Either Party may terminate this Agreement at any time by providing thirty (30) days’ written notice to the other Party.
8.3 Survival of Obligations
Upon termination of this Agreement:
• All confidentiality obligations shall survive for a period of seven (7) years from the date of termination
• The obligation to return or destroy Confidential Information shall survive indefinitely
• All other provisions necessary to give effect to the confidentiality obligations shall survive
• Trade secrets shall remain protected for so long as they qualify as trade secrets under applicable law
9\. RETURN OR DESTRUCTION OF INFORMATION
9.1 Upon Termination
Upon termination of this Agreement, or upon written request by the Disclosing Party, the Receiving Party shall, at the Disclosing Party’s option:
• Return all documents, materials, and other tangible manifestations of Confidential Information; OR
• Destroy all such materials and provide written certification of such destruction within thirty (30) days
9.2 Electronic Information
With respect to electronic Confidential Information, the Receiving Party shall:
• Delete all electronic files containing Confidential Information from all computer systems and storage devices
• Overwrite storage media to prevent recovery of deleted information where feasible
• Destroy any backup copies that cannot be easily deleted, or place such copies under continuing confidentiality controls
• Provide certification of complete deletion and destruction signed by an officer of the Receiving Party
9.3 Exceptions to Return / Destruction
The Receiving Party may retain:
• Legal Compliance Copies required to be retained by law or regulation
• Attorney Work Product prepared by legal counsel
• Archived Copies that exist solely in secure backup systems and cannot be easily retrieved
Such retained copies shall remain subject to the confidentiality obligations of this Agreement for so long as they exist.
10\. INTELLECTUAL PROPERTY
10.1 No License Granted
Nothing in this Agreement grants any license, right, or interest in any patent, copyright, trademark, trade secret, or other intellectual property right of either Party. All rights are expressly reserved.
10.2 Ownership
All Confidential Information remains the exclusive property of the Disclosing Party. No title or ownership rights are transferred to the Receiving Party by virtue of this Agreement.
10.3 Improvements and Derivatives
Any improvements, modifications, or derivative works created by the Receiving Party based on Confidential Information shall be deemed Confidential Information of the Disclosing Party and shall be owned by the Disclosing Party.
11\. REMEDIES AND ENFORCEMENT
11.1 Irreparable Harm
The Receiving Party acknowledges that disclosure of Confidential Information would cause irreparable harm to the Disclosing Party that cannot be adequately compensated by monetary damages alone.
11.2 Equitable Relief
In the event of breach or threatened breach of this Agreement, the Disclosing Party shall be entitled to:
• Immediate Injunctive Relief without the necessity of proving actual damages and without being required to post bond
• Specific Performance of the terms of this Agreement
• Other Equitable Relief as deemed appropriate by a court of competent jurisdiction
11.3 Additional Remedies
The equitable remedies set forth above are in addition to, and not in lieu of, any other remedies available at law or in equity, including monetary damages.
11.4 Attorney’s Fees
In any action to enforce this Agreement, the prevailing Party shall be entitled to recover its reasonable attorney’s fees and costs, including fees on appeal.
12\. GENERAL PROVISIONS
12.1 Governing Law
This Agreement shall be governed by and construed in accordance with the laws of the State of Wyoming, without regard to its conflict of laws principles. The United Nations Convention on Contracts for the International Sale of Goods shall not apply.
12.2 Jurisdiction and Venue
Any legal action arising out of or relating to this Agreement shall be brought exclusively in the state or federal courts located in Laramie County, Wyoming. Each Party irrevocably consents to the personal jurisdiction of such courts and waives any objection to venue or forum non conveniens.
12.3 Entire Agreement
This Agreement constitutes the entire agreement between the Parties with respect to the subject matter hereof and supersedes all prior agreements, understandings, negotiations, and discussions, whether oral or written.
12.4 Amendments
This Agreement may be amended or modified only by a written instrument signed by an authorized representative of each Party.
12.5 Severability
If any provision of this Agreement is held to be invalid, illegal, or unenforceable, the validity, legality, and enforceability of the remaining provisions shall not be affected or impaired, and the Parties shall negotiate in good faith to replace the invalid provision with one that achieves the original intent.
12.6 Waiver
No waiver of any breach of this Agreement shall be deemed a waiver of any subsequent breach. Any waiver must be in writing and signed by the waiving Party.
12.7 Assignment
Neither Party may assign this Agreement or any rights or obligations hereunder without the prior written consent of the other Party, except that either Party may assign this Agreement to an affiliate or in connection with a merger, acquisition, or sale of all or substantially all of its assets, provided that the assignee assumes all obligations hereunder in writing.
12.8 Notices
All notices required or permitted under this Agreement shall be in writing and deemed given when:
• Delivered personally to the recipient, OR
• Sent by certified mail (return receipt requested) or recognized overnight courier to the addresses below, OR
• Sent by email to the email addresses below with confirmation of receipt
To Groovy Company, Inc.:
600 W Peachtree St NW, Suite 1700
Atlanta, GA 30308
Email:
To Counterparty:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Email: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
12.9 Counterparts
This Agreement may be executed in counterparts, each of which shall be deemed an original and all of which together shall constitute one and the same instrument. Electronic signatures (including DocuSign and equivalent platforms) shall be deemed valid and binding to the same extent as handwritten signatures.
12.10 Force Majeure
Neither Party shall be liable for any delay or failure to perform due to circumstances beyond its reasonable control, including acts of God, war, terrorism, pandemic, government action, infrastructure failure, or natural disasters; provided, however, that the confidentiality obligations under this Agreement shall not be excused by force majeure.
12.11 No Partnership / No Obligation to Proceed
Nothing in this Agreement creates a partnership, joint venture, agency, or employment relationship between the Parties, nor does it obligate either Party to enter into any further agreement or transaction. Each Party may discontinue discussions at any time, in its sole discretion.
13\. SIGNATURES
By signing below, the Parties acknowledge that they have read, understood, and agree to be bound by the terms and conditions of this Agreement.
GROOVY COMPANY, INC.
| Signature: | \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
| ---------- | ---------------------------------------------------------------------------------------------- |
| Name: | \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
| Title: | \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
| Date: | \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
COUNTERPARTY
| Signature: | \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
| ---------- | ---------------------------------------------------------------------------------------------- |
| Name: | \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
| Title: | \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
| Date: | \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
WITNESS (if required by applicable state law)
| Signature: | \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
| ---------- | ---------------------------------------------------------------------------------------------- |
| Name: | \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
| Title: | \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
| Date: | \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |
SCHEDULE A — SPECIFIC CONFIDENTIAL INFORMATION CATEGORIES
*\[To be completed based on specific disclosure requirements of the engagement.]*
Technical Information Categories
☐ Solana program source code (Transfer Hook, AMM, Oracle Aggregator, Governance, Liquidity Pool)
☐ ST22 Digital Securities creation, mint, and lifecycle management specifications
☐ Custom AMM Engine — CPMM mathematical models with module-aware pricing
☐ Oracle Network design — custody (all modules), OFAC, AML, TWAP, EDGAR, appraisal (Module 2), reserve attestation (Module 3)
☐ Transfer Hook 42-control security architecture and module-conditional control logic
☐ Cryptographic methods, key management, and Ed25519 signature verification
☐ CEDEX exchange engine — order routing, settlement, and circuit breaker logic
☐ Predictive AI Module — IDOS scoring methodology, NLP pipeline, and OTC issuer universe
Module-Specific Information
☐ Module 1 — Equities: issuer onboarding pipeline, OTC microcap and global-exchange-listed targets
☐ Module 2 — Real Estate: appraisal cadence schedules, USPAP appraiser network, NAV methodology, fractionalization premium model
☐ Module 3 — CORECM: SPE-PRMS reserve methodology, qualified-engineer network, basin-asset onboarding pipeline
Business Information Categories
☐ Financial projections and three-module revenue models
☐ Issuer acquisition strategies, IDOS scoring data, and target lists
☐ Partnership agreements and terms (Empire Stock Transfer, Pyth, Helius, Chainalysis, TRM Labs, Jito, Certora)
☐ Regulatory compliance procedures and SEC engagement materials (Crypto Task Force, no-action letter correspondence)
☐ Competitive analysis and market intelligence
☐ Investment terms, Reg D / Reg S / Reg CF structuring, and funding strategies
☐ Groovy Security Token (STO) offering structure, allocation, and use of proceeds
Other Specific Categories
☐ \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
☐ \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
☐ \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
CONFIDENTIAL — This document contains proprietary and confidential information of Groovy Company, Inc. Unauthorized distribution is strictly prohibited.
# Welcome
Welcome to the **RWA Tokens Marketing Wiki** — the central library for everything we publish about the platform to the outside world. Articles, pitch decks, the lightpaper, investor presentations, SEC filings and staff statements we cite, regulatory commentary, and ongoing news coverage all live here, organized so the comms team, partners, and counsel can find the right asset for the right audience without rebuilding it from scratch.
You'll find collateral grouped by the three asset-class modules — **Equities (ST22), Real Estate, and CORECM** — alongside cross-cutting materials that apply to the platform as a whole: corporate-identity assets, SEC regulatory framework references (Release No. 33-11412, the January 28, 2026 Joint Staff Statement, the April 13, 2026 Covered User Interface Providers statement), and the live news and X/LinkedIn campaign archive. Each item is tagged by audience (institutional investor, issuer prospect, regulator, press) and by stage (draft, internal review, legal-cleared, published) so nothing ships externally without the right approval state.
This wiki is the canonical source for any RWA Tokens marketing artifact under the Groovy Company, Inc. brand (the "OTCM Protocol" dba was retired May 1, 2026; CEDEX, ST22, and GROO remain as product and instrument names). Platform URL is [**https://rwatokens.net**](https://rwatokens.net/); trading venue is **cedex.market**. When in doubt about which version of a deck or letter is current, this wiki is the answer — anything found elsewhere should be checked against the version here before sending.
####
# Solana Blockchain Foundation
### Solana Blockchain Foundation
**Why Solana · How It Works · SPL Token-2022 · Module-Specific Foundations**
This page explains the blockchain foundation that the **RWA Tokens** platform is built on — Solana Mainnet-Beta and the SPL Token-2022 Transfer Hook extension — and how that foundation supports each of the platform's three production modules: **Equities**, **Real Estate**, and **CORECM** (Carbon Ore, Rare Earth, and Critical Minerals).
It is written for institutional evaluators, prospective issuers, regulatory counsel, and capital-markets professionals who need to understand *why* Solana is the only chain where the platform's runtime-enforced compliance architecture can exist today — and what that means for each asset class the platform tokenizes.
***
#### Table of Contents
1. Why Solana
2. Solana Architecture at a Glance
3. Consensus and Finality
4. Parallel Execution
5. SPL Token-2022 — The Tokenization Standard
6. Transfer Hook — Runtime-Enforced Compliance
7. Why Ethereum Cannot Do This
8. Module-Specific Foundations
1. 8.1 Module 1 — Equities
2. 8.2 Module 2 — Real Estate
3. 8.3 Module 3 — CORECM
9. Network Stability and Operational Resilience
10. Performance Comparison
11. Regulatory Alignment
12. Related Documentation
***
#### 1. Why Solana
The RWA Tokens platform chose Solana for one reason above all others: **SPL Token-2022 Transfer Hooks provide runtime-enforced compliance that cannot be bypassed.**
This is not a preference. It is the only blockchain on which the platform's 42-control compliance architecture can be built as specified. Every other chain — Ethereum, the Ethereum Layer 2 ecosystem, Polygon, Avalanche, BNB Chain — implements security-token compliance at the application layer, where any caller with direct access to the underlying token contract can bypass the compliance wrapper. Solana's Token-2022 standard moves compliance into the token program itself, where bypass is structurally impossible. The decision is documented in the platform's Architecture Decision Records (ADR-001) with full alternatives analysis.
The secondary advantages — the approximately 400-millisecond block cadence that aligns with Empire Stock Transfer's per-block custody attestation, the per-transaction cost of approximately $0.00025 that makes per-transfer compliance economically viable, and the theoretical throughput exceeding 65,000 transactions per second — are significant but subordinate to the Transfer Hook capability.
**The Core Comparison**
RequirementSolanaEthereum L1Ethereum L2
Runtime-enforced compliance
**Yes** — Transfer Hook
No — application layer only
No — inherits L1 limitation
Compliance bypass path
**None**
Direct `transfer()` call bypasses wrapper
Same as L1
Block time
**\~400ms**
12–15 seconds
2–15 seconds
Per-transfer cost
**\~$0.00025**
$1–$50+
\~$0.01
Per-transfer compliance economically viable
**Yes** — at any market capitalization
No — prohibitive below $10M
Marginal
Custody attestation cadence
**Per block** (\~400ms)
Minutes to hours
Minutes
For a regulated tokenization platform, only the first row matters in absolute terms. The remaining rows determine whether the platform is operationally viable; the first row determines whether it can exist at all.
***
#### 2. Solana Architecture at a Glance
Solana is a Layer 1 blockchain designed for high throughput and low latency. It is structurally different from Ethereum in two ways that matter for tokenization: it processes transactions in parallel rather than sequentially, and it produces a verifiable cryptographic clock (Proof of History) that allows validators to agree on transaction ordering without communicating timestamps to each other.
**Core Subsystems**
SubsystemFunctionRelevance to RWA Tokens
**Proof of History (PoH)**
Cryptographic clock — sequential SHA-256 hashing produces verifiable ordering of events
Provides the \~400ms block cadence that aligns with Empire Stock Transfer's per-block custody attestation
**Tower BFT**
Byzantine Fault-Tolerant consensus optimized for PoH; validators vote on block validity
Two-thirds supermajority confirmation produces deterministic finality within \~13 seconds
**Sealevel**
Parallel transaction execution engine
Different ST22 mints can execute transfers simultaneously — enables platform throughput at scale
**Gulf Stream**
Mempool-less transaction forwarding to upcoming validator leaders
Reduces latency between submission and inclusion
**Turbine**
Block propagation through validator network
Maintains synchronization across 2,000+ validators
**Cloudbreak**
Parallel-I/O accounts database
Stores all on-chain state, including ST22 mint accounts and compliance configuration
**Network-Level Properties**
PropertyValueWhy It Matters
Block time
\~400ms
One full custody-attestation cycle per block
Theoretical throughput
65,000+ TPS
Headroom for thousands of compliance-verified trades
Compliance-verified throughput
400–600 TPS
Limited by oracle query latency, not Solana itself
Transaction cost
\~$0.00025
Per-transfer 42-control verification is economically viable at any issuer market cap
Finality
\~13 seconds (32 confirmations)
Trading reads use confirmed; settlement uses finalized
Validator count
2,000+
Decentralized consensus; no single-entity control
Validator client diversity
Agave + Firedancer
Two independent implementations reduce correlated-failure risk
***
#### 3. Consensus and Finality
**Proof of History**
Solana's primary innovation. Proof of History is a cryptographic clock — a verifiable delay function that produces a hash chain proving that time has passed between events. Each hash is the SHA-256 of the previous hash, and the chain cannot be parallelized: producing hash *N* requires having produced hash *N-1*. Transactions are inserted into the hash chain at specific positions, proving they occurred at specific points relative to other transactions.
For tokenization, PoH provides something other chains cannot: a deterministic \~400-millisecond block cadence, which is the operational interval at which Empire Stock Transfer's custody oracle posts its per-block attestation that backing collateral remains intact. On Ethereum's 12-to-15-second block time, per-block attestation would mean custody verification every 12-plus seconds — a roughly thirty-fold degradation in real-time backing verification.
**Tower BFT**
Solana's consensus mechanism. Validators vote on the validity of PoH sequences. Once two-thirds or more of staked SOL has voted on a block, that block is considered confirmed. After 32 confirmed blocks (approximately 13 seconds), the block is finalized — the strongest level of certainty before economic settlement.
Confirmation LevelThresholdTimePlatform Usage
Processed
Leader confirms
\~400ms
Not used — too risky for institutional trading
Confirmed
2/3+ supermajority
\~400ms
CEDEX read operations, oracle updates
Finalized
31+ confirmed blocks
\~13 seconds
CEDEX settlement, fee distribution, custody mark-offs
***
#### 4. Parallel Execution
Sealevel is Solana's parallel transaction-execution engine. Unlike Ethereum's EVM, which executes transactions one at a time, Sealevel can execute thousands of transactions simultaneously across all available CPU cores — provided those transactions don't read or write the same accounts.
Why this matters for the platform: ST22 transfers for *different* mints (different issuers, different properties, different mineral basins) can execute in parallel because they touch independent state accounts. Transfers for the *same* mint serialize because they share the SecurityConfig account that governs that issuance. The result is that platform throughput scales horizontally as more issuances launch — adding a new issuer does not slow down trading for existing ones.
This property has direct economic significance for issuers in all three modules: a tokenized property in Module 2 does not compete for execution bandwidth with a tokenized rare-earth basin in Module 3 or a tokenized OTC microcap equity in Module 1.
***
#### 5. SPL Token-2022 — The Tokenization Standard
Solana has two token programs. The distinction between them is the foundation of the RWA Tokens platform's security architecture.
**SPL Token (Original Standard)**
The original Solana token program. Supports mint, transfer, burn, approve, and revoke operations. **Has no Transfer Hook support** — transfers execute without any custom logic. This is the program every major Solana DEX (Raydium, Orca, Jupiter, Meteora) was built around.
**SPL Token-2022 (Extended Standard)**
Solana Labs' next-generation token program. Includes all original SPL Token functionality plus a set of programmable extensions. **Includes the Transfer Hook extension** — a custom program that the Token-2022 runtime invokes on every transfer.
ST22 Digital Securities — the platform's tokenized representation across Equities, Real Estate, and CORECM — are issued under SPL Token-2022 with the Transfer Hook extension permanently attached at mint creation.
**Token-2022 Extensions Used by the Platform**
ExtensionPurposeUsed by RWA Tokens?
**Transfer Hook**
Custom program executed on every transfer
**Yes** — the 42 compliance controls
**Transfer Fee**
Protocol-level fee on every transfer
**Yes** — funds the Global Unified CEDEX Liquidity Pool
**Metadata**
On-chain token name, symbol, URI
**Yes** — issuer identity, property identity, basin identity
**Permanent Delegate**
Irrevocable transfer authority for compliance freeze
**Yes** — Empire Stock Transfer regulatory-freeze authority
Confidential Transfer
Zero-knowledge encrypted balances
Not currently used
Interest-Bearing
Token balance accrues interest
Not applicable to equity, real estate, or basin assets
Default Account State
Accounts created frozen by default
Not currently used
**Why External DEXs Cannot Trade ST22**
Raydium, Orca, Jupiter, and Meteora were built before Token-2022 existed. Their swap programs call the original SPL Token Program — which has no Transfer Hook support. When an ST22 token is sent to one of these DEXs, the DEX's program invokes the original Token Program for the transfer, and the Transfer Hook is never triggered. All compliance controls are bypassed.
This is not a configuration issue. It is a fundamental architectural incompatibility. The DEX would need to rewrite its swap program to call Token-2022 instead of the original Token Program, and no major Solana DEX has done so because there is no commercial incentive for them: unprotected tokens generate higher trading volume, more fees, and more extractable value.
The platform's CEDEX trading venue is built specifically around Token-2022 and the Transfer Hook. Every CEDEX swap invokes the Transfer Hook via Cross-Program Invocation — meaning all 42 controls execute on every trade, atomically and irrevocably.
***
#### 6. Transfer Hook — Runtime-Enforced Compliance
**What a Transfer Hook Is**
A Transfer Hook is a program address permanently stored in a Token-2022 mint account at the time of mint creation. When any transfer instruction is executed for tokens from that mint, the Token-2022 program automatically invokes the specified hook program before the transfer completes. If the hook returns success, the transfer proceeds. If the hook returns an error, the entire transaction reverts atomically — no tokens move, no fees are collected, no state changes persist.
**The Five Properties That Make This Different**
PropertyWhat It MeansWhy It Matters
**Permanent**
Hook address is stored in the mint account at creation; cannot be removed, changed, or disabled afterward
Compliance is permanent for the lifetime of the security
**Mandatory**
The Token-2022 runtime invokes the hook automatically; it is not optional
No caller, wallet, DEX, smart contract, or script can skip the hook
**Atomic**
Hook rejection reverts the entire transaction in a single state machine step
No partial state — either fully compliant or fully reverted
**Universal**
Executes regardless of caller identity or entry point
The platform itself cannot bypass its own controls
**Runtime-enforced**
Invocation is performed by the Token-2022 program — a Solana system program
Enforcement is by the protocol, not by application code
**What "Runtime-Enforced" Actually Means**
The Transfer Hook is not a smart contract call that an application chooses to make. It is executed by the Token-2022 program — which is part of the Solana protocol itself — as a mandatory step in transfer-instruction processing. This is structurally analogous to the way a Solana transaction cannot execute without paying its base fee: the fee is part of the protocol, not a policy choice that an application can opt out of.
Enforcement LevelExampleBypass Path
**Policy**
Terms of service
User ignores the ToS
**Application**
ERC-3643 compliance overlay
Direct EVM call to underlying `transfer()`
**Smart contract**
Restricted-token contract
Admin override function
**Runtime**
SPL Token-2022 Transfer Hook
**None** — enforced by the token program itself
The platform's 42 controls operate at the runtime level. There is no `transferWithoutHook()` function. There is no admin key that disables the hook. There is no governance vote that removes controls. The hook is permanent, mandatory, and atomic.
**The Compliance Control Set**
Every ST22 transfer triggers a sequence of 42 controls. The full specification is documented in the platform's Transfer Hook Technical Specification. The categories are:
CategoryControlsFunction
Custody verification
1–6
Empire Stock Transfer Ed25519 attestation that backing collateral is intact
OFAC / SDN screening
8–10
Real-time sanctions-list check against sender and recipient
AML risk scoring
11
Chainalysis Know-Your-Transaction and TRM Labs three-tier risk score
KYC / Accreditation
12–14
Investor identity and accreditation status
Holding period
24
Rule 144 and Regulation S compliance lock periods
Position limits
15–19
Per-wallet ownership ceiling (4.99% threshold)
Circuit breakers
20–23
Volatility halts and reappraisal triggers
CEI integrity
29–35
Constant-product market-maker invariant checks
Protective conversion
35–38
Cliff-date and conversion mechanics
Audit trail and governance
39–42
Event emission and regulatory-freeze authority
Every control executes on every transfer in every module. The platform cannot route around them.
***
#### 7. Why Ethereum Cannot Do This
**ERC-3643 — Application-Layer Compliance**
Ethereum's leading security-token standard, ERC-3643 (also called T-REX), implements compliance as a set of smart-contract calls that wrap the underlying ERC-20 transfer function. The compliance checks — OnchainID, Identity Registry, Compliance Contract — execute before the transfer, but they are application-layer logic rather than runtime enforcement.
**The Bypass Problem**
Any caller with direct EVM access can call the underlying ERC-20 `transfer()` function on the token contract without going through the T-REX compliance wrapper. This is not a bug in ERC-3643. It is a structural limitation of building compliance on top of a token standard rather than inside it.
**The Admin-Override Problem**
ERC-3643 includes administrator functions that have no equivalent in Token-2022:
ERC-3643 FunctionPurposeToken-2022 Equivalent
`forceTransfer()`
Administrator moves tokens without holder consent
Does not exist
`freezePartialTokens()`
Administrator freezes a portion of holdings
Does not exist
`recoveryAddress()`
Administrator redirects tokens to recovery wallet
Does not exist
`updateIdentityRegistry()`
Administrator modifies the verified-identity list
Empire verification is external; the platform cannot modify it
These functions exist in ERC-3643 for legitimate operational reasons — regulatory freeze, lost-key recovery — but they also create an attack surface where a compromised administrator can move investor tokens unilaterally. In the platform's architecture, the equivalent of a regulatory freeze (Control 42) halts all transfers across the affected mint; it cannot selectively redirect tokens.
**The Cost Problem**
Even if Ethereum added a Transfer Hook equivalent, the gas cost of executing 42 compliance checks on every transfer would be prohibitive at L1, and marginal at L2:
OperationSolana CostEthereum L1 CostCost Ratio
Transfer with 42 compliance checks
\~$0.00025
$5–$50+
20,000× to 200,000×
Custody oracle read
\~$0.00001
$0.50–$5
50,000× to 500,000×
Annual cost at 1,000 transfers/day
\~$91
$1.8M–$18M
Economically infeasible on L1
For a CORECM basin-asset issuance with thousands of small institutional positions trading periodically, the difference between Solana economics and Ethereum economics is the difference between a viable platform and an impossible one.
***
#### 8. Module-Specific Foundations
The platform's three production modules share the same Solana foundation, the same Token-2022 standard, and the same 42-control Transfer Hook framework — but each module exercises specific Solana properties for module-specific operational reasons.
**8.1 Module 1 — Equities**
**What gets tokenized:** Equity securities of companies listed on the OTC microcap market, NASDAQ, NYSE American (AMEX), the Toronto Stock Exchange (TSX), and additional global exchanges. Tokens are issued as ST22 Digital Securities backed 1:1 by Common Class B shares of the issuer held in qualified custody by Empire Stock Transfer.
**Solana properties exercised:**
PropertyUse in Module 1
\~400ms block time
Per-block custody attestation aligns with Empire's Ed25519 signing cadence — investors can verify backing collateral is intact in near real-time
Sealevel parallel execution
Different issuers' ST22 mints execute trades in parallel; one issuer's volume does not slow another
Token-2022 metadata extension
On-chain issuer identity, CUSIP reference, and exemption-class tagging
Transfer Hook Control 24
Rule 144 and Regulation S holding periods enforced atomically per investor
Transfer Hook Controls 12–14
Per-investor accreditation status verified on every transfer
**Regulatory framework:** Operates under the platform's SEC Category 1 Model B architecture as described in SEC Release No. 33-11412 (March 17, 2026), informed by the Joint Staff Statement on Tokenized Securities (January 28, 2026). Issuance offerings are conducted under Regulation D for U.S. accredited investors, Regulation S for non-U.S. investors, and Regulation Crowdfunding (Reg CF) for U.S. retail.
**8.2 Module 2 — Real Estate**
**What gets tokenized:** Direct-ownership interests in real-property assets — commercial, residential, and mixed-use. Each tokenized property is issued by a single-asset entity holding the underlying property, with backing collateral held by Empire Stock Transfer.
**Solana properties exercised:**
PropertyUse in Module 2
Sealevel parallel execution
Each property is a separate mint with an independent SecurityConfig account; properties trade in parallel without interference
Token-2022 metadata extension
On-chain property identifier, jurisdiction, appraisal-cycle tag, and NAV reference
Transfer Hook Controls 20–23
Circuit-breaker controls calibrated to NAV reappraisal cycles — trading halts when on-chain price diverges from appraised value beyond defined thresholds
Transfer Hook Controls 29–35
Constant-product market-maker invariant checks enforce that secondary-market pricing remains consistent with NAV-anchored bands
Per-block finality
Settlement finalizes within \~13 seconds — meaningful for property positions where holders may need to liquidate quickly relative to traditional real-estate settlement timelines
**Pricing architecture:** Module 2 uses appraisal-anchored Net Asset Value pricing with a constant-product market-maker mechanism on CEDEX. Circuit-breaker controls activate when on-chain price moves outside reappraisal-defined bands, pausing trading until the next appraisal cycle confirms or revises the NAV.
**8.3 Module 3 — CORECM**
**What gets tokenized:** Basin-asset interests within the United States strategic minerals supply chain — Carbon Ore (including Department of Energy coal-derived rare-earth element recovery initiatives), Rare Earth elements, and Critical Minerals as defined by U.S. federal frameworks.
**Solana properties exercised:**
PropertyUse in Module 3
Token-2022 metadata extension
On-chain basin identifier, USGS Critical Minerals List classification, jurisdiction, mineral-class tag
Transfer Hook Controls 8–10
OFAC and SDN screening — particularly relevant for strategic minerals subject to export-control regimes
Transfer Hook Controls 12–14
Investor accreditation verification before any transfer of a strategic-mineral basin position
Permanent Delegate extension
Regulatory-freeze authority routed through Empire Stock Transfer in coordination with U.S. agencies if a basin asset becomes subject to federal action
Cross-mint parallel execution
Each basin asset is an independent mint; trading activity in one basin does not affect another
**Regulatory alignment:** Module 3 is aligned to the regulatory and policy frameworks established by the United States Geological Survey Critical Minerals List, the U.S. Department of Energy Critical Materials Strategy, Section 232 of the Trade Expansion Act of 1962, Title III of the Defense Production Act, the critical-minerals provisions of the Inflation Reduction Act, Executive Order 14017 ("America's Supply Chains"), and the Energy Act of 2020. Each Module 3 issuance is subject to issuer-level technical and regulatory diligence in addition to the platform's standard offering-exemption framework.
**Cross-Module Properties**
What every module gets from the same Solana foundation:
* **Identical security guarantees.** The Transfer Hook executes the same 42 controls regardless of asset class. A real-estate token receives the same atomic compliance enforcement as an equity token or a basin token.
* **Identical settlement mechanics.** All three modules settle with \~13-second finality on Solana. There is no asset class that gets weaker settlement guarantees because of its structure.
* **Identical custody architecture.** Empire Stock Transfer serves as the qualified custodian for backing collateral across all three modules; the Ed25519 attestation mechanism is the same.
* **Independent execution lanes.** A spike in Module 1 equity trading does not slow Module 2 property settlement or Module 3 basin transfers. Sealevel ensures cross-module isolation.
***
#### 9. Network Stability and Operational Resilience
**Historical Context**
Solana experienced multiple network outages in 2022 and 2023, raising legitimate concerns about reliability for financial infrastructure. The situation has materially improved through the QUIC networking transition, the deployment of the Firedancer client by Jump Crypto, and the maturation of the validator software stack.
PeriodMajor OutagesLongest OutageStatus
2022
Multiple (7+)
\~17 hours
Historical — pre-QUIC
2023
2
\~5 hours
Improved — QUIC deployed
2024
0 major
N/A
Stable — Firedancer in testing
2025–2026
0 major
N/A
Production-ready — Firedancer on mainnet
**Mitigations the Platform Has in Place**
RiskMitigation
Solana network halt
On-chain state is preserved during halts; no data loss. CEDEX pauses and resumes automatically.
Validator client bug
Firedancer (Jump Crypto) provides an independent validator client. Two-client diversity reduces correlated-failure risk.
Network congestion (priority-fee spikes)
Jito Block Engine for priority-fee optimization. Helius dedicated cluster avoids shared-tier congestion.
RPC provider failure
Helius primary plus Triton failover. Automatic failover in SDK and relay services.
**What Happens to Each Module During a Solana Halt**
SubsystemImpactRecovery
CEDEX trading (all modules)
Trading pauses
Automatic resume on network recovery
Custody oracle attestations
Pause; oracle staleness flag activates
Catch-up on first block of recovered network
Token balances (all modules)
Preserved on-chain
No action needed
Holding-period clocks
Pause (Solana clock stops)
Resume on recovery — no investor disadvantage
Module 2 NAV reappraisal triggers
Pause
Resume on recovery; appraisal cadence unaffected
Module 3 OFAC screening updates
Continue off-chain; queue on-chain updates
Flush queue on recovery
Global Unified CEDEX Liquidity Pool
Balance preserved (immutable program)
No action needed
The key property: a Solana halt is an operational pause, not a state loss. Investor positions, custody attestations, and compliance state survive intact.
***
#### 10. Performance Comparison
MetricSolanaEthereum L1Ethereum L2 (Arbitrum)Platform Requirement
Block time
\~400ms
12–15s
250ms (L2) plus 12s (L1 finality)
Per-block custody attestation
Finality
\~13s (32 confirms)
\~13 min (64 slots)
Minutes to hours (challenge period)
Settlement within seconds
Throughput (theoretical)
65,000+ TPS
\~15 TPS
100–4,000 TPS
400–600 compliance-verified TPS
Transfer cost
\~$0.00025
$1–$50+
\~$0.01
Per-transfer compliance economically viable
Native runtime compliance
**Yes** (Token-2022)
**Not available**
**Not available**
42-control enforcement at runtime
Parallel execution
**Yes** (Sealevel)
No (sequential EVM)
No (sequential EVM)
Cross-module / cross-issuer parallelism
Across every metric that matters for runtime-enforced tokenization compliance, Solana is the only chain that meets the platform's requirements without compromise.
***
#### 11. Regulatory Alignment
The Solana foundation supports the platform's regulatory posture in three concrete ways:
**SEC Category 1 Model B architecture.** SEC Release No. 33-11412 (March 17, 2026) establishes the Category 1 / Model B framework for digital securities. The Transfer Hook's runtime enforcement of custody, OFAC, AML, KYC, holding-period, and position-limit controls is what allows the platform to operate within this framework. Application-layer compliance — which is all Ethereum can offer today — does not provide the same disclosure-of-controls posture.
**Joint Staff Statement on Tokenized Securities (January 28, 2026).** The Joint Staff Statement clarified that tokenization does not alter the underlying legal character of a security and confirmed that existing federal securities laws apply to digital-securities issuances. The platform's runtime-enforced compliance is the technical mechanism that operationalizes this clarification: every transfer of every ST22 security across every module is subject to the same controls that would apply to the underlying security off-chain.
**Stablecoin settlement under the GENIUS Act.** All ST22 purchases on CEDEX settle in stablecoins compliant with the Guiding and Establishing National Innovation for U.S. Stablecoins (GENIUS) Act. Solana's per-block finality and low transaction cost are what make stablecoin-settled tokenized-securities trading economically and operationally viable at institutional scale.
***
#### 12. Related Documentation
* **Architecture Decisions** — ADR-001 (Solana over Ethereum) with full alternatives analysis
* **Smart Contract Reference** — All platform programs with instruction specifications and account schemas
* **Transfer Hook Technical Specification** — Full 42-control reference
* **Competitive Analysis — ERC-3643 vs ST22** — Architectural and economic comparison
* **Whitepaper Section 2** — Technical Architecture (nine-layer stack)
* **Whitepaper Section 3** — Transfer Hook specification
* **Whitepaper Section 11** — ERC-3643 vs ST22 deep dive
* **Compliance Integration Guide** — How module-specific issuances configure the 42 controls
* **Empire Stock Transfer Integration** — Custody attestation, onboarding, and regulatory-freeze workflow
***
*RWA Tokens · Solana Blockchain Foundation · Groovy Company, Inc.*
# Architecture Decisions
### Architecture Decision Records
**ADR-001 through ADR-012 · Evidence-Based Engineering Decisions for the RWA Tokens Platform**
Every major architectural decision underlying the RWA Tokens platform is documented below with context, alternatives considered, decision rationale, consequences, and — where applicable — empirical evidence from beta deployments. This is how an engineering organization operates: decisions are deliberate, documented, and traceable.
This document is maintained by Groovy Company, Inc. for institutional evaluators, prospective issuers across all three production modules (Equities, Real Estate, CORECM), regulatory counsel, and capital-markets professionals who need to understand *why* the platform is built the way it is.
***
#### ADR Format
Each record follows a standard structure:
* **Status:** Accepted, Superseded, or Deprecated
* **Date:** When the decision was finalized
* **Context:** The problem or constraint that required a decision
* **Decision:** What was decided
* **Consequences:** What follows from this decision (positive and negative)
* **Alternatives Considered:** What other options were evaluated and why they were rejected
* **Evidence:** Empirical data, regulatory citations, or technical measurements supporting the decision
***
#### ADR Index
ADRTitleStatusDate
001
Solana over Ethereum
Accepted
June 2025
002
Custom AMM over External DEXs
Accepted
December 2025
003
Global Unified Pool over Per-Issuer Pools
Accepted
June 2025
004
LP Tokens Burned — No Withdrawal Function
Accepted
June 2025
005
Ed25519 Custody Attestation
Accepted
September 2025
006
Dual-Provider AML (Chainalysis + TRM Labs)
Accepted
October 2025
007
5% Fee Structure
Accepted
June 2025
008
Common Class B Replaces Series M
Accepted
March 2026
009
GENIUS Act Stablecoin Settlement
Accepted
January 2026
010
Jito Block Engine for MEV Protection
Accepted
December 2025
011
Three-Module Platform Architecture
Accepted
May 2026
012
Empire Stock Transfer as Sole ST22 Onboarding Authority
Accepted
March 2026
***
#### ADR-001: Solana over Ethereum
**Status:** Accepted **Date:** June 2025 **Deciders:** Chief Technology Officer (Frank Yglesias)
**Context**
The platform requires a blockchain that enforces compliance controls atomically on every token transfer — not as an application-layer overlay that can be bypassed. The January 28, 2026 Joint Staff Statement on Tokenized Securities distinguishes Category 1 (issuer-sponsored, distributed ledger technology in official records) from Category 2 (third-party sponsored, with counterparty risk). Only runtime-enforced compliance achieves Category 1 Model B treatment.
**Decision**
Build exclusively on Solana Mainnet-Beta using SPL Token-2022 Transfer Hooks for compliance enforcement.
**Consequences**
**Positive:**
* Transfer Hook enforcement is a Solana runtime property — no bypass path exists regardless of caller, frontend, or venue.
* \~400ms block time matches Empire Stock Transfer's custody oracle refresh interval — real-time 1:1 verification.
* \~$0.00025 per transaction versus $1–$50+ on Ethereum L1 — makes per-transfer compliance economically viable.
* Sealevel parallel execution — concurrent Transfer Hook verifications across non-overlapping accounts.
* 65,000+ TPS theoretical throughput — headroom for thousands of compliance-verified trades across all three modules.
**Negative:**
* Smaller institutional ecosystem compared to Ethereum.
* ERC-3643 (T-REX) has billions in tokenized assets and longer market adoption history.
* Single-chain dependency until cross-chain bridge (Wormhole NTT) in a future phase.
**Alternatives Considered**
AlternativeWhy Rejected
**Ethereum L1**
No native Transfer Hook equivalent. ERC-3643 compliance is an application-layer overlay — a direct EVM `transfer()` call bypasses all compliance. Gas cost ($1–$50+) makes per-transfer compliance economically unviable. 12-second block time too slow for real-time custody verification.
**Ethereum L2 (Arbitrum, Optimism, Base)**
Inherits ERC-3643 bypass vulnerability. L2 adds sequencer centralization risk. Compliance enforcement still at the application layer, not runtime.
**Polygon**
Same ERC-20 bypass path as Ethereum. No runtime-enforced compliance primitive.
**Avalanche**
Subnet architecture interesting but no equivalent to Transfer Hook enforcement. Smaller DeFi ecosystem than Solana.
**Aptos / Sui (Move-based)**
Move Prover enables formal verification, but neither chain has a Transfer Hook equivalent. Token transfer is a system call that does not natively invoke custom compliance logic. Nascent ecosystems with limited tooling.
**Evidence**
* **SEC Release No. 33-11412 (March 17, 2026):** Establishes Digital Securities as a recognized asset class. Category 1 Model B requires DLT in official shareholder records — runtime enforcement necessary.
* **ERC-3643 bypass risk:** Documented in the platform whitepaper. Direct EVM `transfer()` call bypasses ONCHAINID compliance layer entirely. SPL Token-2022 has no such bypass path.
* **Cost comparison:** 42 control checks at $0.00025 per transaction (Solana) versus $5–$50 per transaction (Ethereum L1) — a 20,000× to 200,000× cost difference per compliance-verified transfer.
***
#### ADR-002: Custom AMM over External DEXs
**Status:** Accepted **Date:** December 2025 **Deciders:** Chief Technology Officer (Frank Yglesias) **Supersedes:** Original assumption that Raydium would serve as a post-graduation trading venue
**Context**
The original architecture assumed ST22 tokens would graduate to Raydium constant-product market-maker pools after the bonding-curve phase. Beta deployments (GROO, GRLF, MSPC) proved this assumption catastrophically wrong. External DEXs call the original SPL Token Program — all 42 Transfer Hook controls are bypassed at the swap instruction level.
**Decision**
Build a custom CPMM AMM engine that natively invokes SPL Token-2022 Transfer Hooks on every swap. ST22 tokens never leave platform infrastructure.
**Consequences**
**Positive:**
* All 42 controls execute on every trade — zero bypass risk.
* Protocol-controlled pool creation — unauthorized liquidity-pool creation is impossible.
* Fee routing enforced at the program level — cannot be circumvented.
* Full CEDEX integration — compliance pre-flight plus on-chain enforcement in one execution path.
* SEC Category 1 Model B compliance maintained throughout the token lifecycle.
**Negative:**
* Must build and maintain custom AMM code — cannot leverage existing DEX infrastructure.
* No Jupiter aggregator integration — ST22 tokens are not discoverable through standard DEX aggregators.
* Substantial development cost for the AMM engine.
* Reduced exposure to liquidity from the broader Solana DeFi ecosystem.
**Alternatives Considered**
AlternativeWhy Rejected
**Raydium**
Partial Token-2022 support. Transfer Hooks disabled at swap. Beta confirmed: GROO -95.8%, GRLF -93.69%. \~85% bot activity. $5.75M extracted from GROO alone.
**Orca**
Limited Token-2022 (whitelist-only). Transfer Hooks not implemented. Concentrated-liquidity design amplifies just-in-time attack surface.
**Jupiter**
Aggregates underlying DEXs — inherits all limitations. No independent Token-2022 support.
**Meteora**
Basic Token-2022. Hooks bypassed at swap.
**Serum / OpenBook**
Order-book DEX. No Transfer Hook support. Would require protocol-level fork to add compliance.
**Wait for DEXs to add Transfer Hook support**
No economic incentive for DEXs to support hooks — unprotected tokens generate more volume, more fees, and more extractable value. The platform's Alesia Doctrine: do not outsource walls to counterparties whose interests are not aligned with yours.
**Evidence**
On-chain, empirically verified across three beta deployments:
BetaDateResult on External DEXControls Bypassed
GROO
October 2025
-95.8% in 2 hours, $5.75M extracted by 1,000+ bots
42 of 42
GRLF
December 2025
-93.69%, \~85% bot activity, six copycat tokens, unauthorized liquidity-pool creation by third-party bot
42 of 42
MSPC
November 2025
Thirteen copycat tokens, RPC bypass of cooldown
42 of 42
This ADR was the direct result of the Alesia Doctrine — the strategic framework produced by analyzing these incidents.
***
#### ADR-003: Global Unified Pool over Per-Issuer Pools
**Status:** Accepted **Date:** June 2025 **Deciders:** Chief Technology Officer (Frank Yglesias)
**Context**
OTC microcap securities and other thinly-traded asset classes face a structural liquidity problem: individual issuers cannot attract dedicated market makers or liquidity providers. Per-issuer pools would require each tokenized issuer, property, or basin asset to source its own buy-side liquidity — the same barrier that makes OTC markets non-functional for these issuers today.
**Decision**
Create a single Global Unified CEDEX Liquidity Pool that serves all ST22 issuers across Modules 1, 2, and 3 simultaneously. Protocol-owned. LP tokens burned at initialization.
**Consequences**
**Positive:**
* Every new issuer inherits immediate secondary-market depth on day one.
* Network effect: more issuers → more trading → deeper pool → better prices → more issuers.
* No dependency on external market makers or liquidity providers.
* Self-reinforcing: 0.44% of every trade permanently deepens the pool.
* Eliminates the bootstrapping problem for new Module 2 properties and Module 3 basin assets.
**Negative:**
* Single pool means correlated risk across issuers and asset classes.
* Pool depth per individual token is a fraction of total pool capital.
* Larger issuances effectively subsidize smaller issuances during the early phase.
* If pool capital is insufficient at launch, all issuers experience thin markets.
**Alternatives Considered**
AlternativeWhy Rejected
**Per-issuer pools**
Bootstrapping problem: each issuer must source $25K–$75K per year in market making. Most OTC microcap companies cannot afford this. The exact problem the platform exists to solve.
**External market makers**
Market makers require guaranteed fees and can withdraw at any time. Their withdrawal creates the very liquidity crises microcap investors experience today.
**Uniswap V3-style concentrated liquidity**
Concentrated liquidity requires active management by LPs. Microcap and basin tokens do not attract sophisticated active LPs. Just-in-time liquidity attacks amplify extractable-value risk.
**Hybrid: Global Pool plus per-issuer optional**
Complexity without clear benefit. Splits liquidity rather than consolidating it.
**Evidence**
* **OTC Markets Group data:** approximately 12,000 OTC issuers; fewer than 500 have active market makers. The remaining \~11,500 have zero or near-zero secondary-market liquidity.
* **Pool economics:** at 50 active issuers averaging $500K daily volume and 5% fees, the 0.44% pool allocation generates approximately $800K per year in permanent pool deepening.
***
#### ADR-004: LP Tokens Burned — No Withdrawal Function
**Status:** Accepted **Date:** June 2025 **Deciders:** Chief Technology Officer (Frank Yglesias)
**Context**
The most common failure mode in decentralized finance is liquidity withdrawal — either malicious (rug pull) or panic-driven (bank run). The Global Pool must be permanent to serve as reliable infrastructure for Digital Securities markets across all three modules.
**Decision**
Burn LP tokens at Global Pool initialization. The withdrawal function was never written into the smart contract code. The liquidity-pool program has no upgrade authority — it is immutable.
**Consequences**
**Positive:**
* Rug pull is mathematically impossible — not policy-prohibited, not governance-restricted, but structurally nonexistent.
* No bank-run risk — liquidity cannot be withdrawn under any condition.
* Formal verification (Certora Prover invariant E.3) confirms this property.
* Institutional evaluators can verify on-chain that the liquidity-pool program has `Authority: none`.
**Negative:**
* Capital committed to the pool can never be recovered — even by Groovy Company, Inc.
* If a catastrophic smart-contract vulnerability is discovered in the pool, the code cannot be upgraded to fix it.
* Pool parameters cannot be adjusted post-deployment (only the AMM program, which is upgradeable, can change how the pool is used).
**Alternatives Considered**
AlternativeWhy Rejected
**Timelock-protected withdrawal**
Timelocks can expire. Multi-signature holders can collude. Governance can be captured. Any withdrawal capability equals non-zero rug-pull risk.
**Governance-gated withdrawal**
Governance votes can be manipulated through capital concentration. A whale buying enough governance tokens could vote to drain the pool.
**Multi-signature withdrawal**
5-of-9 collusion, while unlikely, is not mathematically impossible. The security guarantee must be mathematical, not probabilistic.
**Upgradeable pool with audit requirements**
Upgrades introduce the exact attack surface the design must eliminate. An upgrade could add a withdrawal function.
**Evidence**
* **Formal verification:** Certora Prover invariant E.3 — no instruction in any platform program can reduce Global Pool balance.
* **On-chain verification:** `solana program show ` returns `Authority: none`.
* **GRLF beta incident:** A third-party bot created an unauthorized Raydium pool and drained it to $0.65. This cannot happen on CEDEX because pool creation is protocol-controlled and LP tokens are burned.
***
#### ADR-005: Ed25519 Custody Attestation
**Status:** Accepted **Date:** September 2025 **Deciders:** Chief Technology Officer (Frank Yglesias); Empire Stock Transfer (Patrick Mokros, Founder)
**Context**
Transfer Hook Control 1 must verify on every transfer that the circulating ST22 token supply does not exceed Empire Stock Transfer's custodied Common Class B share count. This requires a cryptographic attestation mechanism that is verifiable on-chain, tamper-proof, and refreshable at Solana block speed (\~400ms).
**Decision**
Empire Stock Transfer signs custody-balance attestations using Ed25519 digital signatures. The attestation payload includes mint address, balance, supply, slot, and timestamp — verified on-chain via Solana's native Ed25519 precompile.
**Consequences**
**Positive:**
* Ed25519 is NIST-standardized and verified natively by Solana — no custom cryptography.
* Per-block attestation (\~400ms) provides near-real-time verification.
* Replay protection built into the payload (slot plus timestamp).
* On-chain public key registration enables anyone to independently verify attestations.
* Zero discrepancy events across three beta issuers and $7M+ processed.
**Negative:**
* Depends on Empire's key management — key compromise would enable false attestation.
* Requires always-on relay infrastructure to push attestations every block.
* Single-source dependency (mitigated by 2-of-3 oracle consensus for discrepancy resolution).
**Alternatives Considered**
AlternativeWhy Rejected
**Merkle proof of reserves**
Batch-oriented — cannot provide per-block attestation. Proof generation too slow for \~400ms cadence. Industry standard (e.g., Chainlink Proof of Reserves) operates on minutes/hours, not milliseconds.
**Zero-knowledge proof**
Computationally expensive on Solana. ZK verification compute-unit cost exceeds Transfer Hook budget. Unnecessary — Empire's balance is not private information.
**Oracle network (Chainlink, Pyth)**
Third-party dependency. No existing oracle provides SEC §17A transfer-agent balance feeds. Would require custom integration anyway. Direct Ed25519 signing is simpler and lower latency.
**Periodic audit only (quarterly)**
Quarterly verification leaves 90 days of unverified trading. Discrepancy detection delayed by months. Unacceptable for real-time securities compliance.
**Evidence**
* **Production record:** Zero discrepancy events across three beta issuers, $7M+ processed liquidity. 1:1 ratio maintained at every block.
* **Solana Ed25519 precompile:** Native instruction — no Cross-Program Invocation overhead. \~120 compute units per verification.
* **\~400ms attestation cadence** matches Solana block time. Staleness threshold: 1 slot. Anything older triggers Error 6002 and halts transfers.
***
#### ADR-006: Dual-Provider AML (Chainalysis + TRM Labs)
**Status:** Accepted **Date:** October 2025 **Deciders:** Chief Technology Officer (Frank Yglesias); Empire Stock Transfer (Patrick Mokros, Founder)
**Context**
Transfer Hook Control 11 requires real-time anti-money-laundering risk scoring on every transaction. A single-provider model creates a blind spot — if one provider's machine-learning model has a false negative, a sanctioned or high-risk entity can trade freely.
**Decision**
Integrate both Chainalysis Know-Your-Transaction and TRM Labs as dual AML providers. Both scores are evaluated; the higher risk score determines disposition. Three-tier risk disposition: 0–30 approve, 31–70 enhanced review, 71–100 reject.
**Consequences**
**Positive:**
* Different ML models and training data reduce false-negative risk.
* Chainalysis KYT: industry standard, widest coverage of known entities.
* TRM Labs: 200+ behavioral features, strong in pattern detection for emerging threats.
* Dual-provider satisfies institutional due-diligence requirements.
* Regulatory defensibility: BSA/AML program exceeds minimum FinCEN requirements.
**Negative:**
* Higher per-transaction cost (\~$0.50–$2.00 per dual query).
* Higher latency (\~300–400ms combined versus \~200ms single-provider).
* Integration complexity — two APIs, two scoring models, two vendor relationships.
* Potential for conflicting scores requiring reconciliation logic.
**Alternatives Considered**
AlternativeWhy Rejected
**Chainalysis only**
Single-provider blind spots. If Chainalysis misses a sanctioned entity's proxy wallet, no backup detection.
**TRM Labs only**
Smaller market share. Less institutional recognition. Same single-provider risk.
**Elliptic**
Strong in EMEA. Less Solana-native integration. Would add a third provider rather than replace either.
**Build in-house**
Multi-year effort. No existing training data. Regulatory defensibility much weaker than established providers with law-enforcement track records.
**Evidence**
* **BSA/AML regulatory framework:** 31 U.S.C. §5311 et seq. requires an "effective" AML program. Dual-provider exceeds the "reasonable" standard.
* **Risk disposition thresholds:** Calibrated against industry data — 30/70 boundaries align with FinCEN Suspicious Activity Report filing thresholds (31 C.F.R. §1020.320).
***
#### ADR-007: 5% Fee Structure
**Status:** Accepted **Date:** June 2025 **Deciders:** Chief Technology Officer (Frank Yglesias)
**Context**
CEDEX must fund real compliance infrastructure: per-transfer oracle verification (\~$2–5 per trade in compliance costs), issuer revenue sharing, permanent pool deepening, and protocol operations. Standard DEX fees (0.3%) cannot fund securities-grade compliance.
**Decision**
A 5% total fee (500 basis points) on every ST22 transaction — both primary offerings and secondary CEDEX trades. Distribution: 2% issuer treasury, 1.5% GROO staking pool, 1.06% protocol operations, 0.44% Global Pool (permanently locked).
**Consequences**
**Positive:**
* Funds real compliance infrastructure (oracle costs, audit, monitoring).
* Issuer revenue sharing (2%) makes the platform commercially viable for tokenizing companies in all three modules.
* 0.44% Global Pool allocation creates self-reinforcing liquidity deepening.
* Staking rewards (1.5%) incentivize long-term GROO holding.
* 5% compares favorably to the 7–10% all-in cost of traditional broker-dealer execution for OTC microcap and similarly-illiquid asset classes.
**Negative:**
* Significantly higher than standard DEX fees (0.3% Raydium, 0.25% Uniswap).
* Makes wash trading expensive (a feature, not a bug) but also increases friction for legitimate high-frequency trading.
* Institutional traders accustomed to sub-1% execution costs may resist initially.
* Fee-discount tiers via GROO staking add complexity.
**Alternatives Considered**
AlternativeWhy Rejected
**0.3% (DEX standard)**
Cannot fund per-transfer compliance costs ($2–5 per trade). Would require external subsidy. Unsustainable.
**1% flat fee**
Covers partial compliance costs but insufficient for issuer revenue sharing and pool deepening. No margin for oracle infrastructure.
**Variable fee by volume tier**
Added complexity without clear benefit. 5% with staking discounts (2.5%–4.5%) achieves the same tiering more simply.
**Separate compliance fee + trading fee**
Confusing user experience. Users see one fee, not two. Single 5% is cleaner.
**Subscription model (monthly fee)**
Poor fit for retail accredited investors who trade infrequently. Per-transaction aligns costs with usage.
**Evidence**
* **Traditional securities cost comparison:** Broker-dealer all-in execution cost for OTC microcap is 7–10% (commission plus spread plus clearing plus settlement). CEDEX at 5% is 30–50% cheaper.
* **Compliance cost per transfer:** Empire oracle query plus OFAC screening plus AML scoring plus TWAP feed equals $2–5 per verified trade. At a 0.3% fee on a $100 trade, revenue is $0.30 — does not cover compliance cost.
***
#### ADR-008: Common Class B Replaces Series M
**Status:** Accepted **Date:** March 2026 **Deciders:** Chief Technology Officer (Frank Yglesias); Legal Counsel **Supersedes:** Series M Preferred as backing instrument for third-party ST22 tokens
**Context**
The SEC Crypto Task Force, in a March 30, 2026 meeting, directed that the backing instrument for third-party ST22 tokens should be Common Class B shares rather than Preferred Series M. Common Class B shares carry full shareholder rights by operation of state law (voting, dividends, liquidation participation). Each issuer designates specific governance terms in its own Certificate of Designation filed with the Secretary of State of the issuer's jurisdiction of incorporation.
**Decision**
Replace Preferred Series M with Common Class B shares as the sole backing instrument for all third-party ST22 Digital Securities tokens across all three modules. Series M is now fully obsolete for issuer-facing tokenization.
**Consequences**
**Positive:**
* Full shareholder rights by operation of state law — not dependent on contract interpretation.
* Simpler corporate governance — Common stock is universally understood by counsel and courts.
* SEC Crypto Task Force alignment — directly responsive to regulatory guidance.
* Certificate of Designation filed with Secretary of State — publicly verifiable.
* Removes Preferred share complexity (liquidation preferences, conversion rights, anti-dilution).
**Negative:**
* Required updating all existing documents, smart contracts, oracle field names, and legal templates.
* 45-item change register across nine categories tracked migration impacts.
* Issuer counsel must file new Certificate of Designation.
* Existing beta tokens (GROO, GRLF, MSPC) were issued under Series M — not retroactively changed.
**Alternatives Considered**
AlternativeWhy Rejected
**Keep Series M Preferred**
Directly contradicts SEC Crypto Task Force March 30, 2026 directive. Regulatory risk unacceptable.
**Common Class A**
Typically reserved for existing common shareholders with superior voting rights. Class B avoids conflict with existing capital structure.
**Convertible Note / SAFE**
Debt instrument, not equity. Does not satisfy Category 1 Model B requirement for direct beneficial ownership.
**Evidence**
* **SEC Crypto Task Force directive:** March 30, 2026 meeting. Common Class B shares specified as backing instrument.
* **Custody oracle update:** `series_m_balance` field renamed to `common_b_balance`. Error 6001 message updated to reference "Common Class B shares."
* **Change register:** 45 items across legal documents, SEC filings, offering documents, smart contracts, websites, Empire systems, marketing materials, GAAP/valuation, and internal operations.
***
#### ADR-009: GENIUS Act Stablecoin Settlement
**Status:** Accepted **Date:** January 2026 **Deciders:** Chief Technology Officer (Frank Yglesias); Legal Counsel
**Context**
ST22 primary offerings and CEDEX secondary trades require a settlement medium. Options: fiat wire transfer, native cryptocurrency (SOL), or regulated stablecoins. The GENIUS Act (Guiding and Establishing National Innovation for U.S. Stablecoins) provides a legislative framework for compliant stablecoin usage in securities settlement.
**Decision**
All ST22 purchases conducted via GENIUS Act-compliant stablecoin settlement — USDC (Circle) and PYUSD (PayPal/Paxos). Not fiat wire. Not SOL or other native cryptocurrency.
**Consequences**
**Positive:**
* Regulatory clarity: GENIUS Act provides explicit legislative framework for stablecoin settlement.
* 1:1 USD backing — no crypto volatility risk during settlement window.
* On-chain settlement — atomic with Transfer Hook enforcement (compliance and settlement in one transaction).
* 24/7/365 settlement — no banking hours, no wire-transfer delays.
* Dual stablecoin (USDC plus PYUSD) avoids single-issuer dependency.
* Existing institutional familiarity with USDC.
**Negative:**
* Stablecoin issuer risk (Circle/Paxos operational risk).
* USDC de-peg risk (March 2023 Silicon Valley Bank event: USDC traded at $0.87 briefly).
* Excludes investors who prefer fiat wire or native cryptocurrency.
* Regulatory dependency on GENIUS Act passage and implementation.
**Alternatives Considered**
AlternativeWhy Rejected
**Fiat wire transfer**
3–5 business-day settlement. Not atomic with on-chain execution. Would require separate clearing/settlement layer. 24/7 trading impossible with banking-hours constraint.
**SOL (native)**
Volatile. 20–50% intraday swings common. Investor receiving ST22 tokens would be exposed to SOL price risk during the offering period. Not suitable for securities settlement.
**USDT (Tether)**
Controversial reserve backing. Lower regulatory clarity than USDC. Not GENIUS Act-aligned. Reputational risk for an institutional-grade platform.
**DAI / algorithmic stablecoins**
Algorithmic stability mechanisms have failed (UST/LUNA collapse, May 2022). Institutional risk teams reject algorithmic stablecoins for securities settlement.
**Evidence**
* **GENIUS Act:** Legislative framework establishing requirements for payment-stablecoin issuers. USDC and PYUSD satisfy issuer reserve and reporting requirements.
* **CFTC Letters 25-39 and 26-05:** Identified as relevant to GENIUS Act stablecoin settlement layer and Empire custody architecture.
* **Atomic settlement:** Stablecoin transfer plus ST22 token delivery plus Transfer Hook verification execute in a single Solana transaction. Fiat wire cannot achieve this.
***
#### ADR-010: Jito Block Engine for MEV Protection
**Status:** Accepted **Date:** December 2025 **Deciders:** Chief Technology Officer (Frank Yglesias)
**Context**
GROO and GRLF beta deployments confirmed that maximal-extractable-value (MEV) bots — sniper bots, sandwich attackers, front-runners — were responsible for approximately 85% of post-launch trading activity. The primary attack vector: bots monitoring the public mempool detect pending transactions and front-run them with higher priority fees.
**Decision**
Integrate Jito Block Engine for private transaction submission on CEDEX. Transactions are submitted directly to the Jito block producer — not visible in the public mempool until they are included in a block. Combined with Transfer Hook price-impact limits (2% maximum) and time-weighted-average-price deviation checks.
**Consequences**
**Positive:**
* \~95% reduction in front-running opportunities (Jito documentation claim, consistent with beta observation).
* Bundled transactions execute atomically — no insertion between bundle components.
* Dynamic priority fees based on network congestion (versus fixed-fee overpayment).
* Complemented by on-chain defenses: 2% price-impact cap (Control 21), circuit breakers (Controls 20–23), wallet limits (Control 15).
**Negative:**
* Jito dependency — if Jito Block Engine is unavailable, fallback to public mempool with degraded MEV protection.
* Jito tip adds small cost to each transaction.
* Not a complete solution alone — requires on-chain controls as a secondary defense layer.
* Centralization concern: Jito validator set is a subset of total Solana validators.
**Alternatives Considered**
AlternativeWhy Rejected
**Public mempool only**
Beta evidence: \~85% bot activity, $5.75M extracted from GROO alone. Public mempool is the primary attack surface.
**Commit-reveal scheme (on-chain)**
Higher latency (two-phase: commit then reveal). Additional compute-unit cost. Complex UX — users must submit two transactions. Jito achieves similar protection with single-phase submission.
**Flashbots Protect (Ethereum equivalent)**
Ethereum-only. No Solana equivalent. Jito is Solana's native MEV protection infrastructure.
**Dedicated validator (platform-operated)**
Significant infrastructure cost. Single point of failure. Regulatory complexity of operating validator infrastructure. Jito provides equivalent protection as a service.
**On-chain controls only (no MEV protection)**
Price-impact limit (2%) and circuit breakers help but do not prevent the initial front-running. Bots can still extract value within the 2% window. Jito prevents them from seeing the transaction at all.
**Evidence**
* **GROO beta (October 2025):** \~1,000+ sniper bots, $5.75M extracted, \~85% automated activity. All attacks leveraged public-mempool visibility.
* **GRLF beta (December 2025):** 34 bot wallets detected. One wallet (`hswtMtZr…`) executed 200+ transactions in minutes — mempool monitoring pattern.
* **Jito architecture:** Transactions submitted to Jito relayer, then to block producer. Not broadcast to public mempool. Visible only upon block inclusion.
* **Fallback behavior:** CEDEX displays "MEV Protection Degraded" banner when Jito is unavailable. All fallback transactions logged for post-incident compliance review.
***
#### ADR-011: Three-Module Platform Architecture
**Status:** Accepted **Date:** May 2026 **Deciders:** Chief Technology Officer (Frank Yglesias)
**Context**
Real-world asset tokenization spans heterogeneous asset classes — equities, real property, strategic minerals, commodities, infrastructure — each with distinct regulatory frameworks, valuation mechanics, and investor profiles. A single undifferentiated tokenization product cannot address this market efficiently. Conversely, a fragmented multi-platform approach (one platform per asset class) sacrifices the network effects of shared liquidity, shared compliance, and shared institutional relationships.
The platform required a structural decision: how to organize the product so that distinct asset classes can be tokenized with class-appropriate diligence and pricing mechanics, while still benefiting from a single Solana foundation, a single Transfer Hook compliance framework, a single Global Unified Pool, and a single qualified custodian.
**Decision**
Organize the platform into three production modules sharing common infrastructure:
* **Module 1 — Equities:** Tokenization of equity securities sourced from OTC microcap, NASDAQ, NYSE American (AMEX), the Toronto Stock Exchange (TSX), and additional global exchanges. Issued as ST22 Digital Securities backed 1:1 by Common Class B shares of the underlying issuer in qualified custody.
* **Module 2 — Real Estate:** Tokenization of direct-ownership interests in real-property assets (commercial, residential, mixed-use). Each property issued by a single-asset entity holding the underlying property. Pricing anchored to independent appraisal-based Net Asset Value with constant-product market-maker mechanics and circuit-breaker controls calibrated to NAV reappraisal cycles.
* **Module 3 — CORECM:** Tokenization of basin-asset interests within the United States strategic minerals supply chain — Carbon Ore (including DOE coal-derived rare-earth element recovery), Rare Earth elements, and Critical Minerals as defined by U.S. federal frameworks.
All three modules share: SPL Token-2022 with Transfer Hook extension, the 42-control compliance framework, the Global Unified CEDEX Liquidity Pool, Empire Stock Transfer as qualified custodian and sole investor-onboarding authority, GENIUS Act stablecoin settlement, and the platform's standard offering-exemption framework (Reg D, Reg S, and Reg CF).
**Consequences**
**Positive:**
* Each module exercises module-appropriate Solana properties and Transfer Hook controls without duplicating infrastructure (see Solana Blockchain Foundation, Section 8).
* Shared Global Pool: liquidity in Module 1 equity trading deepens the pool that supports Module 2 property and Module 3 basin trading. Cross-asset network effects.
* Shared Transfer Hook: compliance enforcement is identical across modules — institutional evaluators verify one framework, not three.
* Shared custody and onboarding: investors onboard once via Empire and trade across all three modules without re-onboarding per asset class.
* Independent Sealevel execution lanes: trading activity in one module does not interfere with another (different mints, different state accounts).
* Module-specific extensions are possible without rearchitecting: Module 2 NAV reappraisal mechanics, Module 3 export-control screening, etc.
**Negative:**
* Operational complexity: each module requires module-specific diligence, valuation, and disclosure tooling.
* Regulatory framing requires per-module precision — Module 3 in particular implicates federal critical-minerals regulation distinct from securities law.
* Marketing must communicate three asset classes without losing the single-platform narrative.
* Issuer-onboarding tooling must accommodate equity issuers, real-estate sponsors, and basin-asset operators with different document requirements.
**Alternatives Considered**
AlternativeWhy Rejected
**Single equities-only platform**
Forfeits the larger and faster-growing tokenization opportunities in real estate and strategic minerals. Restricts the platform to a single asset-class market that, while real, does not justify the underlying infrastructure investment.
**Separate platforms per asset class**
Fragments liquidity, compliance, and custody. Each platform must rebuild what the others already have. No cross-asset network effect. Higher total cost of operation.
**Generic "RWA platform" without module structure**
Loses the asset-class precision required for institutional investors and regulators. A property-tokenization buyer does not want to read equity-tokenization disclosures, and vice versa.
**Two modules (equities + real estate, no CORECM)**
Forfeits the most defensible competitive position the platform has — strategic-minerals tokenization aligned to USGS, DOE, Section 232, DPA Title III, IRA, EO 14017, and the Energy Act of 2020. CORECM is not an incremental product; it is a category creation.
**Evidence**
* **Market research:** Independent analyses (BCG/Ripple, Standard Chartered, Citi) project the tokenized RWA market at approximately USD 4 trillion to USD 30 trillion by 2030, with the largest sub-segments being equities, real estate, and commodities/strategic minerals — the three Modules.
* **Solana Sealevel cross-mint parallelism:** Empirically verified that trading activity in one mint does not affect transaction throughput for unrelated mints. The platform inherits this property at the module level.
* **Regulatory framework alignment:** Module 1 maps to SEC Release No. 33-11412 and the Joint Staff Statement on Tokenized Securities. Module 2 maps to property law plus securities issuance via single-asset entities. Module 3 maps to USGS Critical Minerals List, DOE Critical Materials Strategy, Section 232 of the Trade Expansion Act of 1962, Title III of the Defense Production Act, Inflation Reduction Act critical-minerals provisions, Executive Order 14017, and the Energy Act of 2020.
***
#### ADR-012: Empire Stock Transfer as Sole ST22 Onboarding Authority
**Status:** Accepted **Date:** March 2026 **Deciders:** Chief Technology Officer (Frank Yglesias); Empire Stock Transfer (Patrick Mokros, Founder)
**Context**
ST22 Digital Securities require investor onboarding (Know-Your-Customer, Know-Your-Business, Anti-Money-Laundering, Office of Foreign Assets Control / Specially Designated Nationals screening, accreditation verification, and wallet verification) before any token can be transferred to the investor's wallet. The architectural question: should onboarding be performed by the platform, by individual issuers, by a network of compliance vendors, or centralized through a single regulated qualified custodian?
A fragmented onboarding model produces inconsistent diligence quality, duplicates investor friction (each issuer collects the same documents independently), and dilutes regulatory accountability. A platform-centric model places the platform in a regulated function (transfer agent / qualified custodian) it is not registered to perform.
**Decision**
Empire Stock Transfer — a transfer agent registered with the U.S. Securities and Exchange Commission under Section 17A of the Securities Exchange Act of 1934 — serves as the sole onboarding authority for all ST22 investors across Modules 1, 2, and 3. Empire performs KYC, KYB, AML screening (using Chainalysis KYT and TRM Labs per ADR-006), OFAC/SDN screening, accreditation verification, and wallet verification. No issuer, no platform component, and no third-party vendor performs these functions independently.
**Consequences**
**Positive:**
* Single, consistent diligence standard across all modules and all issuers.
* Investor onboards once and can trade across all three modules without re-onboarding.
* Regulatory accountability is concentrated in a §17A-registered entity with established procedures, audit history, and operational maturity.
* Issuers do not bear onboarding cost or complexity individually — Empire's relationship aggregates the diligence function.
* Custody and onboarding under a single counterparty (Empire) simplifies the regulatory map for SEC and state-level reviewers.
* Reduces investor friction: institutional investors prefer one onboarding event covering the entire platform.
**Negative:**
* Single counterparty dependency: an Empire operational disruption affects all three modules simultaneously.
* Empire's procedural standards are the platform's procedural standards — modifications require coordination with Empire rather than unilateral platform decisions.
* Geographic and jurisdictional limits on Empire's onboarding capacity may constrain investor universe in some markets.
* Concentration risk for regulatory examination — Empire is the operational chokepoint for compliance, which means its examination posture is the platform's examination posture.
**Alternatives Considered**
AlternativeWhy Rejected
**Platform-direct onboarding (no transfer agent)**
Places the platform in the role of a regulated transfer agent without §17A registration. Operationally and legally untenable.
**Per-issuer onboarding**
Inconsistent quality across issuers. Duplicate friction (investors complete KYC/AML for each issuance). No single standard for diligence. Higher aggregate cost. Fragments compliance accountability.
**Multi-vendor onboarding marketplace**
Investor confusion over which vendor performs which check. Inconsistent record-keeping. Difficult regulatory examination — examiners must audit multiple vendors with varying procedures.
**Two-step model: platform pre-screen plus Empire confirmation**
Adds complexity and latency without clear quality gain. If Empire's confirmation is the regulatory anchor, the platform pre-screen is duplicative work.
**Evidence**
* **Empire Stock Transfer registration:** SEC §17A-registered transfer agent under 15 U.S.C. § 78q-1 and 17 C.F.R. § 240.17Ad-1 et seq. Federal-level regulatory anchor.
* **Operational record:** Manages shareholder accounts for hundreds of public companies. Established AML, OFAC, accreditation, and wallet-verification procedures.
* **Custody integration:** Empire is also the qualified custodian for ST22 backing collateral (Common Class B shares per ADR-008). Onboarding and custody under a single regulated counterparty.
* **No-action letter Position 1:** The platform's pending consolidated no-action letter to the SEC Division of Trading and Markets includes Empire's qualified-custodian status as a primary position. Empire's regulatory standing is a load-bearing element of the platform's overall compliance posture.
***
#### ADR Governance
**Adding New ADRs**
New architectural decisions are documented as ADRs when they meet any of these criteria:
* Affects more than one layer of the platform's nine-layer stack.
* Has security implications for Transfer Hook enforcement.
* Changes the regulatory compliance posture.
* Is irreversible (e.g., immutable program deployment, LP burn).
* Has cost implications exceeding $50,000.
* Establishes or modifies a module-level architectural property.
**Superseding ADRs**
When a decision is reversed or replaced, the original ADR status changes to "Superseded" with a reference to the new ADR. The original record is preserved for historical context.
**ADR Review**
ADRs are reviewed quarterly by the Chief Technology Officer. Any ADR whose context has materially changed (new regulation, technology update, competitive development) is flagged for reassessment.
***
#### Related Documentation
* **Solana Blockchain Foundation** — Why Solana, Token-2022, Transfer Hook, and module-specific foundations
* **Whitepaper** — Full technical specification referenced throughout
* **Security Model** — Threat model and formal verification
* **Smart Contract Reference** — Program details for decisions implemented on-chain
* **CEDEX API Reference** — Trading venue API specification
* **Empire Stock Transfer Integration** — Custody attestation, onboarding, and regulatory-freeze workflow
* **Compliance Integration Guide** — How module-specific issuances configure the 42 controls
***
*RWA Tokens · Architecture Decision Records · Groovy Company, Inc.*
# Security Model
### Security Model
**Threat Model · Trust Assumptions · Attack Surface Analysis · Formal Verification**
Security architecture documentation for engineers, auditors, institutional risk teams, regulatory counsel, and the Solana Foundation. This document defines what the platform trusts, what it defends against, and how each defense is mathematically or architecturally guaranteed across all three production modules — Equities, Real Estate, and CORECM (Carbon Ore, Rare Earth, and Critical Minerals).
The platform is operated by Groovy Company, Inc. The trading venue is CEDEX. The issuer-onboarding and qualified-custody anchor is Empire Stock Transfer.
***
#### Table of Contents
1. Security Philosophy
2. Trust Assumptions
3. Threat Model
4. Attack Surface Analysis
5. Module-Specific Threat Surfaces
6. Control-to-Threat Mapping
7. Key Management Architecture
8. Upgrade Security
9. Oracle Security
10. Economic Attack Analysis
11. Formal Verification
12. Beta Incident Post-Mortems
13. Incident Response
14. Bug Bounty Program
15. Responsible Disclosure
***
#### 1. Security Philosophy
The platform's security architecture is based on a single principle: **mathematical impossibility, not policy prohibition.**
Policy can be circumvented. Governance votes can be manipulated. Administrator keys can be compromised. Legal agreements can be breached. Mathematical impossibility cannot be argued with — if a withdrawal function does not exist in the bytecode, no combination of keys, votes, or legal orders can execute it.
This principle drives every architectural decision:
Design DecisionPolicy ApproachPlatform Approach
Liquidity lock
Governance vote to lock
No withdrawal function in code — mathematically impossible
Compliance enforcement
Application-layer checks
Solana runtime-enforced Transfer Hook — no bypass path
Holding period
Contractual agreement
On-chain timer — Control 24 rejects until elapsed
Wallet limits
Terms of service
Transfer Hook rejects above 4.99% — every transfer, every path
Transfer Hook permanence
Administrator can disable
SPL Token-2022 stores hook in mint account — permanent
This same principle applies identically across all three modules. A real-estate token issued under Module 2 receives the same mathematical guarantees as an equity token under Module 1 or a basin asset under Module 3. There is no module that gets weaker security because of its asset class.
***
#### 2. Trust Assumptions
Every security model has trust boundaries. The platform explicitly documents what it trusts and what it does not.
**2.1 What the System Trusts**
Trusted ComponentWhyFailure ConsequenceMitigation
**Solana validator consensus**
Proof of History plus Tower BFT with 2,000+ validators
Chain halt or reorg
Multi-client diversity (Agave plus Firedancer)
**SPL Token-2022 runtime**
Hook invocation is Solana-enforced
Hook bypass
Solana Labs-maintained; formally verified; multi-billion TVL
**Empire Stock Transfer**
SEC §17A registered transfer agent; custody attestation source; sole investor-onboarding authority
False attestation
Ed25519 signatures plus quarterly third-party audit plus 2-of-3 oracle consensus
**Ed25519 cryptography**
NIST-standardized signature algorithm
Signature forgery
Cryptographic standard — no known practical attack
**Anchor framework**
Smart-contract development framework
Framework vulnerability
Coral-maintained; widely audited; Solana ecosystem standard
**2.2 What the System Does NOT Trust**
Untrusted ComponentAttack VectorDefense
**External DEXs** (Raydium, Orca, Jupiter, Meteora)
Bypass Transfer Hook entirely
CEDEX is the only venue — tokens never leave platform infrastructure
**Individual administrator key holders**
Rogue key holder
5-of-9 multi-signature — no single key can execute
**The platform itself**
Insider threat, compromised administrator
Immutable Transfer Hook controls — the platform cannot weaken protections
**Governance voters**
Governance capture
The 42 controls are outside governance scope — hard-coded immutability
**Oracle providers** (Chainalysis, TRM Labs)
False risk scores
Dual-provider cross-validation — both must agree
**Internet connectivity**
Network partition, distributed denial of service
Fail-safe: oracle staleness triggers halt (custody) or degrade (AML/OFAC)
**Users**
Social engineering, compromised wallets
On-chain enforcement regardless of wallet behavior
**Frontend applications**
Spoofed UI, modified client
Transfer Hook enforced by Solana runtime — frontend is UX only
**2.3 Trust Boundary Diagram**
Copy
```
TRUSTED UNTRUSTED
─────────────────────────────────────────────────────
Solana Runtime │ External DEXs
├─ Token-2022 program │ User frontends
├─ Transfer Hook invocation │ Third-party wallets
├─ Ed25519 precompile │ Raw CLI transactions
└─ Consensus (PoH + Tower BFT) │ Governance voters
│ Individual key holders
Empire Stock Transfer │ Oracle network (partial)
├─ Custody balance │ ├─ Single provider failure
├─ Ed25519 attestation │ └─ Network latency
├─ §17A regulatory obligations │
└─ Sole onboarding authority │ Platform team
│ ├─ Cannot weaken 42 controls
On-Chain Programs │ ├─ Cannot extract from Global Pool
├─ Immutable Transfer Hook │ └─ Cannot shorten holding periods
├─ Immutable Liquidity Pool │
└─ Certora-verified invariants │
```
***
#### 3. Threat Model
**3.1 Threat Categories**
CategoryExamplesSeverityPrimary Defense Layer
**On-chain exploit**
Smart-contract vulnerability, arithmetic overflow, reentrancy
Critical
Formal verification plus audit plus fuzz testing
**Oracle manipulation**
False custody attestation, stale OFAC data, AML score gaming, NAV oracle manipulation
Critical
Ed25519 signatures, dual-provider, staleness halts
**Economic attack**
Flash loan, sandwich attack, price manipulation, wash trading
High
Circuit breakers, TWAP, price-impact limits, Jito MEV protection
**Key compromise**
Administrator key theft, multi-signature collusion
High
5-of-9 geographic distribution, 24h timelock, governance supermajority
**Infrastructure attack**
RPC distributed denial of service, oracle network failure, Solana congestion
Medium
Helius dedicated cluster, Triton failover, fail-safe oracle design
**Social engineering**
Phishing, copycat tokens, impersonation
Medium
On-chain issuer verification, Empire onboarding gate, single verified venue
**Regulatory action**
SEC enforcement, OFAC emergency designation, export-control action (Module 3)
Low–Medium
Control 42 (immediate freeze), OFAC emergency push, compliance architecture
**3.2 Threat Actor Profiles**
ActorCapabilityMotivationPrimary Vectors
**MEV bots**
Mempool monitoring, Jito bundles, sandwich infrastructure
Profit extraction
Front-running, sandwich attacks, arbitrage
**Sniper bots**
Automated LP detection, priority-fee bidding
First-mover extraction
LP creation sniping, mempool monitoring
**Coordinated dump groups**
Multi-wallet infrastructure, timing coordination
Market manipulation
Cascade selling, wash trading
**Nation-state actors**
Advanced persistent threats, zero-day exploits
Sanctions evasion, financial warfare, strategic-mineral access
Proxy wallets, AML evasion, oracle manipulation, Module 3 export-control circumvention
**Insider threats**
Administrator access, key holder status
Financial gain, coercion
Key compromise, parameter manipulation
**Copycat deployers**
Token creation capability, social media access
Fraud
Name squatting, fake tokens, phishing
**Real-estate-specific bad actors**
Property-valuation manipulation, false appraisals
NAV gaming for arbitrage
Module 2 NAV oracle manipulation
***
#### 4. Attack Surface Analysis
**4.1 On-Chain Attack Surface**
SurfaceAttackMitigationVerified By
CPMM arithmetic
Overflow/underflow in u64 multiplication
u128 checked arithmetic — all intermediates
Certora Prover (E.5)
Transfer Hook logic
Control bypass via unexpected account layout
CEI pattern enforcement (Controls 29–35) — account owner, size, type verified
Quantstamp plus Halborn audit
PDA derivation
PDA collision or substitution
Deterministic seeds with bump verification
Anchor framework standard
CPI reentrancy
Recursive call exploiting intermediate state
Solana runtime prevents CPI reentrancy by design
Solana architecture
Account confusion
Wrong account type passed as oracle
Account discriminator check (8-byte Anchor prefix)
Anchor framework
Mint authority
Unauthorized minting inflating supply
Mint authority disabled or held by multi-signature. Control 1 verifies supply ≤ custody on every transfer.
Certora Prover (E.1)
Global Pool extraction
Any instruction reducing pool balance
No withdrawal function exists. Immutable program (no upgrade authority).
Certora Prover (E.3)
Holding period bypass
Early unlock through governance or administrator
Holding period parameters are immutable — governance cannot shorten.
Hard-coded constants
Transfer Hook removal
Removing hook after mint creation
SPL Token-2022 standard — hook address permanently stored in mint account.
Solana runtime property
**4.2 Oracle Attack Surface**
SurfaceAttackMitigationFail-Safe
Custody oracle
False balance attestation
Ed25519 signature — Empire private key required
Reject ALL transfers (Error 6001)
Custody oracle
Stale attestation replayed
Slot plus timestamp in signed payload — stale rejected
Reject ALL transfers (Error 6002)
Custody oracle
Empire relay compromised
2-of-3 oracle consensus (primary plus backup plus quarterly audit)
Halt until consensus
OFAC oracle
Stale Specially Designated Nationals (SDN) list
Staleness threshold (24h cache / 48h halt)
Cache <24h; halt >48h
OFAC oracle
SDN list evasion via proxy wallet
Three-layer screening: exact plus fuzzy plus 2-hop clustering
Graph analysis catches proxy chains
AML oracle
Single-provider blind spot
Dual-provider (Chainalysis plus TRM Labs) — different ML models
Cache <6h
AML oracle
Score gaming (just below threshold)
0–30 approve / 31–70 review / 71–100 reject — manual review catches borderline
Enhanced review for 31–70
TWAP oracle
Price manipulation to trigger or avoid breaker
60-observation minimum plus 30-min window plus 3σ outlier rejection
Sustained manipulation required
**NAV oracle (Module 2)**
False appraisal feed for real-estate tokens
Independent licensed appraiser plus reappraisal cycle plus circuit breaker on NAV deviation
Trading halt outside reappraisal-defined bands
**Export-control oracle (Module 3)**
Stale or missing critical-minerals classification
USGS Critical Minerals List plus DOE Critical Materials Strategy data feeds
Enhanced review on classification ambiguity
EDGAR oracle
Tampered filing data
SEC-sourced via official RSS plus EFTS API — signed at source
Last batch; flagged stale in IDOS
**4.3 Off-Chain Attack Surface**
SurfaceAttackMitigation
CEDEX backend
Order matching manipulation
Pre-flight compliance check plus on-chain settlement atomicity — backend cannot alter on-chain outcome
RPC infrastructure
DDoS or degradation
Helius dedicated cluster plus Triton failover plus rate limiting (500 req/s)
WebSocket feeds
False market data
Market data is informational — all trades settle on-chain with Transfer Hook enforcement
API authentication
Stolen credentials
Empire wallet verification required — credentials alone insufficient without on-chain wallet
DNS / TLS
Domain hijacking
Certificate pinning plus HSTS plus DNSSEC
Key storage
HSM compromise
Ledger Enterprise HSM plus geographic distribution plus key rotation schedule
**4.4 Social and Operational Attack Surface**
SurfaceAttackMitigationBeta Evidence
Token impersonation
Copycat tokens on external platforms
Only Empire-verified issuers create ST22 tokens on CEDEX. Single verified venue.
19 copycats deployed across GRLF (6) and MSPC (13) — zero possible on CEDEX
Community confusion
"Which token is real?"
ST22 tokens require Empire custody deposit plus on-chain issuer verification
Direct beta observation — community flooded with support requests
Phishing
Fake CEDEX frontend
Domain verification, certificate pinning, official links only from rwatokens.net
—
Insider trading
Employee front-running issuer launches
Insider Trading Policy, restricted trading windows, compliance monitoring
—
***
#### 5. Module-Specific Threat Surfaces
The same Solana foundation, the same Token-2022 standard, and the same 42-control Transfer Hook framework serve all three modules — but each module presents asset-class-specific threat surfaces that require dedicated defensive consideration.
**5.1 Module 1 — Equities**
**Asset-class-specific threats:**
ThreatDescriptionDefense
Issuer disclosure failure
Tokenized issuer fails to maintain SEC disclosure obligations
Empire onboarding requires current disclosure status; Control 38 (protective conversion) triggers on issuer distress
Rule 144 / Reg S evasion
Early resale before holding period elapses
Control 24 — on-chain HoldingPeriodAccount with jurisdiction-specific timer
Unregistered securities trading
Non-accredited investor receives Reg D security
Empire accreditation verification plus Controls 12–14 enforced on every transfer
Insider trading
Issuer insider trades on material non-public information
Insider Trading Policy plus blackout-window enforcement at the wallet level
**Module 1 trust anchor:** SEC Category 1 Model B architecture per SEC Release No. 33-11412, with Empire as registered transfer agent for the underlying Common Class B shares.
**5.2 Module 2 — Real Estate**
**Asset-class-specific threats:**
ThreatDescriptionDefense
**NAV manipulation**
False appraisal data inserted to enable arbitrage between NAV and on-chain price
Independent licensed appraiser per property; reappraisal cycle on defined cadence; circuit breaker (Control 21) on price-NAV deviation outside defined bands
Single-asset entity failure
The legal entity holding the underlying property defaults, files bankruptcy, or loses title
Control 38 protective conversion; jurisdictional title insurance; per-property due diligence
Property-specific encumbrances
Liens, easements, or transfer-tax obligations not disclosed at tokenization
Pre-issuance title search plus jurisdictional review plus Empire onboarding diligence
Geographic concentration risk
Multiple Module 2 issuances in one jurisdiction face correlated regulatory or environmental risk
Cross-property diligence; jurisdictional diversity tracking; portfolio-level circuit breakers
Reappraisal-cycle gaming
Bad actor accumulates position before favorable reappraisal, sells after
Position limits (Control 15) at 4.99% per wallet; reappraisal-window trading restrictions
**Module 2 trust anchor:** Independent licensed appraiser plus single-asset entity structure plus Empire as qualified custodian for backing collateral.
**5.3 Module 3 — CORECM**
**Asset-class-specific threats:**
ThreatDescriptionDefense
**Export-control evasion**
Sanctioned entity acquires position in strategic-mineral basin via proxy wallet
Three-layer OFAC screening (exact plus fuzzy plus 2-hop graph); Empire enhanced KYC for Module 3 issuances; Section 232 / Defense Production Act cross-reference
**Federal action freeze**
Basin asset becomes subject to federal action under DPA Title III, Section 232, or EO 14017
Control 42 (regulatory freeze) plus Permanent Delegate extension routed through Empire; coordination protocol with relevant federal agency
Basin-asset misclassification
Mineral classification differs from USGS Critical Minerals List or DOE Critical Materials Strategy
Pre-issuance classification verification plus periodic re-verification against authoritative federal lists
Geological-reserve overstatement
Basin proven-reserves figures inflated to support issuance
Independent geological survey plus periodic re-verification plus protective conversion (Control 38) on material misrepresentation
Carbon Ore / DOE program disqualification
Project loses eligibility for DOE coal-derived rare-earth element recovery program
Federal-program-status oracle; Control 38 trigger on disqualification
**Module 3 trust anchor:** USGS Critical Minerals List plus DOE Critical Materials Strategy plus issuer-level technical and regulatory diligence plus Empire as qualified custodian.
**5.4 Cross-Module Threat Properties**
What every module gets, regardless of asset class:
* **Identical Transfer Hook enforcement.** Every transfer in every module triggers all 42 controls atomically.
* **Identical custody architecture.** Empire Stock Transfer holds backing collateral for all three modules under the same §17A regulatory framework.
* **Identical settlement mechanics.** All three modules settle with \~13-second finality on Solana via GENIUS Act-compliant stablecoin.
* **Cross-module isolation.** Sealevel parallel execution prevents an attack on one module's mints from affecting trading or settlement in another module.
***
#### 6. Control-to-Threat Mapping
Every Transfer Hook control maps to a specific threat it mitigates. The mapping applies across all three modules:
ThreatControlsError CodesDefense Mechanism
**Unauthorized minting / supply inflation**
1–6
6001, 6002
Ed25519 custody oracle: supply ≤ custodied shares on every transfer
**Unverified investor trading**
7–10
6002, 6003
Empire KYC/KYB whitelist gate on every transfer
**Sanctioned entity trading**
11–13, 30–34
6003–6007
Three-layer OFAC screening plus dual AML scoring per transfer
**Whale accumulation**
15–19
6004, 6020–6023
4.99% maximum per wallet plus velocity plus cross-wallet detection
**Flash crash / cascade dump**
20–23
6005, 6006
Circuit breaker: >10% in 5 min triggers halt; >2% single impact triggers block; volume-spike detection
**Early resale (Rule 144 / Reg S)**
24–29
6024
On-chain HoldingPeriodAccount with jurisdiction-specific timer
**Issuer / asset distress**
35–38
6008
Protective conversion triggers on bankruptcy, enforcement, loss of Empire (all modules); NAV-divergence threshold (Module 2); federal-action triggers (Module 3)
**Regulatory emergency**
42
6042
Immediate freeze — Legal Counsel plus 3-of-5 multi-signature
**Audit trail integrity**
39–40
—
Immutable on-chain compliance record plus hash-chain verification
**Governance capture**
41
6041
Parameters bounded by hard-coded ranges. The 42 controls are immutable.
***
#### 7. Key Management Architecture
**7.1 Multi-Signature Configuration**
AuthorityThresholdTotal SignersGeographic DistributionUse
**Transfer Hook upgrade**
5-of-9
9
5+ jurisdictions
Program upgrade (24h timelock)
**AMM upgrade**
5-of-9
9
5+ jurisdictions
Program upgrade (24h timelock)
**Oracle upgrade**
5-of-9
9
5+ jurisdictions
Program upgrade (24h timelock)
**Parameter adjustment**
3-of-5
5
3+ jurisdictions
Fee, threshold, cooldown changes (48h timelock)
**Emergency freeze**
3-of-5 plus Legal Counsel
5 plus 1
—
Control 42 (immediate)
**Governance**
3-of-5
5
—
Proposal execution (48h timelock)
**7.2 Key Storage**
Key TypeStorageBackupRotation
Multi-signature signer keys
Ledger Enterprise HSM
Encrypted cold backup in geographically separate safe deposit
Annual or on personnel change
Empire attestation key
Empire internal HSM
Empire custody infrastructure
Empire-managed per §17A requirements
Oracle relay keys
AWS KMS (EKS service)
Cross-region replica
Quarterly
Deployer key
Ledger hardware wallet
Cold backup
Disabled post-deployment (single-use)
**7.3 Key Compromise Scenarios**
ScenarioImpactMitigationRecovery
1 of 9 signer key stolen
None — below threshold
Attacker cannot execute. Compromised key immediately rotated.
Rotate key. Notify other signers.
2 of 9 signer keys stolen
None — below threshold
Same.
Rotate both. Review physical security.
4 of 9 signer keys stolen
None — below threshold
5-of-9 required.
Emergency rotation of all 9 keys via governance proposal.
5 of 9 signer keys stolen
**Critical** — attacker can upgrade programs
24h timelock visible on-chain. Remaining 4 signers or community can alert.
Cancel pending upgrade during timelock. Emergency governance response. Rotate all keys.
Empire attestation key stolen
False custody attestation
Quarterly audit detects discrepancy. Backup oracle cross-reference.
Empire revokes key. New key registered on-chain.
Oracle relay key stolen
Stale or false oracle data injection
Signed payloads include slot — stale payloads rejected. 2-of-3 consensus catches mismatch.
Rotate relay key. Oracle continues via backup.
**7.4 Key Rotation Protocol**
Copy
```
1. New key generated on Ledger Enterprise HSM
2. New key proposed via governance (ParameterAdjustment type)
3. 48-hour timelock — visible on-chain
4. 3-of-5 (or 5-of-9 for upgrade authority) execute rotation
5. Old key deauthorized in same transaction
6. Confirmation: verify new key can sign, old key rejected
7. Documentation updated in Network Configuration
```
***
#### 8. Upgrade Security
**8.1 Transfer Hook Upgrade Process**
The Transfer Hook is the most security-sensitive program. Upgrades follow the most restrictive protocol:
Copy
```
Step 1: Governance proposal (ProgramUpgrade type)
Step 2: Voting period ≥ 48 hours
Step 3: 66.67% supermajority required (not simple majority)
Step 4: Certora re-verification — all 6 invariants must pass on new code
Step 5: Independent audit attestation (Quantstamp or Halborn)
Step 6: 24-hour timelock (cancellable by 2-of-5 during window)
Step 7: 5-of-9 multi-signature executes BPF upgrade instruction
```
**8.2 What Upgrades CANNOT Do**
Prohibited ActionEnforcement Mechanism
Remove any of the 42 controls
Certora re-verification rejects — invariant E.4 violated
Lower holding period below statutory minimum
Hard-coded constants — not in adjustable parameter space
Add withdrawal to Global Pool
Pool program is immutable — no upgrade authority exists
Remove Transfer Hook from existing mints
SPL Token-2022 standard — hook address permanent in mint account
Bypass multi-signature requirement
Multi-signature enforced at Solana program level — not application logic
**8.3 Immutable Programs**
ProgramUpgrade AuthorityImplication
Liquidity-pool program
**None**
Cannot be upgraded. Ever. By anyone. This is the Global Pool permanence guarantee.
***
#### 9. Oracle Security
**9.1 Asymmetric Fail-Safe Design**
Oracle failures are not treated equally. The consequence of each failure determines the response severity:
OracleFailure ModeRisk of ContinuingFail-Safe Response
**Custody**
Stale attestation
**Catastrophic** — trading without verified backing
**Reject ALL transfers** (Error 6001/6002)
**OFAC**
Stale SDN list
**High** — potential sanctions violation
Cache <24h. Halt ALL transfers >48h stale.
**AML**
Stale risk score
**Medium** — elevated compliance risk
Cache <6h. Flag stale for manual review.
**TWAP**
No price feed
**Medium** — circuit breaker disabled
Use last confirmed price. Disable breaker >5 min.
**NAV (Module 2)**
Reappraisal feed delayed
**Medium** — pricing band uncertainty
Trading paused until reappraisal feed restored
**EDGAR**
Feed delay
**Low** — delayed intelligence
Continue with last batch. Flag stale in IDOS.
The custody oracle has the strictest fail-safe because a custody discrepancy threatens the 1:1 backing guarantee — the foundational property of every ST22 token across every module. A stale AML score is a manageable risk. A wrong custody count is an existential threat.
**9.2 Oracle Consensus Model**
Copy
```
┌──────────────┐
│ Empire API │ Primary — Ed25519 signed per block
│ (Ed25519) │
└──────┬───────┘
│
┌───────────▼───────────┐
│ 2-of-3 Consensus │
│ Required for: │
│ - Discrepancy │
│ resolution │
│ - Post-halt resume │
└───────────┬───────────┘
┌─────┴─────┐
┌───────▼──┐ ┌─────▼────────┐
│ Platform │ │ Quarterly │
│ Backup │ │ Third-Party │
│ Node │ │ Audit │
└──────────┘ └──────────────┘
```
**9.3 Ed25519 Attestation Security**
PropertyImplementation
**Signature algorithm**
Ed25519 (EdDSA on Curve25519) — NIST-standardized
**Key registration**
Empire public key registered on-chain at oracle initialization
**Payload structure**
`mint (32B) + common_b_balance (8B) + token_supply (8B) + slot (8B) + timestamp (8B)` = 64 bytes
**Replay prevention**
Slot number in payload — attestation for past slots rejected
**Verification**
Solana Ed25519 precompile — verified in same transaction as Transfer Hook
**Key rotation**
Empire-managed. New key registered on-chain via multi-signature. Old key deauthorized.
**9.4 Oracle Security Properties**
PropertyMechanism
Single-oracle compromise resistance
2-of-3 consensus required for approval decisions
Replay attack prevention
Ed25519 signatures include slot plus timestamp — stale rejected
Price manipulation resistance
TWAP (30-min window) plus 60-observation minimum plus 3σ outlier rejection
SDN evasion resistance
Three-layer screening: exact address plus fuzzy entity plus 2-hop graph clustering
AML score gaming
Dual-provider (Chainalysis plus TRM Labs) — different ML models and training data
NAV oracle integrity (Module 2)
Independent licensed appraiser plus reappraisal-cycle enforcement plus on-chain price-NAV deviation circuit breaker
Federal-classification integrity (Module 3)
USGS plus DOE feed cross-reference plus quarterly re-verification
***
#### 10. Economic Attack Analysis
**10.1 Flash Loan Attack**
**Attack:** Borrow massive capital in a single block, manipulate price, extract profit, repay loan — all atomically.
**Why it fails on CEDEX:**
DefenseMechanismControl
Price impact limit
\>2% single-trade impact triggers block
Control 21 (Error 6021)
Volume halt
\>30% daily sell per wallet triggers 24h halt
Control 23 (Error 6037)
TWAP deviation
Requires sustained manipulation across 60 observations / 30 minutes
Control 20
Circuit breaker
\>10% price move in 5 min triggers 15-min halt
Control 20 (Error 6005)
Flash loans require large single-block execution. The 2% price-impact limit makes the profit margin insufficient after accounting for fees (5%) and slippage. The attack is economically irrational across all three modules.
**10.2 Sandwich Attack**
**Attack:** Bot detects pending trade, places buy before and sell after to extract MEV from price movement.
**Why it fails on CEDEX:**
DefenseMechanism
Jito Block Engine
Private transaction submission — trades not visible in mempool
Price impact limit
2% maximum per trade — sandwich profit margin compressed below fee cost
Fallback (no Jito)
CEDEX displays degraded MEV protection banner. Fair-sequencing by commit time.
**10.3 Coordinated Dump**
**Attack:** Multiple wallets coordinate to sell simultaneously, crashing price for community.
**Why it fails on CEDEX:**
DefenseMechanismControl
Wallet limit
Maximum 4.99% per wallet — limits individual selling pressure
15
Volume halt
\>30% daily sell per wallet triggers halt
23
Circuit breaker
\>10% price move in 5 min triggers 15-min halt
20
Cross-wallet detection
Behavioral clustering identifies coordinated wallets
18
**Beta evidence (GROO):** 1,000+ sniper bots used 200+ wallets to circumvent the 4.99% limit on Raydium. On CEDEX, Control 15 enforces 4.99% per wallet on every transfer at the Solana runtime level — multi-wallet strategies cannot bypass because the hook executes on every path.
**10.4 Wash Trading**
**Attack:** Self-trading to inflate volume metrics and attract investors.
**Why it fails on CEDEX:**
DefenseMechanismControl
Self-transfer block
sender == receiver triggers Error 6015
CEI
5% fee
Every trade costs 5% — wash trading has real cost
Fee architecture
Timing correlation
Same-wallet buy-sell within window flagged
Analytics
Amount correlation
Matching amounts across wallets flagged
Analytics
**10.5 Rugpull**
**Attack:** Issuer or LP provider withdraws liquidity, leaving token worthless.
**Why it is mathematically impossible on CEDEX:**
DefenseMechanism
LP burned
LP tokens burned at Global Pool initialization. No withdrawal function exists.
Immutable pool program
Liquidity-pool program has no upgrade authority — cannot add withdrawal.
Formal verification
Certora Prover invariant E.3: no instruction can reduce Global Pool balance.
Per-issuer isolation
Issuers do not control pool capital. Pool is protocol-owned.
**10.6 NAV Arbitrage (Module 2-Specific)**
**Attack:** Bad actor manipulates appraisal data to create arbitrage between on-chain price and "true" NAV.
**Why it fails on CEDEX:**
DefenseMechanism
Independent appraiser
Each property has a licensed appraiser; the platform does not control appraisal
Reappraisal cycle
Defined cadence — appraisals do not move continuously, removing high-frequency manipulation incentive
Circuit breaker on deviation
Control 21 halts trading when on-chain price diverges from appraised band
Position limits
4.99% maximum per wallet limits accumulation ahead of reappraisal
**10.7 Federal-Action Position-Building (Module 3-Specific)**
**Attack:** Bad actor anticipates federal regulatory action on a basin asset (DPA Title III, Section 232, EO 14017) and accumulates position before broader market awareness.
**Why it fails on CEDEX:**
DefenseMechanism
Position limits
4.99% maximum per wallet limits pre-action accumulation
Cross-wallet detection
Coordinated multi-wallet strategies flagged via behavioral clustering
Federal-action freeze
Once federal action occurs, Control 42 freezes the affected mint immediately
Insider trading policy
Platform personnel and counterparties prohibited from trading on material non-public information
***
#### 11. Formal Verification
Six invariants verified via Certora Prover symbolic execution. Each invariant provides a mathematical proof — not a test result — that a critical property holds under ALL possible execution conditions.
**11.1 Invariant Registry**
IDPropertyFormal StatementImplication
**E.1**
No Unauthorized Minting
`∀ s→s': mint_to ⟹ custody_oracle(s').common_b ≥ s'.supply ∧ Ed25519.valid`
Supply cannot increase without verified Empire custody deposit
**E.2**
Custody Ratio
`∀ s, t: t executes ⟹ s.custody.common_b ≥ s.supply ∧ s.custody.slot ≥ current - 1`
Every transfer has verified 1:1 backing at execution time
**E.3**
Pool Non-Extractability
`¬∃ i: execute(i, s) → s' where s'.pool_balance < s.pool_balance`
No instruction can reduce Global Pool balance. Withdrawal impossible.
**E.4**
Hook Completeness
`∀ t on hook-mint: Token2022.transfer(t) ⟹ hook(t) invoked ∧ (hook = Err ⟹ revert)`
Every transfer triggers hook. Rejection causes atomic revert.
**E.5**
Fee Accuracy
\`∀ swap s:
actual\_fee - (a × 500/10000)
**E.6**
Circuit Breaker Correctness
`∀ t: (impact > θ) ⟺ rejected`
Breaker activates if and only if threshold exceeded. No false positives or negatives.
**11.2 Verification Scope**
ProgramCertoraQuantstampHalbornOtterSec
Transfer Hook program
6 invariants
Full audit
Full audit
—
AMM program
E.5 (fee)
—
—
Full audit
Liquidity Pool program
E.3 (non-extract)
—
—
—
Governance program
—
—
Full audit
—
Oracle Aggregator program
—
Full audit
—
—
***
#### 12. Beta Incident Post-Mortems
Three beta deployments on Solana Mainnet provided empirical validation of every security assumption. The attacks were real, measured, and on-chain.
**12.1 GROO — Sniper Attack (October 2025)**
MetricValue
Peak market cap
$6,000,000
Post-attack market cap
$250,000 (-95.8%)
Time to collapse
<2 hours
Estimated bots
\~1,000+ wallets
Value extracted
\~$5,750,000
**Root cause:** Token traded on Raydium (external DEX). Raydium calls the original SPL Token Program — Transfer Hook never invoked. All 42 controls bypassed.
**Attack vectors confirmed:** Mempool sniping (\~300 bots), front-running (\~400), sandwich attacks (\~200), Jito bundle attacks (\~100).
**Architectural response:** Built custom AMM and CEDEX. ST22 tokens never leave platform infrastructure. All trades execute through Transfer Hook.
**12.2 GRLF — Bot Dominance plus Copycats (December 2025)**
MetricValue
Price collapse
-93.69%
Bot share of activity
85% (34 of 40 post-launch transactions)
Human share
15% (6 transactions)
Copycat tokens
6 across Pump.fun, Raydium, Moonshot
Unauthorized LP
Created by third-party bot 54 min after mint
**Root cause:** Same as GROO — external DEX bypass. Additional finding: unauthorized LP creation by adversary bots.
**Architectural response:** Protocol-controlled pool creation (only the platform can initialize CEDEX pools). Empire onboarding required for token creation — copycat deployment structurally impossible.
**12.3 MSPC — Infrastructure Bottleneck (November 2025)**
MetricValue
Copycat tokens
13 across external platforms
RPC bottleneck
50 sendTx/sec exceeded — cooldown bypassed
Transactions beyond limit
Processed without security controls
**Root cause:** Helius RPC tier (200 req/sec, 50 sendTx/sec) insufficient for launch volume. Bots consumed RPC capacity, legitimate users saw failures.
**Architectural response:** Dedicated Helius cluster (500+ req/sec) plus Triton failover plus transaction queuing.
**12.4 Beta Summary**
FindingConfirmed AcrossArchitectural Response
External DEXs bypass ALL 42 controls
GROO, GRLF, MSPC
CEDEX-only venue. Custom AMM with native Token-2022 support.
85% of activity is automated bots
GRLF
Jito MEV protection, circuit breakers, commit-reveal
Unauthorized LP creation by bots
GRLF
Protocol-controlled pool initialization
19 copycat tokens across 3 launches
GRLF (6), MSPC (13)
Empire-verified issuers only. On-chain issuer verification.
RPC capacity limits enable bypass
MSPC
Dedicated Helius cluster plus Triton failover
Contract-level controls survive external DEX
All three
Confirms: liquidity lock plus vesting work everywhere. Hook-dependent controls require CEDEX.
***
#### 13. Incident Response
**13.1 Severity Classification**
SeverityDefinitionResponse SLAEscalation
**P0 — Active Exploit**
Funds at risk, control bypass confirmed, custody discrepancy
15 minutes
CTO plus Legal Counsel plus all multi-signature holders
**P1 — Service Degradation**
Oracle stale, CEDEX latency >10s, RPC failover triggered
1 hour
CTO plus DevOps lead
**P2 — Partial Failure**
Single oracle degraded (cached serving), non-critical feature unavailable
4 hours
On-call engineer
**P3 — Monitoring Alert**
Threshold warning, unusual pattern, non-exploitable anomaly
24 hours
On-call engineer
**13.2 P0 Response Procedure**
Copy
```
1. DETECT: Automated monitoring alerts (Datadog plus PagerDuty)
OR manual report via security@rwatokens.net
2. TRIAGE (15 min SLA):
- Confirm exploit — on-chain evidence
- Identify affected mints and modules
- Estimate funds at risk
3. CONTAIN (immediate):
- Control 42: Regulatory freeze on affected mint(s)
Requires: Legal Counsel plus 3-of-5 multi-signature
- Notify Empire Stock Transfer compliance (15-min SLA)
- Disable CEDEX trading for affected pairs
4. INVESTIGATE:
- Full on-chain forensics — transaction trace
- Oracle state audit — attestation history
- Smart contract review — identify vulnerability
5. REMEDIATE:
- If program vulnerability: emergency upgrade (5-of-9 plus Certora re-verify)
- If oracle issue: rotate oracle keys, verify backup consensus
- If key compromise: emergency key rotation
6. RECOVER:
- 2-of-3 oracle consensus confirms integrity restored
- Lift Control 42 freeze
- Resume CEDEX trading
- Publish post-incident report
7. POST-MORTEM (within 72 hours):
- Root cause analysis
- Timeline reconstruction
- Control effectiveness review
- Remediation verification
- Public disclosure (if warranted)
```
**13.3 Communication Protocol**
AudienceChannelTiming
Multi-signature holders
Encrypted channel (Signal)
Immediate on P0/P1
Empire Stock Transfer
Dedicated compliance hotline
15-min SLA on P0
Institutional investors
Direct notification via CEDEX portal
Within 1 hour of confirmed P0
Public / community
Status page plus social media
After containment (not during active response)
SEC / regulators
Formal notification if SAR threshold met
Per 31 C.F.R. §1020.320 requirements
***
#### 14. Bug Bounty Program
**14.1 Scope**
In ScopeOut of Scope
Transfer Hook program — all 42 controls
Third-party dependencies (Solana, Anchor, Token-2022)
AMM program — CPMM logic, fee routing
Social engineering attacks
Liquidity-pool program — extraction attempts
Denial of service (volumetric)
Oracle aggregator program — attestation verification
Frontend / UI issues
Governance program — proposal execution
Known issues already in remediation
CEDEX API — authentication, authorization
Rate-limiting behavior
**14.2 Rewards**
SeverityImpactReward
**Critical**
Fund extraction, control bypass, supply inflation, Global Pool drainage
Up to $100,000
**High**
Oracle manipulation, key compromise path, fee bypass, holding-period bypass
Up to $25,000
**Medium**
Information leak, partial control degradation, non-exploitable logic error
Up to $5,000
**Low**
UX issue with security implications, documentation inconsistency
Up to $1,000
**14.3 Priority Targets**
Highest-reward vulnerabilities that would represent fundamental security failures:
TargetImpactMaximum Reward
CPMM invariant violation (k decreases)
Fund extraction via swap manipulation
$100,000
Transfer Hook bypass on CEDEX
Any transfer without 42-control validation
$100,000
Global Pool balance reduction
Any instruction that reduces pool capital
$100,000
Custody oracle signature forgery
False attestation without Empire key
$100,000
NAV oracle manipulation (Module 2)
Trading based on false appraisal data
$50,000
Federal-classification oracle bypass (Module 3)
Trading of misclassified basin asset
$50,000
Fee routing bypass
Trade without 5% fee collection
$50,000
Holding-period early unlock
Transfer before Rule 144 / Reg S elapsed
$50,000
Circuit breaker bypass
Trade exceeding 2% impact without rejection
$25,000
***
#### 15. Responsible Disclosure
**15.1 Reporting**
ChannelContact
**Email**
**Encrypted**
PGP key published at rwatokens.net/security/pgp
**Response SLA**
Acknowledgment within 24 hours. Triage within 72 hours.
**15.2 Disclosure Policy**
* **Embargo period:** 90 days from report acknowledgment before public disclosure.
* **Coordination:** Reporter and the platform agree on disclosure timeline.
* **Credit:** Reporter credited in security advisory (unless anonymity requested).
* **Safe harbor:** Good-faith security research conducted within scope will not result in legal action.
**15.3 What to Include in a Report**
Copy
```
- Description of vulnerability
- Affected program(s) and instruction(s)
- Affected module(s) (Equities, Real Estate, CORECM, or all)
- Steps to reproduce (localnet or devnet preferred)
- Proof of concept (code or transaction)
- Estimated severity and impact
- Suggested mitigation (if any)
```
***
#### Related Documentation
* **Solana Blockchain Foundation** — Why Solana, Token-2022, Transfer Hook, module-specific foundations
* **Architecture Decisions** — ADR-001 through ADR-012 with full alternatives analysis
* **Smart Contract Reference** — Program instructions, accounts, error codes
* **SDK Reference** — Error handling and recovery patterns
* **Empire Stock Transfer Integration** — Custody attestation, onboarding, regulatory-freeze workflow
* **Compliance Integration Guide** — How module-specific issuances configure the 42 controls
* **Incident Response Playbook** — Detailed P0 / P1 / P2 / P3 procedures
* **Whitepaper** — Full technical specification referenced throughout
***
*RWA Tokens · Security Model · Groovy Company, Inc.*
# Infrastructure Overview
### Infrastructure Overview
**Cloud Architecture · Security Posture · Development Pipeline · Operational Maturity**
Public infrastructure documentation for institutional evaluators, auditors, prospective issuers across all three production modules (Equities, Real Estate, CORECM), and developers. This page describes the architecture, security practices, and operational environment that support the RWA Tokens platform — without exposing operational details that would aid adversaries.
The platform is operated by Groovy Company, Inc. The trading venue is CEDEX. The issuer-onboarding and qualified-custody anchor is Empire Stock Transfer.
> **Security Note:** This document intentionally omits IP addresses, hostnames, internal network topology, port configurations, and service-to-host mappings. Detailed infrastructure documentation is maintained internally and available to auditors under non-disclosure agreement.
***
#### Table of Contents
1. Infrastructure Philosophy
2. Cloud Architecture
3. Environment Separation
4. Production Environment
5. Development Environment
6. CI/CD Pipeline
7. Network Security
8. Data Security
9. Monitoring and Alerting
10. Backup and Disaster Recovery
11. Blockchain Infrastructure
12. Object Storage
13. Module-Specific Infrastructure Considerations
14. Compliance Posture
15. Infrastructure Roadmap
***
#### 1. Infrastructure Philosophy
The platform's infrastructure follows three principles:
**Environment isolation.** Development and production run on physically separate infrastructure with no shared credentials, no shared databases, and no network connectivity between them. A compromised development environment cannot reach production.
**Defense in depth.** No single control protects any asset. Every production service is behind multiple independent security layers — network firewall, application authentication, TLS encryption, access logging, and runtime monitoring. Compromise of any single layer does not grant access.
**Minimal attack surface.** Only the services required for production operation are exposed to the public internet. Internal services communicate over private networks. Administrative access requires key-based authentication — password authentication is disabled everywhere.
These principles apply identically across all three modules. A real-estate issuance under Module 2 traverses the same hardened infrastructure as an equity issuance under Module 1 or a basin-asset issuance under Module 3.
***
#### 2. Cloud Architecture
**Provider**
AttributeDetail
**Primary provider**
DigitalOcean
**Compute**
DigitalOcean Droplets (dedicated CPU available)
**Object storage**
DigitalOcean Spaces (S3-compatible)
**Regions**
US East and US West (multi-region)
**Blockchain RPC**
Helius (dedicated cluster) plus Triton (failover) — not self-hosted
**DNS and CDN**
Cloudflare (DDoS protection, CDN caching, SSL termination)
**Monitoring**
Datadog (metrics, logs, APM) plus PagerDuty (alerting)
**Secrets**
Encrypted environment configuration — not stored in source control
**Architecture Diagram**
Copy
```
INTERNET
│
┌──────▼──────┐
│ Cloudflare │ DDoS protection · WAF · SSL
│ CDN + WAF │ Rate limiting · Bot mitigation
└──────┬──────┘
│
┌─────────────┼─────────────┐
│ │ │
┌─────▼─────┐ ┌────▼────┐ ┌──────▼──────┐
│ Frontend │ │ CEDEX │ │ Issuer │
│ (Web App) │ │ API │ │ Portal │
└─────┬─────┘ └────┬────┘ └──────┬──────┘
│ │ │
┌─────▼─────────────▼─────────────▼─────┐
│ PRIVATE NETWORK │
│ ┌──────────┐ ┌───────────────────┐ │
│ │ Backend │ │ Oracle Relay │ │
│ │ Services │ │ Services │ │
│ └──────────┘ └───────────────────┘ │
│ ┌──────────┐ ┌───────────────────┐ │
│ │ Database │ │ AI / IDOS │ │
│ │ Layer │ │ Module │ │
│ └──────────┘ └───────────────────┘ │
└──────────────────┬────────────────────┘
│
┌────────────┼────────────┐
│ │ │
┌─────▼─────┐ ┌───▼───┐ ┌─────▼─────┐
│ Helius │ │ Pyth │ │ Empire │
│ RPC │ │ Oracle│ │ Stock │
│ (Solana) │ │ │ │ Transfer │
└───────────┘ └───────┘ └───────────┘
EXTERNAL SERVICES (not self-hosted)
```
***
#### 3. Environment Separation
PropertyProductionDevelopment
**Purpose**
Live CEDEX trading, oracle relays, investor-facing services
Feature development, testing, staging
**Isolation**
Physically separate infrastructure
No access to production data or credentials
**Shared resources**
None
None
**Credential overlap**
Zero — no shared keys, tokens, or API credentials
Zero
**Network connectivity**
Not connected to dev
Not connected to prod
**Deployment**
Manual promotion with approval gates
CI/CD automated
**Access**
Restricted to authorized operations personnel
Available to engineering team
**Data**
Real investor and issuer data (encrypted)
Synthetic / test data only
***
#### 4. Production Environment
**Compute**
Service CategoryInstancesSpecificationsPurpose
**Frontend**
1
Lightweight
rwatokens.net and cedex.market web applications
**Backend API**
1
Standard
CEDEX REST API, WebSocket, order management
**Oracle relays**
Colocated with backend
Standard
Custody, OFAC, AML, TWAP, NAV (Module 2), federal-classification (Module 3), EDGAR relay services
**Production Hardening**
ControlImplementation
**SSH access**
Key-based only — password authentication disabled
**Root login**
Disabled — sudo via named user accounts
**Firewall**
DigitalOcean Cloud Firewall — default deny inbound, explicit allow per service port
**Exposed ports**
Minimum required (HTTPS 443). All other ports firewalled.
**OS updates**
Automated security patches (unattended-upgrades)
**TLS**
TLS 1.2+ enforced on all public endpoints. HSTS enabled.
**DDoS protection**
Cloudflare proxy — production IPs not publicly exposed
**Rate limiting**
Application-level (CEDEX API tiers) plus Cloudflare WAF rules
**Logging**
All access logs shipped to Datadog. Retention: 30 days hot, 1 year cold.
**Intrusion detection**
Automated alerting on SSH login, sudo usage, and failed authentication attempts
**Uptime Target**
ServiceTargetMonitoring
CEDEX API
99.9%
Datadog synthetic checks plus uptime monitoring
Oracle relays
99.95% (custody relay critical)
Datadog custom metrics plus PagerDuty escalation
Frontend
99.9%
Cloudflare analytics plus Datadog
***
#### 5. Development Environment
**Services**
ServicePurpose
**GitLab (self-hosted)**
Source control, issue tracking, CI/CD pipelines, code review
**Development backends**
CEDEX API dev, oracle relay dev, integration testing
**Design and project management**
Penpot (open-source design), Plane (project tracking)
**AI / IDOS development**
EDGAR NLP pipeline, IDOS model training, wallet profiling
**IPFS node**
Decentralized content storage for on-chain metadata references
**CDN development**
CDN origin testing and static asset staging
**Development Specifications**
ResourceAllocation
**Total compute**
6 development droplets across US East and US West
**Total RAM**
45 GB aggregate development capacity
**Total disk**
465 GB aggregate development storage
**Largest instance**
16 GB RAM / 80 GB disk (AI module training plus project-management backends)
**Development Tools**
ToolPurposeHosting
**GitLab CE**
Source control, CI/CD, container registry
Self-hosted (dedicated droplet)
**Penpot**
Open-source design tool (UI/UX)
Self-hosted
**Plane**
Open-source project management
Self-hosted
**IPFS**
Decentralized storage for metadata
Self-hosted node
**Docker**
Containerization for all services
On each droplet
***
#### 6. CI/CD Pipeline
**Pipeline Architecture**
Copy
```
DEVELOPER
│
├─ git push → GitLab (self-hosted)
│
├─ GitLab CI triggers:
│ ├─ Lint (cargo fmt + clippy + prettier + eslint)
│ ├─ Unit tests (cargo test --workspace)
│ ├─ Integration tests (anchor test)
│ ├─ Security scan (cargo audit + npm audit)
│ └─ Build artifacts (anchor build + docker build)
│
├─ Merge to develop → auto-deploy to dev environment
│
├─ Merge to main → requires:
│ ├─ 2 code review approvals
│ ├─ All CI gates pass
│ ├─ No critical/high security findings
│ └─ CTO sign-off (for smart contract changes)
│
└─ Production deployment → manual promotion with checklist
```
**CI/CD Security**
ControlImplementation
**Secrets in CI**
GitLab CI/CD variables — masked and protected. Never in source code.
**Container scanning**
Automated vulnerability scanning on Docker images
**Dependency audit**
`cargo audit` (Rust) plus `npm audit` (Node.js) on every pipeline run
**Branch protection**
`main` and `develop` branches protected — no force push, no direct commit
**Artifact signing**
Build artifacts include SHA-256 hash for reproducibility verification
***
#### 7. Network Security
**Defense Layers**
Copy
```
LAYER 1: Cloudflare (edge)
├─ DDoS mitigation (L3/L4/L7)
├─ Web Application Firewall (WAF)
├─ Bot management
├─ Rate limiting
├─ SSL/TLS termination
└─ Origin IP masking — production IPs not publicly resolvable
LAYER 2: DigitalOcean Cloud Firewall
├─ Default deny inbound
├─ Explicit allow rules per service
├─ SSH restricted to authorized IPs
└─ Inter-droplet communication via private network only
LAYER 3: Application layer
├─ Wallet signature authentication (CEDEX API)
├─ Empire Stock Transfer verification gate
├─ API rate limiting per tier
└─ Request validation and input sanitization
LAYER 4: Runtime monitoring
├─ Datadog APM (application performance)
├─ Anomaly detection on all endpoints
├─ Failed authentication alerting
└─ PagerDuty escalation (P0–P3)
```
**Network Isolation**
Network SegmentVisibilityCommunication
**Public-facing** (frontend, API)
Internet via Cloudflare
Inbound HTTPS only
**Private services** (backend, oracles, DB)
Private network only
Not internet-accessible
**Development**
Separate infrastructure entirely
No production connectivity
**External APIs** (Helius, Empire, Chainalysis, TRM Labs)
Outbound only
Authenticated API calls over TLS
***
#### 8. Data Security
**Encryption**
Data StateEncryptionStandard
**In transit**
TLS 1.2+ on all connections
HTTPS enforced, HSTS headers
**At rest (disk)**
DigitalOcean volume encryption
AES-256
**At rest (database)**
Application-level encryption for PII
AES-256
**At rest (object storage)**
DigitalOcean Spaces server-side encryption
AES-256
**Backups**
Encrypted snapshots
DigitalOcean managed
**Sensitive Data Handling**
Data CategoryStorageAccessRetention
**Investor PII**
Empire Stock Transfer (not platform-side)
Empire only
Per BSA (5 years)
**KYC / KYB documents**
Empire Stock Transfer
Empire only
Per BSA (5 years)
**Transaction records**
On-chain (immutable) plus compliance database
Authorized compliance personnel
7 years (Securities Act)
**Oracle attestations**
On-chain (immutable)
Public (Solana ledger)
Permanent
**API credentials**
Encrypted environment variables
Operations team only
Rotated per schedule
**Multi-signature keys**
Ledger Enterprise HSM (not on servers)
Key holders only
Rotated annually
**Module 2 appraisal records**
Independent appraiser plus compliance database
Authorized compliance personnel
7 years
**Module 3 federal-classification records**
Compliance database with USGS / DOE source attribution
Authorized compliance personnel
Permanent (federal record-keeping standard)
**Access Control**
ResourceAuthenticationAuthorization
**Server SSH**
Ed25519 key-based only
Named user accounts, sudo logging
**GitLab**
SSO plus 2FA enforced
Role-based (developer, maintainer, admin)
**CEDEX API (public)**
Wallet signature
Empire-verified investors only
**CEDEX API (admin)**
Key-based plus IP whitelist
Operations team only
**Datadog / PagerDuty**
SSO plus 2FA
Role-based
**DigitalOcean console**
SSO plus 2FA
CTO plus DevOps lead only
***
#### 9. Monitoring and Alerting
**Monitoring Stack**
ToolPurposeCoverage
**Datadog**
Infrastructure metrics, application logs, APM traces
All production services
**PagerDuty**
Alert routing and on-call management
P0–P3 escalation policies
**Cloudflare Analytics**
Edge traffic, DDoS events, WAF blocks
All public endpoints
**DigitalOcean Monitoring**
Droplet CPU, memory, disk, network
All droplets
**Custom health endpoints**
Per-service health checks
Oracle relays, CEDEX API
**Key Dashboards**
DashboardMetrics
**CEDEX Trading**
Order volume, fill rate, latency (p50/p95/p99), error rate — segmented by module
**Oracle Health**
Custody freshness (slot age), OFAC staleness, AML cache hit rate, NAV reappraisal cycle status (Module 2), federal-classification freshness (Module 3)
**Transfer Hook**
Control pass/fail distribution, error code frequency, latency
**Infrastructure**
CPU, memory, disk, network per droplet. RPC latency.
**Security**
Failed SSH attempts, failed API authentication, WAF blocks, rate-limit triggers
**Alert Thresholds**
AlertConditionSeverityResponse
Custody oracle stale
Slot age > 5
P0
Immediate — all transfers halt
CEDEX API 5xx > 10%
5-minute window
P1
1-hour response
RPC failover triggered
Primary Helius unreachable
P2
4-hour response
Disk usage > 85%
Any production droplet
P3
24-hour response
Failed SSH login
Any production server
P2
4-hour review
NAV oracle stale (Module 2)
Reappraisal feed delayed beyond defined cadence
P1
1-hour response — affected mints paused
Federal-classification stale (Module 3)
USGS / DOE classification feed unreachable beyond cache window
P2
4-hour response — enhanced review on new transfers
***
#### 10. Backup and Disaster Recovery
**Backup Strategy**
AssetMethodFrequencyRetentionTested
**Production droplets**
DigitalOcean snapshots
Weekly
4 weeks
Quarterly restore test
**Databases**
Automated managed backups
Daily
30 days
Monthly restore test
**GitLab**
Full backup (repos plus CI config plus issues)
Daily
30 days
Monthly restore test
**Object storage**
DigitalOcean Spaces versioning
Continuous
90 days
Quarterly
**On-chain state**
Solana ledger (immutable)
N/A — permanent
Permanent
N/A
**Configuration**
Infrastructure-as-code in GitLab
Every change
Git history
Every deployment
**Disaster Recovery Targets**
MetricTargetNotes
**RPO (Recovery Point Objective)**
24 hours (worst case)
Most data is on-chain (permanent). Off-chain data: daily backup.
**RTO (Recovery Time Objective)**
4 hours
New droplet from snapshot plus restore config plus verify services
**On-chain data**
Zero data loss — permanent
Solana ledger is the authoritative record
**Recovery Procedures**
ScenarioProcedureRTO
Single droplet failure
Restore from latest snapshot to new droplet
1–2 hours
Database corruption
Restore from managed backup plus replay from on-chain state
2–4 hours
Region failure
Redeploy to alternate region from snapshots plus IaC
4–8 hours
Complete provider failure
Redeploy to alternate provider from GitLab backups plus IaC
8–24 hours
On-chain programs
Programs are deployed on Solana — independent of platform infrastructure
0 (already available)
***
#### 11. Blockchain Infrastructure
**Solana Connectivity**
ComponentProviderSelf-Hosted?Purpose
**Primary RPC**
Helius (dedicated cluster)
No — managed
All Solana reads, transaction submission
**Failover RPC**
Triton
No — managed
Automatic failover on Helius outage
**WebSocket**
Helius enhanced
No — managed
Real-time slot/block subscriptions
**MEV protection**
Jito Block Engine
No — managed
Private transaction submission
**Why RPC Is Not Self-Hosted**
Running a Solana full node requires 512 GB RAM, 2 TB NVMe, and enterprise-grade networking — a $2,000+ per month dedicated server commitment. Helius dedicated clusters provide equivalent performance with 99.9% SLA, geographic redundancy, and enhanced WebSocket support at a fraction of the operational burden. The Triton failover ensures no single-provider dependency.
**Oracle Relay Architecture**
Oracle relay services run on platform infrastructure, bridging external data sources to on-chain oracle accounts. The relay set includes module-specific feeds for Module 2 (NAV) and Module 3 (federal classification):
Relay ServiceExternal SourceUpdate CadenceOn-Chain TargetModule Scope
Custody relay
Empire Stock Transfer API
Every block (\~400ms)
CustodyOracle PDA
All modules
OFAC indexer
U.S. Treasury OFAC API
Hourly plus emergency push
OFACOracle PDA
All modules
AML bridge
Chainalysis KYT plus TRM Labs
Per-transfer (cached 6h)
AMLOracle PDA
All modules
TWAP consumer
Pyth Network (on-chain)
Continuous
SecurityConfig TWAP
All modules
NAV relay
Independent licensed appraisers
Reappraisal-cycle cadence
NAVOracle PDA
Module 2 (Real Estate)
Federal-classification relay
USGS Critical Minerals List, DOE Critical Materials Strategy
Daily plus emergency on EO update
ClassificationOracle PDA
Module 3 (CORECM)
EDGAR pipeline
SEC EDGAR RSS plus EFTS
60s poll plus daily batch
IDOS state
Module 1 (Equities)
***
#### 12. Object Storage
**DigitalOcean Spaces**
PropertyConfiguration
**Provider**
DigitalOcean Spaces (S3-compatible)
**Region**
US West
**Encryption**
Server-side AES-256
**Access**
Private by default — authenticated access only
**CDN**
DigitalOcean Spaces CDN enabled for static assets
**Versioning**
Enabled — 90-day retention
**Storage Use Cases**
Bucket CategoryContentAccess
**Issuer communications**
Issuer onboarding documents, communication records
Authenticated platform personnel only
**Static assets**
Frontend assets, documentation files
CDN (public)
**Backup artifacts**
Database dumps, configuration backups
Encrypted, operations team only
**Module 2 appraisal artifacts**
Appraisal reports, supporting documentation
Authorized compliance personnel only
**Module 3 classification artifacts**
USGS / DOE classification source records, geological surveys
Authorized compliance personnel only
> No investor PII, KYC documents, or financial records are stored in platform-managed object storage. All investor data is maintained exclusively by Empire Stock Transfer.
***
#### 13. Module-Specific Infrastructure Considerations
The same core infrastructure serves all three modules. Three module-specific extensions have measurable infrastructure implications:
**13.1 Module 1 — Equities**
**Infrastructure characteristics:**
* Highest expected transaction volume of the three modules.
* EDGAR pipeline integration for issuer-disclosure intelligence (Layer 9 IDOS).
* Standard custody, OFAC, AML, and TWAP oracle dependencies.
**Infrastructure-specific risks:** Transaction-volume spikes during issuer disclosure events (8-K, 10-Q, 10-K filings). Mitigated by Helius dedicated cluster headroom and Jito Block Engine bundling.
**13.2 Module 2 — Real Estate**
**Infrastructure characteristics:**
* Lower transaction-volume cadence than Module 1, but higher per-transaction notional value.
* Additional NAV oracle relay bridging independent licensed appraisers to on-chain pricing bands.
* Per-property single-asset entity tracking in compliance database.
**Infrastructure-specific risks:** Reappraisal-cycle gaps create on-chain pricing-band staleness. Mitigated by Module 2-specific monitoring of NAV oracle freshness with P1 alerting.
**13.3 Module 3 — CORECM**
**Infrastructure characteristics:**
* Lowest expected transaction volume but highest regulatory sensitivity.
* Federal-classification oracle relay sourced from USGS Critical Minerals List and DOE Critical Materials Strategy feeds.
* Enhanced KYC depth in Empire onboarding pipeline for accredited basin-asset investors.
**Infrastructure-specific risks:** Federal action under DPA Title III, Section 232, or Executive Order 14017 may require rapid Control 42 freeze coordination. Mitigated by federal-classification relay alerting plus established Empire-coordinated freeze procedure.
**13.4 Cross-Module Infrastructure Properties**
Identical across modules:
* Network ingress and egress paths (Cloudflare → backend → Solana RPC).
* Multi-signature authority for program upgrade and parameter adjustment.
* Backup and disaster recovery procedures.
* Datadog and PagerDuty alerting infrastructure.
* Empire Stock Transfer custody and onboarding integration.
***
#### 14. Compliance Posture
**Infrastructure Compliance**
RequirementImplementation
**Data encryption at rest**
AES-256 on all volumes and object storage
**Data encryption in transit**
TLS 1.2+ enforced on all connections
**Access logging**
All SSH, API, and admin actions logged to Datadog (30-day hot, 1-year cold)
**Secrets management**
Encrypted environment variables — not in source control, not on disk in plaintext
**Patch management**
Automated security updates (unattended-upgrades)
**Backup verification**
Monthly restore tests with documented results
**Incident response**
Documented runbooks (see Incident Response Playbook) with quarterly tabletop exercises
**Change management**
All infrastructure changes tracked in GitLab with approval workflows
**SOC 2 alignment**
Controls aligned with SOC 2 Type II trust service criteria (audit pending)
**Separation of Duties**
FunctionPersonnelOverlap
**Smart contract deployment**
CTO plus multi-signature holders
No overlap with operations
**Infrastructure operations**
DevOps plus CTO
No overlap with compliance
**Investor data (KYC / KYB)**
Empire Stock Transfer exclusively
The platform has no access
**Compliance decisions**
Legal Counsel
Independent of engineering
**Key management**
Designated multi-signature holders (Ledger Enterprise)
Geographically distributed, no key overlap
***
#### 15. Infrastructure Roadmap
**Q3 2026 (Mainnet Launch)**
InitiativeStatusPurpose
Production hardening review
In progress
Pre-launch security audit of all production infrastructure
Load testing at 600 TPS
Planned
Verify production capacity under mainnet trading load
Disaster recovery drill
Planned
Full region-failover test before launch
SOC 2 Type II audit
Planned
Institutional compliance requirement
Module 2 NAV oracle production deployment
Planned
Required for Module 2 launch readiness
Module 3 federal-classification oracle production deployment
Planned
Required for Module 3 launch readiness
**Q4 2026 – Q1 2027**
InitiativePurpose
**Kubernetes migration**
Container orchestration for auto-scaling, rolling deployments, and self-healing
**Multi-region production**
Active-active deployment across US East and US West for latency and redundancy
**Dedicated database cluster**
Managed PostgreSQL or MongoDB Atlas with read replicas and automated failover
**Infrastructure-as-Code**
Full Terraform / Pulumi coverage for reproducible deployments
**WAF rule hardening**
Custom Cloudflare WAF rules tuned to CEDEX API traffic patterns
**2027+**
InitiativePurpose
**CDN edge compute**
Cloudflare Workers for pre-flight compliance caching at the edge
**HSM-backed API signing**
Hardware security module for CEDEX API response signing
**Zero-trust networking**
Identity-verified access per request — no VPN dependency
**Cross-region oracle relays**
Geographically distributed relay services for oracle latency reduction
***
#### For Auditors
Detailed infrastructure documentation — including service-to-host mapping, network topology, firewall configurations, and credential management procedures — is available under non-disclosure agreement. Contact:
PurposeContact
Security audit / penetration test
Infrastructure review (institutional)
Compliance audit
***
#### Related Documentation
* **Solana Blockchain Foundation** — Why Solana, Token-2022, Transfer Hook, module-specific foundations
* **Architecture Decisions** — ADR-001 through ADR-012 with full alternatives analysis
* **Security Model** — Threat model, key management, formal verification, module-specific threat surfaces
* **Network Configuration** — Program IDs, RPC endpoints, PDA registry, production parameters
* **Incident Response Playbook** — P0–P3 runbooks, communication protocol
* **Deployment Guide** — Build, deploy, verify procedures
* **Oracle Integration Guide** — Relay service architecture, fail-safe cascade, module-specific oracles
***
*RWA Tokens · Infrastructure Overview · Groovy Company, Inc.*
# Network Configuration
### Network Configuration
**Program IDs · RPC Endpoints · Oracle Accounts · Multi-Signature Addresses · Parameters**
Authoritative reference for all deployed program addresses, infrastructure endpoints, oracle account addresses, multi-signature configurations, and production parameters across mainnet and devnet environments. This page is updated with every deployment.
The platform is operated by Groovy Company, Inc. The trading venue is CEDEX. The qualified-custody and onboarding anchor is Empire Stock Transfer. Production endpoints support all three production modules: Equities (Module 1), Real Estate (Module 2), and CORECM — Carbon Ore, Rare Earth, and Critical Minerals (Module 3).
> **Deployment status note:** Mainnet program IDs and PDA addresses are populated at production deployment (Q3 2026). Placeholder values shown below. This page is updated with production addresses upon mainnet launch.
***
#### Table of Contents
1. Program IDs
2. RPC Configuration
3. Oracle Accounts
4. Multi-Signature Wallets
5. Global Pool Accounts
6. Production Parameters
7. SDK Configuration
8. Environment Variables
9. Token-2022 Program Reference
10. Verification Commands
***
#### 1. Program IDs
**Mainnet-Beta**
ProgramProgram IDUpgrade AuthorityStatus
Transfer Hook
``
5-of-9 multi-signature plus 24h timelock
Pending mainnet deployment
AMM
``
5-of-9 multi-signature plus 24h timelock
Pending mainnet deployment
Liquidity Pool
``
**None — immutable**
Pending mainnet deployment
Governance
``
3-of-5 multi-signature
Pending mainnet deployment
Oracle Aggregator
``
5-of-9 multi-signature plus 24h timelock
Pending mainnet deployment
**Devnet**
ProgramProgram IDUpgrade AuthorityStatus
Transfer Hook
``
Deployer keypair
Deployed
AMM
``
Deployer keypair
Deployed
Liquidity Pool
``
Deployer keypair
Deployed
Governance
``
Deployer keypair
Deployed
Oracle Aggregator
``
Deployer keypair
Deployed
**External Programs**
ProgramProgram IDNetworkPurpose
SPL Token-2022
`TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb`
All
Token standard with Transfer Hook
SPL Token (legacy)
`TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA`
All
SOL transfers, USDC and PYUSD
Associated Token
`ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL`
All
ATA derivation
Ed25519 Precompile
`Ed25519SigVerify111111111111111111111111111`
All
Custody attestation verification
System Program
`11111111111111111111111111111111`
All
Account creation, SOL transfers
Sysvar Clock
`SysvarC1ock11111111111111111111111111111111`
All
Timestamp, slot
Sysvar Rent
`SysvarRent111111111111111111111111111111111`
All
Rent exemption
***
#### 2. RPC Configuration
**Mainnet-Beta**
ParameterValue
**Primary RPC**
`https://mainnet.helius-rpc.com/?api-key=`
**Fallback RPC**
`https://.rpcpool.com`
**WebSocket**
`wss://mainnet.helius-rpc.com/?api-key=`
**Provider**
Helius (dedicated cluster)
**Fallback provider**
Triton (backup)
**Commitment (reads)**
`confirmed`
**Commitment (settlement)**
`finalized`
**Preflight simulation**
Enabled
**Priority fee strategy**
Dynamic — Jito tip based on congestion
**Max retries**
3 (exponential backoff: 1s, 2s, 4s)
**Timeout**
30 seconds
**Devnet**
ParameterValue
**Primary RPC**
`https://devnet.helius-rpc.com/?api-key=`
**Fallback RPC**
`https://api.devnet.solana.com`
**WebSocket**
`wss://devnet.helius-rpc.com/?api-key=`
**Commitment**
`confirmed`
**Preflight**
Enabled
**Priority fee**
None
**Max retries**
3
**Localnet**
ParameterValue
**RPC**
`http://localhost:8899`
**WebSocket**
`ws://localhost:8900`
**Commitment**
`confirmed`
**Rate Limits**
TierRequests/secsendTransaction/secProvider
**Production**
500+
100+
Helius dedicated
**Devnet**
100
25
Helius shared
**Public fallback**
Rate limited
Rate limited
Triton / Solana public
**Failover Behavior**
Copy
```
PRIMARY (Helius) ──request──► Success → return
│
└── Failure (timeout / 5xx / rate limit)
│
▼
FALLBACK (Triton) ──request──► Success → return
│
└── Failure
│
▼
ERROR → retry with exponential backoff (1s, 2s, 4s)
After 3 retries → surface error to caller
P2 alert raised on failover trigger
```
***
#### 3. Oracle Accounts
**Mainnet PDA Accounts**
OraclePDA SeedsAddressCardinalityModule Scope
**CustodyOracle**
`[b"custody-oracle", mint]`
Per-mint derived
One per ST22 mint
All modules
**OFACOracle**
`[b"ofac-oracle"]`
``
Global singleton
All modules
**AMLOracle**
`[b"aml-oracle", wallet]`
Per-wallet derived
One per wallet
All modules
**SecurityConfig**
`[b"security-config", mint]`
Per-mint derived
One per ST22 mint
All modules
**HoldingPeriodAccount**
`[b"holding-period", mint, beneficiary]`
Per-pair derived
One per investor × mint
All modules
**NAVOracle**
`[b"nav-oracle", mint]`
Per-mint derived
One per Module 2 mint
Module 2 (Real Estate)
**ClassificationOracle**
`[b"classification-oracle", mint]`
Per-mint derived
One per Module 3 mint
Module 3 (CORECM)
**ExtraAccountMetaList**
Token-2022 standard
Per-mint derived
One per ST22 mint
All modules
**PDA Derivation Code**
Copy
```
import { PublicKey } from '@solana/web3.js';
function derivePDA(seeds: Buffer[], programId: PublicKey): [PublicKey, number] {
return PublicKey.findProgramAddressSync(seeds, programId);
}
// SecurityConfig (all modules)
const [securityConfig] = derivePDA(
[Buffer.from('security-config'), mint.toBuffer()],
TRANSFER_HOOK_PROGRAM_ID,
);
// HoldingPeriodAccount (all modules)
const [holdingPeriod] = derivePDA(
[Buffer.from('holding-period'), mint.toBuffer(), beneficiary.toBuffer()],
TRANSFER_HOOK_PROGRAM_ID,
);
// CustodyOracle (all modules)
const [custodyOracle] = derivePDA(
[Buffer.from('custody-oracle'), mint.toBuffer()],
ORACLE_AGGREGATOR_PROGRAM_ID,
);
// OFACOracle (singleton, all modules)
const [ofacOracle] = derivePDA(
[Buffer.from('ofac-oracle')],
ORACLE_AGGREGATOR_PROGRAM_ID,
);
// AMLOracle (all modules, per wallet)
const [amlOracle] = derivePDA(
[Buffer.from('aml-oracle'), wallet.toBuffer()],
ORACLE_AGGREGATOR_PROGRAM_ID,
);
// NAVOracle (Module 2 only)
const [navOracle] = derivePDA(
[Buffer.from('nav-oracle'), mint.toBuffer()],
ORACLE_AGGREGATOR_PROGRAM_ID,
);
// ClassificationOracle (Module 3 only)
const [classificationOracle] = derivePDA(
[Buffer.from('classification-oracle'), mint.toBuffer()],
ORACLE_AGGREGATOR_PROGRAM_ID,
);
// Pool (per-mint AMM pool)
const [pool] = derivePDA(
[Buffer.from('pool'), mint.toBuffer()],
AMM_PROGRAM_ID,
);
// GlobalPool (singleton)
const [globalPool] = derivePDA(
[Buffer.from('global-pool')],
LIQUIDITY_POOL_PROGRAM_ID,
);
```
**Oracle Relay Service Endpoints**
ServiceInternal EndpointHealth CheckModule Scope
Custody Relay
`custody-relay:3001`
`GET /health`
All modules
OFAC Indexer
`ofac-indexer:3002`
`GET /health`
All modules
AML Bridge
`aml-bridge:3003`
`GET /health`
All modules
TWAP Consumer
`twap-consumer:3004`
`GET /health`
All modules
EDGAR Pipeline
`edgar-pipeline:3005`
`GET /health`
Module 1 (Equities)
NAV Relay
`nav-relay:3006`
`GET /health`
Module 2 (Real Estate)
Classification Relay
`classification-relay:3007`
`GET /health`
Module 3 (CORECM)
**Oracle External Data Sources**
OracleExternal APIAuthenticationRate Limit
**Empire Custody**
`https://api.empirestocktransfer.com/v1/custody`
API key plus IP whitelist
Per-block (\~400ms)
**OFAC / SDN**
`https://api.treasury.gov/ofac/sdn`
None (public)
Hourly refresh
**Chainalysis KYT**
`https://api.chainalysis.com/v2/kyt`
API key
Per-transfer
**TRM Labs**
`https://api.trmlabs.com/v1/risk`
API key
Per-transfer
**Pyth Network**
On-chain (Solana native)
None
Sub-second
**SEC EDGAR RSS**
`https://www.sec.gov/cgi-bin/browse-edgar?RSS`
None (public)
60-second polling
**SEC EDGAR EFTS**
`https://efts.sec.gov/LATEST/search-index`
None (public)
Daily batch
**NAV Appraiser API (Module 2)**
Per-property licensed appraiser endpoints
API key plus mTLS
Reappraisal-cycle cadence
**USGS Critical Minerals (Module 3)**
`https://mrdata.usgs.gov/critical-minerals`
None (public)
Daily plus emergency on EO update
**DOE Critical Materials (Module 3)**
`https://www.energy.gov/eere/critical-materials`
None (public)
Daily plus emergency on policy update
***
#### 4. Multi-Signature Wallets
**Mainnet Multi-Signature Addresses**
Multi-SignatureAddressThresholdSignersPurpose
**Upgrade Authority (5-of-9)**
``
5 of 9
Geographically distributed
Transfer Hook, AMM, Oracle program upgrades
**Parameter Authority (3-of-5)**
``
3 of 5
—
Fee, threshold, cooldown adjustments
**Emergency Authority (3-of-5 plus Legal)**
``
3 of 5 plus Legal Counsel
—
Control 42 regulatory freeze
**Timelock Configuration**
AuthorityTimelockCancellation
5-of-9 (upgrade)
24 hours
2-of-5 during window
3-of-5 (parameter)
48 hours
2-of-5 during window
Emergency (Control 42)
**None — immediate**
N/A
**Signer Distribution**
SignerJurisdictionKey StorageBackup
1
US East
Ledger Enterprise HSM
Encrypted cold backup
2
US West
Ledger Enterprise HSM
Encrypted cold backup
3
EU
Ledger Enterprise HSM
Encrypted cold backup
4
APAC
Ledger Enterprise HSM
Encrypted cold backup
5
US Central
Ledger Enterprise HSM
Encrypted cold backup
6–9
Distributed
Ledger Enterprise HSM
Encrypted cold backup
No signer holds more than one signing position in any quorum. Key rotation follows the same multi-signature threshold as the actions the keys authorize.
***
#### 5. Global Pool Accounts
**Mainnet**
AccountAddressPurpose
**GlobalPool PDA**
Derived: `[b"global-pool"]`
Pool state account
**SOL Vault**
``
SOL reserve (permanently locked)
**LP Mint**
``
LP mint (supply = 0, burned)
**Pool Properties**
PropertyValueVerifiable?
LP supply
0 (burned at initialization)
`solana account --output json | jq '.data.parsed.info.supply'`
LP mint authority
None
`solana account --output json | jq '.data.parsed.info.mintAuthority'`
Pool program upgrade authority
None (immutable)
`solana program show | grep Authority`
Withdrawal function
Does not exist in bytecode
Certora invariant E.3
***
#### 6. Production Parameters
**Transfer Hook Parameters**
ParameterValueGovernance RangeImmutable?
`max_wallet_percent`
499 (4.99%)
100–999 (1%–9.99%)
No
`circuit_breaker_threshold`
3000 (30%)
1000–5000 (10%–50%)
No
`circuit_breaker_cooldown`
86,400 sec (24h)
3,600–259,200 (1h–72h)
No
`price_impact_max_bps`
200 (2%)
100–500 (1%–5%)
No
`twap_window_secs`
1,800 (30 min)
900–3,600 (15min–1h)
No
`twap_min_observations`
60
—
**Yes**
`outlier_rejection_sigma`
3
—
**Yes**
`holding_period_rule_144`
15,778,800 sec (6 months)
—
**Yes**
`holding_period_reg_s`
31,536,000 sec (12 months)
—
**Yes**
**Module 2 NAV Parameters (Real Estate)**
ParameterValueGovernance RangeImmutable?
`nav_deviation_max_bps`
Per-property
200–2000 (2%–20%)
No
`nav_reappraisal_max_age_secs`
Per-property
Per offering documentation
No
`nav_circuit_breaker_enabled`
True
—
**Yes**
**Module 3 CORECM Parameters**
ParameterValueGovernance RangeImmutable?
`classification_max_age_secs`
86,400 (24h)
21,600–172,800 (6h–48h)
No
`federal_action_freeze_enabled`
True
—
**Yes**
**Fee Configuration**
ParameterValue (BPS)Percentage
`total_fee`
500
5.00%
`pool_fee`
44
0.44%
`issuer_fee`
200
2.00%
`staking_fee`
150
1.50%
`protocol_fee`
106
1.06%
**Invariant:** `pool_fee + issuer_fee + staking_fee + protocol_fee == total_fee`
**Oracle Staleness Thresholds**
OracleCache ValidWarningHalt
Custody
1 slot (\~400ms)
\>3 slots
\>1 slot (Error 6002)
OFAC
24 hours
\>12 hours
\>48 hours (Error 6005)
AML
6 hours
\>3 hours
No score available (Error 6006)
TWAP
5 minutes
\>2 minutes
\>5 minutes (breaker disabled)
EDGAR
36 hours
\>24 hours
No halt (continue with last batch)
NAV (Module 2)
Per-property
Half of `nav_reappraisal_max_age_secs`
Beyond `nav_reappraisal_max_age_secs` (mint paused)
Classification (Module 3)
24 hours
\>12 hours
\>48 hours (enhanced review on transfers)
**Circuit Breaker Parameters**
BreakerTriggerResponseCooldown
Price halt
\>10% move in 5 minutes
15-minute trading halt
Automatic on TWAP normalization
Price impact
\>2% single-trade impact vs TWAP
Block trade (Error 6021)
Immediate (per-trade)
Volume halt
\>30% daily sell by single wallet
24-hour wallet halt
24 hours
Oracle failure (custody)
Custody stale >1 slot
Halt ALL transfers
Until oracle restored
NAV deviation (Module 2)
On-chain price outside `nav_deviation_max_bps` of NAV
Halt affected mint
Until next reappraisal cycle
**AML Risk Thresholds**
Score RangeDispositionAction
0–30
Approve
Transfer proceeds
31–70
Enhanced review
Transfer proceeds, flagged for 24h compliance review
71–100
Reject
Transfer rejected (Error 6006)
***
#### 7. SDK Configuration
**Mainnet**
Copy
```
import { RwaTokensClient } from '@rwatokens/sdk';
const client = new RwaTokensClient({
network: 'mainnet-beta',
rpcEndpoint: 'https://mainnet.helius-rpc.com/?api-key=YOUR_KEY',
wsEndpoint: 'wss://mainnet.helius-rpc.com/?api-key=YOUR_KEY',
commitment: 'confirmed',
jitoEnabled: true,
priorityFee: 'auto',
maxRetries: 3,
timeoutMs: 30_000,
});
```
**Devnet**
Copy
```
const client = new RwaTokensClient({
network: 'devnet',
rpcEndpoint: 'https://devnet.helius-rpc.com/?api-key=YOUR_KEY',
commitment: 'confirmed',
jitoEnabled: false,
priorityFee: 'none',
});
```
**Localnet**
Copy
```
const client = new RwaTokensClient({
network: 'localnet',
rpcEndpoint: 'http://localhost:8899',
});
```
***
#### 8. Environment Variables
**Production (.env.mainnet)**
Copy
```
# ── Network ──────────────────────────────────────────
SOLANA_CLUSTER=mainnet-beta
RPC_ENDPOINT=https://mainnet.helius-rpc.com/?api-key=
WS_ENDPOINT=wss://mainnet.helius-rpc.com/?api-key=
FALLBACK_RPC=https://.rpcpool.com
# ── MEV Protection ───────────────────────────────────
JITO_ENABLED=true
JITO_BLOCK_ENGINE=https://mainnet.block-engine.jito.wtf
JITO_TIP_ACCOUNT=
# ── Program IDs ──────────────────────────────────────
HOOK_PROGRAM_ID=
AMM_PROGRAM_ID=
POOL_PROGRAM_ID=
GOV_PROGRAM_ID=
ORACLE_PROGRAM_ID=
# ── Oracle APIs (All Modules) ────────────────────────
EMPIRE_API_ENDPOINT=https://api.empirestocktransfer.com/v1
EMPIRE_ED25519_PUBKEY=
OFAC_API_ENDPOINT=https://api.treasury.gov/ofac/sdn
CHAINALYSIS_API_KEY=
TRM_API_KEY=
PYTH_PRICE_FEED_ID=
# ── Module 2 NAV ─────────────────────────────────────
NAV_APPRAISER_API_BASE=
NAV_APPRAISER_API_KEY=
# ── Module 3 Federal Classification ──────────────────
USGS_API_ENDPOINT=https://mrdata.usgs.gov/critical-minerals
DOE_API_ENDPOINT=https://www.energy.gov/eere/critical-materials
# ── CEDEX API ────────────────────────────────────────
CEDEX_API_BASE=https://api.cedex.market/v1
CEDEX_WS_BASE=wss://api.cedex.market/ws/v1
# ── Monitoring ───────────────────────────────────────
DATADOG_API_KEY=
PAGERDUTY_ROUTING_KEY=
LOG_LEVEL=info
# ── Multi-Signature ──────────────────────────────────
UPGRADE_MULTISIG=<5_OF_9_ADDRESS>
PARAM_MULTISIG=<3_OF_5_ADDRESS>
EMERGENCY_MULTISIG=<3_OF_5_ADDRESS>
```
**Development (.env.devnet)**
Copy
```
SOLANA_CLUSTER=devnet
RPC_ENDPOINT=https://devnet.helius-rpc.com/?api-key=
FALLBACK_RPC=https://api.devnet.solana.com
JITO_ENABLED=false
HOOK_PROGRAM_ID=
AMM_PROGRAM_ID=
POOL_PROGRAM_ID=
GOV_PROGRAM_ID=
ORACLE_PROGRAM_ID=
# Devnet uses simulated oracle data
EMPIRE_API_ENDPOINT=https://api.devnet.rwatokens.net/mock-empire
CHAINALYSIS_API_KEY=devnet-test-key
TRM_API_KEY=devnet-test-key
NAV_APPRAISER_API_BASE=https://api.devnet.rwatokens.net/mock-nav
USGS_API_ENDPOINT=https://api.devnet.rwatokens.net/mock-usgs
DOE_API_ENDPOINT=https://api.devnet.rwatokens.net/mock-doe
CEDEX_API_BASE=https://api.devnet.cedex.market/v1
LOG_LEVEL=debug
```
**Local (.env.local)**
Copy
```
SOLANA_CLUSTER=localnet
RPC_ENDPOINT=http://localhost:8899
JITO_ENABLED=false
# Local programs deployed by `anchor deploy`
HOOK_PROGRAM_ID=
AMM_PROGRAM_ID=
POOL_PROGRAM_ID=
GOV_PROGRAM_ID=
ORACLE_PROGRAM_ID=
LOG_LEVEL=debug
```
***
#### 9. Token-2022 Program Reference
**Key Addresses**
ComponentAddress
Token-2022 Program
`TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb`
Associated Token Program
`ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL`
**ST22 Mint Extensions**
Every ST22 mint — across all three modules — is created with these Token-2022 extensions:
ExtensionPurposePermanent?
**Transfer Hook**
Points to the platform's Transfer Hook program — 42 controls on every transfer
**Yes — cannot be removed**
**Metadata**
On-chain: issuer or property or basin name, symbol, classification (CUSIP for Module 1; property identifier for Module 2; USGS classification for Module 3)
Yes
**Transfer Fee**
5% protocol fee enforced at token program level
Yes
**Permanent Delegate**
Empire Stock Transfer — emergency freeze capability
Yes
**Verifying a Mint's Extensions**
Copy
```
# Get all extensions for an ST22 mint
solana account --output json | \
jq '.data.parsed.info.extensions'
# Expected output includes:
# - transferHook: { programId: "" }
# - transferFeeConfig: { ... }
# - metadata: { name, symbol, uri }
```
**Settlement Tokens**
StablecoinMint Address (Mainnet)ProgramDecimals
**USDC** (Circle)
`EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v`
SPL Token
6
**PYUSD** (PayPal/Paxos)
`2b1kV6DkPAnxd5ixfnxCpjxmKwqjjaYmCZfHsFu24GXo`
SPL Token
6
All ST22 settlement across Modules 1, 2, and 3 occurs in USDC or PYUSD pursuant to the GENIUS Act framework.
***
#### 10. Verification Commands
**Verify Program Deployment**
Copy
```
# Check all 5 programs are deployed
for PROG in $HOOK_PROGRAM_ID $AMM_PROGRAM_ID $POOL_PROGRAM_ID $GOV_PROGRAM_ID $ORACLE_PROGRAM_ID; do
echo "$(solana program show $PROG 2>&1 | head -1)"
done
```
**Verify Upgrade Authorities**
Copy
```
# Transfer Hook — should be 5-of-9 multi-signature
solana program show $HOOK_PROGRAM_ID | grep "Authority"
# AMM — should be 5-of-9 multi-signature
solana program show $AMM_PROGRAM_ID | grep "Authority"
# Liquidity Pool — should be "none" (IMMUTABLE)
solana program show $POOL_PROGRAM_ID | grep "Authority"
# Governance — should be 3-of-5 multi-signature
solana program show $GOV_PROGRAM_ID | grep "Authority"
# Oracle — should be 5-of-9 multi-signature
solana program show $ORACLE_PROGRAM_ID | grep "Authority"
```
**Verify Transfer Hook on Mint**
Copy
```
# Confirm hook is attached and points to the platform's Transfer Hook program
solana account --output json | \
jq '.data.parsed.info.extensions[] | select(.extension == "transferHook")'
# Expected: { "extension": "transferHook", "state": { "programId": "" } }
```
**Verify Oracle Health**
Copy
```
# Custody oracle freshness (all modules)
curl -s https://api.cedex.market/v1/oracle//custody | jq '{
ratio: .ratio,
ed25519_verified: .ed25519_verified,
slot_age: .slot_age,
discrepancy: .discrepancy_detected
}'
# OFAC oracle status (all modules)
curl -s https://api.cedex.market/v1/oracle/ofac/status | jq '{
is_fresh: .is_fresh,
entry_count: .entry_count,
last_refresh: .last_refresh
}'
# NAV oracle status (Module 2)
curl -s https://api.cedex.market/v1/oracle//nav | jq '{
current_nav: .current_nav,
on_chain_price: .on_chain_price,
deviation_bps: .deviation_bps,
last_reappraisal: .last_reappraisal,
next_reappraisal: .next_reappraisal
}'
# Classification oracle status (Module 3)
curl -s https://api.cedex.market/v1/oracle//classification | jq '{
usgs_class: .usgs_class,
doe_status: .doe_status,
federal_action_status: .federal_action_status,
last_refresh: .last_refresh
}'
# Full system health
curl -s https://api.cedex.market/v1/health | jq '.oracle_status'
```
**Verify Global Pool**
Copy
```
# LP supply must be 0 (burned)
spl-token supply --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb
# Pool program must have no upgrade authority
solana program show $POOL_PROGRAM_ID | grep "Authority"
# Expected: "Authority: none"
```
**Verify SecurityConfig Parameters**
Copy
```
# Read SecurityConfig for a specific mint
anchor account transfer_hook SecurityConfig \
--provider.cluster mainnet | jq '{
max_wallet_percent: .maxWalletPercent,
price_impact_max_bps: .priceImpactMaxBps,
circuit_breaker_threshold: .circuitBreakerThreshold,
holding_period_enabled: .holdingPeriodConfig.enabled,
is_paused: .isPaused
}'
```
**Quick Health Check Script**
Copy
```
#!/bin/bash
# scripts/quick-health.sh — run from any machine with curl + jq
API="https://api.cedex.market/v1"
echo "=== Platform Health Check ==="
echo ""
# System health
HEALTH=$(curl -s "$API/health")
echo "Status: $(echo $HEALTH | jq -r '.status')"
echo "Version: $(echo $HEALTH | jq -r '.version')"
echo "Solana slot: $(echo $HEALTH | jq -r '.solana_slot')"
echo "MEV protection: $(echo $HEALTH | jq -r '.mev_protection')"
echo ""
# Oracle status
echo "--- Oracles ---"
echo "Custody: $(echo $HEALTH | jq -r '.oracle_status.custody')"
echo "OFAC: $(echo $HEALTH | jq -r '.oracle_status.ofac')"
echo "AML: $(echo $HEALTH | jq -r '.oracle_status.aml')"
echo "TWAP: $(echo $HEALTH | jq -r '.oracle_status.twap')"
echo "EDGAR: $(echo $HEALTH | jq -r '.oracle_status.edgar')"
echo "NAV (Mod 2): $(echo $HEALTH | jq -r '.oracle_status.nav')"
echo "Class (Mod 3): $(echo $HEALTH | jq -r '.oracle_status.classification')"
echo ""
# Circuit breaker
echo "Circuit breaker (global): $(echo $HEALTH | jq -r '.circuit_breaker_global')"
echo ""
echo "=== Done ==="
```
***
#### Related Documentation
* **Solana Blockchain Foundation** — Why Solana, Token-2022, Transfer Hook, module-specific foundations
* **Architecture Decisions** — ADR-001 through ADR-012 with full alternatives analysis
* **Security Model** — Threat model, key management, formal verification, module-specific threat surfaces
* **Infrastructure Overview** — Cloud architecture, environment separation, blockchain infrastructure, module-specific considerations
* **Deployment Guide** — How to deploy and initialize all programs
* **Oracle Integration Guide** — Oracle relay service configuration, fail-safe cascade, module-specific oracles
* **SDK Reference** — SDK initialization using these endpoints
* **Smart Contract Reference** — Program instruction specifications
***
*RWA Tokens · Network Configuration · Groovy Company, Inc.*
# Deployment Guide
### Deployment Guide
**Build · Deploy · Verify · Monitor · Upgrade · Roll Back**
Procedural reference for building, deploying, and verifying all platform on-chain programs across local, devnet, and mainnet environments. This guide is the authoritative procedure document for the operations team executing deployments and for auditors reviewing the deployment process.
The platform is operated by Groovy Company, Inc. The trading venue is CEDEX. The qualified-custody and onboarding anchor is Empire Stock Transfer. Production deployments support all three production modules: Equities (Module 1), Real Estate (Module 2), and CORECM — Carbon Ore, Rare Earth, and Critical Minerals (Module 3).
> This document describes **what** must happen in each deployment phase, **why** each step is required, and **how each step is verified**. Specific commands, code, and configuration files are maintained in the platform's internal operations runbooks and are available to authorized operators and auditors under non-disclosure agreement.
***
#### Table of Contents
1. Prerequisites and Approvals
2. Repository Structure
3. Local Development Setup
4. Building
5. Testing
6. Devnet Deployment
7. Mainnet Deployment
8. Post-Deployment Initialization
9. Module-Specific Initialization
10. Verification Procedures
11. Monitoring Setup
12. Upgrade Procedures
13. Rollback and Emergency Halt
14. What Cannot Be Rolled Back
15. Roles and Approvals
***
#### 1. Prerequisites and Approvals
**Required Toolchain**
The platform programs are built on the Solana toolchain. Operators must have the following installed and version-aligned with the platform's published toolchain manifest:
ToolPurpose
Rust
Smart-contract compilation
Solana CLI
Cluster interaction, key management
Anchor
Build, test, and deployment framework
Node.js
SDK, scripts, integration tests
Yarn
Package management
jq
JSON parsing in verification scripts
Exact version requirements are maintained in the repository's toolchain manifest and operations runbook. Version mismatches are the single most common source of build determinism issues; auditors verify the toolchain version before reproducing any build.
**Hardware Requirements**
EnvironmentProfile
Local development
Standard developer workstation, sufficient RAM and SSD for Rust compilation
Devnet deployment
Equivalent to local development
Mainnet deployment
Workstation with redundant connectivity and access to the deployer Ledger device
**Key Requirements**
OperationKey TypeStorage
Local testing
File system keypair
Local development directory
Devnet deployment
File system keypair, funded via airdrop
Operator's development directory
Mainnet deployment
Ledger hardware wallet
Physical Ledger device, operator-controlled
Program upgrade
5-of-9 multi-signature
Distributed Ledger Enterprise HSMs
**Required Approvals Before Mainnet**
Mainnet deployment cannot proceed without all of the following:
* All unit, integration, fuzz, and end-to-end tests passing.
* Certora formal verification: all six invariants verified.
* Independent audits (Quantstamp, Halborn, OtterSec): zero Critical or High findings.
* Build hash matches the audited source.
* Devnet deployment validated for at least seven days under representative load.
* Multi-signature wallets configured (5-of-9 for upgrades, 3-of-5 for parameters and emergency).
* Timelock program deployed and tested.
* Oracle relay infrastructure tested across all module-specific oracles.
* Empire Stock Transfer integration verified.
* Helius dedicated RPC cluster provisioned. Triton fallback configured.
* Datadog monitoring dashboards created. PagerDuty escalation policies configured.
* Incident Response Playbook reviewed. Tabletop exercise completed within the prior quarter.
* Legal Counsel sign-off on deployment.
* CTO sign-off on deployment.
***
#### 2. Repository Structure
The platform's monorepo contains five on-chain programs, the SDK, integration tests, deployment and initialization scripts, formal-verification specifications, and published audit reports.
Top-Level ComponentPurpose
Anchor and Cargo workspace configuration
Build orchestration
Programs directory
Five on-chain programs (Transfer Hook, AMM, Liquidity Pool, Governance, Oracle Aggregator)
Tests directory
Unit, integration, and end-to-end test suites
SDK directory
TypeScript SDK package consumed by CEDEX backend and external integrators
Scripts directory
Deployment, initialization, verification, and monitoring-setup scripts
Migrations directory
Anchor migration scripts for ordered program deployment
Specs directory
Certora formal-verification specifications corresponding to the six published invariants
Audits directory
Published audit reports from Quantstamp, Halborn, OtterSec, and Certora
The five on-chain programs are deployed in dependency order: Transfer Hook (no dependencies) → Oracle Aggregator → Liquidity Pool → AMM → Governance.
***
#### 3. Local Development Setup
Local development uses a Solana test validator running on the operator's workstation, configured to load the SPL Token-2022 program from the official binary. This allows full integration testing of the Transfer Hook and Token-2022 interaction without devnet or mainnet exposure.
The local setup procedure is:
1. Clone the platform repository from the internal GitLab instance.
2. Install Node.js dependencies and run the Anchor build to produce program binaries and IDL files.
3. Configure the Solana CLI to point at the local validator.
4. Generate or import a local keypair for development use only — local keypairs must never be reused for devnet or mainnet operations.
5. Start the local Solana test validator with the SPL Token-2022 program loaded.
6. Deploy the platform's five programs to the local validator.
7. Run the full integration test suite to verify the local deployment is functional.
Local deployment is intentionally low-friction. Failure here typically indicates a toolchain version mismatch.
***
#### 4. Building
**Full Build**
A full Anchor build produces five program binaries (one per platform program) and five corresponding IDL files. Build outputs are placed in the standard Anchor `target` directory.
**Build Determinism**
Reproducible builds are required so that auditors can verify that the bytecode deployed on chain matches the audited source. Every release is accompanied by a published SHA-256 hash for each program binary. Auditors and institutional reviewers reproduce the build and verify the hash matches.
Build determinism depends on the toolchain version. Operators must use the exact Rust, Solana CLI, and Anchor versions specified in the toolchain manifest at the time of the audited release.
**Per-Program Builds**
Individual programs can be built without rebuilding the entire workspace. This is useful during development and during upgrade preparation, when only one program is being modified. Per-program builds use the same toolchain and produce the same deterministic output as full builds.
**IDL Verification**
After build, the generated IDL is compared against a freshly parsed IDL derived from the source files. Any difference indicates a stale build cache or an inconsistency between source and generated artifacts; the build is rejected until reconciled.
***
#### 5. Testing
**Test Categories**
CategoryPurposeRequired Pass Rate
Rust unit tests
Per-function correctness within Rust modules
100%
Anchor integration tests
Cross-program behavior on a local validator
100%
Boundary tests
Behavior at exact thresholds (4.99% wallet, 30% breaker, holding-period elapsed)
100%
Fuzz tests
Adversarial inputs across the Transfer Hook and AMM arithmetic
100,000+ runs with zero crashes
Certora formal verification
Symbolic proof of the six invariants
All six invariants must pass
End-to-end tests
Full lifecycle from mint creation through trading to fee distribution
100%
Coverage
Aggregate test coverage of the program codebases
Transfer Hook control logic and CPMM arithmetic at 100%; oracle and governance at 95% or higher
**Key Test Scenarios**
ScenarioWhat It Verifies
All 42 controls pass on a valid transfer
Successful transfer when every control's preconditions are met
Each control rejects individually when its precondition is violated
Specific error code (6001 through 6042) returned by the right control
Wallet limit boundary at 4.99% versus 5.00%
Control 15 rejects exactly at 5.00% and accepts at 4.99%
Circuit breaker boundary at 30%
Control 20 triggers at threshold and passes below
Holding period: locked versus unlocked
Control 24 rejects before elapsed and accepts after
CPMM u128 arithmetic
Maximum-value inputs do not overflow
CPMM fee accuracy
Fee within 1 lamport of expected value
Global Pool non-extractability
No instruction in any program reduces pool balance
Full lifecycle
Mint creation → offer → hold → unlock → trade → fee distribution all succeed
Circuit breaker recovery
Trigger → halt → cooldown → automatic resume
**Formal Verification**
The platform's six Certora invariants — E.1 (no unauthorized minting), E.2 (custody ratio), E.3 (pool non-extractability), E.4 (hook completeness), E.5 (fee accuracy), E.6 (circuit breaker correctness) — must all pass on every release before deployment. The Certora run is gated in CI: any specification failure blocks the release.
The full invariant set is documented in the Security Model.
***
#### 6. Devnet Deployment
Devnet deployment is the operator's first opportunity to validate behavior on a real Solana cluster with mock module-specific oracle feeds. Devnet deployments use a file-system deployer keypair funded via airdrop.
**Procedure**
1. Configure the Solana CLI to target devnet.
2. Generate or load the devnet deployer keypair. Devnet deployer keypairs are isolated from mainnet keys.
3. Fund the deployer with a minimum of 5 SOL via airdrop (more if multiple deployment cycles are anticipated).
4. Update the Anchor configuration with the devnet program IDs.
5. Deploy all five programs in dependency order.
6. Record the deployed program IDs in the operations runbook and update the Network Configuration page.
7. Run the automated post-deployment verification script.
**Devnet Validation Period**
Devnet deployments must run for at least seven days under representative load before mainnet deployment is approved. This validation period exercises:
* Custody oracle freshness over many block cycles.
* OFAC and AML oracle staleness handling.
* Circuit breaker triggering and automatic recovery.
* Module 2 NAV oracle reappraisal cycle handling.
* Module 3 Classification oracle refresh handling.
* End-to-end trading paths under mock load.
***
#### 7. Mainnet Deployment
Mainnet deployment is irreversible in the most important sense: although programs are upgradeable (except the Liquidity Pool), every transfer the platform processes after deployment is permanent on the Solana ledger.
**Pre-Deployment Verification**
Before mainnet deployment, the operator confirms every item in Section 1's "Required Approvals Before Mainnet" list. Deployment cannot proceed if any item is incomplete.
**Hardware-Wallet Requirement**
Mainnet deployment uses a Ledger hardware wallet — never a file-system keypair. The Ledger device is held by the deploying operator under documented chain-of-custody procedures. The operator's identity is logged in the operations runbook for each deployment.
**Deployment Sequence**
Programs must be deployed in this exact order, because of cross-program dependencies:
1. **Transfer Hook** — foundation; no dependencies.
2. **Oracle Aggregator** — Transfer Hook reads oracle accounts.
3. **Liquidity Pool** — AMM deposits fees here.
4. **AMM** — depends on Transfer Hook, Oracle Aggregator, and Liquidity Pool.
5. **Governance** — can modify parameters on all of the above.
After all five programs are deployed, the operator records the mainnet program IDs in the operations runbook and proceeds to upgrade-authority transfer.
**Upgrade-Authority Transfer**
Immediately after deployment, upgrade authority is transferred from the deployer to the appropriate multi-signature wallet. This is the most security-sensitive moment in the entire deployment process — until this transfer is complete, the deployer keypair has unilateral upgrade authority over every program except the Liquidity Pool.
ProgramFinal Upgrade Authority
Transfer Hook
5-of-9 multi-signature
AMM
5-of-9 multi-signature
Oracle Aggregator
5-of-9 multi-signature
Governance
3-of-5 multi-signature
Liquidity Pool
**None — upgrade authority is permanently removed**
The Liquidity Pool program's upgrade authority is removed via the Solana CLI's `--final` flag. **This action is irreversible.** Once complete, the Liquidity Pool program is permanently immutable. No combination of keys, votes, or legal orders can ever modify it. This is the structural foundation of the Global Pool non-extractability guarantee (Certora invariant E.3).
The CTO confirms each upgrade-authority transfer in the operations runbook before the next program is processed.
***
#### 8. Post-Deployment Initialization
Once programs are deployed and upgrade authorities are transferred, the operator initializes the system accounts. These initializations are also irreversible in important respects.
**8.1 Initialize Global Pool**
One-time initialization. Seeds the Global Unified CEDEX Liquidity Pool with the platform's initial SOL allocation. **Initialization burns LP tokens — no withdrawal function exists in the program code.**
After initialization, the operator verifies that:
* Global Pool state account is created.
* LP mint supply is exactly zero (burned).
* LP mint authority is `None`.
* Pool program has no upgrade authority.
If any of these verifications fails, deployment must halt and the issue must be resolved before any other initialization proceeds.
**8.2 Initialize Oracle Accounts**
Creates the OFAC oracle (a global singleton serving all modules), sets initial staleness thresholds, and registers Empire Stock Transfer's Ed25519 public key for custody-attestation verification.
After initialization, the operator verifies:
* OFAC oracle PDA exists and is populated.
* Empire's public key is correctly registered.
* Staleness thresholds match the values specified in the Network Configuration document.
**8.3 Start Oracle Relay Services**
Bring oracle relay services online in this order:
1. Empire custody relay (highest priority — produces per-block attestations).
2. OFAC indexer.
3. AML bridge (Chainalysis plus TRM Labs).
4. TWAP consumer (reads Pyth Network).
5. EDGAR pipeline (Module 1 issuer-disclosure intelligence).
6. NAV relay (Module 2 — see Section 9.2).
7. Classification relay (Module 3 — see Section 9.3).
Each service is verified healthy before the next is started. The custody relay is verified posting attestations within the first three Solana blocks; failure here halts the deployment.
***
#### 9. Module-Specific Initialization
Each module has additional initialization steps beyond the cross-module foundation. Module-specific initialization is performed per issuance, not per module — every new mint requires the appropriate module-specific oracle and configuration.
**9.1 Module 1 — Equities Mint Initialization**
For each new equity issuer onboarded by Empire Stock Transfer:
1. **Empire onboarding.** Empire Stock Transfer completes issuer-side KYC, KYB, accreditation, and Common Class B custody-deposit confirmation before any on-chain action.
2. **Mint creation.** Operator creates the ST22 mint with the Transfer Hook extension permanently attached, the Metadata extension populated with issuer name, symbol, and CUSIP, the Transfer Fee extension set to 5%, and the Permanent Delegate extension set to Empire's authority.
3. **SecurityConfig PDA initialization.** Per-mint compliance parameters are set: 4.99% wallet limit, 30% circuit breaker, 2% price-impact cap, 30-minute TWAP window, holding-period configuration matching the offering exemption (Reg D, Reg S, or Reg CF).
4. **ExtraAccountMetaList PDA initialization.** Token-2022 hook account-resolution list is populated.
5. **CustodyOracle PDA initialization.** Empire's public key is registered for this mint's per-block custody attestations.
6. **CEDEX trading pool initialization.** After Empire confirms backing collateral is in custody, the AMM pool for this mint is initialized and seeded.
The Transfer Hook attachment and Permanent Delegate assignment are permanent and irreversible.
**9.2 Module 2 — Real Estate Mint Initialization**
Module 2 adds NAV oracle initialization and reappraisal-cycle configuration to the standard mint procedure. For each new real-estate property:
1. **Property due diligence.** Pre-issuance title search, jurisdictional review, transfer-tax review, and physical inspection completed by the issuer's professional service providers. Empire Stock Transfer reviews the diligence package.
2. **Single-asset entity confirmation.** The legal entity holding the property is confirmed in good standing in its jurisdiction of formation. The entity's structure permits Common Class B issuance with the Certificate of Designation filed with the appropriate Secretary of State.
3. **Initial appraisal.** An independent licensed appraiser produces the initial Net Asset Value appraisal. The appraisal is signed and submitted to Empire.
4. **Empire onboarding.** As with Module 1, Empire completes issuer-side KYC, KYB, and Common Class B custody-deposit confirmation.
5. **Mint creation.** Same procedure as Module 1, with the Metadata extension populated with property identifier, jurisdiction, appraisal-cycle tag, and NAV reference.
6. **SecurityConfig PDA initialization.** Standard parameters plus Module 2-specific values: NAV deviation maximum (in basis points), reappraisal maximum age, and the NAV-circuit-breaker enabled flag.
7. **NAVOracle PDA initialization.** Per-mint NAV oracle account created. The appraiser's authentication credentials and reappraisal-cycle cadence are registered.
8. **CustodyOracle, ExtraAccountMetaList, and trading pool initialization.** Same as Module 1.
The NAV reappraisal cadence is per-property and is set in the offering documentation. Common cadences are quarterly and semi-annually depending on property type.
**9.3 Module 3 — CORECM Mint Initialization**
Module 3 adds federal-classification oracle initialization and enhanced regulatory verification. For each new basin asset:
1. **Geological and regulatory diligence.** Independent geological survey of proven reserves. Verification of the basin's classification on the United States Geological Survey Critical Minerals List and the Department of Energy Critical Materials Strategy. Confirmation of the basin's status under Section 232 of the Trade Expansion Act of 1962, Title III of the Defense Production Act, the Inflation Reduction Act critical-minerals provisions, Executive Order 14017, and the Energy Act of 2020.
2. **Basin-asset entity confirmation.** The legal entity holding the basin or mining concession is in good standing. Mineral rights, surface rights, and any applicable federal program participation (such as Department of Energy coal-derived rare-earth element recovery) are documented.
3. **Empire enhanced onboarding.** Empire Stock Transfer applies enhanced KYC depth for Module 3 issuances, including verification of any federal program eligibility constraints applicable to the basin.
4. **Mint creation.** Same procedure as Module 1, with the Metadata extension populated with basin identifier, USGS classification, jurisdiction, and mineral-class tag.
5. **SecurityConfig PDA initialization.** Standard parameters plus Module 3-specific values: classification maximum age (24 hours by default) and the federal-action-freeze enabled flag.
6. **ClassificationOracle PDA initialization.** Per-mint classification oracle account created. USGS and DOE feed sources are registered. Initial classification is recorded.
7. **CustodyOracle, ExtraAccountMetaList, and trading pool initialization.** Same as Module 1.
If a basin asset participates in a federal program (such as DOE coal-derived rare-earth element recovery), the program's eligibility and reporting obligations are documented in the offering disclosure and reflected in the ClassificationOracle initial state.
***
#### 10. Verification Procedures
After every deployment — devnet or mainnet — the operator runs an automated verification script and confirms each result against the expected baseline.
**Verification Categories**
CategoryWhat Is Verified
Program deployment
All five programs are present on the target cluster
Upgrade authorities
Each program's upgrade authority matches the expected multi-signature address (or `None` for the Liquidity Pool)
Transfer Hook attachment
Each ST22 mint has the Transfer Hook extension pointing to the correct program
SecurityConfig parameters
Per-mint parameters match the expected values for the issuance's module
Custody Oracle freshness
Oracle is updating within one to two slots of the current Solana slot
Module 2 NAV oracle (per Module 2 mint)
NAV oracle has a valid initial appraisal and the next-reappraisal timestamp is set
Module 3 Classification oracle (per Module 3 mint)
Classification oracle has a valid initial classification from USGS and DOE feeds
Global Pool LP burn
LP mint supply is zero and LP mint authority is `None`
Liquidity Pool program immutability
Pool program upgrade authority is `None`
**Failure Handling**
Any verification failure halts the deployment. The operator does not proceed to the next phase until the failure is investigated, the cause identified, and the issue resolved. For mainnet deployments, verification failures trigger a P1 incident response notification to the CTO.
***
#### 11. Monitoring Setup
**Datadog Integration**
After successful deployment and verification, monitoring is brought online before any external traffic is permitted to reach the platform. Datadog dashboards are populated with the deployed program addresses and oracle PDAs.
**Key Dashboards**
DashboardPrimary MetricsCritical Alert Threshold
Transfer Hook
Control pass/fail rate, latency per control, error code distribution
Any Error 6001 (custody) → P0
CEDEX Trading
Order volume, fill rate, pre-flight rejection rate, average latency — segmented by module
Fill rate below 90% → P1
Oracle Health
Custody freshness (slot age), OFAC staleness, AML cache age, NAV freshness (Module 2), Classification freshness (Module 3)
Custody age above 5 slots → P0
Circuit Breakers
Active breakers, trigger count, cooldown status
Any global breaker → P1
RPC Performance
Request latency, error rate, sendTransaction throughput
Latency above 500ms → P2
Global Pool
Total deposited, fee deposit count, balance
Balance decrease → P0 (Certora invariant violation)
**PagerDuty Escalation**
SeverityResponse SLAEscalation
P0
15 minutes
CTO plus Legal Counsel plus all multi-signature holders
P1
1 hour
CTO plus DevOps lead
P2
4 hours
On-call engineer
P3
24 hours
On-call engineer
**Health-Check Endpoint**
The platform exposes a public health-check endpoint that returns the status of every oracle and the global circuit breaker. Automated external monitoring polls this endpoint every 60 seconds. Any non-healthy status triggers PagerDuty escalation per the table above.
***
#### 12. Upgrade Procedures
**Parameter Adjustment**
Parameter adjustments — fee changes within governance bounds, threshold modifications, cooldown changes — follow the Parameter Authority procedure:
1. Governance proposal created (proposal type: Parameter Adjustment).
2. Voting period of at least 48 hours.
3. Simple majority required for passage.
4. 48-hour timelock after passage.
5. 3-of-5 multi-signature execution after timelock expires.
6. On-chain verification that the parameter is updated.
Parameter adjustments cannot exceed the governance ranges hard-coded in the program. For example, the wallet-limit parameter accepts values from 1.00% to 9.99%; values outside this range are rejected at the program level regardless of governance vote.
**Program Upgrade**
Program upgrades — Transfer Hook, AMM, Oracle Aggregator — follow the Upgrade Authority procedure, which is more restrictive than parameter adjustment:
1. New program version built with toolchain matching the audited release.
2. Build hash verified against the audited source.
3. Certora formal verification re-run on the new code: all six invariants must pass on the new bytecode.
4. Independent audit attestation obtained from Quantstamp or Halborn covering the upgrade scope.
5. Governance proposal created (proposal type: Program Upgrade).
6. Voting period of at least 48 hours.
7. **Two-thirds supermajority** required for passage (not simple majority).
8. 24-hour timelock after passage.
9. During the timelock, any 2-of-5 of the parameter-authority multi-signature can cancel the upgrade.
10. After timelock expiry, 5-of-9 multi-signature executes the BPF upgrade instruction.
11. On-chain verification that the program bytecode hash matches the new audited version.
**What Upgrades Cannot Do**
Even with full multi-signature authority, no upgrade can:
* Remove any of the 42 Transfer Hook controls (Certora invariant E.4 would fail).
* Lower a holding period below the statutory minimum (hard-coded constants are outside parameter space).
* Add a withdrawal function to the Global Pool (the Liquidity Pool program is immutable).
* Remove the Transfer Hook from existing mints (SPL Token-2022 standard makes hook attachment permanent).
* Bypass the multi-signature requirement (multi-signature is enforced at the Solana program level).
**Liquidity Pool Upgrades**
The Liquidity Pool program has no upgrade authority. It cannot be upgraded by any combination of keys, votes, or legal orders. This is the architectural foundation of the Global Pool non-extractability guarantee. Operators must understand that any future limitation discovered in the Liquidity Pool program cannot be patched — it can only be worked around by external programs that consume the pool's interface.
***
#### 13. Rollback and Emergency Halt
**Program Rollback**
If a deployed upgrade introduces a critical issue that is not caught during the timelock window, rollback is possible for upgradeable programs. The procedure mirrors the upgrade procedure in reverse:
1. Identify the previous program buffer address from deployment logs.
2. Coordinate the same multi-signature threshold required for an upgrade (5-of-9 for Transfer Hook, AMM, and Oracle Aggregator).
3. Deploy the previous version's buffer to the program ID.
4. Verify the rolled-back program's bytecode hash matches the previously audited version.
5. Document the rollback in the operations runbook with root cause analysis.
Rollback latency is at least 24 hours due to the standard upgrade timelock, unless the issue qualifies for emergency halt (see below) as an interim measure.
**Emergency Halt**
If immediate action is required before a rollback can be coordinated, the platform's emergency-halt mechanism (Control 42, regulatory freeze) can pause transfers on affected mints immediately. Emergency halt:
* Requires Legal Counsel authorization plus 3-of-5 multi-signature.
* Has no timelock — execution is immediate.
* Halts all transfers on the affected mint until lifted.
* Does not move tokens — it pauses, it does not redirect.
* Is logged on-chain as an immutable compliance record.
Emergency halt is the correct response to a Critical-severity incident under the Security Model's P0 procedure. Rollback follows once root cause is understood and a verified replacement is ready.
***
#### 14. What Cannot Be Rolled Back
These actions are permanent and cannot be undone by any procedure:
ActionReason
Transfer Hook attachment to a mint
SPL Token-2022 standard — hook address is permanently stored in the mint account
Global Pool LP burn
LP mint authority was set to `None` at initialization; tokens cannot be re-minted
Removal of Liquidity Pool program upgrade authority
The Solana CLI `--final` flag is permanent; the program is immutable forever
On-chain compliance audit trail
Solana ledger is immutable
Empire custody-deposit confirmation logged on-chain
Same
Operators must understand these properties before they execute the corresponding initialization steps. The platform's security guarantees rest on these irreversibilities.
***
#### 15. Roles and Approvals
RoleResponsibilitiesSign-off Required For
**Chief Technology Officer (Frank Yglesias)**
Engineering oversight; final technical sign-off on every mainnet deployment and upgrade
Mainnet deployment; program upgrades; emergency halts
**Legal Counsel (JDT Legal)**
Regulatory and legal sign-off; coordination with SEC and other regulators
Mainnet deployment; emergency halts; regulatory-freeze authorizations
**Empire Stock Transfer (Patrick Mokros, Founder)**
Custody, onboarding, and qualified-custodian functions for all modules
Custody-deposit confirmations; per-mint onboarding completion
**Multi-signature signers (5-of-9)**
Geographically distributed key holders for Transfer Hook, AMM, and Oracle Aggregator program upgrades
Program upgrades
**Multi-signature signers (3-of-5)**
Parameter authority and emergency authority signers
Parameter adjustments; emergency halts
**DevOps lead**
Infrastructure operations and monitoring
Datadog and PagerDuty configuration; oracle relay deployment
**On-call engineer**
First response for P0 through P3 incidents
Incident triage and initial containment
No single role has unilateral authority over any production action. Every mainnet operation requires at least two-party approval, and program upgrades require coordinated multi-signature execution across at least five geographically distributed signers.
***
#### Related Documentation
* **Solana Blockchain Foundation** — Why Solana, Token-2022, Transfer Hook, module-specific foundations
* **Architecture Decisions** — ADR-001 through ADR-012 with full alternatives analysis
* **Security Model** — Threat model, key management, formal verification, module-specific threat surfaces
* **Infrastructure Overview** — Cloud architecture, environment separation, blockchain infrastructure
* **Network Configuration** — Program addresses, RPC endpoints, oracle PDAs, multi-signature addresses, production parameters
* **Smart Contract Reference** — Program instruction specifications, account schemas, error codes
* **Oracle Integration Guide** — Oracle relay service architecture, fail-safe cascade, module-specific oracles
* **Testing Guide** — Detailed test procedures and coverage targets
* **Incident Response Playbook** — P0 through P3 runbooks, communication protocol
***
*RWA Tokens · Deployment Guide · Groovy Company, Inc.*
# Incident Response Playbook
### Incident Response Playbook
**Severity Classification · Escalation Paths · Runbooks · Communication · Post-Incident Review**
Operational reference for the on-call team, DevOps engineers, compliance officers, and executive leadership during production incidents. Every person on the escalation chain must have read this document before their first on-call rotation.
The platform is operated by Groovy Company, Inc. The trading venue is CEDEX. The qualified-custody and onboarding anchor is Empire Stock Transfer. Production runbooks cover all three production modules: Equities (Module 1), Real Estate (Module 2), and CORECM — Carbon Ore, Rare Earth, and Critical Minerals (Module 3).
> This document describes **what** must happen at each phase of incident response, **why** each step is required, and **how each step is verified**. Specific commands, scripts, and runbook automation are maintained in the platform's internal operations runbooks and are accessible to authorized on-call personnel under documented chain-of-custody.
> **Classification:** Internal — authorized personnel only.
***
#### Table of Contents
1. Incident Command Structure
2. Severity Classification
3. Detection and Alerting
4. General Response Procedure
5. Runbook: Custody Discrepancy (P0)
6. Runbook: Smart Contract Exploit (P0)
7. Runbook: Oracle Failure (P1/P2)
8. Runbook: Module 2 NAV Oracle Failure (P1)
9. Runbook: Module 3 Classification Oracle Failure (P2)
10. Runbook: RPC Infrastructure Degradation (P1/P2)
11. Runbook: Circuit Breaker Activation (P2)
12. Runbook: Regulatory Freeze — Control 42 (P0)
13. Runbook: Module 3 Federal-Action Freeze (P0)
14. Runbook: Key Compromise (P0)
15. Communication Protocol
16. Post-Incident Review
17. Escalation Contact Sheet
18. Tabletop Exercise Schedule
***
#### 1. Incident Command Structure
**1.1 Roles**
RolePersonResponsibility
**Incident Commander (IC)**
Chief Technology Officer (Frank Yglesias)
Full authority during declared incident. Decides severity, coordinates response, authorizes containment actions.
**Technical Lead**
On-call senior engineer
Root cause investigation, remediation execution, technical diagnostics
**Compliance Lead**
Legal Counsel (JDT Legal)
Regulatory notification decisions, SAR filing assessment, Control 42 authorization, federal-action coordination (Module 3)
**Empire Liaison**
Empire Stock Transfer (Patrick Mokros, Founder)
Empire coordination — custody issues, onboarding impacts, qualified-custodian functions
**Communications**
Designated by IC at incident declaration
External communications — status page, investor notifications, issuer notifications
**DevOps Lead**
Platform DevOps lead
Infrastructure operations, oracle relay services, monitoring
**1.2 War Room Activation**
Upon any P0 or P1 incident declaration:
1. PagerDuty fires alert to IC, Technical Lead, and Compliance Lead.
2. IC acknowledges within 5 minutes (P0) or 15 minutes (P1).
3. IC opens a dedicated incident channel for the responding team.
4. All responders join the channel within 15 minutes of declaration.
5. IC assigns roles, opens the relevant runbook, and announces severity.
6. Status updates posted to the incident channel every 15 minutes (P0) or 30 minutes (P1).
**1.3 Decision Authority**
ActionAuthorityAdditional Approval
Declare P0 or P1
IC, or on-call engineer (provisional)
IC confirms within 15 minutes
Activate Control 42 (regulatory freeze)
Legal Counsel plus 3-of-5 multi-signature
None — immediate execution
Emergency program upgrade
IC plus 5-of-9 multi-signature
Certora re-verification required post-execution
Notify SEC or FinCEN
Legal Counsel
IC concurrence
Public disclosure
IC plus Communications role
Legal Counsel review
Rollback to previous program version
IC plus 5-of-9 multi-signature
Post-execution audit attestation
Coordinate Module 3 federal-action freeze
Legal Counsel plus IC
Empire notification mandatory
If the IC is unreachable within 15 minutes of a P0 page, the on-call senior engineer assumes command provisionally and is responsible for engaging Legal Counsel and the Empire liaison while continuing escalation attempts to the IC.
***
#### 2. Severity Classification
SeverityDefinitionResponse SLAEscalationExamples
**P0 — Active Exploit or Critical Failure**
Funds at risk, control bypass confirmed, custody discrepancy, key compromise, federal-action requirement
**15 minutes**
IC plus all leads plus multi-signature holders
Custody discrepancy detected (Error 6001); Transfer Hook bypass; unauthorized fund extraction; key compromise; federal-action freeze required (Module 3)
**P1 — Service Degradation**
Trading halted or severely degraded; oracle stale beyond threshold; CEDEX API down
**1 hour**
IC plus Technical Lead plus DevOps
Custody oracle stale beyond 5 slots; OFAC oracle stale beyond 48 hours; CEDEX 5xx error rate above 10%; RPC failover triggered; NAV oracle stale (Module 2)
**P2 — Partial Failure**
Non-critical oracle degraded; single service impacted; monitoring alert
**4 hours**
On-call engineer
AML provider timeout (cached serving); TWAP stale beyond 5 minutes; EDGAR batch failed; Classification oracle stale (Module 3); single relay crash
**P3 — Monitoring Alert**
Threshold warning; unusual pattern; non-exploitable anomaly
**24 hours**
On-call engineer
Volume spike detection; latency increase; disk space warning; certificate expiry approaching
**Severity Escalation Rules**
ConditionEscalation
P2 unresolved after 4 hours
Escalate to P1
P1 unresolved after 4 hours
Escalate to P0
Any P0 involving funds
IC plus Legal Counsel plus Empire plus all multi-signature holders
IC unreachable within 15 minutes
On-call senior engineer assumes provisional command
Module 3 federal action received
Automatic P0 regardless of operational impact
***
#### 3. Detection and Alerting
**3.1 Automated Detection**
MonitorToolCheck IntervalP0 TriggerP1 TriggerP2 Trigger
Custody oracle freshness
Datadog
10 seconds
Discrepancy detected
Slot age above 5
Slot age above 3
OFAC oracle staleness
Datadog
1 minute
—
Age above 48 hours
Age above 24 hours
AML provider availability
Datadog
1 minute
—
Both providers down beyond 30 minutes
One provider down
CEDEX API error rate
Datadog
30 seconds
—
5xx rate above 10% for 5 minutes
5xx rate above 5%
RPC latency
Datadog
10 seconds
—
Primary plus fallback both down
Primary down (failover active)
Transfer Hook error spike
Datadog
1 minute
Unexpected Error 6001 (custody)
Error rate above 5%
Error rate above 1%
Global Pool balance
Custom
Every block
Balance decreased
—
—
Multi-signature transactions
Datadog
Real-time
Unauthorized upgrade attempt
—
—
Solana network
Helius
30 seconds
—
Network halt beyond 5 minutes
TPS below 500
NAV oracle freshness (per Module 2 mint)
Datadog
1 minute
—
Reappraisal age beyond `nav_reappraisal_max_age_secs`
Reappraisal age above 50% of `nav_reappraisal_max_age_secs`
Classification oracle freshness (per Module 3 mint)
Datadog
5 minutes
Federal-action notification received
Classification age above 48 hours
Classification age above 12 hours
Module 3 federal-action feed
Custom
5 minutes
New EO, Section 232 action, or DPA Title III order matching basin
—
—
**3.2 Alert Routing**
SeverityPagerDuty PolicyNotification
P0
Critical-severity policy: phone call plus SMS plus dedicated channel plus email
IC plus all leads plus multi-signature holders
P1
High-severity policy: SMS plus dedicated channel plus email
IC plus Technical Lead plus DevOps Lead
P2
Medium-severity policy: dedicated channel plus email
On-call engineer
P3
Low-severity policy: dedicated channel only
On-call engineer (next business day)
**3.3 Manual Reporting**
Anyone can declare an incident through any of the following channels:
* PagerDuty manual trigger
* Dedicated incident channel with structured command
* Email to `incidents@rwatokens.net`
* Direct phone call to the IC line (P0 only — when other channels are insufficient)
***
#### 4. General Response Procedure
Every incident follows this seven-step framework. Specific runbooks (Sections 5 through 14) provide detailed procedures for common incident types.
**Step 1 — Detect**
Automated alert fires or manual report received. On-call engineer acknowledges within the SLA for the declared severity.
**Step 2 — Triage (first 15 minutes)**
1. Confirm the incident is real (not a false positive from a known monitoring artifact).
2. Classify severity (P0 / P1 / P2 / P3).
3. Identify affected systems, mints, and wallets.
4. Estimate blast radius — how many users or issuers are affected, across which modules.
5. Open the incident channel and page the IC if severity is P0 or P1.
**Step 3 — Contain (immediate)**
1. Stop the bleeding — prevent further damage.
2. Activate Control 42 (regulatory freeze) if funds are at risk.
3. Disable affected services if necessary.
4. Preserve evidence — capture logs, on-chain state snapshots, oracle attestation history.
5. Notify Empire Stock Transfer if the incident is custody-related.
**Step 4 — Investigate**
1. Conduct full on-chain forensics — transaction trace from suspected wallet or mint.
2. Audit oracle state — attestation history, slot ages, ed25519 verification records.
3. Analyze logs — relay services, RPC, CEDEX backend.
4. Review smart-contract behavior to identify any vulnerability or bypass path.
5. Reconstruct the timeline (who, what, when, how).
**Step 5 — Remediate**
Class of IssueRemediation
Program vulnerability
Emergency upgrade with 5-of-9 multi-signature plus Certora re-verification
Oracle issue
Rotate keys, verify backup consensus
Key compromise
Emergency key rotation with appropriate multi-signature threshold
Infrastructure
Restore, fail over, scale
External (Solana network, Helius)
Wait, communicate, monitor recovery
**Step 6 — Recover**
1. Verify the fix is in place via on-chain confirmation.
2. Confirm 2-of-3 oracle consensus on integrity (custody-affected incidents).
3. Lift Control 42 freeze if it was activated.
4. Resume CEDEX trading.
5. Verify monitoring shows healthy state across all dashboards.
6. Notify stakeholders that the incident is resolved.
**Step 7 — Post-Mortem (within 72 hours)**
Conduct root cause analysis, reconstruct the timeline, review control effectiveness, verify remediation, identify process improvements, and prepare any required public disclosure.
***
#### 5. Runbook: Custody Discrepancy (P0)
**Trigger:** CustodyOracle detects that the Empire-attested Common Class B share balance does not match the on-chain ST22 token supply. Error 6001 returned on every transfer for the affected mint. Applies across all modules — custody integrity is the foundational invariant for the platform.
**Severity:** P0 — automatic. No triage required.
**Immediate Actions (0 to 15 minutes)**
1. **Confirm the discrepancy is real.** Query the platform's custody oracle endpoint for the affected mint. Verify that `discrepancy_detected` is true and capture the reported `common_b_balance` and `token_supply` values along with the delta.
2. **Confirm transfers are halted.** Control 1 automatically rejects every transfer for this mint with Error 6001. No manual containment action is required. Verify by attempting a test transfer and confirming the rejection.
3. **Notify Empire Stock Transfer within the 15-minute SLA.** Contact Empire's compliance hotline by phone and follow up via email. Provide the mint address, the oracle's reported balance and supply, and the delta.
4. **Notify the IC** if not already paged via PagerDuty, and open the incident channel.
5. **Preserve evidence.** Snapshot the CustodyOracle account state, record the current Solana slot and timestamp, and capture the Datadog custody dashboard at the moment of detection.
**Investigation (15 to 60 minutes)**
Determine which of the five possible root causes applies:
Possible CauseIndicatorResolution Path
Empire custody change not yet reflected on chain
Recent Empire-side custody event with relay lag
Wait for relay to catch up; verify cadence within next slot
Unauthorized minting
Recent mint instruction not authorized by Empire
Escalate to Legal Counsel; SEC notification assessment required
Token burn without corresponding custody withdrawal
Burn instruction on-chain not matched by Empire-side withdrawal
Should never happen by design; escalate as P0 architectural issue
Oracle relay malfunction (Ed25519 signature issue)
Relay logs show signature failures
Restart relay; rotate keys if signature problem persists
Empire API returning incorrect data
Empire confirms wrong data was served
Empire corrects records; relay pushes update
Coordinate directly with Empire to reconcile actual share counts against the Master Securityholder File. Empire is the authoritative source for Common Class B balances; any reconciliation defers to Empire's records.
Conduct on-chain forensics by examining the recent transaction history for the affected mint, looking for unexpected mint or burn instructions and any program upgrade transactions on the Transfer Hook.
**Resolution**
1. Once Empire and the platform agree on the correct values, push an updated attestation through the custody relay.
2. Verify 2-of-3 oracle consensus: primary (Empire Ed25519 attestation) matches supply; secondary (platform verification node) confirms the match; tertiary (most recent quarterly audit record) is consistent.
3. Confirm that `discrepancy_detected` returns to false and a test transfer succeeds.
4. Verify monitoring dashboards return to normal and notify stakeholders that the incident is resolved.
**Post-Resolution**
Conduct the post-mortem within 72 hours. If the SAR criteria are met (suspicious activity at or above the regulatory threshold), Legal Counsel assesses filing. If the event is material, SEC notification is initiated within 24 hours of confirmation per the platform's compliance policy.
***
#### 6. Runbook: Smart Contract Exploit (P0)
**Trigger:** Unauthorized state change, fund extraction, control bypass, or unexpected error pattern indicating an exploitable vulnerability.
**Severity:** P0 — immediate.
**Immediate Actions (0 to 15 minutes)**
1. **Activate Control 42 — regulatory freeze on the affected mint(s).** Requires Legal Counsel authorization plus 3-of-5 multi-signature; executes immediately with no timelock.
2. **If the exploit is cross-mint** — affecting multiple issuers — freeze all mints simultaneously. This is the platform's nuclear option and is reserved for systemic exploits where the scope is not yet contained.
3. **Preserve on-chain evidence.** Record all transactions from the suspected attacker wallet or wallets, snapshot all affected account states, and record the Solana slot and block hash at detection.
4. **Notify the IC, Legal Counsel, Empire Stock Transfer, and all multi-signature holders** simultaneously through PagerDuty critical-severity policy.
**Investigation**
Identify the attack vector by determining:
* Which of the 42 controls was bypassed.
* Which program instruction was exploited.
* Whether the cause was a program-logic flaw, oracle manipulation, account confusion, or operational misconfiguration.
Identify all affected wallets and mints by tracing transactions from the attacker wallet or wallets and determining the total funds at risk or extracted.
Determine whether a program upgrade is needed:
* If a program-logic vulnerability: emergency upgrade is required.
* If an oracle vulnerability: rotate keys and fix the relay; no program upgrade required.
* If an operational issue: fix configuration; no program upgrade required.
**Remediation**
For program upgrades the procedure is:
1. Build the patched version with the toolchain matching the audited release.
2. Run all six Certora invariants on the patched bytecode — every invariant must pass.
3. Create the emergency governance proposal.
4. Collect 5-of-9 multi-signature signatures for the upgrade authority.
5. Deploy the upgrade.
6. Verify on-chain that the patched program is active and the bytecode hash matches the audited replacement.
**Recovery**
Lift the Control 42 freeze only after the patch is deployed, verified, and monitoring is healthy. Lifting requires Legal Counsel authorization plus 3-of-5 multi-signature.
Monitor closely for 48 hours after the freeze is lifted: enhanced alerting thresholds active, manual review of the first 100 post-resume transactions.
***
#### 7. Runbook: Oracle Failure (P1/P2)
**7.1 Custody Oracle Stale (P1)**
**Trigger:** Custody oracle slot age above 5. Transfers automatically halted with Error 6002 across all modules.
1. **Check the relay service.** Confirm whether the custody-relay process is running. If stopped, restart it. If running but stale, examine recent logs for connectivity errors, signature failures, or rate-limit events.
2. **Check the Empire API.** Verify Empire's API health endpoint. A 5xx response indicates an Empire-side outage; contact Empire compliance immediately. A 200 response with stale data indicates an Empire backend issue; also contact Empire.
3. **Check RPC connectivity.** Confirm the primary RPC (Helius dedicated cluster) is reachable. If the primary is down, verify the platform has failed over to the Triton fallback.
4. **Restart the relay with a fresh connection** and monitor that the oracle slot age drops to 0 or 1 within the next two slots.
5. **If unresolved after 30 minutes**, escalate to P0 and prepare communications for an extended trading halt.
**7.2 OFAC Oracle Stale (P1 if above 48 hours; P2 if above 24 hours)**
1. **Check the OFAC indexer.** Confirm the indexer process is running and review recent logs.
2. **Check the U.S. Treasury OFAC API.** A response failure indicates the public Treasury endpoint is unavailable. The platform's cached SDN list remains valid for up to 48 hours; trading continues during cache validity.
3. **Restart the indexer** and verify the oracle's `is_fresh` status returns to healthy.
4. **If staleness exceeds 48 hours,** all transfers halt with Error 6005. Escalate to P1, prepare communications, and verify Empire is informed.
**7.3 AML Provider Failure (P2)**
1. **Identify which provider or providers are failing** by reviewing the AML bridge logs for timeout or error patterns from Chainalysis KYT and TRM Labs.
2. **If one provider is down**, the system continues using the surviving provider's score. P2 — monitor for resolution.
3. **If both providers are down**, cached scores serve wallets with scores under 6 hours old. New wallets cannot trade because no AML score is available; transfers reject with Error 6006. Escalate to P1 if both providers remain down beyond 30 minutes.
4. **Check API key validity.** Both providers' credentials are stored in the platform's secrets manager. If credentials have expired, rotate them and restart the AML bridge.
**7.4 TWAP Oracle Stale (P2)**
1. **Check the Pyth Network feed.** Pyth's status page indicates whether the issue is platform-specific or Solana-network-wide.
2. **Check the TWAP consumer service.** Confirm it is running and review recent logs.
3. **Understand the impact.** After 5 minutes of staleness, the TWAP-based price-impact circuit breaker is disabled — trades execute without price-impact protection. The other 41 controls remain active. P2 alert is appropriate for short-term degradation.
4. **Restart the TWAP consumer** and verify Pyth feed consumption resumes.
***
#### 8. Runbook: Module 2 NAV Oracle Failure (P1)
**Trigger:** NAVOracle for a Module 2 mint has not received a fresh appraisal within `nav_reappraisal_max_age_secs`. The affected mint is paused on the AMM until a fresh appraisal arrives. Other Module 2 mints and all other modules are unaffected.
**Severity:** P1.
**Immediate Actions**
1. **Confirm the staleness.** Query the platform's NAV oracle endpoint for the affected mint. Verify the `last_reappraisal` timestamp, the `next_reappraisal` timestamp, and the current age against `nav_reappraisal_max_age_secs`.
2. **Identify the property and the appraiser of record.** The platform's compliance database maps each Module 2 mint to its single-asset entity, the property identifier, and the licensed appraiser engaged for the reappraisal cycle.
3. **Contact the appraiser.** The appraiser may be running late on a scheduled cycle or may have submitted to the wrong endpoint. The appraiser's response determines whether the issue is operational (delivery delay) or substantive (no completed appraisal).
4. **Notify Empire Stock Transfer.** Empire is the qualified custodian for the underlying Common Class B shares of the single-asset entity. Empire is informed of any NAV oracle disruption that affects an issuance under their custody.
**Investigation**
Possible CauseResolution Path
Appraiser delivery delay
Appraiser submits the completed appraisal to the NAV relay; relay pushes to chain
NAV relay service failure
Restart the NAV relay; verify the appraiser endpoint is reachable
Appraiser API authentication failure
Rotate API credentials; verify mTLS configuration
Appraiser engagement lapsed
Engage new appraiser; document in compliance database; reissue offering documentation if cadence change
Property under dispute (legal hold, title issue)
Coordinate with Legal Counsel; the mint may need a formal hold rather than a stale-NAV pause
**Resolution**
1. Once the new appraisal is received, the NAV relay verifies the appraiser's signature, validates the value falls within reasonable bounds against the prior appraisal, and pushes the update on chain.
2. Confirm the NAVOracle freshness drops below the warning threshold.
3. Confirm the affected mint resumes AMM trading.
4. Notify the issuer and affected investors that trading has resumed.
**Post-Resolution**
The post-mortem evaluates whether the cadence configured for this property is adequate. If the property type or market conditions warrant tighter cadence, an updated offering disclosure may be required.
If the NAV deviation between the new appraisal and the prior appraisal exceeds `nav_deviation_max_bps`, the NAV-deviation circuit breaker (Section 11) may also activate, requiring separate handling.
***
#### 9. Runbook: Module 3 Classification Oracle Failure (P2)
**Trigger:** ClassificationOracle for a Module 3 mint has not received a fresh USGS or DOE classification update within the configured `classification_max_age_secs` (default 24 hours). Transfers continue but enhanced compliance review is triggered for all transfers on the affected mint.
**Severity:** P2 (escalates to P1 if classification age exceeds 48 hours; P0 if a federal-action notification arrives during staleness — see Section 13).
**Immediate Actions**
1. **Confirm the staleness.** Query the platform's classification oracle endpoint for the affected mint. Verify the USGS class, DOE status, federal-action status, and last-refresh timestamp.
2. **Check the federal feeds.** USGS Critical Minerals List and DOE Critical Materials Strategy feeds are the primary inputs. A federal-side outage (rare) means the platform's cached classification continues to govern.
3. **Check the Classification relay service.** Confirm the relay is running and review recent logs.
4. **Notify the Compliance Lead.** Module 3 classifications are regulated metadata; staleness affects the platform's compliance posture for the affected basin asset.
**Investigation**
Possible CauseResolution Path
USGS or DOE feed temporary unavailability
Wait for federal endpoint recovery; cached classification valid through cache window
Classification relay service crash
Restart the relay; verify federal endpoints are reachable
Classification source change (USGS reclassifies the mineral)
Compliance Lead reviews; if the mineral is removed from the Critical Minerals List, broader review of the basin's federal status is required
Federal action affecting the basin (EO, Section 232 order, DPA Title III order)
This is a P0 — see Section 13
**Resolution**
1. Once the federal feeds return current data, the relay pushes the updated classification on chain.
2. Confirm classification oracle freshness drops below the warning threshold.
3. Enhanced compliance review automatically de-activates.
4. The post-mortem documents the cause, notes any pattern of federal-feed reliability issues, and updates the classification cadence if warranted.
**What This Runbook Does Not Cover**
This runbook handles operational staleness only. If the federal classification has substantively changed (the mineral has been added to or removed from a critical list, or a federal action has been issued affecting the basin), the appropriate response is the federal-action freeze runbook in Section 13.
***
#### 10. Runbook: RPC Infrastructure Degradation (P1/P2)
**Trigger:** Primary RPC (Helius dedicated cluster) latency above 500ms, error rate above 5%, or total failure.
1. **Verify automatic failover is active.** The SDK and relay services automatically switch to the Triton fallback. A P2 alert is generated on failover trigger. Confirm the platform's health endpoint reports the fallback is serving.
2. **Check Helius status.** Helius publishes a public status page. If an incident is in progress, monitor for resolution. If no incident is published, contact Helius support directly.
3. **If both primary and fallback are down (P1 escalation):** all oracle relays will fail because no RPC path is available. The custody oracle will go stale within minutes and transfers will halt automatically. From the platform's perspective, this is effectively a Solana-connectivity issue. Communications: "Infrastructure maintenance — trading paused."
4. **Recovery.** Monitor Helius and Triton status. When primary RPC recovers, verify all relay services reconnect and the custody oracle returns to fresh status. Verify the CEDEX order book is in sync. Resume normal operations.
***
#### 11. Runbook: Circuit Breaker Activation (P2)
**Trigger:** Automated circuit breaker triggered. Trading is halted or restricted for a specific mint.
**11.1 Price Halt (above 10% move in 5 minutes)**
1. **Verify the trigger is legitimate.** Check the CEDEX trading history: was there genuine volume causing the move? Check for coordinated activity across multiple wallets and timing patterns. Check whether a public news event justifies the price movement.
2. **No manual action is required.** The 15-minute cooldown elapses and the circuit breaker resets automatically when the TWAP normalizes. Monitor the first trade after cooldown to confirm successful resumption.
3. **If repeated triggers occur (more than three in 24 hours)**, investigate for manipulation. Review cross-wallet clustering. The compliance team assesses for SAR criteria.
**11.2 Volume Halt (above 30% daily sell by single wallet)**
1. **Identify the wallet.** Datadog query on Transfer Hook errors with code 6037 produces the wallet address.
2. **No manual action is required.** The wallet is automatically halted for 24 hours. Other wallets and other mints are unaffected.
3. **Investigation.** The compliance team determines within 24 hours whether the activity represents a legitimate institutional rebalance or coordinated activity warranting escalation.
**11.3 Module 2 NAV Deviation Breaker (Real Estate)**
1. **Trigger.** On-chain price for a Module 2 mint has deviated outside `nav_deviation_max_bps` from the on-chain NAV. The mint is paused on the AMM.
2. **Verify.** Query the NAV oracle endpoint and confirm the deviation magnitude.
3. **Investigation.** Either the NAV is stale (Section 8) or genuine market pricing has diverged from appraised NAV. Coordinate with the issuer and appraiser.
4. **Recovery.** Resumes upon receipt of a fresh appraisal that brings the on-chain price within the deviation band, or upon governance-approved adjustment to the deviation threshold.
***
#### 12. Runbook: Regulatory Freeze — Control 42 (P0)
**Trigger:** Legal Counsel directs an immediate halt of all transfers on a specific mint or platform-wide. This is the most severe containment action and is used only when legally required or when it is the appropriate response to an active exploit.
**Activation**
1. **Legal Counsel authorization** is documented in writing in the incident channel before execution. Verbal authorization may be used only when written authorization will follow within the same hour.
2. **Multi-signature execution (3-of-5)** with no timelock — executes immediately. Three of the five emergency-authority signers coordinate the freeze instruction.
3. **Verify the freeze is active** by attempting a test transfer (should return Error 6042) and by confirming `SecurityConfig.is_paused` is true.
4. **Notify stakeholders** in this order: Empire Stock Transfer (immediate), affected issuer (within 1 hour), affected investors via the CEDEX portal notification (within 1 hour), public status page ("Trading halted for \[SYMBOL] — regulatory review").
**Triggers for Control 42**
TriggerAuthoritySpeed
SEC enforcement action against issuer
Legal Counsel
Immediate
Court order or subpoena requiring halt
Legal Counsel
Immediate
FinCEN SAR investigation requiring halt
Legal Counsel
Immediate
OFAC emergency SDN designation
Automated (Control 39) plus Legal Counsel confirmation
Automatic
Active exploit (while investigation proceeds)
IC plus Legal Counsel
Immediate
Issuer bankruptcy filing
Automated (Control 35)
Automatic — protective conversion
**Deactivation**
The Control 42 freeze is lifted only when:
1. Legal Counsel authorizes the lift in writing.
2. Root cause is resolved.
3. 3-of-5 multi-signature executes the unfreeze instruction.
4. A test transfer succeeds.
5. Monitoring confirms normal operations.
6. Stakeholder notification: "Trading resumed."
***
#### 13. Runbook: Module 3 Federal-Action Freeze (P0)
**Trigger:** A federal action has been issued that affects a basin asset underlying a Module 3 mint. Federal actions include Executive Orders affecting strategic minerals, Section 232 tariff or restriction orders, Defense Production Act Title III orders, Department of Energy program changes affecting eligibility, and any court order or regulatory directive specifically naming the basin or mineral classification.
**Severity:** P0 — automatic. No triage required. Federal-action notifications go directly to Legal Counsel and the IC.
**Immediate Actions (0 to 15 minutes)**
1. **Capture the federal action.** Record the issuing agency, action type, effective date, and scope (specific basin, specific mineral class, or broader category).
2. **Identify affected mints.** The compliance database maps each Module 3 mint to its basin identifier, mineral class, and federal program participation. Determine which mints are within the action's scope.
3. **Activate Control 42 on each affected mint** (Section 12 procedure). Federal-action freezes use the same Control 42 mechanism — Legal Counsel authorization plus 3-of-5 multi-signature, no timelock.
4. **Notify Empire Stock Transfer** within the 15-minute SLA. Empire holds Common Class B shares for the underlying single-asset entity and coordinates any custodial response that may be required.
5. **Notify affected issuers** (the basin operators) and affected investors.
6. **Update the Classification oracle** with the federal-action status so that any subsequent compliance check on the affected mints reflects the action.
**Investigation**
The investigation phase for federal-action freezes is led by Legal Counsel rather than the Technical Lead, because the action's scope, duration, and required response are legal questions:
DeterminationPath
Does the action restrict transfer of the underlying basin asset?
Legal review of the action text; may require coordination with issuer's outside counsel
Does the action affect federal program eligibility (such as DOE coal-derived REE recovery)?
Compliance database is updated with new eligibility state
Is the action time-bounded (e.g., 90-day Section 232 review) or open-ended (e.g., new EO)?
Determines remediation path
Is the action subject to legal challenge, and is challenge being initiated?
Coordinate with issuer; freeze remains until resolution
**Resolution**
The freeze remains active for the full duration that the federal action prohibits transfer or while substantial uncertainty about transfer status persists. Resolution requires:
1. **Federal action resolution.** The action expires, is rescinded, the basin is exempted, or the issuer obtains an authorized variance.
2. **Legal Counsel authorization** for the lift, in writing.
3. **3-of-5 multi-signature** executes the unfreeze.
4. **Classification oracle updated** to reflect the new federal status.
5. **Stakeholder notification** that trading has resumed.
**Post-Resolution**
The post-mortem documents the federal action, the platform's response timeline, the duration of the freeze, the impact on issuers and investors, and any process improvements identified. If the federal action revealed a gap in the platform's federal-action monitoring, the gap is remediated before the next incident.
***
#### 14. Runbook: Key Compromise (P0)
**Trigger:** Suspected or confirmed compromise of any signing key — multi-signature signer, oracle relay, or Empire attestation key.
**14.1 Multi-Signature Signer Key Compromise**
1. **Assess severity.** How many keys are compromised? Is the attacker below threshold (the upgrade-authority requires 5-of-9; the parameter and emergency authorities require 3-of-5)? Has any unauthorized transaction been submitted on chain?
2. **If below threshold (1 to 4 keys for upgrade authority; 1 to 2 keys for parameter or emergency authority):** the attacker cannot execute. Immediate risk is low. Rotate the compromised keys via governance proposal. Monitor for unauthorized multi-signature proposals.
3. **If at or above threshold:** this is a critical P0. Check whether any program upgrade is currently pending in the timelock window. If yes, cancel the pending upgrade immediately (a 2-of-5 cancellation is sufficient during the timelock window). Activate Control 42 across all mints as a precautionary measure. Initiate emergency governance to rotate all affected keys. Conduct a physical-security review of all key-holder locations and chain-of-custody.
**14.2 Key Rotation Procedure**
1. Generate new keys on fresh Ledger Enterprise devices.
2. Initiate the governance proposal that registers new keys and deauthorizes old keys.
3. Execute the proposal through the standard timelock and multi-signature thresholds for the affected authority. Even in emergencies, the timelock remains in force unless an emergency override has been authorized through the platform's governance bylaws.
4. Verify the rotation by confirming old-key transactions are rejected and new-key transactions are accepted.
**14.3 Oracle Relay Key Compromise**
1. **Impact assessment.** An attacker with a compromised relay key could submit false oracle data. The Ed25519 payload format includes the slot, so stale data is rejected at the program level. The 2-of-3 oracle consensus catches manipulated data when only one source is compromised.
2. **Rotate immediately.** Generate a new key in the platform's HSM. Update the oracle program to register the new relay authority. Restart the relay service with the new key. The old key is deauthorized.
3. **Audit.** Review the last 24 hours of oracle updates for anomalies.
**14.4 Empire Attestation Key Compromise**
1. **Impact assessment.** This is the most critical key compromise scenario because Empire's Ed25519 attestation drives the platform's foundational 1:1 backing verification.
2. **Immediate.** Halt all transfers — the custody oracle is no longer trusted. The IC activates Control 42 across all mints simultaneously.
3. **Coordinate with Empire.** Empire revokes the compromised key, generates a new Ed25519 keypair on Empire's HSM, and communicates the new public key through documented chain-of-custody.
4. **On-chain update.** Initiate a governance proposal that updates the Empire public key on every CustodyOracle account. The proposal proceeds through the standard 48-hour timelock unless an emergency override has been authorized. 5-of-9 multi-signature executes the rotation.
5. **Resume.** New attestations are verified on chain. The Control 42 freeze is lifted across all mints after 2-of-3 oracle consensus confirms integrity.
***
#### 15. Communication Protocol
**15.1 Internal Communication**
ChannelUseDuring Incident
Dedicated incident channel
Real-time coordination among responders
All responders join. Status updates every 15 minutes (P0) or 30 minutes (P1).
PagerDuty
Alerting and acknowledgment
On-call engineer acknowledges within SLA.
Encrypted messaging
Multi-signature coordination
Signer coordination for emergency actions.
Phone
IC direct line
P0 only — when other channels are insufficient.
**15.2 External Communication**
AudienceChannelTimingContent
Status page
Automated plus manual
Within 15 minutes of P0 or P1
System status, affected services, ETA
Institutional investors
CEDEX portal notification
Within 1 hour of P0
Incident summary, impact, ETA
Affected issuers
Direct email plus phone
Within 1 hour of P0
Issuer-specific impact, action required
Empire Stock Transfer
Compliance hotline
Within 15 minutes of custody-related P0
Custody status, discrepancy details
Public and community
Social media plus blog
After containment — never during active response
Post-incident summary
SEC or FinCEN
Formal notification
Per Legal Counsel determination
If material event or SAR threshold met
Federal agency (Module 3)
Counsel-to-counsel via outside SEC counsel
Per Legal Counsel determination
If federal action coordination is appropriate
**15.3 Status Page Template**
The standard status page entry includes timestamp, brief description, impact statement, affected ST22 tokens or "all", and the next update commitment. Updates are issued at the cadence required by severity. The final entry is a Resolved status with root cause summary, total duration, and a commitment to publish a full post-incident report within 72 hours.
**15.4 Communication Rules**
* Never speculate about root cause in external communications.
* Never share technical details of an exploit before the patch is deployed.
* Never promise specific resolution times — use "investigating" and "ETA when known."
* Always coordinate external messaging through the Communications role.
* Always have Legal Counsel review any SEC or FinCEN notification before sending.
* For Module 3 federal-action incidents, all external communications are reviewed by Legal Counsel before publication regardless of audience.
***
#### 16. Post-Incident Review
**16.1 Timeline**
MilestoneDeadline
Post-incident review meeting
72 hours after resolution
Draft post-mortem document
5 business days
Action items assigned
5 business days
Action items tracked in the platform's project-tracking system
5 business days
Public disclosure (if warranted)
30 calendar days
**16.2 Post-Mortem Structure**
The post-mortem document is structured into the following sections:
1. **Summary.** Severity, duration, impact, one-to-two-sentence root cause statement.
2. **Timeline.** Time-stamped sequence of events from initial alert through resolution.
3. **Root Cause Analysis.** Detailed technical or operational explanation.
4. **What Went Well.** Specific actions, controls, or decisions that limited the impact.
5. **What Went Wrong.** Specific actions, controls, or decisions that allowed the incident to occur or extended its duration.
6. **Action Items.** Numbered list with owner, priority, and deadline.
7. **Regulatory Implications.** SAR filing assessment, SEC notification assessment, Empire notification confirmation, federal-action assessment for Module 3 incidents.
8. **Lessons Learned.** Key takeaways for the team and for the platform's runbooks.
**16.3 Blameless Culture**
Post-incident reviews focus on systems and processes — not individuals. The goal is to understand what happened, why it happened, and how to prevent recurrence. If human error contributed, the question is "why did the system allow this error to propagate?" — not "who made the mistake?"
***
#### 17. Escalation Contact Sheet
RolePrimaryBackupContact Method
**Incident Commander**
Chief Technology Officer (Frank Yglesias)
On-call senior engineer (provisional command)
PagerDuty → phone → encrypted messaging
**Technical Lead**
On-call engineer
Senior engineer (rotation backup)
PagerDuty → dedicated channel
**Compliance Lead**
Legal Counsel (JDT Legal)
IC (interim coverage only)
Phone → email
**Empire Liaison**
Empire Stock Transfer (Patrick Mokros, Founder)
Empire compliance hotline
Phone → email
**Communications**
Designated by IC at incident declaration
IC
Dedicated channel → email
**DevOps**
Platform DevOps Lead
On-call engineer
PagerDuty → dedicated channel
**Helius Support**
Helius dedicated support channel
Helius escalation email
Dedicated channel → email
**PagerDuty Services**
ServiceEscalation PolicyOn-Call Rotation
Custody Oracle
Critical-severity policy (P0)
24/7 weekly rotation
CEDEX API
High-severity policy (P1)
24/7 weekly rotation
Oracle Services (general)
Medium-severity policy (P2)
Business hours plus on-call
Module 2 NAV Oracle
High-severity policy (P1)
24/7 weekly rotation
Module 3 Classification Oracle
Medium-severity policy (P2)
Business hours plus on-call
Module 3 Federal-Action Feed
Critical-severity policy (P0)
24/7 weekly rotation
Infrastructure
Medium-severity policy (P2)
Business hours plus on-call
***
#### 18. Tabletop Exercise Schedule
Quarterly tabletop exercises ensure the team can execute runbooks under pressure. Exercises rotate through high-impact runbooks across all three modules.
QuarterScenarioModule CoverageParticipantsObjective
Q3 2026
Custody discrepancy (Section 5)
All modules
Full team
Validate detection → containment → Empire coordination → resolution
Q4 2026
Smart contract exploit (Section 6)
All modules
IC plus engineers plus Legal
Validate Control 42 activation → emergency upgrade → Certora re-verification
Q1 2027
Module 2 NAV oracle failure (Section 8)
Module 2
IC plus engineers plus Legal plus appraiser representative
Validate appraiser coordination → relay restart → mint resume
Q2 2027
Module 3 federal-action freeze (Section 13)
Module 3
IC plus Legal plus Empire plus issuer representative
Validate federal-action capture → Control 42 activation → Empire coordination → multi-stakeholder communication
Q3 2027
Multi-signature key compromise (Section 14)
All modules
IC plus multi-signature holders
Validate key rotation → pending upgrade cancellation → enhanced monitoring
Q4 2027
Full oracle cascade failure
All modules
Full team
Validate fail-safe cascade → communication protocol → recovery sequence
**Exercise Format**
1. **Scenario briefing (10 minutes).** Facilitator presents the incident scenario.
2. **Response execution (45 minutes).** Team follows the relevant runbook in real time. The facilitator injects new information as the exercise progresses to mirror real-incident dynamics.
3. **Debrief (30 minutes).** What worked, what did not, and what runbook updates are required.
4. **Runbook updates** are completed within 5 business days following the exercise.
***
#### Related Documentation
* **Solana Blockchain Foundation** — Why Solana, Token-2022, Transfer Hook, module-specific foundations
* **Architecture Decisions** — ADR-001 through ADR-012 with full alternatives analysis
* **Security Model** — Threat model, key management, formal verification, module-specific threat surfaces, bug bounty
* **Infrastructure Overview** — Cloud architecture, environment separation, blockchain infrastructure
* **Network Configuration** — Program addresses, RPC endpoints, oracle PDAs, multi-signature addresses, production parameters
* **Deployment Guide** — Build, deploy, verify, upgrade, rollback procedures
* **Smart Contract Reference** — Program instruction specifications, account schemas, error codes
* **Oracle Integration Guide** — Oracle relay service architecture, fail-safe cascade, module-specific oracles
* **Compliance Integration Guide** — SAR filing obligations, regulatory notifications, federal-action coordination
***
*RWA Tokens · Incident Response Playbook · Groovy Company, Inc.* *Classification: Internal — authorized personnel only*
# Welcome
Welcome to the **RWA Tokens Marketing Wiki** — the central library for everything we publish about the platform to the outside world. Articles, pitch decks, the lightpaper, investor presentations, SEC filings and staff statements we cite, regulatory commentary, and ongoing news coverage all live here, organized so the comms team, partners, and counsel can find the right asset for the right audience without rebuilding it from scratch.
You'll find collateral grouped by the three asset-class modules — **Equities (ST22), Real Estate, and CORECM** — alongside cross-cutting materials that apply to the platform as a whole: corporate-identity assets, SEC regulatory framework references (Release No. 33-11412, the January 28, 2026 Joint Staff Statement, the April 13, 2026 Covered User Interface Providers statement), and the live news and X/LinkedIn campaign archive. Each item is tagged by audience (institutional investor, issuer prospect, regulator, press) and by stage (draft, internal review, legal-cleared, published) so nothing ships externally without the right approval state.
This wiki is the canonical source for any RWA Tokens marketing artifact under the Groovy Company, Inc. brand (the "OTCM Protocol" dba was retired May 1, 2026; CEDEX, ST22, and GROO remain as product and instrument names). Platform URL is [**https://rwatokens.net**](https://rwatokens.net/); trading venue is **cedex.market**. When in doubt about which version of a deck or letter is current, this wiki is the answer — anything found elsewhere should be checked against the version here before sending.
# Empire Stock Transfer Integration
### Empire Stock Transfer Integration
**Qualified Custodian · Sole Investor Onboarding Authority · Ed25519 Attestation · Master Securityholder File**
Deep-dive into the regulatory and technical integration between the platform and Empire Stock Transfer — the SEC §17A-registered entity that holds every Common Class B share, verifies every investor, and signs every custody attestation that makes the 42 Transfer Hook controls function. This integration applies across all three production modules: Equities (Module 1), Real Estate (Module 2), and CORECM — Carbon Ore, Rare Earth, and Critical Minerals (Module 3).
Empire is not a vendor. Empire is load-bearing infrastructure. Without Empire, no ST22 token can exist.
The platform is operated by Groovy Company, Inc. The trading venue is CEDEX. Empire Stock Transfer (Patrick Mokros, Founder) is the sole §17A-registered transfer agent and qualified custodian for all three RWA Tokens product modules.
***
#### Table of Contents
1. Empire's Dual Role
2. Regulatory Foundation
3. Custody Architecture
4. Ed25519 Attestation Lifecycle
5. Master Securityholder File
6. Investor Onboarding Flow
7. KYC — Individual Verification
8. KYB — Entity Verification
9. AML and OFAC Screening
10. Wallet Verification (KYW)
11. Accredited Investor Verification
12. Transfer Hook Integration Map
13. Protective Conversion Mechanics
14. Tripartite Agreement Structure
15. Conflict of Interest Disclosure
16. Empire Operational Continuity
17. Module-Aware Custody Coverage
***
#### 1. Empire's Dual Role
Empire Stock Transfer serves two distinct functions in the platform's architecture. Both are mandatory for Category 1 Model B compliance. Neither can be replaced by the platform or any other component.
RoleScopeRegulatory BasisReplaceable?
**Qualified Custodian**
Holds all Common Class B shares in irrevocable, perpetual custody. Signs Ed25519 attestations every Solana block (\~400ms). Maintains authoritative share count.
SEC Exchange Act §17A
No — custody must be performed by a §17A-registered entity
**Sole Investor Onboarding Authority**
Performs all KYC (individuals), KYB (entities), AML (Chainalysis KYT plus TRM Labs), OFAC/SDN screening, accreditation verification, and wallet registration.
BSA CIP (31 CFR §1020.220), FinCEN CDD Rule, Reg D Rule 501
No — the platform does not perform onboarding
**Why this architecture exists:** Category 1 Model B requires that investor verification and custody are performed by a regulated entity with §17A obligations — not by the platform operator. If the platform performed investor onboarding, the architecture would be Category 2 (third-party sponsored) with counterparty risk. Empire's independence is the structural guarantee that eliminates counterparty risk.
**What the Platform Does NOT Do**
FunctionPerformed ByPlatform Role
Hold investor assets
Empire Stock Transfer
None — the platform holds no shares
Verify investor identity
Empire Stock Transfer
Portal routes to Empire dashboard
Store KYC/KYB documents
Empire Stock Transfer
The platform has no access to investor PII
File SARs with FinCEN
Empire Stock Transfer
The platform provides transaction analytics
Make accreditation determinations
Empire Stock Transfer
The platform enforces via Transfer Hook (Control 12)
Maintain shareholder records
Empire Stock Transfer (MSF)
Solana blockchain serves as notification layer
***
#### 2. Regulatory Foundation
**Empire's Registrations**
RegistrationAuthoritySinceScope
**Transfer Agent**
SEC, Exchange Act §17A
2006
Shareholder record maintenance, proxy distribution, dividend disbursement, ownership transfer
**Qualified Custodian**
SEC custody requirements
Operating
Irrevocable custody of securities on behalf of beneficial owners
**Regulatory Obligations**
RequirementCFR ReferenceImplementation
Customer Identification Program (CIP)
31 CFR §1020.220
Four-pillar identity verification at onboarding
Customer Due Diligence (CDD)
31 CFR §1010.210
Risk-based assessment at onboarding plus ongoing
Beneficial Ownership
31 CFR §1010.230
UBO identification at 25% or higher for entities
Suspicious Activity Reports (SARs)
31 CFR §1010.320
Filing for transactions at $5,000 or above meeting BSA criteria
Currency Transaction Reports (CTRs)
31 CFR §1010.311
Filing for fiat transactions at $10,000 or above
Recordkeeping
31 CFR §1010.410
5-year retention for KYC, KYB, and AML records
OFAC Screening
Executive Orders plus 31 CFR Parts 500–598
Real-time SDN screening at onboarding plus hourly refresh
Transfer Agent Rules
17 CFR §§240.17Ad-1 through 17Ad-22
Timely processing, recordkeeping, safeguarding
**Empire's Credentials**
AttributeDetail
SEC registration
Section 17A of the Securities Exchange Act of 1934
Operating since
2006
Companies served
530+ publicly traded companies
Geographic scope
Operations across 5 continents
DLT integration
Master Securityholder File with blockchain notification layer (Category 1 Model B)
***
#### 3. Custody Architecture
**Custody Flow**
Copy
```
ISSUER
│
├─ Board resolution authorizing Common B creation
├─ Certificate of Designation filed with Secretary of State
│
▼
EMPIRE STOCK TRANSFER — IRREVOCABLE CUSTODY
│
├─ Common B shares deposited
├─ CUSIP assigned to share class
├─ Shares recorded in Master Securityholder File
├─ Ed25519 attestation key activated
├─ Oracle relay begins publishing per-block attestations
│
▼
ON-CHAIN (Solana)
│
├─ CustodyOracle PDA created: [b"custody-oracle", mint]
├─ Empire Ed25519 public key registered
├─ Attestation: common_b_balance ≥ token_supply (every ~400ms)
│
▼
TRANSFER HOOK — Control 1
│
└─ Every ST22 transfer: verify supply ≤ custodied shares
└─ Discrepancy → Error 6001 → ALL transfers halt
```
**Custody Properties**
PropertySpecification
**Custody type**
Irrevocable — shares cannot be withdrawn by the issuer
**Duration**
Perpetual — no expiration, no termination by issuer
**Custodian independence**
Empire is an independent entity — not owned by Groovy Company, Inc.
**Segregation**
Common B shares segregated per issuer — no commingling
**Insurance**
Per Empire's §17A insurance requirements
**Audit**
Quarterly independent custody audit published on-chain
**CUSIP**
Each Common B share class receives a unique CUSIP identifier (Module 1); property identifier (Module 2); basin identifier (Module 3)
**Attestation**
Ed25519 signed per Solana block (\~400ms)
**What "Irrevocable" Means**
Once Common B shares are deposited with Empire, the issuer cannot withdraw them. This is not a policy — it is a contractual commitment in the tripartite agreement. The only way shares leave custody is through protective conversion (Controls 35–38), which converts them to common stock delivered to shareholders — not returned to the issuer.
This irrevocability is what makes the 1:1 backing guarantee credible. If the issuer could withdraw shares at any time, the custody attestation would be meaningless — the issuer could empty the custody account and leave token holders with worthless tokens. Irrevocable custody eliminates this attack vector by design.
***
#### 4. Ed25519 Attestation Lifecycle
**How It Works**
Empire Stock Transfer signs a custody balance attestation on every Solana block (\~400ms). The signed payload is submitted to the on-chain CustodyOracle account by the platform's relay service. The Transfer Hook reads this account on every ST22 transfer (Control 1).
**Attestation Payload**
Copy
```
┌──────────────────────────────────────────────────────┐
│ Ed25519 SIGNED PAYLOAD (64 bytes) │
├──────────────────────────────────────────────────────┤
│ mint: Pubkey (32 bytes) │
│ common_b_balance: u64 ( 8 bytes) │
│ token_supply: u64 ( 8 bytes) │
│ slot: u64 ( 8 bytes) │
│ timestamp: i64 ( 8 bytes) │
├──────────────────────────────────────────────────────┤
│ SIGNED BY: Empire Ed25519 private key (HSM-backed) │
│ VERIFIED BY: Solana Ed25519 precompile (~120 CU) │
└──────────────────────────────────────────────────────┘
```
**Attestation Lifecycle**
Copy
```
1. EMPIRE INTERNAL
Empire custody system calculates current Common B share count
per issuer (per mint). System runs continuously.
2. EMPIRE SIGNS
Empire HSM signs the 64-byte payload with Ed25519 private key.
One signature per mint per Solana block.
3. RELAY TRANSMITS
The platform's custody relay service fetches signed attestation
from Empire API. Relay submits update_custody_oracle transaction
to Solana.
4. ON-CHAIN VERIFICATION
The Oracle Aggregator program:
├─ Verifies Ed25519 signature via Solana precompile
├─ Verifies slot is current (≤1 slot old)
├─ Updates CustodyOracle account state
└─ If common_b_balance < token_supply:
└─ Sets discrepancy_detected = true
└─ Emits CustodyDiscrepancyDetected event
5. TRANSFER HOOK READS (every transfer)
Control 1:
├─ Is oracle valid? (Ed25519 verified)
├─ Is oracle fresh? (≤1 slot)
├─ supply ≤ balance? (zero tolerance)
└─ Any discrepancy? (halt if true)
```
**Attestation Security Properties**
PropertyMechanism
**Authentication**
Ed25519 — only Empire's HSM-backed private key can produce valid signatures
**Freshness**
Slot number in payload — stale attestations rejected (above 1 slot returns Error 6002)
**Replay prevention**
Slot plus timestamp — captured attestations cannot be replayed in future blocks
**Tamper detection**
Signature covers all payload fields — any modification invalidates signature
**Independence**
Empire signs; the platform's relay transmits; Solana verifies. No single entity controls all three.
**Public verifiability**
Empire's public key is registered on-chain. Anyone can verify attestation signatures independently.
**Key Lifecycle**
PhaseProcess
**Key generation**
Empire generates Ed25519 keypair on HSM (hardware security module)
**Key registration**
Empire public key registered in CustodyOracle account at oracle initialization
**Key usage**
Empire signs every attestation with private key. Relay submits. Solana verifies with registered public key.
**Key rotation**
Empire generates new keypair → communicates new public key to the platform → governance proposal to update on-chain → 48h timelock → 3-of-5 multi-signature executes → old key deauthorized
**Key compromise**
Immediate: halt all transfers (Control 42). Empire revokes key. New key registered. 2-of-3 oracle consensus before resume.
**2-of-3 Oracle Consensus**
For discrepancy resolution and post-halt resume, 2-of-3 independent sources must agree:
SourceTypeAuthority
**Primary**
Empire Ed25519 per-block attestation
Authoritative — Empire holds the shares
**Secondary**
Platform internal verification node
Cross-references Empire data against on-chain supply
**Tertiary**
Quarterly third-party audit (published on-chain)
Independent institutional confirmation
**Production Record**
Zero discrepancy events across three beta issuers (GROO, GRLF, MSPC) and over $7M in processed liquidity. The 1:1 backing ratio has been maintained at every block with zero exceptions. This record reflects the integrity of Empire's custody operations and the reliability of the attestation architecture.
***
#### 5. Master Securityholder File
**What Is the MSF?**
The Master Securityholder File is the authoritative, legally binding record of all Common Class B share ownership. Maintained by Empire Stock Transfer. It IS the official shareholder register for all ST22-backed securities across Modules 1, 2, and 3.
Under Category 1 Model B, the Solana blockchain serves as the operational notification layer — not the legal record of ownership. Empire's MSF is the legal record. The blockchain notifies Empire of transfers, and Empire updates the MSF accordingly.
**Legal Basis**
Every ST22 transfer on CEDEX constitutes an effective entitlement order under UCC Article 8 (§8-102(a)(8)), triggering an update to the MSF. Wyoming Digital Asset Statute (W\.S. 34-29-101) provides additional statutory support for DLT-based securities ownership records.
**MSF Update Flow**
Copy
```
INVESTOR A sells ST22 tokens to INVESTOR B on CEDEX
│
▼
SOLANA: Token-2022 transfer executes (with Transfer Hook — 42 controls pass)
│
├─ TransferValidated event emitted on-chain
│
▼
EMPIRE NOTIFICATION LAYER
│
├─ Platform backend detects TransferValidated event
├─ Constructs UCC Article 8 entitlement order
├─ Submits to Empire MSF API
│
▼
EMPIRE STOCK TRANSFER
│
├─ Validates entitlement order
├─ Updates Master Securityholder File:
│ Investor A: balance decreased by transfer amount
│ Investor B: balance increased by transfer amount
├─ Confirms update
│
▼
MSF STATE NOW REFLECTS ON-CHAIN STATE
│
└─ Next custody attestation (≤400ms) reflects updated balances
```
**MSF Data Architecture**
FieldDescriptionSource
**Investor legal name**
Full name as verified during KYC/KYB
Empire CIP
**Investor wallet address**
Solana wallet linked to verified identity
Empire KYW
**Mint address**
ST22 token mint (Common B share class)
Platform mint creation
**Share balance**
Number of Common B shares held
On-chain balance (authoritative)
**CUSIP / property identifier / basin identifier**
Securities or asset identifier for the Common B class
Empire issuance record
**Jurisdiction**
US (Reg D) or Non-US (Reg S) or US retail (Reg CF)
Empire onboarding determination
**Accreditation status**
Verified accredited; non-US person; or Reg CF investor
Empire verification
**KYC expiry**
Date KYC verification expires
Empire records
**Holding period start**
Date tokens were delivered
On-chain HoldingPeriodAccount
***
#### 6. Investor Onboarding Flow
**End-to-End Process**
Copy
```
INVESTOR visits portal.rwatokens.net
│
├─ Selects issuer / property / basin asset (Module 1, 2, or 3)
├─ The platform Portal routes to Empire Stock Transfer
│ verification dashboard
│
▼
EMPIRE VERIFICATION (sole onboarding authority)
│
├─ Step 1: Identity verification (KYC or KYB)
│ ├─ Individual: government ID, address, SSN/passport
│ └─ Entity: formation docs, UBO identification, EIN
│
├─ Step 2: Accreditation verification (where applicable)
│ ├─ US accredited: income or net worth or professional cert
│ ├─ Non-US: non-US person verification under Reg S
│ └─ US retail: Reg CF eligibility verification
│
├─ Step 3: AML screening
│ ├─ Chainalysis KYT wallet risk score
│ └─ TRM Labs behavioral analysis
│ └─ Score 0–30: approve | 31–70: enhanced review | 71–100: reject
│
├─ Step 4: OFAC/SDN screening
│ ├─ Layer 1: exact wallet address match
│ ├─ Layer 2: fuzzy entity name match
│ └─ Layer 3: 2-hop transaction graph clustering
│
├─ Step 5: Wallet verification (KYW)
│ ├─ Investor provides Solana wallet address
│ ├─ Empire sends Ed25519 signature challenge
│ ├─ Investor signs with wallet private key
│ └─ Empire registers wallet in MSF + Transfer Hook whitelist
│
▼
EMPIRE DETERMINATION
│
├─ APPROVED → investor can participate in ST22 offering
│ ├─ Wallet added to Empire's verified registry
│ ├─ On-chain: wallet whitelisted for Transfer Hook Controls 7–14
│ └─ Investor proceeds to stablecoin purchase (USDC/PYUSD)
│
├─ ENHANCED REVIEW → additional documentation required
│ └─ AML score 31–70 triggers manual review (24h SLA)
│
└─ REJECTED → investor cannot participate
├─ AML score 71–100 → wallet blocked
├─ OFAC match → wallet permanently blocked
└─ KYC failure → may reapply with correct documentation
```
***
#### 7. KYC — Individual Verification
Empire Stock Transfer performs all individual identity verification per BSA CIP requirements (31 CFR §1020.220).
**Required Information**
FieldRequiredVerification Method
Full legal name
Yes
Government-issued photo ID
Date of birth
Yes
Government ID match
Residential address
Yes (no P.O. boxes)
Utility bill or bank statement (under 90 days)
SSN/TIN (US persons)
Yes
Database verification (LexisNexis or equivalent)
Passport number (non-US)
Yes
Document verification plus country of issuance
Email address
Yes
Email confirmation
Phone number
Yes
SMS verification
Solana wallet address
Yes
Ed25519 signature challenge (KYW)
**Accepted Documents**
Document TypeUS PersonsNon-US Persons
Government-issued photo ID
Driver's license, state ID, passport
Passport (required)
Address proof
Utility bill, bank statement (under 90 days)
Same
Liveness verification
Biometric selfie match
Same
**Re-Verification**
KYC is not one-time. Empire re-verifies investors periodically and on trigger events:
TriggerAction
KYC expiry (annual)
Re-verification required — Transfer Hook Control 14 blocks expired KYC
Material change (name, address, citizenship)
Update required — investor provides new documentation
AML score change (crosses threshold)
Automatic re-review by Empire compliance
OFAC SDN list update
Re-screening on every transfer (Controls 8–10)
Unusual transaction pattern
Enhanced review triggered by platform analytics
***
#### 8. KYB — Entity Verification
For corporate, fund, trust, and other non-individual investors. Per FinCEN Beneficial Ownership Rule (31 CFR §1010.230).
**Required Information**
FieldRequiredVerification Method
Legal entity name
Yes
Formation documents
DBA names
If applicable
State registration
Principal business address
Yes
Business utility bill or lease
EIN/TIN
Yes
IRS confirmation letter
State or country of formation
Yes
Articles of incorporation or organization
Entity type
Yes
Formation documents
Authorized signatories
Yes
Board resolution or operating agreement
Ultimate Beneficial Owners (25% or higher)
Yes
UBO declaration plus identity verification per KYC
**UBO Requirements**
Every individual who directly or indirectly owns 25% or more of the entity must be identified and verified through the same KYC process as individual investors. This includes government-issued ID, residential address, and SSN or passport.
***
#### 9. AML and OFAC Screening
**AML — Dual-Provider Architecture**
Empire integrates two independent blockchain analytics providers. The higher score determines disposition.
ProviderCapabilitiesIntegration
**Chainalysis KYT**
Industry standard. Widest entity coverage. Law enforcement data.
REST API per-wallet
**TRM Labs**
200+ behavioral features. Strong emerging threat detection.
REST API per-wallet
**AML Risk Disposition**
ScoreTierOnboardingTradingSAR Trigger
0–30
Low risk
Approved
Transfer Hook approves
No
31–70
Medium risk
Enhanced review (24h)
Approved but flagged — compliance reviews within 24h
If investigation confirms suspicious activity
71–100
High risk
Rejected
Transfer Hook rejects (Error 6006)
Yes — SAR filed if at $5,000 or above
**OFAC — Three-Layer Screening**
LayerMethodCatches
**1: Exact address**
Direct Solana wallet match against SDN addresses
Directly sanctioned wallets
**2: Fuzzy entity**
Entity name and alias matching via Chainalysis entity resolution
Slight name variations ("ACME Corp" versus "ACME Corporation LLC")
**3: 2-hop clustering**
Transaction graph analysis — wallets within 2 degrees of SDN entities
Proxy wallet strategies, indirect funding paths
**Continuous versus Onboarding Screening**
CheckpointWhenPerformed By
**Onboarding**
Once — at initial verification
Empire Stock Transfer
**Every transfer**
Continuous — on every ST22 transfer
Transfer Hook Controls 8–10 (on-chain)
**SDN list refresh**
Hourly plus emergency push
Platform OFAC oracle indexer
A wallet that was clean at onboarding but later added to the SDN list is blocked immediately on its next transfer attempt. This continuous re-screening is architecturally impossible in an application-layer compliance system — the Transfer Hook enforces it at the Solana runtime level.
***
#### 10. Wallet Verification (KYW)
**Purpose**
Every Solana wallet that will hold ST22 tokens must be cryptographically linked to a verified identity in Empire's Master Securityholder File. Unregistered wallets cannot receive ST22 tokens — the Transfer Hook rejects all transfers to unverified wallets (Control 15).
**Verification Process**
Copy
```
1. Investor provides Solana wallet address to Empire during onboarding
2. Empire sends Ed25519 signature challenge:
"EMPIRE-KYW-{timestamp}-{random_nonce}"
3. Investor signs the challenge with their wallet's private key
(proving they control the wallet)
4. Empire verifies the signature matches the provided wallet address
5. Empire registers the wallet in:
├─ Master Securityholder File (legal record)
└─ Transfer Hook whitelist (on-chain enforcement)
6. Wallet can now receive ST22 tokens
```
**One Wallet Per Identity**
Each verified identity is linked to a specific Solana wallet address. If an investor needs to change wallets (for example, lost key or hardware wallet upgrade), they must re-verify with Empire, and the old wallet is deregistered.
***
#### 11. Accredited Investor Verification
**US Persons — SEC Rule 501**
Empire verifies accreditation using one of these qualification paths:
PathThresholdAccepted Documentation
**Income**
$200,000 individual ($300,000 joint) in each of the 2 most recent years
IRS W-2, 1099, K-1, tax returns
**Net worth**
$1,000,000 or more excluding primary residence
Broker statements, bank statements, property appraisals
**Professional certification**
Series 7, 65, or 82 license
FINRA BrokerCheck verification
**Entity**
$5,000,000 or more in assets, or all equity owners accredited
Audited financials, formation documents
**Knowledgeable employee**
Of the private fund issuer
Employer certification
**Third-party letter**
Valid for 90 days
CPA, attorney, registered broker-dealer, or investment adviser letter
**Non-US Persons — Reg S**
Empire verifies that the investor is not a "U.S. person" per Reg S §230.902(k):
* Not a natural person resident in the United States.
* Not a partnership or corporation organized under US law.
* Not an estate or trust with a US executor, administrator, or trustee.
* Transaction occurs in an "offshore transaction."
**US Retail — Reg CF**
For Reg CF offerings, Empire applies the SEC Rule 100(a)(2) investment-limit determination based on the investor's annual income and net worth, plus the FINRA-registered funding portal's intermediation requirements.
**On-Chain Enforcement**
Empire's verification determination is reflected on-chain. Transfer Hook Controls 12 through 14 check the investor's status on every transfer. If accreditation lapses or KYC expires, transfers are blocked until re-verification.
***
#### 12. Transfer Hook Integration Map
Every Transfer Hook control that depends on Empire data:
ControlEmpire Data SourceUpdate FrequencyError on Failure
**1–6 (Custody)**
Ed25519 custody attestation
Every block (\~400ms)
6001 / 6002
**7 (KYC Status)**
Empire verified investor registry
At onboarding plus re-verification
6003
**8 (Accreditation)**
Empire accreditation determination
At onboarding plus annual refresh
6003
**9 (AML)**
Chainalysis plus TRM via Empire integration
Per transfer (cached 6h)
6006
**10 (Identity)**
Empire CIP verification
At onboarding
6003
**11 (Jurisdiction)**
Empire Reg D / Reg S / Reg CF determination
At onboarding
6003
**12 (Age)**
Empire DOB verification
At onboarding
6003
**13 (Classification)**
Empire investor type classification
At onboarding
6003
**14 (Expiry)**
Empire KYC expiry date
Continuous — blocks expired
6003
**15 (Wallet)**
Empire MSF wallet registration
At KYW plus wallet changes
6004
**24 (Holding Period)**
Empire jurisdiction flag (US / Non-US / Reg CF)
Set at onboarding — immutable
6024
**30–34 (OFAC)**
Empire onboarding plus platform oracle (continuous)
Hourly refresh plus per-transfer
6003–6005
**35–38 (Protective Conversion)**
Empire custody records plus adverse event triggers
Event-driven
6008
**Data Flow Summary**
Copy
```
EMPIRE STOCK TRANSFER
│
├──── Custody balance ────────► CustodyOracle (on-chain, per block)
│ └─► Control 1 reads per transfer
│
├──── Investor registry ──────► Controls 7–14 read per transfer
│ (KYC, KYB, accreditation, (whitelist + status checks)
│ jurisdiction, wallet)
│
├──── AML scoring ────────────► AMLOracle (on-chain, cached 6h)
│ (via Chainalysis + TRM) └─► Control 9 reads per transfer
│
├──── OFAC screening ─────────► OFACOracle (on-chain, hourly)
│ (onboarding + continuous) └─► Controls 30–34 per transfer
│
└──── Adverse event triggers ─► Controls 35–38 (protective conversion)
(bankruptcy, enforcement,
loss of services)
```
***
#### 13. Protective Conversion Mechanics
Controls 35 through 38 implement automatic conversion of Common B shares to common stock upon defined adverse events — protecting investors even if the issuer or the platform fails.
**Trigger Events**
ControlTriggerDetectionAction
**PC-35**
Issuer bankruptcy filing
EDGAR 8-K detection (Layer 9) plus manual notification
Common B automatically converts to common stock per Certificate of Designation
**PC-36**
SEC enforcement action or criminal indictment of officer or director
EDGAR 8-K detection plus SEC notification
Same — automatic conversion
**PC-37**
Loss of Empire Stock Transfer services
Empire notification plus operational detection
Same — custody transfers to successor entity
**PC-38**
Material breach of tripartite agreement
Determination by the platform plus Empire
Conversion at discretion of non-breaching parties
**Conversion Mechanics**
Copy
```
TRIGGER EVENT DETECTED
│
├─ On-chain: Controls 35–38 activate
│ └─ ST22 transfers for affected mint halted (preventive)
│
├─ Off-chain: Empire initiates conversion process
│ ├─ Empire updates MSF: Common B shares → Common A shares
│ ├─ Investors now hold common stock (not tokenized)
│ ├─ Standard transfer agent processes apply
│ └─ Investors can exercise shareholder rights directly
│
└─ Result: investor equity claim survives issuer distress
regardless of blockchain infrastructure status
```
**Why This Matters**
Protective conversion is the safety valve separating Category 1 Model B from Category 2. In a Category 2 architecture, if the platform fails, investors may be left holding tokens with no underlying claim. In Category 1, protective conversion ensures investors retain genuine equity ownership (common stock held at Empire) even if the platform, CEDEX, and the entire Solana blockchain ceased to exist.
***
#### 14. Tripartite Agreement Structure
**Three Parties**
PartyResponsibilities
**Issuer**
Board resolution, Certificate of Designation, share deposit, ongoing SEC reporting, cooperation with regulatory inquiries
**Groovy Company, Inc.**
Technical infrastructure (ST22 minting, Transfer Hook, CEDEX, oracle relays), platform operations, compliance monitoring
**Empire Stock Transfer**
Irrevocable custody, investor onboarding (KYC, KYB, AML, OFAC), MSF maintenance, Ed25519 attestation, regulatory compliance
**Key Terms**
TermDetail
**Custody**
Irrevocable, perpetual. Empire cannot release shares to issuer.
**Attestation**
Empire authorizes Ed25519 signing per Solana block
**Fee structure**
5% of all ST22 transactions (distribution per fee config)
**Onboarding authority**
Empire is sole investor onboarding authority — non-negotiable
**Data handling**
Investor PII stays at Empire. The platform receives verification status only.
**Termination**
Triggers protective conversion (Control 37). No unilateral termination without investor protection.
**Dispute resolution**
Governed by the State of Wyoming
**Duration**
Co-terminous with ST22 token existence. No expiration.
***
#### 15. Conflict of Interest Disclosure
**Patrick Mokros serves as both Chief Operating Officer of Groovy Company, Inc. and Founder of Empire Stock Transfer.** This dual role is fully disclosed.
**Disclosure Framework**
AspectHandling
**Public disclosure**
Disclosed in all SEC filings (10-K, 10-Q, 8-K), whitepaper, pitch deck, and legal documents
**Related party transactions**
All transactions between Groovy Company, Inc. and Empire Stock Transfer automatically classified as related party transactions
**Approval requirement**
Material Empire-related decisions require Audit Committee review per the platform's Related Party Policy
**Fee arrangements**
Standard custody and onboarding fees — modified fee arrangements require CEO and Compliance Officer approval
**Equity or partnership arrangements**
Require full Board approval
**Why the Dual Role Exists**
The dual role provides an operational advantage: direct coordination between platform operations and custody / onboarding operations without inter-company communication latency. For a platform that requires per-block custody attestation (\~400ms), this tight integration is architecturally valuable.
The conflict is managed through disclosure, governance controls, and the structural independence of Empire's §17A regulatory obligations — Empire's regulatory duties to its registered companies exist independently of any relationship with Groovy Company, Inc.
***
#### 16. Empire Operational Continuity
**What Happens If Empire Services Are Disrupted?**
ScenarioImpactResolution
**Empire API temporary outage**
Custody relay stops updating → oracle stales → Error 6002 after 1 slot
Transfers halt automatically. Resume when API recovers.
**Empire API extended outage (over 24h)**
All ST22 transfers halted
P0 incident. Direct Empire coordination. Backup attestation from quarterly audit data.
**Empire business disruption**
Control 37 trigger — protective conversion
Common B converts to common stock. Investors hold equity at successor entity.
**Empire regulatory action**
Control 36 trigger — protective conversion
Same — conversion protects investors.
**Empire key compromise**
False attestations possible
Immediate Control 42 freeze. Empire revokes key. New key registered. 2-of-3 consensus before resume.
**Successor Custodian**
If Empire Stock Transfer ceases operations or loses §17A registration, the tripartite agreement requires designation of a successor transfer agent and custodian. Common B shares transfer to the successor, and the MSF transfers with them. Investors retain equity ownership throughout the transition.
The protective conversion mechanism (Control 37) activates automatically, converting tokenized Common B shares to standard common stock — ensuring investor rights are protected even during the transition period when no custody attestation is available.
***
#### 17. Module-Aware Custody Coverage
Empire's role is identical in structure across the three RWA Tokens production modules — every module uses Common Class B custody, Ed25519 attestation, KYC / KYB / AML / OFAC onboarding, and the same MSF data architecture. The module-specific differences sit at the asset-class layer, not the custody layer.
**17.1 Module 1 — Equities**
**Asset class.** Public-company equity securities sourced from OTC microcap, NASDAQ, AMEX, TSX, and other global exchanges.
**Empire's specific role.** Empire holds the issuer's Common Class B shares per the tripartite agreement, assigns the CUSIP, performs standard accreditation verification, and signs custody attestations every Solana block.
**Module-specific onboarding considerations.** Standard accreditation paths (Reg D income, net worth, professional certification, entity tests; Reg S non-US person determination; Reg CF eligibility for retail offerings).
**MSF metadata.** CUSIP, issuer name, share class, accreditation tier, jurisdiction.
**Custody attestation cadence.** Every block (\~400ms), identical to all other modules.
**17.2 Module 2 — Real Estate**
**Asset class.** Tokenized real-property assets held via single-asset entities.
**Empire's specific role.** Empire holds the Common Class B shares of the single-asset entity (the entity that holds title to the real-property asset). The economic exposure is to the single-asset entity's equity, which in turn holds the property.
**Single-asset entity structure.** Each Module 2 issuance corresponds to one single-asset entity (typically a Nevada corporation or comparable structure). The Certificate of Designation authorizes the Common Class B share class. Empire's custody is of the entity's equity, not of the property itself; the property is held by the entity per its title documentation.
**Module-specific onboarding considerations.** Standard accreditation paths apply. Module 2 issuances typically pair with a property identifier and appraisal-cycle metadata in the MSF.
**MSF metadata.** Property identifier, jurisdiction of the single-asset entity, share class, accreditation tier, current NAV reference, last appraisal date.
**Custody attestation cadence.** Every block (\~400ms), identical to all other modules. The Module 2 NAV oracle is a separate per-mint oracle that exists alongside Empire's custody attestation — the NAV oracle reports appraised value; Empire's custody attestation continues to report 1:1 backing of Common B shares.
**17.3 Module 3 — CORECM**
**Asset class.** Tokenization of US strategic minerals supply chain. CORECM means Carbon Ore, Rare Earth, and Critical Minerals. Frameworks include the USGS Critical Minerals List, the DOE Critical Materials Strategy, Section 232 of the Trade Expansion Act of 1962, Title III of the Defense Production Act, the Inflation Reduction Act critical-minerals provisions, Executive Order 14017, and the Energy Act of 2020. Carbon Ore covers DOE coal-derived rare-earth element recovery.
**Empire's specific role.** Empire holds the Common Class B shares of the basin-asset entity (the entity that holds the mineral basin or mining concession). As with Module 2, custody is of the entity's equity, not of the underlying physical asset.
**Module-specific onboarding considerations.** Empire applies enhanced KYC depth for Module 3 issuances. Enhanced depth includes verification of any federal-program eligibility constraints applicable to the basin (such as DOE coal-derived REE recovery program participation), confirmation of the investor's eligibility under any applicable export-control regime, and additional review for entity-investor UBO chains where federal counter-party diligence is appropriate.
**MSF metadata.** Basin identifier, USGS classification, mineral class, jurisdiction of the basin-asset entity, share class, accreditation tier, federal-action status.
**Custody attestation cadence.** Every block (\~400ms), identical to all other modules. The Module 3 Classification oracle is a separate per-mint oracle that exists alongside Empire's custody attestation — the Classification oracle reports federal classification status; Empire's custody attestation continues to report 1:1 backing of Common B shares.
**Federal-action coordination.** Empire is a coordinating party in the Module 3 federal-action freeze runbook (Incident Response Playbook Section 13). When a federal action is issued affecting a basin asset, Empire is notified within the 15-minute response SLA and participates in the protective response.
**17.4 Cross-Module Custody Properties**
Identical across modules:
* Irrevocable, perpetual Common Class B custody at Empire.
* Per-block Ed25519 custody attestation.
* 1:1 backing invariant enforced by Transfer Hook Control 1.
* KYC, KYB, AML, OFAC, and KYW onboarding authority resides solely with Empire.
* MSF as the legal record of ownership; blockchain as notification layer.
* Tripartite agreement structure (Issuer, Groovy Company, Inc., Empire).
* Protective conversion mechanics (Controls 35 through 38).
* Successor-custodian provisions for operational continuity.
The platform's structural guarantee — that no investor depends on the platform's solvency or operational continuity for their underlying equity claim — applies identically across all three modules because Empire's role applies identically.
***
#### Related Documentation
* **Solana Blockchain Foundation** — Why Solana, Token-2022, Transfer Hook, module-specific foundations
* **Architecture Decisions** — ADR-001 through ADR-012, with ADR-012 specifically covering Empire as sole onboarding authority
* **Security Model** — Threat model, key management, formal verification, module-specific threat surfaces, bug bounty
* **Infrastructure Overview** — Cloud architecture, environment separation, blockchain infrastructure
* **Network Configuration** — Program addresses, RPC endpoints, oracle PDAs, multi-signature addresses, production parameters
* **Deployment Guide** — Build, deploy, verify, upgrade, rollback procedures including Empire integration steps in module-specific initialization
* **Incident Response Playbook** — P0 through P3 runbooks; Empire coordination explicit in custody discrepancy and federal-action freeze runbooks
* **Oracle Integration Guide** — Ed25519 relay service implementation, custody oracle architecture, fail-safe cascade
* **Issuer Onboarding Guide** — Customer-facing nine-stage process including Empire custody and share deposit
* **Compliance Integration Guide** — BSA / AML program, OFAC sanctions, regulatory mapping, federal-action coordination
* **Smart Contract Reference** — CustodyOracle account schema, Control 1 implementation
* **Whitepaper Section 6** — Oracle Network architecture
***
*RWA Tokens · Empire Stock Transfer Integration · Groovy Company, Inc.*
# Compliance Integration Guide
### Compliance Integration Guide
**Regulatory Mapping · BSA/AML Program · On-Chain Verification · Module-Aware Coverage · Institutional Due Diligence**
Technical compliance reference for compliance officers, institutional risk teams, legal counsel evaluating the platform, and auditors verifying regulatory alignment. This document maps every regulatory obligation to the specific on-chain control or off-chain procedure that satisfies it, and details how compliance applies across all three production modules: Equities (Module 1), Real Estate (Module 2), and CORECM — Carbon Ore, Rare Earth, and Critical Minerals (Module 3).
The platform is operated by Groovy Company, Inc. The trading venue is CEDEX. The qualified-custody and onboarding anchor is Empire Stock Transfer.
> This document describes **what** must happen for each compliance obligation, **why** each obligation applies, and **how each obligation is verified**. Specific shell commands, RPC queries, and program-account schemas used by auditors for independent verification are maintained in the platform's internal compliance runbooks and Smart Contract Reference, and are accessible to authorized auditors under non-disclosure agreement.
***
#### Table of Contents
1. Regulatory Framework
2. Category 1 Model B Requirements
3. The 42 Controls — Regulatory Mapping
4. Empire Stock Transfer Compliance Architecture
5. BSA / AML Program
6. OFAC Sanctions Program
7. Holding Period Enforcement
8. Investor Eligibility
9. Record Keeping and Audit Trail
10. Protective Conversion
11. On-Chain Compliance Verification
12. Module-Specific Compliance
13. Module 3 Federal-Action Coordination
14. Institutional Due Diligence Checklist
15. Regulatory Contact Matrix
***
#### 1. Regulatory Framework
**1.1 Governing Authorities**
AuthorityJurisdictionPlatform Relevance
**SEC**
Federal securities law
Release No. 33-11412, Category 1 Model B, Reg D / Reg S / Reg CF, Form D, beneficial ownership
**FinCEN**
Bank Secrecy Act and AML
BSA compliance program, SAR / CTR filing, CIP, beneficial ownership
**OFAC**
Sanctions enforcement
SDN list screening, comprehensively sanctioned countries, secondary sanctions
**State securities regulators**
Blue Sky laws
State notice filings per Reg D
**Wyoming Secretary of State**
Issuer (Groovy Company, Inc.) incorporation
Wyoming Business Corporation Act, W\.S. 34-29-101 (Digital Asset Statute)
**Issuer states of incorporation**
Corporate governance
Certificate of Designation filing, Common B share class authorization
**USGS / DOE**
Critical minerals classification (Module 3)
USGS Critical Minerals List, DOE Critical Materials Strategy
**Federal trade and defense authorities**
Strategic minerals (Module 3)
Section 232 of the Trade Expansion Act of 1962, Defense Production Act Title III, Executive Order 14017, Energy Act of 2020
**FINRA**
Reg CF intermediation
Funding portal registration and oversight
**1.2 Primary Regulatory Citations**
CitationDateRelevance
**SEC Release No. 33-11412**
March 17, 2026
Establishes Digital Securities taxonomy. ST22 tokens classified as Category 5 Digital Securities.
**January 28, 2026 Joint Staff Statement**
January 28, 2026
Defines Category 1 (issuer-sponsored) versus Category 2 (third-party sponsored) tokenization. The platform operates under Category 1 Model B.
**SEC Crypto Task Force directive**
March 30, 2026
Common Class B shares specified as sole backing instrument for third-party ST22 tokens across all modules.
**April 13, 2026 SEC Staff Statement on Covered User Interface Providers**
April 13, 2026
Statement confirming that interface providers are not subject to broker-dealer registration when they do not engage in restricted activities.
**Securities Act of 1933**
As amended
Registration requirements; Reg D (§230.501–506), Reg S (§230.901–905), and Reg CF (§227.100–504) exemptions.
**Securities Exchange Act of 1934 §17A**
As amended
Transfer agent registration requirements. Empire Stock Transfer's compliance basis.
**Bank Secrecy Act (31 U.S.C. §5311)**
As amended
AML program requirements, CIP, CTR / SAR filing, recordkeeping.
**31 CFR Part 1010**
As amended
FinCEN regulations implementing the BSA.
**GENIUS Act**
Enacted
USDC and PYUSD stablecoin settlement framework.
**Wyoming W\.S. 34-29-101**
As amended
Wyoming Digital Asset Statute — statutory support for DLT-based securities.
**UCC Article 8**
Uniform
ST22 transfers on CEDEX constitute effective instructions to update Empire Master Securityholder File per §8-102(a)(8).
**USGS Critical Minerals List**
Most recent designation
Module 3 classification baseline.
**DOE Critical Materials Strategy**
Most recent edition
Module 3 classification baseline.
**Section 232 of the Trade Expansion Act of 1962**
As amended
Module 3 strategic-minerals federal-action source.
**Defense Production Act Title III**
As amended
Module 3 federal-action source.
**Executive Order 14017 (America's Supply Chains)**
February 24, 2021
Module 3 critical-minerals supply-chain policy basis.
**Inflation Reduction Act critical-minerals provisions**
August 16, 2022
Module 3 federal incentive and eligibility framework.
**Energy Act of 2020**
December 27, 2020
Module 3 critical materials and DOE coal-derived REE recovery basis.
**1.3 Mathematical versus Legal Enforcement**
DimensionLegal EnforcementThe Platform's Mathematical Enforcement
**Timing**
After violation (detective)
Before violation (preventive) — transaction reverts
**Certainty**
Subject to interpretation
Binary: compliant or blocked
**Dependence**
Good faith of intermediaries
Solana runtime — cannot be circumvented
**Override**
Administrative discretion
No override exists — immutable program logic
**Audit**
Reconstructed from logs
Immutable on-chain record per transaction
**Speed**
Weeks to months
\~400ms (one Solana block)
***
#### 2. Category 1 Model B Requirements
Release No. 33-11412 and the January 28, 2026 Joint Staff Statement establish seven requirements for Category 1 Model B compliance. The platform satisfies all seven across all three modules.
RequirementImplementationStatusVerification
**1. Direct issuer authorization**
Board resolution required before Common B creation. Corporate action of the issuer — not the platform.
Binding
Board resolution on file with Empire and the platform
**2. Official shareholder register**
Empire Master Securityholder File — DLT-integrated. Certificate of Designation filed with the issuer's state of incorporation.
Binding
Empire MSF plus state filing
**3. Regulated custody**
Empire Stock Transfer — SEC §17A-registered qualified custodian. Irrevocable custody.
Binding
Custody oracle attestation per block
**4. True equity backing**
1:1 Common Class B shares. Issuer-designated voting, dividends, liquidation per Certificate of Designation.
Binding
Ed25519 attestation every \~400ms
**5. Clear ownership chain**
CUSIP assigned per Common B class (Module 1); property identifier (Module 2); basin identifier (Module 3). UCC Article 8 transfer mechanics.
Binding
Empire records
**6. Investor protection**
42 Transfer Hook controls plus protective conversion triggers (Controls 35–38).
Binding
On-chain verification (Section 11)
**7. Token standard compliance**
SPL Token-2022 with Transfer Hook extension on Solana Mainnet-Beta.
Binding
Mint account extensions query
**Category 1 versus Category 2**
DimensionCategory 1 Model B (the platform)Category 2 (third-party sponsored)
Issuer authorization
Required — board resolution
Not required
Counterparty risk
None — direct ownership
Significant — intermediary holds assets
Custody
Empire §17A qualified custodian
Varies — often unregulated
DLT in official records
Yes — Empire MSF
Not typically
Onboarding
Empire — sole authority
Third-party, platform-dependent
Compliance enforcement
42 immutable Transfer Hook controls
Application-layer — bypassable
***
#### 3. The 42 Controls — Regulatory Mapping
Every Transfer Hook control maps to a specific regulatory obligation. The 42 controls apply identically across all three modules; module-specific extensions are documented in Section 12.
**Custody Verification (Controls 1–6)**
ControlFunctionRegulatory BasisError
**CV-01**
Verify Empire custody balance matches token supply — per block (\~400ms)
Category 1 Model B Req. 3 (regulated custody)
6001
**CV-02**
Confirm 1:1 ratio (supply ≤ custodied Common B) — per transfer
Category 1 Model B Req. 4 (true equity backing)
6001
**CV-03**
Confirm Empire Stock Transfer operational status — per transfer
Exchange Act §17A
6002
**CV-04**
Ed25519 oracle health and latency — continuous
Category 1 Model B Req. 7 (token standard compliance)
6002
**CV-05**
Asset-identifier match — custodied shares match CUSIP, property, or basin assignment — per transfer
Category 1 Model B Req. 5 (clear ownership chain)
6001
**CV-06**
Wallet registered in Empire MSF under UCC Article 8 — per transfer
Category 1 Model B Req. 2 (official shareholder register)
6002
**Investor Verification (Controls 7–14)**
ControlFunctionRegulatory BasisError
**IV-07**
Block unverified wallets — Empire KYC required
BSA CIP (31 CFR §1020.220)
6003
**IV-08**
Block ineligible investors — Reg D (US accredited), Reg S (non-US), Reg CF (US retail)
Securities Act §4(a)(2), Reg D Rule 501, Reg S, Reg CF
6003
**IV-09**
AML risk scoring — Chainalysis KYT plus TRM Labs
BSA (31 U.S.C. §5318), 31 CFR §1010.210
6006
**IV-10**
Verified identity linked to wallet
BSA CIP, FinCEN CDD Rule
6003
**IV-11**
Block prohibited jurisdictions (comprehensively sanctioned)
OFAC regulations (31 CFR Parts 510, 515, 542, 560, 589)
6003
**IV-12**
Block minors from all trading
State securities laws, platform policy
6003
**IV-13**
Track investor classification (accredited, institutional, non-US, Reg CF)
Reg D Rule 501, Reg S, Reg CF
6003
**IV-14**
Require re-verification when KYC or accreditation expires
BSA ongoing due diligence, FinCEN CDD Rule
6003
**Position Limits (Controls 15–19)**
ControlFunctionRegulatory BasisError
**PL-15**
Wallet registration — Empire MSF whitelist required
Exchange Act §17A (transfer agent records)
6004
**PL-16**
Wallet concentration at or below 4.99% of supply
Market manipulation prevention (Exchange Act §9, §10)
6020
**PL-17**
Velocity limit — maximum 50 transactions per hour per wallet
Wash trading prevention
6022
**PL-18**
Cross-wallet clustering detection
Coordinated activity detection
6023
**PL-19**
Cumulative position tracking
Beneficial ownership monitoring
6020
**Circuit Breakers (Controls 20–23)**
ControlFunctionRegulatory BasisError
**CB-20**
Halt on price move above 10% in 5 minutes — 15-minute cooldown
NYSE Rule 80B equivalent, SEC market structure
6005
**CB-21**
Block single trade with price impact above 2% versus TWAP
SEC market manipulation prevention
6021
**CB-22**
Velocity limit enforcement — per-wallet transaction rate
Flash crash prevention
6022
**CB-23**
Halt all trading if custody oracle fails
Fail-safe — data integrity
6002 / 6038
**Holding Period Enforcement (Controls 24–29)**
ControlFunctionRegulatory BasisError
**HP-24**
Rule 144 (6 months, US accredited); Reg S (12 months, non-US); Reg CF (12 months, US retail)
Securities Act Rule 144; Reg S §230.903; Reg CF §227.501
6024
**HP-25**
Jurisdiction flag verification
Reg S Category 1 (equity of non-reporting issuers); Reg CF retail eligibility
6024
**HP-26**
Purchase timestamp immutability
Securities Act (no backdating)
—
**HP-27**
Timer cannot be shortened by governance
Statutory minimum enforcement
—
**HP-28**
Per-investor-mint tracking (one account per pair)
Individual investor compliance
—
**HP-29**
Reg S US-person check during compliance period
Reg S §230.903(b) — flowback prevention
6024
**Sanctions Compliance (Controls 30–34)**
ControlFunctionRegulatory BasisError
**SC-30**
Exact wallet address match against SDN list
OFAC SDN screening (50 Fed. Reg. 5342)
6003 / 6004
**SC-31**
Fuzzy entity name matching for entity investors
OFAC guidance on name matching
6003 / 6004
**SC-32**
2-hop graph clustering — funding source analysis
OFAC secondary sanctions, proxy detection
6003 / 6004
**SC-33**
Continuous re-screening (every transfer, not just onboarding)
OFAC ongoing screening requirement
6005
**SC-34**
Blacklist enforcement — confirmed matches permanently blocked
OFAC blocking requirements
6003
**Protective Conversion (Controls 35–38)**
ControlTriggerActionRegulatory Basis
**PC-35**
Issuer bankruptcy filing
Automatic conversion of Common B to common stock
Investor protection — Certificate of Designation
**PC-36**
SEC enforcement action or criminal indictment
Automatic conversion
Investor protection
**PC-37**
Loss of Empire Stock Transfer services
Automatic conversion
§17A continuity, investor protection
**PC-38**
Material breach of tripartite agreement
Conversion at the platform's plus Empire's discretion
Contract enforcement
**Record Keeping and Governance (Controls 39–42)**
ControlFunctionRegulatory BasisError
**RK-39**
Immutable on-chain compliance audit trail per transfer
BSA recordkeeping (31 CFR §1010.410), Securities Act
—
**RK-40**
Hash chain verification of audit record integrity
Data integrity
—
**GOV-41**
Controlled migration — upgrades in progress
Governance protocol
6041
**REG-42**
Regulatory compliance freeze — immediate halt
Legal Counsel plus 3-of-5 multi-signature. No timelock. Used for SEC enforcement, court orders, FinCEN SAR investigations, OFAC emergency designations, active exploits, and Module 3 federal actions.
6042
***
#### 4. Empire Stock Transfer Compliance Architecture
**4.1 Empire's Dual Role**
RoleScopeRegulatory Basis
**Qualified Custodian**
Holds all Common Class B shares in irrevocable, perpetual custody. Maintains Master Securityholder File. Ed25519 attestation every \~400ms.
Exchange Act §17A; SEC custody requirements
**Sole Investor Onboarding Authority**
KYC (individuals), KYB (entities), AML (Chainalysis KYT plus TRM Labs), OFAC / SDN screening, wallet verification.
BSA CIP (31 CFR §1020.220); FinCEN CDD and Beneficial Ownership Rules
The platform does not perform investor onboarding. The platform Portal routes to Empire's dashboard for all verification. This architectural decision ensures that investor verification is performed by a regulated entity with §17A obligations — not by the platform operator.
**4.2 Empire Verification Types**
VerificationIndividual (KYC)Entity (KYB)
**Identity**
Government-issued photo ID, full legal name, DOB, SSN or ITIN
Entity formation documents, registration number, EIN
**Address**
Residential proof of address
Principal business address
**Accreditation**
Income ($200K+ individual, $300K+ joint), net worth ($1M+ excluding residence), or professional certification (Series 7, 65, 82)
$5M+ assets, or all equity owners accredited
**Beneficial ownership**
N/A
UBO at 25% or higher ownership threshold
**OFAC screening**
SDN list check
SDN list check plus entity officer and director check
**AML scoring**
Chainalysis KYT plus TRM Labs wallet risk score
Same plus entity risk assessment
**Wallet**
Solana wallet address linked to verified identity
Same — per authorized signer
**4.3 Empire Credentials**
CredentialDetail
SEC registration
Section 17A of the Securities Exchange Act of 1934
Operating since
2006
Companies served
530+ publicly traded companies
Geographic scope
Operations across 5 continents
DLT integration
Master Securityholder File with DLT record per Category 1 Model B
Conflict disclosure
Patrick Mokros serves as Chief Operating Officer of Groovy Company, Inc. and Founder of Empire Stock Transfer. The dual role is fully disclosed; all transactions between the two entities are classified as related-party transactions and subject to Audit Committee review per the platform's Related Party Policy.
***
#### 5. BSA / AML Program
**5.1 Program Elements**
ElementImplementationCFR Reference
**Customer Identification Program (CIP)**
Empire performs four-pillar identity verification at onboarding
31 CFR §1020.220
**Customer Due Diligence (CDD)**
Risk-based due diligence at onboarding plus ongoing monitoring
31 CFR §1010.210
**Beneficial Ownership**
Empire identifies UBOs at 25% or higher for all entity investors
31 CFR §1010.230
**Transaction Monitoring**
Transfer Hook Controls 9 and 11 through 15 screen every transfer. Chainalysis and TRM Labs analyze 200+ behavioral features.
31 CFR §1010.210
**Suspicious Activity Reports**
Empire files SARs with FinCEN for transactions at $5,000 or above meeting BSA criteria
31 CFR §1010.320
**Currency Transaction Reports**
Fiat on-ramp transactions at $10,000 or above trigger CTR filing
31 CFR §1010.311
**Recordkeeping**
5-year retention for KYC, KYB, and AML records. 7-year retention for transaction records.
31 CFR §1010.410
**Independent Testing**
Annual external audit of AML program effectiveness
31 CFR §1010.210(b)
**Compliance Officer**
Designated BSA compliance officer
31 CFR §1010.210(b)
**Training**
Annual AML training for all staff. Quarterly for compliance officers.
31 CFR §1010.210(b)
**5.2 Three-Layer AML Architecture**
The platform's AML defense operates in three layers, each handling a different point in the investor lifecycle:
**Layer 1 — Empire Onboarding (one-time plus periodic refresh).** Performed by Empire Stock Transfer at investor onboarding and on each periodic refresh. Includes identity verification (CIP), accreditation verification (Reg D Rule 501; Reg S non-US person determination; Reg CF eligibility), beneficial-ownership identification for entity investors, OFAC and SDN screening, AML risk assessment, and wallet registration in the Master Securityholder File.
**Layer 2 — Transfer Hook (every transfer, real-time).** Enforced by the on-chain Transfer Hook program at the Solana runtime level. Every transfer evaluates Controls 1 through 6 (custody verification via Ed25519), Controls 7 through 14 (investor eligibility), Controls 8 through 10 (OFAC re-screening against current SDN list), Control 11 (AML risk score check), Control 24 (holding period enforcement), and Controls 15 through 42 (position limits, circuit breakers, audit trail).
**Layer 3 — Platform Analytics (continuous).** Off-chain monitoring. Includes Chainalysis KYT real-time transaction monitoring, TRM Labs behavioral pattern analysis, volume-spike detection (100x threshold), cross-wallet clustering for coordinated activity, and SAR-trigger analysis.
**5.3 AML Risk Disposition**
ScoreTierActionSAR Trigger
0–30
Low
Approve — transfer proceeds
No
31–70
Medium
Approve and flag — compliance reviews within 24 hours
If investigation confirms suspicious activity
71–100
High
Reject (Error 6006) — wallet blocked
Yes — SAR filed if at $5,000 or above
***
#### 6. OFAC Sanctions Program
**6.1 Three-Layer Screening**
LayerMethodCatches
**Layer 1: Exact address**
Direct Solana wallet match against SDN addresses
Directly sanctioned wallets
**Layer 2: Fuzzy entity**
Entity name and alias matching via Chainalysis entity resolution
Slight name variations ("ACME Corp" versus "ACME Corporation LLC")
**Layer 3: 2-hop clustering**
Transaction graph analysis — wallets within 2 degrees of SDN entities
Proxy wallet strategies, indirect funding paths
**6.2 Comprehensively Sanctioned Jurisdictions**
Transfer Hook Control 11 blocks wallets associated with OFAC comprehensively sanctioned jurisdictions:
JurisdictionCFR Reference
Iran
31 CFR Part 560
North Korea
31 CFR Part 510
Syria
31 CFR Part 542
Cuba
31 CFR Part 515
Crimea region
31 CFR Part 589
**6.3 Continuous Re-Screening**
OFAC screening is not a one-time onboarding event. Controls 8 through 10 re-screen every wallet on every ST22 transfer against the current SDN list (refreshed hourly plus emergency push). A wallet clean at onboarding but later added to the SDN list is blocked immediately on its next transfer attempt. This continuous re-screening is architecturally impossible in an application-layer compliance system; the Transfer Hook enforces it at the Solana runtime level.
**6.4 Staleness Safeguards**
SDN List AgeBehavior
0–24 hours
Normal operation — screening on every transfer
24–48 hours
Cached list used. P2 alert raised. OFAC indexer investigated.
Above 48 hours
All transfers halt — Error 6005 until SDN list refreshed
**6.5 Module 3 Secondary Sanctions Considerations**
Module 3 issuances may involve basin-asset entities operating in or sourcing materials from jurisdictions where US secondary sanctions apply. Empire applies enhanced screening for Module 3 entity investors and basin-asset issuers, including review of supply-chain counterparty exposures where federal counter-party diligence is appropriate.
***
#### 7. Holding Period Enforcement
**7.1 On-Chain Mechanism**
Transfer Hook Control 24 enforces mandatory holding periods at the Solana runtime level. This is not a contractual agreement — it is mathematically enforced code that rejects transfers before the statutory period elapses.
Investor TypeExemptionHolding PeriodEnforcementStatutory Basis
US accredited
Reg D
6 months (15,778,800 seconds)
On-chain (Control 24)
Securities Act Rule 144(d)
Non-US
Reg S
12 months (31,536,000 seconds)
On-chain (Control 24)
Reg S §230.903(b)(3)
US retail
Reg CF
12 months (31,536,000 seconds)
On-chain (Control 24)
Reg CF §227.501
**7.2 HoldingPeriodAccount**
A per-investor-per-mint state account is created at token delivery. The account records the purchase timestamp (set by the Solana runtime clock — never by user input), the jurisdiction flag (US / Non-US / Reg CF), the holding period in seconds (immutable per investor type), and the lock status.
**7.3 Properties**
PropertyEnforcement
Cannot be shortened
Holding period seconds are hard-coded program constants — governance cannot reduce below statutory minimum
Cannot be backdated
Purchase timestamp is set by the Solana runtime clock at transaction execution
Cannot be overridden
No administrative override path. The platform cannot unlock a holding period early.
Per-investor tracking
One HoldingPeriodAccount per investor and per mint
Jurisdiction immutable
Set by Empire at onboarding. Cannot be changed post-delivery.
**7.4 Verification**
Auditors verify holding period enforcement by querying the HoldingPeriodAccount for a specific investor-mint pair. The query returns the jurisdiction (US, Non-US, or Reg CF), the purchase timestamp, the holding period in seconds, and the lock status. Verification methodology is documented in the Smart Contract Reference and the platform's compliance runbooks.
***
#### 8. Investor Eligibility
**8.1 Accredited Investor Definition (SEC Rule 501)**
Qualification PathThreshold
**Income**
$200,000 individual ($300,000 joint) in each of the 2 most recent years with reasonable expectation of continuance
**Net worth**
$1,000,000 or higher excluding primary residence
**Professional certification**
Series 7, 65, or 82 license holders
**Entity**
$5,000,000 or higher in assets, or all equity owners accredited
**Knowledgeable employee**
Of the private fund issuer
**8.2 Verification by Empire**
Empire Stock Transfer performs all accreditation verification. Accepted methods include:
* Third-party accreditation letter (valid 90 days).
* Tax return verification (IRS Form W-2, 1099, K-1).
* Account statements (broker-dealer, bank).
* Professional license verification.
* Entity documentation (audited financials, formation documents).
**8.3 Reg S Investor Qualification**
Non-US investors must satisfy Reg S requirements:
* Not a "US person" per Reg S §230.902(k).
* Transaction occurs in an "offshore transaction."
* No "directed selling efforts" into the United States.
* Verified by Empire Stock Transfer.
**8.4 Reg CF Investor Qualification**
US retail investors purchasing in Reg CF offerings must satisfy the SEC Rule 100(a)(2) investment-limit determination:
* Annual income or net worth determines the maximum amount the investor may purchase across all Reg CF offerings in a 12-month period.
* A FINRA-registered funding portal must intermediate the offering.
* Empire performs the eligibility determination at onboarding and the funding portal applies the per-offering investment limit at purchase.
**8.5 Investor-Type Determination at Onboarding**
Empire's onboarding determination flags each investor as US accredited (Reg D), non-US (Reg S), or US retail (Reg CF). The flag is recorded in the Master Securityholder File and on chain via the HoldingPeriodAccount jurisdiction field. The flag is immutable after delivery — an investor's classification cannot be changed post-purchase.
***
#### 9. Record Keeping and Audit Trail
**9.1 Dual Record Architecture**
Record LayerWhatRetentionRegulatory Basis
**On-chain (immutable)**
Every ST22 transfer with all 42 control results, amounts, timestamps, wallet addresses, error codes
Permanent (Solana ledger)
BSA §1010.410; Securities Act
**Empire Stock Transfer**
KYC and KYB records, accreditation documents, MSF entries, SAR and CTR filings
5–7 years per BSA
31 CFR §1010.410
**Platform compliance database**
Oracle attestation history, circuit breaker events, AML scores, OFAC screening results, Module 2 NAV records, Module 3 federal-action records
7 years
BSA plus Securities Act
**9.2 On-Chain Audit Record**
Every successful transfer emits a TransferValidated event including the mint, sender, recipient, amount, timestamp, and a signal that all 42 controls passed. Every rejected transfer returns a specific error code identifying which control failed. Both outcomes are recorded on the Solana ledger — immutable and independently verifiable by any party with an RPC connection.
**9.3 Retention Summary**
Record TypeRetentionRegulatory Basis
KYC records
5 years after account closure
BSA
KYB records
5 years after relationship ends
BSA, FinCEN CDD
Transaction records
7 years
Securities Act, IRS
Accreditation records
5 years
Reg D
OFAC screening records
5 years
OFAC regulations
SAR filings
5 years from filing
BSA
CTR filings
5 years
BSA
Audit reports
5 years
BSA
Training records
5 years
BSA
Module 2 appraisal records
7 years
Real-property records standard; SEC offering documentation retention
Module 3 federal-classification records
Permanent
Federal record-keeping standard for strategic-minerals diligence
On-chain transfer records
Permanent
Solana ledger
***
#### 10. Protective Conversion
**10.1 Trigger Events**
Controls 35 through 38 implement automatic protective conversion — converting Common B shares to common stock upon adverse events, protecting investors even if the issuer fails:
TriggerControlActionInvestor Impact
Issuer bankruptcy filing
PC-35
Automatic conversion per Certificate of Designation
Investor holds common stock through bankruptcy proceedings
SEC enforcement action
PC-36
Automatic conversion
Investor holds common stock — exits tokenized structure
Criminal indictment (officer or director)
PC-36
Automatic conversion
Same
Loss of Empire services
PC-37
Automatic conversion
Investor holds common stock — custody transfers
Material breach of tripartite agreement
PC-38
Conversion at the platform's plus Empire's discretion
Case-by-case determination
**10.2 Purpose**
Protective conversion ensures that investors retain genuine equity ownership (common stock) even if the tokenization infrastructure fails. This is the safety valve that separates Category 1 Model B from Category 2 — the investor is never left holding a token with no underlying claim.
**10.3 Module-Specific Protective Conversion**
The same four trigger types apply across all modules. Module-specific considerations:
* **Module 1 (Equities).** The investor receives common stock of the issuer corporation upon conversion.
* **Module 2 (Real Estate).** The investor receives common stock of the single-asset entity that holds the property. The single-asset entity continues as a going concern post-conversion; the investor's claim is now to the entity's equity directly rather than to a tokenized representation.
* **Module 3 (CORECM).** The investor receives common stock of the basin-asset entity that holds the mineral basin or mining concession. As with Module 2, the entity continues as a going concern, and the investor holds direct equity.
***
#### 11. On-Chain Compliance Verification
Auditors and institutional risk teams independently verify every compliance claim without relying on the platform's representations. The platform exposes verification methodology and reproducible procedures through the Smart Contract Reference, the platform's published audits (Quantstamp, Halborn, OtterSec, Certora), and on-chain queries that any party with a Solana RPC connection can perform.
**11.1 Verifications Required Across All Modules**
VerificationWhat Is Confirmed
Transfer Hook permanently attached
The Token-2022 mint extension stores the Transfer Hook program ID; the SPL Token-2022 standard makes attachment permanent
1:1 custody backing
The custody oracle reports `common_b_balance` greater than or equal to `token_supply`; Ed25519-verified; no discrepancy detected
Holding period enforcement
The HoldingPeriodAccount records the correct jurisdiction-specific period; lock status accurate
Global Pool permanently locked
LP mint supply is zero, LP mint authority is `None`, pool program upgrade authority is `None`
OFAC oracle current
The OFAC oracle's `is_fresh` status is true; entry count consistent with the published SDN list
SecurityConfig parameters
All parameters within governance-approved ranges; pause flag false during normal operation
Holding period constant immutability
Verified by Certora invariant E.4 plus examination of deployed program bytecode against audited source
**11.2 Module-Specific Verifications**
Module 2 and Module 3 add verification points for the module-specific oracles:
VerificationModuleWhat Is Confirmed
NAV oracle freshness
Module 2
`last_reappraisal` within `nav_reappraisal_max_age_secs`; appraiser signature verified
NAV deviation within bounds
Module 2
On-chain price within `nav_deviation_max_bps` of NAV
Classification oracle freshness
Module 3
USGS and DOE classification within `classification_max_age_secs`
Federal-action status
Module 3
Classification oracle reports current federal-action status for the basin
**11.3 Independent Verifiability**
Every verification listed above can be performed without the platform's cooperation. The on-chain accounts are public; any Solana RPC provider returns the data; the Ed25519 signatures are verifiable using Empire's published public key; the program bytecode is verifiable against published audit hashes. This is a structural property of Category 1 Model B, not a discretionary practice of the platform.
***
#### 12. Module-Specific Compliance
The 42 Transfer Hook controls apply identically across all three modules. Module-specific compliance considerations sit at the asset-class and federal-framework layer, not at the on-chain enforcement layer.
**12.1 Module 1 — Equities**
**Asset class.** Public-company equity securities sourced from OTC microcap, NASDAQ, AMEX, TSX, and other global exchanges.
**Compliance posture.** Standard Reg D, Reg S, and (where applicable) Reg CF offering exemptions. CUSIP-identified Common Class B share class. EDGAR pipeline integration provides issuer-disclosure intelligence to support investor-protection controls (Layer 9 IDOS).
**Empire onboarding considerations.** Standard accreditation paths. Investor-type classification flags Reg D, Reg S, or Reg CF.
**Module-specific records.** Issuer board resolution, Certificate of Designation filed with the issuer's state of incorporation, CUSIP assignment, EDGAR filings.
**12.2 Module 2 — Real Estate**
**Asset class.** Tokenized real-property assets held via single-asset entities.
**Compliance posture.** Same Category 1 Model B framework. Common Class B is issued by the single-asset entity that holds the property. Module-specific NAV oracle reports appraised value alongside Empire's per-block custody attestation; on-chain price is constrained to remain within governance-set deviation bounds of NAV.
**Empire onboarding considerations.** Standard accreditation paths. The investor's economic exposure is to the single-asset entity's equity; offering documentation discloses the property's specific risks (jurisdiction, title status, tenancy, environmental, insurance).
**Module-specific records.** Property identifier, appraisal-cycle metadata, single-asset entity formation documents, title diligence package, initial appraisal, periodic reappraisals.
**Module-specific compliance considerations.** NAV oracle staleness triggers a P1 incident under the Incident Response Playbook. NAV deviation outside `nav_deviation_max_bps` triggers a per-mint circuit breaker that pauses AMM trading on the affected mint until a fresh appraisal restores the on-chain price within bounds.
**12.3 Module 3 — CORECM**
**Asset class.** Tokenization of US strategic minerals supply chain. CORECM means Carbon Ore, Rare Earth, and Critical Minerals. Frameworks include the USGS Critical Minerals List, the DOE Critical Materials Strategy, Section 232 of the Trade Expansion Act of 1962, Title III of the Defense Production Act, the Inflation Reduction Act critical-minerals provisions, Executive Order 14017, and the Energy Act of 2020. Carbon Ore covers DOE coal-derived rare-earth element recovery.
**Compliance posture.** Same Category 1 Model B framework. Common Class B is issued by the basin-asset entity that holds the mineral basin or mining concession. Module-specific Classification oracle reports federal classification status from USGS and DOE feeds alongside Empire's per-block custody attestation.
**Empire onboarding considerations.** Empire applies enhanced KYC depth for Module 3 issuances. Enhanced depth includes verification of any federal-program eligibility constraints applicable to the basin (such as DOE coal-derived REE recovery program participation), confirmation of the investor's eligibility under any applicable export-control regime, and additional review for entity-investor UBO chains where federal counter-party diligence is appropriate.
**Module-specific records.** Basin identifier, USGS classification, mineral class, basin-asset entity formation documents, geological survey, mineral-rights documentation, federal-program participation records, federal-action history.
**Module-specific compliance considerations.** Classification oracle staleness triggers a P2 incident (P1 if staleness exceeds 48 hours; P0 if a federal-action notification arrives during staleness). Federal-action issuance against a basin asset is automatically a P0 — see Section 13.
***
#### 13. Module 3 Federal-Action Coordination
Federal actions affecting strategic minerals are a regulatory category unique to Module 3. They have no parallel in Module 1 (Equities) or Module 2 (Real Estate).
**13.1 What Constitutes a Federal Action**
Federal actions include:
* Executive Orders affecting strategic minerals (such as Executive Order 14017 and successor orders).
* Section 232 tariff or restriction orders issued under the Trade Expansion Act of 1962.
* Defense Production Act Title III orders.
* Department of Energy program changes affecting eligibility (such as changes to the DOE coal-derived REE recovery program).
* Inflation Reduction Act critical-minerals eligibility determinations.
* Court orders or regulatory directives specifically naming a basin or mineral classification.
**13.2 Detection**
The platform's Module 3 federal-action feed monitors federal sources (Federal Register, DOE program announcements, USGS classification updates, Department of Defense procurement directives) on a 5-minute cadence. New actions that match a basin or mineral class associated with an issued ST22 mint trigger an automatic P0 incident under the Incident Response Playbook (Section 13).
**13.3 Response Procedure**
Federal-action response is governed by the Incident Response Playbook Section 13. The procedure summarized:
1. Capture the federal action — issuing agency, action type, effective date, and scope.
2. Identify affected mints by mapping each Module 3 mint to its basin identifier, mineral class, and federal-program participation.
3. Activate Control 42 (regulatory freeze) on each affected mint — same Control 42 mechanism as SEC enforcement actions or court orders. Legal Counsel authorization plus 3-of-5 multi-signature; no timelock.
4. Notify Empire Stock Transfer within the 15-minute SLA.
5. Notify affected issuers (basin operators) and affected investors.
6. Update the Classification oracle with the federal-action status.
**13.4 Resolution**
The freeze remains active for the full duration that the federal action prohibits transfer or while substantial uncertainty about transfer status persists. Resolution requires the federal action to expire, be rescinded, the basin to be exempted, or the issuer to obtain an authorized variance — followed by Legal Counsel authorization, 3-of-5 multi-signature execution, Classification oracle update, and stakeholder notification.
**13.5 Investor and Issuer Communication**
Module 3 federal-action incidents involve a fourth external audience beyond Module 1 and Module 2 incidents: the federal agency. The platform's Communications Lead and Legal Counsel coordinate counsel-to-counsel communication with the issuing federal agency through the platform's outside SEC counsel where appropriate, and review all external communications before publication regardless of audience.
**13.6 Why This Matters Architecturally**
Federal-action coordination demonstrates that Category 1 Model B compliance scales beyond securities-law obligations to other federal regulatory frameworks. The same Control 42 freeze mechanism and the same Empire-coordinated response procedure handle SEC enforcement, court orders, FinCEN SAR investigations, OFAC emergency designations, and Module 3 federal actions — without a new on-chain primitive for each new regulatory category. The platform's compliance architecture is extensible by design.
***
#### 14. Institutional Due Diligence Checklist
For institutional investors, fund managers, or compliance teams evaluating the platform.
**Regulatory**
* Verify SEC Release No. 33-11412 applies (March 17, 2026).
* Confirm Category 1 Model B alignment (seven requirements — Section 2).
* Verify Empire Stock Transfer's §17A registration.
* Confirm Reg D, Reg S, and Reg CF offering frameworks as applicable to the issuance.
* Review Form D filing status for the issuance (where applicable).
* Verify no SEC enforcement actions against Groovy Company, Inc. (EDGAR query).
* Review the OFAC sanctions program (Section 6).
* Review the BSA / AML program elements (Section 5).
* For Module 3 issuances, review the basin's USGS classification, DOE Critical Materials status, and any pending federal action affecting the basin or mineral class.
**Custody**
* Verify Empire holds Common B shares in irrevocable custody.
* Verify Ed25519 attestation updating per block.
* Verify 1:1 backing ratio on-chain.
* Confirm zero-discrepancy production history.
* Review protective conversion triggers (Section 10).
**Technology**
* Verify the Transfer Hook is permanently attached to the mint.
* Verify all 42 controls are active by querying SecurityConfig.
* Verify Global Pool immutability (LP burn complete; pool program upgrade authority is `None`).
* Review audit reports (Quantstamp, Halborn, OtterSec, Certora).
* Review the six Certora formal-verification invariants.
* Verify holding period enforcement.
* For Module 2 issuances, verify NAV oracle freshness and deviation bounds.
* For Module 3 issuances, verify Classification oracle freshness and federal-action status.
**Operational**
* Review the conflict of interest disclosure (Patrick Mokros dual role).
* Verify multi-signature configuration (5-of-9 for upgrades; 3-of-5 for parameter and emergency).
* Review incident response procedures (Incident Response Playbook).
* Verify monitoring and alerting infrastructure (Datadog and PagerDuty escalation).
* Review the bug bounty program (refer to the Security Model).
* For Module 3 issuances, review the federal-action monitoring and response procedure (Incident Response Playbook Section 13).
***
#### 15. Regulatory Contact Matrix
MatterContactChannel
**Issuer onboarding**
Empire Stock Transfer plus the platform's issuer services
Through Empire's onboarding dashboard
**Compliance inquiries**
Compliance team
**Security vulnerabilities**
Security team
**SEC and regulatory**
Legal Counsel (JDT Legal)
Through the platform's SEC counsel coordination
**Empire Stock Transfer**
Empire compliance team
Through platform-Empire coordination
**Technical and CTO**
Frank Yglesias, Chief Technology Officer
**Module 3 federal-action**
Legal Counsel (JDT Legal)
Counsel-to-counsel through the platform's SEC counsel
**SAR Filing**
Empire Stock Transfer files SARs with FinCEN per 31 CFR §1010.320. The platform provides transaction data and AML analytics to support Empire's filing obligations. SAR filings are confidential — contents are not disclosed to the subject of the report.
**Regulatory Examination Support**
In the event of an SEC, FinCEN, OFAC, or federal-agency examination, Groovy Company, Inc. and Empire Stock Transfer cooperate fully. On-chain records are independently verifiable and cannot be altered. Off-chain records are maintained per the retention schedule in Section 9.3. For Module 3 issuances, federal-program participation records are maintained on a permanent retention basis appropriate to federal record-keeping standards.
***
#### Related Documentation
* **Solana Blockchain Foundation** — Why Solana, Token-2022, Transfer Hook, module-specific foundations
* **Architecture Decisions** — ADR-001 through ADR-012, including ADR-011 (three-module architecture) and ADR-012 (Empire as sole onboarding authority)
* **Security Model** — Threat model, key management, formal verification, module-specific threat surfaces, bug bounty
* **Infrastructure Overview** — Cloud architecture, environment separation, blockchain infrastructure
* **Network Configuration** — Program addresses, RPC endpoints, oracle PDAs, multi-signature addresses, production parameters
* **Deployment Guide** — Build, deploy, verify, upgrade, rollback procedures including module-specific initialization
* **Incident Response Playbook** — P0 through P3 runbooks; Module 3 federal-action freeze runbook (Section 13)
* **Empire Stock Transfer Integration** — Custody architecture, Ed25519 attestation, MSF, KYC / KYB / AML / OFAC, conflict of interest disclosure, module-aware custody coverage
* **Smart Contract Reference** — Transfer Hook control implementations, account schemas, error codes
* **Oracle Integration Guide** — Custody, OFAC, AML, NAV (Module 2), Classification (Module 3) relay architecture
* **Issuer Onboarding Guide** — Customer-facing nine-stage process
***
*RWA Tokens · Compliance Integration Guide · Groovy Company, Inc.*
# Transfer Hook Reference
### Transfer Hook Reference
**The 42 Security Controls · SPL Token-2022 · Module-Aware**
A standalone reference for the platform's Transfer Hook program — the single most consequential security primitive in the RWA Tokens architecture. This page documents what each of the 42 controls does, when it triggers, what it returns when it fails, and how it differs across the three production modules: Equities (Module 1), Real Estate (Module 2), and CORECM — Carbon Ore, Rare Earth, and Critical Minerals (Module 3).
For program-level documentation (instruction signatures, account schemas, PDA registry, event registry, state machines), see the **Smart Contract Reference**. For the formal specification submitted to regulators and auditors, see the **SPL Token-2022 Transfer Hook Technical Specification**.
***
#### Why This Page Exists
The 42 controls are referenced in dozens of platform documents — the Whitepaper, the Compliance Integration Guide, the Security Model, the Empire Stock Transfer Integration, the Architecture Decisions, the Incident Response Playbook, and the Smart Contract Reference. Each document covers the controls from its own angle.
This page is the canonical reference. When a control number appears anywhere in platform documentation, this is the page that defines it.
***
#### The Foundational Property
The Transfer Hook is the platform's foundational security guarantee. It rests on three properties of the SPL Token-2022 standard:
1. **Mandatory invocation.** Once a Token-2022 mint specifies a Transfer Hook program, the SPL Token-2022 runtime invokes the hook on every transfer of that token. The runtime — not the platform — enforces this.
2. **Permanent attachment.** A Transfer Hook cannot be removed from a mint after creation. SPL Token-2022 has no `removeTransferHook` instruction. Anyone — including Groovy Company, Inc. itself — is structurally incapable of detaching the hook.
3. **Atomic revert.** If the hook returns an error, the entire transfer transaction reverts. There is no path to a partially-completed transfer.
The combination means: every ST22 token transfer ever, for the entire existence of every ST22 mint, is validated against the 42 controls. There is no bypass. There is no exception. There is no override at the mint level.
***
#### How the Hook Executes
The 42 controls execute in two phases on every transfer:
Copy
```
PHASE 1 — SEQUENTIAL (critical path):
CV-01 through CV-06 → Custody verification
IV-07 through IV-14 → Investor eligibility
HP-24 → Holding period
PHASE 2 — PARALLEL (any failure reverts atomically):
PL-15 through PL-19 → Position limits
CB-20 through CB-23 → Circuit breakers
SC-30 through SC-34 → Sanctions compliance
PC-35 through PC-38 → Protective conversion
RK-39 through REG-42 → Audit trail and governance
EMIT:
TransferValidated event with all 42 results
```
Phase 1 controls are evaluated in order — each must pass before the next is evaluated. Phase 2 controls are evaluated together; a failure in any one reverts the whole transfer.
The hook reads multiple state accounts during validation: SecurityConfig, HoldingPeriodAccount, CustodyOracle, OFACOracle, AMLOracle, and (for Module 2 and Module 3) NAVOracle and ClassificationOracle. All reads are deterministic — the hook does not perform off-chain calls during execution.
***
#### Section 1 — Custody Verification (CV-01 through CV-06)
**Purpose.** Verify that every ST22 transfer is backed 1:1 by Common Class B shares held in Empire Stock Transfer custody. This is the structural difference between an ST22 and a synthetic on-chain token: the underlying shares physically exist, are held by a §17A-registered transfer agent, and are continuously attested.
**Mechanism.** Empire signs an Ed25519 attestation on every Solana block (\~400ms). The attestation contains the custodied Common Class B balance for the affected mint. The Transfer Hook reads this attestation on every transfer and verifies the 1:1 invariant.
IDControlTriggerError
CV-01
Custody balance match
Empire-attested Common B balance is less than on-chain ST22 supply
6001 — CustodyDiscrepancy
CV-02
1:1 ratio confirmation
Token supply exceeds custodied Common B for the affected mint
6001 — CustodyDiscrepancy
CV-03
Empire operational status
Empire reports degraded or suspended state
6038 — CustodyDiscrepancyHalt
CV-04
Ed25519 oracle health
Oracle attestation is stale beyond 1 Solana slot
6002 — CustodyOracleUnavailable
CV-05
Asset-identifier match
Custodied shares do not match the assigned identifier (CUSIP, property ID, or basin ID)
6038 — CustodyDiscrepancyHalt
CV-06
MSF wallet registration
Sender or receiver wallet not registered in Empire's Master Securityholder File
6007 — InvalidSigner
**Production record.** Across three beta issuances and over $7M of processed liquidity, zero custody discrepancy events have been recorded. The 1:1 backing invariant has been maintained at every Solana block.
**Module behavior.** Identical across all three modules. CV-05 verifies the assigned identifier — CUSIP for Module 1, property identifier for Module 2, basin identifier for Module 3.
***
#### Section 2 — Investor Verification (IV-07 through IV-14)
**Purpose.** Verify that the sender and receiver wallets are linked to Empire-verified identities meeting the appropriate offering exemption criteria. KYC, KYB, AML scoring, and OFAC screening are performed exclusively by Empire Stock Transfer — the platform does not perform investor onboarding.
**Mechanism.** Empire's Master Securityholder File (MSF) is the authoritative record of which wallets are registered, what jurisdiction the wallet's owner falls under, and what offering exemption applies. The Transfer Hook reads MSF state via the AML oracle and the SecurityConfig blacklist.
IDControlTriggerError
IV-07
KYC required
Wallet has no Empire KYC verification
6007 — InvalidSigner
IV-08
Accreditation eligibility
Investor not eligible under the mint's exemption — Reg D (US accredited), Reg S (non-US), Reg CF (US retail)
6007 — InvalidSigner
IV-09
AML risk score
Risk score above 70/100 (Chainalysis KYT or TRM Labs)
6006 — AMLHighRisk
IV-10
Identity-wallet linkage
Verified identity not linked to the wallet
6007 — InvalidSigner
IV-11
Jurisdiction
Wallet's jurisdiction is comprehensively sanctioned (Iran, North Korea, Syria, Cuba, Crimea, etc.)
6007 — InvalidSigner
IV-12
Age verification
Wallet owner under 18
6007 — InvalidSigner
IV-13
Investor classification
Track investor classification (accredited / institutional / non-US / Reg CF)
(Tracking only — no error)
IV-14
KYC expiry
KYC verification expired (annual re-verification required)
6007 — InvalidSigner
**Module behavior.** Module 1 and Module 2 share identical investor verification. Module 3 (CORECM) requires enhanced KYC depth — beneficial-ownership disclosure to ultimate owner is required for entity investors, given the federal-action sensitivity of critical-minerals assets.
***
#### Section 3 — Position Limits (PL-15 through PL-19)
**Purpose.** Enforce wallet concentration, velocity, and clustering limits to prevent market manipulation and coordinated activity.
**Mechanism.** SecurityConfig stores per-mint position parameters. The Transfer Hook reads these parameters on every transfer and rejects any transfer that would breach a position limit.
IDControlDefaultAdjustable RangeError
PL-15
Wallet whitelist
Wallet must be MSF-registered
Not adjustable
6007 — InvalidSigner
PL-16
Concentration cap
4.99% of supply (499 bps)
1.00% – 9.99% (100 – 999 bps)
6020 — WalletLimitExceeded
PL-17
Velocity cap
50 tx/hour per wallet
Governance-adjustable
6022 — VelocityExceeded
PL-18
Cross-wallet clustering
2-hop graph analysis
Not adjustable
6023 — CrossWalletDetected
PL-19
Cumulative position
Aggregate across linked wallets
Not adjustable
6020 — WalletLimitExceeded
**Module behavior.** Module 1 and Module 3 use the standard 4.99% cap. Module 2 (Real Estate) uses an issuer-configurable cap up to 9.99% — single-asset real-estate offerings often have natural concentration patterns where a single institutional investor holds a significant share.
***
#### Section 4 — Circuit Breakers (CB-20 through CB-23)
**Purpose.** Halt trading on extreme price movements, excessive single-trade impact, and oracle failures.
**Mechanism.** SecurityConfig stores per-mint circuit-breaker thresholds and cooldown durations. The Transfer Hook reads the TWAP from Pyth Network on every transfer and compares the proposed trade against the threshold.
IDControlDefaultAdjustable RangeError
CB-20
Price halt
30% move in 5 minutes; 24h cooldown
10% – 50%; 1h – 72h cooldown
6005 — CircuitBreakerActive
CB-21
Price impact cap
2% vs TWAP
1% – 5%
6021 — PriceImpactExceeded
CB-22
Velocity halt
Wallet > 30% daily sell
Not adjustable
6037 — DailySellLimitExceeded
CB-23
Oracle failure halt
Halt on custody oracle stale beyond 1 slot
Not adjustable
6038 — CustodyDiscrepancyHalt
**Module behavior.**
* Module 1 — standard circuit breakers.
* Module 2 — adds NAV-deviation breaker as part of CB-21. When the on-chain price deviates from the appraised NAV by more than `nav_deviation_max_bps`, the affected mint is paused on the AMM until a fresh appraisal restores the price within bounds. Returns Error 6021.
* Module 3 — CB-23 also pauses on Classification oracle failure beyond `classification_max_age_secs`.
**NAV-Deviation Breaker State Machine (Module 2)**
Copy
```
TRADING ──► NAV ORACLE UPDATE (per reappraisal cycle)
│
├─ Price within nav_deviation_max_bps → CONTINUE
│
▼
DEVIATION DETECTED ──► MINT PAUSED (per-mint, not platform-wide)
│
▼
AWAITING NEW APPRAISAL
│
├─ Fresh appraisal restores price → RESUME
├─ Governance adjusts threshold → RESUME
│
▼
TRADING (resumed)
```
***
#### Section 5 — Holding Period Enforcement (HP-24 through HP-29)
**Purpose.** Enforce statutory holding periods at the Solana runtime level. Investors cannot transfer ST22 tokens before the holding period elapses, regardless of platform state, governance action, or counterparty agreement.
**Mechanism.** Each investor-mint pair has a HoldingPeriodAccount PDA. The PDA records the purchase timestamp (set by the Solana runtime clock — never user input), the jurisdiction flag (US, Non-US, or Reg CF), and the holding period in seconds.
IDControlTriggerError
HP-24
Holding period elapsed
`(now - purchase_timestamp) < holding_period_secs`
6024 — TokensLocked
HP-25
Jurisdiction flag verification
Jurisdiction flag does not match HoldingPeriodAccount config
6007 — InvalidSigner
HP-26
Purchase timestamp immutability
Verified at PDA creation; cannot be modified post-creation
(Verified once)
HP-27
Timer non-shortenable
Holding period seconds are hard-coded constants
(Verified at compile time)
HP-28
Per-investor-mint tracking
One HoldingPeriodAccount per (investor, mint) pair
(Verified at PDA derivation)
HP-29
Reg S US-person check
Reg S investor attempting flowback to US person before period elapses
6024 — TokensLocked
**Holding period values (immutable program constants):**
JurisdictionHolding PeriodStatutory Basis
US Reg D (accredited)
15,778,800 seconds (\~6 months)
SEC Rule 144(d)(1)(ii)
Non-US Reg S
31,536,000 seconds (\~12 months)
SEC Regulation S Category 2
US Reg CF (retail)
31,536,000 seconds (\~12 months)
SEC Regulation Crowdfunding §227.501
**Module behavior.** Identical across all three modules. The same holding-period constants apply to Equities, Real Estate, and CORECM ST22 tokens.
***
#### Section 6 — Sanctions Compliance (SC-30 through SC-34)
**Purpose.** Enforce OFAC sanctions screening on every transfer using continuous re-screening against the current SDN list.
**Mechanism.** The OFAC Oracle aggregator service polls the U.S. Treasury OFAC SDN list hourly (with emergency push on Treasury-flagged updates). The Transfer Hook reads the OFAC oracle and the SecurityConfig blacklist on every transfer.
IDControlTriggerError
SC-30
Exact address match
Sender or receiver Solana wallet matches an SDN-listed wallet
6003 — SenderSanctioned, 6004 — ReceiverSanctioned
SC-31
Fuzzy entity match
Entity name or alias matches an SDN entity (for entity investors)
6003 / 6004
SC-32
2-hop graph clustering
Transaction graph analysis for proxy-wallet detection
6003 / 6004
SC-33
Continuous re-screening
Re-screen every wallet on every transfer against current SDN list
6005 — OfacOracleStale (if oracle stale > threshold)
SC-34
Blacklist enforcement
Confirmed matches added to per-mint blacklist; permanent block
6003 / 6004
**Production record.** Zero false-positive OFAC blocks across the beta period; one true-positive block (Iranian corporate structure mid-2025).
**Module behavior.** Identical across all three modules. Treasury maintains a special interest in critical-minerals supply-chain sanctions; Module 3 incidents may trigger coordinated regulatory action under §13.
***
#### Section 7 — Protective Conversion (PC-35 through PC-38)
**Purpose.** Automatically convert ST22 tokens to underlying common stock upon defined adverse events, ensuring investors retain genuine equity ownership even if the platform fails.
**Mechanism.** The Transfer Hook reads the `protective_conversion_triggered` flag on the SecurityConfig. When set, the hook prevents transfers and signals Empire Stock Transfer to begin the conversion procedure documented in the Empire Integration §11.
IDControlTriggerBehavior
PC-35
Issuer bankruptcy
Issuer files Chapter 7 or Chapter 11
Automatic conversion to common stock
PC-36
SEC enforcement / criminal indictment
SEC enforcement action or criminal indictment against officer or director
Automatic conversion
PC-37
Empire service loss
Empire Stock Transfer ceases providing custody services for any reason
Automatic conversion
PC-38
Tripartite breach
Material breach of the Issuer–Empire–Platform tripartite agreement
Discretionary conversion (Legal Counsel + 3-of-5)
**Mechanism detail.** The protective-conversion controls do not block transfers in normal operation. They activate only when the SecurityConfig flag is set by Legal Counsel plus 3-of-5 multi-signature. Once set, the conversion procedure is triggered, custody is preserved, and ST22 tokens are converted to physical common stock certificates issued by the appropriate transfer agent.
**Module behavior.** Module 1 and Module 2 use the same protective-conversion logic. Module 3 adds an additional implicit trigger: a federal action that effectively prohibits operation of the underlying basin asset can trigger PC-37 via Empire's discretion.
***
#### Section 8 — Record-Keeping and Governance (RK-39 through REG-42)
**Purpose.** Provides immutable audit trail and emergency containment authority.
IDControlTriggerBehavior
RK-39
On-chain audit trail
Every transfer (success or failure)
TransferValidated event emitted
RK-40
Hash-chain integrity
Audit-record hash chain
Prevents retroactive modification
GOV-41
Controlled migration
Program upgrade in progress
6041 — ControlledMigration
REG-42
Regulatory freeze
Legal Counsel + 3-of-5 multi-sig authority
6042 — RegulatoryOverride
**REG-42 (Regulatory Freeze) properties.**
* No timelock — immediate execution on multi-signature approval.
* Per-mint scope by default; can be platform-wide if requested.
* Reversible — the same multi-signature can lift the freeze.
* Logged on chain with the freezing authority's identity and timestamp.
**Module-specific automation.** Module 3 has automatic federal-action freeze coordination. The platform's federal-action monitoring service polls the Federal Register, DOE program announcements, and USGS classification updates on a 5-minute cadence. Detected federal actions matching a basin or mineral class associated with an issued Module 3 mint trigger an automatic P0 incident, and Legal Counsel plus 3-of-5 multi-signature execute REG-42 on each affected mint within 60 minutes per the Incident Response Playbook §13.
**Federal-Action Freeze State Machine (Module 3)**
Copy
```
NORMAL OPERATION ──► CLASSIFICATION ORACLE (24h cache)
│
▼
FEDERAL ACTION DETECTED (P0 incident)
│
├─ Legal Counsel + 3-of-5 multi-sig → REG-42 FREEZE
│
▼
FROZEN ──► No transfers; mint paused on AMM
│
▼
AWAITING FEDERAL-ACTION RESOLUTION
│
├─ Action expires / rescinded / variance / exemption
│
▼
FREEZE LIFTED (Legal Counsel + 3-of-5)
│
▼
TRADING (resumed)
```
***
#### Adjustable vs Immutable Parameters
A complete summary of which parameters are adjustable through governance and which are hard-coded program constants.
**Governance-Adjustable**
ParameterDefaultMinMax
Wallet concentration cap
4.99% (499 bps)
1.00% (100 bps)
9.99% (999 bps)
Circuit breaker threshold
30% (3000 bps)
10% (1000 bps)
50% (5000 bps)
Circuit breaker cooldown
24h (86,400s)
1h (3,600s)
72h (259,200s)
Price impact maximum
2% (200 bps)
1% (100 bps)
5% (500 bps)
TWAP window
30m (1,800s)
15m (900s)
1h (3,600s)
Velocity cap
50 tx/hr
(governance-set)
(governance-set)
Module 2: NAV deviation max
(per-mint)
(governance-set)
(governance-set)
Module 2: NAV reappraisal max age
(per-mint)
(governance-set)
(governance-set)
Module 3: Classification max age
(per-mint)
(governance-set)
(governance-set)
**Immutable (Hard-Coded Program Constants)**
ParameterValue
Holding period — Reg D (Rule 144)
15,778,800 seconds (6 months)
Holding period — Reg S
31,536,000 seconds (12 months)
Holding period — Reg CF
31,536,000 seconds (12 months)
TWAP minimum observations
60
Cross-wallet clustering algorithm
2-hop graph analysis
Liquidity Pool — withdrawal
(No function exists)
**Why immutability matters.** The hard-coded constants are outside the parameter space governance can adjust. Even with full multi-signature authority and 100% supermajority, governance cannot reduce a Reg D holding period below six months. Any upgrade attempting this fails Certora invariant E.4 verification at the formal-verification gate, before being executable.
***
#### Errors Summary
The Transfer Hook returns one of the following errors when a control fails. Application clients should map error codes to user-facing messages; the codes themselves are stable across program versions.
CodeNameMost Likely Cause
6001
CustodyDiscrepancy
Empire-attested balance below on-chain supply (incident escalation)
6002
CustodyOracleUnavailable
Empire relay outage; oracle stale beyond 1 slot
6003
SenderSanctioned
Sender on OFAC SDN list
6004
ReceiverSanctioned
Receiver on OFAC SDN list
6005
OfacOracleStale
OFAC oracle has not refreshed within the staleness threshold
6006
AMLHighRisk
Risk score from Chainalysis or TRM Labs above 70/100
6007
InvalidSigner
KYC missing, expired, jurisdiction-blocked, or wallet not registered in MSF
6020
WalletLimitExceeded
Receiving wallet would exceed concentration cap
6021
PriceImpactExceeded
Single trade exceeds price-impact cap vs TWAP (Module 2: vs NAV)
6022
VelocityExceeded
Per-wallet transaction rate exceeded
6023
CrossWalletDetected
Multiple wallets cluster as a single position above the limit
6024
TokensLocked
Holding period (Reg D, Reg S, or Reg CF) has not elapsed
6037
DailySellLimitExceeded
Wallet daily sell volume above 30% threshold
6038
CustodyDiscrepancyHalt
Awaiting custody oracle consensus
6041
ControlledMigration
Program upgrade in progress
6042
RegulatoryOverride
Legal Counsel + 3-of-5 freeze active
***
#### Module-Aware Summary
For each module, this is the relationship between the 42 controls and module-specific behavior.
**Module 1 — Equities**
* All 42 controls apply identically.
* No additional oracles.
* EDGAR pipeline supplies issuer-disclosure intelligence to Layer 9 IDOS off-chain compliance system.
**Module 2 — Real Estate**
* All 42 controls apply.
* Adds NAV Oracle (per mint).
* CB-21 enforces NAV-deviation circuit breaker.
* PL-16 concentration cap may be issuer-configured up to 9.99%.
**Module 3 — CORECM (Carbon Ore, Rare Earth, and Critical Minerals)**
* All 42 controls apply.
* Adds Classification Oracle (per mint).
* IV-08 requires enhanced KYC depth (beneficial-ownership to ultimate owner).
* REG-42 has automatic federal-action freeze coordination.
* Federal action sources: Federal Register, DOE Critical Materials Strategy program announcements, USGS Critical Minerals List updates, Department of Defense procurement directives, executive orders, court orders.
***
#### Cross-Reference
TopicDocument
Program-level documentation (instructions, account schemas, PDA registry)
Smart Contract Reference
Formal specification (auditor and regulator audience)
SPL Token-2022 Transfer Hook Technical Specification
Regulatory mapping (which control satisfies which regulation)
Compliance Integration Guide §3
Threat model (what each control defends against)
Security Model §4
Custody attestation lifecycle
Empire Stock Transfer Integration §5
Federal-action runbook
Incident Response Playbook §13
NAV oracle architecture (Module 2)
Oracle Integration Guide §6
Classification oracle architecture (Module 3)
Oracle Integration Guide §7
Architecture decisions (why these controls, why this architecture)
Architecture Decisions ADR-001 through ADR-012
***
*RWA Tokens · Transfer Hook Reference · Groovy Company, Inc.*
# Issuer Onboarding Guide
### Issuer Onboarding Guide
**Tokenization Onboarding · 9 Stages · Board Resolution to CEDEX Trading**
End-to-end onboarding guide for issuers tokenizing assets through Groovy Company, Inc.'s **RWA Tokens** platform. The platform supports three asset classes through three production modules:
* **Module 1 — Equities.** OTC microcap (OTCQB, OTCID, Expert Market), NASDAQ, AMEX, TSX, and global exchange-listed equities.
* **Module 2 — Real Estate.** Commercial buildings, multifamily portfolios, real-estate funds, and basin-attached real-property assets.
* **Module 3 — CORECM.** Carbon Ore, Rare Earth, and Critical Minerals — basin assets and mining concessions issuing under SEC Reg D, Reg S, and Reg CF exemptions.
This document covers corporate prerequisites, Empire Stock Transfer custody, on-chain token creation, offering mechanics, and secondary-market activation across all three modules. Stages 1–9 are the standard onboarding flow; module-specific variations are called out in §16.
***
#### Table of Contents
1. Overview
2. Prerequisites
3. Stage 1 — Application
4. Stage 2 — Due Diligence
5. Stage 3 — Legal Documentation
6. Stage 4 — Empire Custody Agreement
7. Stage 5 — Asset Deposit
8. Stage 6 — Reg D / Reg S / Reg CF Filing
9. Stage 7 — Token Minting
10. Stage 8 — CEDEX Listing
11. Stage 9 — Live Trading
12. Post-Launch Operations
13. Costs and Timeline
14. Technical Requirements for Issuer Counsel
15. Frequently Asked Questions
16. Module-Specific Onboarding Variations
***
#### 1. Overview
**What Happens**
The issuer authorizes the asset that will back the ST22 tokens, deposits the underlying instrument with Empire Stock Transfer under irrevocable custody, and the platform mints 1:1 ST22 Digital Securities tokens on Solana. The tokens trade 24/7 on CEDEX (cedex.market) with all 42 Transfer Hook security controls enforced on every trade.
The same nine-stage flow applies across all three modules. The asset class differs — Common Class B equity for Module 1, single-asset real-property entity for Module 2, basin-asset entity for Module 3 — but the onboarding architecture, custody, oracle attestation, Transfer Hook enforcement, and CEDEX listing are identical.
**Division of Responsibility**
Issuer ResponsibilityPlatform / Empire Responsibility
Board resolution authorizing tokenized class
Due-diligence review
State filing (Certificate of Designation, single-asset entity charter, or basin-asset entity charter)
Technical tokenization infrastructure
Asset deposit to Empire custody
42 Transfer Hook controls deployed
Reg D / Reg S / Reg CF offering documents
CEDEX listing and Global Pool seeding
Ongoing reporting (10-K, 10-Q, NAV reappraisal, classification refresh)
Real-time custody oracle and compliance monitoring
**What Issuers Do Not Provide**
Issuers do not need blockchain expertise, smart-contract development capability, market makers, liquidity providers, or exchange-listing fees. The platform handles all technical infrastructure. Issuers provide the corporate authorization and the underlying assets — the platform provides the technology.
**End-to-End Flow**
Copy
```
Board Resolution → State Filing → Empire Custody Deposit
→ Asset Identifier Assignment (CUSIP / Property ID / Basin ID)
→ Oracle Integration → ST22 Mint Creation
→ Transfer Hook Attached (IRREVERSIBLE) → SecurityConfig Initialized
→ Reg D / Reg S / Reg CF Offering → Empire Investor Onboarding (KYC/KYB/AML)
→ Stablecoin Settlement (USDC / PYUSD) → Token Delivery
→ Holding Period Enforcement (Control 24)
→ CEDEX Pool Creation (protocol-controlled, LP burned)
→ 24/7 Secondary Trading on cedex.market
```
***
#### 2. Prerequisites
**Corporate Prerequisites**
RequirementDetailWho Prepares
Active corporate entity
Must be in good standing with state of incorporation
Issuer
Board of Directors
Authorized to approve the tokenized share or interest class
Issuer
Charter documentation
Certificate of Incorporation or LLC operating agreement, current with Secretary of State
Issuer counsel
SEC reporting (if applicable)
Current 10-K / 10-Q filings (Module 1 only; not required for all OTC tiers)
Issuer
Transfer-agent relationship
Empire Stock Transfer engagement
Platform coordinates
No disqualifying events
Bad-actor check for officers, directors, and 20%+ beneficial owners
Legal Counsel reviews
Module-specific entity
Single-asset entity (Module 2); basin-asset entity (Module 3)
Issuer counsel
**What Issuer Counsel Prepares**
DocumentPurposeFiled With
Board Resolution
Authorizes creation and issuance of the tokenized class
Corporate records
Charter Filing
Certificate of Designation (Module 1), single-asset entity charter (Module 2), or basin-asset entity charter (Module 3)
Secretary of State of issuer's jurisdiction
Shareholder Approval (if required)
Approval for new share class creation per articles
Corporate records
Tripartite Agreement
Issuer + Groovy Company, Inc. + Empire Stock Transfer custody and service agreement
All three parties
Reg D / Reg S / Reg CF offering documents
Subscription agreement, investor questionnaire, risk disclosures, PPM
SEC (Form D within 15 days of first sale; Form C for Reg CF)
Module 2 NAV documentation
Independent appraisal report from licensed appraiser
Tripartite filing
Module 3 classification documentation
USGS classification, DOE Critical Materials Strategy alignment, mineral rights and chain of title
Tripartite filing
**Technical Prerequisites (Platform Provides)**
ComponentStatus at Onboarding
Solana Mainnet-Beta programs
Deployed and audited
Transfer Hook program
Live — 42 controls operational
Empire custody oracle
Ed25519 attestation active (\~400ms cadence)
CEDEX trading venue
Live at cedex.market
Global Unified CEDEX Liquidity Pool
Funded, LP burned, permanently locked
Investor onboarding portal
Empire Stock Transfer dashboard active
Module 2 NAV oracle infrastructure
NAV relay service operational
Module 3 Classification oracle infrastructure
USGS / DOE feed monitoring operational
***
#### 3. Stage 1 — Application
**Process**
The issuer submits an application via the Issuer Portal at **rwatokens.net/issuers**.
**Application Information Required**
FieldExamplePurpose
Company legal name
ACME Corporation
Issuer identification
State of incorporation
Delaware
Determines charter-filing jurisdiction
CIK number (if SEC reporting)
0001234567
EDGAR data integration for Layer 9 IDOS off-chain compliance
Module
Module 1 (Equities), Module 2 (Real Estate), or Module 3 (CORECM)
Determines onboarding workflow
OTC tier (Module 1 if applicable)
OTCQB / OTCID / Expert Market
Market context
Authorized shares / interest units
100,000,000 Common (Module 1); 1,000,000 LLC units (Module 2); 1,000,000 basin-asset units (Module 3)
Capital structure review
Proposed tokenized authorization
10,000,000 Common Class B / 100% LLC units / 100% basin-asset units
Tokenization scope
Primary contact
CEO / CFO / General Counsel
Onboarding coordination
Issuer website
acme-corp.com
Due-diligence baseline
**Module-Specific Application Information**
**Module 1 (Equities):** OTC tier, 15c2-11 status, last 10-K filing date, Caveat Emptor flags, market-maker presence.
**Module 2 (Real Estate):** Property address, square footage, NAV (most recent appraisal), property type (commercial, multifamily, retail, industrial), occupancy and revenue history, single-asset entity formation.
**Module 3 (CORECM):** Mineral basin location, USGS classification (rare earth, critical mineral, etc.), DOE Critical Materials Strategy alignment, mineral-rights chain of title, basin-asset entity formation, any current federal contracts or supply-chain commitments.
**Platform Response**
Application is acknowledged within 2 business days. Issuer Services assigns a primary contact. Due-diligence process is initiated.
***
#### 4. Stage 2 — Due Diligence
**Diligence Scope**
Diligence AreaWhat Is ReviewedSource
Corporate standing
Good standing, articles of incorporation, bylaws
Secretary of State records
SEC filings (Module 1, if reporting)
10-K, 10-Q current status, EDGAR filing history
SEC EDGAR (Layer 9 IDOS scoring)
Shareholder structure
Outstanding shares, beneficial ownership, control persons
Transfer-agent records
Officers and directors
Identity verification, background, bad-actor check
SEC EDGAR, public records
OTC Markets status (Module 1)
Current tier, 15c2-11 compliance, Caveat Emptor flags
OTC Markets Group
Litigation / enforcement
Pending SEC actions, ongoing litigation
PACER, SEC EDGAR, public records
Financial condition
Going-concern opinions, auditor status
Most recent 10-K / audited financials
**Module 2:** Property documentation
Title, valuation, occupancy, environmental disclosures
Title insurer, appraiser, Phase I / II reports
**Module 3:** Mineral rights
Title chain, lease terms, classification, federal contracts
County records, USGS, DOE contract registry
**IDOS Score (Module 1 — Layer 9)**
The platform's Layer 9 off-chain compliance system generates an Issuer Distress and Opportunity Score (IDOS) for Module 1 applicants, scoring tokenization readiness across EDGAR filing data, OTC Markets tier status, market-maker presence, trading volume, and shareholder concentration. The score informs onboarding priority — it does not determine eligibility.
**Module 2 Real Estate Diligence**
In addition to corporate standing, Module 2 due diligence reviews property-specific documents: independent appraisal, title insurance, occupancy and lease history, environmental Phase I (and Phase II if triggered), real-estate tax history, and operating expense schedules. The single-asset entity must be properly formed in a jurisdiction acceptable to Empire Stock Transfer (Delaware, Wyoming, and Nevada are pre-approved for single-asset LLCs).
**Module 3 CORECM Diligence**
Module 3 due diligence adds a federal-classification review: USGS Critical Minerals List status, DOE Critical Materials Strategy alignment, Section 232 sensitivity, Defense Production Act Title III applicability, and any current or pending federal contracts. Mineral rights chain of title is independently verified through county records and the relevant state oil-gas-and-minerals registry.
**Due-Diligence Timeline**
ModuleTypical DurationComplex-Situation Range
Module 1
5–10 business days
15–30 business days
Module 2
10–15 business days
25–45 business days (environmental escalation)
Module 3
15–25 business days
30–60 business days (federal-classification review)
**Outcome**
ResultNext Step
Approved
Proceed to Stage 3 — Legal Documentation
Conditionally approved
Specific issues identified for remediation; re-review upon resolution
Declined
Written explanation provided; may re-apply after conditions addressed
***
#### 5. Stage 3 — Legal Documentation
**5.1 Board Resolution**
The issuer's Board of Directors passes a resolution authorizing:
* Creation of the tokenized share or interest class (Common Class B for Module 1; LLC units for Module 2; basin-asset units for Module 3).
* Deposit of the tokenized class with Empire Stock Transfer under irrevocable custody.
* Tokenization as ST22 Digital Securities through the RWA Tokens platform.
* Appointment of Empire Stock Transfer as qualified custodian.
* Authorization of Reg D, Reg S, and (if applicable) Reg CF offerings.
The board resolution is a corporate action of the issuer — not a platform document. The platform provides a template; issuer counsel customizes it for the specific corporate-governance requirements of the issuer.
**5.2 Charter Filing**
The state filing depends on the module:
**Module 1 — Certificate of Designation.** Filed with the Secretary of State of the issuer's jurisdiction of incorporation. Specifies Common Class B shareholder rights:
TermIssuer DecisionExample
Voting rights
Per share or aggregate
1 vote per Common B share
Dividend rights
Pari passu with Common A, or specified
Equal to Common A dividends
Liquidation preference
Pro rata or specified
Pro rata with all common shares
Conversion rights
Convertible to Common A, or not
1:1 conversion at holder election
Protective conversion triggers
Standard or customized
Bankruptcy, SEC enforcement, loss of Empire (Controls 35–38)
Anti-dilution
Standard or broad-based
Standard
Redemption
At issuer option, holder option, or none
None
**Module 2 — Single-Asset Entity Charter.** Filed with the entity's jurisdiction of formation. The single-asset entity owns the underlying real-property asset directly. The entity's operating agreement specifies token-holder economic rights, NAV reappraisal cadence, and protective-conversion triggers tied to property events (default, condemnation, environmental order).
**Module 3 — Basin-Asset Entity Charter.** Filed with the basin-asset entity's jurisdiction of formation. The basin-asset entity owns the underlying mineral basin or mining concession directly. The entity's operating agreement specifies token-holder economic rights, classification refresh cadence, and protective-conversion triggers tied to federal action (Executive Order, Section 232 order, DPA Title III order, USGS classification change, court order).
The platform does not dictate these terms. Each issuer designates governance terms appropriate to the asset structure and investor base. Charter documents are public — filed with the state, verifiable by any party.
**5.3 Tripartite Agreement**
Three-party agreement between the issuer, Groovy Company, Inc., and Empire Stock Transfer establishing:
* Custody terms (irrevocable, perpetual).
* Oracle attestation authorization (Empire signs Ed25519 every Solana block).
* Fee structure (5% on all ST22 transactions).
* Compliance obligations (ongoing reporting, cooperation with regulatory inquiries).
* Termination provisions (protective conversion triggers).
* Module-specific oracle responsibilities (NAV reappraisal cadence for Module 2; classification refresh cadence for Module 3).
***
#### 6. Stage 4 — Empire Custody Agreement
**Empire Stock Transfer's Dual Role**
Empire Stock Transfer serves two distinct functions for every ST22 issuance, regardless of module:
1. **Qualified Custodian.** SEC §17A-registered transfer agent holding the underlying asset (Common Class B shares for Module 1; single-asset entity equity for Module 2; basin-asset entity equity for Module 3) in irrevocable custody.
2. **Sole Investor Onboarding Authority.** KYC, KYB, AML risk scoring (Chainalysis KYT and TRM Labs), OFAC and SDN screening, and wallet verification for all ST22 investors.
**Custody Agreement Terms**
TermSpecification
Custody type
Irrevocable — assets cannot be withdrawn by the issuer
Custody duration
Perpetual — no expiration
Recordkeeping
Empire Master Securityholder File — the authoritative shareholder record
DLT integration
Category 1 Model B — DLT used in official shareholder records per the January 28, 2026 Joint Staff Statement
Oracle authorization
Issuer authorizes Empire to sign Ed25519 custody attestations every Solana block
Asset identifier assignment
Empire coordinates CUSIP assignment (Module 1), property identifier (Module 2), or basin identifier (Module 3)
Regulatory compliance
Empire maintains Rules 17Ad-2 through 17Ad-13 compliance
Protective conversion
Empire executes conversion upon trigger events per the charter document
**Empire Credentials**
CredentialDetail
SEC registration
Section 17A of the Securities Exchange Act of 1934
Operating since
2006
Companies served
530+ publicly traded companies
Geographic scope
Operations across five continents
**Conflict-of-Interest Disclosure**
Patrick Mokros serves as Chief Operating Officer of Groovy Company, Inc. and Founder of Empire Stock Transfer. This dual role is material to the platform's operating structure and is disclosed to every issuer at Stage 4. The Audit Committee of Groovy Company's Board reviews and approves all Empire-related transactions under the platform's Related Party Transactions Policy. The dual relationship is the structural mechanism that delivers tight integration between custody attestations and on-chain enforcement (\~400ms Ed25519 cadence) — but it is mitigated by independent Audit Committee oversight, independent annual audit, and the irrevocability of custody (which limits any party's ability to act unilaterally).
***
#### 7. Stage 5 — Asset Deposit
**Module 1 — Common Class B Share Deposit**
Copy
```
1. CUSIP assigned to Common Class B share class (Empire coordinates)
2. Issuer executes irrevocable share transfer to Empire custody
3. Empire records deposit in the Master Securityholder File
4. Platform configures custody oracle for the new mint:
- Empire Ed25519 public key registered on chain
- CustodyOracle PDA created: [b"custody-oracle", mint]
- Oracle relay service begins per-block attestation
5. 1:1 verification confirmed before any tokens are minted
```
**Module 2 — Single-Asset Entity Deposit**
Copy
```
1. Property identifier assigned (Empire coordinates with title insurer)
2. Issuer executes irrevocable transfer of single-asset LLC equity to Empire custody
3. Empire records deposit in the Master Securityholder File
4. Independent appraisal performed by licensed appraiser; NAV recorded
5. Platform configures custody oracle and NAV oracle for the new mint:
- CustodyOracle PDA: [b"custody-oracle", mint]
- NAVOracle PDA: [b"nav-oracle", mint]
- NAV relay service begins; first appraisal published on chain
6. 1:1 verification confirmed; NAV initial value verified
```
**Module 3 — Basin-Asset Entity Deposit**
Copy
```
1. Basin identifier assigned (Empire coordinates with USGS data and county records)
2. Issuer executes irrevocable transfer of basin-asset entity equity to Empire custody
3. Empire records deposit in the Master Securityholder File
4. USGS Critical Minerals List classification verified; DOE Critical Materials Strategy alignment confirmed
5. Platform configures custody oracle and Classification oracle for the new mint:
- CustodyOracle PDA: [b"custody-oracle", mint]
- ClassificationOracle PDA: [b"classification-oracle", mint]
- Classification relay service begins; initial USGS / DOE classification published on chain
6. 1:1 verification confirmed; classification status verified; federal-action monitoring activated
```
**On-Chain Oracle Activation**
Once assets are deposited, the custody oracle begins attesting on every Solana block. The oracle operates continuously from this point — even before tokens are minted. This ensures the 1:1 backing verification is active before the first investor receives tokens.
Copy
```
Empire API → Ed25519 signature → CustodyOracle account updated
custodied_balance: [deposit amount]
token_supply: 0 (no tokens minted yet)
ratio: N/A (supply = 0)
ed25519_verified: true
discrepancy_detected: false
```
***
#### 8. Stage 6 — Reg D / Reg S / Reg CF Filing
**Offering Framework**
ST22 offerings are conducted under three SEC offering exemptions, depending on investor base:
* **Reg D** — US accredited investors (17 CFR §§ 230.501–506).
* **Reg S** — non-US investors, offshore-transaction safe harbor (17 CFR §§ 230.901–905).
* **Reg CF** — US retail crowdfunding (17 CFR §§ 227.100–504).
The issuer selects the exemption(s) that match the offering's investor base. A single offering may use Reg D and Reg S in parallel (US accredited plus non-US); Reg CF is typically conducted as a separate offering under the integration safe harbors.
**Form D Filing (Reg D and Reg S)**
RequirementDetail
Filing deadline
Within 15 calendar days of first sale
Filed with
SEC (electronically via EDGAR)
Content
Issuer identity, offering amount, exemption claimed, sales commissions
Amendment
Annual amendments as required, or upon material changes
Prepared by
Issuer counsel (platform provides template guidance)
**Form C Filing (Reg CF)**
RequirementDetail
Filing deadline
Before any offer is made
Filed with
SEC (electronically via EDGAR)
Content
Form C disclosure statement, financial statements (audited or reviewed depending on offering size), risk factors
Conducting platform
A FINRA-registered funding portal must conduct the offering
Prepared by
Issuer counsel
**Investor Eligibility**
Investor TypeVerificationHolding PeriodEnforced By
US accredited (Reg D)
Empire KYC plus accreditation verification
6 months (Rule 144)
Transfer Hook Control 24
Non-US (Reg S)
Empire KYC plus non-US person verification
12 months (Reg S compliance period)
Transfer Hook Control 24
US retail (Reg CF)
Empire KYC plus Reg CF investor-cap verification
12 months (Reg CF)
Transfer Hook Control 24
Non-eligible
**Not eligible**
—
Transfer Hook rejects (Error 6007)
**Settlement**
All ST22 purchases settle via GENIUS Act-compliant stablecoins:
* **USDC** (Circle) — primary.
* **PYUSD** (PayPal / Paxos) — secondary.
Settlement is atomic with token delivery — stablecoin transfer and ST22 token delivery execute in a single Solana transaction with full Transfer Hook enforcement.
**Issuer receives:** 95% of subscription proceeds (5% platform fee deducted). The platform fee is paid in USDC; settlement to issuer is wired to the issuer's designated USD bank account.
***
#### 9. Stage 7 — Token Minting
**Mint Creation — Irreversible**
The ST22 mint is created on Solana using SPL Token-2022 with the Transfer Hook extension. Once created, the Transfer Hook is permanently attached — it cannot be removed, disabled, or changed.
**Technical Process**
Copy
```
Step 1: Create SPL Token-2022 mint with Transfer Hook extension
→ Hook program: platform Transfer Hook
→ Token program: TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb
→ PERMANENT — cannot be removed after creation
Step 2: Initialize SecurityConfig PDA
→ Seeds: [b"security-config", mint]
→ Default parameters:
max_wallet_percent: 499 (4.99%)
circuit_breaker_threshold: 3000 (30%)
circuit_breaker_cooldown: 86400 (24h)
price_impact_max_bps: 200 (2%)
twap_window_secs: 1800 (30 min)
holding_period_enabled: true
→ Module-specific extensions populated:
Module 2: nav_deviation_max_bps, nav_reappraisal_max_age_secs
Module 3: classification_max_age_secs, federal_action_freeze_enabled
Step 3: Initialize ExtraAccountMetaList
→ Registers all oracle and holding-period PDAs for Token-2022 resolution
Step 4: Initialize CustodyOracle PDA
→ Seeds: [b"custody-oracle", mint]
→ Links to Empire Ed25519 public key
→ Oracle relay begins per-block attestation
Step 5 (Module 2): Initialize NAVOracle PDA
→ Seeds: [b"nav-oracle", mint]
→ First appraisal published
Step 5 (Module 3): Initialize ClassificationOracle PDA
→ Seeds: [b"classification-oracle", mint]
→ Initial USGS / DOE classification published
→ Federal-action monitoring activated
Step 6: Mint ST22 tokens 1:1 with deposited assets
→ Managed via Ledger Enterprise (HSM-backed key management)
→ Mint amount must equal Empire-custodied amount exactly
→ CustodyOracle verifies: token_supply == custodied_balance
Step 7: Verify all 42 controls operational
→ Test transfer on devnet (or controlled mainnet test)
→ Confirm Controls 1–42 execute; error codes respond correctly
→ Confirm Control 24 holding-period enforcement active
```
**Token Characteristics**
AttributeValue
Token standard
SPL Token-2022 (Solana)
Transfer Hook
Platform Transfer Hook — 42 controls, permanently attached
Decimals
9 (standard)
Supply
Exactly 1:1 with Empire-custodied units
Mint authority
Controlled — new minting requires Empire custody deposit first
Freeze authority
Empire permanent delegate (emergency-freeze capability)
Metadata
On chain: issuer name, symbol, asset identifier, charter reference
**What the Issuer Sees**
The issuer does not interact with Solana, Rust, or smart contracts. The technical process is executed by the platform's engineering team. The issuer receives:
* ST22 mint address (Solana public key).
* CEDEX trading-pair URL (cedex.market/trade/SYMBOL).
* SecurityConfig confirmation (42 controls active; parameters verified).
* CustodyOracle health dashboard (real-time 1:1 attestation status).
* Module 2: NAV oracle dashboard (current NAV; reappraisal countdown).
* Module 3: Classification oracle dashboard (USGS / DOE status; federal-action monitor).
***
#### 10. Stage 8 — CEDEX Listing
**Pool Creation**
The platform creates a CEDEX trading pool for the ST22 token. Pool creation is protocol-controlled — only the platform can initialize pools. Third parties cannot create pools, which prevents the unauthorized-LP-creation attack class observed in beta deployments.
Copy
```
Pool initialization:
→ PDA: [b"pool", mint]
→ Initial SOL reserve: seeded from the Global Unified CEDEX Liquidity Pool
→ Initial token reserve: ST22 tokens allocated for secondary market
→ LP tokens: BURNED at initialization — withdrawal impossible
→ CPMM formula: x × y = k (constant product)
→ Fee: 5% per trade (500 bps)
```
**Fee Distribution (Per Trade)**
RecipientRatePurpose
Issuer treasury
2.00%
Revenue to issuer — withdrawable
GROO staking pool
1.50%
Distributed to GROO stakers
Protocol operations
1.06%
Infrastructure, oracles, development
Global Pool
0.44%
**Permanently locked** — pool deepening
**Total**
**5.00%**
The issuer earns 2% of every secondary trade on CEDEX. This is automatic, on chain, and requires no action from the issuer. Revenue accrues to the issuer's designated treasury wallet.
**Listing Checklist**
Copy
```
[ ] ST22 mint created with Transfer Hook
[ ] SecurityConfig initialized and verified
[ ] CustodyOracle active and fresh (within 1 slot)
[ ] ExtraAccountMetaList initialized
[ ] CEDEX trading pool created (LP burned)
[ ] Token metadata published (symbol, name, asset identifier)
[ ] Issuer treasury wallet configured for 2% fee revenue
[ ] Empire investor onboarding portal active for this issuer
[ ] Test trade executed and verified (all 42 controls passed)
[ ] (Module 2) NAV oracle initialized and within configured deviation
[ ] (Module 3) Classification oracle initialized; federal-action monitoring confirmed live
[ ] Issuer approval for go-live
```
***
#### 11. Stage 9 — Live Trading
**What Happens at Launch**
Copy
```
1. CEDEX listing goes live at cedex.market/trade/SYMBOL
2. Empire investor onboarding portal opens for this issuer's offering
3. Investors complete Empire KYC / KYB / AML / OFAC verification
4. Verified investors purchase ST22 tokens via stablecoin (USDC / PYUSD)
5. Token delivery triggers HoldingPeriodAccount creation:
- PDA: [b"holding-period", mint, investor_wallet]
- jurisdiction: US (Reg D, 6 months), Non-US (Reg S, 12 months),
or Reg CF (US retail, 12 months)
- purchase_timestamp: Solana runtime clock at delivery
- is_locked: true
6. Holding period begins — Control 24 enforces on every transfer attempt
7. After holding period elapses:
- is_locked transitions to false
- Investor can sell on the CEDEX secondary market
- All 42 controls still execute on every trade
```
**24/7 Trading**
CEDEX operates 24 hours a day, 7 days a week, 365 days a year. No market hours. No geographic restrictions beyond OFAC and jurisdictional sanctions enforcement. Any Empire-verified eligible investor worldwide can trade.
**What the Issuer Sees Post-Launch**
Dashboard FeatureDescription
Real-time price
Current CPMM price from the CEDEX pool
Trading volume
24-hour, 7-day, 30-day volume in SOL and USD
Holder count
Number of unique wallets holding ST22 tokens
Custody status
Real-time 1:1 attestation from the Empire oracle
Fee revenue
Cumulative 2% issuer share of trading fees
Holding-period status
Count of locked versus unlocked positions
Circuit-breaker status
Active or normal
Module 2: NAV vs. price
Current price deviation from latest appraisal; reappraisal countdown
Module 3: Classification status
Current USGS / DOE classification; federal-action monitoring status
***
#### 12. Post-Launch Operations
**Ongoing Issuer Obligations**
ObligationFrequencyModule ScopeConsequence of Non-Compliance
SEC reporting (10-K, 10-Q)
Annual / quarterly (if applicable)
Module 1
Control 37 may trigger — issuer-eligibility lapse halts ST22 transfers
Cooperate with regulatory inquiries
As needed
All
Tripartite-agreement obligation
Maintain corporate good standing
Continuous
All
Charter validity depends on good standing
Update material information
As events occur
All
Investors rely on accurate disclosure
Notify platform of material changes
Immediately
All
Board changes, enforcement actions, M\&A, bankruptcy
NAV reappraisal
Per tripartite cadence (typically annual)
Module 2
NAV-deviation breaker pauses mint until fresh appraisal
Classification refresh
Continuous monitoring
Module 3
Federal-action freeze triggers automatically on detected action
Property reporting (rent rolls, occupancy)
Quarterly
Module 2
Material misstatement may trigger PC-38
Mineral-rights reporting
Quarterly
Module 3
Material misstatement may trigger PC-38
**Protective-Conversion Triggers**
If any of these events occur, the 42 Transfer Hook controls include automatic protective-conversion provisions (Controls 35–38):
TriggerControlAction
Bankruptcy filing
PC-35
Tokenized class automatically converts to underlying physical security per the charter
SEC enforcement action
PC-36
Automatic conversion
Criminal indictment (officer or director)
PC-36
Automatic conversion
Loss of Empire Stock Transfer services
PC-37
Automatic conversion
Material breach of tripartite agreement
PC-38
Conversion at platform plus Empire discretion
Module 3 adds an additional implicit trigger: a federal action that effectively prohibits operation of the underlying basin asset can result in PC-37 conversion via Empire's discretion under the basin-asset entity charter.
**Oracle Monitoring**
The issuer can monitor oracle health at any time via the platform's monitoring API:
Copy
```
GET https://api.cedex.market/v1/oracle/{mint}/custody
Response:
{
"custodied_balance": 10000000,
"token_supply": 10000000,
"ratio": 1.0,
"ed25519_verified": true,
"discrepancy_detected": false,
"latency_ms": 145
}
```
A `discrepancy_detected: true` response halts all trading on the issuer's ST22 token until 2-of-3 oracle consensus resolves the discrepancy. This has never occurred across three beta issuers and over $7M of processed liquidity.
Module 2 issuers can also query the NAV oracle:
Copy
```
GET https://api.cedex.market/v1/oracle/{mint}/nav
```
Module 3 issuers can also query the Classification oracle:
Copy
```
GET https://api.cedex.market/v1/oracle/{mint}/classification
```
***
#### 13. Costs and Timeline
**Costs**
CostAmountPaid ByWhen
Minting fee
$1,000–$25,000 (tiered by valuation)
Issuer
One-time at Stage 7
Legal documentation
Varies (issuer counsel fees)
Issuer
Stages 3–6
Empire custody agreement
Included in tripartite agreement
Covered by platform fee
Stage 4
CEDEX listing
$0
No listing fee
Stage 8
Module 2 appraisal (initial)
$5,000–$25,000 (licensed appraiser)
Issuer
Stage 5
Module 2 appraisal (reappraisal)
$3,000–$15,000 per reappraisal
Issuer
Per cadence in tripartite
Module 3 classification verification
$5,000–$20,000 (initial USGS / DOE confirmation)
Issuer
Stage 5
Ongoing platform fee
5% of trading volume (deducted per trade)
Traders (not issuer)
Continuous
Ongoing custody
Included in platform operations
Covered by platform fee
Continuous
Market maker
$0 — not required
N/A
N/A
**Timeline**
StageModule 1 DurationModule 2 DurationModule 3 Duration
1\. Application
1–2 business days
1–2 business days
1–2 business days
2\. Due Diligence
5–10 business days
10–15 business days
15–25 business days
3\. Legal Documentation
10–20 business days
15–25 business days
15–30 business days
4\. Empire Custody Agreement
5–10 business days
5–10 business days
5–10 business days
5\. Asset Deposit
3–5 business days
5–10 business days
5–15 business days
6\. Reg Filing
1–2 business days
1–2 business days
1–5 business days
7\. Token Minting
1–2 business days
1–2 business days
1–2 business days
8\. CEDEX Listing
1–2 business days
1–2 business days
1–2 business days
9\. Live Trading
Immediate
Immediate
Immediate
**Cumulative (typical)**
**8–12 weeks**
**10–14 weeks**
**12–16 weeks**
Primary variable across all modules: legal documentation preparation (Stage 3), which depends on issuer counsel responsiveness and corporate-governance complexity. Module 3 timeline is longer primarily due to USGS / DOE classification verification and federal-action review.
**Comparison to Traditional Infrastructure**
Cost CategoryTraditional Market InfrastructureRWA Tokens Platform
Market-maker retainer
$5,000–$20,000 / month
$0
Exchange listing
$50,000–$250,000
$0
Annual compliance
$25,000–$75,000
Included in 5% platform fee
Tokenization fee
N/A
$1,000–$25,000 (one-time)
Time to market
6–12 months
8–16 weeks
***
#### 14. Technical Requirements for Issuer Counsel
**What Counsel Needs to Know**
Issuer counsel does not need blockchain expertise. The technical infrastructure is the platform's responsibility. Counsel's role is limited to corporate governance and securities law:
Counsel ResponsibilityTechnical Context
Draft charter document
Module 1 Certificate of Designation; Module 2 single-asset entity charter; Module 3 basin-asset entity charter. Filed with the issuer's state. Platform provides template; counsel customizes.
Board resolution
Authorizes tokenized class creation and Empire custody. Standard corporate action. Platform provides template.
Reg D / Reg S / Reg CF compliance
Standard private-placement and crowdfunding-exemption practice. Form D filing within 15 days; Form C filing before Reg CF offering. Empire handles investor verification — counsel reviews offering documents.
Bad-actor check
Disqualification verification for officers, directors, and 20%+ beneficial owners. Standard Reg D requirement.
Tripartite-agreement review
Three-party custody and service agreement. Counsel reviews terms on behalf of the issuer.
Module 2 property documentation
Title insurance, environmental reports, lease and tenant disclosures. Standard real-estate practice.
Module 3 mineral rights
Title chain verification, lease terms, USGS classification confirmation. Coordination with USGS/DOE counsel as needed.
**What Counsel Does Not Need to Know**
* Solana blockchain architecture.
* SPL Token-2022 Transfer Hook implementation.
* Smart-contract code (Rust, Anchor).
* CPMM AMM mathematics.
* Oracle attestation mechanics.
* CEDEX trading-venue technology.
**Key Legal Concepts for Counsel**
ConceptExplanation
Category 1 Model B
SEC classification per the January 28, 2026 Joint Staff Statement. Issuer-sponsored tokenization with DLT in official shareholder records. Direct beneficial ownership; no counterparty risk.
Release No. 33-11412
March 17, 2026 SEC release establishing the Digital Securities taxonomy. ST22 tokens are Category 5 Digital Securities.
Transfer Hook
Solana runtime mechanism enforcing 42 compliance controls on every token transfer. Cannot be bypassed, disabled, or overridden. Provides the structural compliance guarantee — not a policy commitment.
Irrevocable custody
Empire holds the underlying assets permanently. The assets cannot be withdrawn by the issuer. Custody is the basis for 1:1 token backing.
Control 24
On-chain enforcement of Reg D (6 months), Reg S (12 months), and Reg CF (12 months) holding periods. Investors cannot sell before the period elapses regardless of any agreement or instruction.
UCC Article 8
Each ST22 transfer on CEDEX constitutes an effective instruction to update Empire's Master Securityholder File under UCC §8-102(a)(8). Wyoming Digital Asset Statute (W\.S. 34-29-101 et seq.) provides additional statutory support.
NAV-Deviation Breaker (Module 2)
On-chain price-bounds enforcement against appraised NAV. Pauses trading if the price deviates beyond the configured threshold; resumes after fresh appraisal.
Federal-Action Freeze (Module 3)
Automatic Control 42 activation on detected federal actions (Executive Orders, Section 232 orders, DPA Title III orders, USGS classification changes). Coordinates with Empire under the basin-asset entity charter.
***
#### 15. Frequently Asked Questions
**Corporate**
**Does tokenization change the issuer's corporate structure?**
No. Module 1 tokenization creates a new share class (Common Class B) alongside existing shares. Existing common shareholders, board structure, and corporate governance are unchanged. Module 2 and Module 3 tokenization use a single-purpose entity that owns the underlying asset; the issuer's primary entity is unaffected.
**Can the issuer control how many tokens are created?**
Token supply is always exactly 1:1 with deposited assets. If the issuer deposits 10,000,000 Common Class B shares, exactly 10,000,000 ST22 tokens are created. The issuer controls supply by controlling the asset deposit.
**What happens if the issuer wants to stop?**
Assets are in irrevocable custody. They cannot be withdrawn. However, protective-conversion triggers (Controls 35–38) can convert ST22 tokens to the underlying physical security under defined conditions (bankruptcy, enforcement, loss of Empire). This is a feature protecting investors, not a limitation — it ensures shareholder rights survive issuer distress.
**Financial**
**What does the issuer earn from secondary trading?**
2% of every CEDEX trade flows automatically to the issuer's treasury wallet. On $1M of daily volume, the issuer earns $20,000/day in passive fee revenue.
**Who pays the 5% fee?**
Traders pay the fee — it is deducted from each CEDEX trade. Issuers do not pay the 5% trading fee. Issuers pay only the one-time minting fee and (for Module 2 and Module 3) appraisal or classification fees.
**Does the issuer need a market maker?**
No. The Global Unified CEDEX Liquidity Pool serves all issuers simultaneously. Protocol-owned. LP burned. No market maker required, no market-maker fees, no risk of market-maker withdrawal.
**Regulatory**
**What kind of offering is this?**
ST22 tokens are Digital Securities under SEC Release No. 33-11412. Offerings are conducted under Reg D (US accredited), Reg S (non-US), and Reg CF (US retail) exemptions. Investors must be verified by Empire Stock Transfer.
**Who handles investor verification?**
Empire Stock Transfer is the sole investor onboarding authority. Empire handles KYC (individuals), KYB (entities), AML (Chainalysis KYT and TRM Labs), OFAC and SDN screening, and wallet verification. The platform does not perform investor onboarding.
**What if SEC reporting lapses (Module 1)?**
Transfer Hook Control 37 monitors issuer eligibility via the EDGAR oracle (Layer 6 off chain). If SEC registration lapses or an enforcement action is detected, ST22 transfers may be halted for the affected mint until the condition is resolved.
**What if a federal action is issued against the basin asset (Module 3)?**
The platform's federal-action monitoring service polls the Federal Register, DOE program announcements, and USGS classification updates on a 5-minute cadence. Detected federal actions matching a basin or mineral class associated with an issued mint trigger an automatic P0 incident. Legal Counsel and 3-of-5 multi-signature execute Control 42 (regulatory freeze) on each affected mint within 60 minutes per the Incident Response Playbook.
**Technical**
**Does the issuer need blockchain developers?**
No. The platform handles all blockchain infrastructure. The issuer's technical involvement is zero — the issuer provides corporate authorization and the underlying asset; the platform provides the technology.
**Can someone copy the issuer's token on another platform?**
Not on CEDEX. ST22 token creation requires Empire Stock Transfer KYC / KYB verification and asset custody deposit. Copycat deployment is structurally impossible because token creation requires on-chain issuer verification. On external platforms, anyone can create a token with any name — this is why CEDEX is the only official venue.
**What is the holding period?**
US Reg D investors: 6 months under Rule 144. Non-US Reg S investors: 12 months. US Reg CF investors: 12 months. Enforced on chain by Transfer Hook Control 24. No early unlock. No exceptions. The timer starts at token delivery and is recorded in the investor's HoldingPeriodAccount PDA.
***
#### 16. Module-Specific Onboarding Variations
The nine-stage flow is identical across all three modules. Module-specific variations sit in three places: the asset class deposited at Stage 5, the additional oracles initialized at Stage 7, and the ongoing operational obligations at Stage 12. This section summarizes the distinguishing characteristics of each module.
**16.1 Module 1 — Equities**
**Asset class.** Common Class B equity in the issuer's existing corporate entity. The Class B shares are pari passu with Class A on dividends and liquidation preference, with conversion rights as specified in the Certificate of Designation.
**Charter document.** Certificate of Designation, filed with the Secretary of State of the issuer's jurisdiction.
**Asset identifier.** CUSIP, assigned by Empire Stock Transfer.
**Additional oracle.** None beyond the standard custody oracle.
**Off-chain integration.** EDGAR pipeline supplies issuer-disclosure intelligence to the Layer 9 IDOS off-chain compliance system. The IDOS scoring informs onboarding priority and ongoing monitoring.
**Suitable issuers.** OTC microcap (OTCQB, OTCID, Expert Market), NASDAQ, AMEX, TSX, and other exchange-listed issuers seeking 24/7 secondary-market liquidity for accredited and non-US investors. Transition from quarterly to continuous-market dynamics.
**16.2 Module 2 — Real Estate**
**Asset class.** Equity in a single-asset entity (typically a Delaware, Wyoming, or Nevada LLC) that owns the underlying real-property asset directly.
**Charter document.** Single-asset entity charter and operating agreement, filed with the entity's jurisdiction. Operating agreement specifies token-holder economic rights, NAV reappraisal cadence, and protective-conversion triggers tied to property events (default, condemnation, environmental order).
**Asset identifier.** Property identifier, coordinated by Empire with the title insurer.
**Additional oracle.** NAV Oracle (per mint). Holds the most recent appraised NAV, the appraiser's signature, the last-reappraisal timestamp, the next-reappraisal target timestamp, and the deviation tolerance.
**Additional SecurityConfig parameters.** `nav_deviation_max_bps` (price-versus-NAV deviation tolerance), `nav_reappraisal_max_age_secs` (maximum age before NAV is considered stale), `nav_circuit_breaker_enabled`.
**On-chain enforcement.** Transfer Hook reads the NAV oracle during the price-impact circuit-breaker check (CB-21). When the on-chain price deviates from the NAV by more than the configured threshold, the affected mint is paused on the AMM until a fresh appraisal restores the price within bounds.
**Operational cadence.** NAV reappraisal per tripartite cadence (typically annually, with quarterly between-cycle reviews triggered by market events). Property reporting (rent rolls, occupancy, operating expenses) submitted quarterly.
**Suitable issuers.** Commercial real estate (offices, retail, multifamily, industrial), real-estate funds, single-asset entities issuing directly. A representative use case: a $4.5M commercial building converted from a Nevada LLC into a Nevada corporation with Common Class B authorization, fractionalized at 22% premium to NAV under NAV-deviation pricing.
**16.3 Module 3 — CORECM (Carbon Ore, Rare Earth, and Critical Minerals)**
**Asset class.** Equity in a basin-asset entity that owns the underlying mineral basin or mining concession directly. The basin-asset entity's primary asset is the mineral rights and the operational concession associated with the basin.
**Charter document.** Basin-asset entity charter and operating agreement, filed with the entity's jurisdiction. Operating agreement specifies token-holder economic rights, classification refresh cadence, and protective-conversion triggers tied to federal action (Executive Order, Section 232 order, DPA Title III order, USGS classification change, court order).
**Asset identifier.** Basin identifier, coordinated by Empire with USGS data and county records.
**Additional oracle.** Classification Oracle (per mint). Holds the most recent USGS Critical Minerals List classification, DOE Critical Materials Strategy status, federal-action status, and the last-refresh timestamp.
**Additional SecurityConfig parameters.** `classification_max_age_secs` (maximum age of Classification Oracle before staleness review), `federal_action_freeze_enabled` (whether automatic Control 42 freeze triggers on federal action).
**On-chain enforcement.** Transfer Hook reads the Classification oracle on every transfer. If the federal-action status is non-null, Control 42 (regulatory freeze) is automatically activated through the platform's federal-action monitoring. Enhanced KYC depth (beneficial ownership to ultimate owner) is required for entity investors given federal-action sensitivity.
**Federal frameworks tracked.**
FrameworkTrigger Source
USGS Critical Minerals List
Annual list; emergency updates
DOE Critical Materials Strategy
Program announcements
Section 232 (Trade Expansion Act of 1962)
Presidential proclamation
Defense Production Act Title III
Executive Order; DOD contract action
Inflation Reduction Act critical-minerals provisions
IRS guidance; Treasury rulemaking
Executive Order 14017 (supply-chain resilience)
EO updates; agency reports
Energy Act of 2020
DOE program updates
**Operational cadence.** Continuous classification monitoring (24-hour cache). Quarterly mineral-rights reporting submitted by issuer. Federal-action incidents handled per the Incident Response Playbook §13 within 60-minute SLA from detection to Control 42 execution.
**Suitable issuers.** US strategic-mineral basin operators, rare earth mining concessions, carbon-ore (DOE coal-derived REE recovery) operations, and other Module 3 asset classes aligned with the federal critical-minerals supply-chain priorities.
***
#### Related Documentation
* **Smart Contract Reference** — Program-by-program documentation including instruction signatures, account schemas, event emissions, and PDA registry.
* **Transfer Hook Reference** — Standalone reference for the 42 controls, including module-aware extensions.
* **Empire Stock Transfer Integration** — Custody architecture, Ed25519 attestation lifecycle, MSF, KYC/KYB/AML/OFAC, conflict-of-interest disclosure, module-aware custody coverage.
* **Compliance Integration Guide** — Regulatory mapping, Category 1 Model B requirements, BSA/AML, OFAC, holding periods, module-specific compliance, federal-action coordination.
* **Oracle Integration Guide** — Custody, OFAC, AML, TWAP, EDGAR, NAV (Module 2), Classification (Module 3) relay architecture.
* **Tokenomics Deep Dive** — Pool economics, fee distribution, NAV mechanics, and protocol revenue.
* **Security Model** — Threat model and investor-protection architecture.
***
*RWA Tokens · Issuer Onboarding Guide · Groovy Company, Inc.* *Issuer Services contact: *
# Stablecoin Settlement Guide
### Stablecoin Settlement Guide
**USDC · PYUSD · GENIUS Act Compliance · End-to-End Purchase Flow · On-Chain Settlement**
How ST22 Digital Securities purchases settle on the RWA Tokens platform. All transactions — primary offerings and secondary CEDEX trades — settle through GENIUS Act-compliant stablecoins. No fiat wire transfers. No SOL or other cryptocurrency. This page explains which stablecoins are accepted, why stablecoins were chosen over alternatives, how an investor goes from dollars in a bank to ST22 tokens in a wallet, and the on-chain settlement mechanics that apply uniformly across all three production modules: Equities (Module 1), Real Estate (Module 2), and CORECM — Carbon Ore, Rare Earth, and Critical Minerals (Module 3).
Settlement is module-agnostic at the technical level. The same USDC and PYUSD primitives, the same atomic-settlement architecture, and the same fee distribution apply to every ST22 token regardless of which module issued it. Module-specific behavior arises only from offering structure (Reg CF flow for Module 1) and module-aware Transfer Hook controls (NAV-deviation breaker for Module 2; federal-action freeze for Module 3).
***
#### Table of Contents
1. Settlement Architecture
2. Accepted Stablecoins
3. Why Stablecoins — Not Fiat, Not Crypto
4. GENIUS Act Compliance
5. End-to-End Purchase Flow — Primary Offering
6. End-to-End Purchase Flow — Secondary Trade
7. Fiat On-Ramp Options
8. On-Chain Settlement Mechanics
9. Settlement Finality
10. Fee Application During Settlement
11. Stablecoin Risk Framework
12. CTR and BSA Implications
13. Developer Integration
14. Module-Specific Settlement Considerations
15. Investor FAQ
***
#### 1. Settlement Architecture
Copy
```
INVESTOR'S BANK ACCOUNT (USD)
│
├─ Fiat on-ramp (Coinbase, Kraken, PayPal, MoonPay, Transak)
│ └─ Investor purchases USDC or PYUSD
│ └─ Stablecoin delivered to investor's Solana wallet
│
▼
INVESTOR'S SOLANA WALLET (USDC or PYUSD)
│
├─ PRIMARY OFFERING: Investor submits subscription via CEDEX
│ └─ Stablecoin transferred to issuer treasury (minus 5% fee)
│ └─ ST22 tokens delivered to investor wallet
│
├─ SECONDARY TRADE: Investor places order on CEDEX
│ └─ CPMM swap executes against Global Pool
│ └─ Stablecoin ↔ ST22 exchange at algorithmic price
│ └─ 5% fee distributed on chain
│
▼
SETTLEMENT COMPLETE
│
├─ ST22 tokens in investor wallet (Transfer Hook enforced)
├─ Stablecoin in counterparty wallet (seller or issuer)
├─ Fee distributed to four recipients (on chain, atomic)
└─ Empire MSF updated (UCC Article 8 entitlement order)
```
**Key Property — Atomic Settlement**
The stablecoin transfer and the ST22 token transfer execute in the **same Solana transaction**. If either side fails — Transfer Hook rejection, insufficient balance, oracle staleness, NAV-deviation breaker active (Module 2), federal-action freeze active (Module 3) — the entire transaction reverts. No partial settlement is possible.
This atomicity is the structural difference between blockchain settlement and traditional securities settlement. T+1 in DTCC requires reconciliation, fails-management, and counterparty risk monitoring; \~13-second on-chain settlement either completes both legs or completes neither.
***
#### 2. Accepted Stablecoins
StablecoinIssuerBackingSolana Mint AddressProgramDecimals
**USDC**
Circle
USD reserves + short-duration US Treasuries
`EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v`
SPL Token
6
**PYUSD**
Paxos (for PayPal)
USD deposits + US Treasuries + overnight repos
`2b1kV6DkPAnxd5ixfnxCpjxmKwqjjaYmCZfHsFu24GXo`
SPL Token
6
**Why These Two**
CriterionUSDCPYUSDUSDT (not accepted)
GENIUS Act compliant
Yes — Circle is a registered money transmitter
Yes — Paxos is NYDFS-regulated trust company
Pending — Tether's reserves composition is less transparent
US-regulated issuer
Yes — Circle (US entity)
Yes — Paxos (NY-regulated)
No — Tether (BVI-domiciled)
Reserve transparency
Monthly attestations by Deloitte
Monthly attestations by WithumSmith+Brown
Quarterly reports, historically contested
Solana native
Yes — native SPL Token mint
Yes — native SPL Token mint
Yes, but regulatory profile insufficient
Institutional acceptance
Widest — used across regulated financial products
Growing — PayPal distribution network
Limited institutional adoption in regulated products
The platform accepts only GENIUS Act-compliant stablecoins from US-regulated issuers with transparent reserve attestations. This is a regulatory-architecture decision, not a technical limitation. Adding additional stablecoins is governance-gated and requires compliance review, GENIUS Act qualification, and a 5-of-9 multi-signature update to the Network Configuration.
***
#### 3. Why Stablecoins — Not Fiat, Not Crypto
**Why Not Fiat Wire Transfer**
IssueDetail
Speed
Wire transfers take 1–5 business days. Stablecoin settlement: \~13 seconds.
Availability
Wire transfers operate during banking hours (M–F). CEDEX trades 24/7/365.
Atomic settlement
Wire plus token delivery cannot execute atomically. Creates settlement risk (investor sends wire, tokens not delivered; or vice versa). Stablecoin plus ST22 settle in the same Solana transaction.
Global access
International wires are expensive ($25–$50), slow (3–5 days), and involve correspondent-banking friction. USDC and PYUSD are global by design.
Reconciliation
Wire transfers require manual reconciliation between bank statements and on-chain records. Stablecoin settlement is self-reconciling — the on-chain record IS the settlement record.
**Why Not SOL or Other Cryptocurrency**
IssueDetail
Price volatility
SOL, BTC, and ETH fluctuate significantly intraday. An investor subscribing $100,000 in SOL could receive $90,000 or $110,000 of value depending on the hour. Stablecoins maintain $1.00 ± 0.01 parity.
Issuer proceeds
Issuers need predictable USD proceeds for operations. Receiving volatile crypto creates treasury-management complexity and FX risk.
Reg D / Reg CF compliance
Subscription amounts must be denominated in USD for Form D and Form C filings, and accreditation thresholds ($200K income / $1M net worth) and Reg CF investment limits are USD-denominated.
GAAP accounting
Cryptocurrency accounting is complex (ASC 350-60 intangible-asset treatment). Stablecoins are treated as cash equivalents.
GENIUS Act alignment
The GENIUS Act establishes a federal framework for payment stablecoins. Using compliant stablecoins positions the platform within this framework.
**Why Stablecoins Are the Right Answer**
Stablecoins provide the speed and atomicity of on-chain settlement with the price stability of USD. The combination is unique — no other instrument provides sub-second, 24/7, globally accessible, programmatically-settleable, price-stable value transfer.
Copy
```
SETTLEMENT COMPARISON
Fiat Wire: 1-5 days · business hours · non-atomic · $25-50 fee
SOL/BTC/ETH: ~13 sec · 24/7 · atomic · VOLATILE
USDC/PYUSD: ~13 sec · 24/7 · atomic · $1.00 STABLE ✓
```
***
#### 4. GENIUS Act Compliance
**What the GENIUS Act Does**
The Guiding and Establishing National Innovation for U.S. Stablecoins Act (GENIUS Act) establishes a federal framework for "payment stablecoins" — digital assets pegged to the US dollar, issued by regulated entities, backed by qualifying reserves, and redeemable at par.
**GENIUS Act Requirements for Payment Stablecoins**
RequirementUSDCPYUSD
Issued by licensed entity
Circle — state money transmitter licenses + pending federal registration
Paxos — NYDFS-regulated trust company
Backed by qualifying reserves
USD deposits, US Treasury bills, overnight repos
USD deposits, US Treasury bills, overnight repos
1:1 redeemable at par
Yes — redeem USDC for $1.00 USD on demand
Yes — redeem PYUSD for $1.00 USD on demand
Regular reserve attestations
Monthly by Deloitte (Big Four)
Monthly by WithumSmith+Brown (CPA firm)
Segregated reserves
Yes — reserves held separate from operating funds
Yes — held at regulated custodians
**Why This Matters**
Using GENIUS Act-compliant stablecoins means that the platform's settlement layer operates within a recognized federal framework — not in a regulatory grey area. When an investor purchases ST22 tokens with USDC, every component of the transaction has a regulatory home: the token (SEC Release No. 33-11412), the custody (Empire Stock Transfer §17A), the compliance enforcement (42 Transfer Hook controls), and the settlement currency (GENIUS Act).
This regulatory layering is part of the platform's Category 1 Model B compliance posture under the January 28, 2026 Joint Staff Statement.
***
#### 5. End-to-End Purchase Flow — Primary Offering
The primary-offering flow varies slightly by exemption. The fundamental on-chain mechanics are identical; the verification gate at Empire and the documents executed differ.
**5.1 Reg D (US Accredited) and Reg S (Non-US) Primary**
Copy
```
STEP 1: INVESTOR COMPLETES EMPIRE VERIFICATION
├─ KYC / KYB + accreditation (Reg D) or non-US person (Reg S)
├─ AML risk scoring (Chainalysis KYT, TRM Labs)
├─ OFAC and SDN screening
└─ Wallet verification (KYW) — investor's Solana wallet whitelisted
STEP 2: INVESTOR ACQUIRES STABLECOIN
├─ Option A: Buy USDC on Coinbase / Kraken → withdraw to Solana wallet
├─ Option B: Buy PYUSD via PayPal → transfer to Solana wallet
├─ Option C: Buy USDC via MoonPay / Transak directly in wallet app
└─ Result: Investor holds USDC or PYUSD in their verified Solana wallet
STEP 3: INVESTOR SUBSCRIBES VIA CEDEX
├─ Select ST22 offering on cedex.market
├─ Enter subscription amount (e.g., $100,000 USDC)
├─ CEDEX pre-flight compliance check:
│ ├─ Empire verification confirmed ✓
│ ├─ Accreditation valid (Reg D) or non-US person (Reg S) ✓
│ ├─ OFAC screening passed ✓
│ ├─ AML score acceptable ✓
│ └─ Wallet concentration check ✓
└─ Investor signs transaction with wallet
STEP 4: ON-CHAIN SETTLEMENT (single Solana transaction)
├─ USDC transferred from investor wallet:
│ ├─ $95,000 → Issuer treasury wallet
│ ├─ $2,000 → Issuer fee allocation (2%)
│ ├─ $1,500 → GROO staking pool (1.5%)
│ ├─ $1,060 → Protocol operations (1.06%)
│ └─ $440 → Global Pool (0.44% — PERMANENTLY LOCKED)
│
├─ ST22 tokens minted and delivered to investor wallet
│ └─ 1:1 with custodied asset
│
├─ Transfer Hook executes all 42 controls ✓
│
├─ HoldingPeriodAccount created:
│ ├─ purchase_timestamp = now (Solana runtime clock)
│ ├─ jurisdiction = US (Reg D, 6 months) or NonUS (Reg S, 12 months)
│ └─ is_locked = true
│
└─ Empire MSF updated (UCC Article 8 entitlement order)
STEP 5: SETTLEMENT CONFIRMATION
├─ Solana transaction confirmed (~400ms)
├─ Finalized (~13 seconds / 32 confirmations)
├─ Investor sees ST22 tokens in wallet
└─ Holding-period countdown begins
```
**5.2 Reg CF (US Retail) Primary**
Reg CF offerings must be conducted through a FINRA-registered funding portal. The platform is currently evaluating funding-portal registration to support direct Reg CF issuances. Until that registration is in place, Reg CF offerings on the platform are conducted in partnership with an existing FINRA-registered funding portal that handles the offering origination and Form C filing.
The investor flow is structurally identical to Reg D / Reg S, with three differences at Empire's verification gate:
Copy
```
DIFFERENCES FROM REG D / REG S FLOW:
STEP 1 (modified): EMPIRE VERIFICATION
├─ Standard KYC + AML + OFAC + KYW
├─ Reg CF investor-cap verification:
│ ├─ Annual income or net worth determines investment cap
│ ├─ Cap formula per 17 CFR §227.100(a)(2)
│ └─ Empire enforces cap at subscription
└─ Funding portal subscription documents executed
(Form C, educational materials, risk disclosures)
STEP 4 (modified): HOLDING PERIOD
└─ jurisdiction = RegCF
holding_period_secs = 31,536,000 (12 months — Reg CF compliance period)
ALL OTHER STEPS IDENTICAL
```
The same atomic-settlement architecture, same Transfer Hook 42 controls, same fee distribution, and same Empire MSF update apply.
***
#### 6. End-to-End Purchase Flow — Secondary Trade
After the holding period elapses, investors trade ST22 tokens on CEDEX. Settlement is stablecoin-denominated regardless of module.
**Sell Flow**
Copy
```
SELLER places sell order on CEDEX
│
├─ CEDEX pre-flight: all 42 controls simulated
│ ├─ Control 24: holding period elapsed ✓
│ ├─ (Module 2) NAV deviation within bounds ✓
│ └─ (Module 3) Classification fresh; no federal-action freeze ✓
│
├─ CPMM calculates output:
│ Input: 1,000 ST22 tokens
│ Pool reserves:
│ Output: X USDC (after 5% fee)
│
├─ Single Solana transaction:
│ ├─ ST22 tokens from seller → Global Pool
│ ├─ USDC from Global Pool → seller wallet (minus fee)
│ ├─ Fee distributed to four recipients
│ └─ Transfer Hook: all 42 controls on the ST22 transfer ✓
│
└─ Settlement complete in ~13 seconds
```
**Buy Flow**
Copy
```
BUYER places buy order on CEDEX
│
├─ CEDEX pre-flight: buyer verification
│ ├─ Empire verified, eligible, OFAC clear ✓
│ ├─ (Module 2) NAV deviation within bounds ✓
│ └─ (Module 3) Classification fresh; no federal-action freeze ✓
│
├─ Single Solana transaction:
│ ├─ USDC from buyer → Global Pool
│ ├─ ST22 tokens from Global Pool → buyer wallet
│ ├─ Fee distributed to four recipients
│ ├─ Transfer Hook: all 42 controls on the ST22 transfer ✓
│ └─ New HoldingPeriodAccount created for buyer
│
└─ Settlement complete. Buyer's holding period starts NOW.
```
***
#### 7. Fiat On-Ramp Options
The platform does not operate a fiat on-ramp directly. Investors acquire stablecoins through regulated third-party providers before interacting with CEDEX.
**Recommended On-Ramp Providers**
ProviderStablecoinsMethodsSolana Native?Speed
Coinbase
USDC
Bank transfer (ACH), wire, debit card
Yes — direct Solana USDC withdrawal
ACH 1–3 days; wire same day; card instant
Kraken
USDC
Bank transfer, wire, crypto deposit
Yes — Solana USDC withdrawal
Wire same day; ACH 1–3 days
PayPal
PYUSD
PayPal balance, bank, debit card
Yes — native PYUSD on Solana
Instant with PayPal balance
MoonPay
USDC
Credit/debit card, bank transfer, Apple Pay
Yes — direct to Solana wallet
Card instant; bank 1–3 days
Transak
USDC
Bank, card, Apple Pay, Google Pay
Yes — direct to Solana wallet
Card instant; bank 1–3 days
**On-Ramp Flow**
Copy
```
INVESTOR (has USD in bank)
│
├─ Opens Coinbase / Kraken / PayPal / MoonPay account
├─ Completes provider's KYC (separate from Empire KYC)
├─ Purchases USDC or PYUSD with USD
├─ Withdraws to their verified Solana wallet address
│ └─ Must be the same wallet registered with Empire (KYW)
│
▼
INVESTOR'S SOLANA WALLET
│
└─ USDC / PYUSD balance ready for CEDEX trading
```
**Important: On-Ramp KYC Is Separate from Empire KYC**
The KYC performed by Coinbase, Kraken, or any other on-ramp provider satisfies that platform's regulatory requirements. It does not satisfy Empire Stock Transfer's investor verification requirements. Investors must complete Empire's full KYC / KYB / AML / OFAC / accreditation verification and wallet verification (KYW) separately before trading on CEDEX. Holding stablecoins in a Solana wallet does not grant CEDEX access — Empire's MSF registration does.
***
#### 8. On-Chain Settlement Mechanics
**Token Programs Involved**
TokenProgramMint AddressRole in Settlement
**USDC**
SPL Token (original)
`EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v`
Payment currency
**PYUSD**
SPL Token (original)
`2b1kV6DkPAnxd5ixfnxCpjxmKwqjjaYmCZfHsFu24GXo`
Payment currency
**ST22**
SPL Token-2022
Per-issuer mint address
Security being traded
USDC and PYUSD use the original SPL Token Program (no Transfer Hook). ST22 tokens use SPL Token-2022 (with Transfer Hook). A CEDEX swap involves both token programs in a single transaction.
**Transaction Composition**
A complete CEDEX swap transaction contains multiple instructions. The structure is the same regardless of module — a Module 1, Module 2, or Module 3 ST22 swap composes identically:
Copy
```
Transaction {
instructions: [
// 1. Compute budget for hook execution + CPI overhead
ComputeBudgetProgram.setComputeUnitLimit(800_000),
ComputeBudgetProgram.setComputeUnitPrice(dynamic_priority_fee),
// 2. Platform AMM swap instruction
amm::swap {
input_mint: USDC_MINT, // or PYUSD_MINT
output_mint: ST22_MINT,
amount_in: 100_000_000_000, // 100,000 USDC (6 decimals)
min_amount_out: 95_000_000, // slippage protection
},
// Within the AMM swap, via CPI:
// ├─ SPL Token: transfer USDC from buyer to pool
// ├─ SPL Token-2022: transfer ST22 from pool to buyer
// │ └─ Transfer Hook invoked (42 controls)
// └─ Fee distribution (4 recipients)
],
signers: [buyer_wallet],
}
```
**Atomicity**
Every instruction in the transaction executes or none do. If the Transfer Hook rejects the ST22 transfer — holding period not elapsed, OFAC match, wallet limit exceeded, NAV-deviation breaker active (Module 2), federal-action freeze active (Module 3) — the USDC transfer also reverts. The investor keeps their stablecoins. No partial settlement.
This is enforced at the Solana runtime level. There is no software path to a partially-completed settlement, regardless of which party tries to construct one.
***
#### 9. Settlement Finality
StageTimingMeaning
Transaction submitted
0ms
Submitted to Solana via Jito Block Engine (MEV protection)
Processed
\~400ms
Leader validator has processed — not yet safe
Confirmed
\~400ms
2/3+ stake supermajority voted — CEDEX considers settled
Finalized
\~13 seconds
32 confirmations — irreversible under all conditions
CEDEX uses `confirmed` commitment for displaying trade results to users and `finalized` commitment for fee distribution and Empire MSF updates. The practical settlement time for an investor is \~400ms (trade appears in portfolio) with full finality at \~13 seconds.
**Comparison to Traditional Settlement**
VenueSettlement TimeFinality
NYSE / NASDAQ
T+1 (next business day)
DTCC settlement
OTC Markets (OTCQB / OTCID / Expert Market)
T+2 (two business days)
Transfer agent
Other digital-securities platforms
T+0 to T+1
Platform-dependent
**CEDEX**
**\~13 seconds**
**Solana blockchain — irreversible**
The CEDEX settlement time is a structural property of running on-chain. It is not faster *because of optimization* — it is faster because the architectural model collapses several DTCC-era steps (matching, clearing, settling, custody update) into a single atomic transaction.
***
#### 10. Fee Application During Settlement
The 5% fee is applied within the settlement transaction — not as a separate charge.
**Primary Offering**
Copy
```
Investor subscribes: $100,000 USDC
On chain (single transaction):
USDC transfers:
$95,000.00 → Issuer treasury
$2,000.00 → Issuer fee wallet (2.00%)
$1,500.00 → GROO staking pool (1.50%)
$1,060.00 → Protocol operations (1.06%)
$440.00 → Global Pool (0.44% — locked)
ST22 tokens:
Minted and delivered to investor wallet
Amount: 100% of subscribed tokens (fee is cost of access, not dilution)
```
**Secondary Trade**
Copy
```
Buyer purchases $10,000 USDC worth of ST22 on CEDEX
On chain (single transaction):
USDC from buyer → Pool (input side of CPMM)
ST22 from pool → buyer (output side of CPMM)
Fee (5% of input, deducted before CPMM calculation):
$200.00 → Issuer treasury (2.00%)
$150.00 → GROO staking pool (1.50%)
$106.00 → Protocol operations (1.06%)
$44.00 → Global Pool (0.44% — locked)
Net input to CPMM: $9,500 USDC
ST22 output: calculated by CPMM formula (x × y = k)
```
The 0.44% Global Pool allocation is the structural mechanism for monotonic pool deepening. Across all modules, every secondary trade adds to the Global Pool reserve. This is verified by Certora invariant E.3 (Global Pool non-extractability) — no instruction in any program can reduce the Global Pool balance.
***
#### 11. Stablecoin Risk Framework
Stablecoins are not risk-free. The platform mitigates stablecoin-specific risks through architectural choices.
**Risk Assessment**
RiskDescriptionMitigation
De-peg risk
USDC or PYUSD trading below $1.00
Two accepted stablecoins — if one de-pegs, investors can use the other. CEDEX displays real-time peg status from Pyth Network.
Issuer insolvency
Circle or Paxos becomes insolvent
Both are US-regulated with segregated reserves. GENIUS Act requires qualifying reserve composition. Monthly reserve attestations.
Regulatory freeze
US government freezes stablecoin addresses
OFAC compliance — Empire screens all wallets via CIP/AML/KYW. Frozen stablecoin addresses cannot interact with CEDEX.
Smart-contract exploit
Vulnerability in USDC or PYUSD token program
Both use the battle-tested original SPL Token Program (not Token-2022). Years of production usage; multiple audits.
Blacklisting
Circle or Paxos blacklists a wallet address
Both stablecoins have issuer-level blacklist capability. The platform cannot prevent issuer-level action. Investors should maintain compliance with stablecoin issuer terms.
Redemption risk
Unable to convert back to USD
Both offer direct redemption. Coinbase, Kraken, PayPal, and other on-ramp providers offer liquid off-ramp.
**De-Peg Circuit Breaker**
If either accepted stablecoin deviates more than 2% from the $1.00 peg (as measured by Pyth Network oracle), CEDEX automatically halts acceptance of that stablecoin for new orders until the peg is restored. Existing positions are unaffected — the breaker prevents new trades from executing at distorted prices. The breaker is implemented as part of the Pyth-backed price-impact circuit-breaker check (CB-21).
***
#### 12. CTR and BSA Implications
**Currency Transaction Reports**
CTR requirements (31 CFR §1010.311) apply when fiat currency is involved. Most platform transactions are stablecoin-based and do not trigger CTR filing.
Transaction TypeFiat Involved?CTR Applicable?
Investor buys USDC on Coinbase with bank transfer
Yes — at Coinbase
Coinbase files if ≥ $10,000
Investor transfers USDC to Solana wallet
No — stablecoin transfer
No CTR
Investor buys ST22 on CEDEX with USDC
No — stablecoin settlement
No CTR
Investor sells ST22 on CEDEX, receives USDC
No — stablecoin settlement
No CTR
Investor sells USDC on Coinbase for USD bank deposit
Yes — at Coinbase
Coinbase files if ≥ $10,000
**BSA Obligations**
Empire Stock Transfer's BSA obligations apply to all platform transactions regardless of settlement currency. SAR filing thresholds (≥ $5,000 suspicious activity) are evaluated on the USD-equivalent value of stablecoin transactions, not only on fiat transactions. Empire's CIP (31 CFR §1023.220), CTR (§1010.311), and SAR (§1023.320) procedures are documented in the AML Policy.
***
#### 13. Developer Integration
**Checking Investor's Stablecoin Balance**
Copy
```
import { getAssociatedTokenAddress, getAccount } from '@solana/spl-token';
import { PublicKey } from '@solana/web3.js';
const USDC_MINT = new PublicKey('EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v');
const PYUSD_MINT = new PublicKey('2b1kV6DkPAnxd5ixfnxCpjxmKwqjjaYmCZfHsFu24GXo');
// Get USDC balance
const usdcAta = await getAssociatedTokenAddress(USDC_MINT, walletPubkey);
const usdcAccount = await getAccount(connection, usdcAta);
const usdcBalance = Number(usdcAccount.amount) / 1e6; // 6 decimals
// Get PYUSD balance
const pyusdAta = await getAssociatedTokenAddress(PYUSD_MINT, walletPubkey);
const pyusdAccount = await getAccount(connection, pyusdAta);
const pyusdBalance = Number(pyusdAccount.amount) / 1e6; // 6 decimals
```
**Executing a CEDEX Swap via SDK**
Copy
```
import { RwaTokensClient } from '@rwatokens/sdk';
const client = new RwaTokensClient({ network: 'mainnet-beta' });
// Buy ST22 tokens with USDC
const result = await client.cedex.swap({
inputMint: 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v', // USDC
outputMint: '',
amountIn: 100_000_000_000n, // 100,000 USDC (6 decimals)
slippageBps: 100, // 1% slippage tolerance
});
// result.outputAmount: ST22 tokens received
// result.feesPaid: { issuer, staking, protocol, pool }
// result.txSignature: Solana transaction signature
```
**Estimating a Swap Before Execution**
Copy
```
const estimate = await client.cedex.estimateSwap({
inputMint: 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v',
outputMint: '',
amountIn: 100_000_000_000n,
});
// estimate.expectedOutput: ST22 tokens
// estimate.priceImpactBps: price impact in basis points
// estimate.feeBreakdown: { issuer, staking, protocol, pool }
// estimate.wouldSucceed: boolean (pre-flight compliance check)
// estimate.failureReason?: string (if wouldSucceed is false)
```
The pre-flight check evaluates all 42 Transfer Hook controls in simulation mode before the actual transaction is submitted. Module-aware checks (Module 2 NAV-deviation, Module 3 federal-action freeze) are included in the simulation. If `wouldSucceed` is false, the application can present a specific reason to the user before requiring a wallet signature.
***
#### 14. Module-Specific Settlement Considerations
The settlement architecture is module-agnostic at the technical level. The same USDC and PYUSD primitives, same atomic-settlement transaction structure, same fee distribution, and same SDK integration apply to all three modules. Module-specific settlement considerations arise in three places: pre-flight compliance behavior, holding-period configuration, and circuit-breaker interactions.
**14.1 Module 1 — Equities**
**Settlement architecture.** Standard. No module-specific behavior beyond the standard 42 Transfer Hook controls.
**Holding period.** Reg D 6 months; Reg S 12 months; Reg CF 12 months (when Reg CF is the offering exemption).
**Pre-flight checks.** Standard — Empire verification, accreditation, OFAC, AML, wallet concentration, and TWAP-based price impact (CB-21).
**Module-specific failure modes.** EDGAR-pipeline issuer eligibility (Control 37 — issuer SEC reporting must be current; protective conversion may trigger if issuer's reporting lapses).
**14.2 Module 2 — Real Estate**
**Settlement architecture.** Standard at the SPL Token-2022 / fee distribution level. The NAV-deviation breaker is layered into the price-impact check.
**Holding period.** Reg D 6 months; Reg S 12 months (Reg CF rare for real estate).
**Pre-flight checks.** Adds NAV-deviation check. The pre-flight verifies that the proposed trade price is within `nav_deviation_max_bps` of the most recent appraised NAV. If the on-chain price exceeds this bound, the pre-flight returns `wouldSucceed: false` with `failureReason: "NAV_DEVIATION_EXCEEDED"`. The mint stays paused on the AMM until a fresh appraisal restores the price within bounds.
**Module-specific failure modes.** Stale NAV oracle (`nav_reappraisal_max_age_secs` exceeded — the mint is paused pending fresh appraisal). Settlement is unaffected for in-flight trades that pass pre-flight, but new orders are rejected.
**Settlement implication for integrators.** Application code displaying real-time prices for Module 2 ST22 tokens should also display the NAV reference and the deviation. This gives users the context for understanding why a trade may be rejected by NAV-deviation enforcement even when pool reserves and stablecoin balance are sufficient.
**14.3 Module 3 — CORECM**
**Settlement architecture.** Standard at the SPL Token-2022 / fee distribution level. The federal-action freeze is an additional pre-flight check that activates Control 42 (regulatory freeze).
**Holding period.** Reg D 6 months; Reg S 12 months; Reg CF 12 months.
**Pre-flight checks.** Adds Classification-oracle freshness check and federal-action status check. The pre-flight verifies that the Classification oracle is fresh (within `classification_max_age_secs`) and that no active federal action is in force for the basin asset. If either check fails, the pre-flight returns `wouldSucceed: false` with `failureReason: "CLASSIFICATION_STALE"` or `failureReason: "FEDERAL_ACTION_FROZEN"`.
**Module-specific failure modes.** A federal action issued during market hours triggers an automatic P0 incident under the Incident Response Playbook §13. Legal Counsel and 3-of-5 multi-signature execute Control 42 (regulatory freeze) on each affected mint within 60 minutes. From the moment the freeze is on chain, all in-flight settlement transactions targeting affected mints will revert at the Transfer Hook level. Pre-flight checks made before the freeze return correct results; pre-flight checks made after the freeze immediately return `wouldSucceed: false`.
**Settlement implication for integrators.** Application code handling Module 3 ST22 tokens should subscribe to the `RegulatoryFreezeEvent` and `ClassificationOracleUpdated` events emitted by the Oracle Aggregator program. This gives the integrator real-time visibility into freeze state changes without polling.
**14.4 Cross-Module Settlement Properties**
The following settlement properties are identical across all three modules:
* USDC and PYUSD are the only accepted settlement currencies.
* The 5% fee distribution (2% / 1.5% / 1.06% / 0.44%) is identical.
* The Global Pool 0.44% allocation is permanently locked across all module activity.
* Settlement finality (\~13 seconds, 32 confirmations) is identical.
* Atomic settlement guarantees are identical.
* Empire MSF update via UCC Article 8 entitlement order is identical.
* The same SDK (`@rwatokens/sdk`) handles swaps for all modules transparently.
* The pre-flight check API is the same — `client.cedex.estimateSwap()` returns the same structure regardless of module; module-specific failure reasons are surfaced through the `failureReason` field.
***
#### 15. Investor FAQ
**Can I pay with a credit card?**
Not directly on CEDEX. You can purchase USDC via MoonPay or Transak using a credit or debit card, then use that USDC on CEDEX. Card purchases may incur the on-ramp provider's fees (typically 1–3%).
**Can I pay with SOL?**
No. ST22 purchases settle exclusively in USDC or PYUSD. This is a regulatory architecture decision — stablecoins provide the price stability required for Reg D / Reg S / Reg CF subscription denomination and issuer USD proceeds.
**Can I pay with Bitcoin or Ethereum?**
No. Convert BTC or ETH to USDC on any exchange (Coinbase, Kraken), then use USDC on CEDEX.
**What if USDC de-pegs?**
If USDC deviates more than 2% from $1.00, CEDEX halts USDC acceptance for new orders. You can use PYUSD instead (or vice versa). Existing positions are unaffected.
**How do I get my money back as USD?**
Sell your ST22 tokens on CEDEX (after the holding period elapses) → receive USDC or PYUSD → transfer to Coinbase, Kraken, or PayPal → withdraw as USD to your bank. The off-ramp process is the reverse of the on-ramp.
**Are stablecoin transactions reported to the IRS?**
The platform does not provide tax advice. Generally, stablecoin-to-ST22 swaps may be taxable events. Consult a qualified tax advisor. CEDEX provides transaction history exports for tax-reporting purposes.
**Why not just use a bank wire?**
Bank wires cannot settle atomically with on-chain token delivery. A wire takes 1–5 business days, operates during banking hours only, and creates settlement risk (investor sends wire but tokens are not delivered, or vice versa). Stablecoin settlement is instant, 24/7, and atomic — both sides of the trade complete in the same Solana transaction or neither does.
**Is there a minimum purchase amount?**
The minimum is determined by the issuer's offering terms and CEDEX's minimum order size (configurable per ST22 token). There is no platform-wide minimum imposed by the stablecoin settlement layer.
**Do I need both USDC and PYUSD?**
No. Either one works. CEDEX accepts both interchangeably. Most investors use whichever stablecoin is easiest for them to acquire.
**What happens to my settlement if a Module 3 federal-action freeze is issued during my trade?**
If you submit a transaction before the freeze is on chain, the transaction may still settle if it lands before the freeze. Once the freeze is on chain, all subsequent transactions on the affected mint revert at the Transfer Hook layer; your stablecoins remain in your wallet untouched. If your application uses pre-flight checks (`client.cedex.estimateSwap()`), the failure surfaces with `failureReason: "FEDERAL_ACTION_FROZEN"` and you can avoid signing a transaction that would fail.
***
#### Related Documentation
* **CEDEX API Reference** — Swap endpoints, estimate endpoints, order types.
* **SDK Reference** — `RwaTokensClient` swap and estimate methods.
* **Tokenomics Deep Dive** — 5% fee structure, distribution, NAV mechanics, Global Pool dynamics.
* **Compliance Integration Guide** — BSA/AML implications, CTR filing thresholds, Empire CIP/SAR procedures.
* **Issuer Onboarding Guide** — Module-specific onboarding flow including Reg D / Reg S / Reg CF gates.
* **Oracle Integration Guide** — Pyth TWAP, NAV oracle (Module 2), Classification oracle (Module 3).
* **Architecture Decisions** — ADR-009 (GENIUS Act stablecoin settlement) and related decisions.
* **Incident Response Playbook** — Module 3 federal-action freeze runbook (§13).
***
*RWA Tokens · Stablecoin Settlement Guide · Groovy Company, Inc.*
# Welcome
# Page 1
# Welcome
Welcome to the **RWA Tokens Marketing Wiki** — the central library for everything we publish about the platform to the outside world. Articles, pitch decks, the lightpaper, investor presentations, SEC filings and staff statements we cite, regulatory commentary, and ongoing news coverage all live here, organized so the comms team, partners, and counsel can find the right asset for the right audience without rebuilding it from scratch.
You'll find collateral grouped by the three asset-class modules — **Equities (ST22), Real Estate, and CORECM** — alongside cross-cutting materials that apply to the platform as a whole: corporate-identity assets, SEC regulatory framework references (Release No. 33-11412, the January 28, 2026 Joint Staff Statement, the April 13, 2026 Covered User Interface Providers statement), and the live news and X/LinkedIn campaign archive. Each item is tagged by audience (institutional investor, issuer prospect, regulator, press) and by stage (draft, internal review, legal-cleared, published) so nothing ships externally without the right approval state.
This wiki is the canonical source for any RWA Tokens marketing artifact under the Groovy Company, Inc. brand (the "OTCM Protocol" dba was retired May 1, 2026; CEDEX, ST22, and GROO remain as product and instrument names). Platform URL is [**https://rwatokens.net**](https://rwatokens.net/); trading venue is **cedex.market**. When in doubt about which version of a deck or letter is current, this wiki is the answer — anything found elsewhere should be checked against the version here before sending.
# Page 1
# Welcome
Welcome to the **RWA Tokens Marketing Wiki** — the central library for everything we publish about the platform to the outside world. Articles, pitch decks, the lightpaper, investor presentations, SEC filings and staff statements we cite, regulatory commentary, and ongoing news coverage all live here, organized so the comms team, partners, and counsel can find the right asset for the right audience without rebuilding it from scratch.
You'll find collateral grouped by the three asset-class modules — **Equities (ST22), Real Estate, and CORECM** — alongside cross-cutting materials that apply to the platform as a whole: corporate-identity assets, SEC regulatory framework references (Release No. 33-11412, the January 28, 2026 Joint Staff Statement, the April 13, 2026 Covered User Interface Providers statement), and the live news and X/LinkedIn campaign archive. Each item is tagged by audience (institutional investor, issuer prospect, regulator, press) and by stage (draft, internal review, legal-cleared, published) so nothing ships externally without the right approval state.
This wiki is the canonical source for any RWA Tokens marketing artifact under the Groovy Company, Inc. brand (the "OTCM Protocol" dba was retired May 1, 2026; CEDEX, ST22, and GROO remain as product and instrument names). Platform URL is [**https://rwatokens.net**](https://rwatokens.net/); trading venue is **cedex.market**. When in doubt about which version of a deck or letter is current, this wiki is the answer — anything found elsewhere should be checked against the version here before sending.
# CEDEX API Reference
## CEDEX API Reference
**Compliant Exchange for Digital Securities · REST + WebSocket · v1.0 · Module-Aware**
API reference for cedex.market — the trading venue that preserves all 42 Transfer Hook security controls on every ST22 Digital Securities trade. Dual-layer architecture: centralized order matching (Web2 performance) with decentralized Solana settlement (Web3 finality). The API serves all three production modules: Equities (Module 1), Real Estate (Module 2), and CORECM — Carbon Ore, Rare Earth, and Critical Minerals (Module 3). Module-aware endpoints, error codes, and WebSocket channels are documented inline.
***
### Table of Contents
1. Overview
2. Authentication
3. Rate Limits
4. Public Endpoints
5. Authenticated Endpoints
6. WebSocket API
7. Compliance Pre-Flight
8. Error Reference
9. Pagination
10. Idempotency
11. Code Examples
12. Module-Aware API Surface
13. Changelog
***
### 1. Overview
#### Base URLs
| Environment | REST API | WebSocket |
| ----------- | ------------------------------------ | ------------------------------------- |
| Production | `https://api.cedex.market/v1` | `wss://api.cedex.market/ws/v1` |
| Devnet | `https://api.devnet.cedex.market/v1` | `wss://api.devnet.cedex.market/ws/v1` |
#### Request Format
All requests use JSON. All responses return JSON.
```
Content-Type: application/json
Accept: application/json
```
#### Timestamps
All timestamps are Unix seconds (UTC) unless otherwise noted. ISO 8601 format is available via the `?format=iso` query parameter.
#### Amounts
All token amounts are in raw units (with decimals applied). For an ST22 token with 9 decimals, `1_000_000_000` = 1.0 token. SOL amounts are in lamports (`1_000_000_000` = 1.0 SOL). Stablecoin amounts (USDC, PYUSD) are in 6-decimal raw units (`1_000_000` = 1.0 stablecoin unit).
#### Performance
| Metric | Value |
| ------------------------- | ------------------------------- |
| Pre-flight compliance | 2,000–3,000ms |
| On-chain execution | 400–600ms |
| Total order-to-settlement | 3–4 seconds |
| Block finality | \~13 seconds (32 confirmations) |
| Order book sync | 400ms (1 Solana block) |
| Compute units per swap | \~800,000 CU |
***
### 2. Authentication
#### Wallet Signature Authentication
CEDEX uses Solana wallet signature authentication. All authenticated endpoints require a signed message proving wallet ownership.
**Step 1: Request Challenge**
```
POST /auth/challenge
```
**Request:**
```json
{
"wallet": "9aB2xY..."
}
```
**Response:**
```json
{
"challenge": "CEDEX-AUTH-1711929600-a1b2c3d4",
"expires_at": 1711929900
}
```
**Step 2: Sign and Submit**
```
POST /auth/verify
```
**Request:**
```json
{
"wallet": "9aB2xY...",
"challenge": "CEDEX-AUTH-1711929600-a1b2c3d4",
"signature": "base58-encoded-ed25519-signature"
}
```
**Response:**
```json
{
"token": "eyJhbGciOiJFZDI1NTE5...",
"expires_at": 1712016000,
"wallet": "9aB2xY...",
"empire_verified": true,
"eligibility": "RegD",
"jurisdiction": "US",
"kyc_status": "verified",
"kyc_expires": 1743465600
}
```
The `eligibility` field reports the offering exemption(s) the wallet is verified for: `"RegD"` (US accredited), `"RegS"` (non-US), `"RegCF"` (US retail crowdfunding), or a comma-separated combination such as `"RegD,RegS"` for wallets that satisfy multiple paths.
**Using the Token**
Include the bearer token in all authenticated requests:
```
Authorization: Bearer eyJhbGciOiJFZDI1NTE5...
```
**Token lifetime:** 24 hours. Refresh by repeating the challenge/verify flow.
#### Empire Verification Requirement
All authenticated endpoints require Empire Stock Transfer verification. Wallets that have not completed Empire's KYC, KYB, AML, OFAC, and KYW verification receive:
```json
{
"error": {
"code": "EMPIRE_VERIFICATION_REQUIRED",
"message": "Wallet not verified by Empire Stock Transfer. Complete onboarding through your issuer."
}
}
```
Empire is the platform's sole investor onboarding authority. The platform does not perform investor verification or operate a KYC portal independent of Empire.
***
### 3. Rate Limits
| Tier | Requests/min | Orders/min | WebSocket Subscriptions |
| ------------------------------ | ------------ | ---------- | ----------------------- |
| Standard | 120 | 30 | 10 channels |
| Verified (Empire KYC complete) | 600 | 120 | 50 channels |
| Institutional (on request) | 3,000 | 600 | Unlimited |
Rate-limit headers on every response:
```
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 587
X-RateLimit-Reset: 1711929660
```
Exceeding limits returns `429 Too Many Requests`:
```json
{
"error": {
"code": "RATE_LIMITED",
"message": "Rate limit exceeded. Retry after 2026-04-01T00:01:00Z",
"retry_after": 1711929660
}
}
```
***
### 4. Public Endpoints
No authentication required. Read-only market data.
#### `GET /markets`
List all active ST22 trading pairs across all modules.
**Query Parameters:**
| Parameter | Type | Description |
| --------- | -------- | ----------------------------------------------------------- |
| `module` | `string` | Filter by module: `"equities"`, `"real_estate"`, `"corecm"` |
**Response:**
```json
{
"markets": [
{
"mint": "7xK9p2...",
"symbol": "ACME-ST22",
"module": "equities",
"issuer_name": "ACME Corporation",
"issuer_cik": "0001234567",
"decimals": 9,
"price_sol": 0.0001153,
"price_usd": 0.0184,
"volume_24h_sol": 1250.5,
"volume_24h_usd": 200080.0,
"pool_depth_sol": 50000.0,
"pool_depth_tokens": 433043000000000,
"change_24h_pct": -2.14,
"high_24h": 0.0001205,
"low_24h": 0.0001098,
"total_supply": 1000000000000000000,
"circulating_supply": 200000000000000000,
"custody_ratio": 1.0,
"custody_verified": true,
"hook_active": true,
"controls_active": 42,
"is_trading": true,
"circuit_breaker_active": false,
"listed_at": 1711929600
}
],
"count": 1,
"timestamp": 1711930000
}
```
The `module` field on each market object is one of `"equities"`, `"real_estate"`, or `"corecm"`. Module 2 markets include additional NAV-related fields (see §12.2). Module 3 markets include additional Classification-related fields (see §12.3).
#### `GET /markets/{mint}`
Get detailed market data for a single ST22 token.
**Path Parameters:**
| Parameter | Type | Description |
| --------- | -------- | -------------------------- |
| `mint` | `string` | ST22 mint address (base58) |
**Response:** Same structure as the single-market object above, plus:
```json
{
"...market fields...",
"security_config": {
"max_wallet_percent_bps": 499,
"price_impact_max_bps": 200,
"circuit_breaker_threshold_bps": 3000,
"circuit_breaker_cooldown_secs": 86400,
"holding_period_reg_d_secs": 15778800,
"holding_period_reg_s_secs": 31536000,
"holding_period_reg_cf_secs": 31536000
},
"custody": {
"custodied_balance": 1000000000,
"token_supply": 1000000000,
"ratio": 1.0,
"attestation_slot": 285000000,
"ed25519_verified": true,
"last_update_ms": 1711930000400
},
"fee_config": {
"total_bps": 500,
"pool_bps": 44,
"issuer_bps": 200,
"staking_bps": 150,
"protocol_bps": 106
}
}
```
For Module 2 markets, the response also includes a `nav` object (see §12.2). For Module 3 markets, the response also includes a `classification` object (see §12.3).
#### `GET /markets/{mint}/orderbook`
Current order book.
**Query Parameters:**
| Parameter | Type | Default | Description |
| --------- | --------- | ------- | ----------------------------------- |
| `depth` | `integer` | 20 | Number of levels per side (max 100) |
**Response:**
```json
{
"mint": "7xK9p2...",
"bids": [
{ "price": 0.0001150, "amount": 50000000000, "total": 50000000000 },
{ "price": 0.0001145, "amount": 30000000000, "total": 80000000000 },
{ "price": 0.0001140, "amount": 75000000000, "total": 155000000000 }
],
"asks": [
{ "price": 0.0001155, "amount": 40000000000, "total": 40000000000 },
{ "price": 0.0001160, "amount": 25000000000, "total": 65000000000 },
{ "price": 0.0001165, "amount": 60000000000, "total": 125000000000 }
],
"spread_bps": 4.3,
"mid_price": 0.00011525,
"timestamp": 1711930000
}
```
#### `GET /markets/{mint}/trades`
Recent trades. Newest first.
**Query Parameters:**
| Parameter | Type | Default | Description |
| --------- | --------- | ------- | ------------------------------- |
| `limit` | `integer` | 50 | Results per page (max 200) |
| `before` | `string` | — | Cursor: trade ID for pagination |
| `after` | `string` | — | Cursor: trade ID for pagination |
**Response:**
```json
{
"trades": [
{
"id": "trade_a1b2c3d4",
"mint": "7xK9p2...",
"side": "buy",
"amount": 10000000000,
"price": 0.0001153,
"value_sol": 1.153,
"fee_sol": 0.05765,
"fee_breakdown": {
"pool": 0.005074,
"issuer": 0.02306,
"staking": 0.017295,
"protocol": 0.012221
},
"price_impact_bps": 12,
"tx_signature": "5vGh7kJ...",
"block_slot": 285000150,
"timestamp": 1711929990
}
],
"has_more": true,
"next_cursor": "trade_x9y8z7w6"
}
```
#### `GET /markets/{mint}/ohlcv`
Candlestick / OHLCV data.
**Query Parameters:**
| Parameter | Type | Default | Description |
| ---------- | --------- | ------- | ----------------------------------------- |
| `interval` | `string` | `1h` | `1m`, `5m`, `15m`, `1h`, `4h`, `1d`, `1w` |
| `from` | `integer` | — | Start time (Unix seconds) |
| `to` | `integer` | — | End time (Unix seconds) |
| `limit` | `integer` | 100 | Max candles (max 1000) |
**Response:**
```json
{
"mint": "7xK9p2...",
"interval": "1h",
"candles": [
{
"timestamp": 1711929600,
"open": 0.0001140,
"high": 0.0001165,
"low": 0.0001098,
"close": 0.0001153,
"volume_tokens": 500000000000,
"volume_sol": 57.65,
"trade_count": 142
}
],
"count": 1
}
```
#### `GET /oracle/{mint}/custody`
Current Empire Stock Transfer custody attestation.
**Response:**
```json
{
"mint": "7xK9p2...",
"custodied_balance": 1000000000,
"token_supply": 1000000000,
"ratio": 1.0,
"attestation_slot": 285000200,
"attestation_timestamp": 1711930080,
"ed25519_verified": true,
"empire_pubkey": "EmpK3y...",
"discrepancy_detected": false,
"slot_age": 0,
"latency_ms": 145
}
```
#### `GET /oracle/{mint}/nav` *(Module 2 only)*
Most recent appraised NAV for a Module 2 ST22 mint. See §12.2.
#### `GET /oracle/{mint}/classification` *(Module 3 only)*
Most recent USGS / DOE classification status and federal-action status for a Module 3 ST22 mint. See §12.3.
#### `GET /oracle/ofac/status`
OFAC oracle health.
**Response:**
```json
{
"last_refresh": 1711929600,
"next_refresh": 1711933200,
"entry_count": 12847,
"list_hash": "a1b2c3d4e5f6...",
"is_fresh": true,
"staleness_threshold_secs": 86400,
"halt_threshold_secs": 172800,
"status": "healthy"
}
```
#### `GET /oracle/aml/{wallet}`
AML risk score for a wallet (cached, public subset).
**Response:**
```json
{
"wallet": "9aB2xY...",
"risk_score": 12,
"disposition": "approve",
"provider": "chainalysis+trm",
"scored_at": 1711926000,
"cache_expires": 1711947600,
"is_fresh": true
}
```
Scores 31–70 return `"disposition": "review"` with limited detail. Scores 71–100 return `"disposition": "reject"`.
#### `GET /health`
System health check.
**Response:**
```json
{
"status": "operational",
"version": "1.0.0",
"solana_slot": 285000250,
"solana_tps": 2847,
"rpc_latency_ms": 45,
"oracle_status": {
"custody": "healthy",
"ofac": "healthy",
"aml": "healthy",
"twap": "healthy",
"edgar": "healthy",
"nav": "healthy",
"classification": "healthy"
},
"circuit_breaker_global": false,
"mev_protection": "active",
"timestamp": 1711930100
}
```
The `nav` and `classification` fields under `oracle_status` reflect the aggregate health of those oracle networks across all Module 2 and Module 3 mints respectively. Per-mint oracle health is reported by the per-mint endpoints.
***
### 5. Authenticated Endpoints
All endpoints below require `Authorization: Bearer ` from a wallet that has completed Empire Stock Transfer verification.
#### `POST /orders`
Place a market or limit order. Every order goes through pre-flight compliance verification (2–3 seconds) before on-chain submission.
**Request (market):**
```json
{
"mint": "7xK9p2...",
"side": "buy",
"type": "market",
"amount": 50000000000,
"slippage_bps": 100,
"idempotency_key": "order_20260401_001"
}
```
**Request (limit):**
```json
{
"mint": "7xK9p2...",
"side": "sell",
"type": "limit",
"amount": 100000000000,
"limit_price": 0.0001200,
"expiry": 1712016000,
"idempotency_key": "order_20260401_002"
}
```
**Request Fields:**
| Field | Type | Required | Description |
| ----------------- | --------- | ----------- | --------------------------------------------- |
| `mint` | `string` | Yes | ST22 mint address |
| `side` | `string` | Yes | `"buy"` or `"sell"` |
| `type` | `string` | Yes | `"market"` or `"limit"` |
| `amount` | `integer` | Yes | Token amount (raw, with decimals) |
| `limit_price` | `number` | Limit only | SOL per token |
| `slippage_bps` | `integer` | Market only | Max slippage (default 100 = 1%, max 500 = 5%) |
| `expiry` | `integer` | Limit only | Unix timestamp (default: 24h from now) |
| `idempotency_key` | `string` | Recommended | Prevents duplicate orders (see §10) |
**Response (market — filled):**
```json
{
"order_id": "ord_x1y2z3",
"status": "filled",
"side": "buy",
"type": "market",
"amount_requested": 50000000000,
"amount_filled": 50000000000,
"effective_price": 0.0001155,
"value_sol": 5.775,
"fee": {
"total_sol": 0.28875,
"total_bps": 500,
"pool_sol": 0.025410,
"issuer_sol": 0.11550,
"staking_sol": 0.086625,
"protocol_sol": 0.061215
},
"price_impact_bps": 18,
"compliance_check": "passed",
"controls_executed": 42,
"tx_signature": "5vGh7kJ...",
"block_slot": 285000300,
"settled_at": 1711930200,
"created_at": 1711930197
}
```
**Response (limit — open):**
```json
{
"order_id": "ord_a4b5c6",
"status": "open",
"side": "sell",
"type": "limit",
"amount_requested": 100000000000,
"amount_filled": 0,
"limit_price": 0.0001200,
"expiry": 1712016000,
"compliance_check": "passed",
"created_at": 1711930210
}
```
**Compliance flow:**
```
1. CEDEX receives order
2. Pre-flight compliance (2-3s):
├─ Custody verification (Empire Ed25519, CV-01 through CV-06)
├─ OFAC screening (SC-30 through SC-34)
├─ AML risk scoring (IV-09)
├─ KYC / eligibility check (IV-07, IV-08)
├─ Holding period verification (HP-24)
├─ Price impact pre-check (CB-21)
├─ Module 2: NAV-deviation pre-check (CB-21 extension)
└─ Module 3: Classification freshness + federal-action freeze pre-check (CV-04, REG-42)
3. If ANY pre-flight fails → return error immediately (no on-chain tx)
4. If pre-flight passes → submit to Solana
5. Token-2022 Transfer Hook executes all 42 controls on chain
6. If on-chain hook passes → settlement + fee distribution
7. If on-chain hook fails → atomic revert (no fee charged)
```
#### `GET /orders`
List orders for the authenticated wallet.
**Query Parameters:**
| Parameter | Type | Default | Description |
| --------- | --------- | ------- | ---------------------------------------------------- |
| `status` | `string` | — | `open`, `filled`, `cancelled`, `expired`, `rejected` |
| `mint` | `string` | — | Filter by ST22 mint |
| `side` | `string` | — | `buy` or `sell` |
| `limit` | `integer` | 50 | Max results (max 200) |
| `before` | `string` | — | Cursor: order ID |
**Response:**
```json
{
"orders": [
{
"order_id": "ord_a4b5c6",
"mint": "7xK9p2...",
"symbol": "ACME-ST22",
"side": "sell",
"type": "limit",
"status": "open",
"amount_requested": 100000000000,
"amount_filled": 0,
"limit_price": 0.0001200,
"expiry": 1712016000,
"created_at": 1711930210
}
],
"has_more": false
}
```
#### `DELETE /orders/{order_id}`
Cancel an open order.
**Response:**
```json
{
"order_id": "ord_a4b5c6",
"status": "cancelled",
"cancelled_at": 1711930500
}
```
Returns `404` if the order is not found or not owned by the authenticated wallet. Returns `409` if the order is already filled or expired.
#### `GET /portfolio`
Current ST22 holdings with holding-period status.
**Response:**
```json
{
"wallet": "9aB2xY...",
"positions": [
{
"mint": "7xK9p2...",
"symbol": "ACME-ST22",
"module": "equities",
"balance": 50000000000,
"value_sol": 5.765,
"value_usd": 922.40,
"percent_of_supply": 0.50,
"within_wallet_limit": true,
"holding_period": {
"purchase_timestamp": 1711929600,
"jurisdiction": "US",
"regime": "RegD",
"holding_period_secs": 15778800,
"unlock_timestamp": 1727708400,
"is_locked": true,
"seconds_remaining": 15778200,
"unlock_date": "2026-09-30T00:00:00Z"
},
"custody": {
"ratio": 1.0,
"ed25519_verified": true,
"last_attestation_ms": 1711930400
}
}
],
"total_positions": 1,
"total_value_sol": 5.765,
"locked_positions": 1,
"tradeable_positions": 0
}
```
The `holding_period.regime` field reports the offering exemption applied to the position: `"RegD"` (6 months), `"RegS"` (12 months), or `"RegCF"` (12 months). The `holding_period_secs` value reflects the regime.
#### `POST /estimate`
Estimate swap output without executing. No on-chain transaction; no fee charged.
**Request:**
```json
{
"mint": "7xK9p2...",
"side": "buy",
"input_amount": 10000000000
}
```
**Response:**
```json
{
"mint": "7xK9p2...",
"side": "buy",
"input_amount": 10000000000,
"output_amount": 86758000000,
"effective_price": 0.00011527,
"price_impact_bps": 95,
"would_trigger_circuit_breaker": false,
"would_succeed": true,
"fee": {
"total_lamports": 500000000,
"total_bps": 500,
"pool_lamports": 44000000,
"issuer_lamports": 200000000,
"staking_lamports": 150000000,
"protocol_lamports": 106000000
},
"pool_state": {
"sol_reserve": 100000000000000,
"token_reserve": 1000000000000000000,
"k": "100000000000000000000000000000000"
},
"timestamp": 1711930300
}
```
If the pre-flight check would fail, `would_succeed` is `false` and a `failure_reason` field is returned with one of: `"HOLDING_PERIOD_LOCKED"`, `"WALLET_LIMIT_EXCEEDED"`, `"PRICE_IMPACT_EXCEEDED"`, `"OFAC_MATCH"`, `"AML_HIGH_RISK"`, `"CUSTODY_DISCREPANCY"`, `"NAV_DEVIATION_EXCEEDED"` (Module 2), `"CLASSIFICATION_STALE"` (Module 3), `"FEDERAL_ACTION_FROZEN"` (Module 3).
***
### 6. WebSocket API
Real-time data streams via persistent WebSocket connection.
#### Connection
```
wss://api.cedex.market/ws/v1
```
Authenticated connection (required for private channels):
```
wss://api.cedex.market/ws/v1?token=eyJhbGciOiJFZDI1NTE5...
```
#### Subscribe
```json
{
"action": "subscribe",
"channel": "orderbook",
"mint": "7xK9p2..."
}
```
#### Unsubscribe
```json
{
"action": "unsubscribe",
"channel": "orderbook",
"mint": "7xK9p2..."
}
```
#### Heartbeat
Server sends ping every 30 seconds. Client must respond with pong within 10 seconds or the connection is terminated.
```json
{ "type": "ping", "timestamp": 1711930400 }
```
```json
{ "type": "pong" }
```
#### Channel: `orderbook`
Real-time order book updates. Snapshot on subscribe, then incremental deltas.
**Subscription:**
```json
{ "action": "subscribe", "channel": "orderbook", "mint": "7xK9p2..." }
```
**Snapshot (sent on subscribe):**
```json
{
"type": "snapshot",
"channel": "orderbook",
"mint": "7xK9p2...",
"bids": [
{ "price": 0.0001150, "amount": 50000000000 },
{ "price": 0.0001145, "amount": 30000000000 }
],
"asks": [
{ "price": 0.0001155, "amount": 40000000000 },
{ "price": 0.0001160, "amount": 25000000000 }
],
"sequence": 100001,
"timestamp": 1711930400
}
```
**Delta (incremental updates):**
```json
{
"type": "delta",
"channel": "orderbook",
"mint": "7xK9p2...",
"changes": [
{ "side": "bid", "price": 0.0001150, "amount": 45000000000 },
{ "side": "ask", "price": 0.0001155, "amount": 0 }
],
"sequence": 100002,
"timestamp": 1711930400
}
```
`amount: 0` = level removed. Apply deltas sequentially by `sequence`. If a sequence gap is detected, re-subscribe for a fresh snapshot.
#### Channel: `trades`
Real-time trade feed.
**Subscription:**
```json
{ "action": "subscribe", "channel": "trades", "mint": "7xK9p2..." }
```
**Message:**
```json
{
"type": "trade",
"channel": "trades",
"mint": "7xK9p2...",
"id": "trade_a1b2c3d4",
"side": "buy",
"amount": 10000000000,
"price": 0.0001153,
"value_sol": 1.153,
"price_impact_bps": 12,
"tx_signature": "5vGh7kJ...",
"timestamp": 1711930410
}
```
#### Channel: `custody`
Real-time Empire custody attestation updates (\~400ms per Solana block).
**Subscription:**
```json
{ "action": "subscribe", "channel": "custody", "mint": "7xK9p2..." }
```
**Message:**
```json
{
"type": "custody_update",
"channel": "custody",
"mint": "7xK9p2...",
"custodied_balance": 1000000000,
"token_supply": 1000000000,
"ratio": 1.0,
"attestation_slot": 285000400,
"ed25519_verified": true,
"discrepancy_detected": false,
"timestamp": 1711930410
}
```
If `discrepancy_detected: true`, all transfers are halted on this mint by Transfer Hook controls CV-01 through CV-06 until 2-of-3 oracle consensus resolves the discrepancy.
#### Channel: `circuit_breaker`
Circuit-breaker activation and deactivation events.
**Subscription:**
```json
{ "action": "subscribe", "channel": "circuit_breaker", "mint": "7xK9p2..." }
```
**Message:**
```json
{
"type": "circuit_breaker",
"channel": "circuit_breaker",
"mint": "7xK9p2...",
"event": "triggered",
"breaker_type": "price_halt",
"trigger_value": 1250,
"threshold": 1000,
"cooldown_secs": 900,
"resume_at": 1711931310,
"timestamp": 1711930410
}
```
**Breaker types:**
| Type | Trigger | Module Scope |
| ---------------------- | --------------------------------------------------------------- | ------------ |
| `price_halt` | Price move > threshold in 5 min | All modules |
| `price_impact` | Single trade price impact > 2% (or per-mint config) | All modules |
| `volume_halt` | Wallet daily-sell limit > 30% | All modules |
| `oracle_failure` | Custody or OFAC oracle stale beyond threshold | All modules |
| `nav_deviation` | On-chain price deviates from NAV beyond `nav_deviation_max_bps` | Module 2 |
| `nav_stale` | NAV oracle exceeds `nav_reappraisal_max_age_secs` | Module 2 |
| `classification_stale` | Classification oracle exceeds `classification_max_age_secs` | Module 3 |
| `federal_action` | Federal-action freeze active (Control 42) | Module 3 |
#### Channel: `nav` *(Module 2 only)*
Real-time NAV oracle updates for Module 2 mints. See §12.2.
#### Channel: `classification` *(Module 3 only)*
Real-time Classification oracle updates and federal-action events for Module 3 mints. See §12.3.
#### Channel: `orders` (Authenticated)
Private channel — requires authenticated WebSocket connection. Real-time updates for the authenticated wallet's orders.
**Subscription:**
```json
{ "action": "subscribe", "channel": "orders" }
```
**Message:**
```json
{
"type": "order_update",
"channel": "orders",
"order_id": "ord_x1y2z3",
"status": "filled",
"amount_filled": 50000000000,
"effective_price": 0.0001155,
"tx_signature": "5vGh7kJ...",
"timestamp": 1711930420
}
```
***
### 7. Compliance Pre-Flight
Every order runs through pre-flight compliance verification before on-chain submission. This saves the user gas fees on trades that would fail the Transfer Hook.
#### Pre-Flight Sequence
| Step | Hook | Source | Latency | Module Scope |
| ---- | ----------------------------------------------- | ----------------------------- | --------- | ------------- |
| 1 | Custody Verification (CV-01 to CV-06) | Empire Ed25519 oracle | 100–150ms | All modules |
| 2 | OFAC Screening (SC-30 to SC-34) | OFAC SDN oracle | 200–500ms | All modules |
| 3 | AML Risk (IV-09) | Chainalysis + TRM Labs | 300–400ms | All modules |
| 4 | KYC and eligibility (IV-07, IV-08) | Empire registry | 50–100ms | All modules |
| 5 | Holding Period (HP-24) | On-chain HoldingPeriodAccount | <10ms | All modules |
| 6 | Price Impact (CB-21) | TWAP oracle (Pyth Network) | 50–100ms | All modules |
| 7 | NAV Deviation (CB-21 extension) | NAVOracle PDA | 50–100ms | Module 2 only |
| 8 | Classification + Federal Action (CV-04, REG-42) | ClassificationOracle PDA | 50–100ms | Module 3 only |
**Total pre-flight:** 2,000–3,000ms
If pre-flight fails, the API returns the specific error code immediately — no on-chain transaction submitted, no gas fee charged. The user can see exactly which control would reject the trade and why.
#### Pre-Flight Response (Failure)
```json
{
"order_id": null,
"status": "rejected",
"compliance_check": "failed",
"failed_control": {
"control_id": "HP-24",
"code": 6024,
"name": "TokensLocked",
"message": "Tokens locked — Reg D / Reg S / Reg CF holding period not elapsed",
"details": {
"mint": "7xK9p2...",
"beneficiary": "9aB2xY...",
"purchase_timestamp": 1711929600,
"unlock_timestamp": 1727708400,
"seconds_remaining": 15778200,
"jurisdiction": "US",
"regime": "RegD"
}
}
}
```
#### Module 2 Pre-Flight Failure (NAV Deviation)
```json
{
"order_id": null,
"status": "rejected",
"compliance_check": "failed",
"failed_control": {
"control_id": "CB-21",
"code": 6021,
"name": "NavDeviationExceeded",
"message": "Price deviates from NAV beyond configured tolerance",
"details": {
"mint": "7xK9p2...",
"current_price_usd": 1250.00,
"appraised_nav_usd": 1000.00,
"deviation_bps": 2500,
"max_allowed_bps": 2200,
"last_appraisal_timestamp": 1709251200,
"next_appraisal_target": 1740787200
}
}
}
```
#### Module 3 Pre-Flight Failure (Federal Action)
```json
{
"order_id": null,
"status": "rejected",
"compliance_check": "failed",
"failed_control": {
"control_id": "REG-42",
"code": 6042,
"name": "FederalActionFrozen",
"message": "Mint frozen by federal-action regulatory override",
"details": {
"mint": "7xK9p2...",
"freeze_timestamp": 1711930000,
"freeze_authority": "LegalCounsel+3of5",
"trigger_source": "Federal Register",
"action_reference": "EO-14118",
"expected_resolution": "pending"
}
}
}
```
***
### 8. Error Reference
#### HTTP Status Codes
| Status | Meaning | When |
| ------ | ------------- | -------------------------------------------------------- |
| `200` | Success | Request completed |
| `201` | Created | Order placed |
| `400` | Bad Request | Invalid parameters |
| `401` | Unauthorized | Missing or expired token |
| `403` | Forbidden | Empire verification required or wallet blacklisted |
| `404` | Not Found | Resource does not exist |
| `409` | Conflict | Order already filled or cancelled; idempotency-key reuse |
| `422` | Unprocessable | Compliance pre-flight failed (Transfer Hook error) |
| `429` | Rate Limited | Exceeded rate limit |
| `500` | Server Error | Internal error |
| `503` | Unavailable | Maintenance or Solana network issue |
#### Error Response Format
```json
{
"error": {
"code": 6024,
"name": "TokensLocked",
"message": "Tokens locked — Reg D / Reg S / Reg CF holding period not elapsed",
"category": "HoldingPeriod",
"control_id": "HP-24",
"recoverable": true,
"details": {
"mint": "7xK9p2...",
"beneficiary": "9aB2xY...",
"purchase_timestamp": 1711929600,
"unlock_timestamp": 1727708400,
"seconds_remaining": 15778200,
"jurisdiction": "US",
"regime": "RegD"
}
},
"request_id": "req_m7n8o9"
}
```
#### Transfer Hook Error Codes (6001–6042)
| Code | Name | HTTP | Recoverable | User Action |
| --------- | -------------------------- | ---- | ----------- | ---------------------------------------------------------------------------------- |
| 6001 | `CustodyDiscrepancy` | 422 | No | System-level. Wait for oracle consensus. |
| 6002 | `CustodyOracleUnavailable` | 422 | Yes | Retry after \~400ms (1 block) |
| 6003 | `SenderSanctioned` | 403 | No | OFAC-flagged wallet. Cannot trade. |
| 6004 | `ReceiverSanctioned` | 403 | No | Receiver OFAC-flagged. |
| 6005 | `OfacOracleStale` | 422 | Yes | OFAC refreshing. Retry in minutes. |
| 6006 | `AMLHighRisk` | 403 | No | AML score above 70. Contact Empire. |
| 6007 | `InvalidSigner` | 403 | No | KYC, eligibility, or wallet registration missing. |
| 6008–6019 | CEI / Integrity | 422 | Varies | See error message. |
| 6020 | `WalletLimitExceeded` | 422 | Yes | Reduce amount below 4.99% of supply. |
| 6021 | `PriceImpactExceeded` | 422 | Yes | Reduce order size or split into smaller orders. |
| 6022 | `VelocityExceeded` | 422 | Yes | Slow down. Wait for velocity window. |
| 6023 | `CrossWalletDetected` | 403 | No | Behavioral clustering flagged. Contact compliance. |
| 6024 | `TokensLocked` | 422 | Yes | Wait for holding period (Reg D 6mo / Reg S 12mo / Reg CF 12mo). |
| 6036 | `GlobalCircuitBreaker` | 503 | Yes | All trading halted. Wait for cooldown (\~15 min). |
| 6037 | `DailySellLimitExceeded` | 422 | Yes | 30% daily sell limit reached. Wait 24h. |
| 6038 | `CustodyDiscrepancyHalt` | 503 | No | Custody issue. Await 2-of-3 consensus. |
| 6039 | `OFACEmergencyBlock` | 503 | No | Treasury emergency SDN update. |
| 6040 | `OracleConsensusFail` | 503 | Yes | Oracle consensus not reached. Retry. |
| 6041 | `ControlledMigration` | 503 | Yes | Upgrade in progress. Wait. |
| 6042 | `RegulatoryOverride` | 503 | No | Legal Counsel + 3-of-5 freeze. Module 3 federal-action freezes also use this code. |
#### Module 2 Specific Error Annotations
| Code | Variant | Detail Field | User Action |
| ---- | ---------------------- | ---------------------------------------------------------- | ---------------------------------------------------------- |
| 6021 | `NavDeviationExceeded` | `deviation_bps`, `max_allowed_bps`, `appraised_nav_usd` | Wait for fresh appraisal that restores price within bounds |
| 6021 | `NavStale` | `last_appraisal_timestamp`, `nav_reappraisal_max_age_secs` | Mint paused pending fresh appraisal |
#### Module 3 Specific Error Annotations
| Code | Variant | Detail Field | User Action |
| ---- | --------------------------------- | -------------------------------------------------------- | ------------------------------------------------ |
| 6002 | `ClassificationOracleUnavailable` | `last_refresh`, `classification_max_age_secs` | Retry after relay refresh |
| 6042 | `FederalActionFrozen` | `freeze_timestamp`, `trigger_source`, `action_reference` | No user action — await federal-action resolution |
#### CEDEX Application Error Codes
| Code | Name | HTTP | Description |
| ------------------------------ | -------------------- | ---- | ----------------------------------------------- |
| `INVALID_MINT` | Invalid Mint | 400 | Mint address not a valid ST22 token |
| `INVALID_SIDE` | Invalid Side | 400 | Must be `"buy"` or `"sell"` |
| `INVALID_AMOUNT` | Invalid Amount | 400 | Amount must be > 0 |
| `SLIPPAGE_EXCEEDED` | Slippage Exceeded | 422 | Output below minimum after slippage |
| `DEADLINE_EXCEEDED` | Deadline Exceeded | 422 | Order deadline passed before execution |
| `INSUFFICIENT_BALANCE` | Insufficient Balance | 422 | Wallet balance < order amount |
| `ORDER_NOT_FOUND` | Order Not Found | 404 | Order ID does not exist for this wallet |
| `ORDER_NOT_CANCELLABLE` | Not Cancellable | 409 | Order already filled or expired |
| `EMPIRE_VERIFICATION_REQUIRED` | Not Verified | 403 | Empire KYC, KYB, AML, OFAC, or KYW not complete |
| `RATE_LIMITED` | Rate Limited | 429 | Request rate exceeded |
| `MAINTENANCE` | Maintenance | 503 | System maintenance window |
| `POOL_NOT_ACTIVE` | Pool Inactive | 503 | Trading pair not active |
| `IDEMPOTENCY_CONFLICT` | Duplicate | 409 | Same idempotency key with different params |
***
### 9. Pagination
All list endpoints use cursor-based pagination.
```
GET /markets/{mint}/trades?limit=50
GET /markets/{mint}/trades?limit=50&before=trade_x9y8z7w6
```
**Response pagination fields:**
```json
{
"data": [...],
"has_more": true,
"next_cursor": "trade_x9y8z7w6"
}
```
Pass `next_cursor` as the `before` parameter to fetch the next page. When `has_more` is `false`, no more results exist.
***
### 10. Idempotency
Prevent duplicate orders by including an `idempotency_key` in order placement requests.
```json
{
"...order fields...",
"idempotency_key": "order_20260401_001"
}
```
**Behavior:**
| Scenario | Response |
| -------------------------------------------------- | ------------------------------------- |
| First request with key | Order created normally |
| Duplicate request with same key + same params | Returns original order (no duplicate) |
| Duplicate request with same key + different params | `409 IDEMPOTENCY_CONFLICT` |
| Key reuse after 24 hours | Key expired — treated as new request |
**Key format:** Any string up to 128 characters. Recommended: `{purpose}_{date}_{sequence}`.
***
### 11. Code Examples
#### TypeScript (SDK)
```typescript
import { RwaTokensClient } from '@rwatokens/sdk';
const client = new RwaTokensClient({ network: 'mainnet-beta', wallet });
// Market buy
const order = await client.cedex.placeOrder({
mint: mintAddress,
side: 'buy',
type: 'market',
amount: 50_000_000_000n,
slippageBps: 100,
});
console.log(`Filled: ${order.txSignature}`);
```
#### Python
```python
import requests
BASE = "https://api.cedex.market/v1"
TOKEN = "eyJhbGciOiJFZDI1NTE5..."
# Get markets
markets = requests.get(f"{BASE}/markets").json()
# Place order
order = requests.post(
f"{BASE}/orders",
headers={"Authorization": f"Bearer {TOKEN}"},
json={
"mint": "7xK9p2...",
"side": "buy",
"type": "market",
"amount": 50000000000,
"slippage_bps": 100,
"idempotency_key": "py_order_001",
},
).json()
print(f"Status: {order['status']}, TX: {order.get('tx_signature')}")
```
#### cURL
```bash
# Public: Get order book
curl -s https://api.cedex.market/v1/markets/7xK9p2.../orderbook?depth=10 | jq
# Authenticated: Place order
curl -X POST https://api.cedex.market/v1/orders \
-H "Authorization: Bearer eyJhbGciOiJFZDI1NTE5..." \
-H "Content-Type: application/json" \
-d '{
"mint": "7xK9p2...",
"side": "buy",
"type": "market",
"amount": 50000000000,
"slippage_bps": 100
}' | jq
# Cancel order
curl -X DELETE https://api.cedex.market/v1/orders/ord_x1y2z3 \
-H "Authorization: Bearer eyJhbGciOiJFZDI1NTE5..." | jq
```
#### WebSocket (JavaScript)
```javascript
const ws = new WebSocket('wss://api.cedex.market/ws/v1');
ws.onopen = () => {
// Subscribe to order book
ws.send(JSON.stringify({
action: 'subscribe',
channel: 'orderbook',
mint: '7xK9p2...',
}));
// Subscribe to trades
ws.send(JSON.stringify({
action: 'subscribe',
channel: 'trades',
mint: '7xK9p2...',
}));
};
ws.onmessage = (event) => {
const msg = JSON.parse(event.data);
if (msg.type === 'ping') {
ws.send(JSON.stringify({ type: 'pong' }));
return;
}
switch (msg.channel) {
case 'orderbook':
if (msg.type === 'snapshot') console.log('Book snapshot:', msg.bids.length, 'bids');
if (msg.type === 'delta') console.log('Book delta:', msg.changes);
break;
case 'trades':
console.log(`Trade: ${msg.side} ${msg.amount} @ ${msg.price}`);
break;
case 'custody':
if (msg.discrepancy_detected) console.error('CUSTODY DISCREPANCY');
break;
case 'nav':
console.log(`NAV update: ${msg.appraised_nav_usd} (deviation ${msg.current_deviation_bps} bps)`);
break;
case 'classification':
if (msg.federal_action_active) console.error(`FEDERAL ACTION: ${msg.action_reference}`);
break;
}
};
```
***
### 12. Module-Aware API Surface
The CEDEX API serves all three modules through the same endpoints, the same authentication, and the same WebSocket protocol. Module-specific behavior surfaces as additional fields on existing endpoints, dedicated oracle endpoints, dedicated WebSocket channels, and module-specific failure-reason codes. This section consolidates the module-specific surface for integrators building module-aware applications.
#### 12.1 Module 1 — Equities
**Module identifier in API responses:** `"equities"`.
**Distinguishing endpoints.** None beyond the standard set. Module 1 mints use the standard custody, OFAC, AML, and TWAP oracles.
**Distinguishing WebSocket channels.** None.
**Distinguishing fields.** `issuer_cik` (for SEC-reporting issuers). The EDGAR pipeline that supplies issuer-disclosure intelligence to Layer 9 IDOS off-chain compliance is not exposed through the public API; Module 1 IDOS-driven status changes appear through the `circuit_breaker` channel as `oracle_failure` events when issuer eligibility lapses.
#### 12.2 Module 2 — Real Estate
**Module identifier in API responses:** `"real_estate"`.
**Additional Public Endpoint: `GET /oracle/{mint}/nav`**
Returns the most recent appraised NAV for a Module 2 mint:
```json
{
"mint": "5xR3p9...",
"appraised_nav_usd": 1000.00,
"appraiser_signature": "Ed25519AppraiserSig...",
"appraiser_id": "appraiser_xyz_456",
"last_appraisal_timestamp": 1709251200,
"next_appraisal_target": 1740787200,
"nav_deviation_max_bps": 2200,
"current_price_usd": 1018.50,
"current_deviation_bps": 185,
"is_within_bounds": true,
"is_fresh": true,
"staleness_threshold_secs": 31536000,
"status": "healthy"
}
```
**Additional Market Object Field (Module 2 mints):**
```json
{
"...standard market fields...",
"nav": {
"appraised_nav_usd": 1000.00,
"current_deviation_bps": 185,
"is_within_bounds": true,
"next_appraisal_target": 1740787200
}
}
```
**Additional Health Field:**
The `oracle_status.nav` field on `GET /health` reports aggregate NAV oracle health: `"healthy"`, `"degraded"` (any per-mint NAV staleness above warning threshold), or `"halted"` (any per-mint NAV exceeds halt threshold).
**Additional WebSocket Channel: `nav`**
Real-time NAV oracle updates for a specific Module 2 mint.
```json
{ "action": "subscribe", "channel": "nav", "mint": "5xR3p9..." }
```
```json
{
"type": "nav_update",
"channel": "nav",
"mint": "5xR3p9...",
"appraised_nav_usd": 1000.00,
"current_price_usd": 1018.50,
"current_deviation_bps": 185,
"is_within_bounds": true,
"appraisal_timestamp": 1709251200,
"appraiser_id": "appraiser_xyz_456",
"timestamp": 1711930410
}
```
**Module 2 Pre-Flight Failure Reasons:**
| Reason | Underlying Control | Recoverable |
| ------------------------ | ------------------ | ----------------------------------------- |
| `NAV_DEVIATION_EXCEEDED` | CB-21 (extension) | Yes — wait for fresh appraisal |
| `NAV_STALE` | CB-21 (extension) | Yes — fresh appraisal will resume trading |
**Application Pattern.** Applications displaying real-time price for Module 2 mints should subscribe to the `nav` channel for the same mint and display the NAV reference alongside the live AMM price. The deviation warning surfaces UX context for users when the NAV-deviation breaker triggers.
#### 12.3 Module 3 — CORECM (Carbon Ore, Rare Earth, and Critical Minerals)
**Module identifier in API responses:** `"corecm"`.
**Additional Public Endpoint: `GET /oracle/{mint}/classification`**
Returns the most recent USGS / DOE classification status and federal-action status for a Module 3 mint:
```json
{
"mint": "8mB4q1...",
"usgs_critical_minerals_status": "critical_mineral_rare_earth",
"doe_critical_materials_status": "high_priority",
"section_232_applicable": false,
"dpa_title_iii_applicable": true,
"federal_action_active": false,
"active_action_references": [],
"last_refresh_timestamp": 1711930000,
"classification_max_age_secs": 86400,
"is_fresh": true,
"status": "healthy",
"monitored_sources": [
"Federal Register",
"DOE Critical Materials Strategy",
"USGS Critical Minerals List",
"DOD Procurement Directives"
]
}
```
**Additional Market Object Field (Module 3 mints):**
```json
{
"...standard market fields...",
"classification": {
"usgs_critical_minerals_status": "critical_mineral_rare_earth",
"doe_critical_materials_status": "high_priority",
"federal_action_active": false,
"is_fresh": true
}
}
```
**Additional Health Field:**
The `oracle_status.classification` field on `GET /health` reports aggregate Classification oracle health.
**Additional WebSocket Channel: `classification`**
Real-time Classification oracle updates and federal-action events for a specific Module 3 mint.
```json
{ "action": "subscribe", "channel": "classification", "mint": "8mB4q1..." }
```
**Routine update message:**
```json
{
"type": "classification_update",
"channel": "classification",
"mint": "8mB4q1...",
"usgs_critical_minerals_status": "critical_mineral_rare_earth",
"doe_critical_materials_status": "high_priority",
"federal_action_active": false,
"last_refresh_timestamp": 1711930000,
"is_fresh": true,
"timestamp": 1711930410
}
```
**Federal-action event message (P0 incident):**
```json
{
"type": "federal_action_detected",
"channel": "classification",
"mint": "8mB4q1...",
"action_reference": "EO-14118",
"trigger_source": "Federal Register",
"detected_timestamp": 1711930000,
"freeze_pending": true,
"expected_freeze_timestamp": 1711933600,
"timestamp": 1711930000
}
```
**Federal-action freeze applied:**
```json
{
"type": "federal_action_freeze_applied",
"channel": "classification",
"mint": "8mB4q1...",
"action_reference": "EO-14118",
"freeze_authority": "LegalCounsel+3of5",
"freeze_timestamp": 1711933600,
"trading_halted": true,
"timestamp": 1711933600
}
```
**Module 3 Pre-Flight Failure Reasons:**
| Reason | Underlying Control | Recoverable |
| ----------------------- | ------------------ | ------------------------------------ |
| `CLASSIFICATION_STALE` | CV-04 (extension) | Yes — wait for relay refresh |
| `FEDERAL_ACTION_FROZEN` | REG-42 | No — await federal-action resolution |
**Application Pattern.** Applications handling Module 3 mints should subscribe to the `classification` channel for every mint they display. The `federal_action_detected` event provides up-to-an-hour advance notice of a likely Control 42 freeze (the platform's incident response runbook §13 specifies a 60-minute SLA from detection to freeze execution); applications can warn users that orders submitted during this window may revert.
#### 12.4 Cross-Module Properties
The following properties are identical across all three modules:
* Authentication, rate limits, idempotency, pagination.
* Order placement and cancellation endpoints.
* The `markets`, `trades`, `orderbook`, `OHLCV`, `custody`, `circuit_breaker`, and `orders` (private) WebSocket channels.
* The 5% fee distribution structure (2% / 1.5% / 1.06% / 0.44%).
* Stablecoin settlement (USDC, PYUSD).
* Pre-flight steps 1–6 (custody, OFAC, AML, KYC, holding period, price impact).
* Holding-period regimes — Reg D (6 months), Reg S (12 months), Reg CF (12 months).
* Transfer Hook error codes 6001–6042.
***
### 13. Changelog
#### v1.0.0 (Q3 2026)
* Initial release — CEDEX mainnet launch.
* Public endpoints: markets, orderbook, trades, OHLCV, oracle status, health.
* Authenticated endpoints: orders (market and limit), portfolio, estimate.
* WebSocket channels: orderbook, trades, custody, circuit\_breaker, orders (private).
* Wallet signature authentication with Empire verification gate.
* Pre-flight compliance verification (42 controls).
* Idempotency support for order placement.
* Three rate-limit tiers (standard, verified, institutional).
* Module-aware endpoint surface: NAV oracle and `nav` WebSocket channel for Module 2; Classification oracle and `classification` WebSocket channel for Module 3.
* Module-specific failure reasons surfaced in pre-flight responses.
***
### Related Documentation
* **SDK Reference** — `RwaTokensClient` wrapping this API.
* **Smart Contract Reference** — On-chain program documentation.
* **Transfer Hook Reference** — Standalone reference for the 42 controls.
* **Stablecoin Settlement Guide** — USDC and PYUSD settlement architecture and developer integration.
* **Oracle Integration Guide** — Custody, OFAC, AML, TWAP, EDGAR, NAV (Module 2), Classification (Module 3) relay architecture.
* **Compliance Integration Guide** — Regulatory mapping for each pre-flight control.
* **Issuer Onboarding Guide** — Module-specific issuer onboarding flow.
* **Incident Response Playbook** — Module 3 federal-action freeze runbook (§13).
***
*RWA Tokens · CEDEX API Reference · v1.0 · cedex.market · Q3 2026*
# CEDEX API Changelog
## CEDEX API Changelog
**Version History · Breaking Changes · Deprecations · Migration Guides · Module-Aware**
Versioned record of all changes to the CEDEX REST API and WebSocket API. The CEDEX API serves all three production modules: Equities (Module 1), Real Estate (Module 2), and CORECM — Carbon Ore, Rare Earth, and Critical Minerals (Module 3). Module-aware endpoints, WebSocket channels, and pre-flight failure reasons are tracked in the version history alongside cross-module changes.
This changelog is maintained separately from the protocol-level Changelog (which tracks smart-contract and platform changes). Integrators should subscribe to the CEDEX API status page (status.cedex.market) and monitor this page for upcoming changes.
***
### Table of Contents
1. Versioning Policy
2. Current Version
3. Changelog
4. Deprecation Policy
5. Migration Guides
6. Upcoming Changes
7. SDK Compatibility Matrix
***
### 1. Versioning Policy
#### Semantic Versioning
The CEDEX API follows semantic versioning (`MAJOR.MINOR.PATCH`):
| Component | Incremented When | Integrator Action |
| ----------------------- | -------------------------------------------------------------- | ----------------------------------------------------------- |
| MAJOR (v1 → v2) | Breaking changes that require code modifications | Must update integration before deprecation deadline |
| MINOR (v1.0 → v1.1) | New endpoints, new fields, new features — backward compatible | No action required — existing integrations continue working |
| PATCH (v1.0.0 → v1.0.1) | Bug fixes, documentation corrections, performance improvements | No action required |
#### Module-Aware Versioning
Module-specific endpoints, fields, and WebSocket channels follow the same versioning policy as cross-module surface. A new module-specific endpoint (for example, a future Module 4 oracle endpoint) is a MINOR change. A breaking change to a module-specific endpoint (for example, restructuring the NAV oracle response) is a MAJOR change. The platform does not maintain separate version trees per module — there is one CEDEX API version that covers all three modules uniformly.
#### Base URLs
| Environment | Base URL | WebSocket |
| ----------- | ------------------------------------ | ------------------------------------- |
| Mainnet | `https://api.cedex.market/v1` | `wss://api.cedex.market/ws/v1` |
| Devnet | `https://api.devnet.cedex.market/v1` | `wss://api.devnet.cedex.market/ws/v1` |
When a new MAJOR version is released, the old version remains available at its existing URL for the deprecation period (minimum 6 months). Both versions run simultaneously during the transition.
#### Change Notification
| Channel | What | Lead Time |
| ---------------------- | ------------------------------ | ----------------------------------------- |
| This changelog page | All changes | Published at release |
| status.cedex.market | Breaking changes, deprecations | 30 days before |
| Developer mailing list | Breaking changes | 60 days before |
| API response headers | Deprecation warnings | At release — `X-CEDEX-Deprecation` header |
***
### 2. Current Version
| Property | Value |
| --------------- | -------------------------------------------------------------- |
| Current version | v1.0.0 |
| Release date | Q3 2026 (mainnet launch) |
| Status | Active — current |
| Base URL | `https://api.cedex.market/v1` |
| SDK version | `@rwatokens/sdk` v1.0.x |
| Module support | Module 1 (Equities), Module 2 (Real Estate), Module 3 (CORECM) |
***
### 3. Changelog
#### v1.0.0 — Initial Release (Q3 2026)
**Release type:** MAJOR — Initial public API release. **Status:** Current.
The initial CEDEX API release supporting all ST22 Digital Securities trading operations, portfolio management, oracle monitoring, and WebSocket real-time data across all three modules at launch.
**REST API — Public Endpoints (No Authentication)**
| Method | Endpoint | Description | Module Scope |
| ------ | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------- |
| `GET` | `/v1/markets` | List all active ST22 trading pairs with 24h stats. Supports `?module=` filter. | All modules |
| `GET` | `/v1/markets/{mint}` | Detailed market data for a single ST22 token. Returns module-specific fields. | All modules |
| `GET` | `/v1/markets/{mint}/orderbook` | Current order book depth | All modules |
| `GET` | `/v1/markets/{mint}/trades` | Recent trade history (paginated, default 50, max 200) | All modules |
| `GET` | `/v1/markets/{mint}/ohlcv` | OHLCV candlestick data (1m, 5m, 15m, 1h, 4h, 1d, 1w) | All modules |
| `GET` | `/v1/oracle/{mint}/custody` | Real-time custody attestation (custodied balance, supply, ratio, Ed25519 status) | All modules |
| `GET` | `/v1/oracle/{mint}/nav` | NAV oracle response — appraised NAV, deviation, reappraisal target | Module 2 only |
| `GET` | `/v1/oracle/{mint}/classification` | Classification oracle — USGS / DOE status, federal-action status | Module 3 only |
| `GET` | `/v1/oracle/ofac/status` | OFAC SDN oracle freshness and entry count | All modules |
| `GET` | `/v1/oracle/aml/{wallet}` | AML risk score (cached, public subset) | All modules |
| `GET` | `/v1/health` | System health — oracle status (custody, OFAC, AML, TWAP, EDGAR, NAV, Classification), RPC latency, circuit-breaker state | All modules |
**REST API — Authenticated Endpoints (Wallet Signature)**
| Method | Endpoint | Description |
| -------- | ---------------------- | -------------------------------------------------------------------------------------------------------- |
| `POST` | `/v1/auth/challenge` | Request authentication challenge for wallet signature |
| `POST` | `/v1/auth/verify` | Submit signed challenge — returns bearer token (24h TTL); response includes `eligibility` field |
| `POST` | `/v1/orders` | Place market or limit order (requires Empire verification) |
| `GET` | `/v1/orders` | List orders for the authenticated wallet (filter by status, mint, side) |
| `DELETE` | `/v1/orders/{orderId}` | Cancel an open limit order |
| `GET` | `/v1/portfolio` | Investor portfolio — balances, holding periods (with `regime` field), unlock dates |
| `POST` | `/v1/estimate` | Pre-flight swap estimate — expected output, price impact, compliance check, module-aware failure reasons |
**WebSocket API**
| Channel | Description | Module Scope |
| ------------------ | ------------------------------------------------------------------------------------------------------------- | ------------- |
| `orderbook` | Order book updates (bids/asks) | All modules |
| `trades` | Real-time trade stream for a specific ST22 token | All modules |
| `custody` | Real-time Empire custody attestation updates per Solana block | All modules |
| `circuit_breaker` | Circuit-breaker activation and deactivation events (8 breaker types) | All modules |
| `nav` | Real-time NAV oracle updates and deviation tracking | Module 2 only |
| `classification` | Routine Classification updates plus `federal_action_detected` and `federal_action_freeze_applied` event types | Module 3 only |
| `orders` (private) | Real-time updates for the authenticated wallet's orders | All modules |
**Authentication**
| Property | Specification |
| ------------------ | --------------------------------------------------------------------------------------------------- |
| Method | Wallet signature (Ed25519) |
| Flow | `POST /auth/challenge` → sign with wallet → `POST /auth/verify` → bearer token |
| Token TTL | 24 hours |
| Header | `Authorization: Bearer ` |
| Empire requirement | All authenticated endpoints require Empire Stock Transfer KYC, KYB, AML, OFAC, and KYW verification |
| Eligibility field | `RegD`, `RegS`, `RegCF`, or comma-separated combination |
**Pre-Flight Compliance**
The pre-flight pipeline at v1.0.0 covers eight steps:
| Step | Hook Coverage | Module Scope |
| ---- | ------------------------------------------------------------------ | ------------- |
| 1 | Custody verification (CV-01 to CV-06) | All modules |
| 2 | OFAC screening (SC-30 to SC-34) | All modules |
| 3 | AML risk scoring (IV-09) | All modules |
| 4 | KYC and eligibility (IV-07, IV-08) | All modules |
| 5 | Holding period (HP-24) — Reg D 6mo / Reg S 12mo / Reg CF 12mo | All modules |
| 6 | Price impact (CB-21) | All modules |
| 7 | NAV deviation (CB-21 extension) | Module 2 only |
| 8 | Classification freshness and federal-action freeze (CV-04, REG-42) | Module 3 only |
**Pre-Flight Failure Reasons**
| Reason | Underlying Control | Module Scope |
| ------------------------ | ------------------ | ------------ |
| `HOLDING_PERIOD_LOCKED` | HP-24 | All modules |
| `WALLET_LIMIT_EXCEEDED` | PL-16 | All modules |
| `PRICE_IMPACT_EXCEEDED` | CB-21 | All modules |
| `OFAC_MATCH` | SC-30 to SC-34 | All modules |
| `AML_HIGH_RISK` | IV-09 | All modules |
| `CUSTODY_DISCREPANCY` | CV-01 to CV-06 | All modules |
| `NAV_DEVIATION_EXCEEDED` | CB-21 (extension) | Module 2 |
| `NAV_STALE` | CB-21 (extension) | Module 2 |
| `CLASSIFICATION_STALE` | CV-04 (extension) | Module 3 |
| `FEDERAL_ACTION_FROZEN` | REG-42 | Module 3 |
**Rate Limits**
| Tier | Requests/min | Orders/min | WebSocket Connections |
| ----------------------------------------- | ------------ | ---------- | --------------------- |
| Public (unauthenticated) | 60 | N/A | 2 |
| Standard (authenticated, Empire verified) | 120 | 30 | 5 |
| Verified (Empire KYC complete) | 600 | 120 | 10 |
| Institutional (by arrangement) | Custom | Custom | Custom |
**Error Response Format**
All errors return the same envelope:
```json
{
"error": {
"code": 6020,
"name": "WalletLimitExceeded",
"message": "Post-transfer balance would exceed 4.99% of supply",
"category": "PositionLimit",
"control_id": "PL-16",
"recoverable": true,
"details": {
"current_balance": 450000,
"transfer_amount": 100000,
"max_allowed": 499000,
"supply": 10000000
}
},
"request_id": "req_m7n8o9"
}
```
**Response Headers**
| Header | Description |
| ----------------------- | ------------------------------------------------------------- |
| `X-CEDEX-Version` | API version serving the response (e.g., `1.0.0`) |
| `X-RateLimit-Remaining` | Remaining requests in current window |
| `X-RateLimit-Reset` | Unix timestamp when rate limit resets |
| `X-CEDEX-Deprecation` | Present only if endpoint is deprecated — contains sunset date |
**Idempotency**
`POST /v1/orders` accepts an `idempotency_key` field (max 128 characters). Duplicate requests with the same key and same parameters return the original order without creating a duplicate. Same key with different parameters returns `409 IDEMPOTENCY_CONFLICT`. Keys expire after 24 hours.
***
#### v1.1.0 — Planned (Q4 2026)
**Release type:** MINOR — Backward-compatible additions. **Status:** Planned.
| Change | Type | Description |
| ------------------------------------------------------ | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `GET /v1/markets/{mint}/stats` | New endpoint | Extended market statistics — 7d / 30d volume, unique traders, fee revenue. Module-specific breakdowns surfaced on Module 2 (NAV history) and Module 3 (classification refresh history). |
| `GET /v1/governance/history` | New endpoint | On-chain governance action history (parameter changes, upgrades) |
| `GET /v1/governance/pending` | New endpoint | Currently-timelocked governance proposals |
| `GET /v1/pool/stats` | New endpoint | Global Pool TVL, cumulative fees, reserve ratios — aggregate across all modules |
| `GET /v1/staking/summary` | New endpoint | Staking pool stats — total staked, current APY, epoch countdown |
| `trades` channel — `fee_breakdown` field | New field | Per-recipient fee breakdown on trade events |
| `portfolio` channel — `holding_period_pct` field | New field | Percentage completion of holding period — works across Reg D, Reg S, and Reg CF regimes |
| `nav` channel — `appraisal_history` snapshot | New message type | Optional historical NAV snapshot on subscribe (Module 2 only) |
| `classification` channel — `monitored_sources_summary` | New field | Roll-up summary of all monitored federal sources for the affected basin asset (Module 3 only) |
All v1.0.0 endpoints and fields remain unchanged. No migration required.
***
#### v1.2.0 — Planned (Q1 2027)
**Release type:** MINOR — Backward-compatible additions. **Status:** Planned.
| Change | Type | Description |
| ---------------------------------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `GET /v1/oracle/{mint}/custody/history` | New endpoint | Historical custody attestation records (paginated, all modules) |
| `GET /v1/oracle/{mint}/nav/history` | New endpoint | Historical NAV appraisals with deviation tracking (Module 2 only) |
| `GET /v1/oracle/{mint}/classification/history` | New endpoint | Historical Classification status changes and federal-action events (Module 3 only) |
| `GET /v1/oracle/aml/{wallet}/tier` | New endpoint | AML risk tier (Low / Medium / High) — abstracts the raw score for less-sensitive consumption |
| `POST /v1/orders/batch` | New endpoint | Submit up to 10 orders in a single request, with atomic-or-best-effort semantics |
| `alerts` WebSocket channel | New channel | Subscribe to circuit-breaker events, oracle staleness warnings, Control 42 freezes, and Module 3 federal-action detections across the entire wallet's holdings |
| Pagination cursor | Enhancement | All paginated endpoints support cursor-based pagination (in addition to offset) |
All v1.0.x and v1.1.x endpoints and fields remain unchanged.
***
#### v2.0.0 — Future (TBD)
**Release type:** MAJOR — Breaking changes. **Status:** Not scheduled.
Potential breaking changes under consideration for a future v2 release. **These are not committed** and may change based on integrator feedback.
| Potential Change | Rationale |
| -------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Authentication migration from wallet signature to OAuth 2.0 + wallet | Institutional integrators prefer OAuth flows for server-to-server |
| Response envelope standardization | Wrap all responses in `{ data: ..., meta: ... }` envelope |
| Decimal representation change (number → string) | Prevent floating-point precision loss for large amounts |
| WebSocket protocol upgrade (JSON → Protobuf option) | Bandwidth reduction for high-frequency institutional feeds |
| Module-aware namespacing | Optional `/v2/equities/...` and `/v2/real-estate/...` and `/v2/corecm/...` namespaces in addition to mint-keyed endpoints, for integrators who want to scope clients to a single module |
When v2.0.0 is scheduled, this section will be replaced with a concrete migration guide and a minimum 6-month deprecation timeline for v1.
***
### 4. Deprecation Policy
#### Timeline
| Phase | Duration | Behavior |
| ---------- | ------------------------- | --------------------------------------------------------------------------------------- |
| Active | Current version | Full support, bug fixes, new features |
| Deprecated | 6 months minimum | Still operational. `X-CEDEX-Deprecation` header added. No new features. Bug fixes only. |
| Sunset | End of deprecation period | Endpoints return `410 Gone`. Integrators must have migrated. |
#### Deprecation Signals
When an endpoint or field is deprecated, three signals are emitted:
```
1. CHANGELOG: Entry added to this page with deprecation date and replacement
2. RESPONSE HEADER: Every response from the deprecated endpoint includes:
X-CEDEX-Deprecation: sunset=2027-06-30; replacement=/v2/markets
3. STATUS PAGE: Deprecation notice posted to status.cedex.market
```
#### Individual Endpoint Deprecation
Individual endpoints within a MAJOR version can be deprecated independently. For example, if `/v1/markets/{mint}/orderbook` is replaced by a more efficient endpoint, the old endpoint enters the deprecation lifecycle while the rest of v1 remains active.
#### Module-Specific Deprecation
A module-specific endpoint (NAV oracle, Classification oracle) can be deprecated and replaced independently of cross-module endpoints. For example, the Module 2 NAV oracle endpoint structure could evolve to support multi-asset NAV (multiple properties under a single mint) in a future version. The original NAV endpoint would enter deprecation while the cross-module surface remains untouched.
#### No Silent Deprecation
The platform will never remove an endpoint, change a response format, or alter behavior without advance notice through the channels listed above. If you see `X-CEDEX-Deprecation` in any response header, check this changelog for migration instructions.
***
### 5. Migration Guides
#### Migrating from Devnet to Mainnet
No code changes required — only configuration:
```typescript
// Devnet
const client = new RwaTokensClient({
network: 'devnet',
rpcEndpoint: 'https://devnet.helius-rpc.com/?api-key=YOUR_KEY',
});
// Mainnet — same SDK, different config
const client = new RwaTokensClient({
network: 'mainnet-beta',
rpcEndpoint: 'https://mainnet.helius-rpc.com/?api-key=YOUR_KEY',
});
```
API base URLs:
* Devnet: `https://api.devnet.cedex.market/v1`
* Mainnet: `https://api.cedex.market/v1`
Request and response formats are identical across environments. Devnet uses simulated oracle data and test tokens. Module-aware endpoints are available on both environments — the same `/v1/oracle/{mint}/nav` and `/v1/oracle/{mint}/classification` endpoints work for devnet test mints with simulated NAV and Classification data.
#### Migrating Between Modules
The CEDEX API is designed so that integrators do not need to change SDK calls when handling mints from different modules. The same `client.cedex.placeOrder()`, `client.cedex.estimateSwap()`, and `client.cedex.cancelOrder()` methods work for any ST22 mint regardless of module. Module-specific behavior is surfaced through module-specific oracle endpoints (`getNAVOracle()`, `getClassificationOracle()`) and module-specific WebSocket channel subscriptions.
The recommended pattern for module-aware applications:
1. Read the `module` field on `GET /v1/markets/{mint}` to determine the mint's module.
2. For Module 2 mints, additionally subscribe to the `nav` WebSocket channel and surface NAV deviation in the UI.
3. For Module 3 mints, additionally subscribe to the `classification` WebSocket channel and surface federal-action status in the UI.
4. Handle the additional pre-flight failure reasons (`NAV_DEVIATION_EXCEEDED`, `CLASSIFICATION_STALE`, `FEDERAL_ACTION_FROZEN`) in error-handling code paths.
#### Future: Migrating from v1 to v2
This section will be populated when v2 is scheduled. It will include:
* Complete mapping of v1 endpoints to v2 equivalents.
* Request and response format changes with before/after examples.
* Authentication migration steps.
* SDK upgrade instructions.
* Timeline with deprecation and sunset dates.
* Module-specific migration steps where applicable.
***
### 6. Upcoming Changes
#### Under Consideration (Not Committed)
These are features and changes being evaluated based on integrator feedback. Nothing in this section is guaranteed to ship.
| Feature | Status | Description |
| --------------------------- | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| GraphQL API | Evaluating | Alternative query interface for complex portfolio and market data queries; particularly useful for module-aware UIs that need to compose data across multiple oracles |
| Webhook notifications | Evaluating | Server-to-server push notifications for trade fills, holding-period unlock, circuit-breaker events, NAV-deviation triggers (Module 2), and federal-action events (Module 3) |
| FIX protocol gateway | Early research | FIX 4.4 / 5.0 interface for institutional trading desks |
| Historical data API | Planned (v1.2) | Paginated historical trades, OHLCV, custody attestations, NAV appraisals (Module 2), and classification history (Module 3) |
| Multi-mint batch operations | Planned (v1.2) | Batch order submission and portfolio queries across multiple ST22 tokens regardless of module |
| Module 4 onboarding hooks | Future research | Generic oracle-extension framework for future asset classes beyond Equities, Real Estate, and CORECM |
#### How to Request Features
Submit feature requests through the platform's developer GitHub issue tracker or via . Include your use case, expected request/response format, and volume expectations.
***
### 7. SDK Compatibility Matrix
| SDK Version | API Version | Node.js | Module Coverage | Status |
| ---------------------- | ------------------------ | -------------- | ----------------- | -------------------------- |
| `@rwatokens/sdk` 1.0.x | v1.0.0 | 20 LTS | All three modules | Current — active support |
| `@rwatokens/sdk` 1.1.x | v1.0.0 + v1.1.0 | 20 LTS, 22 LTS | All three modules | Planned (Q4 2026) |
| `@rwatokens/sdk` 1.2.x | v1.0.0 + v1.1.0 + v1.2.0 | 20 LTS, 22 LTS | All three modules | Planned (Q1 2027) |
| `@rwatokens/sdk` 2.0.x | v2.0.0 | TBD | All three modules | Future (when v2 API ships) |
#### SDK Update Policy
| SDK Version Change | API Change | Action Required |
| --------------------- | ----------------- | ---------------------------------- |
| Patch (1.0.0 → 1.0.1) | Bug fixes only | Recommended but not required |
| Minor (1.0.x → 1.1.0) | New methods added | Not required — existing code works |
| Major (1.x → 2.0) | Breaking changes | Required — update before v1 sunset |
#### Checking Your SDK Version
```typescript
import { version } from '@rwatokens/sdk';
console.log(version); // "1.0.0"
```
#### Checking the API Version at Runtime
```typescript
const response = await fetch('https://api.cedex.market/v1/health');
const apiVersion = response.headers.get('X-CEDEX-Version');
console.log(apiVersion); // "1.0.0"
```
#### Module-Aware SDK Usage
The SDK exposes module-specific helpers without requiring integrators to instantiate per-module clients:
```typescript
// Single client — handles all modules
const client = new RwaTokensClient({ network: 'mainnet-beta', wallet });
// Standard methods — module-agnostic
await client.cedex.placeOrder(/* ... */);
await client.cedex.estimateSwap(/* ... */);
// Module-specific oracle helpers
const navData = await client.oracle.getNAV(mint); // Module 2
const classificationData = await client.oracle.getClassification(mint); // Module 3
```
***
### Related Documentation
* **CEDEX API Reference** — Complete endpoint documentation with request/response schemas, code examples, and module-aware API surface.
* **SDK Reference** — `RwaTokensClient` methods, error handling, WebSocket patterns.
* **Changelog** — Protocol-level version history (smart contracts, platform changes).
* **Network Configuration** — RPC endpoints, program IDs, environment variables, oracle PDAs.
* **Smart Contract Reference** — On-chain program documentation (Transfer Hook, AMM, Oracle Aggregator, Liquidity Pool, Governance).
* **Oracle Integration Guide** — Custody, OFAC, AML, TWAP, EDGAR, NAV, and Classification relay architecture.
***
*RWA Tokens · CEDEX API Changelog · v1.0.0 · Q3 2026*
# Oracle Integration Guide
## Oracle Integration Guide
**Seven Oracle Categories · Ed25519 Attestation · Fail-Safe Architecture · Relay Operations · Module-Aware**
Technical reference for oracle operators, the Empire Stock Transfer technical team, compliance provider integrators (Chainalysis, TRM Labs), and infrastructure engineers responsible for maintaining the real-time data feeds that drive every Transfer Hook compliance decision. The platform's oracle architecture serves all three production modules: Equities (Module 1), Real Estate (Module 2), and CORECM — Carbon Ore, Rare Earth, and Critical Minerals (Module 3). Module-aware oracles (NAV for Module 2; Classification for Module 3) are documented alongside cross-module oracles (Custody, OFAC, AML, TWAP, EDGAR).
***
### Table of Contents
1. Architecture Overview
2. Custody Verification Oracle (Empire)
3. OFAC / SDN Sanctions Oracle
4. AML Risk Scoring Oracle
5. TWAP and Price Discovery Oracle (Pyth)
6. SEC EDGAR Intelligence Oracle
7. NAV Oracle — Module 2
8. Classification Oracle — Module 3
9. On-Chain Account Schemas
10. Relay Service Architecture
11. Fail-Safe Cascade
12. Health Monitoring
13. Failure Injection Testing
14. Key Rotation
15. Troubleshooting
***
### 1. Architecture Overview
#### 1.1 Role in the Stack
The Oracle Network is the real-time data backbone feeding the Transfer Hook's 42 compliance controls. Oracle data flows directly to the Transfer Hook through the Oracle Aggregator program — it does not pass through the platform's application stack. **An oracle failure is a compliance failure.**
```
EXTERNAL DATA SOURCES
┌────────┬────────┬────────┬────────┬────────┬────────┬────────┐
│ Empire │Treasury│Chainalys│ Pyth │ SEC │ Lic'd │ USGS+ │
│ Stock │ OFAC │ + TRM │ Net │ EDGAR │ Apprai-│ DOE + │
│ Trans- │ API │ Labs │ │ RSS │ ser │ Federal│
│ fer │ │ │ │ │ Network│Register│
└────┬───┴────┬───┴────┬───┴────┬──┴────┬───┴────┬───┴────┬───┘
│ │ │ │ │ │ │
┌────▼───┬────▼───┬────▼───┬────▼──┬────▼───┬────▼───┬────▼───┐
│Custody │ OFAC │ AML │ TWAP │ EDGAR │ NAV │Classif-│
│ Relay │Indexer │ Bridge │Consum-│Pipeline│ Relay │ication │
│ │ │ │ er │ │ │ Relay │
└────┬───┴────┬───┴────┬───┴────┬──┴────┬───┴────┬───┴────┬───┘
│ │ │ │ │ │ │
ORACLE AGGREGATOR PROGRAM (on chain)
│
┌────▼──────────────────────────────────────────────────────────┐
│ TRANSFER HOOK (42 controls) │
│ Controls CV-01 to CV-06: read CustodyOracle │
│ Controls SC-30 to SC-34: read OFACOracle │
│ Control IV-09: read AMLOracle │
│ Control HP-24: read HoldingPeriodAccount │
│ Control CB-21: read TWAP from SecurityConfig │
│ (+ NAVOracle for Module 2 mints) │
│ Control CV-04 / IV-08: read EDGAR issuer eligibility + │
│ ClassificationOracle for Module 3 │
│ Control REG-42: activated on Module 3 federal │
│ actions; auto-coordination via │
│ ClassificationOracle │
└───────────────────────────────────────────────────────────────┘
```
#### 1.2 Seven Oracle Categories
| Oracle | Transfer Hook Controls | Source | Update Cadence | Module Scope | Fail-Safe |
| ------------------ | -------------------------- | ------------------------------- | ------------------------------ | ---------------------- | ----------------------------------------------------------- |
| **Custody** | CV-01 to CV-06 | Empire Ed25519 API | Every block (\~400ms) | All modules | **REJECT ALL TRANSFERS** |
| **OFAC / SDN** | SC-30 to SC-34 | U.S. Treasury OFAC | Hourly + emergency push | All modules | Cache <24h; halt >48h |
| **AML** | IV-09 | Chainalysis KYT + TRM Labs | Per-transfer (cached 6h) | All modules | Cache <6h |
| **TWAP / Price** | CB-20, CB-21, CB-22, CB-23 | Pyth Network | Sub-second | All modules | Last confirmed price |
| **EDGAR** | IV-08 + Layer 9 IDOS | SEC EDGAR RSS + EFTS | Real-time + daily batch | Module 1 (Equities) | Last batch |
| **NAV** | CB-21 (extension) | Independent licensed appraisers | Per reappraisal cycle | Module 2 (Real Estate) | Mint paused on staleness |
| **Classification** | CV-04 (extension) + REG-42 | USGS + DOE + Federal Register | Daily + emergency on EO update | Module 3 (CORECM) | Enhanced review on staleness; auto-freeze on federal action |
#### 1.3 Asymmetric Fail-Safe Principle
Not all oracle failures are equal. The custody oracle has the strictest fail-safe because a custody discrepancy threatens the 1:1 backing guarantee — the foundational property of every ST22 token. A stale AML score is manageable risk. A wrong custody count is existential.
| Oracle Failure | Risk Level | Response |
| -------------------------------------------------------------------------- | ------------ | ---------------------------------------------------------------------------- |
| Custody stale > 1 slot | Catastrophic | Reject ALL transfers (Error 6001 / 6002) |
| OFAC stale > 24h | High | Use cached list |
| OFAC stale > 48h | Critical | Halt ALL transfers |
| AML stale > 6h | Medium | Mandatory on-demand refresh |
| TWAP unavailable > 5 min | Medium | Disable circuit breaker |
| EDGAR batch delayed | Low | Continue with last batch, flag stale |
| **NAV stale beyond `nav_reappraisal_max_age_secs`** *(Module 2)* | High | Pause affected Module 2 mint until fresh appraisal |
| **NAV deviation exceeds `nav_deviation_max_bps`** *(Module 2)* | High | Pause affected Module 2 mint until fresh appraisal restores price |
| **Classification stale beyond `classification_max_age_secs`** *(Module 3)* | Medium | Continue with enhanced review; flag operations |
| **Federal action detected** *(Module 3)* | Catastrophic | Auto-coordinate Control 42 freeze (Legal Counsel + 3-of-5 within 60-min SLA) |
***
### 2. Custody Verification Oracle (Empire)
The most critical oracle. Zero-tolerance. Zero-discrepancy. Hard fail-safe. Operates identically across all three modules.
#### 2.1 Data Source
Empire Stock Transfer — SEC §17A-registered transfer agent and qualified custodian. Empire holds the authoritative record of the underlying asset for each ST22 issuer:
* **Module 1.** Common Class B shares of the issuing entity.
* **Module 2.** Equity in the single-asset entity that owns the underlying real-property asset.
* **Module 3.** Equity in the basin-asset entity that owns the underlying mineral basin or mining concession.
The custody oracle treats all three uniformly — it tracks the custodied balance and the on-chain token supply. The asset class is recorded in the SecurityConfig's `asset_identifier` field at mint creation; the oracle does not need to discriminate between modules.
#### 2.2 Attestation Payload
Empire signs a 64-byte payload with Ed25519 on every Solana block. The signed payload contains:
| Field | Size | Description |
| ------------------- | -------- | --------------------------- |
| `mint` | 32 bytes | ST22 mint address |
| `custodied_balance` | 8 bytes | Empire-custodied unit count |
| `token_supply` | 8 bytes | On-chain circulating supply |
| `slot` | 8 bytes | Current Solana slot |
| `timestamp` | 8 bytes | Unix timestamp |
Total signed payload: 64 bytes. Signed with Empire's Ed25519 private key (HSM-backed). Verified with the Solana Ed25519 precompile.
#### 2.3 Relay Service
The custody relay service bridges Empire's API to the on-chain CustodyOracle account. The service polls per Solana slot (\~400ms cadence), fetches the latest attestation from Empire, verifies the Ed25519 signature locally as a pre-check, and submits the on-chain update.
```typescript
interface EmpireCustodyResponse {
mint: string;
custodied_balance: number;
token_supply: number;
signature: string; // Base58-encoded Ed25519 signature
timestamp: number;
}
class CustodyRelay {
private readonly empireApi: string;
private readonly connection: Connection;
private readonly relayKeypair: Keypair;
async run(): Promise {
// Poll every Solana block (~400ms)
this.connection.onSlotChange(async (slotInfo) => {
for (const mint of this.activeMints) {
try {
const attestation = await this.fetchEmpireAttestation(mint);
this.verifySignature(attestation);
await this.updateCustodyOracle(mint, attestation);
if (attestation.custodied_balance !== attestation.token_supply) {
this.triggerP0Alert(mint, attestation);
}
} catch (error) {
this.handleRelayError(mint, error);
}
}
});
}
private async updateCustodyOracle(
mint: PublicKey,
attestation: EmpireCustodyResponse,
): Promise {
return await this.oracleProgram.methods
.updateCustodyOracle(/* attestation fields */)
.accounts({
custodyOracle: this.deriveCustodyOraclePda(mint),
mint,
relayAuthority: this.relayKeypair.publicKey,
clock: SYSVAR_CLOCK_PUBKEY,
ed25519Program: Ed25519Program.programId,
})
.signers([this.relayKeypair])
.rpc();
}
}
```
#### 2.4 On-Chain Verification Flow
When the Transfer Hook reads the CustodyOracle, it executes four sequential checks:
1. Ed25519 signature is valid (`is_valid` flag is true). If false, return Error 6002 (`CustodyOracleUnavailable`).
2. Attestation is fresh — slot age must be at most 1 (i.e., current slot or one slot prior). If older, return Error 6002.
3. Token supply is less than or equal to the custodied balance (zero-tolerance ratio). If supply exceeds custody, return Error 6001 (`CustodyDiscrepancy`).
4. No active discrepancy is recorded. If `discrepancy_detected` is true, return Error 6038 (`CustodyDiscrepancyHalt`).
All four checks must pass for any transfer to proceed.
#### 2.5 Discrepancy Response Procedure
```
CustodyOracle detects: custodied_balance ≠ token_supply
│
├─ IMMEDIATE: Error 6001 on ALL subsequent transfers (affected mint)
├─ IMMEDIATE: Circuit breaker activates
├─ IMMEDIATE: CustodyDiscrepancyDetected event emitted
│
├─ 0-15 min: P0 dual notification
│ ├─ Platform operations: PagerDuty alert
│ └─ Empire compliance: dedicated hotline
│
├─ Investigation:
│ ├─ Empire confirms actual unit count
│ ├─ Platform verifies on-chain supply
│ └─ Root cause identified
│
└─ Resolution:
├─ 2-of-3 oracle consensus confirms count matches
│ ├─ Primary: Empire Ed25519
│ ├─ Secondary: platform verification node
│ └─ Tertiary: quarterly audit record
├─ discrepancy_detected set to false
└─ Trading resumes
```
#### 2.6 Specifications
| Parameter | Value |
| --------------------- | ----------------------------------------------------------------- |
| Update cadence | Every Solana block (\~400ms) |
| Signature algorithm | Ed25519 (NIST-standardized) |
| Verification | Solana native Ed25519 precompile (\~120 CU) |
| Staleness threshold | 1 slot (> 1 slot = Error 6002) |
| Discrepancy threshold | Zero tolerance (≥ 1 unit = Error 6001) |
| Latency SLA | < 200ms from custody change to oracle update |
| Fail-safe | REJECT ALL TRANSFERS — hard halt |
| Production record | Zero discrepancy events across three beta issuers, $7M+ processed |
***
### 3. OFAC / SDN Sanctions Oracle
#### 3.1 Data Source
U.S. Treasury Department Office of Foreign Assets Control (OFAC) SDN list via official API. Operates identically across all three modules.
#### 3.2 Three-Layer Screening
| Layer | Method | Purpose | Example |
| ------------------------- | --------------------------------------------------------------------- | -------------------------------------------------- | --------------------------------------------- |
| Layer 1: Exact Address | Direct Solana wallet address match against known SDN addresses | Catches directly sanctioned wallets | Wallet `ABC123` matches SDN entry |
| Layer 2: Fuzzy Entity | Entity name and alias matching via Chainalysis KYT entity resolution | Catches slight name variations in entity investors | "ACME Corp" matches "ACME Corporation LLC" |
| Layer 3: 2-Hop Clustering | Transaction graph analysis — wallets within 2 degrees of SDN entities | Catches proxy wallet strategies | Wallet funded by wallet funded by SDN address |
#### 3.3 Indexer Service
The OFAC indexer service runs scheduled hourly refreshes plus an emergency-push listener for Treasury webhook events. On each refresh, the service fetches the current SDN list, computes a SHA-256 hash, compares with the previous hash, indexes new entries if changed, and updates the on-chain OFACOracle account with the hash and entry count.
```typescript
class OFACIndexer {
private readonly ofacApiUrl = 'https://api.treasury.gov/ofac/sdn';
private readonly refreshIntervalMs = 3_600_000; // 1 hour
private sdnList: SDNEntry[] = [];
private listHash: Buffer;
async run(): Promise {
setInterval(() => this.refreshSDNList(), this.refreshIntervalMs);
this.listenForEmergencyUpdates();
}
private async refreshSDNList(): Promise {
const response = await fetch(this.ofacApiUrl);
const entries: SDNEntry[] = await response.json();
const hash = crypto.createHash('sha256')
.update(JSON.stringify(entries))
.digest();
if (hash.equals(this.listHash)) return;
this.sdnList = entries;
this.listHash = hash;
await this.updateOFACOracle(hash, entries.length);
await this.rescreenActiveWallets();
}
}
```
The actual SDN entries are tracked off chain — Solana account-size limits make on-chain storage of the full SDN list infeasible. The on-chain hash provides cryptographic commitment to the indexer's view of the list.
#### 3.4 Transfer Hook Integration
Controls SC-30 through SC-34 read the OFAC oracle on every transfer. The hook performs three checks: oracle freshness (halt if older than `halt_threshold`), exact address match against the indexed SDN set, and continuous re-screening on every transfer (Control SC-33). Sender match returns Error 6003 (`SenderSanctioned`); receiver match returns Error 6004 (`ReceiverSanctioned`); oracle stale beyond threshold returns Error 6005 (`OfacOracleStale`).
#### 3.5 Staleness Thresholds
| Age | Status | Behavior |
| ----------- | -------------- | ------------------------------------------------------------------- |
| 0–24 hours | Fresh | Normal operation — SDN check on every transfer |
| 24–48 hours | Stale (cached) | Continue with cached list. P2 alert raised. |
| > 48 hours | Critical | **HALT ALL TRANSFERS** — Error 6005 on every transfer until refresh |
#### 3.6 False-Positive Handling
If a legitimate wallet is flagged: the transfer is rejected with Error 6003 or 6004; the compliance team is notified automatically (5-minute SLA); Empire Stock Transfer is notified for investor record annotation; manual review determines whether the flag is accurate; if false positive, the wallet is cleared in the oracle and the investor can retry. Typical resolution: 1–4 hours.
***
### 4. AML Risk Scoring Oracle
#### 4.1 Dual-Provider Architecture
Two independent blockchain-analytics providers score every wallet. Different ML models and training data reduce single-provider blind spots.
| Provider | Capabilities | Integration |
| --------------- | ------------------------------------------------------------------------- | ------------------------- |
| Chainalysis KYT | Industry standard. Widest entity coverage. Law-enforcement relationships. | REST API per-wallet query |
| TRM Labs | 200+ behavioral features. Strong pattern detection for emerging threats. | REST API per-wallet query |
#### 4.2 Risk Disposition
| Score Range | Disposition | Transfer Action | Post-Transfer |
| ----------- | --------------- | ------------------------------ | ---------------------------------- |
| 0–30 | Approve | Transfer proceeds | — |
| 31–70 | Enhanced Review | Transfer proceeds but flagged | Compliance team reviews within 24h |
| 71–100 | Reject | Transfer rejected — Error 6006 | Wallet blocked. Empire notified. |
The higher of the two provider scores determines disposition. If Chainalysis scores 25 (approve) but TRM scores 72 (reject), the wallet is rejected.
#### 4.3 Bridge Service
The AML bridge service queries both providers in parallel, aggregates the higher score, determines disposition, updates the on-chain AMLOracle account, and caches the result for 6 hours.
```typescript
class AMLBridge {
private readonly chainalysisApi: ChainalysisKYT;
private readonly trmApi: TRMLabs;
private readonly cacheValidSecs = 21_600; // 6 hours
async scoreWallet(wallet: PublicKey): Promise {
const cached = await this.getCache(wallet);
if (cached && !this.isStale(cached)) return cached;
const [chainalysisScore, trmScore] = await Promise.all([
this.chainalysisApi.getScore(wallet.toBase58()),
this.trmApi.getScore(wallet.toBase58()),
]);
const aggregateScore = Math.max(
chainalysisScore.risk_score,
trmScore.risk_score,
);
const disposition =
aggregateScore <= 30 ? 'approve' :
aggregateScore <= 70 ? 'review' :
'reject';
await this.updateAMLOracle(wallet, aggregateScore, disposition);
await this.setCache(wallet, aggregateScore, disposition);
return { score: aggregateScore, disposition };
}
}
```
#### 4.4 Cache Management
| Scenario | Behavior |
| ---------------------------- | ---------------------------------------------------------- |
| Cached score < 6 hours old | Use cached. No API call. |
| Cached score 6–12 hours old | Mandatory refresh before transfer proceeds. |
| No cached score (new wallet) | On-demand fresh query. Both providers. |
| Provider API timeout (> 2s) | Use partner provider score only. Log degradation. |
| Both providers timeout | Use last cached score if < 12h. Reject if no score exists. |
#### 4.5 Specifications
| Parameter | Value |
| -------------------- | -------------------------------------------------------- |
| Providers | Chainalysis KYT + TRM Labs |
| Aggregation | Higher score determines disposition |
| Approve threshold | 0–30 |
| Review threshold | 31–70 |
| Reject threshold | 71–100 (Error 6006) |
| Cache validity | 6 hours |
| Refresh cadence | Every 6h for active wallets; on-demand for new wallets |
| Latency SLA | < 400ms (cached), < 2s (fresh query) |
| Fail-safe | Cache < 6h; reject if no score available |
| Module 3 enhancement | Beneficial-ownership depth required for entity investors |
***
### 5. TWAP and Price Discovery Oracle (Pyth)
#### 5.1 Data Source
Pyth Network — pull-based high-frequency price oracle. First-party data publishers (institutional market makers, trading firms) publish price attestations directly on chain.
#### 5.2 TWAP Calculation
Control CB-21 enforces maximum 2% price impact per transfer against a rolling TWAP. The TWAP calculation uses time-weighted observations across a 30-minute window with a minimum of 60 observations.
The TWAP state is held inside the SecurityConfig per mint. Observation list, window seconds, minimum observations, and outlier-rejection sigma are all read by the Transfer Hook on every transfer.
#### 5.3 TWAP Parameters
| Parameter | Default | Governance Range | Immutable? |
| ----------------------------- | ------------------------------- | ------------------ | ---------- |
| Calculation window | 30 minutes | 15–60 min | No |
| Minimum observations | 60 | — | **Yes** |
| Max price impact per transfer | 2% (200 bps) | 1–5% (100–500 bps) | No |
| Outlier rejection | > 3σ from rolling median | — | **Yes** |
| Circuit-breaker reset | Automatic on TWAP normalization | — | N/A |
#### 5.4 Consumer Service
The TWAP consumer subscribes to the Pyth Network SOL-USD price feed, accumulates observations into a rolling window, prunes observations outside the window, rejects outliers using 3σ filtering against the rolling median, calculates the time-weighted TWAP, and updates the SecurityConfig's TWAP state.
```typescript
class TWAPConsumer {
private readonly pythConnection: PythConnection;
private observations: PriceObservation[] = [];
async run(): Promise {
this.pythConnection.onPriceChange(this.priceFeedId, (price) => {
this.observations.push({
price: price.price,
confidence: price.confidence,
timestamp: Date.now() / 1000,
slot: price.slot,
});
const windowStart = Date.now() / 1000 - this.windowSecs;
this.observations = this.observations
.filter(o => o.timestamp >= windowStart);
const filtered = this.rejectOutliers(this.observations);
if (filtered.length >= this.minObservations) {
const twap = this.calculateTWAP(filtered);
this.updateSecurityConfigTWAP(twap);
}
});
}
}
```
#### 5.5 Circuit-Breaker Integration
| Trigger | Threshold | Response | Control |
| ------------------------- | -------------- | ----------------------------------- | ------- |
| Single-trade price impact | > 2% vs TWAP | Block trade (Error 6021) | CB-21 |
| 5-minute price movement | > 10% | 15-minute trading halt (Error 6005) | CB-20 |
| TWAP unavailable | > 5 minutes | Circuit breaker disabled. P2 alert. | CB-22 |
| Volume spike | > 100x 24h avg | Enhanced monitoring. P2 alert. | CB-22 |
#### 5.6 Manipulation Resistance
| Attack | Defense | Why It Fails |
| --------------------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| Single-block price manipulation | 60-observation minimum across 30-min window | One manipulated observation cannot move TWAP |
| Sustained manipulation (30 min) | Cost of sustained manipulation across 60+ observations exceeds extractable value | Economically irrational |
| Outlier injection | 3σ rejection excludes extreme values | Manipulated observations automatically excluded |
| TWAP stale attack (force disable) | Circuit breaker disabled after 5 min — trades proceed without impact limit | Attacker gains no advantage; other controls (wallet limits, volume halt) still active |
#### 5.7 Module 2 — TWAP versus NAV
For Module 2 (Real Estate) mints, the TWAP-based circuit breaker (CB-21) is supplemented by a NAV-deviation circuit breaker also classified under CB-21. Both checks must pass: the TWAP-based price-impact check and the NAV-deviation check. The NAV oracle and its deviation enforcement are documented in §7. Module 1 and Module 3 mints rely on TWAP alone for CB-21.
***
### 6. SEC EDGAR Intelligence Oracle
#### 6.1 Module Scope
The EDGAR oracle is **Module 1-only**. It serves Equities issuers that file SEC reports via EDGAR. Module 2 (Real Estate) and Module 3 (CORECM) issuers are not SEC-reporting in the same way; their issuer-disclosure pipelines are the NAV oracle (Module 2) and the Classification oracle (Module 3) respectively.
#### 6.2 Dual Consumer Architecture
The EDGAR oracle is unique — it feeds both the Transfer Hook (via Control IV-08 issuer eligibility) and the Layer 9 IDOS off-chain compliance system. Single pipeline, two consumers.
| Consumer | Purpose |
| ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| Control IV-08 (Transfer Hook) | Issuer eligibility — SEC registration current, no enforcement action, 15c2-11 compliance. Failure flags via `is_eligible` field on SecurityConfig. |
| Layer 9 IDOS | Issuer Distress and Opportunity Score — issuer-disclosure intelligence for onboarding priority and ongoing monitoring. |
#### 6.3 Data Pipeline
```
SEC EDGAR RSS Feed ──────────────────────────────────────────┐
│ Real-time: new filings across ~15,000 OTC companies │
│ Polling interval: 60 seconds │
▼ │
Deduplication + Normalization ──────────────────────┐ │
▲ │ │
SEC EDGAR EFTS API ─────────────────────────────────┘ │
│ Daily batch: full-text search across complete corpus │
│ Throughput: 1,000 CIKs per batch │
▼ │
┌──────────────────────────────────────────────────────────────┘
│
├──► Control IV-08: issuer eligibility flag
│ ├─ 10-K / 10-Q current? → allow
│ ├─ 8-K enforcement detected? → flag for halt
│ ├─ Form D filed? → Reg D verified
│ └─ Rule 15c2-11 status → eligibility flag
│
└──► Layer 9 IDOS:
├─ NLP extraction from 8-K, 10-K, 10-Q
├─ Going-concern detection
├─ Tier degradation tracking
└─ Capital-raise timing analysis
```
#### 6.4 Filing Type Mapping
| Filing | Control IV-08 (Transfer Hook) | Layer 9 IDOS | Latency |
| ----------- | ---------------------------------------------- | -------------------------------------- | -------------- |
| 8-K | Enforcement detection → flag for halt on match | Material event → immediate IDOS update | < 60s from RSS |
| 10-K / 10-Q | Current filing status verification | Financial-distress NLP scan | < 60s from RSS |
| Form D | Reg D registration verification | Capital-raise urgency scoring | < 60s from RSS |
| DEF 14A | SEC reporting compliance confirmation | Shareholder-count extraction | Daily batch |
| 15c2-11 | Trading eligibility (Expert Market detection) | Tier-degradation scoring | 15-min polling |
#### 6.5 Pipeline Service
The EDGAR pipeline runs RSS polling every 60 seconds and a full EFTS batch daily at 02:00 UTC. RSS-detected filings are deduplicated against the cache, classified by type, processed by both consumers (Control IV-08 and Layer 9 IDOS), and update the on-chain issuer-eligibility flag where applicable.
```typescript
class EDGARPipeline {
private readonly rssUrl = 'https://www.sec.gov/cgi-bin/browse-edgar?...';
private readonly eftsUrl = 'https://efts.sec.gov/LATEST/search-index';
async run(): Promise {
setInterval(() => this.pollRSS(), 60_000);
cron.schedule('0 2 * * *', () => this.runFullBatch());
}
private async pollRSS(): Promise {
const filings = await this.fetchRSS();
for (const filing of filings) {
if (this.isMonitoredIssuer(filing.cik)) {
await this.updateIssuerEligibility(filing);
await this.updateIDOSScore(filing);
}
}
}
}
```
#### 6.6 Specifications
| Parameter | Value |
| ---------------------- | ------------------------------------------------------- |
| RSS polling interval | 60 seconds |
| EFTS batch schedule | Daily at 02:00 UTC |
| EFTS throughput | 1,000 CIKs per batch |
| Monitored universe | \~15,000 OTC companies |
| 8-K processing latency | < 60 seconds from RSS publication |
| Module scope | Module 1 only |
| Fail-safe | Continue with last batch. IDOS flagged stale. P2 alert. |
***
### 7. NAV Oracle — Module 2
The NAV Oracle holds the most recent appraised Net Asset Value for a Module 2 (Real Estate) ST22 mint. It is the structural mechanism for tying the on-chain price of a Module 2 mint to the underlying real-property value.
#### 7.1 Module Scope
The NAV oracle is **Module 2-only**. Module 1 mints have no NAV oracle (their value is determined purely by AMM trading). Module 3 mints have no NAV oracle (their value is also AMM-determined; classification status, not NAV, is the regulatory anchor).
#### 7.2 Data Source
Independent licensed real-estate appraisers engaged under the tripartite agreement between the issuer, Groovy Company, Inc., and Empire Stock Transfer. The appraiser is selected at mint creation and rotates per the schedule defined in the issuer's tripartite. Each appraisal is signed by the appraiser using Ed25519 (HSM-backed where the appraiser's infrastructure supports it; software-backed otherwise) and submitted via the NAV relay service.
#### 7.3 Update Cadence
NAV reappraisals follow the schedule defined in the tripartite agreement. Common schedules:
| Property Type | Reappraisal Cadence | Between-Cycle Reviews |
| ------------------------------------------- | ------------------- | ------------------------- |
| Stabilized commercial (office, multifamily) | Annual | Quarterly |
| Active development | Quarterly | Monthly |
| Distressed or special situation | Quarterly | Continuous (event-driven) |
The on-chain `nav_reappraisal_max_age_secs` field on the NAVOracle PDA reflects the configured maximum. When the on-chain age exceeds this threshold, the affected mint is paused on the AMM until a fresh appraisal is published.
#### 7.4 Attestation Payload
The NAV attestation is a 96-byte signed payload containing the mint, the appraised NAV in USD-pegged stablecoin units, the appraiser's identifier, the appraisal timestamp, the next-reappraisal target timestamp, and the appraiser's authority signature.
| Field | Size | Description |
| ------------------------- | -------- | --------------------------------------------------- |
| `mint` | 32 bytes | Module 2 ST22 mint address |
| `appraised_nav_usd` | 16 bytes | u128 — appraised NAV in USD-pegged stablecoin units |
| `appraiser_id` | 16 bytes | Identifier of the licensed appraiser |
| `appraisal_timestamp` | 8 bytes | Unix timestamp |
| `next_reappraisal_target` | 8 bytes | Unix timestamp (issuer-tripartite schedule) |
| `signature_metadata` | 16 bytes | Appraiser key version, license number reference |
#### 7.5 Relay Service
The NAV relay service receives signed appraisal submissions from authorized appraisers, verifies appraiser authentication and license credentials, validates the Ed25519 signature against the appraiser's registered public key, and submits the on-chain update.
```typescript
class NAVRelay {
private readonly authorizedAppraisers: Map;
private readonly oracleProgram: Program;
async receiveAppraisal(submission: NAVSubmission): Promise {
const appraiser = this.authorizedAppraisers.get(submission.appraiser_id);
if (!appraiser) {
throw new Error('Unauthorized appraiser');
}
if (this.isLicenseExpired(appraiser, submission.appraisal_timestamp)) {
throw new Error('Appraiser license expired at appraisal time');
}
const signatureValid = this.verifySignature(
submission.payload,
submission.signature,
appraiser.public_key,
);
if (!signatureValid) {
throw new Error('Invalid Ed25519 signature');
}
await this.updateNAVOracle(submission);
this.emitNAVOracleUpdated(submission);
}
}
```
#### 7.6 Transfer Hook Integration
The Transfer Hook reads the NAV oracle during the price-impact circuit-breaker check (CB-21). For each Module 2 transfer:
1. The on-chain price is calculated from the AMM pool reserves.
2. The current NAV is read from the NAVOracle PDA.
3. The deviation `(price - nav) / nav` is computed in basis points.
4. If the deviation exceeds `nav_deviation_max_bps`, the transfer is rejected with Error 6021 (`PriceImpactExceeded` / NAV variant).
5. If the NAV is stale beyond `nav_reappraisal_max_age_secs`, the mint is paused on the AMM. New transfers are rejected with Error 6021 (NAV stale variant).
#### 7.7 Specifications
| Parameter | Value |
| --------------------------- | ------------------------------------------------------------------------------------------ |
| Update cadence | Per tripartite reappraisal schedule (typically annual or quarterly) |
| Signature algorithm | Ed25519 |
| Verification | Solana Ed25519 precompile against registered appraiser public key |
| Deviation tolerance default | 22% (2200 bps) — aligned with the documented commercial-building fractionalization premium |
| Deviation tolerance range | Governance-set per mint |
| Staleness threshold default | Configured per mint via `nav_reappraisal_max_age_secs` |
| Module scope | Module 2 only |
| Fail-safe | Mint paused pending fresh appraisal |
***
### 8. Classification Oracle — Module 3
The Classification Oracle holds the most recent USGS Critical Minerals List classification, DOE Critical Materials Strategy status, and federal-action status for a Module 3 (CORECM) ST22 mint's basin asset.
#### 8.1 Module Scope
The Classification oracle is **Module 3-only**. It is the regulatory backbone for CORECM tokenization — Module 3 ST22 tokens are subject to federal-action sensitivity that does not apply to Module 1 or Module 2.
#### 8.2 Data Sources
| Source | What | Update Cadence |
| ------------------------------- | ------------------------------------------------------------------------------- | ------------------------------ |
| USGS Critical Minerals List | Mineral-classification status (rare earth, critical mineral category, etc.) | Annual list; emergency updates |
| DOE Critical Materials Strategy | Material-priority designation (high priority, near-critical, etc.) | Program announcements |
| Federal Register | Executive Orders, Section 232 proclamations, DPA Title III orders, court orders | Continuous |
| DOE program announcements | Critical Materials Strategy program changes, funding directives | Continuous |
| DOD Procurement Directives | Defense-procurement actions affecting strategic minerals | Continuous |
#### 8.3 Update Mechanism
The classification relay service polls the federal sources on a 5-minute cadence for federal-action detection (the most time-sensitive class) and a daily cadence for routine classification refreshes. New federal actions matching a basin or mineral class associated with an issued Module 3 mint trigger an automatic P0 incident under the Incident Response Playbook §13.
#### 8.4 Federal Frameworks Tracked
| Framework | Trigger Source | Typical Lead Time to Effect |
| ----------------------------------------------- | ----------------------------------------- | ------------------------------------------- |
| USGS Critical Minerals List | Annual list publication; emergency update | 30–60 days from publication |
| DOE Critical Materials Strategy | Program announcement | 30–90 days from announcement |
| Section 232 (Trade Expansion Act of 1962) | Presidential proclamation | Effective on signature; sometimes phased in |
| Defense Production Act Title III | Executive Order; DOD contract action | Effective immediately |
| Inflation Reduction Act critical-minerals | IRS guidance; Treasury rulemaking | 30–60 days from guidance |
| Executive Order 14017 (supply-chain resilience) | EO updates; agency reports | Variable |
| Energy Act of 2020 | DOE program updates | Variable |
#### 8.5 Attestation Payload
The Classification attestation is a multi-field on-chain account containing:
| Field | Description |
| ------------------------------- | ----------------------------------------------------------- |
| `mint` | Module 3 ST22 mint address |
| `usgs_critical_minerals_status` | USGS classification (e.g., `"critical_mineral_rare_earth"`) |
| `doe_critical_materials_status` | DOE designation (e.g., `"high_priority"`) |
| `section_232_applicable` | Boolean — whether Section 232 currently applies |
| `dpa_title_iii_applicable` | Boolean — whether DPA Title III currently applies |
| `federal_action_active` | Boolean — whether any federal-action freeze is active |
| `active_action_references` | Array of action references (e.g., `["EO-14118"]`) |
| `last_refresh_timestamp` | Unix timestamp of last update |
#### 8.6 Relay Service
The classification relay service maintains a continuous monitoring posture across federal sources. The service deduplicates events, classifies severity, and submits two distinct on-chain update types: routine classification refreshes (USGS / DOE status changes without federal action) and federal-action events (P0-severity, triggering automatic Control 42 coordination).
#### 8.7 Transfer Hook Integration
The Transfer Hook reads the Classification oracle on every Module 3 transfer:
1. **Freshness check** — if `classification_max_age_secs` is exceeded, transfers are flagged for enhanced compliance review (does not block transfers but is logged for operations review).
2. **Federal-action check** — if `federal_action_active` is true, Control 42 (regulatory freeze) is triggered automatically. Transfers are rejected with Error 6042 (`RegulatoryOverride` / `FederalActionFrozen` variant). The freeze is executed by Legal Counsel + 3-of-5 multi-signature within 60 minutes per the Incident Response Playbook §13.
#### 8.8 Federal-Action Freeze Coordination
When the relay detects a federal action targeting a basin or mineral class associated with an issued Module 3 mint, the following sequence executes:
```
1. Federal action detected (Federal Register, DOE, USGS, court order)
├─ Source verified
├─ Action reference captured (e.g., "EO-14118")
└─ Affected basin/mineral class matched against issued mint registry
2. P0 incident raised
├─ PagerDuty alert to operations
├─ Notification to Legal Counsel
└─ Notification to all multi-signature key holders
3. ClassificationOracle updated
├─ federal_action_active = true
├─ active_action_references += action reference
└─ federal_action_detected event emitted on chain
4. Pre-flight enforcement begins
├─ All new orders for affected mints rejected with Error 6042
└─ classification WebSocket channel emits federal_action_detected
5. Legal Counsel + 3-of-5 multi-signature execution (within 60-min SLA)
├─ Control 42 (regulatory freeze) activated on chain
├─ federal_action_freeze_applied event emitted
└─ All in-flight transfers revert at the Transfer Hook layer
6. Resolution
├─ Federal action expires, is rescinded, or variance/exemption obtained
├─ Legal Counsel + 3-of-5 multi-signature lift the freeze
├─ federal_action_active = false
└─ Trading resumes
```
#### 8.9 Specifications
| Parameter | Value |
| ------------------------------ | ----------------------------------------------------- |
| Federal-action polling cadence | 5 minutes |
| Routine classification refresh | Daily + emergency push |
| Staleness threshold | Configured per mint via `classification_max_age_secs` |
| Detection-to-freeze SLA | 60 minutes |
| Module scope | Module 3 only |
| Fail-safe (staleness) | Enhanced review on transfers; flagged for operations |
| Fail-safe (federal action) | Auto-coordinate Control 42 freeze |
***
### 9. On-Chain Account Schemas
#### 9.1 CustodyOracle
A single CustodyOracle PDA exists per ST22 mint. The account holds the most recent attestation, including the custodied balance, the on-chain token supply, the attestation slot and timestamp, Empire's Ed25519 public key, the Ed25519 signature of the most recent attestation, the validity flag, the discrepancy-detected flag, and the PDA bump.
PDA seeds: `[b"custody-oracle", mint]`. Cardinality: one per ST22 mint regardless of module.
#### 9.2 OFACOracle
A global singleton account holds the OFAC oracle state: the last refresh timestamp, the SHA-256 hash of the current SDN list, the entry count, the staleness threshold (`86,400` seconds = 24h default), and the halt threshold (`172,800` seconds = 48h default).
PDA seeds: `[b"ofac-oracle"]`. Cardinality: global singleton.
#### 9.3 AMLOracle
One AMLOracle PDA per wallet. The account holds the wallet, the aggregated risk score (0–100), the provider that generated the score (Chainalysis or TRM Labs), the score timestamp, the cache validity (`21,600` seconds = 6h default), and the PDA bump.
PDA seeds: `[b"aml-oracle", wallet]`. Cardinality: one per wallet.
#### 9.4 NAVOracle (Module 2 only)
One NAVOracle PDA per Module 2 mint. The account holds the most recent appraised NAV in USD-pegged stablecoin units, the appraiser identifier, the appraisal timestamp, the next-reappraisal target, the signature, the deviation tolerance, the staleness threshold, and the PDA bump.
PDA seeds: `[b"nav-oracle", mint]`. Cardinality: one per Module 2 ST22 mint.
#### 9.5 ClassificationOracle (Module 3 only)
One ClassificationOracle PDA per Module 3 mint. The account holds the USGS classification status, the DOE classification status, the Section 232 applicability flag, the DPA Title III applicability flag, the federal-action active flag, the array of active action references, the last refresh timestamp, the staleness threshold, and the PDA bump.
PDA seeds: `[b"classification-oracle", mint]`. Cardinality: one per Module 3 ST22 mint.
#### 9.6 PDA Registry
| PDA | Seeds | Cardinality | Module Scope |
| -------------------- | ---------------------------------- | --------------------- | ------------- |
| CustodyOracle | `[b"custody-oracle", mint]` | One per ST22 mint | All modules |
| OFACOracle | `[b"ofac-oracle"]` | Global singleton | All modules |
| AMLOracle | `[b"aml-oracle", wallet]` | One per wallet | All modules |
| NAVOracle | `[b"nav-oracle", mint]` | One per Module 2 mint | Module 2 only |
| ClassificationOracle | `[b"classification-oracle", mint]` | One per Module 3 mint | Module 3 only |
***
### 10. Relay Service Architecture
#### 10.1 Service Registry
| Service | Process | Restart Policy | Health Check | Module Scope |
| ---------------------- | ----------- | --------------------- | ----------------------------------------------- | ------------ |
| `custody-relay` | pm2 managed | Auto-restart on crash | `/health` endpoint + slot age check | All modules |
| `ofac-indexer` | pm2 managed | Auto-restart on crash | `/health` endpoint + staleness check | All modules |
| `aml-bridge` | pm2 managed | Auto-restart on crash | `/health` endpoint + provider status | All modules |
| `twap-consumer` | pm2 managed | Auto-restart on crash | `/health` endpoint + observation count | All modules |
| `edgar-pipeline` | pm2 managed | Auto-restart on crash | `/health` endpoint + last batch time | Module 1 |
| `nav-relay` | pm2 managed | Auto-restart on crash | `/health` endpoint + appraiser-channel status | Module 2 |
| `classification-relay` | pm2 managed | Auto-restart on crash | `/health` endpoint + federal-source poll status | Module 3 |
#### 10.2 Infrastructure
```
┌────────────────────────────────────────────────────┐
│ Kubernetes (EKS) │
├────────────────────────────────────────────────────┤
│ custody-relay │ Dedicated pod (critical) │
│ ofac-indexer │ Shared pod │
│ aml-bridge │ Shared pod │
│ twap-consumer │ Shared pod │
│ edgar-pipeline │ Shared pod (Module 1) │
│ nav-relay │ Shared pod (Module 2) │
│ classification-relay │ Dedicated pod (Module 3) │
├────────────────────────────────────────────────────┤
│ Helius RPC │ Primary Solana connection │
│ Triton RPC │ Failover connection │
│ MongoDB Atlas │ Cache + state storage │
│ Datadog Agent │ Metrics + logging │
│ PagerDuty │ Alert routing │
└────────────────────────────────────────────────────┘
```
The `classification-relay` service runs in a dedicated pod because federal-action detection has the strictest detection-to-freeze SLA (60 minutes) outside the custody fail-safe.
#### 10.3 Relay Key Management
| Service | Key Type | Storage | Rotation |
| -------------------- | ------------------------------------------------------ | -------------------------- | ----------------------------------------------- |
| custody-relay | Ed25519 (relay authority) | AWS KMS | Quarterly |
| ofac-indexer | Ed25519 (relay authority) | AWS KMS | Quarterly |
| aml-bridge | API keys (Chainalysis + TRM) | AWS Secrets Manager | Annual or on compromise |
| twap-consumer | Ed25519 (no write — read-only) | AWS KMS | Annual |
| edgar-pipeline | None (SEC API is public) | — | — |
| nav-relay | Ed25519 (relay authority) + appraiser pubkeys registry | AWS KMS + secured registry | Quarterly (relay); per-appraiser per tripartite |
| classification-relay | Ed25519 (relay authority) | AWS KMS | Quarterly |
***
### 11. Fail-Safe Cascade
When multiple oracles fail simultaneously, the cascade follows priority order. The custody fail-safe always dominates — when custody fails, the platform is in a compliance halt and downstream oracles become irrelevant for the affected mint.
```
CUSTODY ORACLE FAILS
└─ IMMEDIATE: All transfers halt (Error 6001 / 6002)
└─ Downstream: OFAC, AML, TWAP, EDGAR, NAV, Classification irrelevant
(no transfers executing to check against)
CUSTODY OK + OFAC ORACLE STALE > 48h
└─ All transfers halt (Error 6005)
└─ Downstream: AML, TWAP, EDGAR, NAV, Classification irrelevant
CUSTODY OK + OFAC OK + AML FAILS
└─ Use cached scores (< 6h). Reject if no score exists.
└─ Transfers continue for wallets with cached scores
└─ New wallets blocked until AML service restored
CUSTODY OK + OFAC OK + AML OK + TWAP FAILS > 5 min
└─ Circuit breaker disabled
└─ Transfers continue WITHOUT price-impact protection
└─ All other 41 controls still active
└─ P2 alert — engineering investigation
CUSTODY OK + OFAC OK + AML OK + TWAP OK + EDGAR FAILS (Module 1)
└─ Continue with last batch data
└─ IDOS scores flagged stale
└─ Control IV-08 uses last confirmed status
└─ P2 alert — operations review
CUSTODY OK + ... + NAV FAILS (Module 2)
└─ Affected Module 2 mint paused on the AMM
└─ New trades on the affected mint rejected (Error 6021 NAV-stale variant)
└─ Other Module 2 mints unaffected; Module 1 / 3 unaffected
└─ P1 alert — appraisal-cycle escalation
CUSTODY OK + ... + CLASSIFICATION ORACLE STALE (Module 3)
└─ Affected Module 3 mint enters enhanced review
└─ Transfers continue but flagged for operations
└─ P2 alert — operations review
CUSTODY OK + ... + FEDERAL ACTION DETECTED (Module 3)
└─ P0 incident raised
└─ Pre-flight rejection: Error 6042
└─ Control 42 freeze executed within 60-min SLA
└─ All transfers on affected mint halt at Transfer Hook
└─ Other Module 3 mints unaffected; Module 1 / 2 unaffected
```
***
### 12. Health Monitoring
#### 12.1 Monitoring Endpoints
| Endpoint | Checks | Alert On |
| ---------------------------- | ----------------------------------------------------------------------------------- | ------------------------------------------------ |
| `GET /health/custody` | Oracle freshness (slot age), signature validity, discrepancy status | Slot age > 5 |
| `GET /health/ofac` | SDN list age, entry count, refresh status | Age > 12h |
| `GET /health/aml` | Provider API availability, cache hit rate, average score latency | Timeout > 2s |
| `GET /health/twap` | Observation count, TWAP staleness, Pyth feed status | Observations < 60 |
| `GET /health/edgar` | Last RSS poll, last batch completion, pipeline status | Batch > 36h old |
| `GET /health/nav` | Per-mint NAV staleness, appraiser-channel status | Any mint > 50% of `nav_reappraisal_max_age_secs` |
| `GET /health/classification` | Per-mint classification staleness, federal-source poll status, federal-action queue | Federal-action queue depth > 0 |
#### 12.2 Datadog Dashboards
| Dashboard | Key Metrics |
| -------------------------------- | -------------------------------------------------------------------------------------------------------- |
| Oracle Overview | All seven oracle statuses, global health score |
| Custody Deep Dive | Attestation latency histogram, slot age trend, discrepancy counter (must always be 0) |
| OFAC and AML | SDN list freshness, AML query latency by provider, score-distribution histogram |
| TWAP and Circuit Breaker | TWAP versus spot price, observation count, breaker trigger count |
| EDGAR Pipeline (Module 1) | Filing processing latency, RSS poll success rate, batch completion times |
| NAV Oracle (Module 2) | Per-mint NAV staleness countdown, deviation distribution, appraisal-cycle calendar |
| Classification Oracle (Module 3) | Per-mint classification freshness, federal-action queue depth, P0 incident timeline, freeze-SLA tracking |
#### 12.3 Alert Thresholds
| Alert | Condition | Severity | Escalation |
| ---------------------------------- | ------------------------------------------ | -------- | --------------------------------------- |
| Custody oracle stale | Slot age > 5 | P0 | CTO + all multi-sig holders |
| Custody discrepancy | `discrepancy_detected == true` | P0 | CTO + Legal Counsel + Empire |
| OFAC stale > 24h | `last_refresh` > 24h ago | P1 | CTO + compliance |
| AML both providers down | Both Chainalysis + TRM timeout | P1 | CTO + DevOps |
| TWAP unavailable > 5 min | Observation count < 60 or feed stale | P2 | On-call engineer |
| EDGAR batch failed | Last batch > 36h ago | P2 | On-call engineer |
| NAV stale (Module 2) | Per-mint > `nav_reappraisal_max_age_secs` | P1 | Operations + issuer outreach |
| NAV deviation (Module 2) | Per-mint > `nav_deviation_max_bps` | P1 | Operations + issuer outreach |
| Classification stale (Module 3) | Per-mint > `classification_max_age_secs` | P2 | On-call engineer |
| Federal action detected (Module 3) | `federal_action_active == true` (any mint) | P0 | CTO + Legal Counsel + multi-sig holders |
| Relay service crash | pm2 status ≠ online | P2 | On-call engineer |
| RPC failover triggered | Primary Helius → Triton backup | P2 | DevOps |
***
### 13. Failure Injection Testing
Chaos testing validates that fail-safes work correctly under degraded conditions.
#### 13.1 Test Scenarios
| Test | Method | Expected Behavior | Frequency | Module Scope |
| ------------------------------- | ----------------------------------------- | ------------------------------------------------------ | --------- | ------------ |
| Custody relay killed | `pm2 stop custody-relay` | All transfers halt after 1 slot stale. Error 6002. | Monthly | All modules |
| Empire API returns 500 | Mock error response | Relay retries 3x, then stale. Transfers halt. | Monthly | All modules |
| False custody discrepancy | Inject `custodied_balance ≠ token_supply` | Error 6001 on all transfers. P0 alert. | Quarterly | All modules |
| OFAC indexer killed | `pm2 stop ofac-indexer` | Cached SDN list used < 24h. Halt > 48h. | Monthly | All modules |
| Both AML providers timeout | Network partition on AML bridge | Cached scores used < 6h. New wallets blocked. | Monthly | All modules |
| Pyth feed stale | Mock stale Pyth data | Circuit breaker disabled after 5 min. P2 alert. | Monthly | All modules |
| EDGAR RSS down | Block SEC RSS endpoint | Last batch used. IDOS flagged stale. P2 alert. | Monthly | Module 1 |
| RPC failover | Block Helius endpoint | Automatic failover to Triton. P2 alert. | Monthly | All modules |
| All oracles fail simultaneously | Kill all relay services | All transfers halt (custody fail-safe dominates). P0. | Quarterly | All modules |
| NAV relay killed | `pm2 stop nav-relay` | Affected Module 2 mints pause when staleness exceeded. | Monthly | Module 2 |
| NAV deviation injection | Inject NAV value triggering deviation | Affected mint paused. Error 6021. P1 alert. | Quarterly | Module 2 |
| Classification relay killed | `pm2 stop classification-relay` | Module 3 mints enter enhanced review on staleness. P2. | Monthly | Module 3 |
| Federal-action injection | Inject federal-action event | P0 incident raised. Control 42 freeze within 60 min. | Quarterly | Module 3 |
#### 13.2 Running Chaos Tests
The chaos-test runbook is documented in the platform's internal operations repository. Module-specific scenarios are gated to environments with active Module 2 or Module 3 mints (devnet always; mainnet via specific test mints).
***
### 14. Key Rotation
#### 14.1 Rotation Schedule
| Key | Rotation | Process |
| ----------------------------------------------------------------- | ------------------------ | ----------------------------------------------------------------------------------- |
| Empire Ed25519 (custody attestation) | Empire-managed per §17A | Empire rotates → new pubkey registered on chain via multi-sig |
| Relay authority keys (custody-relay, ofac-indexer, twap-consumer) | Quarterly | New key generated in AWS KMS → governance proposal → 48h timelock → on-chain update |
| Chainalysis API key | Annual | Rotate in Secrets Manager → restart aml-bridge |
| TRM Labs API key | Annual | Rotate in Secrets Manager → restart aml-bridge |
| Module 2 appraiser keys | Per appraiser engagement | New appraiser key registered when added to tripartite registry |
| Module 2 NAV-relay authority | Quarterly | Same as other relay authority keys |
| Module 3 classification-relay authority | Quarterly | Same as other relay authority keys |
#### 14.2 Empire Key Rotation
```
1. Empire generates new Ed25519 keypair (HSM-backed)
2. Empire communicates new public key to the platform via secure channel
3. Platform creates governance proposal to update empire_pubkey on every CustodyOracle
4. 48-hour timelock
5. 5-of-9 multi-signature executes on-chain update
6. Old key deauthorized in same transaction
7. Verification: next attestation signed with new key, verified on chain
```
#### 14.3 Module 2 Appraiser Key Rotation
When a new appraiser is engaged or an appraiser's license is renewed:
```
1. Appraiser provides new public key plus current license documentation
2. Issuer-Empire-Platform tripartite reviews and signs off
3. NAV relay registers the new appraiser public key in the authorized registry
4. Old appraiser public key remains valid for verification of historical appraisals
but cannot sign new attestations
```
***
### 15. Troubleshooting
#### 15.1 Common Issues
| Symptom | Diagnosis | Resolution |
| ------------------------------------------- | ----------------------------------------- | -------------------------------------------------------------------------------------------------- |
| All transfers failing with 6002 | Custody oracle stale | Check `pm2 status custody-relay`. Verify Helius RPC. Restart relay. |
| Transfers failing with 6005 | OFAC oracle stale > 48h | Check `pm2 status ofac-indexer`. Verify Treasury API access. Restart indexer. |
| New wallets rejected with 6006 | AML providers unreachable | Check Chainalysis + TRM API keys. Verify network. Restart aml-bridge. |
| Circuit breaker stuck active | TWAP stale or miscalculated | Check Pyth feed status. Verify observation count ≥ 60. Restart twap-consumer. |
| Module 1 issuer tokens halted unexpectedly | Control IV-08 detected enforcement action | Check EDGAR pipeline logs. Verify 8-K filing. May be correct behavior. |
| AML scores all returning 0 | API key expired | Rotate API keys in AWS Secrets Manager. Restart aml-bridge. |
| Oracle accounts not found | PDAs not initialized | Run oracle-initialization for the affected mint per the Deployment Guide. |
| Module 2 mint paused on AMM with Error 6021 | NAV deviation exceeded or NAV stale | Check `pm2 status nav-relay`. Verify appraiser-channel health. Confirm next reappraisal scheduled. |
| Module 2 NAV oracle missing data | NAV PDA not initialized at mint creation | Re-run NAV oracle initialization for the affected mint. |
| Module 3 mint frozen with Error 6042 | Federal action detected | Verify in `classification-relay` logs. Confirm action reference. Coordinate with Legal Counsel. |
| Module 3 mint flagged for enhanced review | Classification stale | Check `pm2 status classification-relay`. Verify federal-source feeds operational. |
#### 15.2 Diagnostic Commands
```bash
# Check custody oracle freshness
anchor account oracle-aggregator CustodyOracle \
--provider.cluster mainnet | jq '.attestationSlot'
# Compare with: solana slot
# Check OFAC oracle age
anchor account oracle-aggregator OFACOracle \
--provider.cluster mainnet | jq '.lastRefresh'
# Check AML score for a wallet
curl https://api.cedex.market/v1/oracle/aml/9aB2xY... | jq
# Module 2: Check NAV oracle for a mint
curl https://api.cedex.market/v1/oracle/{mint}/nav | jq
# Module 3: Check Classification oracle for a mint
curl https://api.cedex.market/v1/oracle/{mint}/classification | jq
# Check all oracle health
curl https://api.cedex.market/v1/health | jq '.oracle_status'
# View relay service logs
pm2 logs custody-relay --lines 100
pm2 logs ofac-indexer --lines 100
pm2 logs aml-bridge --lines 100
pm2 logs nav-relay --lines 100
pm2 logs classification-relay --lines 100
```
***
### Related Documentation
* **Smart Contract Reference** — Oracle account schemas and update instructions.
* **Transfer Hook Reference** — Standalone reference for the 42 controls including module-aware extensions.
* **Security Model** — Oracle attack-surface analysis and fail-safe design; module-specific threat surfaces.
* **Deployment Guide** — Oracle relay service deployment, including Module 2 NAV oracle and Module 3 Classification oracle initialization.
* **Incident Response Playbook** — P0 through P3 runbooks; Module 3 federal-action freeze runbook (§13).
* **Empire Stock Transfer Integration** — Custody architecture, Ed25519 attestation lifecycle, MSF, and module-aware custody coverage.
* **CEDEX API Reference** — Public oracle endpoints (`/oracle/{mint}/custody`, `/oracle/{mint}/nav`, `/oracle/{mint}/classification`).
* **Issuer Onboarding Guide** — Module-specific oracle initialization at mint creation.
* **Network Configuration** — Oracle PDAs and oracle-relay endpoints.
***
*RWA Tokens · Oracle Integration Guide · Groovy Company, Inc.*
# Smart Contract Reference
## Smart Contract Reference
**On-Chain Program Documentation · Solana Mainnet-Beta · Module-Aware Throughout**
Reference document for institutional reviewers, auditors, compliance officers, and integrators evaluating the platform's on-chain programs. This page documents what each program does, how the programs interact, what state they maintain, what events they emit, and how they enforce the 42 Transfer Hook controls — with explicit Module 1 (Equities), Module 2 (Real Estate), and Module 3 (CORECM — Carbon Ore, Rare Earth, and Critical Minerals) behavior surfaced in every program section.
The platform is operated by Groovy Company, Inc. The trading venue is CEDEX. The qualified-custody and onboarding anchor is Empire Stock Transfer. The same five programs serve all three modules at the structural level; module-specific behavior arises through module-aware oracles, additional SecurityConfig fields, and module-aware Transfer Hook checks documented inline below.
> This document describes **what** each program does, **why** each design decision exists, and **how each behavior is verified across modules**. Specific instruction signatures, account schemas, function bodies, and code-level details are maintained in the platform's internal program documentation and audit reports, accessible to authorized auditors under non-disclosure agreement.
***
### Table of Contents
1. Program Registry
2. Transfer Hook Program
3. AMM Program
4. Liquidity Pool Program
5. Governance Program
6. Oracle Aggregator Program
7. PDA Registry (All Programs)
8. Event Registry (All Programs)
9. State Machines
10. Upgrade Authority Model
11. Cross-Program Invocation Map
12. Deployment Verification
13. Module-Aware Program Behavior
***
### 1. Program Registry
The platform deploys five on-chain programs on Solana Mainnet-Beta. All five are written in Rust against the Anchor framework, audited by independent firms, and verified through Certora formal-verification specifications.
| Program | Purpose | Module Scope | Upgrade Authority | Audit |
| --------------------- | -------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | ---------------------------------------- | ------------------------------------ |
| **Transfer Hook** | Enforces the 42 sequential security controls on every ST22 token transfer. The foundational security layer. | All modules — module-aware checks for Module 2 (NAV) and Module 3 (Classification) | 5-of-9 multi-signature plus 24h timelock | Certora plus Quantstamp plus Halborn |
| **AMM** | Constant Product Market Maker engine. Native SPL Token-2022 Transfer Hook support. | All modules — same fee distribution; per-mint pool isolation | 5-of-9 multi-signature plus 24h timelock | Certora plus OtterSec |
| **Liquidity Pool** | Global Unified CEDEX Liquidity Pool. LP tokens burned at initialization. | All modules — single pool aggregating all module activity | **None — immutable program** | Certora |
| **Governance** | On-chain proposal and voting system for adjustable parameters. | All modules — same governance for module-shared and module-specific parameters | 3-of-5 multi-signature | Halborn |
| **Oracle Aggregator** | Aggregates and validates oracle data from custody, OFAC, AML, NAV (Module 2), and Classification (Module 3) sources. | All modules — module-specific oracles initialized per mint | 5-of-9 multi-signature plus 24h timelock | Quantstamp |
Production program addresses are published in the Network Configuration document at mainnet deployment (Q3 2026). Until that point, this document refers to programs by descriptive name rather than address.
The five programs are deployed in dependency order: Transfer Hook (no dependencies) → Oracle Aggregator → Liquidity Pool → AMM → Governance. The deployment sequence is identical regardless of how many modules are in production; module-specific oracle initialization happens per-mint at issuance time, not at platform deployment.
***
### 2. Transfer Hook Program
**Purpose.** Enforces 42 sequential security controls on every ST22 token transfer through SPL Token-2022 cross-program invocation. The foundational security layer. All other programs depend on this.
**Why this program is special.** SPL Token-2022 introduced the Transfer Hook extension, which lets a token's mint specify a program that must approve every transfer. Once the hook is attached, it cannot be removed. This is what makes 100% compliance enforcement possible — every transfer of a Module 1, Module 2, or Module 3 ST22 token must pass all 42 controls; there is no path that bypasses them.
**Module relationship.** A single Transfer Hook deployment serves Module 1, Module 2, and Module 3 ST22 mints uniformly. Per-mint configuration in the SecurityConfig PDA carries module-specific parameters; module-aware oracle reads happen at runtime based on which oracles exist for the affected mint.
#### 2.1 Program Responsibilities
The Transfer Hook program performs three distinct functions:
| Function | Frequency | Trigger | Module Scope |
| ---------------------------------------- | ------------------------------------------------------- | ----------------------------------------- | ------------------------------------------------------------ |
| **Hook execution** | Every ST22 transfer | SPL Token-2022 cross-program invocation | All modules — same execution path |
| **Per-mint configuration management** | Once at mint creation; periodic parameter updates | Admin instruction (multi-signature gated) | All modules — module-specific fields populated per mint type |
| **Per-investor holding-period tracking** | Once at token delivery; lock state queried per transfer | Empire Stock Transfer onboarding | All modules — same Reg D / Reg S / Reg CF regimes |
#### 2.2 Per-Mint Configuration State (SecurityConfig)
For each ST22 mint, the Transfer Hook program maintains a SecurityConfig state account. The same account schema serves all three modules; module-specific extensions sit in dedicated fields that are populated at mint creation based on module type.
**Cross-module fields (always populated):**
* The mint address and the configuration version.
* The maximum wallet concentration (default 4.99%, governance-adjustable between 1.00% and 9.99%).
* The circuit breaker threshold and cooldown duration.
* The price-impact maximum versus TWAP.
* The TWAP window seconds and minimum observations.
* The holding-period configuration (Reg D 6 months, Reg S 12 months, Reg CF 12 months — jurisdiction-specific durations are immutable program constants).
* The volume tracker (24-hour rolling buckets for spike detection).
* A blacklist of permanently-blocked wallets (OFAC SDN matches).
* The pause state (set true by Control 42 regulatory freeze).
**Module 1 (Equities) — no additional fields.** Standard SecurityConfig with default parameters. EDGAR-pipeline issuer-eligibility intelligence flows through Layer 9 IDOS off chain; the hook reads only the issuer-eligibility flag synthesized into the existing Control IV-08 path.
**Module 2 (Real Estate) — additional fields:**
* `nav_deviation_max_bps` — maximum allowed deviation between on-chain price and the most recent appraised NAV.
* `nav_reappraisal_max_age_secs` — maximum age of a NAV appraisal before the mint is paused on the AMM.
* `nav_circuit_breaker_enabled` — flag enabling the NAV-deviation circuit breaker.
For Module 2 mints, the wallet-concentration cap may be issuer-configured up to 9.99% (single-asset real-estate offerings often have natural concentration patterns where a single institutional investor holds a significant share).
**Module 3 (CORECM) — additional fields:**
* `classification_max_age_secs` — maximum age of the Classification oracle before staleness review.
* `federal_action_freeze_enabled` — flag enabling automatic Control 42 freeze coordination on detected federal action.
The configuration account is per-mint, not global. A pause on one ST22 mint does not affect other mints unless the pause is platform-wide. A federal-action freeze on one Module 3 mint does not affect other Module 3 mints unless the action references multiple basins.
#### 2.3 Per-Investor Holding Period State
For each investor-mint pair, the Transfer Hook program maintains a HoldingPeriodAccount. The schema is identical across modules:
* The beneficiary wallet address and mint address.
* The purchase timestamp (set by the Solana runtime clock at delivery — never by user input).
* The jurisdiction flag (US, Non-US, or Reg CF).
* The holding period in seconds (15,778,800 for US accredited under Reg D Rule 144; 31,536,000 for non-US under Reg S; 31,536,000 for US retail under Reg CF).
* The lock status.
The holding period seconds are hard-coded program constants. Governance cannot reduce them below the statutory minimum. The purchase timestamp is immutable post-creation and is verified by the Solana runtime clock — it cannot be backdated by any party. The same regime applies to Module 1, Module 2, and Module 3 investors.
#### 2.4 The 42 Controls
The Transfer Hook program executes 42 sequential controls on every transfer. The controls are documented in the Compliance Integration Guide §3 and consolidated in the Transfer Hook Reference. A high-level summary with module-aware annotations:
| Control Group | Range | Function | Module-Aware Behavior |
| ----------------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- |
| Custody verification | CV-01 through CV-06 | Verify Empire's per-block 1:1 attestation | Same across all modules; CV-05 verifies the asset identifier (CUSIP for Module 1, property ID for Module 2, basin ID for Module 3) |
| Investor verification | IV-07 through IV-14 | Verify KYC, accreditation (Reg D / Reg S / Reg CF), AML, identity, jurisdiction, age, classification, expiry | Module 3 requires enhanced KYC depth (beneficial ownership to ultimate owner) |
| Position limits | PL-15 through PL-19 | Wallet whitelist, concentration, velocity, clustering, cumulative position | Module 2 concentration cap (PL-16) may be issuer-configured up to 9.99% |
| Circuit breakers | CB-20 through CB-23 | Price halt, price impact, velocity, oracle failure | **Module 2: CB-21 also enforces NAV-deviation breaker.** Module 3: CB-23 also pauses on Classification oracle failure. |
| Holding period | HP-24 through HP-29 | Reg D / Reg S / Reg CF holding-period enforcement | Same across all modules |
| Sanctions compliance | SC-30 through SC-34 | Three-layer OFAC screening, continuous re-screening, blacklist | Same across all modules; Module 3 incidents may trigger coordinated regulatory action |
| Protective conversion | PC-35 through PC-38 | Issuer bankruptcy, SEC enforcement, Empire service loss, tripartite breach | Module 3 adds an implicit federal-action trigger via PC-37 (Empire discretion) |
| Record-keeping and governance | RK-39 through REG-42 | Audit trail, hash-chain integrity, controlled migration, regulatory freeze | **Module 3: REG-42 has automatic federal-action freeze coordination** through the Classification oracle |
#### 2.5 Hook Execution Flow
The hook executes controls in two phases. The execution structure is identical across modules; the difference is which oracles the parallel-phase controls read.
```
SEQUENTIAL (critical path — each must pass before next is evaluated):
CV-01 through CV-06 → Custody verification (Ed25519 attestation, 1:1 ratio)
IV-07 through IV-14 → Investor eligibility
HP-24 → Holding period
PARALLEL (remaining controls execute together; any failure reverts atomically):
PL-15 through PL-19 → Position limits
CB-20 through CB-23 → Circuit breakers
(Module 2: + NAV-deviation read)
(Module 3: + Classification staleness read)
SC-30 through SC-34 → Sanctions compliance
PC-35 through PC-38 → Protective conversion
RK-39 through REG-42 → Audit trail and governance
(Module 3: + Classification federal-action read)
EMIT:
TransferValidated event with all 42 controls' results
```
If any control fails, the entire transfer reverts — the Solana runtime guarantees atomicity, so no state changes are persisted on a partially-evaluated transfer.
The hook is **not callable directly**. The SPL Token-2022 runtime is the only caller; any direct invocation is rejected.
#### 2.6 Adjustable Parameters and Hard-Coded Bounds
The same parameter table applies to Module 1, Module 2, and Module 3 mints. Module-specific parameters (NAV deviation, classification age) follow the same governance bounds discipline.
| Parameter | Minimum | Maximum | Default | Immutable? | Module Scope |
| ------------------------------- | ---------- | ------------ | --------------------------------- | ----------------------------------- | ----------------------------------------- |
| Maximum wallet concentration | 100 (1%) | 999 (9.99%) | 499 (4.99%) | No | All modules; Module 2 may use up to 9.99% |
| Circuit breaker threshold | 1000 (10%) | 5000 (50%) | 3000 (30%) | No | All modules |
| Circuit breaker cooldown | 3600 (1h) | 259200 (72h) | 86400 (24h) | No | All modules |
| Price impact maximum (vs TWAP) | 100 (1%) | 500 (5%) | 200 (2%) | No | All modules |
| TWAP window | 900 (15m) | 3600 (1h) | 1800 (30m) | No | All modules |
| TWAP minimum observations | — | — | 60 | **Yes** | All modules |
| Holding period (Reg D) | — | — | 15,778,800 (6 months) | **Yes** | All modules |
| Holding period (Reg S, Reg CF) | — | — | 31,536,000 (12 months) | **Yes** | All modules |
| `nav_deviation_max_bps` | Per mint | Per mint | Per mint (typically 2200 = 22%) | No | **Module 2 only** |
| `nav_reappraisal_max_age_secs` | Per mint | Per mint | Per mint (per tripartite cadence) | No | **Module 2 only** |
| `classification_max_age_secs` | Per mint | Per mint | Per mint (typically 86400 = 24h) | No | **Module 3 only** |
| `federal_action_freeze_enabled` | — | — | true | No (governance-toggleable per mint) | **Module 3 only** |
Parameters marked "Immutable" are hard-coded program constants. Governance cannot adjust them through any procedure, including emergency action. This is verified by Certora invariant E.4.
#### 2.7 Error Codes
The same error code map applies regardless of module. Module 2 NAV-deviation failures map to error 6021 (`PriceImpactExceeded`) with an `nav_variant` flag; Module 3 federal-action freezes map to error 6042 (`RegulatoryOverride`) with a `federal_action` source flag. The Transfer Hook Reference §Errors and the CEDEX API Reference §8 enumerate the module-specific variants.
| Code | Name | Category | Module Scope |
| ---- | -------------------------- | --------------- | ----------------------------------------------------- |
| 6001 | Custody discrepancy | Custody | All modules |
| 6002 | Custody oracle unavailable | Custody | All modules |
| 6003 | Sender sanctioned | Sanctions | All modules |
| 6004 | Receiver sanctioned | Sanctions | All modules |
| 6005 | OFAC oracle stale | Sanctions | All modules |
| 6006 | AML high risk | AML | All modules |
| 6007 | Invalid signer | CEI | All modules |
| 6020 | Wallet limit exceeded | Position | All modules |
| 6021 | Price impact exceeded | Circuit Breaker | All modules; Module 2 includes NAV-deviation variant |
| 6022 | Velocity exceeded | Position | All modules |
| 6023 | Cross-wallet detected | Position | All modules |
| 6024 | Tokens locked | Holding Period | All modules; Reg D / Reg S / Reg CF variants |
| 6036 | Global circuit breaker | Emergency | All modules |
| 6037 | Daily sell limit exceeded | Volume | All modules |
| 6038 | Custody discrepancy halt | Emergency | All modules |
| 6039 | OFAC emergency block | Emergency | All modules |
| 6040 | Oracle consensus fail | Emergency | All modules |
| 6041 | Controlled migration | Governance | All modules |
| 6042 | Regulatory override | Regulatory | All modules; Module 3 includes federal-action variant |
#### 2.8 Compute Budget
The hook logic itself uses approximately 3,500 compute units. Total transfer cost varies slightly by module due to additional oracle reads:
| Module | Additional Oracle Reads | Total Compute (approx.) |
| -------- | ---------------------------------------------------- | ----------------------- |
| Module 1 | None beyond standard set | \~800,000 CU |
| Module 2 | NAVOracle PDA read + deviation check | \~820,000 CU |
| Module 3 | ClassificationOracle PDA read + federal-action check | \~830,000 CU |
All three figures fit well within Solana's per-transaction compute budget.
***
### 3. AMM Program
**Purpose.** Constant Product Market Maker engine with native SPL Token-2022 Transfer Hook support. Every swap triggers all 42 Transfer Hook controls. This is the structural reason external DEXes (Raydium, Orca, Jupiter) cannot serve ST22 tokens — they call the original SPL Token Program, which bypasses the hook entirely.
**Module relationship.** The same AMM program serves all three modules. Each ST22 mint — Module 1, 2, or 3 — gets its own pool with the same constant-product mechanics. The fee distribution is identical (2% / 1.5% / 1.06% / 0.44%). The structural difference between modules is in pool dynamics: Module 2 pools have the additional NAV-deviation constraint imposed by the Transfer Hook; Module 3 pools have the additional federal-action freeze possibility.
#### 3.1 Pool Creation
Pools are protocol-controlled. Only the platform can initialize trading pools for ST22 tokens. Third parties cannot create pools. This applies identically to Module 1, Module 2, and Module 3 mints.
When a pool is initialized:
1. The mint is verified to have the platform's Transfer Hook extension permanently attached.
2. The pool is initialized with the constant-product invariant `k = initial_sol × initial_tokens`.
3. LP tokens are minted and immediately burned. The LP mint authority is set to `None`. No path to reconstitute the LP supply exists.
4. The pool is linked to the Global Unified CEDEX Liquidity Pool for fee deposit routing.
5. **For Module 2 pools:** the AMM verifies the mint has a configured NAVOracle PDA before pool initialization is permitted.
6. **For Module 3 pools:** the AMM verifies the mint has a configured ClassificationOracle PDA before pool initialization is permitted.
#### 3.2 Swap Execution
Every swap follows the same sequence regardless of module. Module-specific behavior surfaces inside the Transfer Hook invocation in step 3.
```
1. Calculate swap output using the constant-product formula
2. Check price impact versus TWAP — reject if above max_price_impact_bps (Control CB-21)
3. Execute Token-2022 transfer (triggers Transfer Hook → all 42 controls)
├─ Module 1 path: standard 42 controls
├─ Module 2 path: standard 42 + NAV-deviation read in CB-21
└─ Module 3 path: standard 42 + Classification reads in CV-04 and REG-42
4. If hook passes → update pool reserves, distribute fees
5. If hook fails → entire transaction reverts atomically (zero state changes)
6. Emit SwapExecuted event with full fee breakdown
```
For a Module 2 mint paused due to NAV-deviation breach, swaps are rejected at step 3 with Error 6021 (NAV variant). For a Module 3 mint frozen by federal action, swaps are rejected at step 3 with Error 6042 (federal-action variant). Other mints — including other Module 2 or Module 3 mints not subject to the same condition — are unaffected.
#### 3.3 Constant-Product Mechanics
The CPMM uses the standard constant-product invariant: `x × y = k`. The 5% fee is deducted from the input amount before the invariant calculation. Every swap increases `k` by the fee amount — this is the structural property that makes the pool's value monotonically non-decreasing. This property holds identically for Module 1, Module 2, and Module 3 pools.
| Operation | Rounding | Rationale |
| --------------------------------- | ---------------- | ---------------------------------------- |
| Output amount | Floor (truncate) | Pool never overpays — `k` only increases |
| Input amount (exact-output swaps) | Ceiling | Pool never under-receives |
| Fee calculation | Floor | Conservative accounting |
All arithmetic uses 128-bit unsigned integers with checked-math. Overflow returns Error 7004 rather than wrapping.
#### 3.4 Fee Distribution
Every successful swap distributes the 5% protocol fee across four destinations. Fee distribution is identical across modules:
| Destination | Allocation | Purpose | Module Scope |
| ----------------------------------- | --------------- | -------------------------------------------- | ------------------------------------ |
| Global Unified CEDEX Liquidity Pool | 0.44% (44 bps) | Permanently locked; pool grows monotonically | All modules — single shared pool |
| Issuer treasury | 2.00% (200 bps) | Issuer's revenue share | All modules — per-mint issuer wallet |
| GROO staking pool | 1.50% (150 bps) | Staking reward distribution | All modules — single shared pool |
| Protocol operations | 1.06% (106 bps) | Platform operations | All modules — single platform wallet |
The four allocations sum to 5.00%. This is a program invariant: the bps values must add to the total fee bps. Any configuration violating this is rejected at the program level.
#### 3.5 Error Codes
Same error map across modules. Module 2 and Module 3 mints can additionally surface Transfer Hook errors that abort swap execution at step 3 of the sequence.
| Code | Name | Trigger |
| ---- | -------------------------- | ----------------------------------------------- |
| 7001 | Insufficient liquidity | Pool reserves too low for swap |
| 7002 | Slippage exceeded | Output below minimum amount out |
| 7003 | Pool not active | Pool paused or not initialized |
| 7004 | Overflow | 128-bit arithmetic overflow |
| 7005 | Zero division | Division by zero in CPMM calculation |
| 7006 | Invalid mint | Mint missing Transfer Hook extension |
| 7007 | Unauthorized pool creation | Non-protocol authority attempted initialization |
| 7008 | Pool already exists | Pool PDA already initialized for mint |
| 7009 | LP not burned | LP tokens not burned (should never occur) |
| 7010 | Fee mismatch | Fee config bps do not sum to total |
***
### 4. Liquidity Pool Program
**Purpose.** Operates the Global Unified CEDEX Liquidity Pool — a single protocol-owned capital reserve serving all ST22 issuers across all three modules. LP tokens are burned at initialization. **The program has no upgrade authority — it is permanently immutable.**
**Module relationship.** The Global Pool is module-agnostic by design. A Module 1 swap, a Module 2 swap, and a Module 3 swap all route the same 0.44% fee allocation to the same Global Pool. Pool reserves grow monotonically across all module activity combined. There is no separate per-module pool.
#### 4.1 Initialization
The Global Pool is initialized once, at platform deployment. Initialization:
1. Creates the GlobalPool state account (PDA: `[b"global-pool"]`).
2. Creates the SOL reserve vault.
3. Creates the LP mint.
4. Burns all LP tokens by setting the LP mint authority to `None`.
5. Records the initialization timestamp and seed amount.
After initialization, **no instruction in any program can withdraw SOL from the pool.** The withdrawal function does not exist in the program code. This is verified by Certora invariant E.3 as a mathematical proof (not a test).
#### 4.2 Fee Deposits
The only function that mutates the Global Pool's state is `deposit_fee`, which is callable only via cross-program invocation from the AMM program. Every successful swap — Module 1, Module 2, or Module 3 — automatically routes the 0.44% fee allocation to the Global Pool through this single instruction.
Direct external calls to `deposit_fee` are rejected — the AMM program PDA must be the signer.
#### 4.3 Immutability
The Liquidity Pool program's upgrade authority is removed at deployment via the Solana CLI `--final` flag. Once removed, the upgrade authority cannot be restored. No combination of multi-signature votes, governance proposals, or legal orders can modify the program. This is the architectural foundation of the Global Pool non-extractability guarantee. The immutability applies regardless of module activity — even adding a hypothetical Module 4 in the future would not change the Liquidity Pool program.
#### 4.4 Certora Invariant E.3 — Global Pool Non-Extractability
Stated formally: for every program state `s` and every instruction `i`, executing `i` against `s` cannot produce a successor state `s'` where the Global Pool balance is less than the original. The Certora Prover verifies this invariant against the deployed bytecode of every program in the workspace. The proof is published with the audit reports.
The invariant covers all module activity: Module 1 fee deposits, Module 2 fee deposits, and Module 3 fee deposits all monotonically increase the pool balance.
#### 4.5 Cross-Module Pool Behavior
The Global Pool serves all three modules identically:
* A swap of a Module 1 ST22 token, a Module 2 real-estate ST22 token, or a Module 3 CORECM ST22 token routes the same 0.44% fee allocation to the same pool.
* The pool balance reflects fees aggregated across all module activity.
* A federal-action freeze on a single Module 3 mint does not affect the Global Pool — the pool continues receiving fees from other Module 3 mints, all Module 1 mints, and all Module 2 mints.
* A NAV-deviation pause on a single Module 2 mint does not affect the Global Pool — the pool continues receiving fees from other Module 2 mints, all Module 1 mints, and all Module 3 mints.
* The pool's growth rate over time reflects the combined trading activity of all three modules.
***
### 5. Governance Program
**Purpose.** On-chain proposal and voting system for adjustable protocol parameters. Governance can adjust parameter values within hard-coded bounds and execute program upgrades — but the 42 Transfer Hook controls themselves cannot be weakened by any governance procedure. This applies uniformly to Module 1, Module 2, and Module 3.
**Module relationship.** Governance proposals can target cross-module parameters (TWAP window, circuit breaker threshold) or module-specific parameters (Module 2 NAV deviation tolerance, Module 3 classification age). The governance program does not segregate proposals by module — a single proposal can affect a single mint, multiple mints across modules, or all mints platform-wide depending on the target parameter.
#### 5.1 Proposal Types
| Proposal Type | Voting Threshold | Timelock | Cancellation | Module Scope |
| -------------------- | ----------------------------------------- | ---------------- | -------------------- | ---------------------------------------------------------- |
| Parameter Adjustment | Simple majority | 48 hours | 2-of-5 during window | All modules; can target single mint or all mints |
| Program Upgrade | 66.67% supermajority | 24 hours | 2-of-5 during window | All modules — programs serve all modules uniformly |
| Emergency Action | 3-of-5 multi-signature plus Legal Counsel | None — immediate | None | All modules; Module 3 federal-action freezes use this path |
#### 5.2 Parameter Adjustment Procedure
1. A governance participant creates a proposal specifying the target parameter, the new value, and a description.
2. The voting period opens for at least 48 hours.
3. Vote tallies are recorded on chain.
4. If passed (simple majority), the proposal enters a 48-hour timelock.
5. During the timelock window, 2-of-5 of the parameter-authority multi-signature can cancel the proposal.
6. After timelock expiry, the 3-of-5 parameter-authority multi-signature executes the parameter update on chain.
Parameters cannot be set outside their hard-coded bounds. The program rejects any update that would push a parameter outside its `min`–`max` range, regardless of how the proposal was passed. Module-specific parameters (Module 2 `nav_deviation_max_bps`, Module 3 `classification_max_age_secs`) follow the same governance discipline.
#### 5.3 Program Upgrade Procedure
The same procedure as parameter adjustment, with three additional requirements:
1. The voting threshold is 66.67% supermajority, not simple majority.
2. The new program bytecode hash must be attested as matching an audited release.
3. Certora formal verification must pass on the new bytecode before execution.
4. The 5-of-9 upgrade-authority multi-signature (not the 3-of-5 parameter-authority) executes the upgrade.
A program upgrade affects all three modules simultaneously — a Transfer Hook upgrade applies to Module 1, Module 2, and Module 3 ST22 mints uniformly. There is no module-specific program upgrade; if module behavior needs to change independently, the change happens through module-specific parameters or new oracle behavior, not through program forking.
#### 5.4 Emergency Action
Emergency actions — primarily Control 42 regulatory freezes — bypass the timelock. Emergency authority requires:
* Legal Counsel authorization (documented in the platform's compliance system).
* 3-of-5 emergency-authority multi-signature.
Emergency actions are limited to specific operations defined in the program code: regulatory freezes (Control 42), oracle key rotations under emergency conditions, and circuit-breaker overrides. Emergency authority cannot upgrade programs or adjust parameters outside their normal governance scope.
**Module 3 federal-action freezes use this path.** When the platform's Classification oracle detects a federal action against a basin or mineral class associated with an issued Module 3 mint, the Incident Response Playbook §13 procedure executes Control 42 through this emergency-action channel — Legal Counsel authorization plus 3-of-5 multi-signature within a 60-minute SLA from detection.
#### 5.5 Proposal State Machine
```
CREATED ──► ACTIVE (voting period: at least 48h)
│
├─ Votes meet threshold → PASSED
├─ Votes below threshold → FAILED
├─ Proposer cancels → CANCELLED
│
▼
PASSED ──► TIMELOCK PENDING
│ Parameter Adjustment: 48h
│ Program Upgrade: 24h
│ Emergency Action: 0h (immediate)
│
├─ 2-of-5 cancel during timelock → CANCELLED
│
▼
EXECUTED ──► On-chain state change applied
```
The state machine is identical regardless of which module a proposal affects. A Module 2 NAV-deviation tolerance adjustment, a Module 3 classification age adjustment, and a cross-module Transfer Hook upgrade all flow through the same state transitions.
***
### 6. Oracle Aggregator Program
**Purpose.** Aggregates and validates oracle data from seven sources before exposing it to the Transfer Hook program. Manages Ed25519 signature verification, staleness checks, consensus logic, and module-specific oracle lifecycles.
**Module relationship.** Five oracle categories serve all modules (Custody, OFAC, AML, TWAP, EDGAR for Module 1). Two oracle categories are module-specific: NAV (Module 2) and Classification (Module 3). The Oracle Aggregator program implements all seven; module-aware behavior is determined by which oracles exist for a given mint.
#### 6.1 Oracle Sources
| Oracle | Source | Update Cadence | Module Scope |
| -------------- | ------------------------------------------------------------------------------ | --------------------------------- | ------------------------------- |
| Custody | Empire Stock Transfer (Ed25519-attested) | Every Solana block (\~400ms) | All modules |
| OFAC | U.S. Treasury OFAC API | Hourly plus emergency push | All modules |
| AML | Chainalysis KYT plus TRM Labs | Per-transfer (cached 6h) | All modules |
| TWAP | Pyth Network (on-chain) | Continuous | All modules |
| EDGAR | SEC EDGAR RSS plus EFTS | 60-second poll plus daily batch | **Module 1 (Equities) only** |
| NAV | Independent licensed appraisers | Per reappraisal-cycle cadence | **Module 2 (Real Estate) only** |
| Classification | USGS Critical Minerals List, DOE Critical Materials Strategy, Federal Register | Daily plus emergency on EO update | **Module 3 (CORECM) only** |
#### 6.2 Custody Oracle Update
The custody-relay service submits Empire-signed attestations to the oracle. The same flow serves Module 1, Module 2, and Module 3 mints — each ST22 mint has its own CustodyOracle PDA, and Empire's per-block attestation covers the affected mint regardless of module.
Each update goes through:
1. **Ed25519 signature verification** via the Solana Ed25519 precompile against Empire's registered public key.
2. **Slot freshness verification** — the slot in the payload must be the current slot or one slot prior.
3. **1:1 ratio check** — the custodied balance must be greater than or equal to the on-chain token supply. If less, `discrepancy_detected` is set true.
4. **State update** — the CustodyOracle account state is updated.
5. **Event emission** — `CustodyAttestationUpdated` for every successful update; `CustodyDiscrepancyDetected` when a discrepancy is detected.
The Custody Oracle is per-mint (PDA seeds: `[b"custody-oracle", mint]`). Each ST22 mint — Module 1, 2, or 3 — has its own oracle account.
#### 6.3 OFAC Oracle Update
The OFAC indexer service submits SDN-list refresh updates as a hash-of-list plus entry count. The actual SDN entries are tracked off chain (the Solana account size limit makes on-chain storage of the full SDN list infeasible); the on-chain hash provides cryptographic commitment to the indexer's view of the list.
The OFAC oracle is a global singleton (PDA seeds: `[b"ofac-oracle"]`). One OFAC oracle serves all mints across all modules.
#### 6.4 AML Oracle Update
The AML bridge service submits per-wallet AML scores from Chainalysis KYT and TRM Labs. The on-chain account caches the higher of the two scores for 6 hours. After cache expiry, the next transfer attempt requires a fresh score, which the AML bridge fetches before the transfer can proceed.
The AML Oracle is per-wallet (PDA seeds: `[b"aml-oracle", wallet]`). Same wallet AML score applies across all module activity for that wallet — a wallet that fails AML cannot trade Module 1, Module 2, or Module 3 ST22 mints.
#### 6.5 EDGAR Oracle (Module 1 only)
The EDGAR pipeline polls the SEC EDGAR RSS feed every 60 seconds for new filings (8-K, 10-K, 10-Q, Form D, DEF 14A, 15c2-11) and runs a daily EFTS full-text search batch at 02:00 UTC across the complete corpus. The pipeline feeds two consumers:
* **Control IV-08 (Transfer Hook)** — issuer eligibility flag synthesized into the SecurityConfig.
* **Layer 9 IDOS off-chain compliance** — issuer-disclosure intelligence for onboarding priority and ongoing monitoring.
The EDGAR oracle does not have a dedicated on-chain account; it influences the Module 1 SecurityConfig's eligibility flags and the off-chain IDOS scoring system. Module 2 and Module 3 issuers are not EDGAR-monitored — Module 2 disclosure flows through NAV oracles and tripartite-agreement reporting; Module 3 disclosure flows through Classification oracles and federal-source monitoring.
#### 6.6 NAV Oracle (Module 2 only)
The NAV Oracle holds the most recent appraised Net Asset Value for a Module 2 ST22 mint. The appraiser submits a signed appraisal to the NAV relay service, which submits it on chain after verifying the appraiser's authentication credentials and license validity at the time of appraisal. The Transfer Hook reads this oracle to enforce the NAV-deviation circuit breaker.
The NAV Oracle is per-mint (PDA seeds: `[b"nav-oracle", mint]`) and exists only for Module 2 ST22 mints. The PDA account holds the appraised NAV in USD-pegged stablecoin units, the appraiser identifier, the appraisal timestamp, the next-reappraisal target timestamp, the deviation tolerance, and the staleness threshold.
#### 6.7 Classification Oracle (Module 3 only)
The Classification Oracle holds the most recent USGS Critical Minerals List classification, DOE Critical Materials Strategy status, and federal-action status for a Module 3 ST22 mint's basin asset. The classification relay service polls federal sources on a 5-minute cadence (federal-action detection) and submits routine classification refreshes daily plus emergency pushes on Executive Order updates or court orders.
The Classification Oracle is per-mint (PDA seeds: `[b"classification-oracle", mint]`) and exists only for Module 3 ST22 mints. The PDA account holds the USGS classification, DOE status, Section 232 applicability flag, DPA Title III applicability flag, federal-action active flag, an array of active action references, and the last refresh timestamp.
#### 6.8 Staleness Thresholds
| Oracle | Cache Valid | Warning | Halt | Module Scope |
| -------------- | ---------------- | ------------------------------------- | --------------------------------------------------- | ------------ |
| Custody | 1 slot (\~400ms) | Above 3 slots | Above 1 slot (Error 6002) | All modules |
| OFAC | 24 hours | Above 12 hours | Above 48 hours (Error 6005) | All modules |
| AML | 6 hours | Above 3 hours | No score available (Error 6006) | All modules |
| TWAP | 5 minutes | Above 2 minutes | Above 5 minutes (breaker disabled) | All modules |
| EDGAR | 36 hours | Above 24 hours | No halt — continue with last batch | Module 1 |
| NAV | Per-property | 50% of `nav_reappraisal_max_age_secs` | Beyond `nav_reappraisal_max_age_secs` (mint paused) | Module 2 |
| Classification | 24 hours | Above 12 hours | Above 48 hours (enhanced review on transfers) | Module 3 |
#### 6.9 Key Rotation
Oracle relay keys can be rotated through governance proposal. Empire's custody attestation key has special handling: rotation requires Empire to communicate the new key through documented chain-of-custody, followed by a governance proposal that updates the Empire public key on every CustodyOracle account, followed by 5-of-9 multi-signature execution. The 48-hour timelock applies unless emergency override is authorized.
Module-specific oracle keys (NAV relay authority, Classification relay authority) follow the same governance procedure. Module 2 appraiser keys are managed per appraiser engagement under the tripartite agreement — when a new appraiser is engaged, their public key is registered in the NAV relay's authorized appraiser registry; old appraiser keys remain valid for verification of historical appraisals but cannot sign new attestations.
***
### 7. PDA Registry (All Programs)
| PDA | Seeds | Program | One Per | Module Scope |
| ------------------------ | ---------------------------------------- | ----------------- | ---------------- | ----------------- |
| SecurityConfig | `[b"security-config", mint]` | Transfer Hook | ST22 mint | All modules |
| HoldingPeriodAccount | `[b"holding-period", mint, beneficiary]` | Transfer Hook | Investor × mint | All modules |
| ExtraAccountMetaList | Token-2022 standard derivation | Transfer Hook | ST22 mint | All modules |
| CustodyOracle | `[b"custody-oracle", mint]` | Oracle Aggregator | ST22 mint | All modules |
| OFACOracle | `[b"ofac-oracle"]` | Oracle Aggregator | Global singleton | All modules |
| AMLOracle | `[b"aml-oracle", wallet]` | Oracle Aggregator | Wallet | All modules |
| **NAVOracle** | `[b"nav-oracle", mint]` | Oracle Aggregator | Module 2 mint | **Module 2 only** |
| **ClassificationOracle** | `[b"classification-oracle", mint]` | Oracle Aggregator | Module 3 mint | **Module 3 only** |
| Pool | `[b"pool", mint]` | AMM | ST22 mint | All modules |
| FeeConfig | `[b"fee-config"]` | AMM | Global singleton | All modules |
| GlobalPool | `[b"global-pool"]` | Liquidity Pool | Global singleton | All modules |
| Proposal | `[b"proposal", id]` | Governance | Proposal | All modules |
The PDA derivations are deterministic — auditors and integrators can compute the address of any account from the published seeds and the program ID. Module-specific PDAs (NAVOracle, ClassificationOracle) exist only for the relevant module's mints; attempting to derive them for a Module 1 mint, for example, returns a valid PDA address but no initialized account.
***
### 8. Event Registry (All Programs)
Every successful operation emits a structured event. Events are written to the Solana ledger and are queryable through standard Solana RPC providers. Cross-module events are emitted regardless of mint module; module-specific events are emitted only for the relevant module's mints.
#### 8.1 Transfer Hook Events
| Event | Emission Trigger | Module Scope |
| ----------------------- | -------------------------------- | ------------------------------------------------------------------------------------------- |
| TransferValidated | Every successful ST22 transfer | All modules |
| CircuitBreakerTriggered | Any of CB-20 through CB-23 fires | All modules |
| RegulatoryFreezeEvent | Control 42 activated or lifted | All modules; Module 3 federal-action freezes use this event with `source: "federal_action"` |
| HoldingPeriodUnlocked | Holding period elapses | All modules |
#### 8.2 AMM Events
| Event | Emission Trigger | Module Scope |
| --------------- | ---------------- | -------------------------------- |
| SwapExecuted | Successful swap | All modules — same fee breakdown |
| PoolInitialized | Pool creation | All modules |
#### 8.3 Oracle Aggregator Events
| Event | Emission Trigger | Module Scope |
| ------------------------------- | ---------------------------------------------------------- | ----------------- |
| CustodyAttestationUpdated | Successful custody oracle update | All modules |
| CustodyDiscrepancyDetected | balance < supply | All modules |
| OFACListRefreshed | OFAC oracle update | All modules |
| **NAVOracleUpdated** | Module 2 appraisal received | **Module 2 only** |
| **ClassificationOracleUpdated** | Routine classification refresh | **Module 3 only** |
| **FederalActionDetected** | Module 3 federal-action P0 incident | **Module 3 only** |
| **FederalActionFreezeApplied** | Module 3 Control 42 freeze applied via Classification path | **Module 3 only** |
#### 8.4 Liquidity Pool Events
| Event | Emission Trigger | Module Scope |
| --------------------- | ------------------------------- | ----------------------------------- |
| GlobalPoolInitialized | One-time at platform deployment | All modules — single shared pool |
| FeeDeposited | Every fee deposit from AMM | All modules — same allocation logic |
#### 8.5 Governance Events
| Event | Emission Trigger | Module Scope |
| ---------------- | -------------------------------- | ------------ |
| ProposalCreated | Proposal submitted | All modules |
| VoteCast | Vote recorded | All modules |
| ProposalExecuted | After timelock and threshold met | All modules |
***
### 9. State Machines
#### 9.1 ST22 Token Lifecycle
The lifecycle structure is identical across modules. The asset class deposited into custody and the on-chain mint creation steps are the same; only the asset identifier and module-specific oracle initialization differ.
```
┌─────────────────────┐
│ Board Resolution │
│ (per-module charter)│
└────────┬─────────────┘
│
┌────────▼─────────────┐
│ Empire Custody │
│ Deposit │
│ Module 1: Common B │
│ Module 2: SAE equity│
│ Module 3: BAE equity│
└────────┬─────────────┘
│
┌────────▼──────────┐
│ ST22 Mint Created │
│ + Transfer Hook │
│ (IRREVERSIBLE) │
└────────┬──────────┘
│
┌────────────────▼──────────────────┐
│ Module-specific oracle init: │
│ Module 1: CustodyOracle │
│ Module 2: + NAVOracle │
│ Module 3: + ClassificationOracle│
└────────────────┬──────────────────┘
│
┌────────────────▼────────────────┐
│ Reg D / Reg S / Reg CF Offering │
│ Empire KYC/KYB → Stablecoin │
│ settlement → Token delivery │
└────────────────┬────────────────┘
│
┌────────▼──────────┐
│ HOLDING PERIOD │
│ Reg D: 6 mo │
│ Reg S: 12 mo │
│ Reg CF: 12 mo │
│ (Control HP-24) │
└────────┬──────────┘
│ Timer elapses
┌────────▼──────────┐
│ TRADEABLE │
│ Secondary on CEDEX│
│ 42 controls/trade │
└───────────────────┘
```
#### 9.2 CEDEX Order Lifecycle
```
PLACED ──► PRE-FLIGHT COMPLIANCE (2-3s)
│
├─ ANY control fails → REJECTED (Error 6xxx)
│ Module 1: standard 6 pre-flight checks
│ Module 2: + NAV-deviation pre-flight check
│ Module 3: + Classification freshness + federal-action checks
│
▼
VALIDATED ──► ON-CHAIN EXECUTION (400-600ms)
│
├─ Slippage exceeded → REVERTED (7002)
├─ Insufficient liquidity → REVERTED (7001)
│
▼
FILLED ──► FEE DISTRIBUTION
│ ├─ 0.44% → Global Pool (LOCKED)
│ ├─ 2.00% → Issuer Treasury
│ ├─ 1.50% → GROO Staking Pool
│ └─ 1.06% → Protocol Operations
│
▼
SETTLED ──► AUDIT TRAIL EMITTED
```
#### 9.3 Module 2 NAV-Deviation Breaker Lifecycle
```
TRADING ──► NAV ORACLE UPDATE (per reappraisal cycle)
│
├─ On-chain price within nav_deviation_max_bps → CONTINUE
│
▼
DEVIATION DETECTED ──► MINT PAUSED (per-mint, not platform-wide)
│
▼
AWAITING NEW APPRAISAL
│
├─ Fresh appraisal restores price within bounds → RESUME
├─ Governance adjusts deviation threshold → RESUME
│
▼
TRADING (resumed)
```
#### 9.4 Module 3 Federal-Action Freeze Lifecycle
```
NORMAL OPERATION ──► CLASSIFICATION ORACLE (24h cache)
│
▼
FEDERAL ACTION DETECTED (P0 incident)
│
├─ Legal Counsel + 3-of-5 multi-sig → CONTROL 42 FREEZE
│
▼
FROZEN ──► No transfers; mint paused on AMM
│
▼
AWAITING FEDERAL-ACTION RESOLUTION
│
├─ Action expires / rescinded / variance / exemption
│
▼
FREEZE LIFTED (Legal Counsel + 3-of-5)
│
▼
TRADING (resumed)
```
***
### 10. Upgrade Authority Model
| Program | Authority Type | Signers | Timelock | Module Scope |
| ----------------- | ---------------------- | -------------------------- | -------- | -------------------------------------------- |
| Transfer Hook | 5-of-9 multi-signature | Geographically distributed | 24 hours | All modules — single hook serves all |
| AMM | 5-of-9 multi-signature | Geographically distributed | 24 hours | All modules |
| Liquidity Pool | **None — immutable** | — | — | All modules — same immutable program |
| Governance | 3-of-5 multi-signature | — | 48 hours | All modules |
| Oracle Aggregator | 5-of-9 multi-signature | Geographically distributed | 24 hours | All modules — module-specific oracles within |
#### 10.1 Transfer Hook Upgrade Procedure
1. A governance participant creates a Program Upgrade proposal.
2. Voting period is at least 48 hours.
3. 66.67% supermajority is required for passage.
4. The new bytecode hash must match an audited release.
5. Certora formal verification must pass on the new bytecode — all six invariants verified.
6. 24-hour timelock begins.
7. During the timelock, 2-of-5 of the parameter-authority multi-signature can cancel.
8. The 5-of-9 upgrade-authority multi-signature executes the BPF upgrade instruction after timelock expiry.
9. **Transfer Hook controls cannot be weakened.** The upgrade can only adjust parameters within hard-coded bounds, fix bugs, or extend functionality. Removing any of the 42 controls — or weakening any module-aware extension — would fail Certora invariant E.4 and the upgrade would be rejected at the formal-verification step.
#### 10.2 What No Upgrade Can Do
Even with full multi-signature authority and supermajority governance support, no upgrade can:
* Remove any of the 42 Transfer Hook controls (Certora invariant E.4 verification would fail). This applies to module-aware variants too — removing the Module 2 NAV-deviation check or the Module 3 federal-action freeze coordination would also fail E.4.
* Reduce a holding period below the statutory minimum (hard-coded constants are outside parameter space). Same Reg D / Reg S / Reg CF constants apply across all modules.
* Add a withdrawal function to the Liquidity Pool (the Liquidity Pool program is permanently immutable). Same pool serves all modules.
* Remove the Transfer Hook from existing mints (SPL Token-2022 standard makes hook attachment permanent). Applies to Module 1, 2, and 3 mints alike.
* Bypass the multi-signature requirement (multi-signature is enforced at the Solana program level).
***
### 11. Cross-Program Invocation Map
```
Token-2022 ───CPI──► Transfer Hook
│
├──reads──► Oracle Aggregator
│ Module 1 reads: CustodyOracle, OFACOracle, AMLOracle
│ Module 2 reads: + NAVOracle
│ Module 3 reads: + ClassificationOracle
│
└──emits──► TransferValidated event
CEDEX Backend ──tx──► AMM
│
├──CPI──► Token-2022 ───CPI──► Transfer Hook (42 controls)
│ (module-aware reads as above)
│
├──CPI──► Liquidity Pool (deposit_fee: 0.44%)
│
└──emits──► SwapExecuted event
Empire Relay ──tx──► Oracle Aggregator (custody attestation)
│
├──verify──► Ed25519 precompile
│
└──emits──► CustodyAttestationUpdated /
CustodyDiscrepancyDetected
(all modules — same path)
NAV Relay ──tx──► Oracle Aggregator (Module 2 appraisal)
│
├──verify──► appraiser signature
│
└──emits──► NAVOracleUpdated
Classification Relay ──tx──► Oracle Aggregator (Module 3 USGS/DOE update)
│
└──emits──► ClassificationOracleUpdated
FederalActionDetected (P0 path)
FederalActionFreezeApplied (post Control 42)
Governance ──tx──► Governance
│
└──CPI──► target program (parameter update or BPF upgrade)
(parameter target may be cross-module
or module-specific)
```
The CPI map is deliberately constrained. The Liquidity Pool's `deposit_fee` instruction can only be called by the AMM program PDA. The Custody Oracle update can only be submitted by the registered Empire relay authority. The NAV Oracle update can only be submitted by the registered NAV relay authority with verified appraiser signatures. The Classification Oracle update can only be submitted by the registered Classification relay authority. Every cross-program path is verified by the calling program's PDA authority — there is no path for an arbitrary signer to invoke a privileged operation.
***
### 12. Deployment Verification
After deployment, every program is verified through the procedure documented in the Deployment Guide §10. Verification confirms:
| Verification | Mechanism | Module Scope |
| ------------------------------------------------------------------ | -------------------------------------------------------------------- | ------------------ |
| Transfer Hook attached to every ST22 mint | Mint extension query — Hook program ID matches | All modules |
| All five programs deployed | Solana program-show on each program ID | All modules |
| Upgrade authorities correct | Each program's authority matches the expected multi-signature | All modules |
| Liquidity Pool program immutable | Pool program upgrade authority is `None` | All modules |
| LP burned at Global Pool initialization | LP mint supply is zero; LP mint authority is `None` | All modules |
| Custody Oracle updating | Attestation slot within 1 of current Solana slot | All modules |
| **Module 1 EDGAR pipeline operational** | Last RSS poll within 60 seconds; last EFTS batch within 36 hours | **Module 1 only** |
| **Module 2 NAV Oracle initialized (per Module 2 mint)** | NAV oracle has valid initial appraisal | **Module 2 only** |
| **Module 3 Classification Oracle initialized (per Module 3 mint)** | Classification oracle has valid USGS/DOE classification | **Module 3 only** |
| **Module 3 federal-action monitoring operational** | Classification relay polling federal sources within 5-minute cadence | **Module 3 only** |
| SecurityConfig parameters within governance bounds | Per-mint parameter query against expected ranges | All modules |
| Module-specific SecurityConfig fields populated | Module 2 NAV bounds, Module 3 classification age | Module 2, Module 3 |
Any verification failure halts the deployment until resolved.
***
### 13. Module-Aware Program Behavior
The five programs serve all three modules identically at the structural level. Module-specific behavior arises from three module-aware components: Module-specific oracles (NAVOracle for Module 2; ClassificationOracle for Module 3), module-specific SecurityConfig fields, and module-aware Transfer Hook checks. This section consolidates the module-specific behavior surface — the same surface that has been threaded through each program section above.
#### 13.1 Module 1 — Equities
**Programs.** All five programs operate normally. No additional oracles or PDAs.
**Distinguishing properties.** Standard ST22 mint with Transfer Hook, AMM pool, fee distribution to Global Pool. Module 1 issuances use the EDGAR pipeline (an off-chain feed read by the Layer 9 IDOS off-chain compliance system) for issuer-disclosure intelligence; this does not change on-chain program behavior.
**Asset identifier.** CUSIP.
**Highest expected transaction volume** of the three modules — correlates with the broadest investor pool.
#### 13.2 Module 2 — Real Estate
**Additional oracle.** NAV Oracle (per mint).
**Distinguishing properties.** Each Module 2 ST22 mint corresponds to a single-asset entity holding the underlying real-property asset. The NAV Oracle holds the most recent appraised NAV from a licensed independent appraiser. The Transfer Hook enforces a NAV-deviation circuit breaker that pauses the mint on the AMM when the on-chain price deviates from the NAV by more than `nav_deviation_max_bps`.
**Asset identifier.** Property identifier.
**Module-specific SecurityConfig parameters.** `nav_deviation_max_bps`, `nav_reappraisal_max_age_secs`, `nav_circuit_breaker_enabled`.
**Module-specific events.** `NAVOracleUpdated`.
**Lower expected transaction volume** than Module 1, but higher per-transaction notional value.
#### 13.3 Module 3 — CORECM
**Additional oracle.** Classification Oracle (per mint).
**Distinguishing properties.** Each Module 3 ST22 mint corresponds to a basin-asset entity holding the mineral basin or mining concession. The Classification Oracle holds the most recent USGS Critical Minerals List classification, DOE Critical Materials Strategy status, and federal-action status from federal feeds. The Transfer Hook applies enhanced compliance review when classification staleness exceeds the threshold and supports automatic Control 42 federal-action freeze in coordination with Empire Stock Transfer.
**Asset identifier.** Basin identifier.
**Module-specific SecurityConfig parameters.** `classification_max_age_secs`, `federal_action_freeze_enabled`.
**Module-specific events.** `ClassificationOracleUpdated`, `FederalActionDetected`, `FederalActionFreezeApplied`.
**Lowest expected transaction volume** but highest regulatory sensitivity. Federal actions issued under Executive Orders, Section 232 of the Trade Expansion Act of 1962, Defense Production Act Title III, the Inflation Reduction Act critical-minerals provisions, Executive Order 14017, or the Energy Act of 2020 are detected by the platform's federal-action monitoring and trigger automatic P0 response under the Incident Response Playbook §13.
#### 13.4 Cross-Module Program Properties
The following properties are identical across all three modules at the program level:
* The Transfer Hook program executes the same 42 controls (with module-aware oracle reads in CB-21 for Module 2 and in CV-04/REG-42 for Module 3).
* The AMM program uses the same constant-product invariant and fee distribution.
* The Liquidity Pool aggregates fees from all module activity into the same Global Pool.
* The Governance program manages parameter and upgrade proposals identically — module-specific parameters follow the same governance discipline as cross-module parameters.
* The Oracle Aggregator manages the cross-module oracles (custody, OFAC, AML, TWAP) for every mint.
* Multi-signature thresholds and timelock durations apply uniformly.
* Empire Stock Transfer is the sole §17A custodian and sole onboarding authority for every issuance.
* The 1:1 backing invariant (Certora E.2) applies to every ST22 mint regardless of module.
* The Global Pool non-extractability invariant (Certora E.3) protects every module's fee accumulation.
* Holding periods (Reg D 6mo, Reg S 12mo, Reg CF 12mo) apply identically across modules.
***
### Related Documentation
* **Solana Blockchain Foundation** — Why Solana, Token-2022, Transfer Hook, module-specific foundations
* **Architecture Decisions** — ADR-001 through ADR-012 with full alternatives analysis
* **Security Model** — Threat model, key management, formal verification, module-specific threat surfaces
* **Infrastructure Overview** — Cloud architecture, environment separation, blockchain infrastructure
* **Network Configuration** — Program addresses, RPC endpoints, oracle PDAs, multi-signature addresses, production parameters
* **Deployment Guide** — Build, deploy, verify, upgrade, rollback procedures including module-specific initialization
* **Incident Response Playbook** — P0 through P3 runbooks; Module 3 federal-action freeze runbook
* **Empire Stock Transfer Integration** — Custody architecture, Ed25519 attestation, MSF, KYC/KYB/AML/OFAC, conflict-of-interest disclosure, module-aware custody coverage
* **Compliance Integration Guide** — Regulatory mapping, Category 1 Model B requirements, BSA/AML, OFAC, holding periods, module-specific compliance, federal-action coordination
* **Oracle Integration Guide** — Custody, OFAC, AML, TWAP, EDGAR (Module 1), NAV (Module 2), Classification (Module 3) relay architecture
* **Transfer Hook Reference** — Standalone reference for the 42 controls
* **Whitepaper Section 3** — Transfer Hook architecture and beta validation
* **Whitepaper Section 5** — AMM math and CEDEX specification
***
*RWA Tokens · Smart Contract Reference · Groovy Company, Inc.*
# Welcome
Welcome to the **RWA Tokens Marketing Wiki** — the central library for everything we publish about the platform to the outside world. Articles, pitch decks, the lightpaper, investor presentations, SEC filings and staff statements we cite, regulatory commentary, and ongoing news coverage all live here, organized so the comms team, partners, and counsel can find the right asset for the right audience without rebuilding it from scratch.
You'll find collateral grouped by the three asset-class modules — **Equities (ST22), Real Estate, and CORECM** — alongside cross-cutting materials that apply to the platform as a whole: corporate-identity assets, SEC regulatory framework references (Release No. 33-11412, the January 28, 2026 Joint Staff Statement, the April 13, 2026 Covered User Interface Providers statement), and the live news and X/LinkedIn campaign archive. Each item is tagged by audience (institutional investor, issuer prospect, regulator, press) and by stage (draft, internal review, legal-cleared, published) so nothing ships externally without the right approval state.
This wiki is the canonical source for any RWA Tokens marketing artifact under the Groovy Company, Inc. brand (the "OTCM Protocol" dba was retired May 1, 2026; CEDEX, ST22, and GROO remain as product and instrument names). Platform URL is [**https://rwatokens.net**](https://rwatokens.net/); trading venue is **cedex.market**. When in doubt about which version of a deck or letter is current, this wiki is the answer — anything found elsewhere should be checked against the version here before sending.
# AI-IDOS Module
## AI and IDOS Module
**Layer 9 Off-Chain Compliance Intelligence · Module-Aware IDOS Scoring · Wallet Profiling · Investor Targeting · Staking Gates**
Layer 9 of the platform's architecture — the commercial intelligence engine that converts the platform's technical infrastructure into an active issuer acquisition pipeline and investor targeting system across all three production modules: Equities (Module 1), Real Estate (Module 2), and CORECM — Carbon Ore, Rare Earth, and Critical Minerals (Module 3). This page expands on Whitepaper V8 Section 9 with module-specific scoring formulas, pipeline architecture, NLP target phrases, and staking-tier access requirements.
> **Scope:** The AI Module operates exclusively at the pre-onboarding discovery and targeting layer. It does not alter or bypass any Transfer Hook security controls. All data sources are publicly available (SEC EDGAR for Module 1; SEC REIT filings and county records for Module 2; USGS, DOE, and Federal Register feeds for Module 3; OTC Markets Group; on-chain Solana data). No proprietary, non-public, or personally identifiable data is accessed without explicit consent.
***
### Table of Contents
1. Module Overview
2. Position in the Platform Stack
3. Module 1 — Equities IDOS Pipeline
4. Module 2 — Real Estate IDOS Pipeline
5. Module 3 — CORECM IDOS Pipeline
6. Composite IDOS Score Architecture
7. Outreach Pathway Multipliers
8. Dynamic Priority Queue
9. Investor-Side Wallet Profiling
10. Launch Readiness Score
11. Staking Tier Access Gates
12. Per-Operation Token Burns
13. Data Moat and Competitive Defensibility
14. Performance Specifications
15. Regulatory and Privacy Considerations
***
### 1. Module Overview
The AI Module is the platform's commercial intelligence overlay. It solves two problems simultaneously across all three production modules.
**Issuer acquisition.** Which issuers across Equities, Real Estate, and CORECM are most ready for tokenization right now? The module generates a continuously refreshed Issuer Distress and Opportunity Score (IDOS) for every entity in each module's target universe, enabling algorithmic prioritization of outreach — processing hundreds of issuers in parallel without proportional headcount growth.
| Module | Target Universe | Primary Data Sources |
| ---------------------- | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| Module 1 — Equities | \~15,000 OTC-listed companies plus NASDAQ, AMEX, TSX, and global exchange-listed equities | SEC EDGAR, OTC Markets Group |
| Module 2 — Real Estate | Single-asset commercial properties, multifamily portfolios, real-estate funds with distress signals | SEC REIT filings, county records, MLS data, environmental databases |
| Module 3 — CORECM | Mineral basins, mining concessions, rare-earth operations | USGS Critical Minerals List, DOE Critical Materials Strategy, Federal Register, county mineral-rights records |
**Investor targeting.** Which verified wallets on Solana are most likely to participate in the next ST22 offering — across Reg D (US accredited), Reg S (non-US), and Reg CF (US retail) eligibility profiles? The module profiles on-chain wallet behavior and targets outreach to wallets matching the offering's eligibility criteria.
#### What the AI Module Is
| Property | Detail |
| ------------ | ------------------------------------------------------------------------------------------ |
| Purpose | Module-aware issuer acquisition pipeline + investor targeting for ST22 offerings |
| Module scope | Module 1, Module 2, and Module 3 — separate IDOS pipelines per module |
| Data sources | All public — SEC EDGAR, USGS, DOE, OTC Markets Group, county records, Solana on-chain data |
| Output | Module-specific IDOS scores, ranked priority queues per module, investor wallet profiles |
| Layer | Layer 9 — off-chain commercial intelligence overlay |
| Enforcement | None — the module does not participate in Transfer Hook controls |
| Access | Gated behind GROO staking tiers |
| Burns | Per-operation GROO burns create deflationary pressure |
#### What the AI Module Is NOT
* Not part of compliance enforcement — Transfer Hook Controls 1–42 operate independently and uniformly across all three modules.
* Not a trading algorithm — does not execute or recommend trades.
* Not a financial advisor — produces scoring data, not investment advice.
* Not accessing non-public data — all sources are publicly available by design.
***
### 2. Position in the Platform Stack
```
L9 │ AI AND IDOS MODULE ◄── THIS DOCUMENT
│ Module-Aware IDOS Scoring · Wallet Profiling
│ Module 1: EDGAR NLP · OTC Markets · IDOS-Equities
│ Module 2: REIT/county · MLS · IDOS-RealEstate
│ Module 3: USGS/DOE · Federal Reg · IDOS-CORECM
│
│ CONSUMES:
│ ├─ Layer 6 oracle data (EDGAR/NAV/Classification pipelines, OTC feeds)
│ └─ On-chain Solana data (wallet behavior, transaction patterns)
│
│ PRODUCES:
│ ├─ Per-module IDOS scored issuer priority queues → Issuer Onboarding (Layer 5)
│ └─ Investor wallet profiles → Offering notifications (all modules)
│
L8 │ Wallet Infrastructure
L7 │ Protocol Governance
L6 │ Oracle Network ◄── EDGAR/NAV/Classification pipelines shared with Layer 9
L5 │ CEDEX Exchange
L4 │ Custom AMM Engine
L3 │ Global Unified Liquidity Pool
L2 │ Security Enforcement (42 Transfer Hook controls — module-aware)
L1 │ Solana Foundation
```
Each module-specific pipeline shares its Layer 6 oracle data with Layer 2 enforcement controls. Module 1's EDGAR pipeline feeds both Control IV-08 (issuer eligibility) at Layer 2 and IDOS scoring at Layer 9. Module 2's NAV oracle pipeline feeds both CB-21 (NAV-deviation circuit breaker) at Layer 2 and IDOS-RealEstate scoring at Layer 9. Module 3's Classification oracle pipeline feeds both CV-04 / REG-42 (federal-action freeze coordination) at Layer 2 and IDOS-CORECM scoring at Layer 9. The pipelines are shared; the consumers are independent.
***
### 3. Module 1 — Equities IDOS Pipeline
#### 3.1 SEC EDGAR Integration
SEC EDGAR is the authoritative public record for U.S. registered and reporting companies. For Module 1 IDOS scoring, EDGAR functions as a real-time issuer distress signal monitor.
| Endpoint | Purpose | Update Mode |
| ------------------------------------------------ | ----------------------------------------------- | ------------------------------- |
| `efts.sec.gov` — Full-Text Search API | Distress language NLP scan across MD\&A filings | Real-time on each new filing |
| `data.sec.gov/submissions/` — Filing History | Form D, 8-K, 10-K indexing per CIK | Event-driven on new submission |
| `data.sec.gov/api/xbrl/` — Structured Financials | Financial health and liquidity ratio scoring | Quarterly on 10-K/10-Q |
| EDGAR RSS Feed | New filing notification pipeline | Real-time continuous monitoring |
#### 3.2 Filing Type Usage
| Filing | Layer 2 Consumer (IV-08) | Layer 9 Consumer (Module 1 IDOS) |
| -------------- | --------------------------------- | ---------------------------------------- |
| Form D | Reg D registration verification | Capital-raise timing and urgency scoring |
| 10-K / 10-Q | Current information status | Liquidity Distress Index NLP scan |
| Form 8-K | Regulatory action detection | Real-time distress trigger alerts |
| DEF 14A | Active SEC reporting verification | Shareholder count extraction |
| 15c2-11 status | Trading eligibility | Tier degradation scoring |
#### 3.3 Liquidity Distress Index (LDI) — NLP Pipeline
10-K / 10-Q MD\&A sections are scanned with weighted phrase matching and normalized to a 0–100 LDI scale.
| Weight | Target Phrases |
| ---------------- | ------------------------------------------------------------------------------------------------- |
| HIGH (2.0x) | "no established trading market exists" · "shareholders may have difficulty selling" |
| HIGH (2.0x) | "limited or no market maker activity" · "no assurance that a liquid market will develop" |
| MEDIUM (1.5x) | "thin trading volume" · "limited trading market" · "no broker-dealer has agreed to make a market" |
| INDICATOR (1.0x) | "OTC Markets" · "Pink Sheets" · "15c2-11" · "delisted" · "trading was suspended" |
```
LDI = Σ(phrase_count × weight) / total_md&a_words × normalization_factor
Normalized to 0–100 scale:
LDI > 80: Severe liquidity distress — highest tokenization readiness
LDI 60–80: Significant distress — high priority
LDI 40–60: Moderate distress — standard outreach
LDI 20–40: Mild distress — nurture sequence
LDI < 20: Minimal distress — monitor
```
#### 3.4 8-K Trigger Alert System
| 8-K Item | Condition | Score | Response |
| -------- | ------------------------------------------ | ----- | ----------------------------------------------------------- |
| 1.03 | Bankruptcy or receivership filing | 0.95 | Urgent — shareholder protection window. Immediate outreach. |
| 4.02 | Non-reliance on prior financial statements | 0.90 | High priority — financial restatement distress |
| 4.01 | Changes in certifying accountant | 0.85 | High priority — audit/leadership uncertainty |
| 2.04 | Triggering events for debt acceleration | 0.80 | High — debt covenant / liquidity stress |
| 5.02 | Departure / appointment of officers | 0.65 | Medium — board restructuring; monitor follow-on filings |
| 2.01 | Completion of acquisition / disposition | 0.50 | Medium — corporate restructuring signal |
| 5.03 | Amendments to articles of incorporation | 0.40 | Low-medium — governance change |
#### 3.5 OTC Markets Tier Degradation
Downward tier movement is the most actionable signal for Module 1. The current OTC Markets tier structure is OTCQX → OTCQB → OTCID → Pink Limited → Pink No Information → Grey Market → Expert Market.
| Tier Transition | Signal Strength | Outreach Timing |
| ---------------------------------- | -------------------------------- | ---------------------------------- |
| OTCQB → OTCID | Medium — early distress | Standard nurture sequence |
| OTCID → Pink Limited | High — liquidity degrading | Accelerated outreach |
| Pink Limited → Pink No Information | Very high — approaching dark | Urgent outreach |
| Pink → Grey Market / Dark | Critical — zero liquidity | Immediate outreach (30-day window) |
| Expert Market designation | Critical — retail access revoked | Same |
#### 3.6 Module 1 IDOS Composite Weights
| Signal Component | Source | Weight | Refresh |
| ---------------------------------- | --------------------- | -------- | ---------------------- |
| Liquidity Distress Index (LDI) | EDGAR 10-K / 10-Q NLP | 0.22 | Per new filing |
| Tier Degradation Score | OTC Markets | 0.18 | Daily |
| Recovery Probability Score (RPS) | OTC Markets | 0.18 | Daily |
| Time Since Last Trade | OTC Markets | 0.12 | Daily |
| Shareholder Count (log-normalized) | EDGAR DEF 14A | 0.12 | Annual / on new filing |
| 8-K Trigger Score | EDGAR RSS | 0.10 | Real-time |
| Form D Urgency Score | EDGAR Form D | 0.08 | Per new filing |
| **TOTAL** | | **1.00** | |
The Recovery Probability Score combines price decay, volume decay, and trading inactivity:
```
RPS = w₁ × PriceDecay + w₂ × VolumeDecay + w₃ × DaysInactive
Where:
PriceDecay = (current_price / peak_52w_price - 1.0), bounded [0, 1]
VolumeDecay = 1 - (avg_30d_volume / avg_prior_year_volume), bounded [0, 1]
DaysInactive = min(days_since_last_trade / 730, 1.0)
Empirically calibrated weights:
w₁ = 0.35 (price trajectory)
w₂ = 0.30 (volume trajectory)
w₃ = 0.35 (trading recency)
```
***
### 4. Module 2 — Real Estate IDOS Pipeline
The Module 2 IDOS pipeline scores commercial properties, multifamily assets, real-estate funds, and basin-attached real-property assets for tokenization readiness.
#### 4.1 Data Sources
| Source | Coverage | Update Mode |
| ----------------------------------------- | -------------------------------------------------------------- | ---------------------------------- |
| SEC REIT filings (10-K, 10-Q, 8-K) | Public REITs and registered real-estate funds | EDGAR RSS + EFTS daily batch |
| County recorder filings | Title transfers, liens, foreclosure notices, tax delinquencies | County-by-county scrapers (daily) |
| MLS data (where licensed) | Listing duration, price reductions, withdrawal patterns | Per MLS license cadence |
| Environmental databases (EPA, state DEPs) | Phase I / Phase II flags, remediation orders | Federal RSS + state portal polling |
| CMBS and CRE-CLO surveillance feeds | Loan-default and watchlist signals | Trustee report cadence |
| Real-estate market indices | Cap rates, regional vacancy, transaction volume | Quarterly data refreshes |
#### 4.2 Property Distress Signals
| Signal | Indicates | IDOS Weight |
| -------------------------------------------- | -------------------------------------------- | ------------- |
| Lis pendens or foreclosure notice | Loan-default distress, owner motivated | High (0.20) |
| Listing duration > 12 months without sale | Pricing-mismatch with market | High (0.18) |
| Multiple price reductions on listing | Owner motivated; tokenization as alternative | High (0.16) |
| Lease expiration cluster (≥40% in 24 months) | NOI volatility on horizon | Medium (0.14) |
| Vacancy rate above submarket average | Operational distress | Medium (0.12) |
| Phase I / II environmental flag | Capital obstacle for traditional sale | Medium (0.10) |
| Tax delinquency on record | Cash-flow distress | Medium (0.10) |
#### 4.3 NAV-Reappraisal Cadence Indicators
For properties already structured as Module 2 candidates (Delaware, Wyoming, or Nevada single-asset LLCs), the module monitors reappraisal cadence as an opportunity signal — properties due for reappraisal within the next 90 days are flagged for proactive issuer outreach.
```
NAV_REFRESH_OPPORTUNITY = (days_until_next_reappraisal < 90)
AND (single_asset_entity_formed)
AND (independent_appraiser_relationship_exists)
```
#### 4.4 Module 2 IDOS Composite Weights
| Signal Component | Source | Weight | Refresh |
| ------------------------------ | ---------------------------------- | -------- | ---------------------- |
| Property Distress Composite | County records, MLS, environmental | 0.32 | Daily |
| REIT Filing Distress Score | SEC REIT NLP | 0.18 | Per new filing |
| Lease Expiration Cluster Score | Tenant data, county records | 0.14 | Quarterly |
| CMBS / CRE-CLO Watchlist Score | Trustee feeds | 0.12 | Trustee report cadence |
| Submarket Cap-Rate Trajectory | Market indices | 0.10 | Quarterly |
| NAV-Reappraisal Opportunity | Tripartite registry (existing) | 0.08 | Per cycle |
| Environmental / Tax Flag | EPA, state DEP, county tax records | 0.06 | Daily |
| **TOTAL** | | **1.00** | |
Module 2 issuers are typically single-asset entities, not the parent operating company. The IDOS pipeline accounts for this by indexing at the property level and aggregating to the entity level only at the outreach stage.
***
### 5. Module 3 — CORECM IDOS Pipeline
The Module 3 IDOS pipeline scores mineral basins, mining concessions, and rare-earth operations for tokenization readiness, with strict regulatory awareness given federal-action sensitivity.
#### 5.1 Data Sources
| Source | Coverage | Update Mode |
| ------------------------------------- | ----------------------------------------------------------------- | ------------------------------------- |
| USGS Critical Minerals List | Mineral classification, criticality designation | Annual list + emergency updates |
| DOE Critical Materials Strategy | Material-priority designation, program status | Program announcements |
| Federal Register | Executive Orders, Section 232 proclamations, DPA Title III orders | Continuous monitoring (5-min cadence) |
| County mineral-rights records | Title chain, lease terms, concession status | County-by-county scrapers |
| State oil-gas-and-minerals registries | Permit status, operational compliance | State-by-state cadence |
| DOD procurement directives | Strategic-procurement actions affecting basins | RSS + agency portals |
| SEC mining-company filings | 10-K / 10-Q / 8-K for SEC-reporting miners | EDGAR RSS + EFTS daily batch |
| DOE program announcements | Critical Materials Strategy updates, funding directives | Program portal monitoring |
#### 5.2 Critical-Mineral Classification Signals
| Signal | Indicates | IDOS Weight |
| ------------------------------------------------- | -------------------------------- | ------------- |
| USGS classification: critical mineral, rare earth | Federal strategic priority | High (0.18) |
| DOE Critical Materials Strategy: high priority | Federal funding eligibility | High (0.16) |
| Section 232 applicability | Trade-policy strategic value | Medium (0.12) |
| DPA Title III applicability | Defense-priority strategic value | Medium (0.12) |
| IRA critical-minerals provisions | Tax-credit eligibility | Medium (0.10) |
| Concession active and in good standing | Operational readiness | Medium (0.10) |
#### 5.3 Federal-Action Exposure (Inverse Signal)
Federal-action exposure is an **inverse** signal — it indicates regulatory sensitivity that elevates IDOS scoring while increasing onboarding complexity. The Module 3 IDOS pipeline tracks current federal-action posture for each basin:
| Federal Posture | Signal Direction |
| ------------------------------------------------------------------------ | ------------------------------------------------------- |
| No active federal action; strategic-priority designation | Highest IDOS — opportunity with low regulatory friction |
| Active strategic-priority designation; recent IRA tax-credit eligibility | High IDOS — opportunity with regulatory tailwind |
| Active Section 232 review or DPA Title III consideration | Moderated IDOS — opportunity with onboarding caution |
| Active federal-action freeze precedent on similar basins | Reduced IDOS — operational risk material |
| Active enforcement or environmental review | Lowest IDOS — defer until resolved |
#### 5.4 Operational Distress Signals (Mining-Specific)
| Signal | Indicates | IDOS Weight |
| -------------------------------------------------- | ------------------------ | ------------- |
| Capital expenditure forecasts exceed cash position | Capital-raise need | High (0.15) |
| Delayed permit renewals | Operational uncertainty | Medium (0.10) |
| Workforce reduction announcements | Operational distress | Medium (0.10) |
| Mineral-reserve estimate downgrades | Asset revaluation needed | Medium (0.10) |
#### 5.5 Module 3 IDOS Composite Weights
| Signal Component | Source | Weight | Refresh |
| ----------------------------------------- | ------------------------------------------ | -------- | -------------------- |
| Critical-Mineral Classification Composite | USGS, DOE | 0.28 | Daily |
| Operational Distress Composite | SEC filings, news, regulatory portals | 0.20 | Daily + event-driven |
| Federal-Action Exposure Score | Federal Register, EO tracker, court orders | 0.18 | 5-minute cadence |
| Concession Health Score | County records, state registries | 0.14 | Daily |
| Capital-Raise Urgency | SEC filings, news | 0.10 | Per filing |
| DOD / IRA Eligibility | DOD directives, IRS guidance | 0.10 | Per announcement |
| **TOTAL** | | **1.00** | |
Module 3 IDOS scoring exhibits the highest signal volatility of the three modules — federal actions can move a basin's score by 30+ points within minutes of Federal Register publication. The module's federal-action monitoring service feeds both the Layer 2 Classification oracle (for Control 42 freeze coordination) and the Layer 9 Module 3 IDOS pipeline.
***
### 6. Composite IDOS Score Architecture
Each module produces its own IDOS score using module-specific weights. The composite score architecture is structurally identical across modules:
```
IDOS_module_raw = Σ (signal_score × signal_weight)
IDOS_module_final = IDOS_module_raw × OutreachPathwayMultiplier
```
Module 1 weights are documented in §3.6. Module 2 weights are documented in §4.4. Module 3 weights are documented in §5.5. The weights are calibrated empirically per module and reviewed quarterly by the platform's intelligence team. The architecture allows future modules to be added without restructuring the IDOS formula — each new module gets its own weighting profile.
| Module | Raw IDOS Range | Typical Score Distribution |
| ---------------------- | -------------- | ------------------------------------------------------------------ |
| Module 1 — Equities | 0–100 | Long-tail; \~5% of universe scores >80 |
| Module 2 — Real Estate | 0–100 | Bimodal; distress-flagged properties cluster 70–95 |
| Module 3 — CORECM | 0–100 | Volatility-driven; classifications shift score range significantly |
Each module's priority queue is independent. A Module 1 issuer scoring 92 and a Module 3 basin scoring 92 are on parallel tracks; outreach automation processes each module's queue in parallel without cross-module priority interference.
***
### 7. Outreach Pathway Multipliers
The composite IDOS score is adjusted by a multiplier reflecting the quality of the existing relationship between the platform and the issuer's transfer agent. The multiplier applies uniformly across all three modules.
| Classification | Multiplier | Criteria |
| --------------- | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Direct Referral | 2.0x | Empire Stock Transfer client confirmed + (Module 1: 10,000+ shareholders of record; Module 2: stabilized property with existing valuation; Module 3: classified critical mineral) |
| Warm Lead | 1.5x | Empire Stock Transfer client confirmed, any other criteria |
| Cold Prospect | 1.0x | No existing Empire or platform relationship on file |
#### Why Empire Clients Score Higher
Empire Stock Transfer serves 530+ publicly traded companies and has expanded relationships into the real-estate single-asset entity space and the basin-asset entity space. Companies and entities already in Empire's client base have an existing custody relationship — the most complex part of ST22 onboarding is already in place. Conversion from Empire client to ST22 issuer requires significantly less legal and operational work, producing higher conversion rates and shorter onboarding timelines, regardless of module.
***
### 8. Dynamic Priority Queue
The IDOS engine maintains continuously ordered priority queues — one per module — across the target universes. Outreach automation consumes from the head of each queue in parallel.
```
MODULE 1 QUEUE (Equities — continuously ranked)
├─ Position 1: IDOS = 92.4 │ Bankruptcy 8-K + 15K shareholders + Empire client
├─ Position 2: IDOS = 87.1 │ Dark company + high LDI + Form D expired
└─ Position 15K: IDOS = 3.1 │ Healthy company, active market
MODULE 2 QUEUE (Real Estate — continuously ranked)
├─ Position 1: IDOS = 89.6 │ CMBS watchlist + lis pendens + Empire warm lead
├─ Position 2: IDOS = 84.2 │ Lease cluster expiring + price-reduction signal
└─ Position N: IDOS = ... │
MODULE 3 QUEUE (CORECM — continuously ranked)
├─ Position 1: IDOS = 91.8 │ DOE high-priority + capex gap + Empire warm
├─ Position 2: IDOS = 86.4 │ USGS critical mineral + permit-renewal lag
└─ Position N: IDOS = ... │
```
#### Queue Properties
| Property | Module 1 | Module 2 | Module 3 |
| ----------------- | ------------------------------------------------- | ---------------------------- | ------------------------------------------------ |
| Universe depth | 15,000+ issuers | 10,000+ properties (growing) | 1,000+ basins / concessions (growing) |
| Storage | Memory-resident with persistent backing | Same | Same |
| Re-ranking | Continuous — any new data point triggers re-sort | Same | Same — federal actions trigger immediate re-sort |
| Top targets | Rolling top 50–100 | Rolling top 30–50 | Rolling top 20–40 |
| Outreach dispatch | Automated — highest IDOS consumed from queue head | Same | Same |
| Trigger delay | < 2 minutes from threshold breach | < 2 minutes | < 5 minutes (federal-action verification window) |
***
### 9. Investor-Side Wallet Profiling
The module profiles on-chain wallet behavior to identify and target verified wallets on Solana for ST22 offering notifications. Wallet profiling operates module-agnostically — the same wallet may participate in Module 1, Module 2, and Module 3 offerings provided the wallet's eligibility profile matches the offering's exemption.
#### 9.1 Behavioral Signals
| Signal | Source | Indicates |
| ---------------------------------- | ---------------------------------- | ------------------------------------------ |
| Historical transaction volume | Solana on-chain | Investment capacity |
| DeFi protocol participation | Solana on-chain | Financial sophistication |
| Token portfolio diversity | Solana on-chain | Investment breadth |
| Stablecoin holdings (USDC / PYUSD) | Solana on-chain | Available capital for ST22 purchase |
| Empire verification status | Empire MSF | Already KYC-verified — conversion-ready |
| Empire eligibility flags | Empire MSF | Reg D / Reg S / Reg CF eligibility profile |
| GROO staking status | Platform staking contract | Platform-engaged — high conversion |
| Previous ST22 participation | CEDEX trading history (per module) | Repeat investor — highest conversion |
#### 9.2 Eligibility-Aware Targeting
The module profiles wallets across three eligibility tracks corresponding to the platform's offering exemptions:
| Track | Verification Source | Target Offerings |
| --------------------- | --------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| Reg D (US accredited) | Empire accreditation verification | Module 1 / 2 / 3 Reg D primary offerings |
| Reg S (non-US) | Empire non-US-person verification | Module 1 / 2 / 3 Reg S primary offerings |
| Reg CF (US retail) | Empire Reg CF investor-cap verification | Module 1 / 2 / 3 Reg CF primary offerings (when conducted via FINRA-registered funding portal partnership) |
A single wallet may carry multiple eligibility flags (for example, US Reg D plus Reg CF tracks). The targeting engine matches wallets to offerings by eligibility intersection.
#### 9.3 Wallet Engagement Score
The module generates a Wallet Engagement Score (WES) for Solana wallets matching the platform's investor profiles:
```
WES = f(tx_volume, defi_activity, stablecoin_balance,
empire_verified, eligibility_profile, groo_staked, st22_history)
WES > 0.80: High-priority targeting — personalized notification
WES 0.50–0.80: Standard targeting — offering announcement
WES < 0.50: Monitor only — no active outreach
```
#### 9.4 Compliance Constraint
All investor targeting operates within the relevant offering exemption parameters — Reg D (US accredited), Reg S (non-US), or Reg CF (US retail). The module enforces this programmatically, filtering wallet profiles through the offering's eligibility criteria before any outreach sequence triggers. Wallets that cannot be verified as matching the offering's eligibility profile are excluded from that offering's targeting — no exceptions.
***
### 10. Launch Readiness Score
For issuers in the active onboarding pipeline, the module generates a Launch Readiness Score (LRS) assessing optimal offering timing based on market conditions, investor demand signals, and platform capacity. The LRS is module-aware — Module 2 and Module 3 LRS scores incorporate module-specific oracle signals.
#### 10.1 LRS Inputs
| Input | Source | Module 1 Weight | Module 2 Weight | Module 3 Weight |
| ----------------------------------------------------- | ------------------------------------------------------------------------------- | --------------- | --------------- | --------------- |
| Investor demand signals | Wallet profiling — interested wallets for issuer category | 0.30 | 0.28 | 0.26 |
| Solana network conditions | Gas fees, congestion, block reliability | 0.20 | 0.18 | 0.16 |
| CEDEX liquidity depth | Current Global Pool TVL and depth per trading pair | 0.20 | 0.18 | 0.16 |
| Similar issuer performance | Recent ST22 offering conversion rates for comparable issuers in the same module | 0.15 | 0.16 | 0.14 |
| Macro sentiment | Stablecoin inflow / outflow on Solana | 0.15 | 0.10 | 0.10 |
| **Module 2: NAV trajectory and reappraisal currency** | NAV oracle | — | 0.10 | — |
| **Module 3: Federal-action posture stability** | Classification oracle | — | — | 0.18 |
| **TOTAL** | | **1.00** | **1.00** | **1.00** |
#### 10.2 LRS Thresholds
| LRS | Recommendation | Action |
| --------- | -------------------- | ----------------------------------------------------------- |
| > 0.80 | Strong launch window | Expedited investor notification sequence (first 72 hours) |
| 0.60–0.80 | Favorable conditions | Standard launch timing |
| 0.40–0.60 | Acceptable | Launch proceeds with standard expectations |
| < 0.40 | Suboptimal | Recommend delay — investor demand or market conditions weak |
LRS updates every 4 hours, with real-time updates triggered by significant Solana congestion events, large stablecoin movements, NAV oracle updates (Module 2), or federal-action events (Module 3).
***
### 11. Staking Tier Access Gates
AI Module features are gated behind active GROO staking. Staking gates apply uniformly across all three modules — a Gold-tier staker has the same Module 1, Module 2, and Module 3 IDOS access.
| Staking Tier | Minimum Stake | AI Module Access |
| ------------ | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| Bronze | 1,000 GROO | IDOS dashboard read-only — top 500 issuers per module |
| Silver | 10,000 GROO | Full IDOS access (all three modules) + weekly AI-generated prospect report |
| Gold | 50,000 GROO | Full module-specific NLP engines (EDGAR for Module 1; REIT-NLP for Module 2; USGS/DOE feeds for Module 3) + tier alerts + investor-pool analytics |
| Platinum | 100,000 GROO | Complete suite: real-time feeds across all modules, IDOS priority queues, Launch Readiness Score, wallet profiling, outreach automation |
#### Why Staking Gates Exist
Staking gates serve three purposes: they generate staking demand for GROO (driving the 1.5% fee distribution), they ensure module users have economic alignment with the platform (staked GROO = skin in the game), and they create tiered value that rewards larger participants with more sophisticated tooling. The gates apply identically regardless of which module(s) the staker is targeting.
***
### 12. Per-Operation Token Burns
Individual AI Module operations carry GROO token burn costs. Burns execute at the smart-contract level, are irreversible, and are permanently recorded on chain. The burn schedule is module-aware — operations on more data-intensive modules carry slightly higher burn costs.
| AI Module Operation | GROO Burned | Module Scope |
| ------------------------------------------------------- | ---------------- | ------------------------------------------------------------------- |
| EDGAR batch query execution (per 500 records) | 1,000 GROO | Module 1 |
| OTC Markets feed refresh subscription (monthly) | 50 GROO | Module 1 |
| REIT-NLP batch query execution (per 500 records) | 1,000 GROO | Module 2 |
| County-records refresh subscription (monthly per state) | 50 GROO | Module 2 |
| USGS / DOE batch query execution (per 500 records) | 1,000 GROO | Module 3 |
| Federal-action subscription (continuous) | 100 GROO / month | Module 3 |
| Investor wallet behavioral report (per ST22 offering) | 250 GROO | All modules |
| Launch Readiness Score analysis (per deployment) | 500 GROO | All modules (Module 2 / 3 incorporate module-specific oracle reads) |
| Full IDOS universe refresh cycle (per module) | 1,000 GROO | Per module |
| Automated outreach sequence launch (per issuer) | 750 GROO | All modules |
#### Deflationary Impact
As AI Module usage grows across all three modules — more issuers analyzed, more investors targeted, more offerings launched — circulating GROO supply decreases permanently. Combined with the 2% staking-reinvestment lock (which removes GROO from circulation into the Global Pool), the effective circulating supply trends downward while staking demand trends upward.
```
MORE ISSUERS (M1+M2+M3) → MORE AI OPERATIONS → MORE BURNS → LOWER SUPPLY
↑ │
│ ▼
BETTER AI ACCURACY ←──── TRAINING DATA (3 modules) ◄─── HIGHER STAKING
│ VALUE
▼ ▲
LOWER ACQUISITION MORE ATTRACTIVE PLATFORM │
COSTS PER MODULE FOR NEXT ISSUER + INVESTOR ───────────────┘
```
***
### 13. Data Moat and Competitive Defensibility
Every campaign executed, every issuer conversion or non-conversion, every investor wallet interaction, and every ST22 offering outcome feeds back into the module's training data. The module improves continuously with platform scale. The data moat compounds across modules — a wallet that participates in Module 1 issuances generates training data that improves Module 2 and Module 3 wallet profiling accuracy for the same investor profile.
#### Three-Module Flywheel
```
ISSUER CONVERSION (M1+M2+M3) → ST22 TRADING VOLUME → FEE REVENUE
↑ │
│ ▼
BETTER AI ACCURACY ◄── TRAINING DATA ◄── DEEPER GLOBAL POOL
(per-module) (single shared pool —
│ all modules contribute)
▼ ▼
LOWER ACQUISITION COSTS MORE ATTRACTIVE PLATFORM
PER MODULE FOR NEXT ISSUER + INVESTOR
```
After 500 ST22 launches across the three modules, the platform will have accumulated a dataset on Digital Securities investor behavior, issuer conversion patterns, and offering timing correlations that no competitor can replicate without operating at equivalent scale across multiple asset classes. This dataset constitutes a structural moat: the AI's accuracy improves as the platform grows, which improves commercial outcomes, which accelerates growth — compounding with each issuer onboarded across each of the three modules.
***
### 14. Performance Specifications
| Metric | Specification | Module Scope |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------------- | ------------ |
| IDOS refresh — 8-K trigger (Module 1) | < 60 seconds from EDGAR RSS publication to score update | Module 1 |
| IDOS refresh — federal-action event (Module 3) | < 5 minutes from Federal Register publication to score update | Module 3 |
| IDOS full universe refresh (per module) | Every 24 hours + continuous partial refresh on real-time events | All modules |
| EDGAR full-text search throughput | 1,000 CIKs per batch cycle | Module 1 |
| REIT filing batch throughput | 500 REITs per batch cycle | Module 2 |
| USGS / DOE batch throughput | Full target universe per daily batch | Module 3 |
| OTC Markets tier change detection | Near real-time (15-minute polling) | Module 1 |
| County-records refresh | Daily per state | Module 2 |
| Federal Register polling cadence | 5 minutes | Module 3 |
| Investor wallet profile refresh | Every 6 hours + event-driven on large on-chain movements | All modules |
| Launch Readiness Score | Every 4 hours + real-time on Solana congestion / NAV / federal-action events | All modules |
| Priority queue depth | 15,000 (Module 1) + 10,000 (Module 2) + 1,000 (Module 3); memory-resident with persistent backing | Per module |
| Empire cross-reference match | < 5 seconds on new issuer ingestion | All modules |
| Outreach sequence trigger delay | < 2 minutes (Module 1, 2); < 5 minutes (Module 3) | Per module |
***
### 15. Regulatory and Privacy Considerations
#### 15.1 Data Sources — All Public
| Source | Public? | Licensing | Module Scope |
| ----------------------------------- | ---------------------------------------------- | ------------------------------------------------------ | ------------------------------------ |
| SEC EDGAR | Yes — operated for universal public access | No license required | Module 1 (primary), Module 2 (REITs) |
| OTC Markets Group | Yes — market infrastructure data | Public tier data free; enhanced feeds via subscription | Module 1 |
| County recorder filings | Yes — public records | Per-county access (free or fee-based) | Module 2 |
| MLS data | Yes — within license terms | Per-MLS license required | Module 2 (where licensed) |
| EPA / state environmental databases | Yes — public records | Free | Module 2 |
| USGS Critical Minerals List | Yes — public | Free | Module 3 |
| DOE Critical Materials Strategy | Yes — public | Free | Module 3 |
| Federal Register | Yes — public | Free | Module 3 |
| Solana blockchain | Yes — all on-chain data is public | No license required | All modules |
| LinkedIn / public web | Yes — publicly available professional profiles | Standard web access | All modules |
#### 15.2 Privacy Compliance
| Requirement | Implementation |
| ----------------------------- | ----------------------------------------------------------------------------------------------- |
| Issuer data | All from public sources — no non-public information |
| Investor wallet data | On-chain Solana data (inherently public) |
| Off-chain identity enrichment | Limited to publicly available professional sources |
| Investor outreach | CAN-SPAM Act compliant; GDPR Article 6(1)(f) legitimate interest |
| Offering notifications | Reg D, Reg S, and Reg CF general solicitation parameters enforced programmatically per offering |
| PII handling | Module does not store SSN, payment cards, or health information |
| Data retention | Subject to the platform's Privacy Policy and annual compliance audit |
#### 15.3 Reg D / Reg S / Reg CF Compliance Gate
The AI Module enforces offering-exemption compliance programmatically. All investor targeting filters through the relevant offering's eligibility criteria before outreach:
* **Reg D offerings:** wallets must be verified accredited investors via Empire's accreditation verification.
* **Reg S offerings:** wallets must be verified non-US persons via Empire's non-US-person verification.
* **Reg CF offerings:** wallets must satisfy Empire's Reg CF investor-cap verification per 17 CFR §227.100(a)(2), and offerings must be conducted through a FINRA-registered funding portal partnership.
Wallets that cannot be verified as matching the offering's eligibility profile are excluded from all targeting sequences for that offering. This is a code-enforced gate, not a policy. Module-aware: the same gate applies to Module 1, Module 2, and Module 3 offerings — only the eligibility profile required varies by exemption, not by module.
***
### Related Documentation
* **Whitepaper V8 Section 9** — AI Module complete technical specification.
* **Oracle Integration Guide** — EDGAR pipeline (Module 1), NAV oracle (Module 2), Classification oracle (Module 3) — all shared with Layer 2.
* **Tokenomics Deep Dive** — Staking tiers, burn mechanics, fee distribution.
* **Issuer Onboarding Guide** — 9-stage process that the AI Module feeds into; module-specific onboarding variations.
* **Empire Stock Transfer Integration** — Empire client cross-reference for outreach multipliers; module-aware custody coverage.
* **Compliance Integration Guide** — Regulatory mapping including module-specific compliance and federal-action coordination.
* **Transfer Hook Reference** — The 42 controls that the AI Module does not interact with at runtime.
***
*RWA Tokens · AI and IDOS Module · Groovy Company, Inc.*
# Tokenomics Deep Dive
# Governance Deep Dive
## Governance Deep Dive
**Authority Structure · Immutable vs Adjustable · Multi-Sig Execution · Proposal Lifecycle · Control 42 · Module-Aware**
Complete governance architecture for the RWA Tokens platform — who can change what, how changes are authorized, what is permanently immutable, and how governance integrates with the 42 Transfer Hook security controls. The platform is operated by Groovy Company, Inc. (Wyoming domicile; principal office 600 W Peachtree St NW, Suite 1700, Atlanta, GA 30308; CIK 1499275; OTC: GROO). Governance covers all three production modules — Equities (Module 1), Real Estate (Module 2), and CORECM — Carbon Ore, Rare Earth, and Critical Minerals (Module 3) — with module-aware parameter scopes documented in each section. Written for institutional evaluators, auditors, regulators, and the executive team.
***
### Table of Contents
1. Governance Philosophy
2. Why Not Token-Based DAO Governance
3. Immutable Parameters — What Cannot Be Changed
4. Adjustable Parameters — What Can Be Changed
5. Corporate Governance Layer
6. Multi-Sig Architecture
7. Timelock Mechanism
8. Proposal Types and Lifecycle
9. Parameter Adjustment Flow
10. Smart Contract Upgrade Protocol
11. Control 42 — Regulatory Compliance Freeze
12. Pool Governance
13. Governance Boundaries Diagram
14. Emergency Response Governance
15. Transparency and Reporting
16. Module-Aware Governance Surface
17. Governance FAQ
18. On-Chain Verification
***
### 1. Governance Philosophy
The platform's governance reflects a single principle: parameters that protect investors must be structurally impossible to change, while parameters that affect platform economics must be adjustable within defined bounds by accountable human decision-makers operating under identified security controls. This principle applies uniformly to Module 1, Module 2, and Module 3 — module-specific parameters follow the same immutable-versus-adjustable discipline as cross-module parameters.
This produces a two-tier architecture:
```
┌──────────────────────────────────────────────────────────────────┐
│ IMMUTABLE TIER │
│ │
│ 42 Transfer Hook controls · 1:1 backing · LP burn · OFAC/AML │
│ Reg D / Reg S / Reg CF holding periods · 4.99% wallet limit │
│ 2% staking reinvestment · 5% total fee · pool immutability │
│ Module 2: NAV-deviation enforcement (CB-21 extension) │
│ Module 3: federal-action freeze coordination (REG-42 extension) │
│ │
│ CANNOT BE CHANGED BY ANY PARTY — including Groovy Company, Inc. │
│ Mathematical property of deployed smart contracts │
└──────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────┐
│ ADJUSTABLE TIER │
│ │
│ TWAP window · price impact threshold · fee distribution ratios │
│ circuit breaker cooldown · AML review threshold · TWAP sigma │
│ Module 2: nav_deviation_max_bps · nav_reappraisal_max_age_secs │
│ Module 3: classification_max_age_secs · federal_action toggle │
│ │
│ Adjustable WITHIN DEFINED BOUNDS by named officers, board │
│ resolution, multi-sig execution, 48h timelock, audit attestation │
└──────────────────────────────────────────────────────────────────┘
```
#### The Institutional Question
For an institutional investor or regulator reviewing the platform, the question is not "who controls governance?" — it is "what is the worst case if governance fails or is compromised?"
An immutable security control has no worst case: it cannot be compromised because it cannot be changed. Every governance mechanism — however well designed — introduces a pathway through which protections could theoretically be weakened. Removing that pathway entirely is the strongest institutional assurance available. This applies equally to the Module 2 NAV-deviation enforcement and the Module 3 federal-action freeze coordination — both are immutable extensions of the 42 controls, governable only through the same supermajority program-upgrade procedure that protects every other control.
***
### 2. Why Not Token-Based DAO Governance
The platform deliberately rejects anonymous token-based DAO governance for security-critical decisions. This applies uniformly to Module 1, Module 2, and Module 3.
| Property | Token-Based DAO | Groovy Company, Inc. Corporate Governance |
| ------------------- | ------------------------------------------------- | ------------------------------------------------------------------ |
| Accountability | Anonymous token holders — no legal identity | Named officers, sole director, SEC-reporting entity (CIK: 1499275) |
| Legal standing | Ambiguous — DAOs face SEC scrutiny | Clear — Wyoming corporation with identified officers |
| Securities risk | Governance token may itself be a security | No governance token exposure — GROO is utility only |
| Attack surface | Flash loan governance attacks, whale accumulation | Multi-sig with geographically distributed key holders |
| Audit trail | On-chain votes (pseudonymous) | Board resolutions + on-chain multi-sig + SEC filings |
| Speed | Days–weeks for voting period | 48h timelock (standard) or immediate (emergency) |
| Investor protection | Majority can vote to weaken protections | 42 controls are immutable — governance cannot weaken them |
GROO staking provides platform utility (fee discounts, AI Module access including Module 1 / 2 / 3 IDOS pipelines, staking rewards) — not governance voting power over security-critical parameters. Protocol governance is corporate governance: transparent, accountable, and subject to securities law.
***
### 3. Immutable Parameters — What Cannot Be Changed
These parameters are embedded in the platform's immutable on-chain programs. No corporate resolution, no multi-sig execution, no legal process, and no technical action can modify them without deploying an entirely new smart-contract program — which would require investors to migrate to a new token, breaking the existing custody and ownership chain. The same immutability discipline applies to every module.
#### 3.1 Cross-Module Immutable Parameters
| Parameter | Status | Why Immutable |
| ---------------------------------------------------------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 42 Transfer Hook security controls | Immutable — on-chain program | Core investor protection — no pathway to weaken |
| 1:1 token-to-asset backing (Controls CV-01 to CV-06) | Immutable | Any relaxation would allow unbacked token creation |
| LP token burn (Global Pool) | Immutable — pool contract | No withdrawal function exists in bytecode |
| Pool program upgrade authority | None — program is immutable | Liquidity pool cannot be upgraded, only migrated under emergency protocol |
| OFAC / SDN screening per transfer (Controls SC-30 to SC-34) | Immutable | Federal sanctions compliance — cannot be disabled |
| AML risk scoring per transfer (Control IV-09) | Immutable | BSA compliance — cannot be disabled |
| Accreditation verification per transfer (Controls IV-07 / IV-08) | Immutable | Reg D / Reg S / Reg CF compliance — cannot be disabled |
| Reg D / Reg S / Reg CF holding periods (Control HP-24) | Immutable | Statutory minimum — cannot be shortened (Reg D 6mo / Reg S 12mo / Reg CF 12mo) |
| 5% total transaction fee rate | Immutable — Token-2022 Transfer Fee Extension | Configured at mint creation — cannot be changed post-mint |
| 2% staking reinvestment to Global Pool | Immutable — hardcoded in Transfer Hook | `LP_REINVESTMENT_BPS` is a program constant — not configurable |
| 4.99% wallet concentration default ceiling (Control PL-16) | Immutable as program constant | Anti-manipulation ceiling — Module 2 may be issuer-configured up to 9.99% within program-defined upper bound (no governance can exceed the upper bound) |
| Transfer Hook address on each mint | Immutable — SPL Token-2022 standard | Set at mint creation — permanently stored in mint account |
#### 3.2 Module 2 — Real Estate Immutable Parameters
| Parameter | Status | Why Immutable |
| ----------------------------------------------------------- | -------------------------------- | ------------------------------------------------------------------------------------ |
| NAV-deviation circuit-breaker enforcement (CB-21 extension) | Immutable as a control mechanism | Cannot be disabled by governance; only the deviation tolerance bounds are adjustable |
| NAV oracle Ed25519 signature requirement | Immutable | Appraisals must be signed by an authorized appraiser; governance cannot waive |
| Single-asset entity backing requirement | Immutable | Each Module 2 mint must back a single-asset entity holding the underlying property |
#### 3.3 Module 3 — CORECM Immutable Parameters
| Parameter | Status | Why Immutable |
| ----------------------------------------------------- | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| Federal-action freeze coordination (REG-42 extension) | Immutable as a control mechanism | Cannot be disabled by governance; only the freeze enablement toggle (per mint) is adjustable, and it defaults to enabled |
| Classification oracle Ed25519 signature requirement | Immutable | Federal-action attestations must be signed by the Classification relay authority |
| Basin-asset entity backing requirement | Immutable | Each Module 3 mint must back a basin-asset entity holding the underlying mineral basin or concession |
| 60-minute federal-action freeze SLA | Immutable as an operational requirement | Documented in the Incident Response Playbook §13; governance cannot extend |
#### What "Immutable" Means Technically
These parameters exist in the deployed on-chain program binary. The Liquidity Pool program has no upgrade authority — `solana program show ` returns `Authority: none`. The Transfer Hook program has a 5-of-9 upgrade authority, but any upgrade must preserve all 42 controls (enforced by audit attestation requirement and Certora invariant E.4) and cannot modify hardcoded constants like `LP_REINVESTMENT_BPS` or the holding-period seconds for any of the three exemption regimes. The same holds for the Module 2 NAV-deviation enforcement and the Module 3 federal-action freeze coordination — these are control extensions written into Transfer Hook bytecode that cannot be removed by any upgrade.
***
### 4. Adjustable Parameters — What Can Be Changed
These parameters may be adjusted within defined bounds. All adjustments require multi-sig execution and a 48-hour on-chain timelock. No parameter can be adjusted outside its range in a single governance action — preventing incremental boundary erosion. Module-specific parameters follow the same governance discipline as cross-module parameters.
#### 4.1 Cross-Module Adjustable Parameters
| Parameter | Current Default | Adjustment Range | Multi-Sig | Timelock | Module Scope |
| ------------------------------ | ------------------------ | ------------------------ | --------- | -------- | ------------ |
| TWAP calculation window | 30 minutes | 15–60 minutes | 3-of-5 | 48 hours | All modules |
| Maximum price impact per trade | 2% | 1–5% | 3-of-5 | 48 hours | All modules |
| Fee distribution ratios | 200 / 150 / 106 / 44 bps | Max 10% shift per action | 3-of-5 | 48 hours | All modules |
| Circuit breaker cooldown | 24 hours | 12–72 hours | 3-of-5 | 48 hours | All modules |
| AML enhanced review threshold | Score 31 | 25–45 | 3-of-5 | 48 hours | All modules |
| TWAP outlier rejection sigma | 3σ | 2–5σ | 3-of-5 | 48 hours | All modules |
#### 4.2 Module 2 Adjustable Parameters
| Parameter | Default | Adjustment Range | Multi-Sig | Timelock | Notes |
| ------------------------------ | -------------------------------- | --------------------------------------------------------- | --------- | -------- | --------------------------------------------------------- |
| `nav_deviation_max_bps` | Per mint, typically 2200 (22%) | Per-mint range set at issuance under tripartite agreement | 3-of-5 | 48 hours | Adjustments require issuer concurrence under tripartite |
| `nav_reappraisal_max_age_secs` | Per mint, per tripartite cadence | Per-mint range set at issuance | 3-of-5 | 48 hours | Tied to the property's reappraisal schedule |
| `nav_circuit_breaker_enabled` | true | true / false | 5-of-9 | 48 hours | Disabling requires elevated threshold; default is enabled |
#### 4.3 Module 3 Adjustable Parameters
| Parameter | Default | Adjustment Range | Multi-Sig | Timelock | Notes |
| ------------------------------- | -------------------------------- | ------------------------------ | --------- | -------- | -------------------------------------------------------------------------------- |
| `classification_max_age_secs` | Per mint, typically 86,400 (24h) | Per-mint range set at issuance | 3-of-5 | 48 hours | Stricter values require closer Classification oracle monitoring |
| `federal_action_freeze_enabled` | true | true / false | 5-of-9 | 48 hours | Disabling requires elevated threshold; default is enabled and routinely retained |
#### Bounds Are Hard Limits
Each adjustable parameter has a hard-coded minimum and maximum. A governance proposal to set the TWAP window to 5 minutes (below the 15-minute minimum) is rejected by the smart contract — not by policy, but by code. A governance proposal to set `nav_deviation_max_bps` outside the per-mint range registered at issuance is rejected by the smart contract. If market conditions require a parameter to move beyond its range, a full program upgrade is required (see §10).
#### Maximum Rate of Change
No single governance action can shift a parameter by more than the defined step size. For fee distribution ratios, the maximum shift is 10% per proposal. Moving from the current 200/150/106/44 split to a hypothetical 250/150/56/44 split (a 25% shift in the issuer allocation) would require three separate governance actions across three timelock periods — a minimum of 6+ days. The same step-size discipline applies to module-specific parameters.
***
### 5. Corporate Governance Layer
All material protocol decisions originate at the corporate governance level of Groovy Company, Inc. This is not a decentralized protocol with anonymous governance — it is a public company (CIK: 1499275; OTC: GROO) with named officers and board-level accountability. The corporate governance layer is module-agnostic — the same officers, the same authority hierarchy, and the same decision flow apply to Module 1, Module 2, and Module 3 actions.
#### Authority Hierarchy
```
GROOVY COMPANY, INC. (Wyoming domicile; principal office Atlanta, GA)
CIK: 1499275 · OTC: GROO
│
│ PNXP holds 51% of GROO
│
├─ BOARD OF DIRECTORS (sole director: Frank Yglesias)
│ └─ Approves: material changes to platform economics,
│ security posture, issuer onboarding standards (cross-module),
│ smart-contract upgrades, and Module 2 / Module 3 charters
│
├─ Frank Yglesias — Chairman of the Board, CTO, sole director
│ └─ Strategic authority, technical authority over smart-contract
│ upgrades and security architecture decisions
│
├─ Patrick Mokros — COO of Groovy Company, Inc.,
│ Founder of Empire Stock Transfer
│ └─ Operational authority over parameter adjustments within
│ pre-approved bounds; Empire-side custody and onboarding
│
├─ Jhony Navarro — Engineering (CTO-level engineering, not a director)
│ └─ Engineering execution under Frank's technical authority
│
└─ Legal Counsel
└─ Legal authority over regulatory compliance, Control 42
authorization (including Module 3 federal-action freezes),
SEC engagement
```
#### Decision Flow
```
1. NEED IDENTIFIED (engineering, operations, or compliance)
Module-aware: parameter need may be cross-module
or Module 1 / Module 2 / Module 3 specific
2. CORPORATE DECISION
├─ Cross-module parameter adjustment → COO / CTO authority (within bounds)
├─ Module 2 NAV-bound adjustment → COO / CTO + tripartite concurrence
├─ Module 3 classification-age adjustment → COO / CTO authority (within bounds)
├─ Fee structure change → Board resolution required
├─ Program upgrade → Board resolution + CTO approval
├─ Emergency action → Incident Commander authority
└─ Regulatory freeze → Legal Counsel authority
(Module 3 federal-action freezes use this path with 60-min SLA)
3. ON-CHAIN EXECUTION
├─ Multi-sig signers assembled
├─ Transaction submitted
├─ Timelock begins (48h standard, 0 for emergency)
└─ Activation after timelock
4. DISCLOSURE
├─ On-chain record (automatic, immutable)
├─ SEC EDGAR filing (if material)
├─ Issuer notification (within 48h)
└─ Investor notification (via Empire channels)
```
***
### 6. Multi-Sig Architecture
Every on-chain governance action requires multi-signature authorization. No single individual — regardless of title or authority — can unilaterally modify any platform parameter. The same multi-sig architecture serves Module 1, Module 2, and Module 3 actions.
#### Multi-Sig Wallets
| Wallet | Threshold | Signers | Purpose |
| ------------------- | ---------------------- | -------------------------------------------------- | ----------------------------------------------------------------------------------- |
| Upgrade Authority | 5-of-9 | Geographically distributed across 5+ jurisdictions | Transfer Hook, AMM, Oracle Aggregator program upgrades — affecting all modules |
| Parameter Authority | 3-of-5 | Authorized officers + designated key holders | Fee ratios, thresholds, cooldowns, module-specific NAV / classification parameters |
| Emergency Authority | 3-of-5 + Legal Counsel | Same as Parameter + Legal Counsel authorization | Control 42 regulatory freeze, including Module 3 federal-action freeze coordination |
#### Signer Rules
| Rule | Enforcement |
| ------------------------------------------------------------- | ------------------------------------------------ |
| No signer holds more than one position in any quorum | Policy + verification at key registration |
| Key holders are geographically distributed | Minimum 3 jurisdictions for 5-of-9 |
| Keys stored on Ledger Enterprise HSMs | Hardware security modules — not software wallets |
| Key rotation follows the same threshold as authorized actions | Rotating a 5-of-9 key requires 5-of-9 approval |
| New signers require board resolution | Corporate governance gate |
#### Why 5-of-9 for Upgrades
Program upgrades modify executable code. The elevated threshold (5-of-9 versus 3-of-5 for parameters) reflects the elevated risk: a malicious upgrade could theoretically weaken compliance controls — including the Module 2 NAV-deviation enforcement and the Module 3 federal-action freeze coordination. The 5-of-9 requirement means an attacker would need to compromise 5 geographically distributed HSM-backed keys simultaneously — while also passing an independent security audit attestation requirement and Certora invariant E.4 verification.
***
### 7. Timelock Mechanism
Every non-emergency governance action is subject to an on-chain timelock — a mandatory waiting period between authorization and execution. During the timelock, the pending action is visible on chain and can be inspected by anyone. The timelock applies uniformly across modules — a Module 2 NAV-bound adjustment goes through the same 48-hour observation window as a cross-module TWAP adjustment.
#### Timelock Configuration
| Action Type | Timelock | Cancellation | Rationale | Module Scope |
| ---------------------------------------------------------- | -------------------- | -------------------------------------------------- | ------------------------------------------------------------ | ------------------- |
| Parameter adjustment | 48 hours | 2-of-5 during window | Allow observation, review, and intervention | All modules |
| Module-specific parameter adjustment (Module 2 / Module 3) | 48 hours | 2-of-5 during window | Same — module-specific changes follow standard discipline | Module 2 / Module 3 |
| Program upgrade | 48 hours | 2-of-5 during window | Same + independent security review time | All modules |
| Emergency circuit breaker | None — immediate | N/A | Time-critical — active exploit or regulatory order | All modules |
| Control 42 freeze (cross-module) | None — immediate | Same process to unfreeze (Legal Counsel + 3-of-5) | Legal compliance — cannot delay court orders | All modules |
| Control 42 freeze (Module 3 federal-action) | None — 60-minute SLA | Same process to lift after federal action resolves | Federal action requires immediate response | Module 3 |
| Emergency pool migration | 48 hours | 2-of-5 during window | Catastrophic vulnerability only — still requires observation | All modules |
#### Timelock Lifecycle
```
T=0h Multi-sig submits governance transaction
├─ Transaction visible on chain
├─ Anyone can inspect the pending change
└─ 48-hour countdown begins
T=0-48h OBSERVATION WINDOW
├─ Community can review
├─ Independent auditors can verify
├─ Legal Counsel can intervene
└─ 2-of-5 can CANCEL if issue discovered
T=48h ACTIVATION
├─ No further action needed — automatic
├─ Parameter change takes effect
└─ On-chain record created (permanent)
```
#### Cancellation
During the timelock window, 2-of-5 multi-sig holders can cancel a pending action. This serves as a safeguard — if the community, an auditor, or Legal Counsel identifies an issue with a pending governance action, it can be stopped before activation. The 2-of-5 cancellation threshold is deliberately lower than the execution threshold (3-of-5 or 5-of-9) to make it easier to stop a bad action than to execute one. The cancellation discipline applies uniformly to cross-module and module-specific actions.
***
### 8. Proposal Types and Lifecycle
#### Three Proposal Types
| Type | Threshold | Timelock | Additional Requirements | Use Case | Module Scope |
| ------------------- | ----------------------------------------------------------------------------- | ---------------- | ----------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | ------------ |
| ParameterAdjustment | 3-of-5 | 48 hours | Written record of approving authority | TWAP window, price impact, fee ratios, cooldowns; Module 2 NAV bounds; Module 3 classification age | All modules |
| ProgramUpgrade | 5-of-9 | 48 hours | Security audit attestation + board resolution + schema compatibility proof + Certora E.4 verification | Transfer Hook patch, AMM update, Oracle Aggregator update | All modules |
| EmergencyAction | 3-of-5 + Legal Counsel (for Control 42) or IC authority (for circuit breaker) | None — immediate | P0 incident declaration or legal process documentation | Regulatory freeze (including Module 3 federal-action), active exploit containment | All modules |
#### Proposal Lifecycle — ParameterAdjustment
```
1. INITIATION
└─ COO or CTO identifies need for parameter change
└─ Example A: "Increase TWAP window from 30 to 45 minutes" (cross-module)
└─ Example B: "Tighten nav_deviation_max_bps from 2200 to 2000 for mint X"
(Module 2)
└─ Example C: "Reduce classification_max_age_secs from 86400 to 43200
for mint Y" (Module 3)
2. AUTHORIZATION
└─ Written approval from authorizing officer
└─ Verified within adjustment bounds
(Example A: 15–60 min range → 45 min ✓)
3. ON-CHAIN SUBMISSION
└─ 3-of-5 multi-sig signers coordinate
└─ Transaction submitted to the governance program
└─ Proposal ID generated, visible on chain
4. TIMELOCK (48 hours)
└─ Pending change visible to all
└─ Cancellation possible (2-of-5)
5. ACTIVATION
└─ SecurityConfig (or per-mint NAVOracle / ClassificationOracle PDA)
updated for affected mint(s)
└─ GovernanceExecuted event emitted
└─ Immutable on-chain record
6. NOTIFICATION
└─ Affected issuers notified within 48 hours
└─ Investor notification via Empire channels
└─ SEC EDGAR filing if material
```
#### Proposal Lifecycle — ProgramUpgrade
```
1. ENGINEERING
└─ Upgrade proposal drafted with full code diff and rationale
└─ Module-aware coverage statement: any module-specific control
extensions (Module 2 NAV, Module 3 federal-action) are
explicitly preserved or extended in the proposal
2. SECURITY AUDIT (7–14 days)
└─ Independent audit by Quantstamp, Halborn, or OtterSec
└─ Audit attestation confirms:
├─ All 42 controls preserved at current specifications
├─ Module 2 NAV-deviation enforcement preserved
├─ Module 3 federal-action freeze coordination preserved
├─ Account schema compatibility (migrate function)
└─ No new vulnerabilities introduced
3. BOARD RESOLUTION
└─ Board of Directors approves upgrade submission
4. CTO REVIEW
└─ CTO confirms technical correctness and security posture
5. ON-CHAIN SUBMISSION
└─ 5-of-9 multi-sig executes upgrade proposal
└─ Proposal includes: new program binary hash, audit attestation
6. TIMELOCK (48 hours)
└─ New program binary visible for independent verification
└─ Cancellation possible (2-of-5)
7. ACTIVATION
└─ BPF loader deploys new program version
└─ Old version replaced atomically
└─ UpgradeExecuted event emitted
8. POST-UPGRADE VERIFICATION
└─ All 42 controls verified operational across all modules
└─ Certora re-verification (post-hoc) — invariants E.1 through E.6
└─ 48-hour enhanced monitoring
```
***
### 9. Parameter Adjustment Flow
#### Worked Example A — Adjusting TWAP Window (Cross-Module)
**Scenario.** Market analysis shows a 45-minute TWAP window would provide more stable circuit-breaker reference pricing across all modules.
```
STEP 1: COO (Patrick Mokros) reviews data and approves change
Current: 30 minutes (1,800 seconds)
Proposed: 45 minutes (2,700 seconds)
Range check: 15–60 minutes → 45 minutes is WITHIN bounds ✓
STEP 2: 3-of-5 multi-sig signers coordinate
Signer 1 (US East): signs via Ledger Enterprise
Signer 2 (US West): signs via Ledger Enterprise
Signer 3 (EU): signs via Ledger Enterprise
Threshold met: 3 of 5
STEP 3: Transaction submitted to the governance program
Instruction: adjust_parameter
Parameter: twap_window_secs
New value: 2700
Proposal ID: GOV-2026-047
STEP 4: 48-hour timelock begins
On-chain: GovernanceProposed { id: GOV-2026-047,
param: "twap_window_secs", value: 2700 }
Anyone can inspect: solana account --output json
STEP 5: 48 hours elapse — no cancellation
SecurityConfig.twap_window_secs updated to 2700 across all
active mints (Module 1, 2, and 3)
On-chain: GovernanceExecuted { id: GOV-2026-047 }
STEP 6: Notification
Issuers across all three modules notified of TWAP change
Next SEC filing includes parameter update disclosure
```
#### Worked Example B — Tightening Module 2 NAV Deviation
**Scenario.** A specific Module 2 mint shows a pattern of price drift narrower than the default 22% deviation tolerance; the issuer and platform agree to tighten the bound to 2000 bps (20%) under tripartite concurrence.
```
STEP 1: Tripartite concurrence
Issuer, Empire Stock Transfer, and Groovy Company, Inc. agree
in writing under the existing tripartite agreement
STEP 2: COO (Patrick Mokros) approves change for the affected mint
Current per-mint: 2200 bps (22%)
Proposed: 2000 bps (20%)
Range check: Per-mint range set at issuance — 2000 ✓
STEP 3: 3-of-5 multi-sig executes
Proposal ID: GOV-2026-052
STEP 4: 48-hour timelock + activation as in Example A
NAVOracle.deviation_tolerance_bps updated for the affected mint only
STEP 5: Notification
Affected issuer notified; investor notification via Empire
as the change tightens (stricter) protections
```
#### Rejection Example — Out-of-Bounds
```
ATTEMPT: Set TWAP window to 5 minutes (300 seconds)
Range check: 15–60 minutes → 5 minutes is BELOW minimum ✗
Smart contract rejects:
Error: GovernanceError::ParameterOutOfBounds
Message: "twap_window_secs 300 below minimum 900"
Transaction reverts. No state change. No timelock initiated.
```
The same out-of-bounds rejection applies to module-specific parameters. A proposal to set `nav_deviation_max_bps` outside the per-mint range registered at issuance, or to set `classification_max_age_secs` to a value outside the per-mint range, is rejected at the program level.
***
### 10. Smart Contract Upgrade Protocol
Program upgrades are the most sensitive governance action — they modify the executable code that enforces compliance on every ST22 transfer across all three modules.
#### Upgrade Requirements (ALL must be satisfied)
| Requirement | Purpose | Verified By |
| ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------- |
| Security audit attestation | Confirm no new vulnerabilities | Quantstamp, Halborn, or OtterSec |
| 42-control preservation attestation | Confirm no control weakened or removed | Audit firm |
| Module-aware preservation attestation | Confirm Module 2 NAV-deviation and Module 3 federal-action freeze coordination preserved | Audit firm |
| Account schema compatibility | New version handles all existing account schemas via `migrate()` — including module-specific PDAs (NAVOracle, ClassificationOracle) | Audit firm |
| Certora invariant E.4 verification | Formal-verification proof of control preservation | Certora Prover |
| Board resolution | Corporate governance approval | Board of Directors |
| CTO approval | Technical authority sign-off | CTO (Frank Yglesias) |
| 5-of-9 multi-sig | On-chain execution authorization | 5 of 9 geographically distributed signers |
| 48-hour timelock | Public observation window | On-chain timelock contract |
#### Upgrade Governance Flow
| Step | Action | Performer | Timeframe |
| ---- | -------------------------------------------------------------------------- | ------------------------------------- | ------------------- |
| 1 | Upgrade proposal drafted with full diff and rationale | Engineering team (Jhony Navarro lead) | Prior to submission |
| 2 | Independent security audit | Quantstamp / Halborn / OtterSec | 7–14 days |
| 3 | Audit attestation received | Auditing firm | On completion |
| 4 | Certora E.4 verification | Certora Prover | On audit completion |
| 5 | Board resolution approving upgrade | Board of Directors | Before submission |
| 6 | CTO technical approval | CTO | Before submission |
| 7 | 5-of-9 multi-sig executes proposal on chain | Authorized signers | After approvals |
| 8 | 48-hour timelock begins | On-chain timelock | Automatic |
| 9 | Upgrade activates | On-chain timelock | After 48 hours |
| 10 | Post-upgrade verification (42 controls + module-aware extensions, Certora) | Engineering + audit | Within 24 hours |
#### What An Upgrade Cannot Do
Even with a valid 5-of-9 multi-sig execution, a program upgrade cannot:
| Prohibited Action | Enforcement |
| ------------------------------------------------------------------------ | -------------------------------------------------------------- |
| Remove any of the 42 Transfer Hook controls | Audit attestation requirement; Certora invariant E.4 |
| Remove the Module 2 NAV-deviation enforcement | Audit attestation; Certora E.4 |
| Remove the Module 3 federal-action freeze coordination | Audit attestation; Certora E.4 |
| Reduce holding period below statutory minimum | Hardcoded constants — Reg D 6mo / Reg S 12mo / Reg CF 12mo |
| Raise wallet concentration above the program-defined upper bound (9.99%) | Hardcoded ceiling |
| Add a withdrawal function to the Pool program | Pool program has no upgrade authority — immutable |
| Disable OFAC screening | Hardcoded in Controls SC-30 to SC-34 |
| Create admin override for token transfers | Transfer Hook architecture has no `forceTransfer()` equivalent |
***
### 11. Control 42 — Regulatory Compliance Freeze
Control 42 is the only mechanism by which specific wallets or token mints can be frozen outside the standard 42-control validation path. It is a targeted legal compliance tool — not a general administrative override. Control 42 covers all three modules with a Module 3 federal-action variant documented below.
#### 11.1 Activation — Cross-Module (Standard Control 42)
| Step | Action | Authority |
| ---- | ----------------------------------------------------------------------------------------- | -------------------------------------------- |
| 1 | Receive formal legal process (court order, SEC enforcement, law-enforcement request) | Incoming to Legal Counsel |
| 2 | Legal Counsel reviews and authorizes — confirms process is valid and scope is appropriate | Legal Counsel |
| 3 | 3-of-5 multi-sig executes targeted freeze | Authorized signers (immediate — no timelock) |
| 4 | Immutable on-chain record created | Automatic |
| 5 | Affected parties notified per legal process requirements | Compliance team |
| 6 | Ongoing reporting to requesting authority | Legal Counsel + Compliance |
#### 11.2 Activation — Module 3 Federal-Action Variant
For Module 3 mints, a federal action detected by the Classification oracle (USGS / DOE / Federal Register / DOD) automatically initiates Control 42 coordination per the Incident Response Playbook §13:
| Step | Action | Authority | SLA |
| ---- | --------------------------------------------------------------------- | -------------------------------- | --------------------------------- |
| 1 | Federal action detected by Classification relay | Classification oracle (P0 event) | 5-min cadence |
| 2 | P0 incident raised; PagerDuty alert; multi-sig holders notified | Operations + Legal Counsel | Within minutes |
| 3 | Legal Counsel confirms federal-action scope and applicability | Legal Counsel | Within 30 min |
| 4 | 3-of-5 emergency multi-sig executes Control 42 freeze | Authorized signers | Detection-to-freeze within 60 min |
| 5 | Immutable on-chain record created; `FederalActionFreezeApplied` event | Automatic | — |
| 6 | Affected issuer and investors notified | Compliance team + Empire | Within 4 hours |
The 60-minute detection-to-freeze SLA is an immutable operational requirement — governance can shorten it but cannot extend it.
#### 11.3 Scope and Limits
| Property | Detail |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| Targeted only | Can freeze a specific wallet or specific mint — cannot disable the 42 controls globally |
| Legal process required | Court order, SEC enforcement, law-enforcement request, or detected federal action (Module 3) — reviewed by Legal Counsel |
| Audit trail | Every activation creates immutable on-chain record (timestamp, authority, affected addresses) |
| Reversible | Lifted through same Legal Counsel + 3-of-5 process upon legal resolution |
| Not an admin override | Cannot waive holding periods, accreditation, OFAC screening, or any investor protection |
| No timelock | Immediate (cross-module) or within 60-min SLA (Module 3 federal-action) |
#### 11.4 What Control 42 Cannot Do
| Prohibited Action | Why |
| ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| Move tokens without holder consent | No `forceTransfer()` function exists |
| Waive holding period | Control HP-24 is immutable; Control 42 freezes transfers, it does not unlock them. Reg D / Reg S / Reg CF regimes preserved |
| Bypass OFAC screening | Controls SC-30 through SC-34 execute independently |
| Unfreeze without Legal Counsel | Legal authorization required for both freeze and unfreeze |
| Freeze the Global Pool itself | Pool is a program, not a wallet — Control 42 targets wallets and mints |
| Disable the Module 3 federal-action freeze coordination | Coordination mechanism is immutable; only the per-mint enablement toggle is adjustable |
***
### 12. Pool Governance
The Global Unified CEDEX Liquidity Pool has its own governance boundary — most pool properties are immutable, with only specific operational parameters adjustable. The Global Pool is module-agnostic by design — Module 1, Module 2, and Module 3 fee deposits all route to the same shared pool.
#### Governable (Adjustable)
| Parameter | Adjustment Mechanism | Bounds | Module Scope |
| -------------------------- | --------------------- | -------------------------------------------------------------------------------- | ------------ |
| Fee distribution ratios | 3-of-5 + 48h timelock | Max 10% shift per action | All modules |
| New ST22 token routing | Governance approval | New mints must pass verification including module-specific oracle initialization | All modules |
| Circuit breaker thresholds | 3-of-5 + 48h timelock | Within defined safety bounds | All modules |
#### Non-Governable (Immutable)
| Parameter | Status | Why |
| ---------------------------- | ----------------------------------------------- | ----------------------------------------------------------------------------- |
| Permanent lock | LP tokens burned — no withdrawal path | Cannot be overridden without full contract migration under emergency protocol |
| 2% staking reinvestment | Hardcoded program constant | Not modifiable by any governance action |
| Capital withdrawal | No withdrawal function in bytecode | Governance cannot create one without program migration |
| GROO graduation migration | Automatic transfer of bonding-curve SOL | Cannot be disabled |
| Pool program upgrade | No upgrade authority | `Authority: none` — program is permanently immutable |
| Cross-module fee aggregation | Pool aggregates Module 1 / 2 / 3 fees uniformly | Cannot be partitioned by module |
#### Emergency Pool Migration
In the catastrophic event of a vulnerability in the pool contract requiring migration to a new contract, the emergency override protocol applies:
| Requirement | Detail |
| ----------------------- | ------------------------------------------------------------ |
| Threshold | 5-of-9 multi-sig |
| Timelock | 48 hours (even in emergency) |
| Audit | Independent security audit of destination contract |
| Legal | Legal Counsel approval |
| Destination restriction | Can only migrate to a contract that preserves permanent lock |
| Disclosure | Full public disclosure before timelock expires |
This has never been activated. The pool contract was formally verified by Certora Prover (invariant E.3 — Global Pool non-extractability) prior to deployment.
***
### 13. Governance Boundaries Diagram
```
┌────────────────────────────────────────────────────────────────────┐
│ GOVERNANCE SCOPE MAP │
│ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ OUTSIDE GOVERNANCE (IMMUTABLE) │ │
│ │ │ │
│ │ 42 Transfer Hook controls · 1:1 backing · LP burn │ │
│ │ OFAC/AML per transfer · holding periods (D/S/CF) │ │
│ │ 4.99% default ceiling · 9.99% program upper bound │ │
│ │ 2% staking reinvestment · 5% total fee · pool immutability│ │
│ │ │ │
│ │ Module 2: NAV-deviation enforcement (CB-21 extension) │ │
│ │ Module 3: federal-action freeze coordination │ │
│ │ (REG-42 extension; 60-min SLA) │ │
│ │ │ │
│ │ NO AUTHORITY CAN CHANGE THESE │ │
│ │ — including Groovy Company, Inc. itself │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ INSIDE GOVERNANCE (ADJUSTABLE) │ │
│ │ │ │
│ │ ┌────────────────────────────────────────────────────┐ │ │
│ │ │ 5-of-9 + 48h + AUDIT + BOARD + CERTORA E.4 │ │ │
│ │ │ Program upgrades (preserving all 42 controls │ │ │
│ │ │ plus module-aware extensions) │ │ │
│ │ │ Emergency pool migration │ │ │
│ │ └────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌────────────────────────────────────────────────────┐ │ │
│ │ │ 3-of-5 + 48h │ │ │
│ │ │ Cross-module: TWAP window · price impact · │ │ │
│ │ │ fee ratios · cooldowns · │ │ │
│ │ │ AML threshold · TWAP sigma │ │ │
│ │ │ Module 2 only: nav_deviation_max_bps · │ │ │
│ │ │ nav_reappraisal_max_age_secs │ │ │
│ │ │ Module 3 only: classification_max_age_secs │ │ │
│ │ └────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌────────────────────────────────────────────────────┐ │ │
│ │ │ 3-of-5 + LEGAL COUNSEL (IMMEDIATE / 60-MIN SLA) │ │ │
│ │ │ Control 42 — regulatory freeze (cross-module) │ │ │
│ │ │ Control 42 — Module 3 federal-action variant │ │ │
│ │ │ Emergency circuit breaker │ │ │
│ │ └────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────┘
```
***
### 14. Emergency Response Governance
During a declared incident (P0 or P1), governance authority shifts to the Incident Commander. See the Incident Response Playbook for full details. The IC primary is Frank Yglesias (Chairman / CTO); IC secondary is Patrick Mokros (COO).
#### Emergency Decision Authority
| Action | Authority | Approval | Timelock | Module Scope |
| ----------------------------------------------------- | ---------------------------------------- | ------------------------------------------------- | ---------------------------- | ------------ |
| Activate Control 42 (regulatory freeze, cross-module) | Legal Counsel + 3-of-5 multi-sig | Legal-process documentation | None — immediate | All modules |
| Activate Control 42 (Module 3 federal-action variant) | Legal Counsel + 3-of-5 multi-sig | Federal-action detection by Classification oracle | None — 60-min SLA | Module 3 |
| Activate emergency circuit breaker | IC + 3-of-5 multi-sig | P0 incident declaration | None — immediate | All modules |
| Emergency program upgrade | IC + 5-of-9 multi-sig | Post-hoc Certora re-verification | 48 hours (even in emergency) | All modules |
| Emergency key rotation | IC + same threshold as key being rotated | Post-hoc audit | Per action type | All modules |
#### Emergency Escalation Levels
| Level | Action | Authorized By | Reversible | Module Scope |
| ------------------ | --------------------------------------------------------------------- | ------------------------------------------------- | ------------------------------ | -------------------------------------------------------------- |
| Level 1 — Pause | Pause new transactions only. Existing positions preserved. | CTO | Yes | All modules; can be scoped to specific mint or specific module |
| Level 2 — Freeze | Freeze all operations. All positions frozen. | Chairman / CTO + COO | Yes | All modules; can be scoped per module |
| Level 3 — Rollback | Revert to last verified good state. Positions restored from snapshot. | Full Board (sole director under board resolution) | No — requires board resolution | All modules |
***
### 15. Transparency and Reporting
#### On-Chain Transparency
Every governance action is permanently recorded on the Solana blockchain. Module-specific actions emit module-aware events.
| Record | Content | Visibility | Module Scope |
| -------------------------------- | --------------------------------------------------------------------- | ---------------------- | ------------------- |
| Parameter change | Timestamp, parameter name, old value, new value, multi-sig signatures | Public — Solana ledger | All modules |
| Module-specific parameter change | Same as above + affected mint identifier | Public — Solana ledger | Module 2 / Module 3 |
| Program upgrade | Timestamp, old program hash, new program hash, audit attestation hash | Public — Solana ledger | All modules |
| Control 42 freeze | Timestamp, affected addresses, legal authority cited | Public — Solana ledger | All modules |
| Module 3 federal-action freeze | Same + classification reference (e.g., EO-14118) | Public — Solana ledger | Module 3 |
| Emergency action | Timestamp, action type, authorizing signatures | Public — Solana ledger | All modules |
#### Off-Chain Disclosure
| Audience | Channel | Timing |
| --------- | ------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| SEC | EDGAR filing (8-K for material changes) | Per SEC reporting requirements |
| Issuers | Direct notification | Within 48 hours of any parameter change affecting their token (cross-module or module-specific) |
| Investors | Empire Stock Transfer communication channel | Within 48 hours of changes affecting transfer restrictions, fees, or holding periods |
| Public | Status page (status.cedex.market) | Real-time for operational changes |
#### Legal Counsel Gate
Legal Counsel reviews all governance actions with potential securities-law implications before execution — not as a rubber stamp, but as an active legal-compliance gate. This applies to:
* Any fee structure modification.
* Any parameter change affecting investor transfer restrictions (cross-module or module-specific).
* All program upgrades.
* All Control 42 activations (including Module 3 federal-action variants).
* Any governance action that would be disclosed in SEC filings.
***
### 16. Module-Aware Governance Surface
This section consolidates the module-specific governance surface — the same surface threaded through each section above.
#### 16.1 Module 1 — Equities
**Adjustable parameters.** All cross-module adjustables (TWAP window, price impact, fee ratios, circuit-breaker cooldowns, AML threshold, TWAP sigma).
**Module-specific governance surface.** None beyond cross-module — Module 1 mints use the standard SecurityConfig without module-specific extensions.
**Control 42 path.** Cross-module standard path. SEC enforcement, court order, or law-enforcement request initiated through Legal Counsel.
#### 16.2 Module 2 — Real Estate
**Adjustable parameters.** All cross-module adjustables plus `nav_deviation_max_bps`, `nav_reappraisal_max_age_secs`, `nav_circuit_breaker_enabled` (per mint, with tripartite concurrence required for NAV-bound adjustments).
**Module-specific governance surface.** NAV-bound adjustments must be made under tripartite concurrence (issuer + Empire + Groovy Company, Inc.). Disabling the NAV circuit breaker requires the elevated 5-of-9 threshold and is rarely contemplated.
**Control 42 path.** Cross-module standard path. Module 2 has no automatic federal-action variant — but legal process directed at the underlying real-property asset (lis pendens, foreclosure injunction, environmental hold) routes through standard Control 42.
#### 16.3 Module 3 — CORECM
**Adjustable parameters.** All cross-module adjustables plus `classification_max_age_secs`, `federal_action_freeze_enabled` (per mint).
**Module-specific governance surface.** Disabling `federal_action_freeze_enabled` requires the elevated 5-of-9 threshold and is generally not contemplated — the default is enabled and operationally retained.
**Control 42 path.** Cross-module standard path PLUS the **Module 3 federal-action variant**: federal actions detected by the Classification oracle (USGS / DOE / Federal Register / DOD) initiate automatic Control 42 coordination with a 60-minute detection-to-freeze SLA. The federal-action variant is the most time-sensitive emergency path in the platform.
#### 16.4 Cross-Module Governance Properties
The following governance properties are identical across all three modules:
* The same 5-of-9 multi-sig executes program upgrades affecting any module.
* The same 3-of-5 multi-sig executes parameter adjustments — cross-module or module-specific.
* The same 48-hour timelock applies to non-emergency module-specific changes.
* The same Legal Counsel review gates Control 42 activations regardless of module.
* The same audit attestation and Certora E.4 verification protect controls across modules.
* Empire Stock Transfer is the sole §17A custodian and sole onboarding authority for every issuance regardless of module.
***
### 17. Governance FAQ
**Can the platform change the 5% fee?**
The total 5% fee rate is immutable — it is set at mint creation via the Token-2022 Transfer Fee Extension and cannot be changed after the mint exists. The distribution ratios within the 5% (currently 200/150/106/44 bps) can be adjusted via governance, subject to 3-of-5 multi-sig, 48-hour timelock, and a maximum 10% shift per proposal. This applies uniformly to Module 1, Module 2, and Module 3.
**Can the platform move my tokens?**
No. There is no `forceTransfer()` function in the ST22 architecture. Control 42 can freeze transfers on a mint (halt all trading), but it cannot move tokens from one wallet to another. Only the wallet holder can initiate a transfer. Same answer regardless of module.
**Can the platform shorten the holding period?**
No. The Reg D (6-month), Reg S (12-month), and Reg CF (12-month) holding periods are hardcoded constants in the Transfer Hook program. They are immutable — governance cannot reduce them below statutory minimums.
**What happens if all 9 multi-sig keys are compromised?**
An attacker with 5-of-9 keys could submit a program upgrade — but the 48-hour timelock makes the upgrade publicly visible, and 2-of-5 can cancel it during the window. The attacker would also need a valid security audit attestation from Quantstamp, Halborn, or OtterSec — which requires social-engineering an audit firm — plus passing Certora invariant E.4 verification, which would reject any upgrade that weakens the 42 controls or the Module 2 / Module 3 control extensions. Even a successful malicious upgrade cannot modify hardcoded immutable constants or add functions to the immutable pool program.
**Who are the multi-sig key holders?**
Key holders are not publicly named (operational security). They are geographically distributed across 5+ jurisdictions, use Ledger Enterprise HSMs, and no individual holds more than one signing position in any quorum. The board has a complete registry.
**Can an upgrade remove the Transfer Hook?**
No. The Transfer Hook address is stored in the mint account by SPL Token-2022 — it is a property of the token standard, not the platform's program. Even if the platform's Transfer Hook program were somehow replaced with a no-op program (which the audit attestation and Certora E.4 prevent), the Token-2022 program would still invoke the hook address on every transfer.
**Can governance disable the Module 2 NAV-deviation circuit breaker?**
The circuit-breaker mechanism itself is immutable — it cannot be removed. The per-mint enablement toggle (`nav_circuit_breaker_enabled`) can be flipped only with the elevated 5-of-9 threshold plus 48-hour timelock plus board resolution. In practice this has never been done; the default is enabled and retained.
**Can governance disable the Module 3 federal-action freeze coordination?**
The coordination mechanism itself is immutable. The per-mint enablement toggle (`federal_action_freeze_enabled`) can be flipped only with the elevated 5-of-9 threshold plus 48-hour timelock plus board resolution. The default is enabled and operationally retained — disabling it would expose the platform to federal regulatory action without automated coordination, which Legal Counsel does not currently contemplate.
**Can a single Module 3 federal-action freeze affect Module 1 or Module 2 mints?**
No. Control 42 is targeted — a Module 3 federal-action freeze affects the specific Module 3 mint(s) referenced by the federal action. Other Module 3 mints, all Module 1 mints, and all Module 2 mints are unaffected. A federal action that simultaneously references multiple Module 3 basins can affect multiple Module 3 mints, but the freeze remains scoped to the affected mints — never platform-wide.
***
### 18. On-Chain Verification
#### Verify Program Upgrade Authorities
```bash
# Transfer Hook — should be 5-of-9 multi-sig
solana program show | grep "Authority"
# AMM — should be 5-of-9 multi-sig
solana program show | grep "Authority"
# Liquidity Pool — MUST be "none" (immutable)
solana program show | grep "Authority"
# Expected: "Authority: none"
# Governance — should be 3-of-5 multi-sig
solana program show | grep "Authority"
# Oracle Aggregator — should be 5-of-9 multi-sig
solana program show | grep "Authority"
```
#### Verify Pending Governance Actions
```bash
# Check for pending timelocked proposals
anchor account governance GovernanceProposal \
--provider.cluster mainnet | jq '{
proposal_id: .proposalId,
action: .actionType,
param: .parameterName,
new_value: .proposedValue,
affected_mint: .affectedMint,
submitted_at: .submittedAt,
activates_at: .activatesAt,
status: .status
}'
```
#### Verify Module-Specific Governance Actions
```bash
# Check for pending Module 2 NAV-bound adjustments
anchor account governance GovernanceProposal \
--provider.cluster mainnet | jq '
select(.actionType == "ParameterAdjustment"
and (.parameterName == "nav_deviation_max_bps"
or .parameterName == "nav_reappraisal_max_age_secs"))
'
# Check for pending Module 3 classification-age adjustments
anchor account governance GovernanceProposal \
--provider.cluster mainnet | jq '
select(.actionType == "ParameterAdjustment"
and .parameterName == "classification_max_age_secs")
'
```
#### Verify Governance Event History
```bash
# Query all GovernanceExecuted events
curl -s https://api.cedex.market/v1/governance/history | jq '.events[] | {
id: .proposal_id,
action: .action_type,
param: .parameter,
old_value: .old_value,
new_value: .new_value,
affected_mint: .affected_mint,
module_scope: .module_scope,
timestamp: .executed_at,
signers: .signer_count
}'
```
***
### Related Documentation
* **Architecture Decisions** — ADR-003 (Global Pool permanence), ADR-004 (LP burned), module-specific architectural rationales.
* **Security Model** — Multi-sig key management, threat model, module-specific threat surfaces.
* **Incident Response Playbook** — Emergency governance procedures including Module 3 federal-action freeze runbook (§13).
* **Smart Contract Reference** — Governance program instructions, module-aware program behavior, Certora invariants.
* **Network Configuration** — Multi-sig addresses, program authorities, oracle PDAs across modules.
* **Compliance Integration Guide** — Control 42 regulatory context, module-specific compliance, federal-action coordination.
* **Oracle Integration Guide** — Custody, OFAC, AML, TWAP, EDGAR (Module 1), NAV (Module 2), Classification (Module 3) relay architecture.
* **Empire Stock Transfer Integration** — Tripartite concurrence requirements for Module 2 NAV-bound adjustments.
***
*RWA Tokens · Governance Deep Dive · Groovy Company, Inc.*
# Welcome
Welcome to the **RWA Tokens Marketing Wiki** — the central library for everything we publish about the platform to the outside world. Articles, pitch decks, the lightpaper, investor presentations, SEC filings and staff statements we cite, regulatory commentary, and ongoing news coverage all live here, organized so the comms team, partners, and counsel can find the right asset for the right audience without rebuilding it from scratch.
You'll find collateral grouped by the three asset-class modules — **Equities (ST22), Real Estate, and CORECM** — alongside cross-cutting materials that apply to the platform as a whole: corporate-identity assets, SEC regulatory framework references (Release No. 33-11412, the January 28, 2026 Joint Staff Statement, the April 13, 2026 Covered User Interface Providers statement), and the live news and X/LinkedIn campaign archive. Each item is tagged by audience (institutional investor, issuer prospect, regulator, press) and by stage (draft, internal review, legal-cleared, published) so nothing ships externally without the right approval state.
This wiki is the canonical source for any RWA Tokens marketing artifact under the Groovy Company, Inc. brand (the "OTCM Protocol" dba was retired May 1, 2026; CEDEX, ST22, and GROO remain as product and instrument names). Platform URL is [**https://rwatokens.net**](https://rwatokens.net/); trading venue is **cedex.market**. When in doubt about which version of a deck or letter is current, this wiki is the answer — anything found elsewhere should be checked against the version here before sending.
# SDK Reference
## SDK Reference
**`@rwatokens/sdk` · TypeScript · v1.0.0 · Module-Aware Throughout**
Complete TypeScript SDK for interacting with the platform's nine-layer infrastructure — ST22 Digital Securities token operations, Transfer Hook verification, custody oracle queries, NAV oracle queries (Module 2), Classification oracle queries (Module 3), CEDEX trading, portfolio management, and real-time data subscriptions. The SDK serves all three production modules — Equities (Module 1), Real Estate (Module 2), and CORECM — Carbon Ore, Rare Earth, and Critical Minerals (Module 3) — through a single client with module-aware helpers.
The SDK is published by Groovy Company, Inc. and is the primary integration surface for institutional integrators, trading-desk operators, custody systems, and analytics tooling. The same client instance handles mints from any of the three modules; module-specific behavior is surfaced through module-specific oracle helpers and module-aware fields on standard methods.
***
### Table of Contents
1. Installation
2. Configuration
3. Client Initialization
4. Core Types
5. Transfer Hook Operations
6. Custody Oracle
7. NAV Oracle (Module 2)
8. Classification Oracle (Module 3)
9. Holding Period
10. CEDEX Trading
11. Portfolio Management
12. Market Data
13. WebSocket Subscriptions
14. Error Handling
15. Utilities
16. Security Best Practices
17. Network Configuration
18. Examples
***
### 1. Installation
```bash
# npm
npm install @rwatokens/sdk
# yarn
yarn add @rwatokens/sdk
# pnpm
pnpm add @rwatokens/sdk
```
#### Peer Dependencies
```json
{
"@solana/web3.js": "^1.95.0",
"@solana/spl-token": "^0.4.0",
"@coral-xyz/anchor": "^0.30.0"
}
```
#### Requirements
| Requirement | Version |
| ----------- | ----------------------------- |
| Node.js | 20 LTS+ |
| TypeScript | 5.0+ |
| Solana CLI | 1.18+ (for local development) |
***
### 2. Configuration
```typescript
import { RwaTokensConfig } from '@rwatokens/sdk';
const config: RwaTokensConfig = {
// Required
network: 'mainnet-beta', // 'mainnet-beta' | 'devnet' | 'localnet'
// Optional — defaults shown
rpcEndpoint: undefined, // Custom RPC (default: Helius cluster)
wsEndpoint: undefined, // Custom WebSocket endpoint
commitment: 'confirmed', // 'processed' | 'confirmed' | 'finalized'
preflight: true, // Simulate transactions before sending
maxRetries: 3, // Retry count with exponential backoff
timeoutMs: 30_000, // Request timeout
priorityFee: 'auto', // 'auto' | 'none' | number (microlamports)
jitoEnabled: true, // Use Jito Block Engine for MEV protection
};
```
#### Environment Variables
```bash
# .env
RWA_TOKENS_NETWORK=mainnet-beta
RWA_TOKENS_RPC_ENDPOINT=https://mainnet.helius-rpc.com/?api-key=YOUR_KEY
RWA_TOKENS_WS_ENDPOINT=wss://mainnet.helius-rpc.com/?api-key=YOUR_KEY
RWA_TOKENS_JITO_ENABLED=true
```
***
### 3. Client Initialization
```typescript
import { RwaTokensClient } from '@rwatokens/sdk';
import { Keypair, Connection } from '@solana/web3.js';
// Basic initialization (uses environment variables)
const client = new RwaTokensClient({ network: 'mainnet-beta' });
// With custom RPC
const client = new RwaTokensClient({
network: 'mainnet-beta',
rpcEndpoint: 'https://mainnet.helius-rpc.com/?api-key=YOUR_KEY',
});
// With wallet for signing (trading operations)
const wallet = Keypair.fromSecretKey(/* ... */);
const client = new RwaTokensClient({
network: 'mainnet-beta',
wallet,
});
// With existing Connection object
const connection = new Connection('https://mainnet.helius-rpc.com/?api-key=YOUR_KEY');
const client = RwaTokensClient.fromConnection(connection);
```
#### Client Properties
```typescript
class RwaTokensClient {
readonly connection: Connection;
readonly network: Network;
readonly programIds: ProgramIds;
// Sub-clients for specific operations
readonly hooks: TransferHookClient;
readonly custody: CustodyOracleClient; // All modules
readonly oracle: OracleClient; // Includes NAV (M2) and Classification (M3) helpers
readonly holdingPeriod: HoldingPeriodClient;
readonly cedex: CedexClient;
readonly portfolio: PortfolioClient;
readonly markets: MarketDataClient;
readonly ws: WebSocketClient;
}
```
The same `RwaTokensClient` instance handles mints from any of the three modules. There is no per-module client — module-aware helpers (`client.oracle.getNAV()` for Module 2; `client.oracle.getClassification()` for Module 3) work alongside cross-module methods (`client.cedex.placeOrder()`, `client.custody.getAttestation()`) on the same instance.
#### Program IDs
```typescript
interface ProgramIds {
transferHook: PublicKey; // Transfer Hook program (all modules)
amm: PublicKey; // Custom CPMM AMM (all modules)
liquidityPool: PublicKey; // Global Unified CEDEX Liquidity Pool (all modules)
governance: PublicKey; // Protocol governance (all modules)
oracleAggregator: PublicKey; // Oracle aggregation program — hosts NAV (M2) and Classification (M3) PDAs
token2022: PublicKey; // SPL Token-2022 program
}
// Mainnet program IDs are published in the Network Configuration document
// at mainnet deployment (Q3 2026).
```
***
### 4. Core Types
#### Token Types
```typescript
/** Module identifier */
type ModuleId = 'equities' | 'real_estate' | 'corecm';
/** ST22 mint information */
interface ST22Mint {
address: PublicKey;
symbol: string;
name: string;
decimals: number;
supply: bigint;
issuer: PublicKey; // Issuer authority
module: ModuleId; // Which module this mint belongs to
transferHook: PublicKey; // Transfer Hook program ID
hookAttached: boolean; // true (always — irreversible)
metadata: {
issuerName: string;
assetIdentifier: string; // CUSIP (M1), property ID (M2), or basin ID (M3)
custodyAuth: string; // Empire Stock Transfer custody reference
classification: 'ST22DigitalSecurity';
};
}
/** Transfer Hook verification result */
interface TransferHookStatus {
mint: PublicKey;
hookProgramId: PublicKey;
controlsActive: 42; // Always 42
bypassPossible: false; // Always false
securityConfig: SecurityConfig;
isValid: boolean;
}
/** Jurisdiction for holding period — drives the Reg D / Reg S / Reg CF regime */
type Jurisdiction = 'US' | 'NonUS' | 'RegCF';
/** Order side */
type OrderSide = 'buy' | 'sell';
/** Order type */
type OrderType = 'market' | 'limit';
/** Order status */
type OrderStatus = 'open' | 'filled' | 'partially_filled' | 'cancelled' | 'expired';
```
#### Account Types
```typescript
/** SecurityConfig PDA — one per ST22 mint, schema covers all modules */
interface SecurityConfig {
mint: PublicKey;
authority: PublicKey; // 5-of-9 multi-sig
version: number;
module: ModuleId;
maxWalletPercent: number; // 499 = 4.99% (bps); M2 may use up to 999
maxSingleTransferPercent: number;
circuitBreakerThreshold: number; // 3000 = 30% (bps)
circuitBreakerCooldown: number; // Seconds (86400)
circuitBreakerTriggered: boolean;
circuitBreakerTriggeredAt: number | null;
priceImpactMaxBps: number; // 200 = 2%
referencePrice: bigint; // TWAP baseline (lamports)
twapWindowSecs: number; // 1800 = 30 min
twapMinObservations: number; // 60 (immutable)
holdingPeriodConfig: HoldingPeriodConfig;
volumeTracker: VolumeTracker;
isPaused: boolean;
// Module 2 only — undefined on Module 1 / Module 3
navDeviationMaxBps?: number; // typically 2200 = 22%
navReappraisalMaxAgeSecs?: number;
navCircuitBreakerEnabled?: boolean;
// Module 3 only — undefined on Module 1 / Module 2
classificationMaxAgeSecs?: number; // typically 86400 = 24h
federalActionFreezeEnabled?: boolean;
bump: number;
}
/** Holding period configuration — same schema across all modules */
interface HoldingPeriodConfig {
enabled: boolean;
regDSecs: number; // 15_778_800 — Reg D 6 months
regSSecs: number; // 31_536_000 — Reg S 12 months
regCfSecs: number; // 31_536_000 — Reg CF 12 months
}
/** Custody oracle state — same schema across all modules; asset class
* recorded in the SecurityConfig metadata, not the oracle */
interface CustodyOracleState {
mint: PublicKey;
custodiedBalance: bigint; // Empire-custodied unit count (asset class per module)
tokenSupply: bigint; // On-chain circulating supply
ratio: number; // Must be exactly 1.0
attestationSlot: bigint;
attestationTimestamp: number;
empirePubkey: PublicKey;
ed25519Verified: boolean;
discrepancyDetected: boolean;
}
/** NAV oracle state — Module 2 only */
interface NAVOracleState {
mint: PublicKey;
appraisedNavUsd: bigint; // USD-pegged stablecoin units
appraiserId: string;
appraisalTimestamp: number;
nextReappraisalTarget: number;
deviationToleranceBps: number; // typically 2200 = 22%
staleThresholdSecs: number;
isStale: boolean;
ed25519Verified: boolean;
}
/** Classification oracle state — Module 3 only */
interface ClassificationOracleState {
mint: PublicKey;
usgsCriticalStatus: string; // e.g., "critical_mineral_rare_earth"
doeMaterialsStatus: string; // e.g., "high_priority"
section232Applicable: boolean;
dpaTitleIIIApplicable: boolean;
federalActionActive: boolean;
activeActionRefs: string[]; // e.g., ["EO-14118"]
lastRefreshTimestamp: number;
staleThresholdSecs: number;
isStale: boolean;
}
/** Holding period account — one per investor-mint pair */
interface HoldingPeriodAccount {
beneficiary: PublicKey;
mint: PublicKey;
purchaseTimestamp: number;
jurisdiction: Jurisdiction; // Drives the regime
regime: 'RegD' | 'RegS' | 'RegCF';
holdingPeriodSecs: number; // 6mo (Reg D) or 12mo (Reg S / Reg CF)
isLocked: boolean;
unlockTimestamp: number;
secondsRemaining: number;
}
```
***
### 5. Transfer Hook Operations
#### Verify Transfer Hook
Confirm an ST22 mint has the Transfer Hook permanently attached. The same method serves Module 1, Module 2, and Module 3 mints uniformly.
```typescript
const status = await client.hooks.verify(mintAddress);
console.log(status.hookProgramId.toBase58()); // Hook program ID
console.log(status.controlsActive); // 42
console.log(status.bypassPossible); // false
console.log(status.isValid); // true
```
#### Get SecurityConfig
Read the full security configuration for an ST22 mint. Module-specific fields are populated per the mint's module.
```typescript
const config = await client.hooks.getSecurityConfig(mintAddress);
console.log(config.module); // 'equities' | 'real_estate' | 'corecm'
console.log(config.maxWalletPercent); // 499 (4.99%) — or up to 999 on M2
console.log(config.priceImpactMaxBps); // 200 (2%)
console.log(config.circuitBreakerTriggered); // false
console.log(config.holdingPeriodConfig.enabled); // true
console.log(config.isPaused); // false
// Module 2 — additional fields populated
if (config.module === 'real_estate') {
console.log(config.navDeviationMaxBps); // 2200 (22%)
console.log(config.navReappraisalMaxAgeSecs); // per tripartite cadence
console.log(config.navCircuitBreakerEnabled); // true
}
// Module 3 — additional fields populated
if (config.module === 'corecm') {
console.log(config.classificationMaxAgeSecs); // 86400 (24h)
console.log(config.federalActionFreezeEnabled);// true
}
```
#### Simulate Transfer
Dry-run a transfer against all 42 controls without submitting on chain. Returns which controls would pass or fail. Module-specific control extensions (Module 2 NAV-deviation, Module 3 federal-action) are evaluated automatically.
```typescript
const simulation = await client.hooks.simulateTransfer({
mint: mintAddress,
source: senderWallet,
destination: receiverWallet,
amount: 1_000_000n, // bigint — raw token amount (with decimals)
});
console.log(simulation.wouldSucceed); // boolean
console.log(simulation.controlResults); // Map
// Check specific control
const control24 = simulation.controlResults.get('HP-24');
console.log(control24.passed); // false
console.log(control24.error); // 'TokensLocked'
console.log(control24.code); // 6024
console.log(control24.details); // { secondsRemaining, jurisdiction, regime }
// Module 2: check NAV-deviation variant of CB-21
const cb21 = simulation.controlResults.get('CB-21');
if (cb21.details?.variant === 'nav_deviation') {
console.log('NAV-deviation circuit breaker triggered');
}
// Module 3: check federal-action variant of REG-42
const reg42 = simulation.controlResults.get('REG-42');
if (reg42.details?.variant === 'federal_action') {
console.log('Federal action freeze active:', reg42.details.actionReferences);
}
```
**`ControlResult` type:**
```typescript
interface ControlResult {
controlId: string; // 'CV-01', 'HP-24', 'REG-42', etc.
category: string; // 'Custody', 'HoldingPeriod', 'Regulatory', etc.
passed: boolean;
error: string | null;
code: number | null;
details: Record | null;
latencyMs: number;
}
```
#### Check Wallet Eligibility
Verify if a wallet can receive ST22 tokens (passes investor verification controls IV-07 through IV-14). The eligibility check is module-agnostic at the wallet level — module-specific eligibility (e.g., Module 3 enhanced beneficial-ownership depth) is enforced at Empire onboarding, not at this method.
```typescript
const eligibility = await client.hooks.checkWalletEligibility({
mint: mintAddress,
wallet: receiverWallet,
});
console.log(eligibility.eligible); // boolean
console.log(eligibility.kycVerified); // boolean
console.log(eligibility.regimes); // Array<'RegD' | 'RegS' | 'RegCF'>
console.log(eligibility.ofacClear); // boolean
console.log(eligibility.amlScore); // number (0-100)
console.log(eligibility.amlDisposition); // 'approve' | 'review' | 'reject'
console.log(eligibility.walletPercent); // current holdings as % of supply
console.log(eligibility.withinLimit); // boolean
```
***
### 6. Custody Oracle
The Custody Oracle is module-agnostic. The same Empire Ed25519-signed attestation flow serves Module 1 (Common Class B equity), Module 2 (single-asset entity equity), and Module 3 (basin-asset entity equity). The asset class is recorded in the SecurityConfig metadata; the custody oracle tracks the unit count and the on-chain supply.
#### Get Custody Attestation
```typescript
const custody = await client.custody.getAttestation(mintAddress);
console.log(custody.custodiedBalance); // 1_000_000_000n (Empire-custodied)
console.log(custody.tokenSupply); // 1_000_000_000n (on-chain supply)
console.log(custody.ratio); // 1.0 (must be exactly 1:1)
console.log(custody.ed25519Verified); // true
console.log(custody.discrepancyDetected); // false
console.log(custody.attestationSlot); // 285_000_000n
console.log(custody.attestationTimestamp); // 1711929600
```
#### Verify Ed25519 Signature
Independently verify the Empire attestation signature.
```typescript
const verified = await client.custody.verifySignature(mintAddress);
console.log(verified.valid); // boolean
console.log(verified.empirePubkey); // PublicKey
console.log(verified.payload); // CustodyAttestationPayload
console.log(verified.signature); // Uint8Array (64 bytes)
```
#### Watch Custody (Real-Time)
Subscribe to custody attestation updates (\~400ms per block). Works uniformly across modules.
```typescript
const unsubscribe = client.custody.watch(mintAddress, (attestation) => {
console.log(`Slot ${attestation.attestationSlot}: ratio=${attestation.ratio}`);
if (attestation.discrepancyDetected) {
console.error('CUSTODY DISCREPANCY — Error 6001');
// All transfers halted on this mint
}
});
// Stop watching
unsubscribe();
```
***
### 7. NAV Oracle (Module 2)
The NAV Oracle holds the most recent appraised Net Asset Value for a Module 2 ST22 mint. Calls are valid only for Module 2 mints — calling these methods against a Module 1 or Module 3 mint returns `null`.
#### Get NAV Oracle
```typescript
const nav = await client.oracle.getNAV(module2MintAddress);
if (!nav) {
// mint is not Module 2, or NAV oracle not initialized
return;
}
console.log(nav.appraisedNavUsd); // bigint — USD-pegged stablecoin units
console.log(nav.appraiserId); // licensed appraiser identifier
console.log(nav.appraisalTimestamp); // 1729785600
console.log(nav.nextReappraisalTarget); // 1745510400
console.log(nav.deviationToleranceBps); // 2200 (22%)
console.log(nav.isStale); // false
console.log(nav.ed25519Verified); // true
```
#### Compute NAV Deviation
Convenience helper to compute the on-chain price's deviation from the most recent NAV.
```typescript
const deviation = await client.oracle.computeNAVDeviation(module2MintAddress);
console.log(deviation.onChainPriceUsd); // current AMM price in USD-pegged units
console.log(deviation.appraisedNavUsd); // most recent NAV
console.log(deviation.deviationBps); // signed basis points
console.log(deviation.withinTolerance); // boolean — true if |deviationBps| <= deviationToleranceBps
console.log(deviation.daysSinceAppraisal); // float
```
#### Watch NAV (Real-Time)
```typescript
const unsubscribe = client.oracle.watchNAV(module2MintAddress, (update) => {
console.log(`NAV updated: $${update.appraisedNavUsd}`);
console.log(`Next reappraisal: ${new Date(update.nextReappraisalTarget * 1000).toISOString()}`);
});
```
***
### 8. Classification Oracle (Module 3)
The Classification Oracle holds the most recent USGS Critical Minerals List classification, DOE Critical Materials Strategy status, and federal-action status for a Module 3 ST22 mint's basin asset. Calls are valid only for Module 3 mints — calling these methods against a Module 1 or Module 2 mint returns `null`.
#### Get Classification Oracle
```typescript
const classification = await client.oracle.getClassification(module3MintAddress);
if (!classification) {
// mint is not Module 3, or Classification oracle not initialized
return;
}
console.log(classification.usgsCriticalStatus); // "critical_mineral_rare_earth"
console.log(classification.doeMaterialsStatus); // "high_priority"
console.log(classification.section232Applicable); // false
console.log(classification.dpaTitleIIIApplicable); // false
console.log(classification.federalActionActive); // false
console.log(classification.activeActionRefs); // []
console.log(classification.lastRefreshTimestamp); // 1729828800
console.log(classification.isStale); // false
```
#### Watch Classification (Real-Time)
The classification subscription emits both routine refresh events and high-severity federal-action events. Federal-action events warrant immediate operational response under the Incident Response Playbook §13.
```typescript
const unsubscribe = client.oracle.watchClassification(module3MintAddress, (update) => {
if (update.eventType === 'federal_action_detected') {
console.error('[P0] Federal action detected:', update.actionReferences);
console.error('Detection-to-freeze SLA: 60 minutes');
return;
}
if (update.eventType === 'federal_action_freeze_applied') {
console.error('Control 42 freeze applied to mint:', update.mint.toBase58());
return;
}
// Routine classification update
console.log(`USGS: ${update.usgsCriticalStatus}, DOE: ${update.doeMaterialsStatus}`);
});
```
***
### 9. Holding Period
#### Get Holding Period Status
Check an investor's holding period status for a specific ST22 mint. The same method serves Reg D, Reg S, and Reg CF investors regardless of which module the mint belongs to.
```typescript
const holding = await client.holdingPeriod.getStatus({
mint: mintAddress,
beneficiary: investorWallet,
});
console.log(holding.jurisdiction); // 'US' | 'NonUS' | 'RegCF'
console.log(holding.regime); // 'RegD' | 'RegS' | 'RegCF'
console.log(holding.holdingPeriodSecs); // 15_778_800 (Reg D) or 31_536_000 (Reg S / Reg CF)
console.log(holding.purchaseTimestamp); // 1711929600
console.log(holding.unlockTimestamp); // 1727708400
console.log(holding.isLocked); // true
console.log(holding.secondsRemaining); // 1572300
// Human-readable unlock date
console.log(holding.unlockDate); // Date object
console.log(holding.unlockDateISO); // '2026-09-30T00:00:00Z'
```
#### Batch Holding Period Query
Check holding status across multiple mints for a single wallet. The query handles mints from any combination of modules in a single call.
```typescript
const statuses = await client.holdingPeriod.getBatch({
beneficiary: investorWallet,
mints: [mintM1, mintM2, mintM3],
});
for (const status of statuses) {
console.log(`${status.mint}: regime=${status.regime}, locked=${status.isLocked}, ` +
`remaining=${status.secondsRemaining}s`);
}
```
#### PDA Derivation
```typescript
const [holdingPda, bump] = client.holdingPeriod.derivePDA(mintAddress, investorWallet);
// Seeds: [b"holding-period", mint, beneficiary]
```
***
### 10. CEDEX Trading
All CEDEX trading operations require an authenticated wallet that has passed Empire Stock Transfer KYC, KYB, AML, OFAC, and KYW verification. The same method signatures serve mints from all three modules; module-specific behavior surfaces inside the pre-flight compliance pipeline.
#### Place Order
```typescript
// Market buy
const marketOrder = await client.cedex.placeOrder({
mint: mintAddress,
side: 'buy',
type: 'market',
amount: 50_000_000n, // ST22 token amount (with decimals)
slippageBps: 100, // 1% max slippage
});
console.log(marketOrder.orderId);
console.log(marketOrder.status); // 'filled'
console.log(marketOrder.executedAmount); // bigint
console.log(marketOrder.executedPrice); // number (SOL per token)
console.log(marketOrder.txSignature); // Solana transaction signature
console.log(marketOrder.complianceCheck); // 'passed'
console.log(marketOrder.controlsExecuted); // 42
// Limit sell
const limitOrder = await client.cedex.placeOrder({
mint: mintAddress,
side: 'sell',
type: 'limit',
amount: 100_000_000n,
limitPrice: 0.0001153, // SOL per token
expiry: Math.floor(Date.now() / 1000) + 86400, // 24h
});
console.log(limitOrder.orderId);
console.log(limitOrder.status); // 'open'
```
**Compliance flow.** Every order passes through pre-flight compliance verification (2–3 seconds) before on-chain execution. The pre-flight pipeline includes module-aware checks: Module 2 orders are pre-validated against the NAV-deviation tolerance; Module 3 orders are pre-validated against Classification freshness and federal-action status. If any check would reject the trade, the SDK returns the specific error code before submitting on chain — saving the user transaction fees.
#### Cancel Order
```typescript
const result = await client.cedex.cancelOrder(orderId);
console.log(result.status); // 'cancelled'
```
#### Get Open Orders
```typescript
const orders = await client.cedex.getOpenOrders({
wallet: myWallet,
mint: mintAddress, // Optional — filter by mint
});
for (const order of orders) {
console.log(`${order.orderId}: ${order.side} ${order.amount} @ ${order.limitPrice}`);
}
```
#### Estimate Swap Output
Preview a swap without executing — returns expected output, price impact, fee breakdown, and module-aware pre-flight result.
```typescript
const estimate = await client.cedex.estimateSwap({
mint: mintAddress,
side: 'buy',
inputAmount: 10_000_000_000n, // 10 SOL in lamports
});
console.log(estimate.outputAmount); // bigint — ST22 tokens received
console.log(estimate.effectivePrice); // number — SOL per token
console.log(estimate.priceImpactBps); // number — basis points impact
console.log(estimate.fee); // { total, pool, issuer, staking, protocol }
console.log(estimate.wouldTriggerCircuitBreaker); // boolean
// Module-aware pre-flight result
console.log(estimate.preFlightResult);
// {
// passed: boolean,
// failureReason: 'HOLDING_PERIOD_LOCKED' | 'PRICE_IMPACT_EXCEEDED' |
// 'NAV_DEVIATION_EXCEEDED' (M2) |
// 'NAV_STALE' (M2) |
// 'CLASSIFICATION_STALE' (M3) |
// 'FEDERAL_ACTION_FROZEN' (M3) | ...,
// moduleScope: 'all_modules' | 'module_2' | 'module_3'
// }
// Fee breakdown — same across all modules
console.log(estimate.fee.totalBps); // 500 (5%)
console.log(estimate.fee.poolBps); // 44 (0.44% → Global Pool, permanently locked)
console.log(estimate.fee.issuerBps); // 200 (2% → issuer treasury)
console.log(estimate.fee.stakingBps); // 150 (1.5% → GROO staking pool)
console.log(estimate.fee.protocolBps); // 106 (1.06% → protocol operations)
```
***
### 11. Portfolio Management
#### Get Portfolio
Returns all ST22 holdings for a wallet across all modules with holding-period status, custody-verification status, and module-aware oracle status.
```typescript
const portfolio = await client.portfolio.get(myWallet);
for (const position of portfolio.positions) {
console.log(`${position.symbol} (${position.module}): ${position.balance} tokens`);
console.log(` Value: ${position.valueSol} SOL`);
console.log(` Locked: ${position.isLocked}`);
console.log(` Unlock: ${position.unlockDateISO ?? 'unlocked'}`);
console.log(` Regime: ${position.regime}`); // 'RegD' | 'RegS' | 'RegCF'
console.log(` Custody verified: ${position.custodyVerified}`);
console.log(` % of supply: ${position.percentOfSupply}%`);
// Module 2: NAV status surfaced
if (position.module === 'real_estate' && position.navStatus) {
console.log(` NAV deviation: ${position.navStatus.deviationBps} bps`);
console.log(` NAV stale: ${position.navStatus.isStale}`);
}
// Module 3: Classification status surfaced
if (position.module === 'corecm' && position.classificationStatus) {
console.log(` Federal action active: ${position.classificationStatus.federalActionActive}`);
console.log(` Classification stale: ${position.classificationStatus.isStale}`);
}
}
console.log(`Total positions: ${portfolio.positions.length}`);
console.log(`Module 1 positions: ${portfolio.byModule.equities}`);
console.log(`Module 2 positions: ${portfolio.byModule.realEstate}`);
console.log(`Module 3 positions: ${portfolio.byModule.corecm}`);
console.log(`Total value: ${portfolio.totalValueSol} SOL`);
```
#### Get Position Detail
```typescript
const position = await client.portfolio.getPosition({
wallet: myWallet,
mint: mintAddress,
});
console.log(position.balance); // bigint
console.log(position.holdingPeriod); // HoldingPeriodAccount
console.log(position.custodyAttestation); // CustodyOracleState
console.log(position.securityConfig); // SecurityConfig
console.log(position.navOracle); // NAVOracleState | null (M2 only)
console.log(position.classificationOracle); // ClassificationOracleState | null (M3 only)
```
***
### 12. Market Data
#### List Markets
```typescript
// All markets across all modules
const markets = await client.markets.list();
// Filter by module
const m2Markets = await client.markets.list({ module: 'real_estate' });
const m3Markets = await client.markets.list({ module: 'corecm' });
for (const market of markets) {
console.log(`${market.symbol} (${market.module}): $${market.price} | Vol: ${market.volume24h}`);
console.log(` Mint: ${market.mint}`);
console.log(` Issuer: ${market.issuerName}`);
console.log(` Pool depth: ${market.poolDepthSol} SOL`);
}
```
#### Get Order Book
```typescript
const book = await client.markets.getOrderBook(mintAddress);
console.log('Bids:', book.bids.map(b => `${b.price} x ${b.amount}`));
console.log('Asks:', book.asks.map(a => `${a.price} x ${a.amount}`));
console.log('Spread:', book.spreadBps, 'bps');
```
#### Get Recent Trades
```typescript
const trades = await client.markets.getRecentTrades(mintAddress, {
limit: 50,
});
for (const trade of trades) {
console.log(`${trade.side} ${trade.amount} @ ${trade.price} | ${trade.txSignature}`);
}
```
#### Get OHLCV (Candlestick Data)
```typescript
const candles = await client.markets.getOHLCV(mintAddress, {
interval: '1h',
from: Math.floor(Date.now() / 1000) - 86400, // 24h ago
to: Math.floor(Date.now() / 1000),
});
for (const c of candles) {
console.log(`${c.timestamp}: O=${c.open} H=${c.high} L=${c.low} C=${c.close} V=${c.volume}`);
}
```
***
### 13. WebSocket Subscriptions
Real-time data via WebSocket connection to CEDEX. Module-specific channels (`nav` for Module 2; `classification` for Module 3) work alongside cross-module channels on the same WebSocket connection.
```typescript
// Initialize WebSocket client
await client.ws.connect();
```
#### Subscribe to Order Book
```typescript
client.ws.subscribeOrderBook(mintAddress, (update) => {
console.log('Bids:', update.bids);
console.log('Asks:', update.asks);
console.log('Timestamp:', update.timestamp);
});
```
#### Subscribe to Trades
```typescript
client.ws.subscribeTrades(mintAddress, (trade) => {
console.log(`${trade.side}: ${trade.amount} @ ${trade.price}`);
console.log(`TX: ${trade.txSignature}`);
});
```
#### Subscribe to Custody Oracle
Real-time custody attestation updates (\~400ms per block). Cross-module — works for Module 1, Module 2, and Module 3 mints.
```typescript
client.ws.subscribeCustody(mintAddress, (attestation) => {
console.log(`Ratio: ${attestation.ratio} | Ed25519: ${attestation.ed25519Verified}`);
if (attestation.discrepancyDetected) {
console.error('CUSTODY DISCREPANCY DETECTED');
}
});
```
#### Subscribe to NAV Oracle (Module 2)
```typescript
client.ws.subscribeNAV(module2MintAddress, (update) => {
console.log(`NAV: $${update.appraisedNavUsd}`);
console.log(`Deviation: ${update.deviationBps} bps`);
console.log(`Stale: ${update.isStale}`);
});
```
#### Subscribe to Classification Oracle (Module 3)
```typescript
client.ws.subscribeClassification(module3MintAddress, (update) => {
if (update.eventType === 'federal_action_detected') {
console.error('[P0] Federal action detected:', update.actionReferences);
return;
}
if (update.eventType === 'federal_action_freeze_applied') {
console.error('Control 42 freeze applied');
return;
}
console.log(`USGS: ${update.usgsCriticalStatus}, DOE: ${update.doeMaterialsStatus}`);
});
```
#### Subscribe to Circuit Breaker Events
```typescript
client.ws.subscribeCircuitBreaker(mintAddress, (event) => {
console.log(`Breaker: ${event.type}`);
// 'price_halt' | 'price_impact' | 'volume_halt' | 'nav_deviation' (M2) |
// 'classification_stale' (M3)
console.log(`Triggered: ${event.triggered}`);
console.log(`Cooldown: ${event.cooldownSecs}s`);
console.log(`Resume at: ${event.resumeTimestamp}`);
});
```
#### Disconnect
```typescript
client.ws.disconnect();
```
***
### 14. Error Handling
#### RwaTokensError Class
All SDK errors extend `RwaTokensError` with structured error data. Module-specific control failures expose a `moduleScope` field on `details` indicating which module's variant fired.
```typescript
import { RwaTokensError, TransferHookError } from '@rwatokens/sdk';
try {
await client.cedex.placeOrder({ /* ... */ });
} catch (error) {
if (error instanceof TransferHookError) {
console.log(error.code); // 6024
console.log(error.name); // 'TokensLocked'
console.log(error.message); // 'Tokens locked — Reg D / Reg S / Reg CF holding period not elapsed'
console.log(error.controlId); // 'HP-24'
console.log(error.category); // 'HoldingPeriod'
console.log(error.details); // { secondsRemaining, jurisdiction, regime, unlockTimestamp }
console.log(error.moduleScope); // 'all_modules' | 'module_2' | 'module_3'
console.log(error.recoverable); // true (will unlock after holding period)
}
}
```
#### Error Code Registry
| Code | Name | Category | Recoverable | Module Scope | Action |
| --------- | ------------------------ | --------------- | ----------------- | --------------------------------------- | ------------------------------------------------------------------------------------------ |
| 6001 | CustodyDiscrepancy | Custody | No — system-level | All | Wait for oracle consensus. Contact platform support. |
| 6002 | CustodyOracleUnavailable | Custody | Yes — transient | All | Retry after 1 block (\~400ms). |
| 6003 | SenderSanctioned | Sanctions | No | All | OFAC-flagged wallet. Cannot trade. |
| 6004 | ReceiverSanctioned | Sanctions | No | All | Receiver is OFAC-flagged. Cannot receive. |
| 6005 | OfacOracleStale | Sanctions | Yes — transient | All | OFAC oracle refreshing. Retry in minutes. |
| 6006 | AMLHighRisk | AML | No | All | AML score >70. Contact Empire Stock Transfer. |
| 6007 | InvalidSigner | CEI | No | All | Transaction not properly signed. |
| 6008–6019 | Structural Integrity | CEI | Varies | All | See detailed error message. |
| 6020 | WalletLimitExceeded | Position | Yes | All | Reduce order size below per-mint cap (4.99% default; up to 9.99% for some Module 2 mints). |
| 6021 | PriceImpactExceeded | Circuit Breaker | Yes | All; M2 includes NAV-deviation variant | Reduce order size or split. M2: check NAV deviation. |
| 6022 | VelocityExceeded | Position | Yes — timed | All | Slow down — wait for velocity window. |
| 6023 | CrossWalletDetected | Position | No | All | Behavioral clustering flagged. Contact compliance. |
| 6024 | TokensLocked | Holding Period | Yes — timed | All; Reg D / Reg S / Reg CF variants | Wait for the applicable Reg D / Reg S / Reg CF holding period. |
| 6036 | GlobalCircuitBreaker | Emergency | Yes — timed | All | All trading halted. Wait for cooldown (15 min). |
| 6037 | DailySellLimitExceeded | Volume | Yes — timed | All | 30% daily sell limit reached. Wait 24h. |
| 6038 | CustodyDiscrepancyHalt | Emergency | No — system-level | All | Custody issue. Wait for 2-of-3 oracle consensus. |
| 6039 | OFACEmergencyBlock | Emergency | No | All | Treasury emergency SDN update. |
| 6040 | OracleConsensusFail | Emergency | Yes — transient | All | Oracle consensus not reached. Retry. |
| 6041 | ControlledMigration | Governance | Yes — timed | All | Upgrade in progress. Wait for completion. |
| 6042 | RegulatoryOverride | Regulatory | No | All; M3 includes federal-action variant | Legal Counsel + 3-of-5 multi-sig freeze. M3: federal action active. |
#### Error Recovery Pattern
```typescript
import { RwaTokensError, TransferHookError, isRetryable } from '@rwatokens/sdk';
async function executeWithRetry(fn: () => Promise, maxRetries = 3) {
for (let attempt = 0; attempt < maxRetries; attempt++) {
try {
return await fn();
} catch (error) {
if (error instanceof TransferHookError) {
if (!isRetryable(error.code)) {
// Non-recoverable — surface to user
throw error;
}
// Retryable error — exponential backoff
const delay = Math.pow(2, attempt) * 1000;
console.warn(`Retryable error ${error.code}: ${error.name}. Retry in ${delay}ms`);
await new Promise(r => setTimeout(r, delay));
continue;
}
throw error;
}
}
throw new Error('Max retries exceeded');
}
```
***
### 15. Utilities
#### PDA Derivation
```typescript
import { derivePDA } from '@rwatokens/sdk';
// Cross-module PDAs
const [securityConfig, b1] = derivePDA.securityConfig(mintAddress);
// Seeds: [b"security-config", mint]
const [holdingPeriod, b2] = derivePDA.holdingPeriod(mintAddress, beneficiaryWallet);
// Seeds: [b"holding-period", mint, beneficiary]
const [custodyOracle, b3] = derivePDA.custodyOracle(mintAddress);
// Seeds: [b"custody-oracle", mint]
const [ofacOracle, b4] = derivePDA.ofacOracle();
// Seeds: [b"ofac-oracle"]
const [amlOracle, b5] = derivePDA.amlOracle(walletAddress);
// Seeds: [b"aml-oracle", wallet]
// Module 2 — NAV oracle
const [navOracle, b6] = derivePDA.navOracle(module2MintAddress);
// Seeds: [b"nav-oracle", mint]
// Module 3 — Classification oracle
const [classificationOracle, b7] = derivePDA.classificationOracle(module3MintAddress);
// Seeds: [b"classification-oracle", mint]
```
#### Format Helpers
```typescript
import { format } from '@rwatokens/sdk';
format.bpsToPercent(499); // '4.99%'
format.bpsToPercent(200); // '2.00%'
format.bpsToPercent(2200); // '22.00%' (default M2 NAV deviation tolerance)
format.lamportsToSol(10_000_000_000n); // '10.000000000'
format.tokenAmount(1_000_000_000n, 9); // '1.000000000'
format.holdingPeriod(15_778_800); // '6 months (Reg D)'
format.holdingPeriod(31_536_000, 'NonUS'); // '12 months (Reg S)'
format.holdingPeriod(31_536_000, 'RegCF'); // '12 months (Reg CF)'
format.secondsToHuman(1572300); // '18d 4h 45m'
format.controlId(24); // 'HP-24'
format.errorCode(6024); // 'TokensLocked (6024): Holding Period'
format.module('equities'); // 'Module 1 — Equities'
format.module('real_estate'); // 'Module 2 — Real Estate'
format.module('corecm'); // 'Module 3 — CORECM'
```
#### Anchor IDL
Access the raw Anchor IDL for advanced use cases.
```typescript
import { IDL } from '@rwatokens/sdk';
// Transfer Hook IDL
const hookIdl = IDL.transferHook;
// AMM IDL
const ammIdl = IDL.amm;
// Oracle Aggregator IDL (includes NAV and Classification oracle accounts)
const oracleIdl = IDL.oracleAggregator;
// Use with Anchor Program
import { Program } from '@coral-xyz/anchor';
const hookProgram = new Program(hookIdl, programId, provider);
```
***
### 16. Security Best Practices
#### Wallet Key Management
```typescript
// NEVER hardcode private keys
// Bad
const wallet = Keypair.fromSecretKey(new Uint8Array([1, 2, 3, /* ... */]));
// Use environment variables
const wallet = Keypair.fromSecretKey(
Uint8Array.from(JSON.parse(process.env.WALLET_PRIVATE_KEY!))
);
// Use Ledger hardware wallet for institutional operations
import { LedgerWallet } from '@rwatokens/sdk/ledger';
const wallet = await LedgerWallet.connect();
```
#### Transaction Verification
```typescript
// Always verify Transfer Hook status before interacting with a mint
const status = await client.hooks.verify(mintAddress);
if (!status.isValid || status.controlsActive !== 42) {
throw new Error('Mint does not have valid Transfer Hook');
}
// Always verify custody before trading (cross-module)
const custody = await client.custody.getAttestation(mintAddress);
if (custody.ratio !== 1.0 || custody.discrepancyDetected) {
throw new Error('Custody discrepancy — do not trade');
}
// Module 2: verify NAV freshness and deviation
const config = await client.hooks.getSecurityConfig(mintAddress);
if (config.module === 'real_estate') {
const dev = await client.oracle.computeNAVDeviation(mintAddress);
if (!dev.withinTolerance) {
throw new Error(`NAV deviation ${dev.deviationBps} bps outside tolerance`);
}
}
// Module 3: verify federal-action status
if (config.module === 'corecm') {
const cls = await client.oracle.getClassification(mintAddress);
if (cls?.federalActionActive) {
throw new Error('Federal action freeze active — cannot trade');
}
}
```
#### Rate Limiting
```typescript
// SDK enforces rate limits to prevent RPC throttling
// Default: 100 requests/second, 50 sendTransaction/second
const client = new RwaTokensClient({
network: 'mainnet-beta',
rateLimits: {
requestsPerSecond: 100,
sendTxPerSecond: 50,
},
});
```
***
### 17. Network Configuration
#### Devnet
```typescript
const client = new RwaTokensClient({
network: 'devnet',
rpcEndpoint: 'https://devnet.helius-rpc.com/?api-key=YOUR_KEY',
});
// Devnet has the same program structure but uses test oracle data:
// Custody oracle: simulated Empire attestations
// OFAC oracle: test SDN list
// AML oracle: configurable test scores
// NAV oracle (M2): simulated NAV with configurable cadence
// Classification (M3): test critical-mineral and federal-action data
```
#### Mainnet
```typescript
const client = new RwaTokensClient({
network: 'mainnet-beta',
rpcEndpoint: 'https://mainnet.helius-rpc.com/?api-key=YOUR_KEY',
jitoEnabled: true, // MEV protection for production trades
commitment: 'confirmed',
priorityFee: 'auto', // Dynamic Jito tip
});
```
#### Localnet (Development)
```typescript
const client = new RwaTokensClient({
network: 'localnet',
rpcEndpoint: 'http://localhost:8899',
});
// Deploy local programs first:
// anchor deploy --provider.cluster localnet
```
***
### 18. Examples
#### Example 1: Verify an ST22 Token (any module)
```typescript
import { RwaTokensClient } from '@rwatokens/sdk';
import { PublicKey } from '@solana/web3.js';
const client = new RwaTokensClient({ network: 'mainnet-beta' });
const mint = new PublicKey('7xK...');
// 1. Verify Transfer Hook is attached
const hook = await client.hooks.verify(mint);
console.log(`Hook active: ${hook.isValid}`);
console.log(`Controls: ${hook.controlsActive}`);
console.log(`Bypass possible: ${hook.bypassPossible}`);
// 2. Read security config — surfaces module
const config = await client.hooks.getSecurityConfig(mint);
console.log(`Module: ${config.module}`);
console.log(`Max wallet: ${config.maxWalletPercent / 100}%`);
console.log(`Price impact limit: ${config.priceImpactMaxBps / 100}%`);
console.log(`Circuit breaker: ${config.circuitBreakerTriggered ? 'ACTIVE' : 'normal'}`);
// 3. Check custody attestation (cross-module)
const custody = await client.custody.getAttestation(mint);
console.log(`Custodied balance: ${custody.custodiedBalance}`);
console.log(`Token supply: ${custody.tokenSupply}`);
console.log(`1:1 ratio: ${custody.ratio === 1.0}`);
console.log(`Ed25519 verified: ${custody.ed25519Verified}`);
// 4. Module-specific oracle checks
if (config.module === 'real_estate') {
const nav = await client.oracle.getNAV(mint);
console.log(`NAV: $${nav?.appraisedNavUsd}`);
console.log(`NAV stale: ${nav?.isStale}`);
}
if (config.module === 'corecm') {
const cls = await client.oracle.getClassification(mint);
console.log(`USGS: ${cls?.usgsCriticalStatus}`);
console.log(`Federal action active: ${cls?.federalActionActive}`);
}
```
#### Example 2: Check Holding Period Before Selling
```typescript
import { RwaTokensClient, TransferHookError } from '@rwatokens/sdk';
const client = new RwaTokensClient({ network: 'mainnet-beta', wallet });
const holding = await client.holdingPeriod.getStatus({
mint: mintAddress,
beneficiary: wallet.publicKey,
});
if (holding.isLocked) {
console.log(`Tokens locked until ${holding.unlockDateISO}`);
console.log(`${holding.secondsRemaining} seconds remaining`);
console.log(`Regime: ${holding.regime}`);
console.log(
`Rule: ${holding.regime === 'RegD' ? 'Reg D (6 months)'
: holding.regime === 'RegS' ? 'Reg S (12 months)'
: 'Reg CF (12 months)'}`
);
} else {
// Safe to sell
const order = await client.cedex.placeOrder({
mint: mintAddress,
side: 'sell',
type: 'market',
amount: holding.balance,
slippageBps: 100,
});
console.log(`Sold: TX ${order.txSignature}`);
}
```
#### Example 3: Real-Time Custody Monitoring (cross-module)
```typescript
import { RwaTokensClient } from '@rwatokens/sdk';
const client = new RwaTokensClient({ network: 'mainnet-beta' });
await client.ws.connect();
// Monitor all custody attestations for a mint — works for any module
client.ws.subscribeCustody(mintAddress, (attestation) => {
const { custodiedBalance, tokenSupply, ratio, ed25519Verified } = attestation;
if (ratio !== 1.0 || !ed25519Verified) {
console.error(`[ALERT] Custody issue on ${mintAddress}`);
console.error(` Custodied: ${custodiedBalance}, Supply: ${tokenSupply}, Ratio: ${ratio}`);
// All transfers will be halted by Transfer Hook Controls CV-01 to CV-06
}
});
// Monitor circuit breaker events (includes M2 nav_deviation, M3 classification_stale)
client.ws.subscribeCircuitBreaker(mintAddress, (event) => {
console.warn(`[BREAKER] ${event.type} triggered on ${mintAddress}`);
console.warn(` Cooldown: ${event.cooldownSecs}s`);
});
```
#### Example 4: Module 2 NAV Monitoring
```typescript
import { RwaTokensClient } from '@rwatokens/sdk';
const client = new RwaTokensClient({ network: 'mainnet-beta' });
await client.ws.connect();
// Monitor NAV oracle for a Module 2 mint
client.ws.subscribeNAV(module2MintAddress, async (update) => {
console.log(`NAV updated: $${update.appraisedNavUsd}`);
console.log(`Next reappraisal: ${new Date(update.nextReappraisalTarget * 1000).toISOString()}`);
// Check current deviation from on-chain price
const dev = await client.oracle.computeNAVDeviation(module2MintAddress);
console.log(`Deviation: ${dev.deviationBps} bps`);
console.log(`Within tolerance: ${dev.withinTolerance}`);
if (!dev.withinTolerance) {
console.warn('[ALERT] Mint paused on AMM until NAV deviation restored');
}
});
```
#### Example 5: Module 3 Federal-Action Monitoring
```typescript
import { RwaTokensClient } from '@rwatokens/sdk';
const client = new RwaTokensClient({ network: 'mainnet-beta' });
await client.ws.connect();
// Monitor Classification oracle for a Module 3 mint
client.ws.subscribeClassification(module3MintAddress, (update) => {
if (update.eventType === 'federal_action_detected') {
console.error('[P0] Federal action detected:', update.actionReferences);
console.error('Detection-to-freeze SLA: 60 minutes');
// Operational response per Incident Response Playbook §13
return;
}
if (update.eventType === 'federal_action_freeze_applied') {
console.error('Control 42 freeze applied — mint frozen');
return;
}
// Routine classification refresh
console.log(`USGS: ${update.usgsCriticalStatus}`);
console.log(`DOE: ${update.doeMaterialsStatus}`);
});
```
#### Example 6: Simulate Before Trading (module-aware)
```typescript
import { RwaTokensClient, TransferHookError, isRetryable } from '@rwatokens/sdk';
const client = new RwaTokensClient({ network: 'mainnet-beta', wallet });
// Step 1: Simulate the transfer
const sim = await client.hooks.simulateTransfer({
mint: mintAddress,
source: wallet.publicKey,
destination: recipientWallet,
amount: 50_000_000n,
});
if (!sim.wouldSucceed) {
// Find which control failed
for (const [id, result] of sim.controlResults) {
if (!result.passed) {
console.error(`Control ${id} failed: ${result.error} (${result.code})`);
console.error(` Details: ${JSON.stringify(result.details)}`);
if (result.code === 6024) {
console.log(` Regime: ${result.details.regime}`);
console.log(` Unlock in: ${result.details.secondsRemaining}s`);
}
if (result.code === 6020) {
console.log(` Current: ${result.details.currentPercent}%, Max: ${result.details.maxPercent}%`);
}
if (result.code === 6021 && result.details?.variant === 'nav_deviation') {
console.log(` NAV deviation: ${result.details.deviationBps} bps`);
console.log(` Tolerance: ${result.details.toleranceBps} bps`);
}
if (result.code === 6042 && result.details?.variant === 'federal_action') {
console.log(` Federal action references: ${result.details.actionReferences}`);
}
}
}
return;
}
// Step 2: Estimate the swap (module-aware pre-flight surfaces here)
const estimate = await client.cedex.estimateSwap({
mint: mintAddress,
side: 'sell',
inputAmount: 50_000_000n,
});
console.log(`Output: ${estimate.outputAmount} SOL`);
console.log(`Impact: ${estimate.priceImpactBps} bps`);
console.log(`Fee: ${estimate.fee.totalBps} bps`);
console.log(`Pre-flight: ${estimate.preFlightResult.passed ? 'PASS' : 'FAIL'}`);
// Step 3: Execute
if (estimate.preFlightResult.passed && !estimate.wouldTriggerCircuitBreaker) {
const order = await client.cedex.placeOrder({
mint: mintAddress,
side: 'sell',
type: 'market',
amount: 50_000_000n,
slippageBps: 100,
});
console.log(`Executed: ${order.txSignature}`);
}
```
***
### Changelog
#### v1.0.0 (Q3 2026)
* Initial release — mainnet support across all three modules at launch.
* Module-aware client supporting Module 1 (Equities), Module 2 (Real Estate), and Module 3 (CORECM) on a single `RwaTokensClient` instance.
* Transfer Hook verification and module-aware simulation.
* Custody oracle queries with Ed25519 verification (cross-module).
* NAV oracle queries (Module 2) and Classification oracle queries (Module 3).
* Holding period status with Reg D, Reg S, and Reg CF regime support; batch queries.
* CEDEX order placement, cancellation, and module-aware pre-flight estimation.
* Portfolio management with module-aware position surfacing (NAV status, classification status).
* Market data (order book, trades, OHLCV) with module filter.
* WebSocket subscriptions including module-specific NAV (M2) and Classification (M3) channels.
* Full error code registry with module-aware variants for 6021 (NAV-deviation) and 6042 (federal-action).
* PDA derivation utilities including NAV oracle and Classification oracle.
* Anchor IDL exports.
* Ledger hardware wallet support.
***
### License
Business Source License 1.1 — See `LICENSE`.
***
### Related Documentation
* **CEDEX API Reference** — REST and WebSocket endpoints with module-aware surface.
* **CEDEX API Changelog** — Version history with module-aware migration guides.
* **Smart Contract Reference** — On-chain program documentation including module-aware program behavior.
* **Transfer Hook Reference** — Standalone reference for the 42 controls and module-aware extensions.
* **Oracle Integration Guide** — Custody, OFAC, AML, TWAP, EDGAR (M1), NAV (M2), and Classification (M3) relay architecture.
* **Network Configuration** — Mainnet program IDs, RPC endpoints, oracle PDAs.
* **Incident Response Playbook** — P0 through P3 runbooks; Module 3 federal-action freeze runbook (§13).
***
*`@rwatokens/sdk` · RWA Tokens · Groovy Company, Inc.*
# Testing Guide
## Testing Guide
**Unit · Integration · Fuzz · Formal Verification · Load · Chaos · CI/CD · Module-Aware**
Complete testing methodology for all five on-chain programs deployed by Groovy Company, Inc. across the three production modules — Equities (Module 1), Real Estate (Module 2), and CORECM — Carbon Ore, Rare Earth, and Critical Minerals (Module 3). This guide defines test strategy, coverage targets, execution procedures, fixture data, and CI/CD pipeline configuration. Required reading for contributors, auditors verifying test coverage, and the QA team executing pre-deployment validation.
The same test apparatus exercises all three modules. Module-specific test scenarios (Module 2 NAV-deviation enforcement, Module 3 federal-action freeze coordination) sit alongside cross-module scenarios (custody, holding period across Reg D / Reg S / Reg CF, OFAC, AML).
***
### Table of Contents
1. Testing Strategy
2. Environment Setup
3. Unit Tests
4. Integration Tests
5. Fuzz Testing
6. Formal Verification (Certora)
7. Load Testing
8. Chaos Testing
9. Test Fixtures and Data
10. Coverage Requirements
11. CI/CD Pipeline
12. Pre-Deployment Checklist
13. Troubleshooting
***
### 1. Testing Strategy
#### 1.1 Testing Pyramid
```
┌──────────┐
│ Formal │ Certora Prover — 6 invariants
│ Verify │ Mathematical proof, not sampling
├──────────┤ E.4 covers module-aware extensions
┌─┤ Load ├─┐ 600 TPS sustained
│ │ & Chaos │ │ Oracle failure injection (all 7)
│ ├──────────┤ │
┌─┤ │ Fuzz │ ├─┐ 100,000+ random inputs
│ │ │ Testing │ │ │ Hook + CPMM + NAV + Classification
│ │ ├──────────┤ │ │
┌─┤ │ │Integration│ │ ├─┐ 42 controls end-to-end
│ │ │ │ Tests │ │ │ │ Full lifecycle per module
│ │ │ ├──────────┤ │ │ │
┌─┤ │ │ │ Unit │ │ │ ├─┐ Per-control
│ │ │ │ │ Tests │ │ │ │ │ Per-function
└─┴─┴─┴─┴──────────┴─┴─┴─┴─┘
HIGH VOLUME ──────── LOW VOLUME
FAST ──────────────── SLOW
```
#### 1.2 Coverage Targets
| Test Type | Tool | Coverage Target | Run Time | Frequency |
| ------------------- | ----------------- | ------------------------------------------------------ | ------------- | --------------------- |
| Unit | `cargo test` | 100% control logic; 100% module-aware extensions | <60 seconds | Every commit |
| Integration | `anchor test` | All 42 controls E2E across Module 1, 2, and 3 | <5 minutes | Every PR |
| Fuzz | `cargo fuzz` | Transfer Hook, CPMM, NAV oracle, Classification oracle | 100,000+ runs | Weekly + pre-release |
| Formal verification | Certora Prover | 6 invariants — E.4 covers module-aware extensions | \~30 minutes | Pre-release |
| Load | Custom generator | 600 TPS sustained across all modules | \~15 minutes | Pre-release |
| Chaos | Failure injection | All fail-safe paths across 7 oracle categories | \~30 minutes | Monthly + pre-release |
#### 1.3 What Gets Tested Where
| Component | Unit | Integration | Fuzz | Formal | Load | Chaos | Module Scope |
| --------------------------- | ----------------------------------------- | ----------------------------------------------------------------- | --------------------------------- | ------------------ | --------------------- | -------------------------------------- | --------------------- |
| Transfer Hook (42 controls) | Each control individually | Full 42-control execution per module | Random inputs | E.1, E.2, E.4, E.6 | 600 TPS with hooks | Oracle failure | All modules |
| CPMM arithmetic | `calculate_output_amount` | Buy/sell/fee flows | u128 overflow | E.5 (fee accuracy) | Concurrent swaps | — | All modules |
| Global Pool | Deposit function | Fee routing across modules | Extraction attempts | E.3 (non-extract) | Fee accumulation | — | All modules |
| Custody Oracle | Signature verification | Attestation flow | Malformed payloads | E.1, E.2 | Per-block update | Relay killed | All modules |
| Circuit Breakers | Trigger/reset logic | Price impact + volume halt + NAV deviation + Classification stale | Boundary values | E.6 (correctness) | Sustained load | TWAP stale | All modules + M2 + M3 |
| Holding Period | Timer logic across Reg D / Reg S / Reg CF | Lock/unlock lifecycle per regime | Timestamp edge cases | — | — | — | All modules |
| Governance | Proposal/vote/execute | Timelock enforcement; module-specific param adjustments | — | — | — | — | All modules |
| **NAV Oracle** | Signature verification + deviation math | Module 2 NAV-deviation lifecycle | Malformed appraisal payloads | E.4 (covered) | NAV updates per cycle | Relay killed; deviation injection | **Module 2** |
| **Classification Oracle** | Federal-action state transitions | Module 3 federal-action freeze E2E | Malformed federal-action payloads | E.4 (covered) | Federal-action storms | Relay killed; federal-action injection | **Module 3** |
***
### 2. Environment Setup
#### 2.1 Test Dependencies
```bash
# Core
rustup update stable
cargo install cargo-tarpaulin # Coverage
cargo install cargo-fuzz # Fuzz testing
cargo install cargo-nextest # Fast test runner
# Anchor
anchor --version # Must be 0.30+
# Node.js (integration tests)
yarn install
# Solana test validator
solana-test-validator --version
```
#### 2.2 Local Test Validator
```bash
# Start with Token-2022 support
solana-test-validator \
--bpf-program TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
target/deploy/spl_token_2022.so \
--reset \
--quiet
# Verify
solana cluster-version
```
#### 2.3 Test Configuration
```toml
# Anchor.toml
[test]
startup_wait = 5000
[test.validator]
url = "http://localhost:8899"
[[test.validator.clone]]
address = "TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb"
[scripts]
test = "yarn run ts-mocha -p ./tsconfig.json -t 1000000 tests/**/*.ts"
```
***
### 3. Unit Tests
#### 3.1 Running Unit Tests
```bash
# All programs
cargo test --workspace
# Specific program
cargo test -p transfer-hook
cargo test -p amm
cargo test -p liquidity-pool
cargo test -p governance
cargo test -p oracle-aggregator
# Module-specific test modules
cargo test -p transfer-hook nav_deviation # Module 2 extensions
cargo test -p transfer-hook federal_action # Module 3 extensions
cargo test -p oracle-aggregator nav_oracle # Module 2 oracle
cargo test -p oracle-aggregator classification_oracle # Module 3 oracle
# Verbose output (shows print statements)
cargo test --workspace -- --nocapture
# Fast runner (parallel execution)
cargo nextest run --workspace
```
#### 3.2 Transfer Hook Unit Tests
Each of the 42 controls has dedicated unit tests covering pass, fail, and boundary conditions. Module-aware extensions (Module 2 CB-21 NAV-deviation; Module 3 REG-42 federal-action) have additional dedicated test modules.
**Test Pattern (Wallet Limit, Cross-Module)**
```rust
// tests/unit/transfer_hook/test_wallet_limit.rs
#[cfg(test)]
mod tests {
use super::*;
use crate::state::SecurityConfig;
fn default_config() -> SecurityConfig {
SecurityConfig {
max_wallet_percent: 499, // 4.99%
..SecurityConfig::default()
}
}
#[test]
fn test_wallet_limit_under_threshold() {
// Wallet holds 4.00% → transfer of 0.50% → total 4.50% → PASS
let config = default_config();
let current_balance = 40_000_000; // 4.00% of 1B supply
let transfer_amount = 5_000_000; // 0.50%
let total_supply = 1_000_000_000;
let result = check_wallet_limit(
current_balance,
transfer_amount,
total_supply,
config.max_wallet_percent,
);
assert!(result.is_ok());
}
#[test]
fn test_wallet_limit_at_exact_threshold() {
// Wallet holds 0% → transfer of exactly 4.99% → PASS (≤ 4.99%)
let config = default_config();
let current_balance = 0;
let transfer_amount = 49_900_000; // 4.99% of 1B
let total_supply = 1_000_000_000;
let result = check_wallet_limit(
current_balance,
transfer_amount,
total_supply,
config.max_wallet_percent,
);
assert!(result.is_ok());
}
#[test]
fn test_wallet_limit_exceeds_threshold() {
// Wallet holds 0% → transfer of 5.00% → FAIL (> 4.99%)
let config = default_config();
let current_balance = 0;
let transfer_amount = 50_000_000; // 5.00% of 1B
let total_supply = 1_000_000_000;
let result = check_wallet_limit(
current_balance,
transfer_amount,
total_supply,
config.max_wallet_percent,
);
assert!(result.is_err());
assert_eq!(
result.unwrap_err(),
TransferHookError::WalletLimitExceeded.into()
);
}
#[test]
fn test_wallet_limit_module_2_higher_cap() {
// Module 2 mints may be issuer-configured up to 9.99%
let mut config = default_config();
config.max_wallet_percent = 999; // 9.99%
let current_balance = 0;
let transfer_amount = 99_000_000; // 9.90% — within Module 2 cap
let total_supply = 1_000_000_000;
let result = check_wallet_limit(
current_balance,
transfer_amount,
total_supply,
config.max_wallet_percent,
);
assert!(result.is_ok());
}
#[test]
fn test_wallet_limit_max_u64() {
// Edge case: maximum u64 values → no overflow
let config = default_config();
let result = check_wallet_limit(
u64::MAX / 2,
u64::MAX / 2,
u64::MAX,
config.max_wallet_percent,
);
// Should not panic — u128 intermediate arithmetic
assert!(result.is_ok() || result.is_err());
}
}
```
**Module 2 — NAV-Deviation Unit Tests**
```rust
// tests/unit/transfer_hook/test_nav_deviation.rs
#[cfg(test)]
mod nav_deviation_tests {
use super::*;
fn module_2_config() -> SecurityConfig {
SecurityConfig {
module: ModuleId::RealEstate,
max_wallet_percent: 999, // M2 may use 9.99%
nav_deviation_max_bps: Some(2200), // 22% default
nav_reappraisal_max_age_secs: Some(7_776_000), // 90 days
nav_circuit_breaker_enabled: Some(true),
..SecurityConfig::default()
}
}
#[test]
fn test_nav_deviation_within_tolerance() {
// On-chain price 105, NAV 100 → +5% (500 bps) → within 22%
let config = module_2_config();
let on_chain_price_usd = 10_500_000_000u128;
let appraised_nav_usd = 10_000_000_000u128;
let result = check_nav_deviation(on_chain_price_usd, appraised_nav_usd, &config);
assert!(result.is_ok());
}
#[test]
fn test_nav_deviation_exact_threshold() {
// 22% above NAV — exactly at threshold → PASS (≤)
let config = module_2_config();
let appraised_nav_usd = 10_000_000_000u128;
let on_chain_price_usd = 12_200_000_000u128; // +22.00%
let result = check_nav_deviation(on_chain_price_usd, appraised_nav_usd, &config);
assert!(result.is_ok());
}
#[test]
fn test_nav_deviation_exceeds_threshold() {
// 23% above NAV — exceeds 22% → FAIL
let config = module_2_config();
let appraised_nav_usd = 10_000_000_000u128;
let on_chain_price_usd = 12_300_000_000u128; // +23.00%
let result = check_nav_deviation(on_chain_price_usd, appraised_nav_usd, &config);
assert!(result.is_err());
assert_eq!(
result.unwrap_err(),
TransferHookError::PriceImpactExceeded.into()
);
}
#[test]
fn test_nav_deviation_negative_within_tolerance() {
// 15% below NAV — within tolerance
let config = module_2_config();
let appraised_nav_usd = 10_000_000_000u128;
let on_chain_price_usd = 8_500_000_000u128; // -15%
let result = check_nav_deviation(on_chain_price_usd, appraised_nav_usd, &config);
assert!(result.is_ok());
}
#[test]
fn test_nav_stale_pauses_mint() {
let config = module_2_config();
let last_appraisal_ts = 1_700_000_000;
let now = last_appraisal_ts + 7_776_001; // exceeds 90-day threshold by 1s
let result = check_nav_freshness(last_appraisal_ts, now, &config);
assert!(result.is_err());
}
#[test]
fn test_module_1_skips_nav_check() {
// Module 1 mint — no NAV oracle → check returns Ok unconditionally
let config = SecurityConfig {
module: ModuleId::Equities,
..SecurityConfig::default()
};
let result = check_nav_deviation(0, 0, &config);
assert!(result.is_ok());
}
}
```
**Module 3 — Federal-Action Freeze Unit Tests**
```rust
// tests/unit/transfer_hook/test_federal_action.rs
#[cfg(test)]
mod federal_action_tests {
use super::*;
fn module_3_config() -> SecurityConfig {
SecurityConfig {
module: ModuleId::Corecm,
classification_max_age_secs: Some(86_400), // 24h
federal_action_freeze_enabled: Some(true),
..SecurityConfig::default()
}
}
#[test]
fn test_federal_action_inactive_passes() {
let config = module_3_config();
let oracle_state = ClassificationOracleState {
federal_action_active: false,
..ClassificationOracleState::default()
};
let result = enforce_federal_action_freeze(&oracle_state, &config);
assert!(result.is_ok());
}
#[test]
fn test_federal_action_active_blocks() {
let config = module_3_config();
let oracle_state = ClassificationOracleState {
federal_action_active: true,
active_action_refs: vec!["EO-14118".to_string()],
..ClassificationOracleState::default()
};
let result = enforce_federal_action_freeze(&oracle_state, &config);
assert!(result.is_err());
assert_eq!(
result.unwrap_err(),
TransferHookError::RegulatoryOverride.into()
);
}
#[test]
fn test_classification_stale_flagged_not_blocked() {
// Classification stale beyond threshold — flagged but transfer continues
let config = module_3_config();
let last_refresh_ts = 1_700_000_000;
let now = last_refresh_ts + 86_401; // 1s past 24h
let result = check_classification_freshness(last_refresh_ts, now, &config);
assert!(result.is_ok()); // Allowed
assert!(result.unwrap().flagged_for_review);
}
#[test]
fn test_module_1_skips_federal_action_check() {
// Module 1 mint — no Classification oracle → check returns Ok
let config = SecurityConfig {
module: ModuleId::Equities,
..SecurityConfig::default()
};
let result = enforce_federal_action_freeze(
&ClassificationOracleState::default(),
&config,
);
assert!(result.is_ok());
}
#[test]
fn test_federal_action_freeze_can_be_disabled_per_mint() {
let mut config = module_3_config();
config.federal_action_freeze_enabled = Some(false);
let oracle_state = ClassificationOracleState {
federal_action_active: true,
..ClassificationOracleState::default()
};
// With per-mint toggle disabled, Control 42 must be invoked manually
let result = enforce_federal_action_freeze(&oracle_state, &config);
assert!(result.is_ok());
}
}
```
**Control Test Matrix (Module-Aware)**
| Control | Pass Test | Fail Test | Boundary Test | Module-Aware Variant |
| ---------------------- | ------------------ | ------------------- | ---------------------- | ---------------------------------------- |
| CV-01 (Custody) | Supply = balance | Supply > balance | Supply = balance + 1 | Asset class per module |
| CV-02 (Oracle fresh) | Slot age = 0 | Slot age = 5 | Slot age = 1 | All modules |
| SC-30 (OFAC sender) | Wallet not on SDN | Wallet on SDN | — | All modules |
| IV-09 (AML) | Score = 25 | Score = 75 | Score = 30, 31, 70, 71 | Module 3 enhanced KYC depth |
| PL-16 (Wallet limit) | 4.50% post (M1/M3) | 5.01% post (M1/M3) | 4.99% exactly | Module 2 cap up to 9.99% |
| CB-20 (Price halt) | 8% move in 5 min | 12% move in 5 min | 10.0% exactly | All modules |
| CB-21 (Price impact) | 1.5% impact | 3.0% impact | 2.0% exactly | **Module 2: NAV deviation also checked** |
| HP-24 (Holding period) | Reg D 7 mo elapsed | Reg D 5 mo elapsed | Reg D 6 mo exactly | Reg D / Reg S / Reg CF variants |
| REG-42 (Reg freeze) | Not paused | Paused by authority | — | **Module 3: federal-action variant** |
#### 3.3 CPMM Arithmetic Unit Tests
```rust
#[cfg(test)]
mod cpmm_tests {
use super::*;
#[test]
fn test_basic_swap() {
// 10 SOL into pool with 100 SOL / 1M tokens, 5% fee
let result = calculate_output_amount(
10_000_000_000, // 10 SOL (lamports)
100_000_000_000, // 100 SOL reserve
1_000_000_000_000, // 1M tokens (9 decimals)
500, // 5% fee
).unwrap();
// Expected: ~86,758 tokens (after fee)
assert!(result.output_amount > 86_000_000_000);
assert!(result.output_amount < 87_000_000_000);
// Fee should be 5% of input
let expected_fee = 10_000_000_000 * 500 / 10_000;
assert_eq!(result.fee_amount, expected_fee);
}
#[test]
fn test_k_invariant_preserved() {
let reserve_sol = 100_000_000_000u64;
let reserve_token = 1_000_000_000_000u64;
let k_before = reserve_sol as u128 * reserve_token as u128;
let result = calculate_output_amount(
10_000_000_000,
reserve_sol,
reserve_token,
500,
).unwrap();
let new_sol = reserve_sol + 10_000_000_000 - result.fee_amount;
let new_token = reserve_token - result.output_amount;
let k_after = new_sol as u128 * new_token as u128;
// k should only increase (fees add to pool) — invariant holds for
// Module 1, Module 2, and Module 3 mints uniformly
assert!(k_after >= k_before);
}
#[test]
fn test_fee_distribution_sums_to_total() {
// 0.44 + 2.00 + 1.50 + 1.06 = 5.00% — must be exact across all modules
let pool_bps = 44u16;
let issuer_bps = 200u16;
let staking_bps = 150u16;
let protocol_bps = 106u16;
let total_bps = 500u16;
assert_eq!(pool_bps + issuer_bps + staking_bps + protocol_bps, total_bps);
}
#[test]
fn test_u128_no_overflow() {
// Max u64 reserves — must not overflow
let result = calculate_output_amount(
u64::MAX / 100,
u64::MAX / 2,
u64::MAX / 2,
500,
);
assert!(result.is_ok());
}
#[test]
fn test_fee_accuracy_within_1_lamport() {
// Certora invariant E.5: |actual_fee - expected_fee| ≤ 1
for amount in [1, 100, 10_000, 1_000_000, u64::MAX / 1000] {
let result = calculate_output_amount(
amount,
100_000_000_000,
1_000_000_000_000,
500,
);
if let Ok(r) = result {
let expected_fee = (amount as u128 * 500 / 10_000) as u64;
let diff = if r.fee_amount > expected_fee {
r.fee_amount - expected_fee
} else {
expected_fee - r.fee_amount
};
assert!(diff <= 1, "Fee accuracy > 1 lamport for amount {}", amount);
}
}
}
}
```
#### 3.4 Holding Period Unit Tests — Reg D / Reg S / Reg CF
```rust
#[cfg(test)]
mod holding_period_tests {
use super::*;
// Holding-period constants — immutable program constants
const REG_D_HOLDING_SECS: i64 = 15_778_800; // 6 months
const REG_S_HOLDING_SECS: i64 = 31_536_000; // 12 months
const REG_CF_HOLDING_SECS: i64 = 31_536_000; // 12 months
#[test]
fn test_reg_d_locked_within_6_months() {
let account = HoldingPeriodAccount {
jurisdiction: Jurisdiction::US,
regime: HoldingRegime::RegD,
purchase_timestamp: 1_700_000_000,
holding_period_secs: REG_D_HOLDING_SECS,
is_locked: true,
..Default::default()
};
// 5 months later — still locked under Reg D
let clock = mock_clock(1_700_000_000 + 13_000_000);
let result = enforce_holding_period(&account, &clock);
assert_eq!(result.unwrap_err(), TransferHookError::TokensLocked.into());
}
#[test]
fn test_reg_d_unlocked_after_6_months() {
let account = HoldingPeriodAccount {
jurisdiction: Jurisdiction::US,
regime: HoldingRegime::RegD,
purchase_timestamp: 1_700_000_000,
holding_period_secs: REG_D_HOLDING_SECS,
is_locked: true,
..Default::default()
};
// 7 months later — unlocked under Reg D
let clock = mock_clock(1_700_000_000 + 18_000_000);
let result = enforce_holding_period(&account, &clock);
assert!(result.is_ok());
}
#[test]
fn test_reg_d_exact_6_month_boundary() {
let account = HoldingPeriodAccount {
jurisdiction: Jurisdiction::US,
regime: HoldingRegime::RegD,
purchase_timestamp: 1_700_000_000,
holding_period_secs: REG_D_HOLDING_SECS,
is_locked: true,
..Default::default()
};
// Exactly 6 months — should PASS (≥ threshold)
let clock = mock_clock(1_700_000_000 + REG_D_HOLDING_SECS);
let result = enforce_holding_period(&account, &clock);
assert!(result.is_ok());
// 1 second before — should FAIL
let clock = mock_clock(1_700_000_000 + REG_D_HOLDING_SECS - 1);
let result = enforce_holding_period(&account, &clock);
assert!(result.is_err());
}
#[test]
fn test_reg_s_12_month_holding() {
let account = HoldingPeriodAccount {
jurisdiction: Jurisdiction::NonUS,
regime: HoldingRegime::RegS,
purchase_timestamp: 1_700_000_000,
holding_period_secs: REG_S_HOLDING_SECS,
is_locked: true,
..Default::default()
};
// 11 months — locked under Reg S
let clock = mock_clock(1_700_000_000 + 29_000_000);
assert!(enforce_holding_period(&account, &clock).is_err());
// 13 months — unlocked under Reg S
let clock = mock_clock(1_700_000_000 + 34_000_000);
assert!(enforce_holding_period(&account, &clock).is_ok());
}
#[test]
fn test_reg_cf_12_month_holding() {
let account = HoldingPeriodAccount {
jurisdiction: Jurisdiction::RegCF,
regime: HoldingRegime::RegCF,
purchase_timestamp: 1_700_000_000,
holding_period_secs: REG_CF_HOLDING_SECS,
is_locked: true,
..Default::default()
};
// 11 months — locked under Reg CF
let clock = mock_clock(1_700_000_000 + 29_000_000);
assert!(enforce_holding_period(&account, &clock).is_err());
// 13 months — unlocked under Reg CF
let clock = mock_clock(1_700_000_000 + 34_000_000);
assert!(enforce_holding_period(&account, &clock).is_ok());
}
#[test]
fn test_already_unlocked() {
let account = HoldingPeriodAccount {
is_locked: false,
..Default::default()
};
// Already unlocked — always passes regardless of regime
let clock = mock_clock(0);
assert!(enforce_holding_period(&account, &clock).is_ok());
}
}
```
***
### 4. Integration Tests
#### 4.1 Running Integration Tests
```bash
# All integration tests (starts local validator)
anchor test
# Specific test file
anchor test -- --grep "transfer hook"
anchor test -- --grep "circuit breaker"
anchor test -- --grep "full lifecycle"
anchor test -- --grep "module 2"
anchor test -- --grep "module 3"
# Skip local validator (if already running)
anchor test --skip-local-validator
```
#### 4.2 Full Lifecycle Test — Module 1 (Equities)
The most important integration test for Module 1 — verifies the complete ST22 token lifecycle from mint to secondary trade.
```typescript
// tests/e2e/full-lifecycle-module1.ts
describe('ST22 Full Lifecycle — Module 1 Equities', () => {
let mint: PublicKey;
let issuerWallet: Keypair;
let investorRegD: Keypair;
let investorRegS: Keypair;
let investorRegCF: Keypair;
before(async () => {
issuerWallet = Keypair.generate();
investorRegD = Keypair.generate();
investorRegS = Keypair.generate();
investorRegCF = Keypair.generate();
await airdrop(issuerWallet.publicKey, 100);
await airdrop(investorRegD.publicKey, 100);
await airdrop(investorRegS.publicKey, 100);
await airdrop(investorRegCF.publicKey, 100);
});
it('Step 1: Creates Module 1 ST22 mint with Transfer Hook', async () => {
mint = await createST22Mint({
authority: issuerWallet,
hookProgram: transferHookProgramId,
decimals: 9,
module: 'equities',
});
const mintInfo = await getMint(connection, mint, 'confirmed', TOKEN_2022_PROGRAM_ID);
const hookExt = getTransferHook(mintInfo);
expect(hookExt.programId.toBase58()).to.equal(transferHookProgramId.toBase58());
});
it('Step 2: Initializes SecurityConfig for Module 1', async () => {
await program.methods
.initializeSecurityConfig({
module: { equities: {} },
maxWalletPercent: 499,
circuitBreakerThreshold: 3000,
circuitBreakerCooldown: new BN(86400),
priceImpactMaxBps: 200,
twapWindowSecs: 1800,
holdingPeriodEnabled: true,
})
.accounts({ mint, authority: issuerWallet.publicKey })
.signers([issuerWallet])
.rpc();
const config = await program.account.securityConfig.fetch(securityConfigPda);
expect(config.maxWalletPercent).to.equal(499);
expect(config.module).to.deep.equal({ equities: {} });
expect(config.holdingPeriodConfig.enabled).to.be.true;
});
it('Step 3: Initializes CustodyOracle (cross-module)', async () => {
await oracleProgram.methods
.initializeCustodyOracle(empirePublicKey)
.accounts({ mint, authority: issuerWallet.publicKey })
.signers([issuerWallet])
.rpc();
const oracle = await oracleProgram.account.custodyOracle.fetch(custodyOraclePda);
expect(oracle.empirePubkey.toBase58()).to.equal(empirePublicKey.toBase58());
});
it('Step 4: Mints ST22 tokens (1:1 with Empire custody)', async () => {
await updateCustodyOracle(mint, { custodiedBalance: 1_000_000_000, tokenSupply: 0 });
await mintTo(connection, issuerWallet, mint, issuerTokenAccount,
issuerWallet, 1_000_000_000);
await updateCustodyOracle(mint, {
custodiedBalance: 1_000_000_000, tokenSupply: 1_000_000_000,
});
const oracle = await oracleProgram.account.custodyOracle.fetch(custodyOraclePda);
expect(oracle.custodiedBalance.toNumber()).to.equal(oracle.tokenSupply.toNumber());
});
it('Step 5: Creates HoldingPeriodAccount for Reg D investor', async () => {
await program.methods
.initializeHoldingPeriod({ regime: { regD: {} }, jurisdiction: { us: {} } })
.accounts({
mint,
beneficiary: investorRegD.publicKey,
authority: empireAuthority.publicKey,
})
.signers([empireAuthority])
.rpc();
const holding = await program.account.holdingPeriodAccount.fetch(holdingPdaRegD);
expect(holding.regime).to.deep.equal({ regD: {} });
expect(holding.holdingPeriodSecs.toNumber()).to.equal(15_778_800);
expect(holding.isLocked).to.be.true;
});
it('Step 5b: Creates HoldingPeriodAccount for Reg S investor', async () => {
await program.methods
.initializeHoldingPeriod({ regime: { regS: {} }, jurisdiction: { nonUs: {} } })
.accounts({
mint,
beneficiary: investorRegS.publicKey,
authority: empireAuthority.publicKey,
})
.signers([empireAuthority])
.rpc();
const holding = await program.account.holdingPeriodAccount.fetch(holdingPdaRegS);
expect(holding.holdingPeriodSecs.toNumber()).to.equal(31_536_000);
});
it('Step 5c: Creates HoldingPeriodAccount for Reg CF investor', async () => {
await program.methods
.initializeHoldingPeriod({ regime: { regCf: {} }, jurisdiction: { regCf: {} } })
.accounts({
mint,
beneficiary: investorRegCF.publicKey,
authority: empireAuthority.publicKey,
})
.signers([empireAuthority])
.rpc();
const holding = await program.account.holdingPeriodAccount.fetch(holdingPdaRegCF);
expect(holding.regime).to.deep.equal({ regCf: {} });
expect(holding.holdingPeriodSecs.toNumber()).to.equal(31_536_000);
});
it('Step 6: Transfers tokens to Reg D investor (hook executes)', async () => {
const tx = await transferChecked(
connection, issuerWallet, issuerTokenAccount,
mint, investorRegDTokenAccount, issuerWallet, 50_000_000,
9, [], undefined, TOKEN_2022_PROGRAM_ID,
);
expect(tx).to.be.a('string');
});
it('Step 7: Reg D investor cannot sell during holding period', async () => {
try {
await transferChecked(
connection, investorRegD, investorRegDTokenAccount,
mint, someOtherAccount, investorRegD, 10_000_000,
9, [], undefined, TOKEN_2022_PROGRAM_ID,
);
expect.fail('Should have thrown TokensLocked');
} catch (error) {
expect(error.message).to.include('6024');
}
});
it('Step 8: After Reg D 6-month holding period, investor can sell', async () => {
await advanceClock(15_778_800 + 1);
const tx = await transferChecked(
connection, investorRegD, investorRegDTokenAccount,
mint, someOtherAccount, investorRegD, 10_000_000,
9, [], undefined, TOKEN_2022_PROGRAM_ID,
);
expect(tx).to.be.a('string');
});
it('Step 9: Wallet limit enforced (4.99%) on Module 1', async () => {
const fivePercent = 50_000_000;
try {
await transferChecked(
connection, issuerWallet, issuerTokenAccount,
mint, freshWalletAccount, issuerWallet, fivePercent,
9, [], undefined, TOKEN_2022_PROGRAM_ID,
);
expect.fail('Should have thrown WalletLimitExceeded');
} catch (error) {
expect(error.message).to.include('6020');
}
});
it('Step 10: Custody discrepancy halts all transfers', async () => {
await updateCustodyOracle(mint, {
custodiedBalance: 999_999_999,
tokenSupply: 1_000_000_000,
});
try {
await transferChecked(
connection, issuerWallet, issuerTokenAccount,
mint, investorRegDTokenAccount, issuerWallet, 1,
9, [], undefined, TOKEN_2022_PROGRAM_ID,
);
expect.fail('Should have thrown CustodyDiscrepancy');
} catch (error) {
expect(error.message).to.include('6001');
}
});
});
```
#### 4.3 Module 2 — Real Estate Lifecycle Test
```typescript
// tests/e2e/full-lifecycle-module2.ts
describe('ST22 Full Lifecycle — Module 2 Real Estate', () => {
let mint: PublicKey;
let saeIssuer: Keypair; // Single-Asset Entity holding underlying property
let appraiser: Keypair; // Authorized licensed appraiser
it('Initializes Module 2 SecurityConfig with NAV bounds', async () => {
await program.methods
.initializeSecurityConfig({
module: { realEstate: {} },
maxWalletPercent: 999, // Up to 9.99% for M2
circuitBreakerThreshold: 3000,
circuitBreakerCooldown: new BN(86400),
priceImpactMaxBps: 200,
twapWindowSecs: 1800,
holdingPeriodEnabled: true,
navDeviationMaxBps: 2200, // 22% default
navReappraisalMaxAgeSecs: new BN(7_776_000), // 90 days
navCircuitBreakerEnabled: true,
})
.accounts({ mint, authority: saeIssuer.publicKey })
.signers([saeIssuer])
.rpc();
});
it('Initializes NAVOracle with first appraisal', async () => {
await oracleProgram.methods
.initializeNavOracle({
appraisedNavUsd: new BN(10_000_000_000), // $10,000 per token
appraiserId: 'APP-2026-001',
appraisalTimestamp: new BN(Date.now() / 1000),
})
.accounts({ mint, appraiserAuthority: appraiser.publicKey })
.signers([appraiser])
.rpc();
});
it('Allows trade within NAV deviation tolerance', async () => {
// Pool price equivalent to NAV ± 5% — within 22% tolerance
const tx = await executeSwap(mint, /* small */ 1_000_000, 'buy');
expect(tx).to.be.a('string');
});
it('Pauses mint when NAV deviation exceeds tolerance', async () => {
// Force pool price 25% above NAV
await forcePoolPrice(mint, /* +25% */);
try {
await executeSwap(mint, 1_000_000, 'buy');
expect.fail('Should have thrown PriceImpactExceeded (NAV variant)');
} catch (error) {
expect(error.message).to.include('6021');
}
});
it('Pauses mint when NAV oracle is stale', async () => {
await advanceClock(7_776_001); // 90 days + 1 second
try {
await executeSwap(mint, 1_000_000, 'buy');
expect.fail('Should have thrown PriceImpactExceeded (NAV stale)');
} catch (error) {
expect(error.message).to.include('6021');
}
});
it('Resumes trading after fresh appraisal', async () => {
await oracleProgram.methods
.updateNavOracle({
appraisedNavUsd: new BN(11_000_000_000),
appraiserId: 'APP-2026-001',
appraisalTimestamp: new BN(Date.now() / 1000),
})
.accounts({ mint, appraiserAuthority: appraiser.publicKey })
.signers([appraiser])
.rpc();
// Trading resumes
const tx = await executeSwap(mint, 1_000_000, 'buy');
expect(tx).to.be.a('string');
});
});
```
#### 4.4 Module 3 — CORECM Federal-Action Lifecycle Test
```typescript
// tests/e2e/full-lifecycle-module3.ts
describe('ST22 Full Lifecycle — Module 3 CORECM', () => {
let mint: PublicKey;
let baeIssuer: Keypair; // Basin-Asset Entity
let classificationRelay: Keypair; // Authorized Classification relay
it('Initializes Module 3 SecurityConfig with classification bounds', async () => {
await program.methods
.initializeSecurityConfig({
module: { corecm: {} },
maxWalletPercent: 499,
circuitBreakerThreshold: 3000,
circuitBreakerCooldown: new BN(86400),
priceImpactMaxBps: 200,
twapWindowSecs: 1800,
holdingPeriodEnabled: true,
classificationMaxAgeSecs: new BN(86_400), // 24h
federalActionFreezeEnabled: true,
})
.accounts({ mint, authority: baeIssuer.publicKey })
.signers([baeIssuer])
.rpc();
});
it('Initializes ClassificationOracle with USGS / DOE status', async () => {
await oracleProgram.methods
.initializeClassificationOracle({
usgsCriticalStatus: 'critical_mineral_rare_earth',
doeMaterialsStatus: 'high_priority',
section232Applicable: false,
dpaTitleIIIApplicable: false,
federalActionActive: false,
activeActionRefs: [],
})
.accounts({ mint, classificationRelay: classificationRelay.publicKey })
.signers([classificationRelay])
.rpc();
});
it('Allows trade when no federal action is active', async () => {
const tx = await executeSwap(mint, 1_000_000, 'buy');
expect(tx).to.be.a('string');
});
it('Federal-action detection triggers Control 42 freeze', async () => {
// Inject federal-action event (simulating Federal Register monitoring)
await oracleProgram.methods
.updateClassificationOracle({
federalActionActive: true,
activeActionRefs: ['EO-14118'],
})
.accounts({ mint, classificationRelay: classificationRelay.publicKey })
.signers([classificationRelay])
.rpc();
// Pre-flight rejects the trade with Error 6042 federal-action variant
try {
await executeSwap(mint, 1_000_000, 'buy');
expect.fail('Should have thrown RegulatoryOverride');
} catch (error) {
expect(error.message).to.include('6042');
}
});
it('Other Module 3 mints not subject to the action remain tradeable', async () => {
// Different mint — different basin reference — federal action does not apply
const otherMint = await createModule3Mint();
const tx = await executeSwap(otherMint, 1_000_000, 'buy');
expect(tx).to.be.a('string');
});
it('Trading resumes after federal action lifted', async () => {
await oracleProgram.methods
.updateClassificationOracle({
federalActionActive: false,
activeActionRefs: [],
})
.accounts({ mint, classificationRelay: classificationRelay.publicKey })
.signers([classificationRelay])
.rpc();
const tx = await executeSwap(mint, 1_000_000, 'buy');
expect(tx).to.be.a('string');
});
});
```
#### 4.5 Circuit Breaker Integration Tests (Cross-Module)
```typescript
// tests/e2e/circuit-breaker.ts
describe('Circuit Breaker', () => {
it('blocks trade exceeding 2% price impact (any module)', async () => {
const largeAmount = 31_000_000; // 3.1% of reserve
try {
await executeSwap(mint, largeAmount, 'buy');
expect.fail('Should have thrown PriceImpactExceeded');
} catch (error) {
expect(error.message).to.include('6021');
}
});
it('allows trade within 2% price impact', async () => {
const safeAmount = 19_000_000;
const tx = await executeSwap(mint, safeAmount, 'buy');
expect(tx).to.be.a('string');
});
it('triggers 15-min halt on >10% move in 5 minutes', async () => {
for (let i = 0; i < 5; i++) {
await executeSwap(mint, 20_000_000, 'sell');
}
try {
await executeSwap(mint, 1_000_000, 'sell');
expect.fail('Should have triggered circuit breaker');
} catch (error) {
expect(error.message).to.include('6005');
}
});
it('resumes after 15-minute cooldown', async () => {
await advanceClock(901);
const tx = await executeSwap(mint, 1_000_000, 'buy');
expect(tx).to.be.a('string');
});
});
```
#### 4.6 Key Integration Test Scenarios
| Scenario | File | Controls Tested | Expected Outcome | Module |
| --------------------------------------------- | ------------------------------- | --------------------------- | -------------------------------------------- | ------ |
| Module 1 happy path: full lifecycle | `e2e/full-lifecycle-module1.ts` | All 42 | Mint → transfer → hold → trade | M1 |
| Module 2 happy path: NAV lifecycle | `e2e/full-lifecycle-module2.ts` | All 42 + NAV ext | Mint → NAV init → trade → reappraisal | M2 |
| Module 3 happy path: federal-action lifecycle | `e2e/full-lifecycle-module3.ts` | All 42 + federal-action ext | Mint → classification init → freeze → resume | M3 |
| Custody discrepancy halt | `e2e/full-lifecycle-module1.ts` | CV-01 to CV-06 | Error 6001, all transfers halt | All |
| OFAC sender blocked | `transfer-hook.ts` | SC-30 to SC-32 | Error 6003 | All |
| AML high risk rejected | `transfer-hook.ts` | IV-09 | Error 6006 | All |
| Wallet limit M1 enforced (4.99%) | `transfer-hook.ts` | PL-16 | Error 6020 at 5.00% | M1 |
| Wallet limit M2 enforced (9.99%) | `transfer-hook.ts` | PL-16 | Error 6020 at 10.00% | M2 |
| Price impact blocked | `e2e/circuit-breaker.ts` | CB-21 | Error 6021 at >2% | All |
| Volume halt triggered | `e2e/circuit-breaker.ts` | CB-23 | Error 6037 at >30% daily | All |
| **NAV deviation circuit breaker** | `e2e/full-lifecycle-module2.ts` | **CB-21 NAV variant** | **Error 6021 (NAV)** | **M2** |
| **NAV stale pause** | `e2e/full-lifecycle-module2.ts` | **CB-21 NAV stale** | **Error 6021 (stale)** | **M2** |
| **Federal-action freeze** | `e2e/full-lifecycle-module3.ts` | **REG-42 federal variant** | **Error 6042 (federal)** | **M3** |
| Holding period: Reg D locked | `transfer-hook.ts` | HP-24 | Error 6024 within 6 months | All |
| Holding period: Reg D unlocked | `transfer-hook.ts` | HP-24 | Success after 6 months | All |
| Holding period: Reg S 12mo | `transfer-hook.ts` | HP-24 | Error 6024 within 12 months | All |
| Holding period: Reg CF 12mo | `transfer-hook.ts` | HP-24 | Error 6024 within 12 months | All |
| Regulatory freeze (cross-module) | `governance.ts` | REG-42 | Error 6042, transfers halt | All |
| Fee distribution accuracy | `amm.ts` | — | 5% total, 0.44% to Global Pool | All |
| LP burn verification | `liquidity-pool.ts` | — | LP supply = 0, no withdrawal possible | All |
| Global Pool only grows | `liquidity-pool.ts` | — | Balance increases with every trade | All |
| Governance timelock | `governance.ts` | RK-41 | Proposal blocked before 48h | All |
***
### 5. Fuzz Testing
#### 5.1 Setup
```bash
cd programs/transfer-hook
cargo fuzz init # First time only
```
#### 5.2 Transfer Hook Fuzz Target
```rust
// fuzz/fuzz_targets/transfer_hook_fuzz.rs
#![no_main]
use libfuzzer_sys::fuzz_target;
use transfer_hook::utils::validation::*;
use transfer_hook::state::*;
fuzz_target!(|data: &[u8]| {
if data.len() < 32 { return; }
let amount = u64::from_le_bytes(data[ 0.. 8].try_into().unwrap_or([0; 8]));
let balance = u64::from_le_bytes(data[ 8..16].try_into().unwrap_or([0; 8]));
let supply = u64::from_le_bytes(data[16..24].try_into().unwrap_or([0; 8]));
let max_pct = u16::from_le_bytes(data[24..26].try_into().unwrap_or([0; 2]));
// Must not panic — should return Ok or Err
let _ = check_wallet_limit(balance, amount, supply, max_pct);
});
```
#### 5.3 CPMM Arithmetic Fuzz Target
```rust
// fuzz/fuzz_targets/cpmm_fuzz.rs
#![no_main]
use libfuzzer_sys::fuzz_target;
use amm::utils::math::*;
fuzz_target!(|data: &[u8]| {
if data.len() < 26 { return; }
let input = u64::from_le_bytes(data[ 0.. 8].try_into().unwrap_or([0; 8]));
let reserve_in = u64::from_le_bytes(data[ 8..16].try_into().unwrap_or([0; 8]));
let reserve_out = u64::from_le_bytes(data[16..24].try_into().unwrap_or([0; 8]));
let fee_bps = u16::from_le_bytes(data[24..26].try_into().unwrap_or([0; 2]));
let result = calculate_output_amount(input, reserve_in, reserve_out, fee_bps);
if let Ok(r) = result {
// Invariant: output < reserve_out
assert!(r.output_amount < reserve_out || reserve_out == 0);
// Invariant: fee ≤ input
assert!(r.fee_amount <= input);
// Invariant: k only grows
if reserve_in > 0 && reserve_out > 0 && input > 0 {
let k_before = reserve_in as u128 * reserve_out as u128;
let new_in = reserve_in as u128 + input as u128 - r.fee_amount as u128;
let new_out = reserve_out as u128 - r.output_amount as u128;
let k_after = new_in * new_out;
assert!(k_after >= k_before);
}
}
});
```
#### 5.4 NAV Deviation Fuzz Target (Module 2)
```rust
// fuzz/fuzz_targets/nav_deviation_fuzz.rs
#![no_main]
use libfuzzer_sys::fuzz_target;
use transfer_hook::utils::nav::*;
fuzz_target!(|data: &[u8]| {
if data.len() < 34 { return; }
let on_chain_price = u128::from_le_bytes(data[ 0..16].try_into().unwrap_or([0; 16]));
let appraised_nav = u128::from_le_bytes(data[16..32].try_into().unwrap_or([0; 16]));
let max_dev_bps = u16::from_le_bytes (data[32..34].try_into().unwrap_or([0; 2]));
// Must not panic for any input combination
let _ = compute_nav_deviation_bps(on_chain_price, appraised_nav, max_dev_bps);
});
```
#### 5.5 Classification Oracle Fuzz Target (Module 3)
```rust
// fuzz/fuzz_targets/classification_fuzz.rs
#![no_main]
use libfuzzer_sys::fuzz_target;
use oracle_aggregator::classification::*;
fuzz_target!(|data: &[u8]| {
if data.len() < 17 { return; }
let last_refresh_ts = i64::from_le_bytes(data[0.. 8].try_into().unwrap_or([0; 8]));
let now = i64::from_le_bytes(data[8..16].try_into().unwrap_or([0; 8]));
let federal_active = data[16] & 1 == 1;
// Must not panic; freshness check must always return Ok or flagged Ok
let _ = check_classification_freshness(last_refresh_ts, now, federal_active);
});
```
#### 5.6 Running Fuzz Tests
```bash
# Transfer Hook fuzz — 100,000 runs
cd programs/transfer-hook
cargo fuzz run transfer_hook_fuzz -- -max_len=1024 -runs=100000
# CPMM fuzz — 100,000 runs
cd programs/amm
cargo fuzz run cpmm_fuzz -- -max_len=512 -runs=100000
# Module 2 — NAV deviation fuzz
cd programs/transfer-hook
cargo fuzz run nav_deviation_fuzz -- -max_len=1024 -runs=100000
# Module 3 — Classification fuzz
cd programs/oracle-aggregator
cargo fuzz run classification_fuzz -- -max_len=1024 -runs=100000
# Extended fuzz (pre-release) — 1,000,000 runs
cargo fuzz run transfer_hook_fuzz -- -max_len=1024 -runs=1000000
# Reproduce a crash
cargo fuzz run transfer_hook_fuzz artifacts/transfer_hook_fuzz/crash-abc123
```
#### 5.7 Fuzz Coverage Targets
| Target | Input Space | Runs (Weekly) | Runs (Pre-Release) | Module Scope |
| -------------------------------- | ----------------------- | ------------- | ------------------ | ---------------------------- |
| `check_wallet_limit` | u64 × 3 + u16 | 100,000 | 1,000,000 | All |
| `calculate_output_amount` | u64 × 3 + u16 | 100,000 | 1,000,000 | All |
| `enforce_holding_period` | i64 × 3 + bool + regime | 100,000 | 1,000,000 | All (Reg D / Reg S / Reg CF) |
| `verify_custody_oracle` | u64 × 4 + bool × 2 | 50,000 | 500,000 | All |
| `check_price_impact` | u64 × 3 + u16 | 50,000 | 500,000 | All |
| `compute_nav_deviation_bps` | u128 × 2 + u16 | 50,000 | 500,000 | **Module 2** |
| `check_classification_freshness` | i64 × 2 + bool | 50,000 | 500,000 | **Module 3** |
***
### 6. Formal Verification (Certora)
#### 6.1 Six Invariants
| ID | Property | Spec File | Program | Module Coverage |
| --- | --------------------------- | ------------------------------ | --------------- | -------------------------------------------------------------------- |
| E.1 | No unauthorized minting | `no_unauthorized_minting.spec` | transfer\_hook | All modules |
| E.2 | Custody ratio maintained | `custody_ratio.spec` | transfer\_hook | All modules |
| E.3 | Global Pool non-extractable | `pool_non_extractability.spec` | liquidity\_pool | All modules — single shared pool |
| E.4 | Transfer Hook completeness | `hook_completeness.spec` | transfer\_hook | **All modules — verifies module-aware extensions cannot be removed** |
| E.5 | Fee accuracy (≤ 1 lamport) | `fee_accuracy.spec` | amm | All modules |
| E.6 | Circuit breaker correctness | `circuit_breaker.spec` | transfer\_hook | All modules; covers Module 2 NAV-deviation variant |
E.4 covers the module-aware extensions explicitly — any program upgrade that would remove the Module 2 NAV-deviation enforcement or the Module 3 federal-action freeze coordination fails E.4 verification. There are no separate per-module invariants.
#### 6.2 Running Certora
```bash
# All specs
cd specs
for spec in *.spec; do
echo "Running: $spec"
certoraRun "$spec" --solana
echo "Result: $?"
done
# Individual spec
certoraRun no_unauthorized_minting.spec --solana
certoraRun pool_non_extractability.spec --solana
certoraRun hook_completeness.spec --solana
```
#### 6.3 Verification Requirement
All 6 invariants must PASS before any deployment (devnet or mainnet). A FAIL on any invariant is a release blocker — no exceptions. This applies regardless of whether the deployment includes only Module 1 mints, only Module 2 mints, only Module 3 mints, or any combination — the same six invariants protect every module.
***
### 7. Load Testing
#### 7.1 Target
600 TPS sustained with full 42-control Transfer Hook verification on every transaction. The target applies to combined load across modules; module-specific load tests verify each module independently.
#### 7.2 Load Generator
```bash
# Cross-module sustained load
npx ts-node scripts/load-test.ts \
--rpc http://localhost:8899 \
--target-tps 600 \
--duration-secs 900 \
--module-mix "M1:60,M2:25,M3:15"
# Module 2 only — NAV updates concurrent with trading
npx ts-node scripts/load-test-module-2.ts \
--rpc http://localhost:8899 \
--target-tps 200 \
--nav-updates "every:60"
# Module 3 only — federal-action storm scenario
npx ts-node scripts/load-test-module-3.ts \
--rpc http://localhost:8899 \
--target-tps 100 \
--federal-action-injections 5
```
#### 7.3 Metrics Collected
| Metric | Target | Alert | Module Scope |
| ---------------------------------------- | --------- | ----------- | -------------------- |
| Sustained TPS | ≥ 600 | < 500 | All modules combined |
| p50 latency | < 500 ms | > 800 ms | All |
| p99 latency | < 2000 ms | > 5000 ms | All |
| Error rate | < 0.1% | > 1% | All |
| CU per swap (M1) | < 800,000 | > 1,000,000 | M1 |
| CU per swap (M2) | < 820,000 | > 1,000,000 | M2 |
| CU per swap (M3) | < 830,000 | > 1,000,000 | M3 |
| Custody oracle update latency | < 200 ms | > 500 ms | All |
| NAV oracle update latency | < 1 s | > 5 s | M2 |
| Classification oracle federal-action SLA | < 60 min | > 60 min | M3 |
***
### 8. Chaos Testing
#### 8.1 Failure Injection Scenarios
| Test | Injection Method | Expected Behavior | Module Scope |
| ----------------------------- | ------------------------------------- | ------------------------------------------------ | ------------ |
| Kill custody relay | `pm2 stop custody-relay` | Transfers halt after 1 slot. Error 6002. | All |
| Empire API 500 | Mock error response | Relay retries 3x, then stale. Halt. | All |
| Inject custody discrepancy | Write `custodied_balance ≠ supply` | Error 6001. P0 alert. | All |
| Kill OFAC indexer | `pm2 stop ofac-indexer` | Cache <24h. Halt >48h. | All |
| Both AML providers timeout | Network partition | Cache <6h. New wallets blocked. | All |
| Pyth feed stale | Mock stale data | Breaker disabled >5 min. P2. | All |
| RPC primary down | Block Helius endpoint | Failover to Triton. P2. | All |
| **Kill NAV relay** | `pm2 stop nav-relay` | Affected M2 mints pause when staleness exceeded | **M2** |
| **NAV deviation injection** | Inject NAV value triggering deviation | Affected mint paused. Error 6021. P1. | **M2** |
| **Kill Classification relay** | `pm2 stop classification-relay` | M3 mints enter enhanced review on staleness. P2. | **M3** |
| **Federal-action injection** | Inject federal-action event | P0 incident. Control 42 freeze within 60 min. | **M3** |
#### 8.2 Running Chaos Tests
```bash
./scripts/chaos/run-all.sh # All scenarios
./scripts/chaos/kill-custody-relay.sh # Cross-module
./scripts/chaos/kill-nav-relay.sh # Module 2
./scripts/chaos/inject-nav-deviation.sh # Module 2
./scripts/chaos/kill-classification-relay.sh # Module 3
./scripts/chaos/inject-federal-action.sh # Module 3
./scripts/chaos/verify-recovery.sh # Confirm recovery
```
***
### 9. Test Fixtures and Data
#### 9.1 Standard Test Accounts
```typescript
// tests/fixtures/accounts.ts
export const TEST_FIXTURES = {
// Module 1 — Equities
m1Mint: Keypair.generate(),
m1Issuer: Keypair.generate(),
// Module 2 — Real Estate (Single-Asset Entity)
m2Mint: Keypair.generate(),
m2SaeIssuer: Keypair.generate(),
m2Appraiser: Keypair.generate(),
// Module 3 — CORECM (Basin-Asset Entity)
m3Mint: Keypair.generate(),
m3BaeIssuer: Keypair.generate(),
m3ClassificationRelay: Keypair.generate(),
// Cross-module investor wallets
investorRegD: Keypair.generate(),
investorRegS: Keypair.generate(),
investorRegCF: Keypair.generate(),
sanctionedWallet: Keypair.generate(),
highRiskWallet: Keypair.generate(),
// Oracle keys
empireKeypair: Keypair.generate(),
custodyRelayKeypair: Keypair.generate(),
// Pool defaults
initialSol: 100_000_000_000, // 100 SOL
initialTokens: 1_000_000_000_000, // 1M tokens (9 decimals)
totalSupply: 1_000_000_000_000_000, // 1B tokens
};
```
#### 9.2 SecurityConfig Fixtures (Per Module)
```typescript
export const DEFAULT_M1_CONFIG = {
module: { equities: {} },
maxWalletPercent: 499, // 4.99%
circuitBreakerThreshold: 3000, // 30%
circuitBreakerCooldown: 86400, // 24h
priceImpactMaxBps: 200, // 2%
twapWindowSecs: 1800, // 30 min
holdingPeriodEnabled: true,
};
export const DEFAULT_M2_CONFIG = {
module: { realEstate: {} },
maxWalletPercent: 999, // 9.99% — M2 may use higher cap
circuitBreakerThreshold: 3000,
circuitBreakerCooldown: 86400,
priceImpactMaxBps: 200,
twapWindowSecs: 1800,
holdingPeriodEnabled: true,
navDeviationMaxBps: 2200, // 22% default
navReappraisalMaxAgeSecs: 7_776_000, // 90 days
navCircuitBreakerEnabled: true,
};
export const DEFAULT_M3_CONFIG = {
module: { corecm: {} },
maxWalletPercent: 499,
circuitBreakerThreshold: 3000,
circuitBreakerCooldown: 86400,
priceImpactMaxBps: 200,
twapWindowSecs: 1800,
holdingPeriodEnabled: true,
classificationMaxAgeSecs: 86_400, // 24h
federalActionFreezeEnabled: true,
};
```
***
### 10. Coverage Requirements
#### 10.1 Generating Coverage
```bash
cargo tarpaulin --workspace --out Html --output-dir coverage/
open coverage/tarpaulin-report.html
```
#### 10.2 Minimum Coverage
| Module | Target | Blocker? |
| ------------------------------------------------------------------- | -------- | --------------------- |
| Transfer Hook control logic (all 42) | **100%** | Yes — release blocker |
| Module 2 NAV-deviation extension | **100%** | Yes — release blocker |
| Module 3 federal-action freeze extension | **100%** | Yes — release blocker |
| CPMM arithmetic | **100%** | Yes — release blocker |
| Error code paths | **100%** | Yes — release blocker |
| Cross-module oracle verification | **95%+** | Yes — release blocker |
| Module 2 NAV oracle verification | **95%+** | Yes — release blocker |
| Module 3 Classification oracle verification | **95%+** | Yes — release blocker |
| Governance proposal logic (incl. module-specific param adjustments) | **90%+** | No |
| SDK TypeScript | **80%+** | No |
***
### 11. CI/CD Pipeline
#### 11.1 GitHub Actions Workflow
```yaml
# .github/workflows/test.yml
name: RWA Tokens Tests
on: [push, pull_request]
jobs:
unit-tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: dtolnay/rust-toolchain@stable
- run: cargo test --workspace
- run: cargo tarpaulin --workspace --fail-under 95
integration-tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: dtolnay/rust-toolchain@stable
- uses: coral-xyz/anchor-action@v0.30
- run: anchor build
- run: anchor test
# Module-specific E2E suites — must all pass
- run: anchor test -- --grep "Module 1"
- run: anchor test -- --grep "Module 2"
- run: anchor test -- --grep "Module 3"
fuzz-tests:
runs-on: ubuntu-latest
if: github.event_name == 'push' && github.ref == 'refs/heads/main'
steps:
- uses: actions/checkout@v4
- uses: dtolnay/rust-toolchain@nightly
- run: cargo install cargo-fuzz
- run: |
cd programs/transfer-hook
cargo fuzz run transfer_hook_fuzz -- -runs=100000
cargo fuzz run nav_deviation_fuzz -- -runs=100000
cd ../amm
cargo fuzz run cpmm_fuzz -- -runs=100000
cd ../oracle-aggregator
cargo fuzz run classification_fuzz -- -runs=100000
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: dtolnay/rust-toolchain@stable
with: { components: clippy, rustfmt }
- run: cargo fmt --all -- --check
- run: cargo clippy --workspace -- -D warnings
```
#### 11.2 PR Merge Gates
| Gate | Required | Blocking? |
| ------------------------------------------ | ------------ | --------------- |
| Unit tests pass | Yes | Yes |
| Integration tests pass — all three modules | Yes | Yes |
| Coverage ≥ 95% | Yes | Yes |
| `cargo fmt` clean | Yes | Yes |
| `cargo clippy` zero warnings | Yes | Yes |
| Code review (1+ approver) | Yes | Yes |
| Fuzz tests (main branch only) | Main only | Yes for release |
| Certora (pre-release only) | Release only | Yes for release |
***
### 12. Pre-Deployment Checklist
```
UNIT TESTS
[ ] cargo test --workspace — ALL PASS
[ ] cargo tarpaulin — coverage ≥ 95%
[ ] cargo clippy — zero warnings
[ ] cargo fmt — clean
[ ] Module 2 NAV-deviation tests — ALL PASS
[ ] Module 3 federal-action tests — ALL PASS
[ ] Reg D / Reg S / Reg CF holding-period tests — ALL PASS
INTEGRATION TESTS
[ ] anchor test — ALL PASS
[ ] Module 1 full lifecycle E2E — PASS
[ ] Module 2 full lifecycle E2E (NAV) — PASS
[ ] Module 3 full lifecycle E2E (federal-action) — PASS
[ ] Circuit breaker E2E — PASS
[ ] All 42 controls individually tested — PASS
[ ] Module-aware extensions individually tested — PASS
FUZZ TESTS
[ ] transfer_hook_fuzz — 100,000+ runs, zero crashes
[ ] cpmm_fuzz — 100,000+ runs, zero crashes
[ ] nav_deviation_fuzz (M2) — 100,000+ runs, zero crashes
[ ] classification_fuzz (M3) — 100,000+ runs, zero crashes
FORMAL VERIFICATION
[ ] E.1 No unauthorized minting — PASS
[ ] E.2 Custody ratio — PASS
[ ] E.3 Pool non-extractability — PASS
[ ] E.4 Hook completeness (incl. module-aware extensions) — PASS
[ ] E.5 Fee accuracy — PASS
[ ] E.6 Circuit breaker (incl. NAV variant) — PASS
LOAD TEST
[ ] 600 TPS sustained 15 min — PASS (mixed module load)
[ ] p99 latency < 2000ms — PASS
[ ] Error rate < 0.1% — PASS
[ ] M2 NAV update concurrent load — PASS
[ ] M3 federal-action storm scenario — PASS
CHAOS TEST
[ ] Custody relay failure — fail-safe works
[ ] OFAC indexer failure — cache fallback works
[ ] AML provider failure — cache fallback works
[ ] RPC failover — automatic
[ ] M2 NAV relay failure — affected mint pauses
[ ] M2 NAV deviation injection — affected mint paused
[ ] M3 Classification relay failure — enhanced review activates
[ ] M3 Federal-action injection — Control 42 freeze within 60 min
BUILD
[ ] Build hash matches audited source
[ ] IDL matches program (incl. module-aware fields)
```
***
### 13. Troubleshooting
| Issue | Cause | Fix |
| ------------------------------------------------- | --------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| `anchor test` timeout | Validator slow to start | Increase `startup_wait` in Anchor.toml |
| `cargo test` linker errors | Missing system deps | `sudo apt install libudev-dev pkg-config libssl-dev` |
| Fuzz target won't compile | Nightly required | `rustup default nightly` for fuzz directory |
| Coverage below threshold | Untested error paths | Add explicit error-path unit tests |
| Integration test: `AccountNotFound` | PDAs not initialized | Check test setup initializes all required accounts including module-specific PDAs (NAVOracle for M2, ClassificationOracle for M3) |
| Module 2 test: NAV deviation not triggering | Pool price helper not reaching threshold | Use `forcePoolPrice` helper to set deterministic deviation |
| Module 3 test: federal-action freeze not applying | Classification oracle not initialized before federal-action injection | Initialize `ClassificationOracle` with `federalActionFreezeEnabled: true` before injecting |
| Reg CF test: jurisdiction not recognized | Older Anchor IDL cached | `anchor build` to regenerate IDL with `Jurisdiction::RegCF` variant |
| Load test: `TransactionExpired` | Localnet too slow | Use devnet for load tests, or increase validator slots |
***
### Related Documentation
* **Smart Contract Reference** — Program instructions, error codes, module-aware program behavior.
* **Deployment Guide** — Pre-deployment checklist references this guide; module-specific oracle initialization.
* **Security Model** — Formal verification invariants; module-specific threat surfaces.
* **Oracle Integration Guide** — Custody, OFAC, AML, TWAP, EDGAR (M1), NAV (M2), Classification (M3) relay architecture and chaos test scenarios.
* **Transfer Hook Reference** — Standalone reference for the 42 controls including module-aware extensions.
* **Incident Response Playbook** — P0 through P3 runbooks; Module 3 federal-action freeze runbook.
***
*RWA Tokens · Testing Guide · Groovy Company, Inc.*
# Contributing
## Contributing to RWA Tokens
**Code Standards · PR Process · Security-Critical Rules · Documentation Requirements · Module-Aware**
Thank you for your interest in contributing to the RWA Tokens platform — operated by Groovy Company, Inc. This document defines the standards, processes, and requirements for contributing to a securities-grade infrastructure codebase. The platform serves all three production modules — Equities (Module 1), Real Estate (Module 2), and CORECM — Carbon Ore, Rare Earth, and Critical Minerals (Module 3) — and the 42 immutable Transfer Hook controls (plus module-aware extensions for Module 2 NAV-deviation enforcement and Module 3 federal-action freeze coordination) protect real investors holding real equity. Every contribution must meet the security bar that responsibility demands.
***
### Table of Contents
1. Code of Conduct
2. Getting Started
3. Development Environment
4. Branch Strategy
5. Commit Standards
6. Pull Request Process
7. Code Style
8. Documentation Requirements
9. Security-Critical Contributions
10. Issue Reporting
11. Review Criteria
12. License
***
### 1. Code of Conduct
The platform follows the [Contributor Covenant v2.1](https://www.contributor-covenant.org/version/2/1/code_of_conduct/). All interactions — issues, PRs, discussions, code review — must be professional, constructive, and respectful. Violations are addressed by maintainers and may result in contribution privileges being revoked.
#### Key Principles
* Technical disagreements are resolved with evidence, not authority.
* Code review feedback is about the code, not the person.
* Every contributor's time is valuable — respond to review comments within 48 hours or indicate you need more time.
* Security vulnerabilities are reported privately (see §9), never in public issues.
***
### 2. Getting Started
#### 2.1 Contribution Types
| Type | Examples | Review Required | Security Review? |
| ------------------------------------------- | ---------------------------------------------------------------------- | ----------------------------- | ---------------------------------------------------------------- |
| **Bug fix** | Error handling, edge case, UI issue | 1 maintainer | If touches L2 controls (cross-module or module-aware extensions) |
| **Feature** | New endpoint, SDK method, monitoring | 1 maintainer + CTO | If touches L2 / L4 / L6 |
| **Transfer Hook change** | Any change to 42 controls | CTO + 2 maintainers + Certora | **Always** |
| **Module 2 NAV-deviation extension change** | Any change to CB-21 NAV variant or NAV oracle handling | CTO + 2 maintainers + Certora | **Always** |
| **Module 3 federal-action freeze change** | Any change to REG-42 federal variant or Classification oracle handling | CTO + 2 maintainers + Certora | **Always** |
| **AMM / Pool change** | CPMM logic, fee routing | CTO + 1 maintainer + Certora | **Always** |
| **Documentation** | Wiki, README, code comments | 1 maintainer | No |
| **Test** | New tests, coverage improvement | 1 maintainer | No |
| **Infrastructure** | CI/CD, monitoring, deployment | 1 maintainer + DevOps | No |
#### 2.2 Before You Start
1. **Check existing issues** — your idea may already be tracked.
2. **Open a discussion** — for non-trivial features, open a GitHub Discussion before writing code.
3. **Claim the issue** — comment on the issue to indicate you're working on it.
4. **Read the architecture** — understand which layer and which module(s) your change affects (see Architecture Decisions).
5. **Identify module scope** — determine whether your change is cross-module or specific to Module 1, Module 2, or Module 3.
#### 2.3 First-Time Contributors
Good first issues are labeled `good-first-issue`. These are typically:
* Documentation improvements.
* Test coverage additions (cross-module or module-specific test fixtures).
* Error message clarity.
* SDK convenience methods.
* Monitoring dashboard additions.
These issues never touch Transfer Hook control logic, CPMM arithmetic, or the module-aware control extensions.
***
### 3. Development Environment
#### 3.1 Setup
```bash
# Clone the repository (URL published in Network Configuration)
git clone
cd rwa-tokens
# Install dependencies
yarn install
# Build all programs
anchor build
# Start local validator
solana-test-validator \
--bpf-program TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
target/deploy/spl_token_2022.so \
--reset --quiet
# Run tests
anchor test --skip-local-validator
```
#### 3.2 Required Tools
| Tool | Version | Install |
| ---------- | ------- | -------------------------------------------------------------------- |
| Rust | 1.75+ | `rustup update stable` |
| Solana CLI | 1.18+ | `sh -c "$(curl -sSfL https://release.anza.xyz/stable/install)"` |
| Anchor | 0.30+ | `cargo install --git https://github.com/coral-xyz/anchor anchor-cli` |
| Node.js | 20 LTS | `nvm install 20` |
| Yarn | 4+ | `corepack enable && yarn set version stable` |
#### 3.3 IDE Configuration
**VS Code (recommended):**
```json
// .vscode/settings.json
{
"rust-analyzer.check.command": "clippy",
"rust-analyzer.check.extraArgs": ["--", "-D", "warnings"],
"editor.formatOnSave": true,
"[rust]": { "editor.defaultFormatter": "rust-lang.rust-analyzer" },
"[typescript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" }
}
```
**Recommended extensions:** rust-analyzer, Solana (by Solana Labs), Prettier, ESLint.
***
### 4. Branch Strategy
#### 4.1 Branch Naming
```
/-
Examples:
fix/142-custody-oracle-stale-check
feat/205-sdk-batch-holding-query
feat/210-module-2-nav-deviation-helper
feat/215-module-3-federal-action-monitoring
docs/310-oracle-integration-guide
test/401-circuit-breaker-boundary
test/410-reg-cf-holding-period
chore/500-ci-fuzz-target
```
#### 4.2 Branch Types
| Prefix | Use | Merges To |
| ----------- | ------------------------------ | ------------------------------ |
| `fix/` | Bug fixes | `develop` |
| `feat/` | New features | `develop` |
| `docs/` | Documentation only | `develop` |
| `test/` | Test additions / improvements | `develop` |
| `chore/` | CI / CD, tooling, dependencies | `develop` |
| `security/` | Security-critical fixes | `develop` (expedited review) |
| `release/` | Release preparation | `main` (maintainers only) |
| `hotfix/` | Production emergency fix | `main` (CTO approval required) |
#### 4.3 Protected Branches
| Branch | Protection | Who Can Merge |
| ----------- | ------------------------------------------------ | ---------------- |
| `main` | Requires 2 approvals + CI pass + CTO sign-off | Maintainers only |
| `develop` | Requires 1 approval + CI pass | Maintainers |
| `release/*` | Requires 2 approvals + full test suite + Certora | CTO |
***
### 5. Commit Standards
#### 5.1 Commit Message Format
```
():
[optional body]
[optional footer]
```
#### 5.2 Types
| Type | Description | Example |
| ---------- | ------------------------------------- | ----------------------------------------------------------- |
| `fix` | Bug fix | `fix(hook): correct wallet limit boundary at exactly 4.99%` |
| `feat` | New feature | `feat(sdk): add batch holding period query` |
| `docs` | Documentation | `docs(wiki): add oracle integration guide` |
| `test` | Test addition / fix | `test(amm): add u128 overflow fuzz target` |
| `refactor` | Code restructure (no behavior change) | `refactor(hook): extract control validation into module` |
| `perf` | Performance improvement | `perf(amm): reduce CU by caching oracle read` |
| `chore` | Tooling, CI, dependencies | `chore(ci): add cargo-tarpaulin coverage gate` |
| `security` | Security-related change | `security(hook): fix stale attestation edge case` |
#### 5.3 Scopes
| Scope | Programs / Areas | Module Scope |
| ---------------- | ------------------------------------------------ | ------------ |
| `hook` | `transfer_hook` — 42 controls | All modules |
| `amm` | `amm` — CPMM engine | All modules |
| `pool` | `liquidity_pool` — Global Pool | All modules |
| `gov` | `governance` | All modules |
| `oracle` | `oracle_aggregator` (cross-module oracles) | All modules |
| `nav` | NAV oracle and CB-21 NAV variant | **Module 2** |
| `classification` | Classification oracle and REG-42 federal variant | **Module 3** |
| `sdk` | `@rwatokens/sdk` | All modules |
| `api` | CEDEX REST / WebSocket API | All modules |
| `ci` | GitHub Actions, CI / CD | All modules |
| `docs` | Documentation, wiki | All modules |
| `infra` | Kubernetes, monitoring, RPC | All modules |
#### 5.4 Rules
* Subject line: imperative mood, ≤72 characters, no period.
* Body: explain *what* and *why*, not *how* (the code explains how).
* Reference issue: `Closes #142` or `Refs #205`.
* Security commits: include `SECURITY:` prefix in body if applicable.
```
fix(hook): correct holding period boundary check
The boundary check used `>` instead of `>=` for the holding period
comparison, allowing transfers exactly at the threshold to incorrectly
fail.
Reg D (6 months), Reg S (12 months), and Reg CF (12 months) should
pass when elapsed time equals holding_period_secs, not only when it
exceeds it.
SECURITY: This affects Control HP-24 behavior at exact boundaries
across all three regimes and applies uniformly to Module 1, Module 2,
and Module 3 mints.
Closes #142
```
***
### 6. Pull Request Process
#### 6.1 PR Template
Every PR must use the repository's PR template:
```markdown
## Description
## Type
## Layer Impact
- [ ] Layer 1 (Solana Foundation)
- [ ] Layer 2 (Transfer Hook — 42 controls)
- [ ] Layer 3 (Liquidity Pool)
- [ ] Layer 4 (AMM)
- [ ] Layer 5 (CEDEX)
- [ ] Layer 6 (Oracle Network)
- [ ] Layer 7 (Governance)
- [ ] Layer 8 (Wallet)
- [ ] Layer 9 (AI / IDOS Module)
- [ ] SDK / API
- [ ] Infrastructure / CI
- [ ] Documentation only
## Module Impact
- [ ] Cross-module (affects all of Module 1, Module 2, and Module 3)
- [ ] Module 1 — Equities
- [ ] Module 2 — Real Estate (touches NAV oracle / NAV-deviation extension?)
- [ ] Module 3 — CORECM (touches Classification oracle / federal-action extension?)
## Security Impact
- [ ] No security impact
- [ ] Security impact — requires security review (describe below)
## Testing
- [ ] Unit tests added / updated
- [ ] Integration tests added / updated (per affected module)
- [ ] Fuzz testing verified (if applicable)
- [ ] Formal verification re-run (if applicable)
## Checklist
- [ ] `cargo fmt --all` — clean
- [ ] `cargo clippy --workspace` — zero warnings
- [ ] `cargo test --workspace` — all pass
- [ ] `anchor test` — all pass (if applicable)
- [ ] Module-specific integration tests pass (Module 1 / 2 / 3 as applicable)
- [ ] Documentation updated (if applicable)
- [ ] Changelog entry added (if user-facing change)
```
#### 6.2 Review Process
```
CONTRIBUTOR REVIEWERS MERGE
│ │ │
├─ Open PR ──────────────────► │ │
│ │ │
│ ◄─── Review comments ───────┤ │
│ │ │
├─ Address feedback ──────────►│ │
│ │ │
│ ◄─── Approval (1+) ────────┤ │
│ │ │
│ CI PASSES ───────────┼─────────────────────────►│
│ │ │
│ │ Maintainer merges
```
#### 6.3 Review SLAs
| PR Type | First Review | Merge (after approval) |
| ----------------- | -------------------- | ---------------------- |
| Documentation | 24 hours | Same day |
| Tests | 24 hours | Same day |
| Bug fix | 48 hours | 24 hours |
| Feature | 72 hours | 48 hours |
| Security-critical | 24 hours (expedited) | CTO approval required |
#### 6.4 What Reviewers Look For
| Area | Criteria |
| ------------- | ---------------------------------------------------------------------------------------------------------------- |
| Correctness | Does the code do what the PR description says? Edge cases handled across all three modules? |
| Security | Any new attack surface? Any weakened controls? Any module-aware extensions weakened? Any key management changes? |
| Tests | Are new code paths tested? Coverage maintained? Boundary conditions? Module-specific scenarios? |
| Performance | CU impact? Latency impact? Memory impact? Module 2 / Module 3 oracle read overhead? |
| Style | Matches project conventions? `cargo fmt` + `cargo clippy` clean? |
| Documentation | Public functions documented? Wiki updated if needed? Module-aware behavior surfaced? |
| Terminology | Correct current terminology? No obsolete terms? (See Terminology section below.) |
***
### 7. Code Style
#### 7.1 Rust
```bash
# Format check (must pass CI)
cargo fmt --all -- --check
# Lint check (must pass CI — zero warnings)
cargo clippy --workspace -- -D warnings
```
**Key conventions:**
```rust
// Use checked arithmetic — never raw operators on financial values
let result = amount.checked_mul(fee_bps as u64)
.ok_or(TransferHookError::ArithmeticOverflow)?;
// Never do this
let result = amount * fee_bps as u64;
// Use descriptive error variants
return Err(TransferHookError::WalletLimitExceeded.into());
// Never use generic errors
return Err(ProgramError::Custom(1));
// Document public functions
/// Verifies the custody oracle attestation is valid and fresh.
///
/// Operates uniformly across Module 1, Module 2, and Module 3 mints —
/// asset class is recorded in the SecurityConfig, not the oracle.
///
/// # Errors
/// - `CustodyDiscrepancy` (6001): token supply exceeds custodied balance
/// - `CustodyOracleUnavailable` (6002): attestation stale (>1 slot)
pub fn verify_custody_oracle(oracle: &CustodyOracle, clock: &Clock) -> Result<()> {
// ...
}
// Use constants, not magic numbers
pub const MAX_WALLET_PERCENT_BPS: u16 = 499; // 4.99% default ceiling
pub const M2_MAX_WALLET_UPPER_BPS: u16 = 999; // 9.99% Module 2 upper bound
pub const REG_D_HOLDING_SECS: i64 = 15_778_800; // Reg D 6 months
pub const REG_S_HOLDING_SECS: i64 = 31_536_000; // Reg S 12 months
pub const REG_CF_HOLDING_SECS: i64 = 31_536_000; // Reg CF 12 months
// Never hardcode values
if wallet_percent > 499 { /* ... */ }
```
**Naming conventions:**
| Item | Convention | Example |
| -------------- | ---------------- | ----------------------------------------------------------------------------------------------------------- |
| Structs | PascalCase | `SecurityConfig`, `HoldingPeriodAccount`, `NAVOracleState`, `ClassificationOracleState` |
| Functions | snake\_case | `verify_custody_oracle`, `check_wallet_limit`, `compute_nav_deviation_bps`, `enforce_federal_action_freeze` |
| Constants | SCREAMING\_SNAKE | `MAX_WALLET_PERCENT_BPS`, `REG_D_HOLDING_SECS`, `REG_S_HOLDING_SECS`, `REG_CF_HOLDING_SECS` |
| Modules | snake\_case | `security_config`, `holding_period`, `nav_oracle`, `classification_oracle` |
| Error variants | PascalCase | `WalletLimitExceeded`, `TokensLocked`, `RegulatoryOverride` |
| PDA seeds | byte literals | `b"security-config"`, `b"holding-period"`, `b"nav-oracle"`, `b"classification-oracle"` |
| Module enum | PascalCase | `ModuleId::Equities`, `ModuleId::RealEstate`, `ModuleId::Corecm` |
| Regime enum | PascalCase | `HoldingRegime::RegD`, `HoldingRegime::RegS`, `HoldingRegime::RegCF` |
#### 7.2 TypeScript
```bash
# Format (must pass CI)
yarn prettier --check "**/*.ts"
# Lint (must pass CI — zero errors)
yarn eslint "**/*.ts"
```
**Key conventions:**
````typescript
// Explicit types on public API boundaries
export async function getSecurityConfig(mint: PublicKey): Promise {
// ...
}
// Use BigInt for token amounts (not number)
const amount: bigint = 50_000_000_000n;
// Never use number for token amounts (precision loss at >2^53)
const amount: number = 50000000000;
// Handle errors with typed catches
try {
await client.cedex.placeOrder(params);
} catch (error) {
if (error instanceof TransferHookError) {
console.log(error.code, error.controlId, error.moduleScope);
}
}
// Document exported functions with JSDoc
/**
* Verifies an ST22 mint has the Transfer Hook permanently attached.
* Works uniformly across Module 1, Module 2, and Module 3 mints.
*
* @param mint - ST22 mint address
* @returns Transfer Hook verification status including all 42 control states
* @throws {RwaTokensError} If the mint does not exist or is not Token-2022
*
* @example
* ```typescript
* const status = await client.hooks.verify(mintAddress);
* console.log(status.controlsActive); // 42
* ```
*/
export async function verify(mint: PublicKey): Promise {
// ...
}
````
#### 7.3 Tests
```rust
// Test names describe the scenario, not the method
#[test]
fn test_wallet_limit_rejects_at_5_percent() { /* ... */ }
// Not descriptive
#[test]
fn test_wallet_limit() { /* ... */ }
// Test the boundary, not just pass/fail
#[test]
fn test_holding_period_passes_at_exact_threshold_reg_d() { /* ... */ }
#[test]
fn test_holding_period_fails_one_second_before_threshold_reg_d() { /* ... */ }
#[test]
fn test_holding_period_passes_at_exact_threshold_reg_cf() { /* ... */ }
// Module-specific test naming
#[test]
fn test_nav_deviation_exceeds_threshold_module_2() { /* ... */ }
#[test]
fn test_federal_action_active_blocks_module_3() { /* ... */ }
// Assert specific error codes
assert_eq!(result.unwrap_err(), TransferHookError::TokensLocked.into());
// Don't just assert failure
assert!(result.is_err());
```
***
### 8. Documentation Requirements
#### 8.1 Code Documentation
Every public function, struct, and module must be documented:
```rust
/// Security configuration for a single ST22 mint.
///
/// One `SecurityConfig` account exists per mint, created at mint initialization.
/// Stores all parameters governing the 42 Transfer Hook controls for the token's
/// entire existence. The same schema serves Module 1, Module 2, and Module 3 —
/// module-specific extension fields (NAV bounds for Module 2; classification
/// bounds and federal-action toggle for Module 3) are populated based on the
/// mint's module.
///
/// PDA: `[b"security-config", mint.key().as_ref()]`
///
/// # Size
/// Base: ~408 bytes + module-specific extension fields + 4 + (32 × blacklist_len)
/// Maximum: 10,240 bytes (Solana account limit)
#[account]
pub struct SecurityConfig {
/// Associated ST22 token mint address
pub mint: Pubkey,
/// Admin authority — 5-of-9 multi-sig
pub authority: Pubkey,
/// Schema version
pub version: u8,
/// Module identifier — drives module-aware behavior
pub module: ModuleId,
// ...
}
```
#### 8.2 When to Update Wiki
| Change Type | Wiki Update Required? | Which Page? |
| -------------------------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------- |
| New SDK method (cross-module or module-specific) | Yes | SDK Reference |
| New error code | Yes | Smart Contract Reference, CEDEX API Reference |
| New instruction | Yes | Smart Contract Reference |
| Parameter change (cross-module or module-specific) | Yes | Smart Contract Reference, Changelog |
| New oracle integration | Yes | Oracle Integration Guide |
| Module 2 NAV-extension change | Yes | Smart Contract Reference, Oracle Integration Guide, Transfer Hook Reference |
| Module 3 federal-action extension change | Yes | Smart Contract Reference, Oracle Integration Guide, Transfer Hook Reference, Incident Response Playbook |
| Deployment procedure change | Yes | Deployment Guide |
| New test pattern | Optional | Testing Guide |
| Internal refactor | No | — |
#### 8.3 Terminology
The platform has legally load-bearing terminology. Using the wrong term in documentation or code comments can create regulatory confusion. The following terms are authoritative.
**Always use**
| Term | Context |
| ---------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| Groovy Company, Inc. | Operating entity (Wyoming domicile; CIK 1499275; OTC: GROO) — no dba |
| RWA Tokens | Platform branding |
| Module 1 — Equities | First production module |
| Module 2 — Real Estate | Second production module |
| Module 3 — CORECM | Third production module — Carbon Ore, Rare Earth, and Critical Minerals |
| Common Class B | Backing instrument for Module 1 (Equities) ST22 tokens |
| Single-asset entity (SAE) equity | Backing instrument for Module 2 (Real Estate) ST22 tokens |
| Basin-asset entity (BAE) equity | Backing instrument for Module 3 (CORECM) ST22 tokens |
| `custodied_balance` / `custodiedBalance` | Custody oracle field — module-agnostic |
| ST22 Digital Securities | Token classification for issuer equity tokens |
| GROO Utility Token | GROO — explicitly NOT a security |
| Groovy Security Token (STO) | Groovy Company, Inc. Common Class B share offering |
| Empire Stock Transfer | Qualified custodian and sole investor onboarding authority |
| CEDEX | Compliant Exchange for Digital Securities |
| cedex.market | Trading venue URL |
| rwatokens.net | Platform URL |
| Legal Counsel | Legal advisory role (generic) |
| OTCID | OTC Markets tier (replaces Pink Current) |
| Transfer Hook | SPL Token-2022 compliance mechanism |
| Reg D | Regulation D — US accredited investors (6-month holding period) |
| Reg S | Regulation S — non-US investors (12-month holding period) |
| Reg CF | Regulation Crowdfunding — US retail (12-month holding period; FINRA-registered funding portal partnership) |
| NAV oracle | Module 2 oracle holding appraised Net Asset Value |
| Classification oracle | Module 3 oracle holding USGS / DOE / federal-action status |
| Federal-action freeze | Module 3 Control 42 variant with 60-minute SLA |
**Never use (obsolete or prohibited)**
| Prohibited Term | Correct Term | Why |
| ---------------------------------------------- | ------------------------------------------ | ---------------------------------------------------------------- |
| OTCM Protocol | RWA Tokens | Platform rebranded May 1, 2026 |
| OTCM Protocol Inc. (as platform entity) | Groovy Company, Inc. | OTCM Protocol Inc. (FL) is a separate entity Frank is evaluating |
| `dba OTCM Protocol` | Groovy Company, Inc. (no dba) | dba was cancelled May 1, 2026 |
| `@otcm-protocol/sdk` | `@rwatokens/sdk` | SDK package renamed |
| `OtcmClient` | `RwaTokensClient` | SDK client class renamed |
| `OtcmError` | `RwaTokensError` | SDK error class renamed |
| `common_b_balance` | `custodied_balance` | Module-agnostic field naming |
| `commonBBalance` | `custodiedBalance` | Module-agnostic field naming |
| Series M / Preferred Series M | Common Class B | SEC Crypto Task Force March 2026 directive |
| Security Meme Token / SMT | ST22 Digital Securities | Terminology obsolete |
| Howey Shield | *(removed entirely)* | Framework obsolete |
| OTCM.VIP / cedex.otcm.io | cedex.market | URL obsolete |
| otcm.io (platform site) | rwatokens.net | URL obsolete |
| Pink Current | OTCID | OTC Markets renamed |
| GROO STO / OTCM STO | GROO Utility Token / Groovy Security Token | GROO is a utility token; the STO is the Groovy Security Token |
| OTCM Security Token | Groovy Security Token (STO) | Renamed alongside platform brand |
| / | | Email domain updated |
| | | Email domain updated |
| | | Email domain updated |
| Jeff Turner / JDT Legal / CLO | Legal Counsel | Attribution retired |
| Berj Abajian / former CEO | *(removed entirely)* | Terminated for Cause effective May 1, 2026 |
| John Morgan | *(removed entirely)* | No longer on team |
| Rule 506(c) / Reg D 506(c) / 506(c) qualifier | Reg D | Standard phrasing is just "Reg D" — never paired with 506(c) |
| "illiquid OTC microcap" / distress framing | Professional capability framing | No distress narratives |
| "trapped shareholders" | Capability-led framing | Lead with infrastructure, not broken markets |
| OTCM Protocol → RWA Tokens transition language | *(no transition language)* | Treat the platform brand as established |
***
### 9. Security-Critical Contributions
#### 9.1 What Is Security-Critical?
Any change that touches:
* Transfer Hook control logic (any of the 42 controls).
* **Module 2 NAV-deviation extension** — CB-21 NAV variant logic, NAV oracle verification, NAV staleness handling.
* **Module 3 federal-action freeze coordination** — REG-42 federal variant logic, Classification oracle verification, federal-action detection and SLA handling.
* CPMM arithmetic (`calculate_output_amount` and related functions).
* Fee routing or distribution.
* Oracle verification (Ed25519, staleness, consensus) — including NAV oracle (Module 2) and Classification oracle (Module 3).
* Key management (multi-sig, upgrade authority, appraiser key registry, Classification relay authority).
* PDA derivation seeds.
* Error code definitions or behavior.
* Account schema changes.
* Holding-period regimes (Reg D, Reg S, Reg CF) and constants.
#### 9.2 Security-Critical PR Requirements
| Requirement | Standard PR | Security-Critical PR |
| ------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| Reviewers | 1 maintainer | CTO + 2 maintainers |
| Unit tests | Required | Required — 100% coverage of changed paths (including module-aware paths) |
| Integration tests | Required | Required — Module 1, Module 2, and Module 3 lifecycle tests must pass as applicable |
| Fuzz testing | Not required | Required — 100,000 runs on affected target (`transfer_hook_fuzz`, `cpmm_fuzz`, `nav_deviation_fuzz`, `classification_fuzz` as applicable) |
| Formal verification | Not required | **Required — all 6 Certora invariants must re-pass; E.4 covers module-aware extensions** |
| Security review | Not required | **Required — documented threat assessment** |
| Changelog | If user-facing | Always |
| Audit impact | N/A | Must document: "Does this change invalidate any existing audit finding from Quantstamp, Halborn, or OtterSec?" |
#### 9.3 Security-Critical PR Template Addition
Security-critical PRs must include this additional section:
```markdown
## Security Assessment
### Threat Analysis
### Control Impact
### Module Scope
### Invariant Impact
### Audit Impact
### Formal Verification
- [ ] All 6 Certora invariants re-verified on the new code
- [ ] Certora output attached to PR
```
#### 9.4 Vulnerability Reporting
**DO NOT** report security vulnerabilities in public GitHub issues.
| Channel | Contact |
| ------------ | ------------------------------------------- |
| Email | |
| Encrypted | PGP key at rwatokens.net/security/pgp |
| Response SLA | Acknowledgment: 24 hours. Triage: 72 hours. |
| Bug bounty | Up to $100,000 for critical vulnerabilities |
See **Security Model — Responsible Disclosure** for full details.
***
### 10. Issue Reporting
#### 10.1 Bug Reports
Use the `Bug Report` issue template:
```markdown
**Describe the bug**
Clear, concise description.
**To Reproduce**
1. Step one
2. Step two
3. Error observed
**Expected behavior**
What should have happened.
**Module Scope**
- Cross-module / Module 1 / Module 2 / Module 3
**Environment**
- OS: [e.g., Ubuntu 24.04]
- Rust: [e.g., 1.75.0]
- Solana CLI: [e.g., 1.18.x]
- Anchor: [e.g., 0.30.x]
- Cluster: [localnet / devnet / mainnet]
**Logs / Error output**
```
#### 10.2 Feature Requests
Use the `Feature Request` issue template. Include:
* Problem statement (what's missing or painful).
* Proposed solution.
* Which layer(s) and which module(s) affected.
* Security implications (if any).
#### 10.3 Labels
| Label | Meaning |
| ------------------ | ---------------------------------------------------------------------------- |
| `good-first-issue` | Suitable for new contributors |
| `bug` | Confirmed bug |
| `feature` | New functionality |
| `security` | Security-sensitive (restricted visibility) |
| `P0-critical` | Production impact — immediate response |
| `P1-high` | Significant but not production-blocking |
| `layer-2` | Affects Transfer Hook |
| `layer-4` | Affects AMM |
| `layer-6` | Affects Oracle Network |
| `module-1` | Affects Module 1 (Equities) |
| `module-2` | Affects Module 2 (Real Estate) — NAV oracle / NAV-deviation extension |
| `module-3` | Affects Module 3 (CORECM) — Classification oracle / federal-action extension |
| `cross-module` | Affects all three modules |
| `sdk` | SDK change |
| `docs` | Documentation |
| `needs-certora` | Requires formal re-verification |
***
### 11. Review Criteria
#### 11.1 Approval Matrix
| Change Scope | Required Approvers | CI Gates |
| ------------------------------ | --------------------- | ------------------------------------------ |
| Documentation only | 1 maintainer | Lint |
| Tests only | 1 maintainer | Unit + integration |
| SDK / API | 1 maintainer | Unit + integration + lint |
| Infrastructure | 1 maintainer + DevOps | Unit + lint |
| Feature (non-security) | 1 maintainer + CTO | Full test suite |
| Bug fix (security) | CTO + 2 maintainers | Full suite + fuzz |
| Transfer Hook change | CTO + 2 maintainers | Full suite + fuzz + Certora |
| Module 2 NAV-extension change | CTO + 2 maintainers | Full suite + fuzz + Certora |
| Module 3 federal-action change | CTO + 2 maintainers | Full suite + fuzz + Certora |
| AMM / Pool change | CTO + 2 maintainers | Full suite + fuzz + Certora |
| Release | CTO + 2 maintainers | Full suite + fuzz + Certora + load + chaos |
#### 11.2 Merge Rules
* **Squash merge** for all PRs to `develop` (clean commit history).
* **Merge commit** for `release/*` → `main` (preserve release structure).
* **Delete branch** after merge (automatic).
* **No force push** on `develop` or `main`.
#### 11.3 Stale PRs
PRs with no activity for 14 days receive a `stale` label and a comment. After 7 more days, they are closed. Re-open by commenting.
***
### 12. License
The platform is released under the **Business Source License 1.1 (BSL 1.1)**.
* Source code is viewable and auditable by anyone.
* Production use requires a commercial license from Groovy Company, Inc.
* After the Change Date (specified in `LICENSE`), the code converts to Apache 2.0.
* Contributions are licensed under the same terms.
By submitting a pull request, you agree that your contribution is licensed under the BSL 1.1 and that you have the right to license the contribution.
***
### Quick Reference
```
SETUP: git clone → yarn install → anchor build → anchor test
BRANCH: fix/142-description or feat/205-description
COMMIT: fix(hook): correct wallet limit boundary at exactly 4.99%
SCOPE: hook | amm | pool | gov | oracle | nav (M2) | classification (M3)
PR: Fill template → CI passes → 1+ approval → squash merge
Tag Module Impact: cross-module / M1 / M2 / M3
STYLE: cargo fmt + cargo clippy (zero warnings) + prettier + eslint
SECURITY: Touches L2 / L4 / L6 / NAV / Classification?
→ CTO + 2 reviewers + Certora
TERMINOLOGY: Common Class B (M1). SAE equity (M2). BAE equity (M3).
GROO Utility Token (not STO). Groovy Security Token (STO).
custodied_balance, not common_b_balance.
Reg D / Reg S / Reg CF — never "506(c)".
REPORT VULN: security@rwatokens.net (NEVER in public issues)
```
***
### Related Documentation
* **Deployment Guide** — Build, deploy, verify procedures (module-specific oracle initialization).
* **Testing Guide** — Test methodology and coverage requirements (module-aware fuzz, integration, chaos).
* **Smart Contract Reference** — Program specifications with module-aware program behavior.
* **Transfer Hook Reference** — Standalone reference for the 42 controls including module-aware extensions.
* **Security Model** — Threat model and vulnerability reporting (module-specific threat surfaces).
* **Architecture Decisions** — ADRs covering cross-module and module-specific decisions.
* **Oracle Integration Guide** — Custody, OFAC, AML, TWAP, EDGAR (M1), NAV (M2), Classification (M3) relay architecture.
* **Governance Deep Dive** — Module-aware governance surface and Control 42 federal-action variant.
***
*RWA Tokens · Contributing Guide · Groovy Company, Inc.*
# Welcome
Welcome to the **RWA Tokens Marketing Wiki** — the central library for everything we publish about the platform to the outside world. Articles, pitch decks, the lightpaper, investor presentations, SEC filings and staff statements we cite, regulatory commentary, and ongoing news coverage all live here, organized so the comms team, partners, and counsel can find the right asset for the right audience without rebuilding it from scratch.
You'll find collateral grouped by the three asset-class modules — **Equities (ST22), Real Estate, and CORECM** — alongside cross-cutting materials that apply to the platform as a whole: corporate-identity assets, SEC regulatory framework references (Release No. 33-11412, the January 28, 2026 Joint Staff Statement, the April 13, 2026 Covered User Interface Providers statement), and the live news and X/LinkedIn campaign archive. Each item is tagged by audience (institutional investor, issuer prospect, regulator, press) and by stage (draft, internal review, legal-cleared, published) so nothing ships externally without the right approval state.
This wiki is the canonical source for any RWA Tokens marketing artifact under the Groovy Company, Inc. brand (the "OTCM Protocol" dba was retired May 1, 2026; CEDEX, ST22, and GROO remain as product and instrument names). Platform URL is [**https://rwatokens.net**](https://rwatokens.net/); trading venue is **cedex.market**. When in doubt about which version of a deck or letter is current, this wiki is the answer — anything found elsewhere should be checked against the version here before sending.
# Glossary
## Glossary
**Authoritative Terminology Reference**
Every platform-specific term, regulatory framework, technical concept, and blockchain primitive used across the documentation suite. Module-aware terminology is annotated with **(M1)**, **(M2)**, or **(M3)** to indicate the production module (Equities, Real Estate, or CORECM) where the term applies. Cross-module terms have no annotation. Obsolete terms are listed in §13 Deprecated Terminology — they must never appear in any current document.
This glossary is the single authoritative source across the documentation suite. When in doubt, check here first.
***
### Table of Contents
1. Platform and Architecture
2. Token Classes
3. Security Controls
4. On-Chain Programs and Accounts
5. Regulatory Framework
6. Compliance and Verification
7. Trading and Liquidity
8. Oracle Network
9. Blockchain and Solana
10. Key Management and Governance
11. Audit and Formal Verification
12. People and Entities
13. Deprecated Terminology
***
### 1. Platform and Architecture
**Groovy Company, Inc.** — Wyoming Corporation, CIK 1499275, OTC: GROO. Principal office 600 W Peachtree St NW, Suite 1700, Atlanta, GA 30308. Wyoming domicile. Operating entity for the RWA Tokens platform. There is no dba.
**RWA Tokens** — The platform brand. The institutional infrastructure operated by Groovy Company, Inc. for tokenizing real-world assets across three production modules — Module 1 (Equities), Module 2 (Real Estate), and Module 3 (CORECM). The platform website is `rwatokens.net`.
**Three-Module Architecture** — The platform's three production modules:
* **Module 1 — Equities.** Tokenization of equity securities from OTC microcap, NASDAQ, AMEX, TSX, and all global exchanges. Backing instrument: Common Class B shares.
* **Module 2 — Real Estate.** Tokenization of real property assets through single-asset entities. Backing instrument: SAE equity. NAV oracle and 22% deviation tolerance enforced at the protocol layer.
* **Module 3 — CORECM.** Carbon Ore, Rare Earth, and Critical Minerals — tokenization of US strategic minerals supply chain. Backing instrument: BAE equity. Classification oracle and federal-action freeze enforced at the protocol layer.
**Nine-Layer Architecture** — The platform's complete technology stack: Layer 1 (Solana Foundation), Layer 2 (Transfer Hook Security Enforcement — 42 controls plus module-aware extensions), Layer 3 (Global Unified CEDEX Liquidity Pool), Layer 4 (Custom AMM Engine — CPMM), Layer 5 (CEDEX Trading Infrastructure), Layer 6 (Oracle Network), Layer 7 (Protocol Governance), Layer 8 (Wallet Infrastructure), Layer 9 (AI / IDOS Module).
**Alesia Doctrine** — The platform's core security philosophy: compliance enforcement at the lowest possible layer of the technology stack, making regulatory bypass structurally impossible rather than merely discouraged. Named for the Roman siege of Alesia — circumvallation (contain the threat) plus contravallation (defend against external relief). In the platform's context: liquidity containment (Global Pool, LP burned) plus bot defense (42 controls, module-aware extensions, Jito MEV protection).
**CEDEX (Compliant Exchange for Digital Securities)** — The platform's purpose-built trading venue at `cedex.market`. Combines centralized order matching (Web2 performance) with decentralized Solana settlement (Web3 finality). The exclusive venue for all ST22 secondary trading — the only exchange that preserves all 42 Transfer Hook controls plus module-aware extensions on every trade. External DEXs (Raydium, Orca, Jupiter, Meteora) disable Transfer Hook functionality.
**Global Unified CEDEX Liquidity Pool** — Single protocol-owned liquidity reserve shared by all ST22 issuers across all three modules. Seeded by the Groovy Security Token (STO) Reg D proceeds via the Solana Treasury and the GROO Staking Pool allocation. Deepened continuously by the 0.44% allocation from every CEDEX trade. LP tokens burned at initialization — liquidity withdrawal is mathematically impossible. Formally verified by Certora Prover invariant E.3.
**Custom AMM Engine** — The platform's proprietary Automated Market Maker operating against the Global Pool using a Constant Product Market Maker (CPMM) formula (x × y = k) with u128 overflow-safe arithmetic. Purpose-built because all major external DEXs disable SPL Token-2022 Transfer Hooks at swap execution. See ADR-002.
**IDOS (Issuer Distress and Opportunity Score)** — Composite score from the Layer 9 AI Module rating tokenization readiness across all three modules. Module-aware inputs:
* **Module 1.** EDGAR filing health, shareholder count, trading history, OTC tier degradation, 8-K trigger events.
* **Module 2.** REIT and county-recorder data, MLS, CMBS performance, NAV-reappraisal opportunity signal (deviation between on-chain price and most recent NAV).
* **Module 3.** USGS Critical Minerals List status, DOE Critical Materials Strategy classification, Federal Register monitoring, federal-action exposure (treated as inverse signal — exposure reduces score).
Used to prioritize the issuer acquisition pipeline. Not a public-facing metric.
***
### 2. Token Classes
The platform has exactly three token classes. They are architecturally and legally distinct.
**ST22 Digital Securities** — Tokens on Solana (SPL Token-2022 with Transfer Hook extension) representing direct beneficial ownership in the underlying issuer's equity, held in irrevocable custody at Empire Stock Transfer. The asset class held in custody varies by module: **Common Class B shares (M1)**, **single-asset entity (SAE) equity (M2)**, or **basin-asset entity (BAE) equity (M3)**. Classified as Category 5 Digital Securities under SEC Release No. 33-11412. Issued under Reg D (US accredited investors), Reg S (non-US investors), and Reg CF (US retail crowdfunding). All 42 Transfer Hook controls plus applicable module-aware extensions enforced on every transfer. Each ST22 token is backed 1:1 by an underlying equity unit with issuer-designated shareholder rights (voting, dividends, liquidation).
**GROO Utility Token** — Ecosystem utility token of Groovy Company, Inc. NOT a security, NOT an STO, NOT backed by shares. GROO provides governance voting rights, staking rewards (1.5% of all CEDEX trading fees), platform feature tiers, and Solana Treasury funding (which seeds the Global Pool). Under SEC Release No. 33-11412, classified as either Category 1 (Digital Commodity) or Category 3 (Digital Tool) — explicitly not a security. Distribution via deterministic linear bonding curve (starting at 0.000001 SOL). No pre-sale. No founder allocation. No treasury reserve. No ICO until Scale phase Dutch auction (governance-decided).
**Groovy Security Token (STO)** — Common Class B share offering of Groovy Company, Inc. itself. $20M Reg D raise. Proceeds seed the Global Unified CEDEX Liquidity Pool via the Solana Treasury. Distinct from ST22 Digital Securities (which represent third-party issuer equity); the Groovy Security Token represents equity in the platform operator.
#### Module-Specific Backing Instruments
**Common Class B Shares (M1)** — A class of common stock created by an issuer via Certificate of Designation, filed with the Secretary of State of the issuer's jurisdiction of incorporation. Common B shares carry full shareholder rights by operation of state law. Issuer-designated terms include voting, dividends, and liquidation participation. Deposited with Empire Stock Transfer under irrevocable, perpetual custody. Backing instrument for Module 1 (Equities) ST22 Digital Securities.
**Single-Asset Entity (SAE) Equity (M2)** — Equity in a single-purpose legal entity (typically a Nevada corporation following a Nevada LLC → corporation conversion) holding a specific real-property asset. The SAE is the issuer of the Module 2 ST22 token. SAE equity is deposited with Empire Stock Transfer under irrevocable, perpetual custody. Each Module 2 mint corresponds to one SAE corresponding to one underlying property.
**Basin-Asset Entity (BAE) Equity (M3)** — Equity in a single-purpose legal entity holding a specific mineral basin or mining concession (the basin asset). The BAE is the issuer of the Module 3 ST22 token. BAE equity is deposited with Empire Stock Transfer under irrevocable, perpetual custody. Each Module 3 mint corresponds to one BAE corresponding to one underlying basin asset.
**Certificate of Designation** — Corporate governance document filed with the Secretary of State of the issuer's state of incorporation (not Wyoming — Wyoming is the platform operator's governing law, not the issuer's). Specifies shareholder rights for the underlying class of equity (Common B for M1, SAE equity for M2, BAE equity for M3). A public document, verifiable by any party.
***
### 3. Security Controls
**Transfer Hook** — SPL Token-2022 program extension executing 42 sequential security controls plus module-aware extensions on every ST22 token transfer before allowing the transaction to complete. Operates at the Solana runtime level — cannot be disabled, bypassed, or routed around by any party, including Groovy Company, Inc. Any control failure causes atomic transaction reversion with a specific error code (6001–6042). Permanently attached at mint creation.
**42 Controls** — The complete set of Transfer Hook security controls, organized into eight categories: Custody Verification (CV-01 to CV-06), Investor Verification (IV-07 to IV-14), Position Limits (PL-15 to PL-19), Circuit Breakers (CB-20 to CB-23), Holding Period Enforcement (HP-24 to HP-29), Sanctions Compliance (SC-30 to SC-34), Protective Conversion (PC-35 to PC-38), and Record Keeping and Governance (RK-39 to RK-42). All execute on every transfer with no exceptions. Module-aware extensions overlay Module 2 NAV-deviation enforcement on CB-21 and Module 3 federal-action freeze coordination on REG-42.
**Control CV-01 (Custody Verification)** — Verifies on every transfer that circulating ST22 token supply does not exceed the custodied balance held by Empire Stock Transfer. Operates uniformly across modules; the asset class held in custody (Common Class B for M1, SAE equity for M2, BAE equity for M3) is recorded in SecurityConfig metadata. Uses Ed25519 attestation from the custody oracle. Zero-tolerance discrepancy threshold. Error 6001 (CustodyDiscrepancy).
**Control HP-24 (Holding Period Lock)** — Enforces holding-period regimes on every transfer attempt. Three regimes:
* **Reg D** (US accredited investors): 6 months — Rule 144 underpinning.
* **Reg S** (non-US investors): 12 months — Regulation S distribution compliance period.
* **Reg CF** (US retail crowdfunding): 12 months.
Records purchase timestamp on-chain at token delivery. Rejects with Error 6024 (TokensLocked) until applicable period elapses. No administrative override. Timer cannot be shortened by governance.
**Control REG-42 (Regulatory Freeze)** — Emergency halt of all transfers on a specific mint or platform-wide. Authorized by Legal Counsel + 3-of-5 multi-sig. No timelock — executes immediately. Used for SEC enforcement actions, court orders, active exploits, OFAC emergency designations, or — for Module 3 — federal action under the federal-action variant.
**CB-21 NAV-Deviation Variant (M2)** — Module 2 extension to Circuit Breaker Control 21. In addition to the standard 2% price-impact-versus-TWAP check, Module 2 mints have a NAV-deviation tolerance (default 22%, configurable per mint). When the on-chain price deviates from the most recent NAV beyond tolerance, or when the NAV oracle is stale beyond the per-mint reappraisal cadence, transfers on the affected mint are rejected with Error 6021 (NAV variant). Returns automatically once NAV is refreshed and deviation falls within tolerance.
**REG-42 Federal-Action Variant (M3)** — Module 3 extension to Regulatory Freeze Control 42. When the Classification oracle reports an active federal action affecting the basin asset (e.g., Section 232 designation, DPA Title III invocation, executive-order-driven export restriction), transfers on the affected mint are automatically frozen within the platform's 60-minute SLA. Other Module 3 mints not subject to the same action remain tradeable. Trading resumes automatically when the action lifts.
**Federal-Action Freeze (M3)** — The automatic Control 42 application driven by Classification oracle federal-action detection. Distinguishes the platform's Module 3 product from peer tokenization platforms. SLA: detection-to-freeze ≤ 60 minutes. See Incident Response Playbook §13.
**Circuit Breaker** — Automated trading halt triggered by predefined market conditions. Cross-module variants: price halt (>10% move in 5 minutes → 15-minute cooldown), price impact (>2% single-trade impact vs TWAP → trade blocked, Error 6021), volume halt (>30% daily sell by single wallet → 24-hour wallet suspension), oracle failure (custody stale → all transfers halt). Module-specific variants: NAV-deviation (M2), classification-stale flagging (M3).
**Protective Conversion** — Controls PC-35 to PC-38. Automatic conversion of underlying equity (Common B for M1, SAE equity for M2, BAE equity for M3) to the issuer's common stock or to platform-arbitrated successor equity upon adverse events: issuer bankruptcy (PC-35), SEC enforcement or criminal indictment (PC-36), loss of Empire services (PC-37), or material breach (PC-38). Ensures investor equity claim survives issuer distress.
***
### 4. On-Chain Programs and Accounts
**`transfer_hook`** — Solana program implementing 42 security controls plus module-aware extensions. Invoked via CPI by SPL Token-2022 on every ST22 transfer. Upgrade authority: 5-of-9 multi-sig with 24-hour timelock. Controls are immutable — governance cannot weaken.
**`amm`** — Solana program implementing the CPMM trading engine. Same engine for all three modules. Upgrade authority: 5-of-9 multi-sig with 24-hour timelock.
**`liquidity_pool`** — Solana program managing the Global Unified CEDEX Liquidity Pool. **Immutable — no upgrade authority.** The withdrawal function does not exist in the bytecode.
**`governance`** — Solana program for on-chain proposal, voting, and execution. Module-aware parameter adjustments routed through this program. Upgrade authority: 3-of-5 multi-sig.
**`oracle_aggregator`** — Solana program aggregating and validating oracle data across all categories: Custody, OFAC, AML, TWAP, EDGAR (M1), NAV (M2), and Classification (M3). Upgrade authority: 5-of-9 multi-sig with 24-hour timelock.
**SecurityConfig** — On-chain account (PDA: `[b"security-config", mint]`) storing all 42 Transfer Hook parameters plus module-aware extension fields for a specific ST22 mint. One per mint. Created at mint initialization. Cross-module fields: max wallet percent, circuit breaker thresholds, cooldown periods, price impact limits, TWAP window, holding period configuration, module identifier. Module 2 fields: NAV deviation max bps (default 2200), NAV reappraisal max age, NAV circuit breaker enabled. Module 3 fields: classification max age, federal-action freeze enabled.
**HoldingPeriodAccount** — On-chain account (PDA: `[b"holding-period", mint, beneficiary]`) recording an individual investor's holding period for a specific ST22 token. Created at token delivery. Contains purchase timestamp, jurisdiction (US / NonUS / RegCF), regime (RegD / RegS / RegCF), holding period duration, and lock status. One per investor-mint pair.
**CustodyOracle** — On-chain account (PDA: `[b"custody-oracle", mint]`) storing Empire Stock Transfer's Ed25519 custody attestation. Module-agnostic schema. Updated every Solana block (\~400ms). Contains custodied balance (asset class per module's SecurityConfig), token supply, attestation slot, signature, and discrepancy flag.
**NAVOracle (M2)** — On-chain account (PDA: `[b"nav-oracle", mint]`) storing the most recent appraised Net Asset Value for a Module 2 mint. Contains appraised NAV (USD-pegged stablecoin units), authorized appraiser identifier, appraisal timestamp, next reappraisal target, deviation tolerance (default 2200 bps / 22%), staleness threshold, Ed25519 signature, and stale flag.
**ClassificationOracle (M3)** — On-chain account (PDA: `[b"classification-oracle", mint]`) storing USGS Critical Minerals List status, DOE Critical Materials Strategy classification, Section 232 applicability, DPA Title III applicability, federal-action active flag, active action references, last refresh timestamp, staleness threshold, and stale flag.
**GlobalPool** — On-chain account (PDA: `[b"global-pool"]`) storing Global Unified CEDEX Liquidity Pool state. Global singleton. Contains SOL vault reference, LP mint reference (supply = 0), cumulative deposits, and initialization timestamp.
**PDA (Program Derived Address)** — Deterministic Solana account address derived from seeds and a program ID. Used for all platform state accounts. No private key — accounts are program-owned.
**ExtraAccountMetaList** — Token-2022 standard account enabling the Transfer Hook program to specify additional accounts it needs during hook execution. Cross-module accounts: SecurityConfig, CustodyOracle, OFACOracle, AMLOracle, HoldingPeriodAccount. Module 2 additionally references NAVOracle. Module 3 additionally references ClassificationOracle.
***
### 5. Regulatory Framework
**SEC Release No. 33-11412** — Joint SEC/CFTC release (March 17, 2026) establishing the Digital Securities taxonomy. Defines five categories of crypto assets. ST22 tokens classified as Category 5 (Digital Securities). Binding federal interpretation.
**January 28, 2026 Joint Staff Statement** — SEC Joint Staff Statement on Tokenized Securities distinguishing Category 1 (issuer-sponsored tokenization with DLT in official records) from Category 2 (third-party sponsored with counterparty risk). The platform operates under Category 1 Model B.
**Category 1 Model B** — SEC's preferred architecture for compliant tokenization. Seven requirements: (1) direct issuer authorization, (2) official shareholder register, (3) regulated custody, (4) true equity backing, (5) clear ownership chain, (6) investor protection, (7) token standard compliance. The platform satisfies all seven across all three modules.
**Category 5 (Digital Securities)** — SEC classification for crypto assets that are financial instruments with ownership recorded on a crypto network. ST22 tokens satisfy this definition under Release No. 33-11412.
**April 13, 2026 SEC Staff Statement** — SEC Staff Statement on Covered User Interface Providers. Defines safe-harbor framing for compliant tokenization interfaces. The platform's CEDEX trading venue aligns with the statement's covered-interface definition.
**Reg D** — SEC registration exemption (17 CFR §§230.501–506) allowing private offerings to accredited investors. Used for US ST22 purchases by accredited investors. General solicitation permitted within the regulatory framework. Form D filed within 15 days of first sale. Standard phrasing is just "Reg D" — never with a 506(c) qualifier.
**Reg S** — SEC registration exemption (17 CFR §§230.901–905) for offshore transactions to non-US persons. Used for non-US ST22 purchases. 12-month distribution compliance period enforced by Control HP-24.
**Reg CF** — Regulation Crowdfunding (17 CFR §§227.100–504). Used for US retail crowdfunding ST22 issuances through a FINRA-registered funding portal partnership. 12-month holding period enforced by Control HP-24. Distinct from Reg D in investor eligibility (retail vs accredited) and offering size limits.
**Rule 144** — SEC rule (17 CFR §230.144) governing resale of restricted securities. The 6-month holding period under Rule 144 is the regulatory underpinning of the Reg D holding period enforced on-chain by Transfer Hook Control HP-24.
**GENIUS Act** — Guiding and Establishing National Innovation for U.S. Stablecoins Act. Legislative framework for compliant stablecoin usage. The platform uses GENIUS Act-compliant stablecoins (USDC and PYUSD) for all ST22 settlement.
**Form D** — SEC filing (17 CFR §230.503) notifying the SEC of a Reg D offering. Filed electronically via EDGAR within 15 days of first sale. Annual amendments as required.
#### Module 3 Federal Frameworks (CORECM)
**USGS Critical Minerals List** — US Geological Survey list of mineral commodities considered critical to the United States. Reviewed every three years. Inputs to the Classification oracle for Module 3 mints.
**DOE Critical Materials Strategy** — US Department of Energy framework prioritizing critical materials for the energy transition. Inputs to the Classification oracle for Module 3 mints.
**Section 232** — Section 232 of the Trade Expansion Act of 1962. Authorizes the President to impose tariffs or quotas on imports threatening national security. Section 232 designations affecting a Module 3 basin asset are surfaced through the Classification oracle and may trigger the federal-action freeze.
**DPA Title III** — Defense Production Act Title III. Authorizes incentives to expand domestic production of strategic and critical materials. DPA Title III invocations affecting a Module 3 basin asset trigger Classification oracle updates.
**IRA Critical Minerals** — Inflation Reduction Act critical minerals provisions. Tax credits and incentives tied to critical minerals sourcing. Surfaced through the Classification oracle.
**EO 14017** — Executive Order 14017 on America's Supply Chains (February 24, 2021). Directs federal critical-minerals supply-chain policy; subsequent executive orders amend the framework. Executive-order-driven export restrictions affecting a basin asset trigger Classification oracle updates.
**Energy Act of 2020** — Title VII of the Consolidated Appropriations Act, 2021. Codifies the federal critical-minerals statutory framework. Source authority for USGS Critical Minerals List.
***
### 6. Compliance and Verification
**Empire Stock Transfer** — SEC §17A-registered transfer agent and qualified custodian. Sole investor onboarding authority for all ST22 issuers across all three modules. Dual role: (1) holds the underlying equity (Common Class B for M1, SAE equity for M2, BAE equity for M3) in irrevocable custody; (2) performs all KYC, KYB, AML, OFAC/SDN screening, and wallet verification (KYW). Operating since 2006, serving 530+ publicly traded companies across 5 continents.
**KYC (Know Your Customer)** — Identity verification for individual investors. Performed by Empire Stock Transfer at onboarding. Four-pillar CIP: government-issued ID, full legal name, DOB, SSN/ITIN. Module 3 onboarding includes enhanced beneficial-ownership depth given the strategic-minerals nature of the asset class. Regulatory basis: BSA CIP (31 CFR §1020.220).
**KYB (Know Your Business)** — Entity verification for corporate/institutional investors. Includes entity formation documents, registration number, EIN, and Ultimate Beneficial Owner identification at ≥25% threshold. Performed by Empire Stock Transfer. Regulatory basis: FinCEN Beneficial Ownership Rule (31 CFR §1010.230).
**KYW (Know Your Wallet)** — Wallet verification linking a Solana wallet address to a verified identity in Empire's Master Securityholder File. Unregistered wallets cannot receive ST22 tokens.
**AML (Anti-Money Laundering)** — Compliance program detecting and preventing money laundering, terrorist financing, and sanctions evasion. Dual-provider: Chainalysis KYT + TRM Labs. Three-tier risk disposition: 0–30 approve, 31–70 enhanced review, 71–100 reject (Error 6006). Regulatory basis: BSA (31 U.S.C. §5311), 31 CFR Part 1010.
**OFAC / SDN** — Office of Foreign Assets Control / Specially Designated Nationals list. Three-layer screening on every transfer: Layer 1 (exact wallet address), Layer 2 (fuzzy entity name), Layer 3 (2-hop graph clustering). Refreshed hourly + emergency push. Stale >48h halts all transfers. Regulatory basis: 50 Fed. Reg. 5342, Executive Orders.
**Accredited Investor** — SEC-defined investor (Rule 501): individual income $200K+/$300K joint in each of 2 most recent years, OR net worth $1M+ excluding primary residence, OR professional certification (Series 7/65/82), OR entity with $5M+ assets. Verified by Empire Stock Transfer. Required for Reg D investors; not required for Reg S or Reg CF.
**Master Securityholder File (MSF)** — Empire Stock Transfer's authoritative, legally binding record of all underlying-equity ownership across all three modules. The official shareholder register for all ST22-backed securities. Updated via UCC Article 8 entitlement orders on every ST22 transfer.
**BSA (Bank Secrecy Act)** — Federal anti-money laundering legislation (31 U.S.C. §5311 et seq.). Requires: CIP, CDD, beneficial ownership, transaction monitoring, SAR/CTR filing, recordkeeping, independent testing, compliance officer, and training.
**SAR (Suspicious Activity Report)** — Filing with FinCEN for transactions ≥$5,000 meeting BSA suspicious activity criteria. Empire Stock Transfer files SARs. Confidential — not disclosed to the subject. Regulatory basis: 31 CFR §1010.320.
**CTR (Currency Transaction Report)** — Filing for fiat on-ramp transactions ≥$10,000. Regulatory basis: 31 CFR §1010.311.
***
### 7. Trading and Liquidity
**CPMM (Constant Product Market Maker)** — Mathematical trading formula: x × y = k, where x = SOL reserve, y = ST22 reserve, k = constant product invariant. Same formula across all three modules. Fee (5%) applied before invariant calculation, ensuring k only increases. All intermediate calculations use u128 arithmetic to prevent overflow.
**Slippage** — Difference between expected and actual trade price. Configurable per order (default 1%, max 5%). If output falls below minimum after slippage, the trade reverts with Error 7002 (SlippageExceeded).
**Price Impact** — Price movement caused by a single trade. Transfer Hook Control CB-21 blocks any trade causing >2% impact versus TWAP. For Module 2 mints, the NAV-deviation variant additionally blocks trades causing the on-chain price to exceed NAV by more than the configured tolerance. Measured in basis points (bps).
**TWAP (Time-Weighted Average Price)** — Rolling average price calculated across a configurable window (default: 30 minutes) with minimum 60 observations. Used as the reference for circuit breaker calculations across all modules. 3σ outlier rejection prevents single-block manipulation.
**NAV-Deviation Tolerance (M2)** — Per-mint configuration setting on Module 2 SecurityConfig. Default 2200 bps (22%). Maximum permitted deviation between the on-chain price and the most recent NAV before transfers are blocked under the CB-21 NAV variant.
**NAV Reappraisal Cadence (M2)** — Per-mint configuration setting on Module 2 SecurityConfig (`nav_reappraisal_max_age_secs`). The maximum permitted time since the last NAV update before the NAV oracle is considered stale. Per-mint cadence is established by tripartite concurrence (issuer + appraiser + Empire Stock Transfer).
**Basis Points (bps)** — 1/100th of a percentage point. 100 bps = 1%. 499 bps = 4.99%. 2200 bps = 22%. Used throughout for fee configuration, wallet limits, price impact thresholds, and NAV deviation thresholds.
**LP (Liquidity Provider) Token** — Token representing a share of a liquidity pool. In the platform's design, LP tokens are burned at Global Pool initialization — supply is permanently zero. No LP token holder exists. No withdrawal function exists.
**Fee Distribution** — 5% total (500 bps) per CEDEX trade, identical across all three modules: 2.00% issuer treasury (200 bps), 1.50% GROO staking pool (150 bps), 1.06% protocol operations (106 bps), 0.44% Global Pool — permanently locked (44 bps).
**Jito Block Engine** — Solana MEV protection infrastructure. CEDEX submits transactions to the Jito relayer for private inclusion — transactions are not visible in the public mempool until block inclusion. Prevents front-running and sandwich attacks. See ADR-010.
***
### 8. Oracle Network
**Custody Attestation Oracle (1:1)** — Empire Stock Transfer's cryptographic custody verification feed, updated every Solana block (\~400ms). Confirms circulating ST22 supply does not exceed the custodied balance for the mint's underlying equity (Common Class B for M1, SAE equity for M2, BAE equity for M3). Ed25519 signed. Zero-tolerance discrepancy. Module-agnostic at the oracle layer.
**EDGAR Oracle (M1)** — Module 1 oracle relaying SEC EDGAR filing data for Equities issuers: 8-K trigger events, OTC tier degradation, Late Filer status, RPS (Risk Profile Score) input. EDGAR coverage applies only to Module 1 — Module 2 and Module 3 use different upstream data sources.
**NAV Oracle (M2)** — Module 2 oracle holding the most recent appraised Net Asset Value for a Module 2 mint. Updated at the per-mint reappraisal cadence by the authorized appraiser. Ed25519 signed. Powers the CB-21 NAV-deviation variant. PDA: `[b"nav-oracle", mint]`.
**Classification Oracle (M3)** — Module 3 oracle holding USGS Critical Minerals List status, DOE Critical Materials Strategy classification, Section 232 applicability, DPA Title III applicability, and federal-action active flag for a Module 3 mint. Updated by the authorized Classification relay monitoring USGS, DOE, and the Federal Register. Powers the REG-42 federal-action variant with a 60-minute detection-to-freeze SLA. PDA: `[b"classification-oracle", mint]`.
**Ed25519** — NIST-standardized digital signature algorithm (EdDSA on Curve25519). Used by Empire Stock Transfer to sign custody attestation payloads, by the authorized appraiser to sign NAV updates (M2), and by the Classification relay to sign classification updates (M3). Verified natively by Solana's Ed25519 precompile (\~120 CU). Replay prevention via slot + timestamp in signed payload.
**Oracle Staleness** — Duration since the last oracle update. Each oracle has a defined staleness threshold beyond which its data is considered unreliable. Custody: 1 slot. OFAC: 24h cache / 48h halt. AML: 6h cache. TWAP: 5 minutes. NAV (M2): per-mint cadence (default 90 days). Classification (M3): 24h refresh / federal-action SLA 60 minutes.
**Byzantine Fault Tolerance (BFT)** — The property that a system continues operating correctly even when some nodes provide incorrect data. The platform's oracle network requires 2-of-3 consensus for discrepancy resolution (primary Empire, backup platform node, quarterly audit).
**Chainalysis KYT** — Know Your Transaction. Blockchain analytics platform for AML compliance and investigation. Integrated in Transfer Hook Controls IV-11 to IV-15 for real-time risk scoring. Industry standard with widest entity coverage.
**TRM Labs** — Machine learning risk scoring for cryptocurrency transactions. 200+ behavioral features. Co-integrated with Chainalysis KYT as dual-provider AML. Different ML models reduce single-provider blind spots.
**Pyth Network** — Pull-based high-frequency price oracle on Solana. First-party data publishers (institutional market makers). Provides SOL/USD and ST22/SOL price data for TWAP calculation across all modules. Sub-second update cadence.
***
### 9. Blockchain and Solana
**Solana** — Layer 1 blockchain. Proof of History (PoH) + Tower BFT consensus. \~400ms block time. \~65,000 TPS theoretical. \~$0.00025 average transaction cost. Home chain for all platform programs and ST22 tokens across all three modules.
**SPL Token-2022** — Solana Program Library next-generation token standard. Adds Transfer Hook, Metadata, Transfer Fee, Permanent Delegate, and Confidential Transfer extensions. The token program used for all ST22 mints. Program ID: `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb`.
**CPI (Cross-Program Invocation)** — Solana mechanism for one program to call another. Token-2022 invokes the Transfer Hook via CPI on every transfer — this invocation is mandatory and cannot be skipped.
**Anchor** — Solana smart contract development framework by Coral. All five platform programs are built with Anchor 0.30+. Provides account serialization, instruction dispatch, PDA derivation, and IDL generation.
**Compute Units (CU)** — Solana's measure of on-chain computation cost. Each transaction has a CU budget. Per-module CU budgets for a complete CEDEX swap with all 42 Transfer Hook controls plus module-aware extensions: Module 1 \~800,000 CU, Module 2 \~820,000 CU, Module 3 \~830,000 CU.
**Slot** — Solana's unit of time for block production. One slot ≈ 400ms. Custody oracle attestation is measured in slot age — attestations older than 1 slot are considered stale.
**Block Finality** — The point at which a transaction is irreversible. Solana: \~13 seconds (32 confirmations). CEDEX uses `confirmed` for reads and `finalized` for settlement.
**Helius** — Enterprise Solana RPC infrastructure provider. The platform's primary RPC. Dedicated cluster (500+ req/sec). Enhanced WebSocket support.
**Triton** — Backup Solana RPC provider. Automatic failover when Helius is unavailable.
**Ledger Enterprise** — Institutional-grade HSM-backed key management. Used by the platform for ST22 token operations (minting, transfers) across all three modules. Multi-sig governance with hardware security modules.
***
### 10. Key Management and Governance
**5-of-9 Multi-Sig** — Multi-signature wallet requiring 5 of 9 geographically distributed key holders to authorize program upgrades. 24-hour timelock on all actions. Keys stored on Ledger Enterprise HSMs.
**3-of-5 Multi-Sig** — Multi-signature wallet for parameter adjustments and emergency actions. 48-hour timelock for parameters. No timelock for Control 42 (requires Legal Counsel authorization).
**Timelock** — Mandatory waiting period between authorization and execution. Parameter changes: 48 hours. Program upgrades: 24 hours. Emergency freeze (Control 42): none — immediate. Timelocked actions can be cancelled by 2-of-5 during the window.
**Governance Proposal** — On-chain proposal for protocol changes. Three types: ParameterAdjustment (simple majority, 48h timelock), ProgramUpgrade (66.67% supermajority, 24h timelock, Certora re-verification), EmergencyAction (3-of-5 + Legal Counsel, immediate). Module-aware parameter adjustments (Module 2 NAV bounds; Module 3 classification bounds and federal-action toggle) are scoped to their respective modules.
**Tripartite Concurrence (M2)** — Module 2 governance pattern requiring agreement among three parties for NAV-bound parameter changes: the SAE issuer, the authorized appraiser, and Empire Stock Transfer. Used for setting per-mint NAV reappraisal cadence and adjusting NAV deviation tolerance.
***
### 11. Audit and Formal Verification
**Certora Prover** — Symbolic execution and formal verification tool for smart contracts. Verifies mathematical properties hold under ALL possible execution conditions — not just tested scenarios. Six invariants verified for the platform across all three modules.
**Certora Invariant E.1** — No unauthorized minting: supply cannot increase without verified Empire custody deposit and Ed25519 signature. Applies uniformly across modules.
**Certora Invariant E.2** — Custody ratio: every executed transfer has verified 1:1 backing at the moment of execution. Applies uniformly across modules.
**Certora Invariant E.3** — Pool non-extractability: no instruction in any platform program can reduce Global Pool balance. Withdrawal is mathematically impossible. Single shared pool across all modules.
**Certora Invariant E.4** — Hook completeness: every transfer on a hook-enabled mint triggers the Transfer Hook. Rejection causes atomic revert. Verifies that module-aware extensions (Module 2 NAV-deviation, Module 3 federal-action freeze coordination) cannot be removed by program upgrade.
**Certora Invariant E.5** — Fee accuracy: actual fee is within 1 lamport of expected (5% of input amount). Rounding floors (favors pool). Applies uniformly across modules.
**Certora Invariant E.6** — Circuit breaker correctness: breaker activates if and only if the threshold is exceeded. No false positives or false negatives. Covers Module 2 NAV-deviation variant of CB-21.
**Quantstamp** — Smart contract security audit firm. Engaged for Transfer Hook and Oracle Aggregator programs.
**Halborn** — Penetration testing and security assessment firm. Engaged for Transfer Hook and Governance programs.
**OtterSec** — Smart contract audit firm. Engaged for AMM program.
***
### 12. People and Entities
**Frank Yglesias** — Chairman of the Board, Chief Technology Officer, and sole director, Groovy Company, Inc. Technical authority over smart contract architecture and security decisions across all three modules. Also Chairman and CEO of Pineapple Express, Inc. (PNXP), which holds 51% of Groovy Company, Inc. Contact: .
**Patrick Mokros** — Chief Operating Officer of Groovy Company, Inc., and Founder of Empire Stock Transfer. Dual role disclosed as conflict of interest given Empire's role as sole onboarding authority for the platform.
**Jhony Navarro** — Engineering, Groovy Company, Inc. CTO-level engineering responsibility, not a director.
**Legal Counsel** — Legal advisory role for the platform. Authorizes Control 42 regulatory freeze. Reviews all regulatory filings and SEC engagement.
**Groovy Company, Inc.** — Wyoming Corporation, CIK 1499275, OTC: GROO. Principal office 600 W Peachtree St NW, Suite 1700, Atlanta, GA 30308. Wyoming domicile. Operating entity for the RWA Tokens platform.
**Empire Stock Transfer** — See §6 entry. Founded by Patrick Mokros. SEC §17A-registered transfer agent and qualified custodian.
**Pineapple Express, Inc. (PNXP)** — Holds 51% of Groovy Company, Inc. Frank Yglesias serves as Chairman and CEO.
***
### 13. Deprecated Terminology
The following terms are obsolete and must never appear in any current document. They are listed here for historical reference and to prevent accidental reuse. No transition language ("formerly known as", "rebranded from", etc.) appears anywhere in current documentation.
| Deprecated Term | Correct Replacement | Reason |
| --------------------------------------------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| **OTCM Protocol** (platform brand) | RWA Tokens | Platform rebranded May 1, 2026 |
| **OTCM Protocol Inc.** (as platform entity) | Groovy Company, Inc. | OTCM Protocol Inc. (FL) is a separate entity Frank is evaluating |
| **`dba OTCM Protocol`** | Groovy Company, Inc. (no dba) | dba was cancelled May 1, 2026 |
| **`@otcm-protocol/sdk`** | `@rwatokens/sdk` | SDK package renamed |
| **`OtcmClient`** | `RwaTokensClient` | SDK client class renamed |
| **`OtcmError`** | `RwaTokensError` | SDK error class renamed |
| **`common_b_balance`** / **`commonBBalance`** | `custodied_balance` / `custodiedBalance` | Module-agnostic field naming |
| **`otcm_transfer_hook`** | `transfer_hook` | Program crate renamed |
| **`otcm_amm`** | `amm` | Program crate renamed |
| **`otcm_liquidity_pool`** | `liquidity_pool` | Program crate renamed |
| **`otcm_governance`** | `governance` | Program crate renamed |
| **`otcm_oracle_aggregator`** | `oracle_aggregator` | Program crate renamed |
| **Series M** / **Preferred Series M** | Common Class B (M1) / SAE equity (M2) / BAE equity (M3) | SEC Crypto Task Force March 2026 directive |
| **Security Meme Token (SMT)** | ST22 Digital Securities (issuers) or GROO Utility Token (GROO) | Terminology fully replaced |
| **Howey Shield** | *(removed entirely)* | Framework obsolete. Category 1 Model B embraces Howey, does not avoid it. |
| **OTCM Security Token** / **OTCM STO** | Groovy Security Token (STO) | Renamed alongside platform brand |
| **GROO STO** | GROO Utility Token | GROO is a utility token, not an STO |
| **OTCM.VIP** / **cedex.otcm.io** | cedex.market | URL obsolete |
| **otcm.io** (platform site) | rwatokens.net | URL obsolete |
| **** / **** | | Email domain updated |
| **** | | Email domain updated |
| **** | | Email domain updated |
| **Berj Abajian** / former CEO | *(removed entirely)* | Terminated for Cause effective May 1, 2026 |
| **John Morgan** | *(removed entirely)* | No longer on team |
| **Jeff Turner** / **JDT Legal** / **CLO** | Legal Counsel | Attribution retired |
| **Pink Current** | OTCID | OTC Markets Group renamed the tier |
| **VestingConfig** | HoldingPeriodAccount | Account schema replaced. Complete rewrite. |
| **VestingLocked** (Error 6024) | TokensLocked (Error 6024) | Error code retained, meaning changed |
| **Per-issuer bonding curve** / **FLP** | Global Unified CEDEX Liquidity Pool | Architecture changed in V6+ |
| **"illiquid OTC microcap"** | Professional, capability-led framing | No distress or pity narratives. Lead with infrastructure. |
| **"trapped shareholders"** | Professional framing | Same — no broken-market narratives |
| **Five-layer architecture** | Nine-layer architecture | Layers 6–9 added |
| **Rule 506(c)** / **Reg D 506(c)** / any 506(c) qualifier | Reg D | Standard phrasing is just "Reg D" — never paired with 506(c) |
| **"Empire as just a transfer agent"** | Empire Stock Transfer — qualified custodian AND sole investor onboarding authority | Empire's role is broader than transfer agent alone |
| **"OTC Microcap" as the only asset class** | Three-module architecture (Equities, Real Estate, CORECM) | Platform scope is global RWA tokenization across three modules |
| **OTCM Protocol → RWA Tokens transition language** | *(no transition language)* | Treat the platform brand as established |
***
### Usage Notes
* When uncertain about a term, check this glossary first — it is the authoritative source across all documentation.
* Module-aware terms are annotated with **(M1)**, **(M2)**, or **(M3)**. Cross-module terms have no annotation.
* Terminology is legally load-bearing — using obsolete terms can create regulatory confusion.
* Terms must be used consistently across all documents: whitepaper, wiki, SDK, API docs, legal documents, marketing, and social media.
* If a term is platform-specific and not in this glossary, add it via a PR to this page.
***
### Related Documentation
* **Contributing Guide** — Terminology requirements for contributors (§8.3 "Always use" / "Never use" tables).
* **Smart Contract Reference** — Module-aware program behavior with full PDA registry.
* **Transfer Hook Reference** — Standalone reference for the 42 controls and module-aware extensions.
* **SDK Reference** — `@rwatokens/sdk` package, `RwaTokensClient` API, module-aware methods.
* **Oracle Integration Guide** — Custody, OFAC, AML, TWAP, EDGAR (M1), NAV (M2), Classification (M3) relay architecture.
* **Governance Deep Dive** — Module-aware governance surface, tripartite concurrence pattern, Control 42 federal-action variant.
* **Tokenomics Deep Dive** — GROO Utility Token bonding-curve mechanics, fee distribution, Global Pool funding.
***
*RWA Tokens · Glossary · Groovy Company, Inc.*
# FAQ & Troubleshooting
## FAQ and Troubleshooting
**Issuers · Investors · Developers · Compliance · Error Resolution**
Answers to the most common questions about the RWA Tokens platform — the institutional infrastructure operated by Groovy Company, Inc. — organized by audience. The Troubleshooting section provides step-by-step error resolution for every Transfer Hook error code and common operational issue across all three production modules: Module 1 (Equities), Module 2 (Real Estate), and Module 3 (CORECM — Carbon Ore, Rare Earth, and Critical Minerals).
***
### Table of Contents
**Part 1 — Frequently Asked Questions**
1. Platform Overview
2. For Investors
3. For Issuers
4. For Developers
5. Regulatory and Compliance
6. GROO Utility Token
7. Module 2 — Real Estate Specifics
8. Module 3 — CORECM Specifics
**Part 2 — Troubleshooting**
9. Transfer Hook Error Code Reference
10. CEDEX Trading Issues
11. Wallet and Connection Issues
12. Oracle and System Issues
13. SDK and API Issues
***
## Part 1 — Frequently Asked Questions
***
### 1. Platform Overview
**Q: What is RWA Tokens?**
RWA Tokens is global institutional infrastructure for tokenizing real-world assets as ST22 Digital Securities on Solana. The platform is operated by Groovy Company, Inc. and currently serves three production modules: Module 1 (Equities — OTC microcap, NASDAQ, AMEX, TSX, and global exchanges), Module 2 (Real Estate — single-asset entities), and Module 3 (CORECM — Carbon Ore, Rare Earth, and Critical Minerals). The platform provides a nine-layer architecture with 42 immutable Transfer Hook security controls plus module-aware extensions, a permanently locked Global Unified CEDEX Liquidity Pool, and real-time Ed25519 custody attestation from Empire Stock Transfer — the SEC §17A-registered qualified custodian.
**Q: What is an ST22 Digital Security?**
An ST22 Digital Security is a token on Solana (SPL Token-2022 standard) representing direct beneficial ownership in the underlying issuer's equity. The asset class held in custody varies by module: Common Class B shares (Module 1), single-asset entity (SAE) equity (Module 2), or basin-asset entity (BAE) equity (Module 3). Each ST22 token is backed 1:1 by the underlying equity unit, held in irrevocable custody at Empire Stock Transfer. ST22 tokens are classified as Category 5 Digital Securities under SEC Release No. 33-11412 (March 17, 2026).
**Q: What is CEDEX?**
CEDEX (Compliant Exchange for Digital Securities) is the exclusive trading venue for ST22 tokens, available at `cedex.market`. It is the only exchange that preserves all 42 Transfer Hook security controls plus module-aware extensions on every trade. CEDEX combines Web2-grade order matching with Web3-grade Solana settlement. Trading operates 24/7/365 across all three modules through a single venue.
**Q: Why can't ST22 tokens trade on Raydium, Jupiter, or other DEXs?**
External DEXs call the original SPL Token Program — not SPL Token-2022. This bypasses the Transfer Hook entirely, disabling all 42 security controls including custody verification, OFAC/SDN screening, AML scoring, accreditation checks, holding period enforcement, and the module-aware extensions (Module 2 NAV-deviation, Module 3 federal-action freeze). Without these controls, ST22 tokens would become non-compliant securities. CEDEX was purpose-built to solve this problem (see ADR-002).
**Q: What is the Global Unified CEDEX Liquidity Pool?**
A single protocol-owned capital reserve shared by all ST22 issuers across all three modules. LP tokens were burned at initialization — meaning withdrawal is mathematically impossible (no withdrawal function exists in the code, the code is immutable, and Certora Prover formally verified this property — invariant E.3). Every new issuer inherits immediate secondary market depth. Every trade deepens the pool via a 0.44% fee allocation.
**Q: What happens to my tokens if Groovy Company, Inc. goes out of business?**
The underlying equity (Common Class B shares for Module 1, SAE equity for Module 2, BAE equity for Module 3) remains in Empire Stock Transfer's irrevocable custody regardless of Groovy Company's status. Empire is an independent, SEC §17A-registered entity. Your direct equity ownership claim is protected through the Certificate of Designation. Protective conversion triggers (Controls PC-35 to PC-38) automatically convert the underlying equity to common stock or platform-arbitrated successor equity upon material adverse events including loss of platform services.
***
### 2. For Investors
**Q: Who can invest in ST22 Digital Securities?**
ST22 tokens are issued under three regulatory regimes:
* **Reg D** — US accredited investors (income, net worth, or professional certification thresholds).
* **Reg S** — non-US persons (offshore transactions only).
* **Reg CF** — US retail crowdfunding through a FINRA-registered funding portal partnership.
All investors must complete KYC, KYB (where applicable), AML, and OFAC/SDN verification through Empire Stock Transfer regardless of regime.
**Q: How do I become a verified investor?**
Complete the verification process through the platform portal, which routes to Empire Stock Transfer's verification dashboard. You will need government-issued photo ID, proof of address, and — for Reg D — proof of accreditation (income documentation, net worth verification, or professional certification). Entity investors need formation documents and Ultimate Beneficial Owner identification at the ≥25% threshold. Module 3 onboarding includes enhanced beneficial-ownership depth given the strategic-minerals nature of the asset class.
**Q: What is the holding period?**
Three regimes, each enforced on-chain by Transfer Hook Control HP-24:
* **Reg D** (US accredited): 6 months — Rule 144 underpinning.
* **Reg S** (non-US): 12 months — Regulation S distribution compliance period.
* **Reg CF** (US retail crowdfunding): 12 months.
These periods cannot be shortened, bypassed, or overridden by anyone, including Groovy Company, Inc. The timer starts at the moment tokens are delivered to your wallet.
**Q: How do I check when my holding period ends?**
Via the CEDEX portfolio dashboard at `cedex.market`, or via the API:
```
GET https://api.cedex.market/v1/portfolio
→ positions[].holdingPeriod.unlockDate
→ positions[].holdingPeriod.secondsRemaining
→ positions[].holdingPeriod.regime // 'RegD' | 'RegS' | 'RegCF'
```
**Q: What is the wallet limit?**
The default per-wallet cap is 4.99% of any ST22 token's total supply (4.99% applies to Module 1 and Module 3). Module 2 issuers may configure a higher per-mint cap — up to 9.99% — when warranted by the underlying property's structure. The cap is recorded in the SecurityConfig at mint initialization. Transfer Hook Control PL-16 enforces this on every transfer — if your post-transfer balance would exceed the configured cap, the transaction is rejected with Error 6020 (WalletLimitExceeded).
**Q: What are the trading fees?**
5% total per trade (500 basis points), distributed automatically on-chain identically across all three modules: 2% to the issuer treasury, 1.5% to GROO staking pool, 1.06% to protocol operations, 0.44% to the Global Pool (permanently locked). Fees are deducted from each trade — they are not charged separately.
**Q: What wallet do I need?**
Any Solana-compatible wallet that supports SPL Token-2022 tokens. Phantom, Solflare, Backpack, Coinbase Wallet, and Ledger are recommended. Your wallet must be registered with Empire Stock Transfer (KYW — Know Your Wallet) before you can receive ST22 tokens.
**Q: What payment methods are accepted?**
All ST22 purchases are settled via GENIUS Act-compliant stablecoins: USDC (Circle) or PYUSD (PayPal/Paxos). No fiat wire transfer. No SOL or other cryptocurrency.
**Q: What are circuit breakers?**
Automated trading halts modeled on traditional exchange mechanisms (NYSE Rule 80B). Cross-module variants:
* **Price halt**: price moves >10% in 5 minutes → 15-minute cooldown.
* **Price impact**: a single trade would cause >2% impact vs the TWAP → trade blocked.
* **Volume halt**: a single wallet sells >30% of circulating supply in 24h → 24-hour wallet suspension.
* **Oracle failure**: custody attestation stale → all transfers halt.
Module 2 adds a NAV-deviation variant: when on-chain price deviates from NAV beyond the configured tolerance (default 22%), trades are blocked under Error 6021 (NAV variant). Module 3 adds federal-action freeze under Control 42 when the Classification oracle reports an active federal action affecting the basin asset.
These protections operate at the smart contract level — there is no administrative override.
**Q: Can I lose my tokens?**
Your tokens are in your Solana wallet — you control them. However, you must safeguard your wallet private key and seed phrase. If you lose your seed phrase, there is no recovery mechanism (Groovy Company, Inc. cannot access your wallet). Transfer Hook controls protect against market manipulation and fraud, but they do not protect against loss of wallet access.
***
### 3. For Issuers
**Q: What does tokenization cost?**
One-time minting fee, tiered by market cap and module: $1,000–$25,000 (Module 1 Equities), $5,000–$50,000 (Module 2 Real Estate, reflecting the SAE setup), $10,000–$75,000 (Module 3 CORECM, reflecting the BAE setup and enhanced compliance overhead). No exchange listing fee. No market maker fee. No ongoing platform fee (the 5% trading fee is paid by traders, not issuers). Legal documentation costs vary based on issuer counsel.
**Q: How long does onboarding take?**
Approximately 8–12 weeks from application to live CEDEX trading for Module 1. Module 2 typically adds 2–4 weeks for the single-asset entity formation and conversion (often Nevada LLC → Nevada corporation). Module 3 typically adds 4–6 weeks for the basin-asset entity formation and the enhanced classification verification with USGS / DOE / Federal Register baselines. The primary variable is legal documentation preparation, which depends on issuer counsel responsiveness.
**Q: What does the issuer earn from secondary trading?**
2% of every CEDEX trade flows automatically to the issuer's designated treasury wallet. At $1M daily volume, the issuer earns $20,000/day in passive fee revenue. This is on-chain and automatic — no action required. Identical mechanics across all three modules.
**Q: Do we need a market maker?**
No. The Global Unified CEDEX Liquidity Pool serves all issuers across all three modules simultaneously. Protocol-owned. LP burned. No market maker required, no market maker fees, no risk of market maker withdrawal.
**Q: Do we need blockchain developers?**
No. The platform handles all blockchain infrastructure. The issuer's technical involvement is zero. You provide corporate authorization and equity — the platform provides the technology.
**Q: What corporate actions are required?**
| Module | Required Corporate Actions |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Module 1 — Equities** | Board resolution authorizing Common Class B share creation; Certificate of Designation filed with the Secretary of State of your jurisdiction of incorporation; tripartite agreement with Groovy Company, Inc. and Empire Stock Transfer. |
| **Module 2 — Real Estate** | Single-asset entity (SAE) formation (typically Nevada corporation following Nevada LLC → corporation conversion) holding the underlying property; SAE board resolution; Certificate of Designation for SAE equity; appraiser engagement; tripartite agreement. |
| **Module 3 — CORECM** | Basin-asset entity (BAE) formation holding the basin asset or mining concession; BAE board resolution; Certificate of Designation for BAE equity; enhanced beneficial-ownership documentation; USGS / DOE classification baseline; tripartite agreement. |
Templates are provided; your counsel customizes them.
**Q: What happens if our SEC reporting lapses (Module 1)?**
Transfer Hook investor verification controls (IV-12 in particular) monitor issuer eligibility via the EDGAR oracle. If SEC registration lapses or an enforcement action is detected, ST22 transfers may be halted for the affected mint until the condition is resolved. EDGAR oracle coverage applies only to Module 1.
**Q: Can we create more tokens later?**
Additional ST22 tokens can only be minted if additional underlying equity (Common Class B for Module 1, SAE equity for Module 2, BAE equity for Module 3) is deposited with Empire Stock Transfer. Token supply always equals 1:1 with the custodied balance. The custody oracle verifies this on every Solana block (\~400ms).
***
### 4. For Developers
**Q: How do I integrate with CEDEX?**
Three options: the TypeScript SDK (`@rwatokens/sdk`), the REST API (`api.cedex.market/v1`), or WebSocket streams (`wss://api.cedex.market/ws/v1`). See the SDK Reference and CEDEX API Reference for complete documentation.
**Q: What SDK is available?**
```bash
npm install @rwatokens/sdk
```
The SDK provides typed clients for Transfer Hook operations, CEDEX trading, portfolio queries, oracle monitoring (including module-specific NAV oracle for Module 2 and Classification oracle for Module 3), and WebSocket subscriptions. Full TypeScript support with JSDoc documentation.
**Q: How do I simulate a transfer without executing it?**
```typescript
const simulation = await client.hooks.simulateTransfer({
mint: mintAddress,
source: sourceWallet,
destination: destinationWallet,
amount: 50_000_000_000n,
});
// Returns: { wouldSucceed: boolean, controlResults: Map }
// Module 2: ControlResult.details.variant === 'nav_deviation' for CB-21 NAV variant
// Module 3: ControlResult.details.variant === 'federal_action' for REG-42 federal variant
```
Or via the API:
```
POST https://api.cedex.market/v1/estimate
```
**Q: How do I derive PDAs for platform accounts?**
```typescript
import { PublicKey } from '@solana/web3.js';
// Cross-module PDAs
const [securityConfig] = PublicKey.findProgramAddressSync(
[Buffer.from('security-config'), mint.toBuffer()],
TRANSFER_HOOK_PROGRAM_ID,
);
const [holdingPeriod] = PublicKey.findProgramAddressSync(
[Buffer.from('holding-period'), mint.toBuffer(), beneficiary.toBuffer()],
TRANSFER_HOOK_PROGRAM_ID,
);
const [custodyOracle] = PublicKey.findProgramAddressSync(
[Buffer.from('custody-oracle'), mint.toBuffer()],
ORACLE_AGGREGATOR_PROGRAM_ID,
);
// Module 2 — NAV oracle
const [navOracle] = PublicKey.findProgramAddressSync(
[Buffer.from('nav-oracle'), mint.toBuffer()],
ORACLE_AGGREGATOR_PROGRAM_ID,
);
// Module 3 — Classification oracle
const [classificationOracle] = PublicKey.findProgramAddressSync(
[Buffer.from('classification-oracle'), mint.toBuffer()],
ORACLE_AGGREGATOR_PROGRAM_ID,
);
```
Full PDA registry in Network Configuration.
**Q: Can I build a frontend for ST22 tokens?**
Yes, but all trades must route through CEDEX. A custom frontend can display market data, portfolio information, and order history via the CEDEX API. However, the Transfer Hook ensures compliance regardless of which frontend is used — compliance is enforced at the Solana runtime level, not the application layer.
**Q: How do I handle Transfer Hook errors programmatically?**
```typescript
import { TransferHookError, isRetryable } from '@rwatokens/sdk';
try {
await client.cedex.placeOrder(params);
} catch (error) {
if (error instanceof TransferHookError) {
console.log(`Control ${error.controlId} failed: ${error.code}`);
console.log(`Module scope: ${error.moduleScope}`);
console.log(`Recoverable: ${isRetryable(error.code)}`);
if (error.code === 6024) {
console.log(`Regime: ${error.details.regime}`);
console.log(`Tokens locked until: ${error.details.unlockTimestamp}`);
}
if (error.code === 6020) {
console.log(`Reduce amount below: ${error.details.maxAllowed}`);
}
if (error.code === 6021 && error.details?.variant === 'nav_deviation') {
console.log(`NAV deviation: ${error.details.deviationBps} bps`);
console.log(`Tolerance: ${error.details.toleranceBps} bps`);
}
if (error.code === 6042 && error.details?.variant === 'federal_action') {
console.log(`Federal action references: ${error.details.actionReferences}`);
}
}
}
```
**Q: What is the Anchor IDL?**
The Anchor Interface Description Language files define the program instruction schemas, account types, and error codes. Available at:
```typescript
import { IDL as TransferHookIDL } from '@rwatokens/sdk/idl/transfer_hook';
import { IDL as AmmIDL } from '@rwatokens/sdk/idl/amm';
import { IDL as OracleAggregatorIDL } from '@rwatokens/sdk/idl/oracle_aggregator';
```
Or fetch directly from on-chain: `anchor idl fetch `.
**Q: How do I subscribe to real-time custody attestations?**
```typescript
const ws = new WebSocket('wss://api.cedex.market/ws/v1');
ws.send(JSON.stringify({ action: 'subscribe', channel: 'custody', mint: '7xK9p2...' }));
ws.onmessage = (event) => {
const msg = JSON.parse(event.data);
if (msg.discrepancyDetected) {
console.error('CUSTODY DISCREPANCY — all transfers halted');
}
};
```
Module 2 NAV oracle and Module 3 Classification oracle have dedicated channels (`nav` and `classification` respectively) — see CEDEX API Reference for full WebSocket channel listing.
***
### 5. Regulatory and Compliance
**Q: Are ST22 tokens securities?**
Yes. ST22 tokens are Category 5 Digital Securities under SEC Release No. 33-11412 (March 17, 2026). The platform embraces securities classification under Category 1 Model B — not an avoidance strategy.
**Q: What is Category 1 Model B?**
The SEC framework (January 28, 2026 Joint Staff Statement) for compliant tokenization where the issuer directly authorizes tokenization, DLT is used in official shareholder records, and a regulated custodian holds the backing assets. The platform satisfies all 7 requirements across all three modules.
**Q: Who handles investor verification?**
Empire Stock Transfer is the sole investor onboarding authority for all ST22 issuers across all three modules. Empire performs KYC (individuals), KYB (entities), AML (Chainalysis KYT + TRM Labs), OFAC/SDN screening, and wallet verification (KYW). Groovy Company, Inc. does not perform investor onboarding.
**Q: How does OFAC screening work?**
Three-layer screening on every transfer (not just at onboarding): Layer 1 — exact wallet address match. Layer 2 — fuzzy entity name matching. Layer 3 — 2-hop graph clustering (catches proxy wallets). The SDN list is refreshed hourly with emergency push capability.
**Q: What happens if my wallet gets flagged by OFAC after onboarding?**
Sanctions controls (SC-30 to SC-32) re-screen every wallet on every transfer. If your wallet is added to the SDN list after onboarding, your next transfer attempt is blocked immediately (Error 6003 or 6004). Contact .
**Q: What is the regulatory freeze (Control 42)?**
An immediate halt of all transfers on a specific mint, authorized by Legal Counsel + 3-of-5 multi-sig. Used for SEC enforcement actions, court orders, active exploit containment, OFAC emergency designations, or — for Module 3 — federal action under the federal-action variant. No timelock — executes immediately.
***
### 6. GROO Utility Token
**Q: Is GROO a security?**
No. GROO is a Utility Token — NOT an STO, NOT a security, NOT backed by shares. GROO and ST22 are distinct token classes with entirely different regulatory frameworks. GROO funds the Solana Treasury (which seeds the Global Pool). Under Release No. 33-11412, GROO is classified as either Category 1 (Digital Commodity) or Category 3 (Digital Tool) — explicitly not a security.
**Q: How is GROO different from the Groovy Security Token (STO)?**
| | GROO Utility Token | Groovy Security Token (STO) |
| ----------------- | ------------------------------------------------------------ | -------------------------------------------- |
| Classification | Utility token (Category 1 or Category 3) | Security (Common Class B share offering) |
| Issuer | Groovy Company, Inc. | Groovy Company, Inc. |
| Distribution | Deterministic linear bonding curve, starting at 0.000001 SOL | $20M Reg D raise |
| Purpose | Ecosystem utility (governance, staking, fee tiers) | Equity in the platform operator |
| Backed by shares? | No | Yes — Common Class B of Groovy Company, Inc. |
**Q: What does GROO do?**
GROO provides ecosystem utility: governance voting rights, staking rewards (1.5% of all CEDEX trading fees distributed to stakers), platform feature access tiers, and Solana Treasury funding (which seeds the Global Pool). It does not represent equity ownership in any company.
**Q: Can I stake GROO?**
Yes. GROO staking earns a share of the 1.5% staking allocation from all CEDEX trading fees. Staking tiers unlock additional platform features including fee discounts, enhanced analytics, and governance voting weight.
**Q: When does the GROO ICO happen?**
There is no ICO at launch. GROO distribution operates via a deterministic linear bonding curve starting at 0.000001 SOL. No pre-sale, no founder allocation, no treasury reserve. A Scale phase Dutch auction is governance-decided, not currently scheduled.
***
### 7. Module 2 — Real Estate Specifics
**Q: What is the NAV oracle?**
The NAV oracle is a Module 2-specific on-chain account holding the most recent appraised Net Asset Value for a Module 2 mint. Updated by an authorized appraiser at the per-mint reappraisal cadence. Ed25519 signed. Powers the CB-21 NAV-deviation circuit-breaker variant.
**Q: What is the NAV deviation tolerance?**
Default 22% (2200 basis points), configurable per mint at initialization. When the on-chain price deviates from the most recent NAV by more than the configured tolerance, transfers on the affected mint are blocked with Error 6021 (NAV variant). Trading resumes automatically when the deviation falls back within tolerance — typically after a fresh appraisal.
**Q: How often is NAV refreshed?**
The reappraisal cadence is set per mint in the SecurityConfig (`nav_reappraisal_max_age_secs`). Default cadence is 90 days, but the cadence is established by tripartite concurrence among three parties: the SAE issuer, the authorized appraiser, and Empire Stock Transfer. If the NAV oracle becomes stale beyond the configured threshold, transfers are paused until a fresh appraisal is published.
**Q: What is a single-asset entity (SAE)?**
A single-purpose legal entity (typically a Nevada corporation following a Nevada LLC → corporation conversion) holding a specific real-property asset. The SAE is the issuer of the Module 2 ST22 token. SAE equity is the underlying instrument backing the token; it is held in irrevocable custody at Empire Stock Transfer. Each Module 2 mint corresponds to one SAE corresponding to one underlying property.
**Q: Can a Module 2 mint have a higher per-wallet cap than the 4.99% default?**
Yes. Module 2 issuers may configure a per-wallet cap up to 9.99% when warranted by the underlying property's structure (for example, a smaller property where a single qualified institutional investor is appropriate). The cap is recorded in SecurityConfig at mint initialization and enforced by Control PL-16.
***
### 8. Module 3 — CORECM Specifics
**Q: What is the Classification oracle?**
The Classification oracle is a Module 3-specific on-chain account holding USGS Critical Minerals List status, DOE Critical Materials Strategy classification, Section 232 applicability, DPA Title III applicability, and federal-action active flag for a Module 3 mint. Updated by the authorized Classification relay monitoring USGS, DOE, and the Federal Register. Powers the REG-42 federal-action freeze variant.
**Q: What is the federal-action freeze?**
When the Classification oracle reports an active federal action affecting the basin asset (for example, a Section 232 designation, DPA Title III invocation, or executive-order-driven export restriction), transfers on the affected mint are automatically frozen within the platform's 60-minute SLA. Other Module 3 mints not subject to the same action remain tradeable. Trading resumes automatically when the action lifts.
**Q: What is a basin-asset entity (BAE)?**
A single-purpose legal entity holding a specific mineral basin or mining concession. The BAE is the issuer of the Module 3 ST22 token. BAE equity is the underlying instrument backing the token; it is held in irrevocable custody at Empire Stock Transfer. Each Module 3 mint corresponds to one BAE corresponding to one underlying basin asset.
**Q: What federal frameworks apply to Module 3?**
The platform tracks the following frameworks through the Classification oracle: USGS Critical Minerals List, DOE Critical Materials Strategy, Section 232 of the Trade Expansion Act of 1962, Defense Production Act (DPA) Title III, IRA critical minerals provisions, Executive Order 14017 on America's Supply Chains, and the Energy Act of 2020 (Title VII).
**Q: How are federal actions detected?**
The Classification relay monitors three primary upstream sources: USGS publications, DOE Critical Materials Strategy updates, and the Federal Register. When a federal action affecting an active basin asset is detected, the relay updates the on-chain Classification oracle. The Transfer Hook then reads the updated oracle on the next transfer and applies the federal-action freeze. Detection-to-freeze SLA: ≤60 minutes.
***
## Part 2 — Troubleshooting
***
### 9. Transfer Hook Error Code Reference
Every Transfer Hook error has a specific cause and resolution. When a transfer is rejected, the error code identifies exactly which control failed. Module-aware error variants (Module 2 NAV-deviation on 6021; Module 3 federal-action on 6042) surface through the `details.variant` field on the error.
#### Custody Errors (6001–6002)
| Code | Name | Cause | Resolution |
| -------- | -------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **6001** | `CustodyDiscrepancy` | Token supply exceeds the custodied balance held by Empire | **System-level.** All transfers halted automatically. Wait for 2-of-3 oracle consensus to resolve. This has never occurred in production. If you see this, a P0 incident is already in progress. |
| **6002** | `CustodyOracleUnavailable` | Ed25519 attestation stale (>1 Solana slot) | **Transient.** Retry after \~400ms (1 block). If persistent >30 seconds, the custody relay may be down — check system status at `status.cedex.market`. |
#### Sanctions and AML Errors (6003–6006)
| Code | Name | Cause | Resolution |
| -------- | -------------------- | ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **6003** | `SenderSanctioned` | Sender wallet matches OFAC SDN list | **Permanent.** Wallet is blocked. Contact if you believe this is a false positive. Resolution: 1–4 hours for false positives. |
| **6004** | `ReceiverSanctioned` | Receiver wallet matches SDN list or KYC/accreditation invalid | **Check:** If KYC-related, complete verification through the platform portal. If OFAC-related, contact compliance. |
| **6005** | `OfacOracleStale` | OFAC SDN list data older than staleness threshold | **System-level.** If >48h stale, all transfers halt. Check `status.cedex.market`. Usually resolves within minutes as the OFAC indexer refreshes. |
| **6006** | `AMLHighRisk` | AML risk score exceeds 70/100 | **Not automatically recoverable.** Your wallet has been flagged by Chainalysis KYT or TRM Labs. Contact for review. |
#### Holding Period Error (6024)
| Code | Name | Cause | Resolution |
| -------- | -------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **6024** | `TokensLocked` | Holding period not elapsed (Reg D 6mo / Reg S 12mo / Reg CF 12mo) | **Wait.** Check your unlock date and regime via the portfolio endpoint. This cannot be shortened or overridden. The CEDEX portfolio page shows your exact unlock date and countdown for each position. |
**How to check your holding period:**
```bash
curl -s https://api.cedex.market/v1/portfolio \
-H "Authorization: Bearer " | jq '.positions[].holdingPeriod'
```
The response includes `regime` (`'RegD'`, `'RegS'`, or `'RegCF'`), `unlockDate`, and `secondsRemaining` for each position.
#### Position Limit Errors (6020–6023)
| Code | Name | Cause | Resolution |
| -------- | --------------------- | ------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **6020** | `WalletLimitExceeded` | Post-transfer balance would exceed per-mint cap (4.99% default; up to 9.99% on some Module 2 mints) | **Reduce amount.** Calculate: `maxAllowed = totalSupply × (cap_bps / 10000) - currentBalance`. Read the cap from SecurityConfig.maxWalletPercent. |
| **6021** | `PriceImpactExceeded` | Single trade would move price >2% vs TWAP — **or, for Module 2, deviation from NAV exceeds tolerance** | **Split your order** into smaller trades. Each trade must cause <2% impact individually. **Module 2:** if `details.variant === 'nav_deviation'`, the price-NAV deviation has exceeded the configured tolerance — wait for a fresh appraisal or for the on-chain price to converge. |
| **6022** | `VelocityExceeded` | Exceeding 50 transactions/hour for this wallet | **Wait.** Slow down transaction frequency. Velocity window resets after the limit period. |
| **6023** | `CrossWalletDetected` | Behavioral clustering flagged coordinated activity | **Not automatically recoverable.** Your wallet has been flagged for coordinated trading patterns. Contact . |
#### Circuit Breaker Errors (6005, 6036–6038)
| Code | Name | Cause | Resolution |
| -------- | ------------------------- | -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| **6005** | `CircuitBreakerTriggered` | Price moved >10% in 5 minutes | **Wait 15 minutes.** Circuit breaker resets automatically when the TWAP normalizes. Check `cedex.market` for live status. |
| **6036** | `GlobalCircuitBreaker` | Platform-wide trading halt | **System-level.** All ST22 trading is paused. Activated by 3-of-5 multi-sig. Check `status.cedex.market` for updates and ETA. |
| **6037** | `DailySellLimitExceeded` | Single wallet sold >30% of circulating supply in 24h | **Wait 24 hours.** Your wallet-level daily sell limit has been reached. Other wallets are unaffected. |
| **6038** | `CustodyDiscrepancyHalt` | Custody discrepancy confirmed, awaiting oracle consensus | **System-level.** Trading halted for the affected mint. Incident response in progress. Check `status.cedex.market`. |
#### Emergency Errors (6039–6042)
| Code | Name | Cause | Resolution |
| -------- | --------------------- | ------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **6039** | `OFACEmergencyBlock` | Treasury emergency SDN designation matched your wallet | **Permanent.** Contact immediately. |
| **6040** | `OracleConsensusFail` | 2-of-3 oracle consensus not reached | **System-level.** Retry after a few minutes. If persistent, oracle services are being investigated. |
| **6041** | `ControlledMigration` | Smart contract upgrade in progress | **Temporary.** Wait for the upgrade to complete (typically <1 hour). Check `status.cedex.market`. |
| **6042** | `RegulatoryOverride` | Legal Counsel + 3-of-5 multi-sig regulatory freeze — **or, for Module 3, federal-action freeze** | **System-level.** Trading halted by regulatory authority. Duration varies by situation. **Module 3:** if `details.variant === 'federal_action'`, the freeze is automatic in response to a federal action affecting the basin asset; trading resumes automatically when the action lifts. |
#### CEI / Integrity Errors (6007–6019)
| Code | Name | Likely Cause | Resolution |
| -------- | -------------------- | ------------------------------------------------ | ------------------------------------------------ |
| **6007** | `InvalidSigner` | Transaction not signed by wallet owner | Verify you are signing with the correct wallet |
| **6008** | `WrongAccountOwner` | Account not owned by Token-2022 program | Verify you are using the correct token accounts |
| **6009** | `MintMismatch` | Source and destination reference different mints | Verify both accounts are for the same ST22 token |
| **6010** | `CorruptAccountSize` | Account data length unexpected | Account may be corrupted — contact support |
| **6014** | `ZeroTransfer` | Transfer amount is 0 | Amount must be greater than 0 |
| **6015** | `SelfTransfer` | Source and destination are the same wallet | Cannot transfer tokens to yourself |
| **6016** | `ArithmeticOverflow` | Internal calculation overflow | Reduce transfer amount and retry |
***
### 10. CEDEX Trading Issues
**My order was rejected before going on-chain.**
The CEDEX pre-flight compliance check rejected your order before submitting it to Solana. This saves you gas fees. The error response includes the specific control that failed and details about why. For Module 2 mints, the pre-flight also includes NAV-deviation and NAV-staleness checks. For Module 3 mints, the pre-flight includes Classification freshness and federal-action checks. Address the specific issue (see error code table above) and retry.
**My order shows "filled" but I don't see tokens.**
Check your Solana wallet (Phantom, Solflare, Backpack, Coinbase Wallet, Ledger) for the specific ST22 token. You may need to add the token mint address manually. Tokens appear after block finality (\~13 seconds / 32 confirmations).
**My limit order expired without filling.**
Limit orders execute only when the CPMM pool price reaches your specified price. If the market didn't reach your limit price before expiry, the order expires unfilled. No fees are charged for unfilled orders.
**Trading shows "Circuit Breaker Active."**
A circuit breaker has been triggered for this token. Wait for the cooldown period (15 minutes for price halt, 24 hours for volume halt). For Module 2 mints, a NAV-deviation circuit breaker may also be active — check the NAV oracle status. Circuit breakers reset automatically — no manual action needed.
**Trading on a Module 3 mint shows "Frozen — Federal Action Active."**
The Classification oracle has detected an active federal action affecting the basin asset (Section 232, DPA Title III, executive order, etc.). Transfers on the affected mint are automatically frozen until the action lifts. Other Module 3 mints not subject to the same action remain tradeable. Check `status.cedex.market` for the current federal-action reference and any ETA.
**I'm getting rate limited (429 errors).**
You are exceeding the API rate limit for your tier. Standard: 120 req/min, 30 orders/min. Verified (Empire KYC complete): 600 req/min, 120 orders/min. Reduce request frequency or contact developer support for institutional tier access.
***
### 11. Wallet and Connection Issues
**My wallet won't connect to CEDEX.**
Verify your wallet supports SPL Token-2022 (Phantom, Solflare, Backpack, Coinbase Wallet, Ledger). Ensure you are on Solana Mainnet-Beta (not devnet). Clear browser cache and retry. If using a hardware wallet (Ledger), ensure the Solana app is open and "blind signing" is enabled.
**I see my ST22 tokens in my wallet but can't trade.**
Your wallet must be registered with Empire Stock Transfer. Complete KYC/KYB through the platform portal. If already verified, your accreditation or KYC may have expired — check your verification status.
**My wallet shows 0 balance but I purchased tokens.**
The token may not be automatically added to your wallet display. Manually add the ST22 mint address in your wallet's "Add Token" feature. If balance is still 0, check the transaction on Solana Explorer using your wallet address.
**I lost my seed phrase / private key.**
Groovy Company, Inc. cannot recover your wallet. Solana wallets are self-custodial — only the seed phrase holder can access the wallet. Your underlying-equity ownership is recorded in Empire's Master Securityholder File, but without wallet access, you cannot trade your ST22 tokens. Contact Empire Stock Transfer to discuss share-level recovery options.
***
### 12. Oracle and System Issues
**Status page shows "Custody Oracle: Degraded."**
The custody oracle relay is experiencing latency. Transfers may be temporarily slower or rejected with Error 6002. This typically resolves within minutes. If transfers are halted, an incident is in progress — check `status.cedex.market` for updates.
**Status page shows "OFAC: Stale."**
The OFAC SDN list has not refreshed within the expected window. If stale <24h, trading continues on the cached list. If stale >48h, all transfers halt (Error 6005). The operations team is actively refreshing the oracle.
**Status page shows "NAV Oracle: Stale" (Module 2).**
The NAV oracle for one or more Module 2 mints has not been refreshed within the per-mint reappraisal cadence. Affected mints are paused until a fresh appraisal is published by the authorized appraiser. Other Module 2 mints with current appraisals are unaffected. Check `status.cedex.market` for the affected mints and expected resumption time.
**Status page shows "Classification Oracle: Stale" (Module 3).**
The Classification oracle for one or more Module 3 mints has not refreshed within the 24-hour staleness threshold. Trades on affected mints are flagged for enhanced review. The Classification relay is being investigated. Check `status.cedex.market` for the affected mints.
**Status page shows "Federal Action Active" (Module 3).**
A federal action has been detected on one or more Module 3 mints. Affected mints are frozen under Control 42 federal-action variant. Other Module 3 mints not subject to the same action remain tradeable. Trading resumes automatically when the action lifts. Check `status.cedex.market` for the federal-action reference and any ETA from the Incident Response Playbook §13 runbook.
**Status page shows "MEV Protection: Degraded."**
Jito Block Engine is unavailable. Trading continues but without private transaction submission — your trades are visible in the public mempool. Consider waiting for MEV protection to be restored before executing large orders. All other 42 controls remain active.
**Solana network is congested.**
During Solana congestion, transactions may fail with `TransactionExpiredBlockheightExceeded`. Retry with a higher priority fee. The SDK handles this automatically with exponential backoff (1s, 2s, 4s, up to 3 retries).
***
### 13. SDK and API Issues
**SDK: `@rwatokens/sdk` installation fails.**
```bash
# Verify Node.js 20+
node --version
# Clear npm cache
npm cache clean --force
# Install with explicit registry
npm install @rwatokens/sdk --registry https://registry.npmjs.org
```
**API: Authentication returns 401.**
Your bearer token has expired (24-hour lifetime). Complete the challenge/verify flow again:
```bash
# Step 1: Get challenge
curl -X POST https://api.cedex.market/v1/auth/challenge \
-H "Content-Type: application/json" \
-d '{"wallet": "YOUR_WALLET_ADDRESS"}'
# Step 2: Sign challenge with wallet and submit
curl -X POST https://api.cedex.market/v1/auth/verify \
-H "Content-Type: application/json" \
-d '{"wallet": "...", "challenge": "...", "signature": "..."}'
```
**API: Getting `EMPIRE_VERIFICATION_REQUIRED`.**
Your wallet has not completed Empire Stock Transfer KYC/KYB. Complete verification through the platform portal before accessing authenticated endpoints.
**SDK: `simulateTransfer` returns unexpected error.**
Ensure you are passing the correct mint address (base58), valid wallet addresses, and amount in raw units (with decimals applied). For a token with 9 decimals, 1.0 token = `1_000_000_000n` (BigInt). For module-aware error inspection, check the `controlResults` Map for the failing control and read its `details.variant` field — Module 2 NAV variants and Module 3 federal-action variants surface there.
**WebSocket: Connection drops frequently.**
Ensure your client responds to ping frames within 10 seconds. The server sends a ping every 30 seconds — if no pong is received, the connection is terminated. Implement automatic reconnection with exponential backoff.
```typescript
ws.onclose = () => {
setTimeout(() => reconnect(), Math.min(1000 * 2 ** retryCount, 30000));
};
```
**SDK: TypeScript types not resolving.**
```bash
# Ensure tsconfig.json includes:
{
"compilerOptions": {
"moduleResolution": "node",
"esModuleInterop": true,
"target": "ES2020"
}
}
```
***
### Quick Reference: Error Resolution
| Symptom | Most Likely Error | Action |
| ----------------------------------------------- | ------------------------------------------------ | ------------------------------------------------- |
| "Transfer failed" on sell | **6024** (TokensLocked) | Check holding period and regime — wait for unlock |
| "Transfer failed" on large buy (M1/M3) | **6020** (WalletLimit) | Reduce amount below 4.99% |
| "Transfer failed" on large buy (M2) | **6020** (WalletLimit) | Reduce amount below configured cap (up to 9.99%) |
| "Transfer failed" on large trade | **6021** (PriceImpact) | Split into smaller orders |
| **M2: "Transfer failed" — NAV deviation** | **6021** (NAV variant) | Wait for fresh appraisal or price convergence |
| All transfers failing for a token | **6001/6002** (Custody) | System issue — check status page |
| All transfers failing platform-wide | **6036** (GlobalBreaker) or **6042** (RegFreeze) | System issue — check status page |
| **M3: All transfers failing for a basin asset** | **6042** (federal-action variant) | Federal action active — wait for action to lift |
| "Not verified" on authenticated endpoint | `EMPIRE_VERIFICATION_REQUIRED` | Complete KYC through platform portal |
| Trade rejected before on-chain | Pre-flight compliance failure | Read error code in response |
| Wallet not showing tokens | Token not added to wallet | Add ST22 mint address manually |
| 429 Too Many Requests | Rate limit exceeded | Reduce request frequency |
| WebSocket disconnects | Missed pong | Implement ping/pong handler |
***
### Getting Help
| Channel | Use |
| --------------------- | ----------------------------------------------------------------------------------- |
| **Status page** | `status.cedex.market` — system health, active incidents, federal-action status (M3) |
| **Investor support** | — account, KYC, trading questions |
| **Issuer support** | — onboarding, tokenization, revenue (all three modules) |
| **Developer support** | — SDK, API, integration |
| **Compliance** | — OFAC flags, AML reviews, regulatory |
| **Security** | — vulnerability reports (NEVER in public issues) |
***
### Related Documentation
* **CEDEX API Reference** — Full API documentation with module-aware endpoints and error codes.
* **SDK Reference** — `@rwatokens/sdk` TypeScript SDK with module-aware methods and error handling patterns.
* **Smart Contract Reference** — Transfer Hook error code registry; module-aware program behavior.
* **Transfer Hook Reference** — Standalone reference for the 42 controls and module-aware extensions.
* **Issuer Onboarding Guide** — Issuer-specific questions across all three modules.
* **Compliance Integration Guide** — Regulatory framework, KYC/KYB/AML, federal frameworks (M3).
* **Oracle Integration Guide** — Custody, OFAC, AML, TWAP, EDGAR (M1), NAV (M2), Classification (M3).
* **Incident Response Playbook** — P0 through P3 runbooks; Module 3 federal-action freeze runbook (§13).
***
*RWA Tokens · FAQ and Troubleshooting · Groovy Company, Inc.*
# Competitive Analysis
## Competitive Analysis
**Digital Securities Market Positioning · ERC-3643 vs. ST22 · Securitize Benchmark · Three-Module Differentiation**
Standalone competitive intelligence for investors, the executive team, and institutional evaluators. This document compares the RWA Tokens platform — operated by Groovy Company, Inc. — against the tokenized securities landscape, focusing on Securitize as the primary institutional benchmark, ERC-3643 as the dominant token standard, and module-by-module competitive positioning across Module 1 (Equities), Module 2 (Real Estate), and Module 3 (CORECM — Carbon Ore, Rare Earth, and Critical Minerals).
***
### Table of Contents
1. Market Landscape
2. Securitize — Primary Benchmark
3. ERC-3643 vs. ST22 — Architecture Comparison
4. Broader Competitor Landscape
5. SWOT Analysis
6. Use Case Fit Matrix
7. Transaction Economics
8. Regulatory Positioning
9. Liquidity Model Comparison
10. Where Securitize Wins
11. Where the Platform Wins
12. Strategic Positioning
***
### 1. Market Landscape
#### 1.1 Tokenized Asset Market Size — Three-Module View
| Segment | Estimated Size | Primary Players | RWA Tokens Module |
| ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | -------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| Institutional RWA (BlackRock, Apollo, KKR) | $4B+ tokenized | Securitize, Ondo, Centrifuge | Outside platform scope — different market |
| Tokenized treasuries (T-bills, money market) | $2.5B+ AUM (BUIDL alone) | Securitize, Franklin Templeton, Ondo | Outside platform scope — different asset class |
| Tokenized large-cap equity (NYSE/NASDAQ S\&P 500) | Emerging | Dinari (DFN), partnership candidate | **Complementary** — Dinari serves Cat-2 large-cap; platform serves Cat-1 across three asset classes |
| **Equity securities — OTC microcap, NASDAQ, AMEX, TSX, global exchanges** | **\~$50B+ addressable across global exchanges** | Largely unserved at the microcap end | **Module 1 — Equities** |
| **Real estate equity (single-asset entity tokenization)** | **$280T+ global real estate market; addressable subset growing** | Fragmented (RealT, Lofty, Roofstock onChain) | **Module 2 — Real Estate** |
| **CORECM — Carbon Ore, Rare Earth, Critical Minerals supply chain** | **No public-chain platform; US strategic priority under EO 14017, IRA, Energy Act of 2020** | **No competitor** | **Module 3 — CORECM (true blue ocean)** |
#### 1.2 Why These Markets Are Underserved
Institutional tokenization platforms (Securitize, Ondo, Centrifuge) target premium-segment clients — BlackRock, KKR, Hamilton Lane. These platforms cannot economically serve the platform's three-module addressable surface because:
* **Gas economics.** $1–$50+ per Ethereum L1 transaction makes per-transfer compliance verification unaffordable for sub-$10M issuers (Module 1 microcap end), per-property tokenization at retail scale (Module 2), or basin-asset trading at the per-transaction granularity strategic-mineral provenance demands (Module 3).
* **Minimum capital.** Institutional platforms require $10M+ AUM to justify onboarding costs.
* **Compliance overhead.** Per-issuer compliance setup is identical whether the client is BlackRock ($2.5B BUIDL) or a Pink Sheets company ($500K market cap), a single Nevada LLC holding a $2M property, or a basin-asset entity holding a critical-minerals concession.
* **Market maker dependency.** Traditional tokenization requires dedicated market makers ($5K–$20K/month) — economically irrational across all three modules at scale.
* **No cross-module infrastructure.** No competing platform offers a single architecture that serves equities, real estate, and strategic-minerals tokenization with shared liquidity, shared compliance, and module-aware enforcement.
* **No federal-action coordination.** Module 3 specifically requires federal-action freeze coordination (Section 232, DPA Title III, EO-driven export restrictions) — a capability no other platform offers.
The platform is purpose-built to serve all three modules through one architecture. The Global Unified CEDEX Liquidity Pool eliminates the market maker requirement uniformly across modules. Solana's \~$0.00025 per transaction makes per-transfer compliance economically viable across the entire addressable surface. Empire Stock Transfer's existing 530+ company infrastructure provides the custody backbone for all three modules.
***
### 2. Securitize — Primary Benchmark
#### 2.1 Company Profile
| Attribute | Detail |
| ---------------- | ---------------------------------------------------------------------------- |
| Founded | November 2017 |
| Founders | Carlos Domingo, Jamie Finn |
| Headquarters | Miami, Florida |
| Funding | \~$147–200M across funding rounds |
| Valuation | $1.25B (SPAC merger with Cantor Equity Partners II, October 2025) |
| Expected listing | NASDAQ under ticker SECZ (H1 2026) |
| Key investor | BlackRock (Joseph Chalom on board) |
| Assets tokenized | $4B+ |
| Registrations | SEC-registered transfer agent, broker-dealer (Securitize Markets), ATS |
| Chains | Ethereum (primary), Solana, Polygon, Arbitrum, Avalanche, Aptos, Sei, Hedera |
| Token standard | ERC-3643 (T-REX) |
| Primary clients | BlackRock (BUIDL), Apollo, KKR, Hamilton Lane, VanEck |
#### 2.2 Securitize Registrations
| Registration | Scope |
| ---------------------------------- | ----------------------------------- |
| SEC transfer agent | Shareholder record management |
| Broker-dealer (Securitize Markets) | Securities distribution and trading |
| Alternative Trading System (ATS) | Secondary market venue |
| EU MiCA | European regulatory compliance |
#### 2.3 Securitize Architecture
Securitize operates as middleware on public blockchains:
```
ISSUER → Securitize Platform (compliance, KYC, issuance)
→ ERC-3643 token on Ethereum
→ Securitize Markets (ATS) for secondary trading
→ External ATS/exchanges (tZERO, INX) via partnerships
```
Key architecture characteristics:
* **Compliance at the application layer** — smart contract overlay on ERC-20, not runtime-enforced.
* **Admin override functions** — `forceTransfer()`, `freezePartialTokens()`, `recoveryAddress()` enable admin-initiated token movement without holder consent.
* **Multi-chain via deployment** — same ERC-3643 deployed per chain, no cross-chain native enforcement.
* **Centralized compliance decisions** — identity registry and compliance contract are admin-updateable.
* **Single-asset-class focus** — institutional tokenization of fund products and treasuries; no module-aware extensions for real estate NAV enforcement or strategic-minerals federal-action coordination.
#### 2.4 BlackRock BUIDL
BlackRock USD Institutional Digital Liquidity Fund (BUIDL) is Securitize's flagship product:
* Launched March 2024.
* $2.5B+ AUM — largest tokenized real-world asset fund.
* ERC-3643 on Ethereum.
* 1 BUIDL = $1.00 (daily accrual of US Treasury yield).
* Securitize Markets provides ATS trading.
* NYSE MOU (March 24, 2026) for potential NYSE-listed access.
#### 2.5 Key Securitize Partnerships
| Partner | Relationship | Significance |
| ----------------------------- | ----------------------------------------------------------- | --------------------------------------- |
| **BlackRock** | BUIDL fund. Joseph Chalom on Securitize board. | Crown jewel — institutional credibility |
| **Apollo** | Tokenized fund products | Alternative asset management |
| **KKR** | Tokenized fund distribution | PE distribution |
| **Hamilton Lane** | Tokenized private credit | Institutional private markets |
| **NYSE** | MOU for NYSE-listed access to tokenized assets (March 2026) | Traditional exchange integration |
| **Cantor Equity Partners II** | $1.25B SPAC merger | Public listing vehicle |
***
### 3. ERC-3643 vs. ST22 — Architecture Comparison
The reference framework for this section is **SEC–CFTC Release No. 33-11412** (March 17, 2026, binding) together with the **January 28, 2026 Joint Staff Statement on Tokenized Securities**. The Seven Pillars of Category 1 Model B (Issuer-Sponsored Tokenization) are the test grid. ST22 satisfies all seven natively at the Solana runtime; ERC-3643 satisfies three natively and bolts on the rest at the application layer — which is exactly the Category 2 (Third-Party Sponsored) failure mode the SEC named.
§3.1 walks the Seven-Pillar scorecard. §3.2 through §3.7 unpack the architectural and enforcement consequences.
#### 3.1 Seven-Pillar Category 1 Model B Scorecard
| # | Category 1 Model B Pillar | ERC-3643 (T-REX / Ethereum) | ST22 (SPL Token-2022 / Solana) |
| - | ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1 | **Direct Issuer Authorization** (board resolution authorizes mint) | ⚠️ **Off-chain only.** Tokeny-issued tokens commonly originate via a deployer wallet; board-resolution linkage lives in the legal stack, not the contract. | ✅ **On-chain.** Mint authority binds to the issuer's signed board resolution; Empire Stock Transfer onboarding gate refuses mint without filed Certificate of Designation. |
| 2 | **Official Shareholder Register on DLT** | ❌ **Not native.** Token ledger is ERC-20 balances. Reconciliation to a Master Securityholder File is an off-chain process. | ✅ **Native.** Empire MSF is the legal register; the on-chain SPL Token-2022 ledger is the *transfer notification layer* per W\.S. 34-29-101 et seq. Ed25519 attestation reconciles the two every Solana slot (\~400 ms). |
| 3 | **SEC §17A-Registered Qualified Custody** | ⚠️ **Possible but rare in deployments.** Most ERC-3643 stacks (Tokeny, Securitize, etc.) use crypto custodians (Fireblocks, BitGo, Anchorage) — not §17A-registered transfer agents. | ✅ **Architecturally required.** Empire Stock Transfer is the §17A custodian and the *sole* onboarding authority across all three modules. No mint exists without Empire holding the underlying equity 1:1 (Common Class B for M1, SAE equity for M2, BAE equity for M3). |
| 4 | **True Equity Backing (1:1)** | ⚠️ **Off-chain attestation.** Backing is asserted in offering documents; verification is auditor-driven and periodic. | ✅ **Cryptographic, continuous.** Custody oracle publishes Ed25519-signed attestation each slot. Transfer Hook **CV-04** halts every transfer if oracle is stale or backing ratio ≠ 1.000. |
| 5 | **Clear Ownership Chain / CUSIP** | ⚠️ **Off-chain mapping.** ONCHAINID is a wallet→identity map; CUSIP and DTC linkage are off-ledger. | ✅ **On-chain mapping.** Control **CV-05** rejects any transfer where the mint's bound asset identifier (CUSIP for M1; property ID for M2; basin ID for M3) fails to match the custodied class. |
| 6 | **Investor Protection (compliance enforcement at every transfer)** | ⚠️ **Application-layer.** Compliance lives in `Compliance.sol` + `IdentityRegistry.sol` overlays. The underlying ERC-20 `transfer()` function still exists. **A direct EVM call to the bare ERC-20 method bypasses the overlay.** This is the ERC-3643 bypass risk documented widely (and acknowledged in the T-REX architecture papers). | ✅ **Runtime-enforced.** SPL Token-2022 mandates Transfer Hook invocation by the Token-2022 *program itself*. There is no `transfer()` path that skips the hook — the runtime will reject the instruction. **42 controls plus module-aware extensions execute atomically; failure = atomic revert.** |
| 7 | **Token Standard Compliance (immutable, no admin override)** | ❌ **Upgradeable proxies + admin functions.** `forceTransfer()`, `freezePartialTokens()`, and proxy-upgrade authority give the issuer/operator unilateral power to move or seize holder tokens. | ✅ **Immutable post-deployment.** Once a Token-2022 mint is created with the Transfer Hook extension pointing at the platform's compliance program, the hook cannot be removed or repointed. No `forceTransfer` primitive. Regulatory freeze (Control 42) requires 3-of-5 multi-sig + Legal Counsel signoff and is bounded to halt-only — it cannot move tokens. |
**Native score: ST22 = 7/7. ERC-3643 = 3/7** (Pillars 1, 3, and 5 *can* be satisfied with disciplined off-chain process; Pillars 2, 4, 6, 7 cannot be satisfied by the standard itself — they require external assertion).
#### 3.2 Summary
| Attribute | ERC-3643 (T-REX / Ethereum) | ST22 (CEDEX / Solana) |
| ------------------------ | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| Market adoption | $32B+ tokenized assets, 8+ years | Emerging; Category 1 Model B pioneer |
| Token standard | ERC-20 + compliance overlay contracts | SPL Token-2022 native Transfer Hooks |
| Compliance enforcement | Application-layer (ONCHAINID + registries) | **Runtime-enforced** (42 controls in Solana runtime + module-aware extensions) |
| Module-aware enforcement | Not supported | **Module 2 NAV-deviation enforcement; Module 3 federal-action freeze coordination — runtime-enforced** |
| Bypass risk | **Yes** — direct EVM `transfer()` bypasses overlay | **No** — hooks execute on every path |
| Admin override | **Yes** — `forceTransfer()`, `freezePartialTokens()` | **No** — Groovy Company cannot move tokens without holder consent |
| Transaction speed | 12–15s (L1), seconds (L2) | \~400ms finality |
| Transaction cost | $1–$50+ (L1), \~$0.01 (L2) | \~$0.00025 |
| Liquidity model | External DEX/ATS, issuer-deployed pools | Global Pool — protocol-owned, permanently locked, shared across all three modules |
| Regulatory posture | EU MiCA compatible, SEC varying | SEC Category 1 Model B, Release No. 33-11412; Reg D + Reg S + Reg CF |
| Holding-period regimes | Smart contract + admin enforcement | On-chain Control HP-24 — Reg D / Reg S / Reg CF immutable timers |
| Upgrade path | Upgradeable proxy contracts | **Immutable** Transfer Hook controls; module-aware extensions cannot be removed (Certora E.4) |
| Multi-chain | Native EVM + L2 deployments | Solana primary; cross-chain roadmap |
| Formal verification | Varies by deployment | Certora Prover — 6 invariants covering all three modules |
#### 3.3 ERC-3643 Five-Component Architecture
| Component | Function | Vulnerability |
| ---------------------------- | ---------------------------------- | --------------------------------------------------------------------- |
| **T-REX Token** | ERC-20 + compliance hooks | Compliance hooks are application-layer — direct `transfer()` bypasses |
| **ONCHAINID** | ERC-734/735 decentralized identity | Off-chain dependency for claim verification |
| **Identity Registry** | Maps wallets to identities | Admin-updateable — registry manipulation risk |
| **Compliance Contract** | Enforces transfer rules | Admin-upgradeable via proxy — compliance logic can change |
| **Trusted Issuers Registry** | Validates identity claim issuers | Admin-updateable — issuer list can be modified |
#### 3.4 ST22 Enforcement Architecture
| Component | Function | Security Property |
| ----------------------------------- | ----------------------------------------------------------- | ------------------------------------------------- |
| **Transfer Hook** | 42 controls plus module-aware extensions on every transfer | Runtime-enforced — no bypass path exists |
| **SecurityConfig** | Per-mint parameters; module-aware extension fields | PDA — deterministic, on-chain |
| **CustodyOracle** | Ed25519 Empire attestation per block | Cryptographic — signature required |
| **NAVOracle (Module 2)** | Per-mint NAV with deviation tolerance enforcement | Ed25519 signed by authorized appraiser |
| **ClassificationOracle (Module 3)** | USGS / DOE / federal-action status | Ed25519 signed by authorized Classification relay |
| **HoldingPeriodAccount** | Per-investor holding lock across Reg D / Reg S / Reg CF | On-chain timer — cannot be shortened |
| **Global Pool** | Protocol-owned liquidity, single shared pool across modules | **Immutable** — no withdrawal function |
#### 3.5 The Bypass Problem — Pillar 6, Concretely
This is the architectural distinction the SEC Crypto Task Force is most attuned to, and the one that determines whether a tokenization stack maps natively to Category 1 or to Category 2.
**ERC-3643 enforcement model:**
```
User → T-REX Token contract → calls Compliance + IdentityRegistry → conditional transfer
↑
BUT: ERC-20.transfer() inherited from OpenZeppelin still exists.
A caller with token-balance access can invoke transfer() directly,
bypassing the Compliance contract entirely.
```
ERC-3643 mitigates this by overriding `transfer()` to revert without compliance approval — but the override is *contract code*, and any upgrade to the proxy or any deployment that forgets the override re-opens the path. Tokeny's own audits (Hacken, Kaspersky) flag this as a governance / code-quality risk rather than an architectural guarantee.
**ST22 enforcement model:**
```
User → Solana Token-2022 program → REQUIRED CPI to Transfer Hook → 42 controls + module-aware extensions → conditional transfer
↑
The Token-2022 program is part of the Solana runtime.
It refuses to process a transfer instruction on a hook-extended mint
without invoking the registered hook program. There is no bypass instruction.
```
The hook invocation is enforced by the Solana runtime itself, not by application code that could be overridden. **It is closer in nature to an OS system call than to a smart-contract function.** This is what allows Pillar 6 ("compliance on every transfer, no exceptions") to be a *property of the protocol* rather than a *property of the developer's discipline*.
The same pseudocode comparison written more directly:
```
ERC-3643 (Ethereum):
wallet.call(token.transfer(to, amount))
→ IF called through T-REX contract: compliance checked ✓
→ IF called through direct EVM transfer(): compliance BYPASSED ✗
→ The compliance layer is an overlay — not the token itself
ST22 (Solana):
wallet.call(spl_token_2022.transfer(to, amount))
→ Token-2022 program AUTOMATICALLY invokes Transfer Hook via CPI
→ Transfer Hook executes ALL 42 controls + applicable module-aware extensions
→ NO BYPASS PATH — hook is part of the token standard
→ The compliance layer IS the token standard
```
#### 3.6 The Admin Override Problem — Pillar 7, Concretely
The SEC Joint Staff Statement (January 28, 2026) explicitly warns that **Category 2 (Third-Party Sponsored)** tokenization carries counterparty risk because the operator can move or freeze holder property. ERC-3643 reproduces this risk *inside* a Category 1 wrapper.
| Function | ERC-3643 (T-REX) | ST22 |
| ----------------------------------------------- | --------------------------------------------------- | -------------------------------------------------------------------------------- |
| Force-transfer holder tokens | `forceTransfer(from, to, amount)` — **exists** | **Does not exist.** No instruction in the program. |
| Freeze partial balance | `freezePartialTokens(account, amount)` — **exists** | Halt-only via Control 42; cannot move tokens. |
| Upgrade compliance logic without holder consent | Yes — proxy upgrade by admin | No — Transfer Hook program ID is bound to mint at creation; cannot be repointed. |
| Mint additional tokens | Subject to `mintAuthority`, often a hot wallet | Mint authority requires Empire co-signature plus the platform 3-of-5 multi-sig |
| Redirect to recovery address | `recoveryAddress()` — **exists** | **Does not exist** — no recovery address mechanism |
| Modify who is verified | `updateIdentityRegistry()` — **exists** | Empire verification is external — not modifiable by Groovy Company |
**Practical example.** In June 2024 Tokeny published a feature article describing how `forceTransfer` was used by an issuer to "recover" tokens from a hacked investor wallet. From a compliance-architecture standpoint, that capability is the *exact attribute* Release No. 33-11412 names as creating Category 2 counterparty risk: the operator demonstrably can move tokens without the holder's signature. Whether or not the use case is benign is irrelevant — the *capability exists*, and its existence triggers the regulatory characterization.
ST22 cannot do this because the instruction is not in the compliance program. The investor's wallet signature is the *only* path to debit the token account.
#### 3.7 Module-Aware Extensions ERC-3643 Cannot Replicate
The platform's module-aware extensions create an additional layer of architectural differentiation that ERC-3643 cannot easily replicate without abandoning its application-layer compliance model.
| Extension | Module | What It Enforces | Why ERC-3643 Cannot Match Natively |
| -------------------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **NAV-deviation enforcement (CB-21 NAV variant)** | Module 2 | Trade rejected if on-chain price exceeds NAV by configured tolerance (default 22%) or if NAV oracle stale beyond reappraisal cadence | NAV oracle reads + deviation math at every transfer would be cost-prohibitive on Ethereum L1; ERC-3643 has no native NAV-bound enforcement primitive |
| **Federal-action freeze (REG-42 federal variant)** | Module 3 | Automatic 60-minute SLA freeze on detection of Section 232 / DPA Title III / EO-driven federal action affecting basin asset | ERC-3643 has no native federal-action coordination; admin-driven freezes via `freezePartialTokens` lack the SLA, the per-mint isolation, or the automatic resumption when action lifts |
| **Per-module holding regimes** | All | Reg D (6mo) / Reg S (12mo) / Reg CF (12mo) enforced per-investor on-chain via HoldingPeriodAccount | ERC-3643 deployments typically enforce one regime per mint; multi-regime per-mint enforcement requires significant overlay-contract complexity |
| **Tripartite concurrence governance** | Module 2 | Per-mint NAV bounds and reappraisal cadence require concurrence among SAE issuer + appraiser + Empire Stock Transfer | ERC-3643 governance is admin-controlled, not multi-party-concurrence-enforced at the protocol layer |
#### 3.8 Where ERC-3643 Actually Wins on Category Fit
To be fair, ERC-3643 has two real advantages relevant to the Release No. 33-11412 framework:
1. **ONCHAINID portability (ERC-734 / 735).** Verifiable credentials follow the investor across issuers without re-KYC. ST22 currently re-onboards through Empire per issuer (acceptable for §17A but operationally heavier).
2. **MiCA compatibility.** ERC-3643 is purpose-built for the EU framework; the SEC framework is closer to MiCA than to Howey, and the institutional vocabulary (BlackRock, Hamilton Lane, Société Générale deployments) is already aligned.
Neither overcomes the Pillar 6 / Pillar 7 architectural gap, but both matter for cross-border and institutional positioning — which is why the cross-chain roadmap evaluates an ERC-3643 wrapper for ST22 representation on EVM, not the reverse.
#### 3.9 Bottom Line
ERC-3643 is a **compliance-by-convention** standard: the rules are in contracts the issuer chooses to deploy and chooses not to override. ST22 is a **compliance-by-runtime** standard: the rules are in the chain itself, and there is no path that does not execute them.
Under Release No. 33-11412 the distinction is binary — either the DLT *is* the official register (Category 1 Model B), or the DLT *mirrors* an off-chain register (Category 2). Application-layer overlays cannot satisfy "DLT in official shareholder records" because the SEC explicitly defined that pillar as runtime-level integration. **That is why ERC-3643 maps natively to Category 2 and ST22 maps natively to Category 1 Model B.**
#### 3.10 Authoritative References
* SEC–CFTC **Release No. 33-11412** (March 17, 2026) — binding Five-Category Taxonomy; defines Category 1 Model B.
* **SEC Joint Staff Statement on Tokenized Securities** (January 28, 2026) — Category 1 vs. Category 2 distinction.
* **SEC Staff Statement on Covered User Interface Providers** (April 13, 2026) — runtime-enforcement weight in compliance.
* **Solana SPL Token-2022 specification** + `spl-transfer-hook-interface` v0.6+ — runtime-level hook semantics.
* **ERC-3643 Specification** (EIP-3643, Final, December 2023) + Tokeny T-REX whitepaper — five-component application-layer architecture.
* **Wyoming Digital Asset Statute** (W\.S. 34-29-101 et seq.) — DLT as legally effective transfer notification.
* **SEC v. Telegram**, 448 F. Supp. 3d 352 (S.D.N.Y. 2020) — "compliance dependent on issuer good faith" as enforcement risk.
***
### 4. Broader Competitor Landscape
#### 4.1 Tokenized Securities Platforms — Equities
| Platform | Token Standard | Chain | Focus | Registrations | Differentiator |
| ---------------- | --------------------- | ----------------- | -------------------------------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| **Securitize** | ERC-3643 | Ethereum + multi | Institutional RWA | Transfer agent, BD, ATS, MiCA | BlackRock BUIDL, institutional relationships |
| **tZERO** | Proprietary | Ethereum | ATS trading | BD, ATS | Early STO platform, Overstock backing |
| **Polymath** | ERC-1400 | Ethereum | Token creation | — | Polymesh (dedicated chain, now pivoting) |
| **Tokeny** | ERC-3643 | Ethereum | Enterprise tokenization | EU-focused | ERC-3643 standard creators |
| **INX** | Proprietary | Ethereum | Regulated exchange | BD, ATS | SEC-registered token offering |
| **Republic** | Varies | Multi | Retail investment | BD, crowdfunding | Retail access, Reg CF / A+ |
| **Dinari (DFN)** | Proprietary | Multi-chain | NYSE / NASDAQ large-cap (Cat-2) | — | **Complementary positioning** — large-cap focus distinct from platform's three-module Cat-1 scope |
| **Ondo Finance** | Proprietary | Ethereum + Solana | Tokenized treasuries | — | USDY, treasury yield on-chain |
| **Centrifuge** | Proprietary | Ethereum + Base | Real-world credit | — | Tinlake protocol, MakerDAO integration |
| **RWA Tokens** | **ST22 (Token-2022)** | **Solana** | **Equities (M1) + Real Estate (M2) + CORECM (M3)** | **Empire §17A custody; FINRA-registered funding portal partnership for Reg CF** | **42 immutable controls + module-aware extensions, Global Pool, Category 1 Model B** |
#### 4.2 Real Estate Tokenization — Module 2 Context
| Platform | Approach | Module 2 Comparison |
| --------------------------- | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| **RealT** | Fractionalized rental property tokens (Ethereum) | No NAV oracle; no deviation tolerance enforcement at the token layer; no SAE-equity custody at a §17A-registered transfer agent |
| **Lofty** | Real estate tokens (Algorand) | No multi-regime holding period; no shared-pool liquidity model; no SEC Category 1 framing |
| **Roofstock onChain** | Whole-property NFTs | Different model entirely — single-property NFTs vs SAE-equity tokenization with secondary market |
| **Tangany / Ondo / others** | Various pilots | No platform integrates Module 2 NAV-deviation enforcement, Reg D / Reg S / Reg CF per-investor regimes, and a shared cross-module liquidity pool |
#### 4.3 Critical Minerals / CORECM — Module 3 Context
No competitor offers a public-chain platform for tokenizing US strategic-minerals supply chain assets with on-chain federal-action coordination. The intersection of (a) Solana SPL Token-2022 runtime enforcement, (b) ClassificationOracle integration with USGS / DOE / Federal Register, and (c) automatic Control 42 federal-action freeze with 60-minute SLA is unique. Module 3 represents true blue-ocean positioning.
#### 4.4 Why None Address the Platform's Three-Module Surface
| Competitor | Why They Cannot Cover the Platform's Surface |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Securitize | Gas economics ($1–$50+/tx). Minimum AUM too high. No permanent liquidity. No NAV-deviation enforcement (Module 2). No federal-action coordination (Module 3). |
| tZERO | Limited to ATS-listed tokens. No self-reinforcing liquidity pool. Low volume. Single asset class. |
| Polymath | Pivoted to Polymesh chain. No permanent liquidity solution. Limited traction. Single asset class. |
| Tokeny | Enterprise-focused, EU regulatory alignment. No US regulatory infrastructure. Single asset class. |
| INX | Small ATS. No permanent liquidity. Limited issuer onboarding infrastructure. Single asset class. |
| Dinari (DFN) | Large-cap focus (Cat-2), complementary to platform's Cat-1 three-module scope; partnership candidate, not direct competitor |
| Ondo | Treasury yield products only. Not equity tokenization. Not real estate. Not strategic minerals. |
| Centrifuge | Credit / lending products. Not equity tokenization. Not real estate. Not strategic minerals. |
| RealT / Lofty / Roofstock onChain | Real estate only, no §17A custody integration, no deviation tolerance enforcement, no shared-pool liquidity, no other modules |
***
### 5. SWOT Analysis
#### 5.1 RWA Tokens Platform
| Category | Detail |
| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **S — Runtime enforcement** | Transfer Hook executes inside Solana runtime — no application-layer bypass |
| **S — 42 immutable controls + module-aware extensions** | Cannot be weakened by upgrade, governance, or admin action; Certora E.4 protects module-aware extensions |
| **S — Three-module architecture** | Equities, Real Estate, and CORECM served through one architecture with shared liquidity, shared compliance, and module-aware enforcement |
| **S — Module 2 NAV enforcement** | Real estate tokenization with on-chain NAV-deviation tolerance enforcement — no other platform offers this |
| **S — Module 3 federal-action coordination** | Strategic-minerals tokenization with automatic federal-action freeze and 60-minute SLA — no other platform offers this |
| **S — Transaction economics** | \~$0.00025/tx enables per-transfer compliance for any market cap, any module |
| **S — \~400ms finality** | Real-time settlement + per-block custody attestation |
| **S — Integrated exchange** | CEDEX = standard + exchange + permanent liquidity in one architecture |
| **S — Permanent liquidity** | LP tokens burned — withdrawal mathematically impossible; single shared pool serves all three modules |
| **S — Category 1 Model B** | Built for Release No. 33-11412 compliance from inception across all three modules |
| **S — Empire custody** | SEC §17A-registered, Ed25519 attestation every \~400ms; covers Common Class B (M1), SAE equity (M2), BAE equity (M3) |
| **S — Reg D / Reg S / Reg CF triple coverage** | All three offering exemptions natively supported with per-investor on-chain enforcement |
| **W — Newer standard** | Less institutional track record than ERC-3643's 8+ years and $32B+ |
| **W — Solana-only initially** | Cross-chain requires Phase 2+ roadmap execution |
| **W — DEX incompatibility** | Raydium / Orca / Jupiter don't support Transfer Hooks — requires CEDEX |
| **W — Single exchange** | All secondary trading routes through CEDEX until multi-venue expansion |
| **W — Module 2 / Module 3 launch posture** | Modules 2 and 3 are launch-phase; institutional track record will accumulate post-launch |
| **O — Multi-module addressable market** | Equities (microcap and global exchanges) + real estate ($280T+ global market) + critical minerals (US strategic priority under EO 14017, IRA, Energy Act of 2020) |
| **O — SEC regulatory clarity** | Release No. 33-11412 provides binding federal framework |
| **O — Federal critical-minerals priority** | Module 3 aligns with Section 232, DPA Title III, IRA, EO 14017 — US strategic-policy tailwind |
| **O — Foreign exchange equity expansion** | Global equity tokenization across NASDAQ, AMEX, TSX, and foreign exchanges within Module 1 |
| **O — White-label infrastructure** | Institutions needing compliant tokenization infrastructure across multiple asset classes |
| **O — Dinari partnership** | Complementary asset-class coverage (large-cap Cat-2) creates joint regulatory positioning opportunity |
| **T — ERC-3643 institutional dominance** | Institutional investors and custodians know ERC-3643 — ST22 requires education |
| **T — Solana network risk** | Historical outages (pre-2023) remain a reputation factor |
| **T — Securitize partnerships** | BlackRock / Apollo / KKR relationships create institutional gravity |
| **T — Regulatory change** | SEC policy change could affect Category 1 framework |
#### 5.2 Securitize
| Category | Detail |
| -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| **S — Institutional relationships** | BlackRock, Apollo, KKR, Hamilton Lane — unmatched institutional credibility |
| **S — Regulatory registrations** | Transfer agent, broker-dealer, ATS, EU MiCA — broadest coverage |
| **S — Market adoption** | $4B+ tokenized, $2.5B BUIDL, $1.25B SPAC valuation |
| **S — Multi-chain** | Ethereum + Solana + Polygon + Arbitrum + Avalanche + others |
| **S — ERC-3643 standard** | $32B+ deployed, 8+ years, EIP Final status |
| **W — Application-layer compliance** | Bypassable via direct EVM transfer — structural vulnerability |
| **W — Admin overrides** | `forceTransfer()` creates centralization risk |
| **W — Gas costs** | $1–$50+ on Ethereum L1 — prohibitive for mid-market |
| **W — No permanent liquidity** | Securitize Markets ATS has limited secondary volume |
| **W — Trading suspension history** | Platform-controlled trading halts expose investors to centralized risk |
| **W — Single asset-class focus** | Institutional fund and treasury products; no native real estate NAV enforcement, no native critical-minerals federal-action coordination |
| **O — NYSE MOU** | Traditional exchange access for tokenized assets |
| **O — EU expansion** | MiCA license opens European institutional market |
| **T — Category 2 classification risk** | SEC may classify middleware-on-public-chains as Category 2 (counterparty risk) |
| **T — Competing L1s** | Non-EVM chains (Solana, Aptos) threaten Ethereum lock-in |
| **T — Module-aware platforms** | Multi-asset-class platforms with native module-aware enforcement (NAV, federal-action) raise the architectural bar |
***
### 6. Use Case Fit Matrix
| Use Case | ERC-3643 (Securitize) | ST22 (RWA Tokens) | Winner |
| ------------------------------------------------------------------- | -------------------------------------------------- | ------------------------------------------------------------------------------------ | ---------------------- |
| BlackRock-scale institutional fund ($1B+) | Established, proven, regulatory comfort | No institutional track record yet | **ERC-3643** |
| Tokenized US Treasury yield | BUIDL ($2.5B), mature | Not applicable (equity / real estate / minerals, not treasuries) | **ERC-3643** |
| EU-regulated tokenization (MiCA) | Licensed and operational | No EU presence | **ERC-3643** |
| **Equity tokenization — OTC microcap to global exchange** | Economically unviable below \~$10M cap | **Purpose-built** — Module 1; Global Pool; $0.00025/tx | **ST22** |
| **Real estate tokenization with NAV-deviation enforcement** | No native NAV-bound enforcement; admin-driven only | **Purpose-built** — Module 2 NAV oracle + 22% deviation tolerance | **ST22** |
| **Critical-minerals tokenization with federal-action coordination** | No equivalent capability | **Purpose-built** — Module 3 Classification oracle + 60-minute federal-action freeze | **ST22 (uncontested)** |
| 24/7 secondary trading with permanent liquidity | ATS with limited hours and volume | CEDEX 24/7, LP burned, protocol-owned, shared across modules | **ST22** |
| Anti-rugpull guarantee | Admin overrides exist | Mathematically impossible — no withdrawal function | **ST22** |
| Per-transfer compliance verification | Gas cost prohibitive at L1 | $0.00025 per verified transfer across all three modules | **ST22** |
| Real-time custody attestation | Periodic (not per-block) | Ed25519 every \~400ms, cross-module | **ST22** |
| Multi-regime per-investor holding period (Reg D + Reg S + Reg CF) | Typically one regime per mint | Native per-investor regime via HoldingPeriodAccount | **ST22** |
| Cross-chain institutional custody (Fireblocks / BitGo) | Mature EVM integration | Solana custody emerging | **ERC-3643** |
| Foreign-exchange equity tokenization (NASDAQ, AMEX, TSX, global) | Limited; EU MiCA covers some | Module 1 covers all global exchanges | **ST22** |
***
### 7. Transaction Economics
| Metric | ERC-3643 (Ethereum L1) | ERC-3643 (L2) | ST22 (Solana) | Advantage |
| --------------------------------------------------- | ----------------------------- | ---------------------------- | ------------------------------------------------------------------------ | ------------------------------- |
| Base transfer fee | $1–$50+ | \~$0.01 | **\~$0.00025** | ST22: 4,000× – 200,000× cheaper |
| Compliance verification cost | $5–$50 (gas for oracle reads) | \~$0.05 | **\~$0.001** | ST22: 50× – 50,000× cheaper |
| Settlement finality | 12–15 seconds | 2–15 seconds | **\~400ms** | ST22: 30× – 37× faster |
| Throughput | \~15 TPS | 100–4,000 TPS | **400–600 TPS** (compliance-verified) | Comparable to L2 |
| Custody attestation frequency | Periodic (minutes – hours) | Same as L1 (separate chain) | **Every block (\~400ms)** | ST22: real-time |
| Module-specific oracle reads (NAV / Classification) | Cost-prohibitive at L1 | Possible at L2 with overhead | **Native — included in CU budget** | ST22: structurally enabled |
| Platform fee (secondary) | 0.5–2% (ATS dependent) | Same | **5%** (includes 42 controls + module-aware extensions + permanent pool) | — |
#### Economic Viability by Market Cap and Module
| Issuer Profile | ERC-3643 Viable? | ST22 Viable? |
| ----------------------------------------------- | ------------------------------------ | -------------------------------- |
| $1B+ institutional fund | Yes — gas is rounding error | Yes |
| $100M – $1B equity issuer | Marginal — gas meaningful | Yes |
| $10M – $100M equity issuer | Difficult — gas erodes returns | **Yes (Module 1)** |
| $1M – $10M microcap issuer | **Not viable** | **Yes (Module 1)** |
| <$1M issuer | **Not viable** | **Yes (Module 1)** |
| Single-asset real estate entity (per-property) | **Not viable** at L1 | **Yes (Module 2)** |
| Basin-asset entity with federal-action exposure | **No federal-action infrastructure** | **Yes (Module 3) — uncontested** |
The platform's transaction economics make per-transfer compliance verification viable across the entire three-module addressable surface. This is the fundamental economic argument for why the platform's market cannot be served by Ethereum-based platforms at scale.
***
### 8. Regulatory Positioning
#### 8.1 SEC Framework Comparison
| Framework Element | Securitize | RWA Tokens |
| --------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Primary SEC engagement | Crypto Task Force submission (Oct 2025) | Crypto Task Force direct meetings + no-action letter |
| Classification | Varies by product | Category 5 Digital Securities (Release No. 33-11412) |
| Category 1 vs Category 2 | Could be classified Category 2 (middleware on public chains) | **Category 1 Model B** (issuer-sponsored, DLT in official records) — applies across all three modules |
| Compliance enforcement | Application-layer (admin-controllable) | Runtime-enforced (42 immutable controls + module-aware extensions) |
| Custody | Own transfer agent registration | Empire Stock Transfer — §17A qualified custodian; covers Common Class B (M1), SAE equity (M2), BAE equity (M3) |
| Admin override | `forceTransfer()` exists | No admin override — mathematical enforcement |
| Holding period | Smart contract + admin enforcement; typically single regime | On-chain Control HP-24 — Reg D / Reg S / Reg CF immutable timers |
| Regulatory freeze | Admin function | Control 42 — Legal Counsel + 3-of-5 multi-sig; **Module 3: automatic federal-action variant with 60-minute SLA** |
| Module 3 federal frameworks | Not addressed | USGS Critical Minerals List, DOE Critical Materials Strategy, Section 232, DPA Title III, IRA, EO 14017, Energy Act of 2020 — all surfaced through Classification oracle |
#### 8.2 Category 1 vs Category 2 Risk
The January 28, 2026 Joint Staff Statement distinguishes:
| Dimension | Category 1 (RWA Tokens) | Category 2 Risk (Securitize potential) |
| ----------------------- | ----------------------------------------------------------- | -------------------------------------- |
| Issuer relationship | Direct — board resolution required | Third-party sponsored (middleware) |
| Counterparty risk | None — direct ownership via Empire across all three modules | Platform intermediary holds tokens |
| Compliance control | Issuer cannot bypass | Admin override functions exist |
| DLT in official records | Empire MSF + Solana blockchain | Public chain + off-chain registry |
Securitize's admin override functions (`forceTransfer()`) could expose it to Category 2 classification risk — where a platform intermediary maintains control over investor tokens. The platform's architecture eliminates this risk by making admin overrides structurally impossible across all three modules.
***
### 9. Liquidity Model Comparison
| Attribute | Securitize (ATS) | RWA Tokens (CEDEX) |
| ----------------------------- | ---------------------------------------- | ---------------------------------------------------------------------------------------- |
| **Venue type** | Alternative Trading System | Custom AMM + Compliant Exchange |
| **Trading hours** | Limited (ATS-dependent) | **24/7/365** |
| **Liquidity source** | Market makers (can withdraw) | **Global Pool — LP burned, protocol-owned** |
| **Cross-asset-class pooling** | Per-product, isolated | **Single pool serves all three modules — Equities, Real Estate, CORECM** |
| **Rugpull risk** | Market maker withdrawal possible | **Mathematically impossible** |
| **Per-issuer dependency** | Each issuer needs dedicated market maker | **Shared pool — no per-issuer market maker needed across modules** |
| **Market maker cost** | $5K – $20K/month | **$0** |
| **Liquidity growth** | Depends on market maker commitment | **Self-reinforcing — 0.44% of every trade across all modules deepens pool** |
| **Network effect** | Limited — each issuer isolated | **Strong — more issuers across more modules → deeper pool → better prices for everyone** |
| **Formal verification** | N/A | Certora E.3 — pool non-extractability proved |
***
### 10. Where Securitize Wins
| Advantage | Detail | Platform Counter-Strategy |
| ------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Institutional relationships** | BlackRock, Apollo, KKR, Hamilton Lane on platform | The platform targets different market segments (Module 1 microcap, Module 2 real estate, Module 3 critical minerals) — not competing for the same institutional fund clients. |
| **Regulatory registrations** | Transfer agent, BD, ATS, EU MiCA — broadest regulatory footprint | Empire Stock Transfer §17A covers custody and onboarding across all three modules. No-action letter for CEDEX pending. FINRA-registered funding portal partnership for Reg CF. |
| **Market adoption** | $4B+ tokenized, $1.25B valuation | The platform is launch-phase. Multi-module addressable market thesis offsets this through addressable surface size. |
| **Multi-chain** | 8+ chains deployed | Solana-only initially. Cross-chain roadmap Phase 2 (Wormhole NTT, Dinari DFN partnership candidate). |
| **ERC-3643 standard adoption** | $32B+ tokenized, 8+ years, EIP Final | ST22 is newer but architecturally superior (runtime enforcement, module-aware extensions). Market education required. |
| **EU presence** | MiCA license, European institutional clients | No EU presence. Phase 3 expansion target. |
***
### 11. Where the Platform Wins
| Advantage | Detail | Securitize Weakness |
| ---------------------------------------- | --------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| **Infrastructure independence** | Alesia Doctrine — eliminates third-party failure vectors | Securitize depends on EVM infrastructure, admin controls, external market makers |
| **Mathematical security** | 42 Transfer Hook controls plus module-aware extensions, immutable, runtime-enforced | ERC-3643 compliance bypassable via direct EVM call. Admin overrides exist. |
| **Three-module architecture** | Equities, Real Estate, CORECM served through one architecture | Single-asset-class focus; no native real estate NAV enforcement, no critical-minerals federal-action coordination |
| **Permanent liquidity** | Global Pool, LP burned, Certora-verified non-extractability, single shared pool across modules | Market makers can withdraw. ATS liquidity is fragile. Per-product isolation. |
| **Multi-module addressable surface** | Equities ($50B+ at microcap end alone), Real Estate ($280T+ global), CORECM (US strategic priority) | Securitize's institutional focus does not extend to per-property real estate or basin-asset critical minerals |
| **Transaction economics** | \~$0.00025 per verified transfer | $1–$50+ per transfer on Ethereum L1 |
| **Real-time custody** | Ed25519 attestation every \~400ms across all three modules | Periodic custody verification |
| **Module 2 NAV enforcement** | On-chain NAV-deviation tolerance + tripartite-concurrence governance | Not offered |
| **Module 3 federal-action coordination** | Automatic Control 42 federal-action freeze with 60-minute SLA | Not offered |
| **Reg D / Reg S / Reg CF triple** | All three offering exemptions natively supported, per-investor on-chain enforcement | Typically single regime per mint |
| **Category 1 Model B** | Release No. 33-11412 binding federal framework across all three modules | Category 2 classification risk from admin overrides |
| **No admin override** | Groovy Company cannot move tokens without holder consent | `forceTransfer()` creates centralized risk |
| **Formal verification** | 6 Certora invariants; E.4 covers module-aware extensions | Varies by ERC-3643 deployment, not standardized |
***
### 12. Strategic Positioning
#### 12.1 Different Markets, Different Architectures
Securitize and the RWA Tokens platform do not compete for the same clients. Securitize's institutional DNA makes it ideal for BlackRock-scale clients who need regulatory comfort and accept centralized admin control. The platform's mathematical security, permanent liquidity, and three-module architecture make it ideal for the vast underserved markets where traditional finance infrastructure has no presence — equities at the microcap and global-exchange end (Module 1), real estate at the per-property scale with on-chain NAV enforcement (Module 2), and strategic-minerals supply chain with on-chain federal-action coordination (Module 3).
```
MARKET POSITIONING
Premium Institutional Multi-Module Underserved Surface
(BlackRock, KKR, Apollo) (Equities + Real Estate + CORECM)
▲ ▲
│ │
SECURITIZE RWA TOKENS
ERC-3643 / Ethereum ST22 / Solana
$4B+ tokenized Multi-module addressable surface
Single asset class M1 + M2 + M3
Admin overrides Mathematical security
ATS liquidity (fragile) Global Pool (permanent, shared)
$1–$50+ per tx $0.00025 per tx
```
#### 12.2 Long-Term Trajectory
The competitive threat to Securitize is not the platform taking its institutional clients. The threat is the platform demonstrating that a better architectural model exists — and that the model extends across multiple asset classes. When ST22 architecture processes significant daily volume across Modules 1, 2, and 3 with zero admin overrides, real-time custody attestation, on-chain NAV enforcement (Module 2), and on-chain federal-action coordination (Module 3) — Securitize's middleware-on-Ethereum model will face increasing architectural scrutiny from regulators and institutional evaluators. Module-aware enforcement raises the architectural bar for the entire industry.
#### 12.3 Convergence Risk
If Securitize adds runtime-enforced compliance (through Solana Token-2022 deployment or an Ethereum protocol-level upgrade), the architectural differentiation narrows for Module 1 equity tokenization. However, this would require Securitize to abandon `forceTransfer()` and other admin override functions — a change that would fundamentally alter its institutional operating model. Module 2 NAV-deviation enforcement and Module 3 federal-action coordination would remain platform-unique even after a hypothetical Securitize architectural pivot, because those extensions reflect deliberate per-module design choices rather than general primitives.
#### 12.4 Complementary Positioning — Dinari (DFN)
Dinari (DFN) operates in the large-cap NYSE / NASDAQ Cat-2 tokenization space — explicitly different from the platform's Cat-1 three-module scope. Rather than direct competition, Dinari represents a partnership candidate for cross-chain ST22 distribution (DFN cross-chain capabilities), joint SEC regulatory positioning (Cat-1 + Cat-2 architectural diversity), and complementary asset-class coverage. Strategic-investment outreach is in progress.
#### 12.5 Competitive Moats
| Moat | Durability | Defensibility |
| ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
| **Empire Stock Transfer integration** | High — §17A-registered; Patrick Mokros is COO of Groovy Company, Inc. and Founder of Empire Stock Transfer | Regulatory relationship not easily replicated; covers all three modules |
| **Global Unified CEDEX Liquidity Pool** | Permanent — LP burned, immutable program, single shared pool across modules | Cannot be drained. Mathematical guarantee. Cross-module network effect. |
| **42 immutable Transfer Hook controls + module-aware extensions** | Permanent — runtime-enforced, formally verified, Certora E.4 protects extensions | Cannot be weakened. Architectural guarantee. |
| **Module 2 NAV-deviation enforcement** | Permanent — on-chain NAV oracle + tolerance tied to immutable Control CB-21 NAV variant | Requires new architectural primitives ERC-3643 cannot replicate at L1 economics |
| **Module 3 federal-action coordination** | Permanent — on-chain Classification oracle + automatic Control 42 federal-action freeze | Uncontested capability; no other platform offers this |
| **First Category 1 Model B platform across three modules** | High — regulatory first-mover | SEC Crypto Task Force engagement, no-action letter |
| **Cross-module network effect** | Growing — more issuers across more modules → deeper shared pool | Self-reinforcing once critical mass reached |
| **Reg D / Reg S / Reg CF triple coverage** | High — FINRA-registered funding portal partnership for Reg CF | Multi-regime per-investor on-chain enforcement is architecturally distinct |
| **Transaction economics** | Structural — Solana's cost advantage | Ethereum cannot match \~$0.00025/tx without fundamental protocol changes |
***
### Related Documentation
* **Architecture Decisions** — ADR-001 (Solana over Ethereum), ADR-002 (Custom AMM), module-aware ADRs.
* **Security Model** — Formal verification and threat model; module-aware threat surfaces.
* **Smart Contract Reference** — Module-aware program behavior with full PDA registry.
* **Transfer Hook Reference** — Standalone reference for the 42 controls and module-aware extensions.
* **Compliance Integration Guide** — Regulatory framework details across Reg D / Reg S / Reg CF.
* **Oracle Integration Guide** — Custody, OFAC, AML, TWAP, EDGAR (M1), NAV (M2), Classification (M3) relay architecture.
* **Governance Deep Dive** — Module-aware governance surface, tripartite concurrence pattern, Control 42 federal-action variant.
* **Glossary** — Authoritative terminology reference with module-aware annotations.
***
*RWA Tokens · Competitive Analysis · Groovy Company, Inc.*
# Platform Changelog
## Platform Changelog
**Version History · Breaking Changes · Migration Notes**
All notable changes to the RWA Tokens platform's on-chain programs, SDK, oracle relays, and supporting infrastructure are documented below. The platform is operated by Groovy Company, Inc. and serves three production modules — Module 1 (Equities), Module 2 (Real Estate), and Module 3 (CORECM — Carbon Ore, Rare Earth, and Critical Minerals).
Format follows Keep a Changelog conventions. Versions are semantic: `MAJOR.MINOR.PATCH`. Breaking changes increment MAJOR and ship with explicit migration notes.
***
### Version Summary
| Version | Date | Codename | Significance |
| --------- | -------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **9.0.0** | May 2026 | — | Three-module architecture: Module 1 (Equities), Module 2 (Real Estate), Module 3 (CORECM). Module-aware Transfer Hook extensions. NAVOracle (M2) and ClassificationOracle (M3) introduced. Reg CF added to offering exemption set. Three-token classification formalized. |
| **8.0.0** | March 2026 | — | SEC Release No. 33-11412 alignment. Category 1 Model B compliance posture. 15-section whitepaper. Production-ready single-module specification. |
| **7.0.0** | September 2025 | — | HoldingPeriodAccount replaces VestingConfig. Rule 144 / Reg S on-chain enforcement. Nine-layer architecture. |
| **6.0.0** | June 2025 | — | 42 Transfer Hook controls defined. Global Unified Liquidity Pool designed. Custom CPMM AMM specified. Layer 9 IDOS module designed. |
| **5.0.0** | March 2025 | — | Initial five-layer architecture. Bonding curve engine. Prototype Transfer Hook. |
| **Beta** | Oct–Dec 2025 | Alesia | Mainnet beta deployments. Empirical validation of DEX bypass, copycat, and unauthorized LP attack vectors. |
***
### V9.0.0 — May 2026
**Three-Module Architecture · Module-Aware Compliance · Reg CF**
The V9 release expands the platform from single-module equity tokenization (V8) to a three-module architecture serving equities, real estate, and strategic-minerals supply chain assets. The 42 Transfer Hook controls remain immutable and unchanged; module-aware extensions (CB-21 NAV-deviation variant, REG-42 federal-action variant) plug into the existing control surface as additive runtime checks. Empire Stock Transfer continues as the sole §17A onboarding authority, now extended to cover Common Class B (M1), single-asset-entity (SAE) equity (M2), and basin-asset-entity (BAE) equity (M3).
#### Breaking Changes
| Change | Impact | Migration |
| ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| **SDK package: `@rwatokens/sdk`** | Single SDK exports `RwaTokensClient` and module-aware sub-clients (`equities`, `realEstate`, `corecm`). | Update package imports; existing single-module integrations continue to work via the `equities` sub-client without code changes. |
| **`SecurityConfig` extension fields** | Added `module: u8` (1=Equities, 2=Real Estate, 3=CORECM), `nav_deviation_max_bps: u16` (M2 only), `classification_max_age_secs: i64` (M3 only), `federal_action_freeze_enabled: bool` (M3 only). All zero for M1 mints. | Existing V8 mints unaffected — `module = 1` and module-aware fields zero. New mints set `module` at creation; field is immutable post-creation. |
| **CustodyOracle: `custodied_balance` field name** | Field name normalized to be module-agnostic across M1 / M2 / M3. The legacy field name is renamed during a one-time bytecode-compatible upgrade. | Update oracle relay payload key; field semantics unchanged. |
| **Three offering exemption regimes** | Reg D (US accredited), Reg S (non-US), and Reg CF (US retail crowdfunding) all natively supported per investor on-chain via `HoldingPeriodAccount`. | New `jurisdiction` enum value: `RegCF`. Existing Reg D / Reg S accounts unaffected. |
| **Three-token classification formalized** | (1) GROO Utility Token, (2) Groovy Security Token (STO) — Common Class B of Groovy Company, Inc., (3) ST22 Digital Securities — per-issuer module-specific equity. Distinct legal treatment for each. | Update internal documentation and SDK guides. The GROO Utility Token is not a security and is not subject to ST22 enforcement. |
#### New Features
* **Module 1 — Equities.** Tokenization of equity securities from OTC microcap, NASDAQ, AMEX, TSX, and global exchanges. Custody: Common Class B held 1:1 by Empire Stock Transfer. Asset identifier: CUSIP. Backing: Common Class B equity.
* **Module 2 — Real Estate.** Tokenization of real property assets via single-asset entity (SAE) structures (Nevada LLC → Nevada corporation conversion). Custody: SAE equity held 1:1 by Empire. Asset identifier: property ID. NAV-deviation enforcement at the runtime layer.
* **Module 3 — CORECM.** Tokenization of Carbon Ore, Rare Earth, and Critical Minerals supply chain assets via basin-asset entity (BAE) structures. Custody: BAE equity held 1:1 by Empire. Asset identifier: basin ID. Federal-action freeze enforcement at the runtime layer.
* **Module-aware Transfer Hook extensions.** Two new extensions plug into the 42-control surface without altering the immutable core:
* **CB-21 NAV-deviation variant (M2).** Trade rejected if on-chain price exceeds NAV by `nav_deviation_max_bps` (default 2,200 bps = 22%) or if NAV oracle is stale beyond reappraisal cadence.
* **REG-42 federal-action variant (M3).** Automatic 60-minute SLA freeze on detection of Section 232 / DPA Title III / EO-driven federal action affecting the basin asset; resumes automatically when action lifts.
* **NAVOracle (Module 2).** Per-mint NAV with deviation tolerance enforcement; Ed25519 signed by authorized appraiser. Reappraisal cadence configurable per mint with default 90 days.
* **ClassificationOracle (Module 3).** USGS Critical Minerals List, DOE Critical Materials Strategy, and federal-action status surfaced on-chain; Ed25519 signed by authorized Classification relay. Maximum oracle age configurable per mint with default 24 hours.
* **EDGAR Oracle (Module 1).** SEC EDGAR filing surface continues to feed the Layer 9 IDOS off-chain compliance system; signal vector enriched for module-aware risk scoring.
* **Tripartite concurrence governance (Module 2).** Per-mint NAV bounds and reappraisal cadence require concurrence among SAE issuer + appraiser + Empire Stock Transfer. Governance pattern documented in Governance Deep Dive §16.
* **Reg CF native enforcement.** US retail crowdfunding (Regulation Crowdfunding) holding period (12 months) enforced per investor on-chain via `HoldingPeriodAccount.jurisdiction = RegCF`. FINRA-registered funding portal partnership operationalized.
* **Three-token classification.** GROO Utility Token (ecosystem utility, no backing instrument, Category 1 / 3 non-security per Release No. 33-11412), Groovy Security Token (STO) (Common Class B of Groovy Company, Inc.; $20M Reg D raise; proceeds seed the Global Unified Liquidity Pool), and ST22 Digital Securities (per-issuer module-specific equity tokenization product).
* **Compute budget per module.** Module 1 \~800K CU, Module 2 \~820K CU (NAV oracle read + deviation math), Module 3 \~830K CU (Classification oracle read + federal-action check).
* **Cross-module liquidity unified.** A single Global Unified Liquidity Pool serves all three modules; LP tokens burned at inception; 0.44% of every cross-module trade deepens the shared pool.
* **Federal frameworks surfaced (Module 3).** USGS Critical Minerals List, DOE Critical Materials Strategy, Section 232 of the Trade Expansion Act of 1962, Defense Production Act Title III, Inflation Reduction Act critical minerals provisions, Executive Order 14017, and the Energy Act of 2020 — all surfaced through ClassificationOracle and contemplated by REG-42 federal-action variant.
#### Deprecated (V9)
| Deprecated Item | Replacement | Notes |
| ---------------------------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| Single-module SDK clients | `RwaTokensClient` with `equities` / `realEstate` / `corecm` sub-clients | Existing equity-only integrations migrate by importing `client.equities` |
| Single asset-class assumption in tooling | Module-aware tooling: `--module 1\|2\|3` flag on CLI commands | CLI defaults to `--module 1` for backward compatibility |
| Two-token framing | Three-token classification (GROO Utility, Groovy STO, ST22) | Update training materials, FAQ, glossary |
| Reg D / Reg S only | Reg D / Reg S / Reg CF | Reg CF is additive — existing flows unchanged |
#### Account Schema Changes
```
SecurityConfig (extension fields added):
V8: module field did not exist; assumed equity tokenization
V9: module: u8 (1=Equities, 2=Real Estate, 3=CORECM)
nav_deviation_max_bps: u16 (M2 only; default 2200)
reappraisal_cadence_secs: i64 (M2 only; default 7,776,000 = 90 days)
classification_max_age_secs: i64 (M3 only; default 86,400 = 24 hours)
federal_action_freeze_enabled: bool (M3 only; default true)
CustodyOracle:
V8: custodied_balance (u64), source-class label assumed equity
V9: custodied_balance (u64), class_label: enum {CommonB, SAE, BAE}
HoldingPeriodAccount:
V8: jurisdiction: enum {US, NonUS}; holding_period_secs: i64
V9: jurisdiction: enum {RegD, RegS, RegCF}; holding_period_secs: i64
NEW: NAVOracle (Module 2)
PDA: [b"nav-oracle", mint]
Fields: version, mint, nav_per_token, currency, last_update_slot,
appraiser_pubkey, signature, bump
NEW: ClassificationOracle (Module 3)
PDA: [b"classification-oracle", mint]
Fields: version, mint, basin_id, classification_status, federal_action_active,
federal_action_started_slot, last_update_slot, relay_pubkey,
signature, bump
```
#### Infrastructure Changes
* **Oracle relay services extended.** Custody, OFAC, AML, TWAP, and EDGAR continue from V8; NAV (M2) and Classification (M3) added. All seven categories deployed across separated dev / prod droplets.
* **Federal Register / USGS / DOE feed monitoring.** Module 3 ClassificationOracle relay polls authoritative federal sources with redundancy; 60-minute freeze SLA documented in Incident Response Playbook §13.
* **Compute budget scaling.** Per-module CU budgets validated under load testing (M1 \~800K, M2 \~820K, M3 \~830K).
* **SDK distribution.** `@rwatokens/sdk` published with module-aware sub-clients; full migration matrix documented in SDK Reference §7 (NAV) and §8 (Classification).
#### Regulatory Changes
* **Reg CF added.** US retail crowdfunding now natively enforced per investor on-chain. FINRA-registered funding portal partnership operationalized.
* **Module 3 federal frameworks integrated.** Federal-action coordination now part of the runtime enforcement surface — a capability no other tokenization platform offers.
* **Category 1 Model B applies across all three modules.** Issuer-sponsored, DLT in official records, direct beneficial ownership preserved across M1 / M2 / M3.
***
### V8.0.0 — March 2026
**SEC Release No. 33-11412 · Category 1 Model B · Production Architecture**
The V8 release was the first production-ready specification, focused on equity tokenization. It established the SEC Release No. 33-11412 alignment, the Category 1 Model B compliance posture, the 15-section whitepaper, and the GitHub documentation suite that V9 extended for three-module operation.
#### Breaking Changes
| Change | Impact | Migration |
| ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| **GROO classified as Utility Token** | GROO is not a security, not an STO, not backed by shares. Distinct from the Groovy Security Token (STO) and from per-issuer ST22 Digital Securities. | Remove any reference to "GROO STO" or "GROO Security Token" from all GROO contexts. |
| **CEDEX URL: cedex.market** | Standalone trading venue domain canonicalized | Update all API base URLs, documentation links, and frontend references to `cedex.market` |
#### New Features
* **SEC Release No. 33-11412 alignment.** ST22 tokens classified as Category 5 Digital Securities. Platform operates under Category 1 Model B per the January 28, 2026 Joint Staff Statement on Tokenized Securities.
* **Two-token architecture (V8 framing).** GROO Utility Token (ecosystem utility, no backing) and ST22 Digital Securities (issuer equity, Common Class B backing). The third token class — Groovy Security Token (STO) — was formalized in V9.
* **Certificate of Designation.** Each issuer files a Certificate of Designation specifying Common Class B shareholder rights with the Secretary of State of their jurisdiction of incorporation.
* **GENIUS Act stablecoin settlement.** All ST22 purchases settle in USDC or PYUSD, not fiat wire and not native crypto. ADR-009 documents the rationale.
* **15-section whitepaper complete.** Sections 1–15 plus Glossary. All former appendices incorporated into parent sections.
* **Beta validation findings incorporated.** Mainnet beta forensics (October–December 2025) documented with finding-to-architecture mapping.
* **Alesia Doctrine.** Strategic framework from beta incidents formally documented. Circumvallation (liquidity containment) + Contravallation (bot defense) directly informs the nine-layer architecture.
* **Complete GitHub documentation suite.** Whitepaper V8, SDK Reference, Smart Contract Reference, Security Model, CEDEX API Reference, Deployment Guide, Architecture Decision Records, Changelog, Home, Sidebar.
#### Deprecated (V8)
| Deprecated Item | Replacement | Notes |
| ---------------------------------------------------------------------- | ---------------------------------- | -------------------------------------------- |
| "Howey Shield" | Removed entirely | Framework obsolete |
| "Security Meme Token" / "SMT" | "ST22 Digital Securities" | Terminology replaced |
| Whitepaper V6 / V7 references | Whitepaper V8 | All prior versions superseded |
| External legal-counsel attribution | "Legal Counsel" generically | Attribution genericized |
| Distress narratives ("illiquid OTC microcap" / "trapped shareholders") | Professional institutional framing | Capability-led, not problem-led, positioning |
| "Pink Current" (OTC tier) | "OTCID" | OTC Markets Group renamed tier |
| Five-Year revenue projections | Removed | Technical specification, not marketing |
#### Infrastructure Changes
* Dedicated Helius RPC cluster (500+ req/sec) replaces shared tier
* Triton backup RPC configured for failover
* Jito Block Engine integration for MEV protection (ADR-010)
* Datadog monitoring + PagerDuty escalation configured
* Five oracle relay categories production-ready: custody, OFAC, AML, TWAP, EDGAR
#### Regulatory Changes
* SEC Release No. 33-11412 (March 17, 2026) — Category 5 Digital Securities taxonomy, binding
* January 28, 2026 Joint Staff Statement on Tokenized Securities — Category 1 / Category 2 framework
* April 13, 2026 SEC Staff Statement on Covered User Interface Providers — runtime enforcement weight
* GENIUS Act alignment for stablecoin settlement
* CFTC Letters 25-39 and 26-05 identified as relevant
#### Account Schema Changes
```
SecurityConfig:
V7 → V8: No structural schema change. Version field updated to 8.
CustodyOracle:
V7 → V8: No structural schema change. Version field updated to 8.
HoldingPeriodAccount:
V7 → V8: No structural schema change. Version field updated to 8.
All accounts: V7 → V8 is documentation, regulatory alignment, and infrastructure
hardening. No on-chain account schema break.
```
***
### V7.0.0 — September 2025
**Rule 144 / Reg S On-Chain Enforcement · Category 1 Model B Alignment**
The V7 release replaced the issuer vesting model with investor holding period enforcement — the most significant compliance architecture change in the protocol's history. Control 24 was completely rewritten. The `HoldingPeriodAccount` replaced `VestingConfig`. The platform shifted from issuer-focused tokenomics to investor-focused regulatory compliance.
#### Breaking Changes
| Change | Impact | Migration |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| **VestingConfig replaced by HoldingPeriodAccount** | Account schema completely changed. New PDA seeds. New fields (`jurisdiction`, `purchase_timestamp`, `holding_period_secs`). | Deploy new `HoldingPeriodAccount` PDA per investor-mint pair. `VestingConfig` accounts deprecated — existing tokens must migrate. |
| **Control 24 rewritten** | Error 6024 meaning changed: was `VestingLocked` (issuer vesting not elapsed), now `TokensLocked` (Rule 144 / Reg S not elapsed) | Update error handling. New error includes jurisdiction and unlock timestamp in details. |
| **Category 3 controls renamed** | Was "Vesting Enforcement" (8 controls). Now "Investor Eligibility & Holding Period Enforcement" (8 controls). | Update documentation and monitoring dashboards. |
| **Five-layer → nine-layer architecture** | Layers 6–9 added (Oracle Network, Governance, Wallet Infrastructure, IDOS Module). Layer numbering changed. | Update all architecture references. |
| **Offering exemptions: Reg D / Reg S** | All ST22 offerings exclusively under Reg D (US accredited) and Reg S (non-US) at the V7 timestamp. Reg CF added in V9. | Empire Stock Transfer is sole investor onboarding authority. |
#### New Features
* **HoldingPeriodAccount.** Per-investor-mint PDA recording purchase timestamp, jurisdiction (US / NonUS at V7; expanded to RegD / RegS / RegCF at V9), and holding period duration. Created at token delivery. One per investor-mint pair.
* **Rule 144 enforcement.** 6-month holding period (15,778,800 seconds) for US accredited investors (Reg D). On-chain. No early unlock path.
* **Reg S enforcement.** 12-month distribution compliance period (31,536,000 seconds) for non-US investors. On-chain. No early unlock path.
* **Jurisdiction flag.** Set by Empire Stock Transfer at investor onboarding. Immutable per `HoldingPeriodAccount`. Determines which holding period applies.
* **Category 1 Model B alignment.** Architecture designed to satisfy January 28, 2026 Joint Staff Statement requirements. Issuer-sponsored. DLT in official shareholder records. Direct beneficial ownership.
* **Nine-layer architecture.** Layers 6–9 added: Oracle Network, Protocol Governance, Wallet Infrastructure, Layer 9 IDOS Module (off-chain compliance system).
* **Empire Stock Transfer as sole onboarding authority.** KYC, KYB, AML, OFAC / SDN, wallet verification all handled by Empire. The platform's investor portal routes to Empire's dashboard. The platform does not perform investor onboarding directly.
* **42 controls expanded to eight categories.** Custody Verification, Investor Verification, Position Limits, Circuit Breakers, Holding Period, Sanctions, Protective Conversion, Governance & Audit.
#### Deprecated (V7)
| Deprecated Item | Replacement | Notes |
| --------------------------------- | ------------------------------------------ | --------------------------------------------------------- |
| `VestingConfig` (account) | `HoldingPeriodAccount` | Complete schema replacement |
| `VestingLocked` (Error 6024) | `TokensLocked` (Error 6024) | Error code retained, meaning changed |
| `vesting.rs` (state file) | `holding_period.rs` | File renamed |
| 5-tranche issuer vesting schedule | Investor holding period (Rule 144 / Reg S) | Architectural shift: issuer vesting → investor compliance |
| Five-layer architecture | Nine-layer architecture | Layers 6–9 added |
| Per-issuer bonding curve / FLP | Global Unified Liquidity Pool | Liquidity model changed |
#### Account Schema Changes
```
NEW: HoldingPeriodAccount (84 bytes)
PDA: [b"holding-period", mint, beneficiary]
Fields: version, beneficiary, mint, purchase_timestamp,
jurisdiction (US/NonUS at V7), holding_period_secs, is_locked, bump
REMOVED: VestingConfig (nested in SecurityConfig)
Was: total_allocation, released_amount, start_timestamp,
cliff_duration, vesting_duration, release_schedule
SecurityConfig:
V6: holding_period_config did not exist. Had vesting_config.
V7: holding_period_config (HoldingPeriodConfig) replaces vesting_config.
New fields: enabled (bool), rule_144_secs (i64), reg_s_secs (i64).
```
***
### V6.0.0 — June 2025
**Nine-Layer Architecture · 42 Controls Defined · Global Pool Designed**
The V6 release formalized the complete architecture. The 42 Transfer Hook controls were defined, categorized, and assigned error codes. The Global Unified Liquidity Pool concept was introduced. The Custom AMM (CPMM) was specified. The Layer 9 IDOS (Issuer Distress and Opportunity Score) module was designed.
#### New Features
* **42 Transfer Hook controls.** Complete control specification across six categories (V6 numbering): Balance Validation, Identity Verification, Vesting Enforcement, Market Integrity, Emergency, Audit.
* **Error code registry (6001–6042).** Every control assigned a unique error code. CEI integrity checks (6007–6019). Market integrity (6020–6025). Emergency (6036–6042).
* **Global Unified Liquidity Pool.** Single shared pool serving all issuers. LP burned at initialization. Protocol-owned. Self-reinforcing via 0.44% fee allocation.
* **Custom CPMM AMM.** Constant Product Market Maker (`x * y = k`) with `u128` overflow-safe arithmetic. Purpose-built because external DEXs bypass Transfer Hooks.
* **CEDEX exchange.** Compliant Exchange for Digital Securities. Dual-layer: centralized order matching + decentralized Solana settlement.
* **Oracle Network.** Five oracle categories: custody (Empire Ed25519), OFAC / SDN, AML (Chainalysis + TRM Labs), TWAP (Pyth Network), EDGAR.
* **Layer 9 IDOS Module.** Issuer Distress and Opportunity Score. XGBoost model. EDGAR NLP pipeline. Wallet behavioral profiling.
* **Protocol Governance.** On-chain proposal / voting. Multi-sig thresholds. 48-hour timelock. Immutable Transfer Hook controls outside governance scope.
* **5% fee structure.** Total fee with distribution: 2% issuer, 1.5% staking, 1.06% protocol, 0.44% Global Pool (locked).
* **Circuit breaker architecture.** Price halt (>10% in 5 min), price impact (>2% TWAP deviation), volume halt (>30% daily sell), oracle failure.
* **SecurityConfig PDA.** Per-mint security configuration account. All 42 control parameters stored on-chain.
* **Ed25519 custody attestation.** Empire signs custody balance per Solana block. Verified by Solana native precompile.
* **Formal verification specification.** Six Certora Prover invariants defined for pre-mainnet verification.
#### Account Schemas Introduced
```
SecurityConfig (~376 bytes)
PDA: [b"security-config", mint]
VestingConfig (nested in SecurityConfig)
Fields: total_allocation, released_amount, start_timestamp,
cliff_duration, vesting_duration, release_schedule
VolumeTracker (217 bytes, nested in SecurityConfig)
Fields: volume_window[24], current_hour_index, last_update_slot,
average_daily_volume, spike_multiplier
CustodyOracle (164 bytes)
PDA: [b"custody-oracle", mint]
OFACOracle
PDA: [b"ofac-oracle"]
AMLOracle
PDA: [b"aml-oracle", wallet]
```
***
### V5.0.0 — March 2025
**Five-Layer Architecture · Bonding Curve · Initial Transfer Hook**
The V5 release was the initial architecture. Five layers. Bonding curve price discovery. Prototype Transfer Hook with basic controls.
#### Features
* Five-layer architecture: Blockchain Foundation, Core Protocol, Protocol Logic, Application Services, User Interface.
* Bonding curve engine — polynomial price formula `P(s) = k1*s^2 + k2*s + k3`.
* Initial Transfer Hook prototype — basic wallet limits and circuit breakers.
* Pool Factory Contract — deploys perpetual liquidity pools.
* Liquidity Vault — minimum 30% permanently locked.
* Fee Distributor — 1.1% bonding curve phase, 0.4% post-graduation.
* Oracle Integration — Empire Stock Transfer custody + Pyth price feeds.
* Anti-sniper Transfer Hook system at the launch venue layer.
* React web application + React Native mobile.
#### Notes
V5 assumed token graduation to external DEXs (Raydium). This assumption was invalidated by beta testing (see ADR-002). V5 architecture is fully superseded by V6+ nine-layer design.
***
### Beta Releases — October–December 2025
**GROO · GRLF · MSPC · Mainnet Validation**
Three beta deployments on Solana Mainnet provided empirical validation of all security assumptions — and proved that external DEX trading is architecturally incompatible with Transfer Hook enforcement.
#### Beta 1: GROO — October 31, 2025
| Metric | Result |
| ---------------------------- | ---------------------------- |
| Peak market cap | $6,000,000 |
| Post-attack market cap | $250,000 (-95.8%) |
| Sniper bots | \~1,000+ coordinated wallets |
| Value extracted | \~$5,750,000 |
| Controls bypassed on Raydium | 42 of 42 |
**Outcome.** Proved external DEXs bypass all Transfer Hook controls. Directly led to ADR-002 (Custom AMM) and the Alesia Doctrine.
#### Beta 2: MSPC — November 2025
| Metric | Result |
| --------------- | ------------------------------------------- |
| Copycat tokens | 13 across external platforms |
| RPC bottleneck | 50 sendTx/sec exceeded |
| Security bypass | Cooldown controls bypassed beyond RPC limit |
**Outcome.** Proved RPC capacity must scale for launch volumes. Led to Helius dedicated cluster upgrade (500+ req/sec) and Triton failover.
#### Beta 3: GRLF — December 1–3, 2025
| Metric | Result |
| --------------- | ------------------------------------------------ |
| Price collapse | -93.69% |
| Bot share | 85% of all activity (34 of 40 transactions) |
| Human share | 15% (6 transactions) |
| Copycat tokens | 6 across Pump.fun, Raydium, Moonshot |
| Unauthorized LP | Created by third-party bot 54 minutes after mint |
**Outcome.** Proved unauthorized LP creation and copycat deployment are primary attack vectors. Led to protocol-controlled pool creation and Empire-verified issuer-only token creation on CEDEX.
#### Combined Beta Findings → V8 Architecture
| Finding | V8 Response | ADR |
| ------------------------------------ | -------------------------------------------------- | ------- |
| External DEXs bypass all 42 controls | Custom AMM + CEDEX only | ADR-002 |
| 85% bot activity | Jito MEV protection | ADR-010 |
| 19 copycat tokens | Empire-verified issuers only | — |
| Unauthorized LP creation | Protocol-controlled pools | — |
| RPC bottleneck | Helius dedicated + Triton failover | — |
| $5.75M extracted (GROO) | Circuit breakers + wallet limits + holding periods | — |
***
### Migration Guides
#### V8 → V9 Migration
**Scope:** Additive. V9 introduces module-aware extensions without breaking V8 single-module integrations.
1. **SDK upgrade.** Replace single-module SDK clients with `RwaTokensClient` from `@rwatokens/sdk`. Existing equity-only integrations migrate by importing `client.equities`.
2. **Custody oracle field name.** Rename payload field to `custodied_balance` (module-agnostic). Field semantics unchanged.
3. **`SecurityConfig` extension fields.** Existing V8 mints unaffected; `module = 1` defaults preserve V8 behavior. New mints set `module` at creation.
4. **`HoldingPeriodAccount.jurisdiction`.** Existing accounts remain valid (`US` maps to `RegD`, `NonUS` maps to `RegS`); new Reg CF accounts use the new `RegCF` value.
5. **Module 2 / Module 3 integrations.** Add NAVOracle relay (M2) or ClassificationOracle relay (M3) to deployment manifest; oracle PDA derivation documented in Smart Contract Reference §10–§11.
6. **Tooling.** CLI commands accept `--module 1|2|3` flag; defaults to `--module 1` for backward compatibility.
#### V7 → V8 Migration
**Scope:** Limited. V8 is documentation, regulatory alignment, and infrastructure hardening. No on-chain account schema break.
1. **Schema versions.** `SecurityConfig`, `HoldingPeriodAccount`, `CustodyOracle` version fields update to 8. No structural schema change.
2. **URLs.** Update trading-venue URL references to `cedex.market`.
3. **Documentation references.** Whitepaper V6 / V7 references should resolve to Whitepaper V8.
#### V6 → V7 Migration
**Scope:** Significant. Account schema replacement.
1. **Account migration.** `VestingConfig` accounts must be replaced with `HoldingPeriodAccount` PDAs. New PDA seeds: `[b"holding-period", mint, beneficiary]`.
2. **Control 24 rewrite.** All error handling for Error 6024 must be updated. New meaning: `TokensLocked` (holding period). New error details include `jurisdiction`, `holding_period_secs`, `unlock_timestamp`.
3. **Architecture layers.** Five-layer references must be updated to nine-layer architecture. Layer numbers changed.
4. **Offering framework.** Update to Reg D / Reg S exclusive (V9 adds Reg CF as additive).
5. **Empire onboarding.** Empire Stock Transfer is sole investor onboarding authority. Remove any direct platform-side investor onboarding references.
***
### Upcoming (Q3 2026)
#### Mainnet Launch
* All on-chain programs deployed to Solana Mainnet-Beta with V9 module-aware extensions enabled.
* CEDEX live at `cedex.market` serving Module 1 (Equities), Module 2 (Real Estate), and Module 3 (CORECM) trading.
* First Module 1 listings — initial ST22 Digital Securities for OTC microcap and global-exchange equity issuers.
* First Module 2 listings — initial single-asset entity (SAE) real estate tokenizations (commercial building use case fully documented through V1.2 of the Module 2 reference design).
* First Module 3 listings — initial basin-asset entity (BAE) critical minerals tokenizations.
* Empire Stock Transfer investor onboarding live across all three modules.
* Solana Treasury funded; Global Unified Liquidity Pool seeded.
* All seven oracle relay categories in production: custody, OFAC, AML, TWAP, EDGAR, NAV, Classification.
* Monitoring and alerting fully operational with module-specific dashboards.
#### Post-Launch Roadmap
| Phase | Timeline | Targets |
| --------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Growth | Q4 2026 – Q1 2027 | Module 1: 100+ issuer listings, UK / EU / UAE expansion, GROO CEX listings. Module 2: 25+ SAE listings. Module 3: 10+ BAE listings. |
| Expansion | 2027 – 2028 | Module 1: 1,000+ issuers. Wormhole NTT cross-chain. Reg CF retail expansion. Governance activation. Module 2: institutional REIT-scale tokenization. Module 3: federal supply-chain integration. |
| Scale | 2028+ | Global Perpetual Market Infrastructure across all three modules. EVM compatibility. Foreign-exchange equity tokenization (M1). Cross-module portfolio products. |
***
### Related Documentation
* **Architecture Decisions** — ADR-001 through ADR-012 documenting why each architectural decision was made.
* **Smart Contract Reference** — Current program specifications, module-aware PDA registry.
* **SDK Reference** — `@rwatokens/sdk` reference, module-aware sub-clients.
* **CEDEX API Changelog** — Module-aware API versioning and deprecation timeline.
* **Deployment Guide** — Build, deploy, and verify procedures across modules.
* **Compliance Integration Guide** — Regulatory framework details across Reg D / Reg S / Reg CF.
* **Oracle Integration Guide** — Seven oracle categories: custody, OFAC, AML, TWAP, EDGAR (M1), NAV (M2), Classification (M3).
***
*Platform Changelog · Groovy Company, Inc.*
# 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.*
# 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 | Name | Responsibility |
| ----------- | -------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **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)
| Property | Value |
| -------------------------------- | ------------------------------------------------------------------ |
| 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)
| Component | Detail |
| ------------------------ | ------------------------------------------------------------- |
| 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:
| Component | Role |
| -------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| `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)
| Property | Value |
| ------------------ | ------------------------------------------------------------------------------------- |
| 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)
| Component | Detail |
| ---------------- | ---------------------------------------------------------------------------------------------- |
| 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:
| # | Oracle | Source | Modules | Cadence |
| - | --------------------- | --------------------------- | ---------- | ----------------------------------------- |
| 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:
| Parameter | Authority |
| ------------------------------------------- | ------------------------------------------------------------------ |
| 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
| Wallet | Role |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| 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:
```
Wallet (Layer 8) — investor signs swap instruction
↓
CEDEX matching engine (Layer 5) — order book match
↓
amm program — issues Token-2022 transfer instruction
↓
SPL Token-2022 program (Layer 1 + Layer 2) — invokes Transfer Hook via CPI
↓
Transfer Hook program (Layer 2) — executes 42 controls + applicable module-aware extensions
↓ (each control reads from)
Layer 3 PDAs (SecurityConfig, HoldingPeriodAccount)
Layer 6 oracles (CustodyOracle, OFAC, AML, TWAP, NAV [M2], Classification [M3])
↓
Layer 1 settlement — atomic commit on Solana (~400 ms)
↓
Layer 4 pool reserves updated; 0.44% locked into Global Pool
↓
Layer 9 IDOS — observes settlement event for surveillance signal generation
```
#### 2.4.2 Oracle Update Path
Oracle updates use a separate path that does not involve transfers:
```
External source (e.g., Federal Register for M3 Classification, Empire for Custody)
↓
Off-chain relay service
↓
Ed25519 signing
↓
Solana RPC submission
↓
On-chain oracle PDA update (signature verified by Solana native precompile)
↓
Subsequent transfers read updated PDA via Layer 2 controls
```
#### 2.4.3 Governance Action Path
Governance actions traverse Layer 7 with multi-sig and timelock:
```
Proposal submission (any of the authorized parties)
↓
On-chain proposal PDA created
↓
48-hour timelock (cannot be shortened)
↓
Tripartite signature collection (for module-aware parameter changes)
OR 3-of-5 multi-sig collection (for platform parameters)
↓
Governance program executes parameter update
↓
GA-42 audit emission
```
***
### 2.5 V10 Architectural Changes vs V8
| Component | V8 | V10 |
| ------------------------------------------ | ----------------------------------- | ------------------------------------------------------------------------------------- |
| 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:
| Pillar | Layer Satisfying | Mechanism |
| ----------------------------------------------------------- | -------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
| 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.*
# SPL Token-2022 Transfer Hook — Layer 2
## Section 3: SPL Token-2022 Transfer Hook — Layer 2
**RWA Tokens Platform Whitepaper · Version 10.0** **Groovy Company, Inc. · May 2026** **Document Reference:** RWA-TH-SPEC-001 v4.0 (aligned with Whitepaper V10.0)
The complete technical specification for the platform's 42-control Transfer Hook security architecture plus module-aware extensions — the foundational compliance enforcement mechanism that makes regulatory bypass structurally impossible across all three production modules.
| Metric | Value |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Total core security controls | 42 (immutable, V6+) |
| Module-aware extensions | 2 (CB-21 NAV-deviation variant — M2; REG-42 federal-action variant — M3) |
| Transfer coverage | 100% — every ST22 transfer invokes all applicable controls |
| Bypass possibility | Zero — enforced at SPL Token-2022 program level by the Solana runtime |
| Target validation latency | < 1,000 ms (parallel execution) |
| Compute unit budget per validation | < 5,000 CU baseline (M1 ≈ 800 K CU, M2 ≈ 820 K CU, M3 ≈ 830 K CU including oracle reads) |
| Implementation language | Rust / Anchor framework |
| Immutability | Transfer Hook program ID bound to mint at creation; cannot be removed, repointed, or disabled (Certora E.4, E.6) |
| V10 change vs V8 | Module-aware extensions added: CB-21 NAV-deviation variant for Module 2 (Real Estate), REG-42 federal-action variant for Module 3 (CORECM). The 42 core controls are unchanged. SecurityConfig PDA extended with module-aware fields. |
***
### 3.1 The Alesia Doctrine — Compliance by Encirclement
The Transfer Hook architecture embodies the **Alesia Doctrine**: the principle that compliance should be enforced through structural encirclement rather than trust. In traditional securities markets, compliance depends on intermediaries — broker-dealers, clearinghouses, and regulators — acting in good faith. These actors can fail, be compromised, or simply be absent in the OTC microcap context where infrastructure has been abandoned. They are also irrelevant to many of the cross-module use cases the platform addresses (single-asset real-estate entities, basin-asset critical-minerals entities) where no traditional securities-clearing infrastructure has ever existed.
The platform's Transfer Hook architecture eliminates the dependency on good-faith intermediary behavior by embedding compliance enforcement in the token transfer primitive itself. Every ST22 token transfer — regardless of which wallet, front-end, or trading venue initiates it, regardless of which module the mint belongs to — must pass through all 42 core controls plus all applicable module-aware extensions before the transaction executes on-chain. There is no path around this enforcement. There is no administrative override. There is no whitelist for trusted parties. The controls execute identically for every participant on every transfer, including Groovy Company itself.
#### 3.1.1 Why Application-Layer Compliance Fails
The January 28, 2026 Joint Staff Statement on Tokenized Securities explicitly identified the compliance gap that results when securities compliance is implemented at the application layer rather than the token standard level. When compliance is enforced by an issuer's portal or a specific trading venue, any participant who routes around that portal or venue bypasses all compliance controls. This is the architectural vulnerability that defines Category 2 (Third-Party Sponsored) tokenization — and it is precisely what the Transfer Hook architecture eliminates.
| Compliance Location | Vulnerability | Platform Approach |
| ----------------------------------------- | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| Application layer (portal) | Any alternative front-end bypasses all controls | Layer 2 enforcement — no front-end can bypass |
| Trading venue (exchange) | Any DEX that doesn't enforce compliance disables all controls | CEDEX exclusive — the only venue that preserves Transfer Hook semantics |
| Issuer policy | Policy can be changed, ignored, or overridden | Immutable smart contract — policy is code, code is law |
| Third-party custodian | Custodian can withdraw backing assets, creating de-peg risk | Transfer Hook Control 1 verifies custody on every transfer; Empire Ed25519 attestation per Solana slot |
| Module-specific risk (NAV drift, M2) | Application-layer NAV checks bypassable | Control CB-21 NAV-deviation variant — runtime-enforced for Module 2 mints |
| Module-specific risk (federal action, M3) | Manual freeze processes lag federal events | Control REG-42 federal-action variant — automatic 60-minute SLA on detection |
| Transfer Hook (Layer 2) | Cannot be bypassed — any failure reverts entire transaction | This is the platform's approach — compliance at the primitive |
#### 3.1.2 The April 13, 2026 Covered User Interface Statement
The SEC Staff Statement on Covered User Interface Providers (April 13, 2026) reinforces the runtime-enforcement weight in compliance characterization. UI-layer compliance is insufficient. The platform's architecture maps directly to the Statement's framework: cedex.market is a Covered UI Provider, but the substantive compliance enforcement happens at the Solana Transfer Hook layer, not at the UI. Even if a user submits transfer transactions directly to a Solana RPC endpoint bypassing cedex.market, the SPL Token-2022 program will refuse the instruction unless the registered Transfer Hook is invoked successfully. This UI-independence is what allows the platform to satisfy Pillar 6 (Investor Protection — compliance enforcement at every transfer) of Category 1 Model B as an architectural property rather than a UI-layer assertion.
***
### 3.2 Architecture
#### 3.2.1 Transaction Flow
The Transfer Hook is invoked by the SPL Token-2022 program on every ST22 token transfer via Cross-Program Invocation (CPI). This invocation is mandatory at the protocol level — it cannot be disabled by the issuer, by Groovy Company, or by any trading venue.
```
Step 1 — Transfer initiation
User signs and submits a transfer instruction through any entry point:
- cedex.market order execution
- Hardware wallet (Ledger Enterprise; Phantom + hardware-wallet bridge)
- Mobile / desktop wallet (Solflare, Backpack, Coinbase Wallet, Ledger)
- Programmatic call via @rwatokens/sdk or direct RPC
Step 2 — Token-2022 receives instruction
SPL Token-2022 program receives the transfer instruction.
Token-2022 reads the mint's transfer-hook extension data and resolves
the registered hook program ID.
Step 3 — Transfer Hook invoked via CPI
Token-2022 automatically invokes the platform's Transfer Hook program
via Cross-Program Invocation. This step is enforced by the Solana
runtime; there is no instruction syntax that skips it on a
hook-extended mint.
Step 4 — Module classification + control execution
The Transfer Hook reads SecurityConfig.module to classify the mint
(M1 / M2 / M3). All 42 core controls execute. Applicable module-aware
extensions execute (CB-21 NAV-deviation for M2; REG-42 federal-action
for M3). Oracle data from Layer 6 (custody, OFAC, AML, TWAP,
EDGAR for M1, NAV for M2, Classification for M3) is consumed in real
time via Ed25519-signature verification.
Step 5 — Atomic result
If ANY control or applicable extension fails: the entire transaction
reverts atomically with a specific error code (6001–6042 for core
controls; 6021 for CB-21 NAV variant; 6042 for REG-42 federal variant).
If ALL controls and applicable extensions pass: execution proceeds to
Layer 1 settlement.
Step 6 — Settlement and audit
Passing transactions settle on Solana Mainnet-Beta with ~400 ms
finality. An immutable audit record of all control results — including
module-aware extension evaluations — is written on-chain via Control
GA-42 for every transfer.
```
#### 3.2.2 Program Structure
The Transfer Hook program is implemented in Rust using the Anchor framework. Module-aware extension logic is structured as conditional execution paths that run only when `SecurityConfig.module` matches the relevant module.
```
programs/
└── transfer_hook/
└── src/
├── lib.rs // Program entrypoint
├── instructions/
│ ├── mod.rs
│ ├── initialize.rs // SecurityConfig initialization
│ └── transfer_hook.rs // Main hook logic (42 controls + module dispatch)
├── state/
│ ├── mod.rs
│ ├── security_config.rs // Per-mint security parameters with module fields
│ ├── circuit_breaker.rs // Circuit-breaker state
│ ├── holding_period.rs // Reg D / Reg S / Reg CF enforcement
│ ├── nav_oracle.rs // V10: Module 2 NAV oracle PDA struct
│ └── classification_oracle.rs // V10: Module 3 Classification oracle PDA struct
├── controls/
│ ├── mod.rs
│ ├── custody.rs // Controls 1–7, 38, 40 (CV-* family)
│ ├── sanctions.rs // Controls 8–11 (SX-*)
│ ├── investor.rs // Controls 12–19 (IV-*, HP-* core)
│ ├── circuit.rs // Controls 20–25 (CB-*) including CB-21 module dispatch
│ ├── conversion.rs // Controls 26–28 (PC-*)
│ ├── governance.rs // Controls 29–37 (GA-*)
│ └── emergency.rs // Controls 38–42 (REG-*) including REG-42 federal dispatch
├── extensions/
│ ├── mod.rs
│ ├── nav_deviation.rs // V10: CB-21 NAV-deviation variant (Module 2)
│ └── federal_action.rs // V10: REG-42 federal-action variant (Module 3)
├── errors.rs // Custom error codes (6001–6042 + variant codes)
└── utils/
├── validation.rs // Validation helpers
├── ed25519.rs // Native precompile invocation for Empire / NAV / Classification signatures
└── math.rs // u128 overflow-safe arithmetic; bps conversion
```
#### 3.2.3 Account Architecture — SecurityConfig PDA
The Transfer Hook utilizes Program Derived Addresses (PDAs) to store security configuration and state for each token mint. One `SecurityConfig` account is created per ST22 mint at initialization, establishing the security parameters that govern all transfers of that token for its entire existence. V10 extends the V8 schema with module-aware fields; V8 mints have `module = 1` by default and zero values for module-aware fields, preserving V8 behavior unchanged.
```rust
#[account]
pub struct SecurityConfig {
// V8 base fields (unchanged in V10)
pub mint: Pubkey, // Associated token mint
pub authority: Pubkey, // 3-of-5 multi-sig admin
pub max_wallet_percent: u16, // basis points; default 999 (9.99%)
pub circuit_breaker_threshold: u16, // 3000 = 30% daily volume
pub circuit_breaker_cooldown: i64, // 86_400 = 24 hours
pub circuit_breaker_triggered: bool,
pub circuit_breaker_triggered_at: i64,
pub reference_price: u64, // TWAP baseline
pub holding_period_config: HoldingPeriodConfig,
pub volume_tracker: VolumeTracker,
pub blacklisted_wallets: Vec,
pub is_paused: bool,
pub bump: u8,
// V10 module-aware extension fields (NEW)
pub module: Module, // Equities | RealEstate | CORECM
pub asset_identifier: [u8; 32], // CUSIP (M1) | property_id (M2) | basin_id (M3)
// V10 Module 2 NAV-deviation enforcement (zero-valued for M1, M3)
pub nav_deviation_max_bps: u16, // default 2200 = 22%
pub reappraisal_cadence_secs: i64, // default 7_776_000 = 90 days
// V10 Module 3 federal-action enforcement (zero-valued for M1, M2)
pub classification_max_age_secs: i64, // default 86_400 = 24 hours
pub federal_action_freeze_enabled: bool, // default true for M3
pub federal_action_sla_secs: i64, // default 3600 = 60 minutes
pub version: u8, // schema version 10
}
#[derive(AnchorSerialize, AnchorDeserialize, Clone, Copy, PartialEq)]
pub enum Module {
Equities = 1,
RealEstate = 2,
CORECM = 3,
}
#[derive(AnchorSerialize, AnchorDeserialize, Clone, Copy, PartialEq)]
pub enum AssetClass {
CommonB, // M1 — Common Class B equity
SAE, // M2 — Single-Asset Entity equity
BAE, // M3 — Basin-Asset Entity equity
}
```
#### 3.2.4 Account Architecture — HoldingPeriodAccount (Reg D / Reg S / Reg CF)
V10 expands the V7 jurisdiction enum from `{US, NonUS}` to `{RegD, RegS, RegCF}`. Existing V8 accounts continue to function; runtime mapping: `US` → `RegD`, `NonUS` → `RegS`. Reg CF requires a new account at issuance and is not retroactively added to existing investors.
```rust
#[account]
pub struct HoldingPeriodAccount {
pub version: u8, // 10
pub beneficiary: Pubkey, // Investor wallet address
pub mint: Pubkey, // ST22 mint address
pub purchase_timestamp: i64, // Unix timestamp at token delivery
pub jurisdiction: Jurisdiction, // V10: RegD, RegS, RegCF
pub holding_period_secs: i64, // Derived from jurisdiction
pub is_locked: bool, // True until holding period elapses
pub bump: u8,
}
#[derive(AnchorSerialize, AnchorDeserialize, Clone, Copy, PartialEq)]
pub enum Jurisdiction {
RegD = 0, // Rule 144 — 6-month holding period (US accredited)
RegS = 1, // Regulation S — 12-month distribution compliance period (non-US)
RegCF = 2, // Regulation Crowdfunding — 12-month holding period (US retail)
}
// V10 holding-period constants
pub const RULE_144_HOLDING_SECS: i64 = 15_778_800; // 6 months (Reg D)
pub const REG_S_COMPLIANCE_SECS: i64 = 31_536_000; // 12 months (Reg S)
pub const REG_CF_HOLDING_SECS: i64 = 31_536_000; // 12 months (Reg CF)
```
#### 3.2.5 Account Architecture — Custody Oracle (All Modules)
The Custody Oracle stores Empire Stock Transfer's Ed25519-signed attestation of the underlying equity backing the mint 1:1. The asset class is encoded in the oracle account so Control CV-04 can verify backing-class consistency with `SecurityConfig.module`.
```rust
#[account]
pub struct CustodyOracle {
pub version: u8, // 10
pub mint: Pubkey,
pub custodied_balance: u64, // Module-agnostic: shares of the custodied class
pub class_label: AssetClass, // CommonB | SAE | BAE
pub last_update_slot: u64, // Slot of the most recent attestation
pub empire_pubkey: Pubkey, // Empire's Ed25519 public key
pub signature: [u8; 64], // Ed25519 signature over (mint, custodied_balance, class_label, slot)
pub bump: u8,
}
```
#### 3.2.6 Account Architecture — NAV Oracle (Module 2 Only)
The NAV Oracle is created per Module 2 mint at initialization. The authorized appraiser Ed25519-signs every NAV attestation. CB-21 NAV-deviation variant reads this account on every Module 2 transfer.
```rust
#[account]
pub struct NavOracle {
pub version: u8,
pub mint: Pubkey,
pub nav_per_token: u64, // Net Asset Value per token, denominated in 1e6 USDC base units
pub currency: [u8; 4], // "USDC" or "PYUS"
pub last_update_slot: u64, // Slot of last attestation
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,
}
```
#### 3.2.7 Account Architecture — Classification Oracle (Module 3 Only)
The Classification Oracle is created per Module 3 mint at initialization. The authorized Classification relay polls Federal Register, USGS, and DOE feeds with redundancy and Ed25519-signs status updates. REG-42 federal-action variant reads this account on every Module 3 transfer.
```rust
#[account]
pub struct ClassificationOracle {
pub version: u8,
pub mint: Pubkey,
pub basin_id: [u8; 32], // Stable basin identifier
pub classification_status: u8, // bitfield: USGS-critical, DOE-critical, IRA-eligible, etc.
pub federal_action_active: bool,
pub federal_action_started_slot: u64, // Slot of detection (drives 60-min SLA timer)
pub federal_action_kind: u8, // 0=none, 1=Section232, 2=DPA-III, 3=EO, 4=USGS-list-change, 5=DOE-event
pub last_update_slot: u64,
pub relay_pubkey: Pubkey,
pub signature: [u8; 64],
pub bump: u8,
}
```
***
### 3.3 The 42 Core Security Controls
The 42 controls are organized into eight categories. Every applicable control executes on every transfer. The categories are not strictly sequential phases; most controls execute in parallel within the Anchor instruction. Sequential dependency exists only within the critical path (Controls CV-01 → CV-02 → CV-03 → CV-04 → HP-24).
#### 3.3.1 Category 1 — Custody Verification (CV-01 through CV-07, plus CV-38, CV-40)
Verify on every transfer that circulating token supply never exceeds the custodied backing-class shares held in Empire custody. Module-aware: backing class is Common B (M1), SAE equity (M2), or BAE equity (M3).
| # | Control Name | Trigger Condition | Enforcement Action | Error Code |
| ----- | ------------------------ | ------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------- | ---------- |
| CV-01 | Custody Oracle Check | Circulating supply would exceed `CustodyOracle.custodied_balance` | Reject — `CustodyDiscrepancy` | 6001 |
| CV-02 | Oracle Availability | Empire custody attestation > 400 ms stale | Reject — `CustodyOracleUnavailable` | 6002 |
| CV-03 | Supply Integrity | Total supply inconsistency detected across mint accounts | Reject — atomic revert | 6007 |
| CV-04 | Backing Class Match | `CustodyOracle.class_label` does not match expected for `SecurityConfig.module` (M1→CommonB; M2→SAE; M3→BAE) | Reject — `BackingClassMismatch` | 6008 |
| CV-05 | Asset Identifier Match | `SecurityConfig.asset_identifier` does not match the bound CUSIP (M1) / property ID (M2) / basin ID (M3) | Reject — `AssetIdentifierMismatch` | 6009 |
| CV-06 | Locked Balance | Transfer would draw from locked (holding-period) balance | Reject per HP-24 | 6024 |
| CV-07 | Precision Validation | Decimal precision exceeds mint-defined limit | Reject — `PrecisionError` | 6016 |
| CV-38 | Custody Discrepancy Halt | Token supply confirmed > custodied class shares (oracle verified) | Halt all transfers for affected mint indefinitely until manual reconciliation | 6038 |
| CV-40 | Oracle Consensus Failure | < 2 of 3 oracle feeds available for > 5 minutes | Halt affected hook category | 6040 |
```rust
// Control CV-01 — Custody Oracle Check
pub fn cv01_custody_check(
ctx: &Context,
transfer_amount: u64,
) -> Result<()> {
let oracle = &ctx.accounts.custody_oracle;
let mint = &ctx.accounts.mint;
// CV-02: oracle freshness
let current_slot = Clock::get()?.slot;
require!(
current_slot - oracle.last_update_slot <= 1, // ≤ 1 slot ≈ 400 ms
TransferHookError::CustodyOracleUnavailable
);
// CV-04: backing class consistency
let cfg = &ctx.accounts.security_config;
let expected_class = match cfg.module {
Module::Equities => AssetClass::CommonB,
Module::RealEstate => AssetClass::SAE,
Module::CORECM => AssetClass::BAE,
};
require!(
oracle.class_label == expected_class,
TransferHookError::BackingClassMismatch
);
// CV-05: asset identifier consistency (CUSIP / property_id / basin_id)
require_keys_eq!(
Pubkey::new_from_array(cfg.asset_identifier),
Pubkey::new_from_array(oracle.asset_identifier_hash()),
TransferHookError::AssetIdentifierMismatch
);
// Ed25519 signature verification via native precompile
verify_empire_attestation(
oracle.empire_pubkey,
&oracle.signature,
&(mint.key(), oracle.custodied_balance, oracle.class_label, oracle.last_update_slot),
)?;
// CV-01: 1:1 backing
require!(
mint.supply.saturating_add(transfer_amount) <= oracle.custodied_balance,
TransferHookError::CustodyDiscrepancy
);
Ok(())
}
```
#### 3.3.2 Category 2 — Sanctions and AML Compliance (SX-08 through SX-11)
OFAC/SDN real-time screening and AML risk scoring on every transfer — not just at onboarding. Empire Stock Transfer performs these checks at investor onboarding; SX-08 through SX-11 ensure they are re-applied on every subsequent transfer. A wallet that was clean at onboarding but later added to the OFAC SDN list is blocked immediately on its next transfer attempt.
| # | Control Name | Trigger Condition | Enforcement Action | Error Code |
| ----- | --------------------- | ---------------------------------------------------- | ----------------------------------------- | ---------- |
| SX-08 | OFAC Sender Screen | Sender wallet matches OFAC SDN list (updated hourly) | Reject permanently — `SenderSanctioned` | 6003 |
| SX-09 | OFAC Receiver Screen | Receiver wallet matches OFAC SDN list | Reject permanently — `ReceiverSanctioned` | 6004 |
| SX-10 | OFAC Oracle Staleness | OFAC SDN feed not updated within 90 minutes | Reject — `StaleSanctionsOracle` | 6005 |
| SX-11 | AML Risk Score | ML risk score for sender or receiver exceeds 70/100 | Reject — `HighRiskWallet` | 6006 |
```rust
// Control SX-11 — AML Risk Scoring (three-tier system)
pub fn sx11_aml_risk(risk_score: u8) -> Result {
match risk_score {
0..=30 => Ok(AMLDecision::Approve),
31..=70 => Ok(AMLDecision::EnhancedReview), // flag, don't reject
71..=100 => Err(TransferHookError::HighRiskWallet.into()),
_ => Err(TransferHookError::InvalidRiskScore.into()),
}
}
```
#### 3.3.3 Category 3 — Investor Eligibility and Holding Period (IV-12 through IV-19; HP-24)
Accreditation verification, KYB entity checks, and Reg D / Reg S / Reg CF holding-period enforcement on every transfer.
| # | Control Name | Trigger Condition | Enforcement Action | Error Code |
| ----- | ---------------------- | ------------------------------------------------------------------------------- | ------------------------------------- | ---------- |
| IV-12 | Accreditation Check | Buyer wallet not in Empire's verified accredited investor registry (Reg D path) | Reject — accreditation required | 6010 |
| IV-13 | KYC Status Check | Buyer or seller KYC status expired or flagged in Empire system | Reject — re-verification required | 6011 |
| IV-14 | KYB Entity Check | Entity investor UBO verification lapsed or flagged | Reject — KYB re-verification required | 6012 |
| IV-15 | Wallet Registration | Destination wallet not registered in Empire MSF | Reject — `UnregisteredWallet` | 6013 |
| IV-16 | Redemption Eligibility | Redemption transaction: KYC completion and accreditation not current | Reject — `KYCInvalid` | 6014 |
| IV-17 | Jurisdiction Flag | Wallet jurisdiction flag missing or invalid | Reject — `JurisdictionUnknown` | 6017 |
| IV-18 | Reg S US Person Check | Non-US wallet attempting US-market transaction during compliance period | Reject — Reg S restriction | 6018 |
| IV-19 | Reg CF Investor Limit | Reg CF investor total annual investment exceeds JOBS Act §4(a)(6) statutory cap | Reject — `RegCFLimitExceeded` (V10) | 6019 |
| HP-24 | Holding Period Lock | `purchase_timestamp + holding_period_secs > current_timestamp` | Reject — `TokensLocked` | 6024 |
**Control HP-24 Deep Dive — Reg D / Reg S / Reg CF On-Chain Enforcement**
Control HP-24 is the mechanism that makes the platform's issuance model legally compliant without relying on investor self-discipline or post-hoc regulatory action. It is the on-chain expression of the mandatory holding periods that securities law imposes on restricted security holders. V10 extends V7's two-jurisdiction model (US/NonUS) to a three-jurisdiction model (Reg D / Reg S / Reg CF).
```rust
// Control HP-24 — Holding Period Enforcement (V10)
pub fn hp24_check_holding_period(
ctx: Context,
transfer_amount: u64,
) -> Result<()> {
let holding = &ctx.accounts.holding_period_account;
let current_ts = Clock::get()?.unix_timestamp;
let required_period = match holding.jurisdiction {
Jurisdiction::RegD => RULE_144_HOLDING_SECS, // 15_778_800 s (6 months)
Jurisdiction::RegS => REG_S_COMPLIANCE_SECS, // 31_536_000 s (12 months)
Jurisdiction::RegCF => REG_CF_HOLDING_SECS, // 31_536_000 s (12 months)
};
let elapsed = current_ts - holding.purchase_timestamp;
require!(
elapsed >= required_period,
TransferHookError::TokensLocked // Error 6024
);
// CV-06 cross-check: locked-balance view
require!(
!holding.is_locked || elapsed >= required_period,
TransferHookError::LockedBalanceDrawdown
);
Ok(())
}
```
**Certora invariant E.5** formally proves that no execution path can shorten the holding-period timer once the `HoldingPeriodAccount` is created. The `purchase_timestamp` field is set exactly once at token delivery and is never written after.
#### 3.3.4 Category 4 — Position Limits (PL-20 through PL-23, PL-25)
Wallet concentration caps and per-investor limits.
| # | Control Name | Trigger Condition | Enforcement Action | Error Code |
| ----- | ---------------------- | ----------------------------------------------------------------------- | ----------------------------- | ---------- |
| PL-20 | Wallet Cap (statutory) | Receiver wallet would exceed `max_wallet_percent` of circulating supply | Reject — `WalletCapExceeded` | 6020 |
| PL-22 | Single-Trade Cap | Trade size > 0.5% of total supply | Reject — `TradeSizeExcessive` | 6022 |
| PL-23 | Daily Wallet Activity | Same wallet > 50 transfers/day | Reject — `WalletActivityCap` | 6023 |
| PL-25 | Cooldown | Sender wallet last transferred < `cooldown_secs` ago | Reject — `CooldownActive` | 6025 |
Default `max_wallet_percent = 999` basis points (9.99%). Per Module 2 commercial use case, `max_wallet_percent` is configurable per mint via tripartite-concurrence governance up to 9.99%; per Module 1 OTC microcap default is 4.99% (statutorily aligned with §13(d) reporting threshold sensitivity).
#### 3.3.5 Category 5 — Circuit Breakers (CB-21, CB-26, CB-27)
Price, volume, and oracle-failure circuit breakers. **CB-21 has a Module 2 module-aware variant** documented in Section 3.4.
| # | Control Name | Trigger Condition | Enforcement Action | Error Code |
| ------------------ | ----------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------- | ---------- |
| CB-21 | Price Halt (core) | Price moves > 10% from TWAP in 5-minute window | Halt all trades 5 minutes | 6021 |
| CB-21 (M2 variant) | NAV Deviation | `\|on_chain_price − NAV\| / NAV > nav_deviation_max_bps / 10000` OR NAV oracle stale beyond `reappraisal_cadence_secs` | Reject — `NavDeviationExceeded` | 6021-NAV |
| CB-26 | Price Impact | Single trade impacts price > 2% vs TWAP | Reject — `PriceImpactExceeded` | 6026 |
| CB-27 | Volume Halt | Daily sell volume > 30% of average daily volume | Halt all sell trades 24 hours | 6027 |
#### 3.3.6 Category 6 — Holding Period Adjacent (HP-26 through HP-33)
Eight controls related to holding-period accounting, including stake-period accounting (where applicable post-graduation) and beneficiary updates.
| # | Control Name | Purpose |
| ----- | -------------------------------- | --------------------------------------------------------------------- |
| HP-26 | Holding-period account existence | Verify HoldingPeriodAccount PDA exists for `(mint, beneficiary)` |
| HP-27 | Cross-mint isolation | Holding-period account binds to one mint only |
| HP-28 | Beneficiary identity | Beneficiary must match wallet performing transfer initiation |
| HP-29 | Account version | Schema version field validation (≥ 7) |
| HP-30 | Locked-flag consistency | `is_locked` derives from time math; cannot be unset by admin |
| HP-31 | Re-onboarding window | New `HoldingPeriodAccount` requires Empire re-attestation |
| HP-32 | Multi-jurisdiction guard | Investor cannot hold same mint under two jurisdictions simultaneously |
| HP-33 | Jurisdiction immutability | `jurisdiction` field is write-once at account creation |
#### 3.3.7 Category 7 — Sanctions & Conversion (SX-34 through SX-37, PC-38 through PC-40)
OFAC re-screening on conversion events and protective conversion controls.
| # | Control Name | Purpose |
| ----- | --------------------------------- | ----------------------------------------------------------------------------------- |
| SX-34 | Conversion-time OFAC re-check | Re-run OFAC at any redemption / burn / conversion event |
| SX-35 | Conversion KYC re-check | KYC must be current at conversion |
| SX-36 | Conversion accreditation re-check | Reg D investor must remain accredited at conversion (Reg D only) |
| SX-37 | Conversion jurisdiction stability | Jurisdiction at conversion = jurisdiction at acquisition |
| PC-38 | Custodied class verification | Conversion must produce equivalent custodied class (M1: Common B; M2: SAE; M3: BAE) |
| PC-39 | Conversion-time supply integrity | Burn/mint atomicity at conversion |
| PC-40 | Conversion audit emission | GA-42 emission per conversion event |
#### 3.3.8 Category 8 — Governance and Emergency (GA-41, GA-42, REG-42)
Audit emission and Regulatory Freeze. **REG-42 has a Module 3 module-aware variant** documented in Section 3.4.
| # | Control Name | Trigger Condition | Enforcement Action | Error Code |
| ------------------- | -------------------------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------- | ---------- |
| GA-41 | Audit-Log Pre-Validation | Pre-execution emission of `(mint, beneficiary, amount, control results)` digest | Continue (emission cannot fail; CB if storage exhausted) | 6041 |
| GA-42 | Audit-Log Emission | Post-execution emission of full control evaluation set | Continue | 6042-AUD |
| REG-42 | Regulatory Freeze (manual) | Legal Counsel signoff + 3-of-5 multi-sig invocation | Halt all transfers on affected mint | 6042 |
| REG-42 (M3 variant) | Federal-Action Freeze | `ClassificationOracle.federal_action_active = true` for the mint | Auto-freeze with 60-minute SLA from detection; auto-resume on `false` | 6042-FED |
```rust
// Control GA-42 — Audit Log Emission (post-execution)
emit!(TransferAudit {
mint: ctx.accounts.mint.key(),
sender: ctx.accounts.source.key(),
receiver: ctx.accounts.destination.key(),
amount: transfer_amount,
slot: Clock::get()?.slot,
module: cfg.module as u8,
control_results: ControlResults {
cv: control_cv_results.to_bitfield(),
sx: control_sx_results.to_bitfield(),
iv: control_iv_results.to_bitfield(),
pl: control_pl_results.to_bitfield(),
cb: control_cb_results.to_bitfield(),
hp: control_hp_results.to_bitfield(),
ga: control_ga_results.to_bitfield(),
// V10: module-aware extension results
cb21_nav_variant: ext_cb21_nav_result, // M2 only; Pass=true for M1, M3
reg42_federal_variant: ext_reg42_federal_result, // M3 only; Pass=true for M1, M2
},
});
```
***
### 3.4 Module-Aware Extensions (V10)
V10 introduces two module-aware Transfer Hook extensions that plug into the immutable 42-control surface as additive runtime checks. The 42 core controls do not change; the extensions execute alongside them when applicable to the mint's `module` classification. Existing V8 mints with `module = 1` (Equities) execute exactly as in V8 — the extensions are dormant for them. **Certora invariant E.4** formally proves that the module-aware extensions cannot be removed or weakened post-deployment.
#### 3.4.1 CB-21 NAV-Deviation Variant — Module 2 (Real Estate)
Trigger: any Module 2 transfer when the on-chain trade price deviates from the Module 2 NAV Oracle's `nav_per_token` by more than `SecurityConfig.nav_deviation_max_bps` (default 2,200 = 22%) OR when the NAV Oracle attestation is older than `SecurityConfig.reappraisal_cadence_secs` (default 7,776,000 = 90 days).
```rust
// CB-21 NAV-Deviation Variant (Module 2 only)
pub fn ext_cb21_nav_deviation(
ctx: &Context,
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)?;
let now_ts = Clock::get()?.unix_timestamp;
let now_slot = Clock::get()?.slot;
// Reappraisal cadence enforcement
require!(
now_ts - nav_oracle.last_appraisal_ts <= cfg.reappraisal_cadence_secs,
TransferHookError::NavReappraisalOverdue // 6021-NAV-STALE
);
// NAV oracle slot freshness (per-block)
require!(
now_slot - nav_oracle.last_update_slot <= 1,
TransferHookError::NavOracleStale // 6021-NAV-STALE
);
// Ed25519 verify NAV attestation
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 (basis points; u128 overflow-safe)
let nav = nav_oracle.nav_per_token as u128;
let price = transfer_price as u128;
let deviation_num = if price > nav { price - nav } else { nav - price };
let deviation_bps = (deviation_num
.checked_mul(10_000)
.ok_or(TransferHookError::ArithmeticOverflow)?
.checked_div(nav)
.ok_or(TransferHookError::ArithmeticOverflow)?) as u16;
require!(
deviation_bps <= cfg.nav_deviation_max_bps,
TransferHookError::NavDeviationExceeded // 6021-NAV
);
Ok(())
}
```
**Why 22% default deviation tolerance.** The 22% default `nav_deviation_max_bps` reflects the platform's fractionalization-premium pricing model: ST22 Module 2 tokens trade at up to 22% premium over the underlying property NAV to account for (a) liquidity premium of 24/7/365 secondary trading, (b) fractionalization convenience versus owning a whole property, (c) ongoing platform compliance and §17A custody costs, and (d) the protocol fee structure. The CB-21 NAV-deviation variant prevents trades from drifting outside this tolerance band, which would either undermine the NAV-bound investor protection (price falls too far below NAV, signaling distress) or signal market-manipulation activity (price spikes above NAV without underlying property revaluation). The 22% can be tightened (never loosened beyond statutory ceiling) per mint via tripartite concurrence governance.
#### 3.4.2 REG-42 Federal-Action Variant — Module 3 (CORECM)
Trigger: any Module 3 transfer when `ClassificationOracle.federal_action_active = true`. Enforcement: automatic freeze with 60-minute SLA from detection. Resume: automatic when `federal_action_active` returns to `false`.
```rust
// REG-42 Federal-Action Variant (Module 3 only)
pub fn ext_reg42_federal_action(
ctx: &Context,
) -> Result<()> {
let cfg = &ctx.accounts.security_config;
if cfg.module != Module::CORECM { return Ok(()); }
if !cfg.federal_action_freeze_enabled { return Ok(()); }
let class_oracle = ctx.accounts.classification_oracle
.as_ref()
.ok_or(TransferHookError::ClassificationOracleMissing)?;
let now_ts = Clock::get()?.unix_timestamp;
let now_slot = Clock::get()?.slot;
// Classification staleness enforcement
require!(
now_ts - class_oracle.last_update_slot_to_ts() <= cfg.classification_max_age_secs,
TransferHookError::ClassificationOracleStale // 6042-FED-STALE
);
// Ed25519 verify classification attestation
verify_classification_attestation(
class_oracle.relay_pubkey,
&class_oracle.signature,
&(cfg.mint, class_oracle.basin_id, class_oracle.federal_action_active,
class_oracle.federal_action_kind, class_oracle.last_update_slot),
)?;
// Federal-action active → reject
require!(
!class_oracle.federal_action_active,
TransferHookError::FederalActionActive // 6042-FED
);
Ok(())
}
```
**The 60-minute SLA**: detection-to-enforcement latency is bounded by (a) the Classification relay polling cycle, (b) Ed25519 signing latency, (c) Solana transaction confirmation, and (d) on-chain attestation propagation. The Classification relay polls Federal Register, USGS, and DOE feeds with redundant subscriptions; on detection of a qualifying event affecting any monitored basin asset, the relay signs and submits a `ClassificationOracle` update within ≤ 30 minutes operational target. The remaining 30 minutes is reserved for Solana network latency, monitoring confirmation, and incident-response paging (Incident Response Playbook §13).
**Federal action kinds tracked** (`federal_action_kind` field):
| Kind | Code | Source |
| ------------------------------------------ | ---- | ----------------------------------------- |
| Section 232 of Trade Expansion Act of 1962 | 1 | Federal Register, Office of the President |
| Defense Production Act Title III | 2 | DOD, DOE federal-investment notices |
| Executive Order (e.g., EO 14017) | 3 | Federal Register, White House |
| USGS Critical Minerals List change | 4 | USGS publication |
| DOE Critical Materials Strategy event | 5 | DOE publication |
***
### 3.5 Implementation: The Main Transfer Hook Entry Point
```rust
// programs/transfer_hook/src/instructions/transfer_hook.rs
#[derive(Accounts)]
pub struct TransferHook<'info> {
#[account(seeds = [b"security-config", mint.key().as_ref()], bump = security_config.bump)]
pub security_config: Account<'info, SecurityConfig>,
#[account(seeds = [b"custody-oracle", mint.key().as_ref()], bump = custody_oracle.bump)]
pub custody_oracle: Account<'info, CustodyOracle>,
#[account(seeds = [b"holding-period", mint.key().as_ref(), beneficiary.as_ref()], bump)]
pub holding_period_account: Account<'info, HoldingPeriodAccount>,
pub mint: AccountInfo<'info>,
pub source: AccountInfo<'info>,
pub destination: AccountInfo<'info>,
pub beneficiary: AccountInfo<'info>,
// V10: optional module-aware oracle accounts (loaded conditionally on module)
#[account(seeds = [b"nav-oracle", mint.key().as_ref()], bump)]
pub nav_oracle: Option>, // Module 2
#[account(seeds = [b"classification-oracle", mint.key().as_ref()], bump)]
pub classification_oracle: Option>, // Module 3
pub ofac_oracle: Account<'info, OfacOracle>,
pub aml_oracle: Account<'info, AmlOracle>,
pub twap_oracle: Account<'info, TwapOracle>,
}
pub fn execute(ctx: Context, amount: u64, transfer_price: u64) -> Result<()> {
let cfg = &ctx.accounts.security_config;
// Pause check
require!(!cfg.is_paused, TransferHookError::SystemPaused);
// Category 1: Custody Verification (CV-01..07, CV-38, CV-40)
cv01_custody_check(&ctx, amount)?;
cv03_supply_integrity(&ctx)?;
cv07_precision_validation(&ctx, amount)?;
cv38_custody_discrepancy_halt_check(&ctx)?;
cv40_oracle_consensus_check(&ctx)?;
// Category 2: Sanctions & AML (SX-08..11)
sx08_ofac_sender(&ctx)?;
sx09_ofac_receiver(&ctx)?;
sx10_ofac_freshness(&ctx)?;
sx11_aml_risk(ctx.accounts.aml_oracle.risk_score)?;
// Category 3: Investor Eligibility & Holding Period (IV-12..19, HP-24)
iv12_accreditation(&ctx)?;
iv13_kyc_status(&ctx)?;
iv14_kyb_entity(&ctx)?;
iv15_wallet_registration(&ctx)?;
iv16_redemption_eligibility(&ctx)?;
iv17_jurisdiction_flag(&ctx)?;
iv18_reg_s_us_person(&ctx)?;
iv19_reg_cf_investor_limit(&ctx)?; // V10
hp24_check_holding_period(ctx.clone(), amount)?;
// Category 4: Position Limits (PL-20, PL-22, PL-23, PL-25)
pl20_wallet_cap(&ctx, amount)?;
pl22_single_trade_cap(&ctx, amount)?;
pl23_daily_wallet_activity(&ctx)?;
pl25_cooldown(&ctx)?;
// Category 5: Circuit Breakers (CB-21 core, CB-26, CB-27)
cb21_price_halt(&ctx, transfer_price)?;
cb26_price_impact(&ctx, transfer_price)?;
cb27_volume_halt(&ctx, amount)?;
// Category 6: Holding Period Adjacent (HP-26..33)
hp26_through_hp33_adjacent_checks(&ctx)?;
// Category 7: Sanctions/Conversion (SX-34..37, PC-38..40)
sx34_through_sx37_conversion_resanction(&ctx)?;
pc38_custodied_class_verify(&ctx)?;
pc39_through_pc40_conversion_audit(&ctx)?;
// Category 8: Governance & Emergency (GA-41, GA-42, REG-42)
ga41_audit_pre(&ctx, amount)?;
reg42_manual_freeze_check(&ctx)?;
// V10: Module-Aware Extensions
ext_cb21_nav_deviation(&ctx, transfer_price)?; // M2 only; passes for M1, M3
ext_reg42_federal_action(&ctx)?; // M3 only; passes for M1, M2
// GA-42 audit emission (post-execution)
ga42_audit_emit(&ctx, amount, transfer_price)?;
Ok(())
}
```
***
### 3.6 Compute Unit Budget by Module
Solana's compute-unit (CU) budget is finite per transaction (default 200,000 CU; max 1,400,000 CU). The 42 core controls plus oracle reads consume the bulk of the budget. Module-aware extensions add module-specific oracle reads.
| Module | Core 42 Controls | Module-Aware Extension | Total Budget Target |
| ---------------------- | ---------------- | ------------------------------------------------------------------------ | ------------------- |
| Module 1 (Equities) | \~770,000 CU | None applicable (CV-04 skips ext oracle reads) | \~800,000 CU |
| Module 2 (Real Estate) | \~770,000 CU | + NAV oracle read + Ed25519 verify + deviation math ≈ 50,000 CU | \~820,000 CU |
| Module 3 (CORECM) | \~770,000 CU | + Classification oracle read + Ed25519 verify + status check ≈ 60,000 CU | \~830,000 CU |
Per-control budgets are validated under load testing (Testing Guide §11). The `requestUnits` instruction is included in every CEDEX transaction with the appropriate per-module budget.
***
### 3.7 Error Code Registry (V10)
| Code | Name | Layer | Module |
| -------------- | -------------------------------------- | ---------------------- | ---------------------------- |
| 6001 | CustodyDiscrepancy | CV-01 | All |
| 6002 | CustodyOracleUnavailable | CV-02 | All |
| 6003 | SenderSanctioned | SX-08 | All |
| 6004 | ReceiverSanctioned | SX-09 | All |
| 6005 | StaleSanctionsOracle | SX-10 | All |
| 6006 | HighRiskWallet | SX-11 | All |
| 6007 | SupplyInconsistency | CV-03 | All |
| 6008 | BackingClassMismatch | CV-04 | All |
| 6009 | AssetIdentifierMismatch | CV-05 | All |
| 6010 | AccreditationRequired | IV-12 | M1, M2, M3 (Reg D path) |
| 6011 | KYCInvalid | IV-13 | All |
| 6012 | KYBLapsed | IV-14 | All (entity investors) |
| 6013 | UnregisteredWallet | IV-15 | All |
| 6014 | RedemptionKYCInvalid | IV-16 | All |
| 6016 | PrecisionError | CV-07 | All |
| 6017 | JurisdictionUnknown | IV-17 | All |
| 6018 | RegSRestriction | IV-18 | All (Reg S investors) |
| 6019 | RegCFLimitExceeded | IV-19 | All (Reg CF investors) — V10 |
| 6020 | WalletCapExceeded | PL-20 | All |
| 6021 | PriceHalt (core) | CB-21 | All |
| 6021-NAV | NavDeviationExceeded | CB-21 NAV variant | M2 only |
| 6021-NAV-STALE | NavReappraisalOverdue / NavOracleStale | CB-21 NAV variant | M2 only |
| 6022 | TradeSizeExcessive | PL-22 | All |
| 6023 | WalletActivityCap | PL-23 | All |
| 6024 | TokensLocked | HP-24 | All |
| 6025 | CooldownActive | PL-25 | All |
| 6026 | PriceImpactExceeded | CB-26 | All |
| 6027 | VolumeHalt | CB-27 | All |
| 6038 | CustodyDiscrepancyHalt | CV-38 | All |
| 6040 | OracleConsensusFailure | CV-40 | All |
| 6041 | AuditPreEmissionFailure | GA-41 | All |
| 6042 | RegulatoryFreeze (manual) | REG-42 | All |
| 6042-FED | FederalActionActive | REG-42 federal variant | M3 only |
| 6042-FED-STALE | ClassificationOracleStale | REG-42 federal variant | M3 only |
***
### 3.8 Formal Verification Mapping
The Transfer Hook is covered by the following Certora invariants:
| Invariant | Statement | Coverage |
| --------- | -------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------ |
| **E.1** | For every issued ST22 token there exists a 1:1 custodied equity share of the appropriate class (CommonB / SAE / BAE) | CV-01, CV-04 |
| **E.2** | No execution path exists by which a Transfer Hook control or applicable module-aware extension can be bypassed | All controls + extensions |
| **E.4** | The 42 core controls and module-aware extensions cannot be removed, weakened, or repointed post-deployment | Program upgrade authority bound to mint creation |
| **E.5** | The HoldingPeriodAccount holding-period timer cannot be shortened by any execution path | HP-24, HP-30, HP-33 |
| **E.6** | The Transfer Hook program ID for a given mint cannot be changed post-creation | Token-2022 transfer-hook extension immutability |
Specifications and verification reports are reproducible from the public program IR.
***
*RWA Tokens Whitepaper V10 — Section 3 — Confidential — Groovy Company, Inc.*
# Global Unified Liquidity Pool — Layer 4
## Section 4: Global Unified Liquidity Pool — Layer 4
**RWA Tokens Platform Whitepaper · Version 10.0** **Groovy Company, Inc. · May 2026** **Document Reference:** RWA-LP-SPEC-001 v2.0
The Global Unified Liquidity Pool ("Global Pool") is the platform's protocol-owned permanent liquidity infrastructure. A single shared CPMM pool serves all three modules (Equities, Real Estate, CORECM). LP tokens representing the protocol's pool position are burned at inception. The pool is non-extractable: Certora invariant E.3 formally proves no execution path exists by which the pool's reserves can be debited to a withdrawal destination.
***
### 4.1 Architectural Position and Purpose
The Global Pool occupies Layer 4. It depends on Layer 1 (Solana), Layer 2 (Transfer Hook — every pool interaction is a transfer subject to controls), Layer 3 (Core Protocol PDAs), and Layer 6 (oracle freshness signals). It is consumed by Layer 5 (CEDEX matching/settlement).
| Property | Value |
| --------------------------- | ----------------------------------------------------------- |
| Pool design | Single shared CPMM serving all three modules |
| Stablecoin reserve | USDC + PYUSD aggregate balance |
| ST22 reserve | Cross-module token-mix (M1 + M2 + M3 mints) |
| LP tokens | Burned at inception |
| Withdrawal mechanism | None (Certora E.3) |
| Self-reinforcement | 0.44% of every CEDEX trade adds to permanent locked reserve |
| Cross-module network effect | Volume in any module deepens liquidity for all modules |
***
### 4.2 Why Protocol-Owned, Permanent Liquidity
#### 4.2.1 The Market-Maker Withdrawal Problem
Conventional ATS / DEX architectures rely on third-party market makers to provide bid/ask liquidity. Market makers can withdraw at any time. Withdrawal is the single largest source of liquidity-collapse risk in tokenized-securities trading. Empirical events:
* Securitize Markets ATS — multiple per-issuer market-maker withdrawal events documented across 2024–2025
* Republic Block ATS (CrowdSafe) — sustained periods of zero bid liquidity for listed issuers
* INX exchange — multiple delistings driven by market-maker exit
* ERC-3643 secondary markets — heavy reliance on issuer-funded liquidity that depletes over time
The platform's architectural answer is: **eliminate the market-maker entirely**. The Global Pool is the market maker. It cannot withdraw because the LP tokens are burned and there is no withdrawal function.
#### 4.2.2 Certora Invariant E.3 — Pool Non-Extractability
The Certora Prover suite formally proves invariant E.3:
**E.3 Statement:** *For all possible execution traces of the platform's Solana programs, no instruction sequence exists that debits the Global Pool's reserves to any account other than (a) a buyer's wallet receiving ST22 from a swap, or (b) a seller's wallet receiving stablecoin from a swap, both subject to the constant-product invariant `x · y ≥ k` being preserved post-trade modulo accumulated fees.*
The proof covers:
* The `liquidity_pool` program — verified that no `withdraw_lp_tokens` instruction exists, and that no instruction debits reserves outside swap-in-fee-out flows
* The `amm` program — verified that swap math preserves `x · y ≥ k`
* The `governance` program — verified that no governance proposal type can mint new LP tokens or create a withdrawal pathway
* Upgrade authority — verified that the program upgrade authority's permitted operations cannot introduce a withdrawal function (program logic that would do so is rejected by the timelock-policy specification)
This is what makes "the pool cannot rugpull" a mathematical guarantee rather than a marketing claim.
***
### 4.3 Pool Schema and Account Architecture
#### 4.3.1 LiquidityPool PDA
```rust
#[account]
pub struct LiquidityPool {
pub version: u8, // 10
pub authority: Pubkey, // 3-of-5 multi-sig (config only — cannot withdraw)
pub stablecoin_reserve: u64, // USDC + PYUSD aggregate, in 1e6 base units
pub st22_reserve: u64, // Aggregate ST22 reserve across modules (in mint-base units)
pub k_invariant: u128, // Last-recorded k = stablecoin_reserve · st22_reserve
pub permanent_locked_share: u64, // Cumulative 0.44% locked from all trades
pub fee_bps_total: u16, // 500 = 5.0%
pub fee_bps_locked: u16, // 44 = 0.44%
pub last_update_slot: u64,
pub bump: u8,
}
```
Note: `k_invariant` is recorded post-trade for monitoring. The CPMM swap path enforces `x · y ≥ k` at execution; deviation alerts trigger compliance review.
#### 4.3.2 Per-Mint Pool Accounting
The shared pool tracks per-mint position via inner accounting:
```rust
#[account]
pub struct PoolMintPosition {
pub mint: Pubkey,
pub module: Module, // 1, 2, or 3
pub st22_balance: u64, // ST22 of this mint held in pool reserves
pub cumulative_volume: u128, // Lifetime trading volume against this mint
pub cumulative_fees_locked: u64, // Cumulative 0.44% locked from this mint's trades
pub last_update_slot: u64,
pub bump: u8,
}
```
Per-mint `PoolMintPosition` accounts are PDAs seeded by `[b"pool-mint", mint.key().as_ref()]`.
***
### 4.4 Pool Initialization and Seeding
#### 4.4.1 Seeding Sources
The pool is initialized at platform genesis with seed liquidity from five sources:
| Source | Mechanism | Approximate Magnitude |
| --------------------------------------- | ------------------------------------------------------------------------- | --------------------- |
| 1. Groovy Security Token (STO) proceeds | $20M Reg D raise; net proceeds routed to Solana Treasury → Global Pool | $20M |
| 2. Initial Staking Pool allocation | Designated portion of pre-graduation staking accumulation | Variable |
| 3. CEDEX permanent lock | 0.44% of every CEDEX trade from inception | Cumulative; growing |
| 4. Investor secondary sale proceeds | Optional — issuers can route a portion of secondary-sale fees to the pool | Per-issuer election |
| 5. Staking reward reinvestment | 2% of staking rewards reinvested into pool depth | Variable |
#### 4.4.2 LP Burn at Inception
```rust
// Pseudo-code: pool initialization with LP burn
pub fn initialize_pool(
ctx: Context,
initial_stablecoin: u64,
initial_st22_seed_amounts: Vec<(Pubkey, u64)>, // (mint, amount) pairs
) -> Result<()> {
// 1. Validate authority (3-of-5 multi-sig + timelock for governance)
require!(verify_multisig(...), Error::Unauthorized);
// 2. Transfer stablecoin reserves into pool PDA
transfer_stablecoin_to_pool(ctx.accounts.source_stable, ctx.accounts.pool_stable_vault, initial_stablecoin)?;
// 3. Transfer ST22 seed amounts (per-mint)
for (mint, amount) in initial_st22_seed_amounts {
transfer_st22_to_pool(mint, amount)?;
// Initialize PoolMintPosition for this mint
init_pool_mint_position(mint, amount)?;
}
// 4. Mint LP tokens to platform
let lp_minted = compute_initial_lp_supply(initial_stablecoin, initial_st22_seed_amounts);
mint_lp_to(ctx.accounts.platform_lp_account, lp_minted)?;
// 5. **BURN ALL LP TOKENS**
burn_lp_tokens(ctx.accounts.platform_lp_account, lp_minted)?;
// After this point, lp_supply = 0
// No execution path exists to withdraw reserves — Certora E.3
// 6. Record invariant
let pool = &mut ctx.accounts.pool;
pool.stablecoin_reserve = initial_stablecoin;
pool.st22_reserve = initial_st22_seed_amounts.iter().map(|(_, a)| *a).sum();
pool.k_invariant = (pool.stablecoin_reserve as u128) * (pool.st22_reserve as u128);
Ok(())
}
// CRITICALLY: there is NO `withdraw_liquidity` instruction in the program.
// Removing this instruction from the program is what makes E.3 hold.
```
***
### 4.5 CPMM Swap Math (Pool-Specific)
The pool implements the same CPMM math documented in Section 7 (CEDEX) but at the pool-program level. The swap is initiated by CEDEX's `amm` program; the `liquidity_pool` program is the counterparty:
```rust
// Swap: stablecoin in, ST22 out (buy direction)
pub fn swap_buy(
ctx: Context,
mint: Pubkey, // ST22 mint being bought
stablecoin_in: u64,
min_st22_out: u64, // slippage protection
) -> Result<()> {
let pool = &mut ctx.accounts.pool;
let pool_mint = &mut ctx.accounts.pool_mint_position;
// Invariant pre-check
let x_pre = pool.stablecoin_reserve as u128;
let y_pre = pool_mint.st22_balance as u128;
let k_pre = x_pre.checked_mul(y_pre).ok_or(Error::Overflow)?;
// Fee math
let fee_factor = 10_000u128 - 500u128; // 9500 (5% total fee deducted)
let stablecoin_in_u128 = stablecoin_in as u128;
let numerator = y_pre
.checked_mul(stablecoin_in_u128).ok_or(Error::Overflow)?
.checked_mul(fee_factor).ok_or(Error::Overflow)?;
let denominator = x_pre
.checked_mul(10_000).ok_or(Error::Overflow)?
.checked_add(stablecoin_in_u128.checked_mul(fee_factor).ok_or(Error::Overflow)?)
.ok_or(Error::Overflow)?;
let st22_out = numerator.checked_div(denominator).ok_or(Error::DivisionByZero)? as u64;
// Slippage check
require!(st22_out >= min_st22_out, Error::SlippageExceeded);
// Execute transfer (subject to Transfer Hook on the ST22 leg)
transfer_stablecoin(stablecoin_in)?;
transfer_st22(mint, st22_out)?; // ← Token-2022 invokes Transfer Hook here
// Update reserves
pool.stablecoin_reserve += stablecoin_in;
pool_mint.st22_balance -= st22_out;
// Distribute the 5% fee (see Section 7.5.2)
let fee_total = stablecoin_in.checked_mul(500).ok_or(Error::Overflow)? / 10_000;
distribute_fees(fee_total, ctx)?;
// 0.44% portion stays in the pool — this is the permanent lock mechanic
let locked_portion = stablecoin_in.checked_mul(44).ok_or(Error::Overflow)? / 10_000;
pool.permanent_locked_share += locked_portion;
pool_mint.cumulative_fees_locked += locked_portion;
// Invariant post-check (modulo locked portion)
let x_post = pool.stablecoin_reserve as u128;
let y_post = pool_mint.st22_balance as u128;
let k_post = x_post.checked_mul(y_post).ok_or(Error::Overflow)?;
require!(k_post >= k_pre, Error::InvariantViolation);
pool.k_invariant = k_post;
Ok(())
}
```
The 0.44% locked-fee portion is mathematically equivalent to "raising k" — it grows the pool's product invariant on every trade, which monotonically deepens liquidity over time.
***
### 4.6 Self-Reinforcing Growth Mathematics
Let `V_t` be cumulative trading volume through time `t`, `r = 0.0044` be the locked-fee rate, and `L_0` be initial pool liquidity (depth). Then:
```
L_t ≥ L_0 + r · V_t
```
The pool depth strictly increases with cumulative volume. Slippage decreases as a function of pool depth, which reduces friction for institutional volume, which deepens the pool further. The dynamic is positively self-reinforcing.
For a pool with constant-product reserves `x · y = k`, the implied price-impact slope at a trade size `Δx` is approximately:
```
slippage(Δx) ≈ Δx / x
```
Doubling pool depth (`x` doubles) halves slippage at the same trade size. The 0.44% locked-fee rate has compounding effect over volume horizons measured in years.
***
### 4.7 Cross-Module Network Effect
Because the pool is shared across all three modules, trading volume in any module deepens liquidity for all modules. Concretely:
* A Module 3 BAE basin tokenization with $50M annual trading volume contributes $220K (0.44%) to the pool's permanent locked share.
* That deepening supports a Module 1 OTC microcap issuer with $500K daily volume by providing more reserve depth against slippage.
* Module 2 SAE real-estate trades benefit from the same shared depth.
This contradicts conventional AMM design, where each token pair has an isolated pool. The contradiction is intentional: it produces a **cross-asset-class liquidity network effect** that no per-mint or per-product pool architecture can replicate. ERC-3643 platforms (Securitize, Tokeny) and ATS architectures (Securitize Markets, INX) are per-product isolated; they cannot harvest cross-asset-class network effects.
***
### 4.8 Pool Health Monitoring and Alerts
| Metric | Healthy Range | Alert Threshold |
| ----------------------------------- | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| Pool TVL (stablecoin reserve) | Growing monotonically | Decreased TVL flag (anomaly only — pool cannot decrease through normal operation; locked-share decrease is impossible) |
| `k_invariant` | Monotonically non-decreasing | Decrease flagged → critical compliance alert |
| Per-mint slippage at 0.5% TVL trade | < 100 bps | > 200 bps → consider pool seeding addition |
| Cross-module reserve concentration | Diversified | > 80% of ST22 reserve in single mint → concentration alert |
| Stablecoin / ST22 ratio | Stable around long-run mean | Sharp deviation → market-condition alert |
| Locked share growth rate | Tracks volume × 0.44% | Deviation → fee-distribution audit |
The platform's monitoring (Datadog + PagerDuty per ADR-008) emits metrics at every pool interaction. Anomalies trigger compliance officer review.
***
### 4.9 Pool and Transfer Hook Interaction
Every pool interaction is a transfer subject to the Transfer Hook:
| Pool Action | Transfer Hook Invocation |
| ------------------------------ | ----------------------------------------------------------------------------------------------------------- |
| Buy (stablecoin in, ST22 out) | Transfer Hook fires on ST22 leg from pool to buyer; all 42 controls + applicable module extensions execute |
| Sell (ST22 in, stablecoin out) | Transfer Hook fires on ST22 leg from seller to pool; all 42 controls + applicable module extensions execute |
| Initial seeding (LP burn flow) | Transfer Hook fires when ST22 enters pool from platform treasury; controls verify supply integrity |
This means: a Module 2 trade against the pool will execute Control CB-21 NAV-deviation variant; a Module 3 trade against the pool will execute Control REG-42 federal-action variant; a Module 1 trade will execute only the 42 core controls. The pool itself does not implement module-aware logic; the Transfer Hook does, and the pool's swap path correctly invokes it.
***
### 4.10 Pool Adjacency: Staking Rewards Reinvestment
A separate but related mechanism: 2% of staking rewards are reinvested into pool depth. The staking program holds GROO Utility Token stakes; rewards accrue per the staking schedule; 2% of accrued rewards are converted (off-chain or via designated DEX) to USDC and added to the pool's stablecoin reserve. This further deepens the pool independently of CEDEX trading volume.
***
### 4.11 Comparison vs Alternative Liquidity Architectures
| Liquidity Source | Withdrawal Risk | Depth Growth | Cross-Asset-Class | Adopted By |
| --------------------------------- | --------------------------- | ---------------------------- | ----------------- | --------------------------------------------------- |
| Third-party market maker | High — can exit at any time | Episodic / sporadic | Per-product | Securitize Markets, INX, ERC-3643 secondary markets |
| Issuer-funded liquidity | Medium — depletes over time | Static | Per-issuer | Tokeny secondary markets |
| Standard AMM LP-token holders | Medium — LPs can withdraw | Variable; LP-mediated | Per-pair | Raydium, Orca, Uniswap |
| **Protocol-owned LP-burned pool** | **Zero — Certora E.3** | **Monotonic via 0.44% lock** | **Cross-module** | **RWA Tokens platform** |
***
### 4.12 The Liquidity Pool and Category 1 Model B
Category 1 Model B does not directly mandate a particular liquidity architecture. However, the Joint Staff Statement of January 28, 2026 emphasizes "investor protection at every transfer." A trading venue without sustained liquidity exposes investors to:
* Inability to exit positions
* Price discovery failure
* Pseudo-trading without true willingness-to-trade
* Pump-and-dump structural vulnerability
The Global Pool's permanence and Certora E.3 non-extractability eliminate these risks at the architectural level. The pool is one of the components that elevates the platform's investor-protection posture from "policy" to "structure."
***
*RWA Tokens Whitepaper V10 — Section 4 — Confidential — Groovy Company, Inc.*
# Layer 1: Solana Blockchain Foundation
## SECTION 5 — Layer 1: Solana Blockchain Foundation
**RWA Tokens Platform Whitepaper · V10.0 · May 2026** **Issued by:** Groovy Company, Inc. (Wyoming corporation; OTC: GROO; SEC EDGAR CIK 1499275) **Section classification:** Technical Specification — Infrastructure Layer **Authority:** SEC–CFTC Release No. 33-11412 § Five-Category Taxonomy; Solana Mainnet-Beta Specification
***
### 5.1 Layer 1 Architectural Position
Layer 1 is the distributed-consensus and execution substrate underneath the entire RWA Tokens platform stack. Every other layer — the Transfer Hook (Layer 2), the core protocol PDAs (Layer 3), the Global Unified Liquidity Pool (Layer 4), the CEDEX trading venue (Layer 5), the Oracle Network (Layer 6), governance (Layer 7), wallet infrastructure (Layer 8), and the IDOS intelligence module (Layer 9) — depends architecturally on properties supplied by Solana Mainnet-Beta. The platform is **not** a multi-chain abstraction. The platform is a Solana-native protocol that derives operational guarantees from properties that no other production L1 supplies in combination.
This section specifies (a) the Solana properties the platform depends on, (b) why no alternative L1 currently satisfies these dependencies, (c) the full Solana program inventory the platform deploys, (d) the production infrastructure (RPC, MEV protection, monitoring) supporting these programs, and (e) the network constants and finality semantics used elsewhere in this whitepaper.
### 5.2 Why Solana — Architectural Dependency Analysis
The platform's runtime-enforced compliance model (SEC Category 1 Model B Pillar 6) creates four Layer 1 requirements that together eliminate every L1 alternative as of the V10 specification date.
| Dependency | Required Property | Solana Mainnet-Beta | Ethereum L1 | Ethereum L2 (Optimism / Arbitrum / Base) |
| ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| **Runtime-level Transfer Hook** | The base token program must invoke a registered hook on every transfer, with no bypass instruction | ✅ SPL Token-2022 with `spl-transfer-hook-interface` v0.6+ enforces invocation at the runtime layer | ❌ ERC-20 `transfer()` is application-layer; ERC-3643 overlay can be bypassed by direct calldata to underlying ERC-20 | ❌ Same as Ethereum L1 — no native runtime hook |
| **Per-transfer compliance economics** | Per-transfer cost low enough to verify 42 controls plus module-aware extensions on every trade at every market-cap tier | ✅ \~$0.00025 per transfer (variable with priority fee) | ❌ $5–$50+ per transfer; impossible at OTC-microcap tier | ⚠️ $0.05–$2.00 per transfer; viable for large-cap, prohibitive for microcap |
| **Sub-second finality** | Settlement finality on the same order as Empire Stock Transfer's per-slot Ed25519 attestation cadence | ✅ \~400 ms single-block finalization (Tower BFT) | ❌ \~12-second blocks; \~12-minute economic finality | ⚠️ \~2 second blocks; finality bonded to L1 confirmation |
| **Native Ed25519 verification** | Native cryptographic precompile for Empire's per-slot signature verification (compute-cheap) | ✅ Native Ed25519 sysvar precompile | ❌ Requires precompile contract; \~3,000 gas per verification | ❌ Same as Ethereum L1 |
The combination — **runtime-hook + low cost + sub-second finality + native Ed25519** — exists on Solana Mainnet-Beta and on no other production L1 as of V10. This is the architectural reason the platform is Solana-native rather than chain-agnostic. ADR-001 (Architecture Decisions registry) memorializes this analysis.
### 5.3 Core Protocol Innovations
Solana's consensus design supplies the four properties above through three protocol-level innovations the platform depends on.
#### 5.3.1 Proof-of-History (PoH) — Verifiable Delay Function
PoH is a Verifiable Delay Function (VDF) — a cryptographic clock that provides a verifiable ordering of events without requiring nodes to communicate to agree on time. Every Solana validator advances a single SHA-256 chain at a roughly constant rate; the chain's current hash is a cryptographic proof that a specific amount of wall-clock time has passed since any earlier hash. Transactions are timestamped against this chain.
Why the platform depends on PoH: per-slot Ed25519 attestation from Empire Stock Transfer (Section 11) anchors to the slot's PoH hash. The attestation states "at this slot, custodied balance equals issued balance." Because PoH supplies a verifiable wall-clock ordering, the attestation cannot be backdated or forward-dated by the relay. Tampering with the attestation timestamp would require breaking SHA-256.
#### 5.3.2 Proof-of-Stake — Tower BFT Consensus
Tower BFT is Solana's PBFT-derived consensus protocol layered over PoH. Validators vote on the current chain head; votes accumulate "lockout" via an exponential weighting that grows with consecutive confirmations. The result: a block becomes economically final after roughly 32 confirmations (\~13 seconds at typical conditions) and probabilistically final at 1 confirmation (\~400 ms).
Why the platform depends on Tower BFT: the **\~400 ms single-confirmation finality** matches the cadence at which Empire publishes custody attestations. Trades settle on Solana, the on-chain ledger reflects the settlement, and Empire's next attestation reconciles the MSF state — all within the same human-perception interval. Compare to Ethereum L1, where \~12-minute economic finality means a settlement-attestation reconciliation cycle would lag the trade by 12+ minutes — long enough for shareholder-register divergence to materially affect dividend distributions or proxy votes scheduled near a custodial event.
#### 5.3.3 Native Ed25519 Precompile
Solana exposes Ed25519 signature verification via a native runtime sysvar (`Secp256k1Program::id()` for Secp256k1 and an Ed25519 program for Ed25519). Verification cost is a fixed compute-unit charge — typically \~600 CU per verification, compared to several thousand CU for an in-program signature verification implementation.
Why the platform depends on it: the Transfer Hook performs Ed25519 verification on **every** transfer of every ST22 mint to verify the Empire custody attestation (Control CV-04). The 42 controls + module-aware extensions consume \~800K–830K CU per transfer (varies by module — see §5.7); a non-native Ed25519 verification path would push compute consumption past the per-transaction CU ceiling. Native Ed25519 is the architectural enabler for runtime-enforced custody verification.
### 5.4 Account Model — Program Derived Addresses
Solana's account model is account-centric, not contract-centric: every byte of state lives in an account, and programs read/write accounts via the runtime's account-borrowing rules. The platform makes extensive use of **Program Derived Addresses (PDAs)** — accounts whose addresses are deterministically derived from seeds and a program ID, with no associated private key.
#### 5.4.1 PDA Derivation Function
```
PDA = find_program_address(
seeds: &[&[u8]],
program_id: &Pubkey
) -> (Pubkey, u8 /* bump */)
```
`find_program_address` repeatedly hashes the seeds plus a counter (the "bump") with the program ID until it finds a result that lies off the Ed25519 curve. The off-curve constraint is essential: it guarantees no private key can ever sign for the address, which means only the owning program can sign for the PDA via the runtime's `invoke_signed` mechanism. The bump value is stored in the PDA itself for stable rederivation.
#### 5.4.2 Platform PDA Inventory
| PDA | Seed Composition | Owning Program | Module Scope |
| ---------------------- | ----------------------------------------------- | ------------------- | ------------ |
| `SecurityConfig` | `[b"security-config", mint]` | `transfer_hook` | M1, M2, M3 |
| `HoldingPeriodAccount` | `[b"holding-period", mint, beneficiary]` | `transfer_hook` | M1, M2, M3 |
| `CustodyOracle` | `[b"custody-oracle", mint]` | `oracle_aggregator` | M1, M2, M3 |
| `OFACOracle` | `[b"ofac-oracle"]` (singleton) | `oracle_aggregator` | M1, M2, M3 |
| `AMLOracle` | `[b"aml-oracle", wallet]` | `oracle_aggregator` | M1, M2, M3 |
| `TWAPOracle` | `[b"twap-oracle", mint]` | `oracle_aggregator` | M1, M2, M3 |
| `EDGAROracle` | `[b"edgar-oracle", cik]` | `oracle_aggregator` | M1 |
| `NAVOracle` | `[b"nav-oracle", mint]` | `oracle_aggregator` | M2 |
| `ClassificationOracle` | `[b"classification-oracle", mint]` | `oracle_aggregator` | M3 |
| `LiquidityPool` | `[b"liquidity-pool"]` (singleton — Global Pool) | `liquidity_pool` | M1, M2, M3 |
| `PoolPosition` | `[b"pool-position", mint]` | `liquidity_pool` | M1, M2, M3 |
| `AmmMarket` | `[b"amm-market", mint]` | `amm` | M1, M2, M3 |
| `GovernanceProposal` | `[b"proposal", proposal_id]` | `governance` | M1, M2, M3 |
Why PDA-centric design matters for the platform: every per-mint configuration (compliance parameters, custody attestation, NAV/Classification state) lives in a PDA whose address is deterministically derivable from the mint pubkey. There is no centralized "registry" account whose corruption could affect multiple mints — each mint's state is isolated by construction.
#### 5.4.3 Account Rent and Reserved State
Solana accounts pay rent unless they hold sufficient SOL to be "rent-exempt." All platform PDAs are funded to rent-exemption at creation. The `transfer_hook` program initialization computes the rent-exempt minimum for the SecurityConfig PDA at program-deployment time and refuses initialization with insufficient lamports. ADR-005 documents the rent-funding economics.
### 5.5 SPL Token-2022 — Compliance-Critical Token Standard
The platform uses **SPL Token-2022** (token program ID `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHCBxGTJSAGkSm`), Solana's extended token standard supporting the **Transfer Hook extension**. This is architecturally distinct from the original SPL Token program, which has no hook mechanism.
#### 5.5.1 Transfer Hook Extension Mechanics
When an ST22 mint is created, the Token-2022 program is invoked with the `TransferHookExtension` initialized to the platform's `transfer_hook` program ID. From that point forward:
1. Any transfer instruction on the mint is dispatched through the Token-2022 program
2. Token-2022 inspects the mint's extensions and identifies the registered hook program
3. Token-2022 invokes the hook program via cross-program invocation (CPI)
4. The hook program executes its 42 controls plus module-aware extensions
5. If the hook returns success, Token-2022 completes the underlying balance update
6. If the hook returns error, Token-2022 reverts the entire transaction atomically
There is no instruction in Token-2022 that bypasses step 3. The hook invocation is enforced at the Token-2022 program level — which is itself a runtime-loaded program governed by Solana's program-upgrade authority (currently held by the Solana Foundation under multi-sig; see §5.6.4 for the platform's upgrade-authority isolation strategy).
#### 5.5.2 Other Token-2022 Extensions Used
| Extension | Used By Platform | Purpose |
| ---------------------- | --------------------------------- | ------------------------------------------------------------------- |
| `TransferHook` | ✅ All ST22 mints | The 42 controls + module-aware extensions |
| `MintCloseAuthority` | ❌ Disabled | Mint cannot be closed — protects 1:1 backing invariant |
| `ConfidentialTransfer` | ❌ Disabled | Conflicts with Empire MSF reconciliation transparency |
| `InterestBearing` | ❌ Disabled | Yield handled via staking program, not token-level |
| `CpiGuard` | ✅ Enabled on issuer treasury PDAs | Prevents accidental CPI-driven debits from issuer accounts |
| `ImmutableOwner` | ✅ Enabled on AMM market accounts | Prevents account-owner reassignment that could break AMM accounting |
| `MetadataPointer` | ⚠️ Optional per mint | Issuer-supplied metadata URI for on-chain mint discoverability |
The deliberate absence of `MintCloseAuthority` and `ConfidentialTransfer` is a Category 1 Model B compliance posture: Pillar 4 (1:1 Backing) requires that mint supply remain pinned to custodied equity, and Pillar 2 (Official DLT Register) requires reconciliation-transparency between the on-chain ledger and the Empire MSF.
### 5.6 Platform Solana Program Inventory
The platform deploys **five Solana programs** to Mainnet-Beta. Each has a distinct responsibility, a distinct upgrade-authority configuration, and explicit Certora-verified invariants.
#### 5.6.1 Program Inventory Table
| # | Program | Program ID (Mainnet-Beta) | Purpose | Upgrade Authority | Certora Invariants Covered |
| - | ----------------------- | ----------------------------------------------------------- | ------------------------------------------------------------------------------------ | ------------------------------------ | --------------------------------------- |
| 1 | **`transfer_hook`** | `RWAhook111…` (32-byte placeholder per V10 deployment plan) | Executes the 42 controls + module-aware extensions | **None — immutable post-deployment** | E.2, E.4, E.5, E.6 |
| 2 | **`amm`** | `RWAamm1…` | CEDEX Custom Constant Product Market Maker | 3-of-5 multi-sig + 48-hour timelock | E.3 (partial — pool reserve protection) |
| 3 | **`liquidity_pool`** | `RWApool1…` | Global Unified Liquidity Pool management; LP burn enforcement | 3-of-5 multi-sig + 48-hour timelock | E.3 |
| 4 | **`governance`** | `RWAgov1…` | On-chain proposal and voting; multi-sig / timelock orchestration | 3-of-5 multi-sig + 48-hour timelock | (governance-scope only) |
| 5 | **`oracle_aggregator`** | `RWAoracle1…` | Aggregates oracle attestations: Custody, OFAC, AML, TWAP, EDGAR, NAV, Classification | 3-of-5 multi-sig + 48-hour timelock | E.1 (custody invariant) |
Program IDs above are placeholder labels. Mainnet-Beta deployment IDs are published in the platform Smart Contract Reference and pinned to the production deployment by the Q3 2026 launch.
#### 5.6.2 `transfer_hook` Program — Immutable
The `transfer_hook` program is deployed with **no upgrade authority** (`upgrade_authority` set to `Pubkey::default()` or program closed to upgrades). This is an architectural decision documented in ADR-006: the 42 controls + module-aware extensions are immutable post-deployment by construction. Certora invariant E.4 formally proves this property — there exists no execution path by which the 42 core controls or applicable module-aware extensions can be removed, weakened, or repointed.
The cost: any defect in the deployed `transfer_hook` program cannot be patched. The mitigation: extensive formal verification (Certora suite, six invariants), Trail of Bits security audit, Halborn audit on the V9 module-aware extensions, and a 12-month bug-bounty period preceding production deployment. See Section 15 for the full security verification dossier.
#### 5.6.3 Multi-Sig and Timelock for Mutable Programs
The four mutable programs (`amm`, `liquidity_pool`, `governance`, `oracle_aggregator`) operate under a **3-of-5 multi-sig with 48-hour timelock**:
* **Multi-sig signers:** Frank Yglesias (Chairman & CTO of Groovy Company), Patrick Mokros (COO of Groovy Company; Founder of Empire Stock Transfer), Empire Stock Transfer Compliance Officer, External Technical Advisor #1 (regulatory expertise), External Technical Advisor #2 (cryptography expertise)
* **Threshold:** 3 of 5 signatures required
* **Timelock:** 48-hour delay between multi-sig approval and on-chain program upgrade
* **Override:** none — the timelock cannot be shortened by any mechanism, including the multi-sig itself
The 48-hour timelock provides a forced public-disclosure window: any pending program upgrade is observable on-chain for 48 hours before activation, allowing the community, regulators, or outside observers to flag concerns before changes go live. This is a Category 1 Model B Pillar 7 ("immutable, no admin override") posture: the only "admin" capability is upgrade-authorization, and that capability is bounded by multi-sig and timelock.
#### 5.6.4 Token-2022 Program Trust Boundary
A subtle property: the platform's `transfer_hook` is immutable, but the Token-2022 program itself is governed by the Solana Foundation's program-upgrade authority. Theoretically, a Solana Foundation upgrade to Token-2022 could weaken hook-invocation enforcement. The platform mitigates this by:
1. Pinning to specific Token-2022 program-version IDs in compliance-critical paths
2. Monitoring Solana Foundation governance activity for any Token-2022 changes
3. Maintaining a contingency procedure (Incident Response Playbook §11) for Control 42 invocation if a Solana Foundation Token-2022 upgrade weakens hook enforcement
This is the residual L1 trust assumption the platform retains. It is documented transparently in ADR-007 and disclosed in the Risk Disclosure document.
### 5.7 Compute Budget per Module
Solana transactions are subject to a per-transaction Compute Unit (CU) ceiling — typically 1,400,000 CU for non-priority transactions, expandable to 1,400,000+ CU via `ComputeBudgetInstruction`. The platform's per-transfer compute budget varies by module due to the additional cost of module-aware extensions:
| Module | Core 42 Controls (CU) | Module-Aware Extension (CU) | Total Per Transfer (CU) |
| -------------------------- | --------------------- | ---------------------------------------------------------------------------------------------- | ----------------------- |
| **Module 1 — Equities** | \~800,000 | (none — baseline) | \~800,000 |
| **Module 2 — Real Estate** | \~800,000 | \~20,000 (CB-21 NAV variant — NAV deviation math + appraiser signature verification) | \~820,000 |
| **Module 3 — CORECM** | \~800,000 | \~30,000 (REG-42 federal variant — Classification status check + federal-action state machine) | \~830,000 |
All three modules fit within the standard 1,400,000 CU ceiling with substantial headroom. The CEDEX `amm` swap path consumes additional CU for AMM math (\~150,000 CU), bringing total CU per CEDEX trade to \~950,000–980,000 CU depending on module — still within the standard ceiling.
### 5.8 Performance Characteristics
| Metric | Value | Notes |
| ----------------------------------------------------- | --------------- | ------------------------------------------------------------------- |
| Block time | \~400 ms | Tower BFT slot duration |
| Single-confirmation finality | \~400 ms | Probabilistic |
| Economic finality | \~13 seconds | \~32 confirmations |
| Per-transfer cost (base) | \~$0.00025 | At \~$150 SOL price; 5,000 lamports base fee + priority fee |
| Per-transfer cost (priority) | $0.0005–$0.001 | During congested periods; CEDEX uses dynamic priority fees via Jito |
| Network throughput (theoretical) | 65,000 TPS | Solana whitepaper figure |
| Network throughput (sustained, realistic) | 2,000–4,000 TPS | Mainnet-Beta observed sustained throughput |
| Platform throughput (compliance-verified ST22 trades) | 400–600 TPS | Bottleneck is hook execution + Ed25519 verification cost per trade |
| RPC capacity (platform dedicated cluster) | 500+ req/sec | Helius dedicated tier; Triton failover |
The 400–600 TPS platform throughput reflects compliance-verified ST22 trades specifically. Non-compliance traffic (e.g., GROO Utility Token trades, USDC stablecoin transfers) is unaffected and can run at network ceiling.
### 5.9 Production Infrastructure
#### 5.9.1 RPC Cluster — Helius Dedicated + Triton Failover
| Layer | Provider | Capacity | Role |
| --------------- | ---------------------------- | ------------ | --------------------------------------------------------------------------------------------- |
| Primary | Helius (dedicated cluster) | 500+ req/sec | All read-path queries (account fetches, mint queries, oracle reads); CEDEX order book backend |
| Failover | Triton One | 200+ req/sec | Primary failure detection triggers automatic switchover within 30 seconds |
| Public fallback | Solana Foundation public RPC | best-effort | Last-resort read-only fallback; never used for write path |
Why dedicated capacity matters: the November 2025 MSPC beta validated empirically that shared-tier RPC capacity (50 req/sec) is the primary bottleneck under launch volume. CEDEX peak load projections require 300+ req/sec sustained, which only dedicated infrastructure supplies reliably.
#### 5.9.2 MEV Protection — Jito Block Engine
All CEDEX trades route through the Jito Block Engine for MEV protection. Jito provides:
* Transaction-bundle inclusion via auction (mitigates sandwich attacks)
* Priority-fee market for predictable inclusion under congestion
* Searcher mempool isolation (CEDEX trades not exposed to public mempool)
Why MEV protection matters: the December 2025 GRLF beta validated that 85% of trade activity on unprotected venues was bot-driven extraction. Jito routing reduces extraction surface to the auction-cleared bundle level, where extraction must compete against legitimate priority demand on equal footing. ADR-010 documents the integration.
#### 5.9.3 Monitoring — Datadog + PagerDuty
| Surface | Coverage |
| ----------------------------- | ----------------------------------------------------------------------------- |
| Transaction throughput | Real-time TPS, success rate, error rate by program |
| Compute consumption | CU per transfer by module, percentile distribution |
| Oracle freshness | Slot age for Custody / OFAC / AML / TWAP / EDGAR / NAV / Classification |
| Hook control errors | Error code 6001–6042 frequency by mint, by error type |
| Module-aware extension errors | CB-21 NAV-deviation rejections by mint; REG-42 federal-action freezes by mint |
| MSF reconciliation | Empire MSF vs on-chain ledger drift detection per slot |
| Liquidity pool depth | Reserve balances; price impact at standard trade sizes |
| Wallet behavioral signals | Coordinated activity signatures (sniper-bot detection); Layer 9 IDOS feed |
PagerDuty escalations route to platform compliance (Empire compliance officer) and Layer 1 SRE (platform engineering). Module-specific dashboards added in V9 surface module-aware extension activity: a Module 2 dashboard tracks NAV deviation patterns; a Module 3 dashboard tracks federal-action freeze events and 60-minute SLA performance.
#### 5.9.4 Validator Strategy
The platform runs **non-validating** Solana infrastructure — no platform-operated validator nodes. Validation is the responsibility of the broader Solana validator set. This is an intentional design: a platform-operated validator would introduce a centralization vector that compromises the Category 1 Model B Pillar 7 ("no admin override") posture. The platform's role is application-layer (programs, RPC, monitoring, oracle relays) — not consensus.
### 5.10 Network Constants and Reference Values
The following constants are used elsewhere in this whitepaper and in the Smart Contract Reference. Their values are pinned by the V10 specification:
| Constant | Value | Use |
| ------------------------------------------------ | ---------- | ----------------------------------------------------------------- |
| `SLOT_DURATION_MS` | 400 | Average Solana slot duration |
| `SLOTS_PER_SECOND` | 2.5 | Inverse of slot duration |
| `SLOTS_PER_MINUTE` | 150 | 60 × 2.5 |
| `SLOTS_PER_HOUR` | 9,000 | 60 × 150 |
| `SLOTS_PER_DAY` | 216,000 | 24 × 9,000 |
| `SLOTS_PER_YEAR` | 78,840,000 | 365 × 216,000 |
| `STAKING_EPOCH_SLOTS` | 432,000 | \~2 days; staking reward distribution cadence |
| `CUSTODY_ATTESTATION_MAX_AGE_SLOTS` | 4 | \~1.6 seconds; CV-04 freshness threshold |
| `OFAC_ORACLE_MAX_AGE_SLOTS` | 216,000 | 24 hours; SX-34 staleness threshold |
| `AML_ORACLE_MAX_AGE_SLOTS` | 1,512,000 | 7 days; IV-12 staleness threshold |
| `TWAP_ORACLE_MAX_AGE_SLOTS` | 4 | \~1.6 seconds; CB-22 freshness threshold |
| `NAV_ORACLE_MAX_AGE_SLOTS_DEFAULT_M2` | 19,440,000 | 90 days; CB-21 NAV variant default reappraisal cadence |
| `CLASSIFICATION_ORACLE_MAX_AGE_SLOTS_DEFAULT_M3` | 216,000 | 24 hours; REG-42 federal variant default classification staleness |
| `FEDERAL_ACTION_DETECTION_SLA_SLOTS_M3` | 9,000 | 60 minutes; REG-42 federal variant SLA |
| `HOLDING_PERIOD_REG_D_SLOTS` | 39,447,000 | \~6 months; Reg D HP-24 enforcement |
| `HOLDING_PERIOD_REG_S_SLOTS` | 78,840,000 | \~12 months; Reg S HP-24 enforcement |
| `HOLDING_PERIOD_REG_CF_SLOTS` | 78,840,000 | \~12 months; Reg CF HP-24 enforcement |
| `REGULATORY_FREEZE_TIMELOCK_SLOTS` | 432,000 | 48 hours; Control 42 manual-freeze timelock |
### 5.11 Architectural Decision Records — Layer 1
| ADR | Title | Date | Decision Summary |
| ------- | ----------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| ADR-001 | Solana as Layer 1 substrate | March 2025 | Dependency analysis (§5.2) eliminated Ethereum L1, Ethereum L2s, Avalanche, Polygon as alternatives. Solana selected for runtime hook + cost + finality + Ed25519 combination. |
| ADR-002 | Custom AMM vs Raydium/Orca | November 2025 | GROO beta validated external DEXs bypass all 42 hook controls. Custom CPMM AMM purpose-built around Token-2022 hook semantics required. |
| ADR-005 | PDA rent-funding economics | June 2025 | All platform PDAs funded to rent-exemption at creation; rent-exempt minimum computed at program-deployment time. |
| ADR-006 | `transfer_hook` immutability | August 2025 | `transfer_hook` deployed with no upgrade authority. Defects must be addressed via re-deployment to a new program ID and migration path, never via in-place upgrade. |
| ADR-007 | Token-2022 trust assumption | September 2025 | Residual L1 trust on Solana Foundation's Token-2022 upgrade authority disclosed in Risk Disclosure; mitigated by version-pinning + monitoring + Control 42 contingency. |
| ADR-009 | Stablecoin settlement (USDC, PYUSD) | December 2025 | Per GENIUS Act framework; atomic on-chain settlement matched to \~400 ms finality; no fiat wires; no native crypto. |
| ADR-010 | Jito MEV protection | December 2025 | December 2025 GRLF beta validated 85% bot share. Jito Block Engine integration mandatory for CEDEX. |
***
### 5.12 Cross-References
* **Section 6** — Layer 2 Transfer Hook (the program loaded into the Token-2022 hook extension)
* **Section 11** — Empire Stock Transfer §17A custody and the per-slot Ed25519 attestation flow
* **Section 12** — Oracle Network (the seven oracle PDAs deployed under `oracle_aggregator`)
* **Section 13** — CEDEX Market (the `amm` program's settlement layer)
* **Section 14** — Global Unified Liquidity Pool (the `liquidity_pool` program)
* **Section 15** — Security Model and Formal Verification (Certora invariants E.1 through E.6)
* **Smart Contract Reference** — full account schemas, instruction interfaces, and program ID registry
* **Network Configuration** — production deployment parameters, RPC endpoints, monitoring dashboards
* **Infrastructure Overview** — Helius / Triton / Jito / Datadog deployment diagram
***
*RWA Tokens Platform Whitepaper · Section 5 — Layer 1: Solana Blockchain Foundation · V10.0 · Groovy Company, Inc.*
# Oracle Network — Layer 6
## Section 6: Oracle Network — Layer 6
**RWA Tokens Platform Whitepaper · Version 10.0** **Groovy Company, Inc. · May 2026** **Document Reference:** RWA-ORACLE-SPEC-001 v2.0
The Oracle Network supplies seven categories of off-chain data to the on-chain compliance program. All oracles use Ed25519 attestation; all signatures are verified by Solana's native Ed25519 precompile. Module-aware oracles (NAV for Module 2, Classification for Module 3) extend the V8 five-oracle baseline.
***
### 6.1 Architecture Principles
#### 6.1.1 Ed25519 Attestation Universally
Every oracle attestation is signed by an authorized off-chain relay using Ed25519. The relay's public key is bound to the oracle PDA at initialization and cannot be changed without governance action. Signature verification uses Solana's native Ed25519 precompile (instruction `Ed25519SigVerify1`), which costs \~3,000 CU per signature and is the most efficient signature-verification path on Solana.
#### 6.1.2 Per-Slot Freshness for Critical Oracles
Custody Oracle (Empire) attestations are required per Solana slot (\~400 ms cadence). Stale attestations cause Control CV-02 to reject transfers. This is the highest-frequency oracle in the system and provides the architectural basis for "compliance enforcement at every transfer."
#### 6.1.3 Module-Conditional Reading
V10's Transfer Hook reads module-specific oracles only when applicable:
| Oracle | Read When |
| --------------------- | ------------------- |
| Custody Oracle | Always (M1, M2, M3) |
| OFAC Oracle | Always (M1, M2, M3) |
| AML Oracle | Always (M1, M2, M3) |
| TWAP Oracle | Always (M1, M2, M3) |
| EDGAR Oracle | Module 1 only |
| NAV Oracle | Module 2 only |
| Classification Oracle | Module 3 only |
This conditional reading is what allows V8 mints (`module = 1`) to execute exactly as in V8 — they do not load NAV or Classification oracle accounts.
#### 6.1.4 Three-Provider Redundancy
Each oracle category is fed by three independent off-chain relay providers across separate cloud infrastructure (AWS, GCP, Azure). Control CV-40 (Oracle Consensus Failure) halts the affected category if fewer than 2 of 3 providers are reachable for more than 5 minutes.
***
### 6.2 Oracle Category 1 — Custody Oracle (Empire Stock Transfer)
#### 6.2.1 Purpose
The Custody Oracle stores Empire Stock Transfer's Ed25519-signed attestation of the underlying equity backing the mint 1:1. It is the architectural anchor for Pillar 4 (True Equity Backing 1:1) of Category 1 Model B.
#### 6.2.2 PDA Schema
```rust
#[account]
pub struct CustodyOracle {
pub version: u8, // 10
pub mint: Pubkey,
pub custodied_balance: u64, // Module-agnostic: shares of custodied class
pub class_label: AssetClass, // CommonB | SAE | BAE
pub last_update_slot: u64,
pub empire_pubkey: Pubkey,
pub signature: [u8; 64],
pub bump: u8,
}
#[derive(AnchorSerialize, AnchorDeserialize, Clone, Copy, PartialEq)]
pub enum AssetClass {
CommonB = 0, // Module 1
SAE = 1, // Module 2
BAE = 2, // Module 3
}
```
#### 6.2.3 Attestation Flow
```
Step 1 — Empire MSF state at slot N
Empire's Master Securityholder File reflects current equity custody
for the mint (custodied_balance, class_label).
Step 2 — Ed25519 signing
Empire's authorized signing service computes:
msg = (mint || custodied_balance || class_label || slot)
signature = Ed25519_sign(empire_priv, msg)
Step 3 — Solana submission
Empire submits update_custody_oracle instruction targeting the
CustodyOracle PDA for the mint.
Step 4 — Native precompile verification
CustodyOracle program invokes Ed25519SigVerify1 precompile.
Signature verified against bound empire_pubkey.
Step 5 — On-chain update
CustodyOracle PDA updated with new fields.
Step 6 — Available to Transfer Hook
Subsequent transfers read updated oracle in Control CV-01, CV-02.
```
#### 6.2.4 Slot Freshness Enforcement
Control CV-02 (`CustodyOracleUnavailable`) rejects transfers where:
```
current_slot - oracle.last_update_slot > 1
```
In practice, Empire's signing service operates a continuous loop that signs every Solana slot, with monitoring on signing-service health and automatic failover to backup signing infrastructure. Control CV-40 halts the affected mint if the oracle stops updating beyond a tolerance window (default 10 slots / \~4 seconds for warning; 75 slots / \~30 seconds for halt).
***
### 6.3 Oracle Category 2 — OFAC Oracle
#### 6.3.1 Purpose
Per-wallet OFAC / SDN sanctions screening. Used by Controls SX-08, SX-09, SX-10, SX-34, SX-37.
#### 6.3.2 PDA Schema
```rust
#[account]
pub struct OfacOracle {
pub version: u8,
pub bloom_filter: [u8; 16384], // Bloom filter of sanctioned addresses (16 KB)
pub bloom_k_funcs: u8, // Number of hash functions (default 7)
pub addresses_count: u32, // Number of addresses encoded in filter
pub last_update_ts: i64, // Unix timestamp of last SDN feed update
pub feed_version: u32, // OFAC SDN feed version number
pub relay_pubkey: Pubkey,
pub signature: [u8; 64],
pub bump: u8,
}
```
#### 6.3.3 Bloom Filter Design
The OFAC SDN list contains millions of addresses across all blockchain types. To make per-transfer OFAC screening computationally feasible, the platform encodes Solana-relevant sanctioned addresses into a Bloom filter:
* **Filter size:** 16,384 bytes = 131,072 bits
* **Hash functions:** 7 (SipHash-2-4 with 7 distinct seeds)
* **False-positive rate:** \~1% at \~50,000 sanctioned addresses
* **Membership query:** O(7) hash operations + 7 bit-tests; \~500 CU per query
A Bloom positive triggers a more expensive secondary check (full address-list lookup against an extended OFAC PDA). True positives are rare; the filter's false-positive rate adds modest latency to a small fraction of transfers.
#### 6.3.4 Update Cadence
OFAC SDN feed is updated daily (and ad-hoc on emergency designations). Empire's relay polls the OFAC API hourly and re-signs the oracle when the feed version changes. Control SX-10 (`StaleSanctionsOracle`) rejects transfers where:
```
current_ts - oracle.last_update_ts > 90 minutes
```
***
### 6.4 Oracle Category 3 — AML Oracle
#### 6.4.1 Purpose
Per-wallet AML risk scoring via Chainalysis Know Your Transaction (KYT) and TRM Labs. Used by Control SX-11.
#### 6.4.2 PDA Schema (Per-Wallet)
```rust
#[account]
pub struct AmlOracle {
pub version: u8,
pub wallet: Pubkey,
pub risk_score: u8, // 0–100
pub risk_categories: u32, // bitfield: mixer use, darknet, sanctions exposure, etc.
pub chainalysis_score: u8, // 0–100 from Chainalysis KYT
pub trm_score: u8, // 0–100 from TRM Labs
pub last_update_slot: u64,
pub last_update_ts: i64,
pub relay_pubkey: Pubkey,
pub signature: [u8; 64],
pub bump: u8,
}
// risk_score is the weighted aggregate:
// risk_score = max(chainalysis_score, trm_score) for high-confidence flagging
// or weighted average per platform-specific risk model
```
#### 6.4.3 On-Demand Lookup
AML attestations are not pre-computed for every wallet. They are computed:
* At Empire onboarding (initial assessment)
* On every transfer involving the wallet (re-fetched if AML PDA stale)
* On compliance review escalation
The `AmlOracle` PDA per wallet is created on first transfer and updated every 24 hours by the AML relay polling Chainalysis and TRM APIs.
#### 6.4.4 Three-Tier System (Control SX-11)
| `risk_score` Range | AML Decision | Action |
| ------------------ | --------------- | -------------------------------------------------------- |
| 0–30 | Approve | Transfer proceeds |
| 31–70 | Enhanced Review | Transfer proceeds; flagged for compliance officer review |
| 71–100 | Reject | Transfer reverts with `HighRiskWallet` (Error 6006) |
***
### 6.5 Oracle Category 4 — TWAP Oracle (Pyth Network)
#### 6.5.1 Purpose
Time-weighted average price reference for circuit breakers (CB-21 core, CB-26 price impact). Used to detect anomalous price movements.
#### 6.5.2 PDA Schema
```rust
#[account]
pub struct TwapOracle {
pub version: u8,
pub mint: Pubkey,
pub price_window: [u64; 24], // 24 hourly checkpoints (1e6 base units USDC)
pub current_hour_index: u8,
pub twap_24h: u64, // Computed 24h TWAP
pub twap_5min: u64, // 5-minute TWAP for fast circuit breakers
pub last_update_slot: u64,
pub pyth_feed_account: Pubkey, // Pyth Network feed for the mint
pub bump: u8,
}
```
#### 6.5.3 Per-Slot TWAP Update
The TWAP relay reads Pyth Network's price feed for the mint every Solana slot and updates the rolling window. Pyth provides per-slot price publishing through its dedicated price-feed program; the platform's TWAP relay aggregates the per-slot prices into 24-hour and 5-minute TWAPs.
For ST22 mints with active CEDEX trading, the TWAP is computed across CEDEX trading activity. For mints in pre-trading state, the TWAP defaults to the most recent NAV (Module 2) or initial offering price (Modules 1, 3).
***
### 6.6 Oracle Category 5 — EDGAR Oracle (Module 1 Only)
#### 6.6.1 Purpose
SEC EDGAR filing surface for issuer-distress signal generation in Layer 9 IDOS. Module 1 only, since EDGAR filings are made by SEC-reporting companies.
#### 6.6.2 PDA Schema
```rust
#[account]
pub struct EdgarOracle {
pub version: u8,
pub issuer_cik: u32, // SEC Central Index Key
pub mint: Pubkey,
pub last_filing_type: [u8; 8], // "10-K", "10-Q", "8-K", "13D/G", etc.
pub last_filing_ts: i64,
pub last_filing_url: [u8; 64], // EDGAR filing URL hash
pub idos_signal: u8, // 0–100 distress score derived from filing content
pub last_update_slot: u64,
pub relay_pubkey: Pubkey,
pub signature: [u8; 64],
pub bump: u8,
}
```
#### 6.6.3 EDGAR NLP Pipeline
The EDGAR relay performs:
1. EDGAR API polling (per filing publication)
2. Filing download and parsing
3. NLP-based distress-signal extraction (IDOS scoring)
4. Material-event detection (8-K classification)
5. Beneficial-ownership change detection (13D/G)
6. Material weakness in internal controls flag (10-K Item 9A)
7. Going-concern flag (10-K / 10-Q auditor commentary)
The IDOS signal is consumed by Layer 9; it does not directly halt transfers but informs compliance officer review and Control 42 manual freeze consideration.
***
### 6.7 Oracle Category 6 — NAV Oracle (Module 2 Only)
#### 6.7.1 Purpose
Per-mint NAV with authorized-appraiser Ed25519 signature. Used by Control CB-21 NAV-deviation variant. Documented in full in Section 9.
#### 6.7.2 PDA Schema
```rust
#[account]
pub struct NavOracle {
pub version: u8,
pub mint: Pubkey,
pub nav_per_token: u64, // 1e6 base units USDC
pub currency: [u8; 4], // "USDC" or "PYUS"
pub last_update_slot: u64,
pub last_appraisal_ts: i64,
pub appraiser_pubkey: Pubkey,
pub signature: [u8; 64],
pub bump: u8,
}
```
#### 6.7.3 Appraiser Authorization
The authorized appraiser's Ed25519 public key is bound at NAV Oracle initialization. The appraiser cannot be changed without tripartite-concurrence governance (SAE issuer + appraiser + Empire). The appraiser must be:
* State-licensed real-estate appraiser in the property's jurisdiction
* USPAP-compliant
* E\&O insurance at platform-required levels
* KYC and KYB by Empire Stock Transfer
#### 6.7.4 Reappraisal Cadence
The NAV attestation is valid only within `SecurityConfig.reappraisal_cadence_secs` (default 7,776,000 = 90 days). Beyond cadence, Control CB-21 NAV variant rejects transfers with `NavReappraisalOverdue` (6021-NAV-STALE).
#### 6.7.5 Anti-Fat-Finger Guard
NAV updates are limited to ±50% of the prior NAV in a single update. Larger revisions require two-step submission with platform compliance review.
***
### 6.8 Oracle Category 7 — Classification Oracle (Module 3 Only)
#### 6.8.1 Purpose
Per-mint federal-classification status for Module 3 BAE basin assets. Used by Control REG-42 federal-action variant. Documented in full in Section 10.
#### 6.8.2 PDA Schema
```rust
#[account]
pub struct ClassificationOracle {
pub version: u8,
pub mint: Pubkey,
pub basin_id: [u8; 32],
pub classification_status: u32, // bitfield: USGS-critical, DOE-critical, etc.
pub federal_action_active: bool,
pub federal_action_started_slot: u64,
pub federal_action_kind: u8, // 0=none, 1=Section232, 2=DPA-III, 3=EO, etc.
pub federal_action_reference: [u8; 32], // Federal Register doc ID hash
pub last_update_slot: u64,
pub relay_pubkey: Pubkey,
pub signature: [u8; 64],
pub bump: u8,
}
```
#### 6.8.3 Authorized Classification Relay
The relay polls authoritative sources continuously:
| Source | Cadence | Polled For |
| ----------------------- | ---------------- | -------------------------------------- |
| Federal Register API | Every 15 minutes | §232 actions, EO actions, DPA actions |
| USGS publications | Hourly | Critical Minerals List changes |
| DOE notices | Hourly | Critical Materials Strategy events |
| BLM notices | Hourly | Land-use actions affecting concessions |
| Office of the President | Per publication | EO publications |
Three-provider redundancy across separate cloud infrastructure ensures no single relay failure halts Module 3 operations.
#### 6.8.4 60-Minute SLA
Detection-to-enforcement latency budget (full breakdown in Section 10.6.3):
| Phase | Target | Maximum |
| --------------------------------------------------- | ------------------- | ---------- |
| Federal event publication → relay polling cycle | 0–15 min | 15 min |
| Pattern detection → compliance officer notification | < 1 min | 5 min |
| Compliance officer review (high-impact) | < 15 min | 30 min |
| Ed25519 signing + Solana submission | < 1 min | 5 min |
| Solana confirmation | < 1 min | 5 min |
| **Total ceiling** | **< 30 min target** | **60 min** |
#### 6.8.5 Staleness Enforcement
`SecurityConfig.classification_max_age_secs` defines the maximum oracle staleness (default 86,400 = 24 hours). Beyond this, REG-42 federal-action variant rejects transfers with `ClassificationOracleStale` (6042-FED-STALE).
***
### 6.9 Cross-Oracle Coordination
#### 6.9.1 Oracle Consensus (Control CV-40)
Control CV-40 (Oracle Consensus Failure) requires that for each oracle category, at least 2 of 3 redundant relay providers be reachable within 5 minutes. If consensus drops, the affected category halts trades on affected mints. The consensus check is per-category, not global — a Custody Oracle consensus failure halts all mints, while a NAV Oracle consensus failure halts only Module 2 mints.
#### 6.9.2 Oracle Failure Cascading
Oracle failures cascade as follows:
| Failure | Effect |
| -------------------------------- | --------------------------------------------------------------------- |
| Custody Oracle stale | All transfers on affected mint halt (CV-02, then CV-40) |
| OFAC Oracle stale | All transfers across all mints halt (SX-10) |
| AML Oracle missing for wallet | Transfer involving that wallet halts pending AML re-fetch |
| TWAP Oracle stale | Circuit breaker controls cannot evaluate; CB-21 core defaults to halt |
| EDGAR Oracle stale (M1) | IDOS scoring degraded; no transfer halt |
| NAV Oracle stale (M2) | All Module 2 transfers on affected mint halt (CB-21 NAV variant) |
| Classification Oracle stale (M3) | All Module 3 transfers on affected mint halt (REG-42 federal variant) |
#### 6.9.3 Recovery Semantics
| Oracle | Recovery |
| ------------------- | -------------------------------------------------------------------------------- |
| Custody | Auto-resume on next valid Empire attestation |
| OFAC | Auto-resume on next valid relay attestation |
| AML | Auto-resume per wallet on next AML re-fetch |
| TWAP | Auto-resume on next valid Pyth update |
| EDGAR | N/A (no halt to recover from) |
| NAV (M2) | Auto-resume on next valid appraiser attestation within reappraisal cadence |
| Classification (M3) | Auto-resume on next valid relay attestation with `federal_action_active = false` |
All recoveries are automatic. No manual unfreeze actions are required for oracle-driven halts.
***
### 6.10 Oracle Network and SEC Category 1 Model B
The Oracle Network is foundational to satisfying Pillar 4 (True Equity Backing 1:1) and Pillar 6 (Investor Protection — compliance enforcement at every transfer):
| Pillar | Oracle Contribution |
| ------------------------------ | ------------------------------------------------------------------------------------------------------ |
| Pillar 4 — True Equity Backing | Custody Oracle Ed25519 attestation per slot; verified by Control CV-01 on every transfer |
| Pillar 6 — Investor Protection | OFAC, AML, TWAP, NAV (M2), Classification (M3) feed Transfer Hook controls executing on every transfer |
Without continuous, signed oracle attestations, neither pillar could be satisfied as architectural property. The Oracle Network is what allows the platform's compliance posture to be cryptographic and continuous rather than periodic and audit-mediated.
***
*RWA Tokens Whitepaper V10 — Section 6 — Confidential — Groovy Company, Inc.*
# CEDEX Market — Compliant Exchange for Digital Securities
## Section 7: CEDEX Market — Compliant Exchange for Digital Securities
**RWA Tokens Platform Whitepaper · Version 10.0** **Groovy Company, Inc. · May 2026** **Document Reference:** RWA-CEDEX-SPEC-001 v2.0
CEDEX (Compliant Exchange for Digital Securities) is the platform-operated trading venue at **cedex.market**. CEDEX is the only legitimate venue at which ST22 mints across all three modules can be traded. CEDEX operates 24/7/365 with permanent protocol-owned liquidity, a custom Constant Product Market Maker (CPMM) Automated Market Maker, and full Transfer Hook enforcement on every trade.
***
### 7.1 Architectural Position
CEDEX occupies **Layer 5** of the nine-layer architecture. It depends on Layer 1 (Solana), Layer 2 (Transfer Hook), Layer 3 (Core Protocol), Layer 4 (Global Unified Liquidity Pool), and Layer 6 (Oracle Network) for substantive operations. It interfaces with Layer 8 (Wallet Infrastructure) for investor connection and Layer 9 (IDOS) for surveillance signals.
| Component | Role |
| ----------------------- | --------------------------------------------------------------------- |
| Order book | Centralized matching engine; price-time priority; off-chain |
| AMM | Custom CPMM; on-chain settlement program; Transfer Hook compatible |
| Liquidity pool | Single shared Global Unified Liquidity Pool serves all three modules |
| Settlement | Atomic on Solana; \~400 ms finality; revert on any 42-control failure |
| Stablecoin denomination | USDC and PYUSD per GENIUS Act |
| Trading hours | 24/7/365; no market hours |
***
### 7.2 Why CEDEX, Not External DEXs
External Solana DEXs (Raydium, Orca, Jupiter, Phoenix) cannot host ST22 mints. The October 2025 GROO mainnet beta empirically validated this: across the beta, $5.75M of value was extracted by \~1,000 coordinated sniper bots routing through Raydium, with zero compliance enforcement on Raydium-routed trades. ADR-002 (Architecture Decisions) documents the conclusion: **a custom AMM purpose-built around Transfer Hook semantics is required**.
#### 7.2.1 Why External DEXs Bypass Transfer Hooks
External DEXs bypass Transfer Hooks for one or more of the following reasons:
| Reason | Detail |
| ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------- |
| Pool initialization without hook awareness | DEX pool factory does not provision hook-required accounts (SecurityConfig, oracles) in the swap path |
| Trade routing via unhooked path | DEX router resolves swap path through token instructions that don't invoke the hook program |
| Account-resolution mismatches | DEX assumes vanilla SPL Token; doesn't resolve hook-extension accounts |
| LP-token wrapper bypass | DEX wraps the ST22 token in a derivative LP token; trades against the wrapper, never invoking hook on the underlying |
In all four cases, the result is the same: the 42 controls do not execute. Compliance is bypassed. The mint trades as if it were an unhooked SPL Token.
#### 7.2.2 Why CEDEX Doesn't Have This Problem
CEDEX is purpose-built around Transfer Hook semantics:
* **Pool initialization integrates SecurityConfig and oracles** — every pool has the SecurityConfig PDA, Custody Oracle, and module-specific oracles (NAV for M2, Classification for M3) wired into the swap-instruction account list.
* **Swap path routes through Token-2022 program with hook attached** — the on-chain `amm` program issues SPL Token-2022 transfer instructions that automatically invoke the registered hook.
* **No LP-token wrapping** — CEDEX trades directly against ST22 reserves; no derivative wrappers.
* **Account-resolution is exact** — the swap instruction declares all PDAs the hook will read at instruction-submission time.
***
### 7.3 Architecture — Two-Layer Design
CEDEX operates as a **dual-layer architecture**:
```
Layer A — Centralized Order Book Matching (off-chain)
├─ Order intake (REST + WebSocket)
├─ Price-time priority matching engine
├─ Order types: market, limit, stop, time-in-force
├─ User-account state (open orders, positions, balances)
└─ Match notification → Layer B
Layer B — Decentralized Solana Settlement (on-chain)
├─ amm program issues swap instruction
├─ swap instruction invokes SPL Token-2022 transfer
├─ Token-2022 invokes Transfer Hook via CPI
├─ 42 controls + module-aware extensions execute atomically
└─ Settlement: ~400 ms finality OR atomic revert
```
This dual-layer design provides:
* **Familiar institutional UX** — order book semantics that traders, market makers, and algos understand
* **Compliance enforcement at settlement** — every match settles via Transfer Hook; off-chain matching cannot bypass on-chain controls
* **Scalability** — order matching scales independently of Solana transaction throughput
* **Atomic settlement** — any 42-control failure reverts the on-chain settlement; the off-chain match is rolled back
#### 7.3.1 Off-Chain Match Rollback
When an on-chain settlement reverts (e.g., Control HP-24 rejection: investor's holding period not elapsed), the matching engine:
1. Receives the revert notification from the Solana RPC observer
2. Marks both maker and taker orders as "rejected — compliance"
3. Returns the order book to pre-match state (orders are not refilled)
4. Notifies both parties via WebSocket with the specific error code (e.g., 6024 `TokensLocked`)
5. Logs the event for compliance review
The revert is observable to investors. Compliance failures are not silent.
***
### 7.4 Custom CPMM AMM — Mathematical Specification
The on-chain settlement layer uses a Constant Product Market Maker (CPMM) with the standard Uniswap V2-compatible invariant:
```
x · y = k
```
where `x` is the stablecoin reserve (USDC or PYUSD), `y` is the ST22 reserve, and `k` is the constant product. Every trade preserves the invariant (modulo fee accounting).
#### 7.4.1 Swap Math
For a swap in which the trader sells stablecoin amount `Δx` to receive ST22:
```
Without fees:
k = x · y
(x + Δx) · (y - Δy) = k
Δy = y · Δx / (x + Δx)
With fee f (CEDEX total fee 5% = 500 bps):
Δy_effective = y · (Δx · (10000 - f)) / (x · 10000 + Δx · (10000 - f))
For Δx = stablecoin in, Δy = ST22 received:
Δy = y · Δx · 9500 / (x · 10000 + Δx · 9500)
```
The reverse direction (trader sells ST22 to receive stablecoin) is symmetric.
#### 7.4.2 u128 Overflow-Safe Arithmetic
All AMM math uses `u128` intermediate values to prevent overflow on large reserves:
```rust
pub fn calculate_swap_output(
input_amount: u64, // Δx (stablecoin in, in 1e6 base units)
reserve_in: u64, // x
reserve_out: u64, // y
fee_bps: u16, // 500 (5%)
) -> Result {
let amount_in_u128 = input_amount as u128;
let reserve_in_u128 = reserve_in as u128;
let reserve_out_u128 = reserve_out as u128;
let fee_factor = 10_000u128 - fee_bps as u128; // 9500
// numerator = reserve_out · input_amount · fee_factor
let numerator = reserve_out_u128
.checked_mul(amount_in_u128).ok_or(AMMError::Overflow)?
.checked_mul(fee_factor).ok_or(AMMError::Overflow)?;
// denominator = reserve_in · 10000 + input_amount · fee_factor
let denominator = reserve_in_u128
.checked_mul(10_000u128).ok_or(AMMError::Overflow)?
.checked_add(amount_in_u128.checked_mul(fee_factor).ok_or(AMMError::Overflow)?)
.ok_or(AMMError::Overflow)?;
let output_u128 = numerator
.checked_div(denominator).ok_or(AMMError::DivisionByZero)?;
require!(output_u128 <= u64::MAX as u128, AMMError::Overflow);
Ok(output_u128 as u64)
}
```
#### 7.4.3 Invariant Drift Tolerance
CEDEX's swap instruction includes an explicit `min_output` parameter (slippage protection). If actual `Δy < min_output`, the swap reverts with `SlippageExceeded`. Default slippage tolerance for institutional orders: 50 bps (0.5%). Configurable per order.
#### 7.4.4 Single-Pool Architecture vs Multiple-Pool
Conventional AMM design (Uniswap V2, Raydium) deploys one pool per token pair. The platform's design is different: **a single shared pool serves all three modules**. The pool reserves are:
* **Stablecoin reserve** — USDC + PYUSD aggregate balance
* **ST22 reserve** — token-mix across all listed mints, weighted by NAV (Module 2) or by inception-pricing-anchored reference (Modules 1, 3)
Per-mint listing within the shared pool uses an inner CPMM accounting layer that tracks per-mint position within the global pool. This design enables cross-module liquidity sharing — a Module 3 BAE basin's trading volume contributes to the same pool that supports a Module 1 OTC microcap issuer's secondary market.
***
### 7.5 Fee Structure (5% Total)
Every CEDEX trade pays a 5% total fee distributed as follows:
| Component | Allocation | Use |
| -------------------- | ---------- | ----------------------------------------- |
| Issuer | 2.0% | Routed to issuer treasury |
| Staking rewards | 1.5% | Distributed to GROO Utility Token stakers |
| Protocol | 1.06% | Operational expenses; reserve fund |
| Global Pool (locked) | 0.44% | Permanent locked reserve in pool |
| **Total** | **5.0%** | |
#### 7.5.1 Why 5% Total
5% is high relative to non-compliant DEX venues (Raydium typical 0.25%, Uniswap V3 standard 0.3%) but includes:
* Per-transfer compliance verification (42 controls + module-aware extensions)
* Real-time custody attestation
* Permanent liquidity provisioning (vs market-maker withdrawal risk)
* Empire onboarding amortization
* Full §17A regulatory infrastructure
* Module-aware enforcement (NAV oracle for M2, Classification oracle for M3)
Non-compliant venues do not provide these. The fee differential is the price of Category 1 Model B compliance.
#### 7.5.2 Fee Distribution Implementation
```rust
// On-chain fee distribution at every swap
const FEE_TOTAL_BPS: u16 = 500; // 5%
const FEE_ISSUER_BPS: u16 = 200; // 2%
const FEE_STAKING_BPS: u16 = 150; // 1.5%
const FEE_PROTOCOL_BPS: u16 = 106; // 1.06%
const FEE_GLOBAL_POOL_BPS: u16 = 44; // 0.44%
// Sum: 500 bps = 5%
pub fn distribute_fees(
trade_value: u128,
issuer_treasury: AccountInfo,
staking_pool: AccountInfo,
protocol_treasury: AccountInfo,
global_pool: AccountInfo,
) -> Result<()> {
let issuer_fee = trade_value.checked_mul(FEE_ISSUER_BPS as u128).ok_or(Err)? / 10_000;
let staking_fee = trade_value.checked_mul(FEE_STAKING_BPS as u128).ok_or(Err)? / 10_000;
let protocol_fee = trade_value.checked_mul(FEE_PROTOCOL_BPS as u128).ok_or(Err)? / 10_000;
let pool_fee = trade_value.checked_mul(FEE_GLOBAL_POOL_BPS as u128).ok_or(Err)? / 10_000;
transfer_stable(issuer_treasury, issuer_fee as u64)?;
transfer_stable(staking_pool, staking_fee as u64)?;
transfer_stable(protocol_treasury, protocol_fee as u64)?;
// Global Pool fee is added directly to pool reserves (permanent lock)
add_to_pool_locked(global_pool, pool_fee as u64)?;
Ok(())
}
```
The Global Pool 0.44% fee is **added to the pool reserves** rather than transferred elsewhere. This is what makes the pool self-reinforcing.
***
### 7.6 Circuit Breakers
CEDEX integrates four runtime-enforced circuit breakers via Controls CB-21 through CB-27 (full specification in Section 3 — Transfer Hook):
| Breaker | Control | Trigger | Effect |
| ------------------------------ | ----------------- | --------------------------------------------------- | ----------------------------- |
| Price halt (core) | CB-21 | Price moves > 10% in 5 minutes | Halt all trades 5 minutes |
| **NAV deviation (M2 variant)** | CB-21 NAV variant | `\|price − NAV\|/NAV > nav_deviation_max_bps/10000` | Reject trade |
| Price impact | CB-26 | Single trade impacts price > 2% vs TWAP | Reject trade |
| Volume halt | CB-27 | Daily sell volume > 30% of average | Halt all sell trades 24 hours |
| Oracle failure | CV-40 | < 2 of 3 oracle feeds available > 5 min | Halt affected category |
#### 7.6.1 TWAP Reference Source
CB-21 (core), CB-26, and CB-27 reference the Pyth Network TWAP price for the relevant reference market. For ST22 mints, the TWAP is computed across the prior 24-hour window of CEDEX trading activity for the specific mint, exponentially weighted by recency.
```rust
pub struct TwapOracle {
pub price_window: [u64; 24], // 24 hourly checkpoints
pub current_hour_index: u8,
pub last_update_slot: u64,
pub twap_24h: u64,
}
```
***
### 7.7 Stablecoin Settlement (GENIUS Act)
All ST22 trades on CEDEX settle in USDC or PYUSD. Section 15 (GENIUS Act Stablecoin Settlement) provides full specification.
#### 7.7.1 No Fiat Wires
CEDEX does not accept fiat wire transfers for ST22 purchases. Investors fund their CEDEX accounts by:
1. Off-platform conversion to USDC or PYUSD via Circle / Paxos institutional on-ramps, or
2. On-platform wallet connection of pre-existing USDC / PYUSD balances
The platform does not intermediate fiat-to-stablecoin conversion. This eliminates the platform's exposure to bank-wire compliance, settlement-bank failure, and dollar-clearance latency.
#### 7.7.2 No Native Crypto
CEDEX does not accept SOL, BTC, ETH, or other native cryptocurrencies for ST22 purchases. The settlement leg is exclusively GENIUS Act payment stablecoins.
***
### 7.8 Issuer Listing Process
Only Empire-verified issuers can list on CEDEX:
| Step | Actor | Output |
| ---- | --------------------------- | ------------------------------------------------------------------------------------------ |
| 1 | Issuer | Issuer onboarding sequence per Module 1 / 2 / 3 (Sections 8.4, 9.2, 10.2) |
| 2 | Empire | Custody intake of underlying equity |
| 3 | Platform | SecurityConfig, Custody Oracle, NAV Oracle (M2), or Classification Oracle (M3) initialized |
| 4 | Platform | SPL Token-2022 mint created with Transfer Hook registered |
| 5 | Platform compliance officer | Listing review (technical correctness; module classification; offering exemption flags) |
| 6 | Platform | Mint registered with CEDEX listing service |
| 7 | Platform | Pool initialization for the mint within the Global Unified Liquidity Pool |
| 8 | Platform | Order book activation |
| 9 | CEDEX | Mint visible to verified investors |
***
### 7.9 Investor Trading Flow (Concrete)
```
Step 1 — Wallet Connection
Investor connects wallet via Phantom, Solflare, Backpack,
Coinbase Wallet, or Ledger
CEDEX UI verifies wallet against Empire MSF registration
(HoldingPeriodAccount existence per mint of interest)
Step 2 — Mint Discovery
Investor browses available ST22 mints filtered by:
- Module (1 = Equities, 2 = Real Estate, 3 = CORECM)
- Offering exemption (Reg D, Reg S, Reg CF)
- Asset class (Common B, SAE, BAE)
Investor's eligibility for each mint is evaluated against:
- HoldingPeriodAccount existence and jurisdiction
- IV-12 accreditation (Reg D path)
- IV-19 Reg CF investor limit (Reg CF path)
Step 3 — Order Submission
Investor submits order:
- Order type: market, limit, stop
- Direction: buy (stablecoin → ST22) or sell (ST22 → stablecoin)
- Stablecoin denomination: USDC or PYUSD
- Slippage tolerance: default 50 bps, configurable
Step 4 — Order Book Matching
CEDEX matching engine resolves order against opposing book:
- Price-time priority
- Partial fills supported
- Match record produced for settlement
Step 5 — On-Chain Settlement
amm program receives swap instruction with:
- Match details (taker wallet, maker wallets, amounts, prices)
- SecurityConfig PDA
- Custody Oracle PDA
- HoldingPeriodAccount PDAs (per investor)
- Module-specific oracle PDAs (NAV for M2, Classification for M3)
- OFAC, AML, TWAP oracle PDAs
Step 6 — Transfer Hook Execution
Token-2022 invokes Transfer Hook via CPI
All 42 controls + applicable module-aware extensions execute
Atomic result: pass → settlement; fail → atomic revert
Step 7 — Settlement Outcome
Pass:
Stablecoin balance debits buyer; credits maker (after fees)
ST22 balance debits maker; credits buyer
Empire MSF reconciles at next slot via custody oracle update
GA-42 audit emission
Fail:
Atomic revert; off-chain match rolled back
Investor notification with error code
Step 8 — Confirmation
Investor sees confirmation in CEDEX UI within ~400 ms of submission
Holdings update reflect in MSF and on-chain ledger
```
***
### 7.10 24/7/365 Operations
CEDEX operates continuously. There are no market hours.
| Aspect | Detail |
| --------------------------- | ---------------------------------------------------------------- |
| Trading hours | 24/7/365 |
| Settlement window | Continuous |
| Empire custody attestation | Per Solana slot (\~400 ms) regardless of US business hours |
| Compliance officer coverage | 24/7 on-call rotation |
| Federal-action SLA (M3) | 60-minute SLA holds at all times including weekends and holidays |
| Wallet support | All supported wallets accessible 24/7 |
***
### 7.11 CEDEX vs Securitize Markets ATS — Architectural Comparison
| Attribute | Securitize Markets (ATS) | CEDEX |
| --------------------------- | ----------------------------- | ---------------------------------------------------------------- |
| Hours | Limited | 24/7/365 |
| Liquidity source | Market makers (can withdraw) | Global Pool (LP burned, non-extractable per Certora E.3) |
| Rugpull risk | Possible (market maker exit) | Mathematically impossible |
| Per-issuer market maker | Required ($5K – $20K / month) | Not required (shared pool) |
| Cross-asset-class liquidity | Per-product isolated | Single pool serves all three modules |
| Compliance enforcement | Application-layer | Runtime-enforced via Transfer Hook + module-aware extensions |
| Settlement finality | T+0 to T+2 | \~400 ms |
| Per-trade fee | 0.5–2% (ATS-dependent) | 5% (includes 42 controls + custody attestation + permanent pool) |
| Module-aware enforcement | Not offered | NAV oracle (M2); Classification oracle + 60-min SLA (M3) |
| Cross-module composability | Not applicable | Single architecture serves Equities + Real Estate + CORECM |
***
### 7.12 Surveillance and Compliance Monitoring
CEDEX integrates with Layer 9 IDOS for ongoing market surveillance:
* **Wash trading detection** — IDOS profiles wallet pairs with bidirectional volume
* **Layered manipulation detection** — IDOS profiles order-cancellation patterns
* **Spoofing detection** — IDOS profiles large-order placement followed by rapid cancellation
* **Cross-mint coordination detection** — IDOS profiles synchronized trading across multiple mints
* **NAV-deviation analytics (M2)** — IDOS profiles deviation patterns over time
* **Federal-action correlation (M3)** — IDOS correlates trading behavior with Classification oracle update history
Surveillance findings feed compliance officer review queues. Material findings trigger Control 42 manual freeze consideration via the platform compliance escalation path.
***
### 7.13 The CEDEX Governance Surface
CEDEX-specific governance parameters (within Layer 7 governance scope):
| Parameter | Default | Adjustment Authority |
| ---------------------------- | ------------------------------ | ---------------------------- |
| Per-mint listing approval | n/a | Platform compliance + Empire |
| Per-mint pool seeding amount | Platform-determined at listing | Platform governance |
| Slippage default | 50 bps | Platform governance |
| Minimum order size | 1 base unit | Platform governance |
| Maker rebate (off-chain) | 0 (default; none) | Platform governance |
| Order-book throttle | per-IP rate limits | Platform operations |
Module-specific governance (NAV deviation tolerance for M2, classification staleness for M3) is per-mint and uses tripartite-concurrence governance, not platform governance.
***
*RWA Tokens Whitepaper V10 — Section 7 — Confidential — Groovy Company, Inc.*
# Module 1 — Equities
## Section 8: Module 1 — Equities
**RWA Tokens Platform Whitepaper · Version 10.0** **Groovy Company, Inc. · May 2026** **Document Reference:** RWA-M1-SPEC-001 v1.0
Module 1 is the equity-securities tokenization module. It addresses the full equity addressable surface — from sub-$1M OTC microcap (where Ethereum L1 tokenization is economically impossible) through NASDAQ / AMEX / TSX-listed mid-to-large-cap equity, and on to global-exchange equity tokenization. Module 1 is the architectural baseline: V8 mints are Module 1 mints with `module = 1` in `SecurityConfig`. Modules 2 and 3 extend Module 1 with module-aware Transfer Hook extensions.
***
### 8.1 Scope
| Asset Tier | Description | Default `max_wallet_percent` |
| ------------------ | ---------------------------------------------- | ------------------------------------ |
| OTC microcap | Sub-$10M market cap; OTCID-tier US issuers | 499 bps (4.99%) — §13(d) sensitivity |
| OTC mid-cap | $10M – $100M; OTCQB / OTCQX-tier | 499 bps (4.99%) |
| NASDAQ-listed | Listed equity (capital, global, global-select) | 999 bps (9.99%) |
| AMEX / NYSE-listed | Listed equity | 999 bps (9.99%) |
| TSX-listed | Toronto Stock Exchange | 999 bps (9.99%) |
| Foreign exchange | Global equity tokenization (Phase 2 expansion) | Per-mint (≤ 999 bps) |
`max_wallet_percent` is configurable at mint initialization within statutory bounds. The default for OTC microcap (499 bps) protects against §13(d) reporting-threshold inadvertent triggers; the default for listed equity (999 bps) reflects standard institutional concentration norms.
***
### 8.2 Backing Instrument — Common Class B
Each Module 1 ST22 token is backed 1:1 by **Common Class B** shares of the issuing company. The platform standardizes on a Common Class B class because it aligns with the SEC Crypto Task Force directive of March 30, 2026 and provides:
* Direct beneficial ownership representation (Pillar 4 of Category 1 Model B)
* Standard corporate-governance attributes (voting, dividends, liquidation preference per Certificate of Designation)
* Compatibility with §17A custody and DTC ownership-chain mapping (Pillar 5)
* Avoidance of the regulatory complexity that attaches to preferred-class tokenization
#### 8.2.1 Certificate of Designation
The issuer files a **Certificate of Designation** with the Secretary of State of its jurisdiction of incorporation specifying the Common Class B shareholder rights. The Certificate is the legally controlling instrument; the on-chain ST22 ledger is the transfer-notification layer per W\.S. 34-29-101 *et seq.* Required Certificate provisions include:
* Class designation: "Common Class B"
* Authorized share count
* Voting rights (1:1 with Common Class A unless otherwise specified)
* Dividend rights (pari passu with Common Class A unless otherwise specified)
* Liquidation preference
* Conversion rights (none, by default)
* Transfer restrictions consistent with Reg D / Reg S / Reg CF
* Designation that Empire Stock Transfer is the §17A transfer agent
#### 8.2.2 1:1 Backing Verification
The Custody Oracle PDA per Module 1 mint stores Empire's Ed25519-signed attestation of `custodied_balance` (Common Class B shares held in Empire custody for this mint). Control CV-01 verifies on every transfer:
```
total_supply + transfer_amount ≤ custodied_balance
```
If the inequality fails, the transfer reverts with Error 6001 (`CustodyDiscrepancy`). Empire publishes attestations every Solana slot (\~400 ms cadence). Control CV-02 (`CustodyOracleUnavailable`) rejects transfers if the most recent attestation is more than 1 slot stale.
***
### 8.3 Asset Identifier — CUSIP
Module 1 mints carry the issuer's **CUSIP** (Committee on Uniform Security Identification Procedures) as the asset identifier. The CUSIP is bound at mint initialization in `SecurityConfig.asset_identifier` (32-byte field; CUSIP padded). Control CV-05 rejects any transfer where the bound CUSIP does not match the Custody Oracle's reported asset-identifier hash for the custodied class.
CUSIP integration enables:
* **Institutional custody integration** — Fireblocks, BitGo, Anchorage on Solana can resolve ST22 holdings to their underlying equity for reporting, audit, and corporate-actions purposes.
* **DTC ownership-chain mapping** — DTCC operations can reconcile ST22 records to existing CUSIP-based infrastructure where applicable.
* **Regulatory reporting** — SEC Form 13F, 13G, 13D, beneficial-ownership filings reference the CUSIP and resolve cleanly to ST22 token-account holdings via the on-chain ledger.
```rust
// SecurityConfig field set at initialization
pub asset_identifier: [u8; 32], // CUSIP (9 chars) zero-padded to 32 bytes
// Control CV-05 implementation
require_keys_eq!(
Pubkey::new_from_array(cfg.asset_identifier),
Pubkey::new_from_array(custody_oracle.asset_identifier_hash()),
TransferHookError::AssetIdentifierMismatch // 6009
);
```
***
### 8.4 Issuer Onboarding Sequence
| Step | Actor | Output | Reference |
| ---- | --------------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------ |
| 1 | Issuer board | Board resolution authorizing Common Class B issuance and tokenization | Issuer Onboarding Guide §3 |
| 2 | Issuer Legal | Certificate of Designation filed with Secretary of State | Issuer Onboarding Guide §4 |
| 3 | Empire Stock Transfer | KYB; AML screening; issuer onboarded; CUSIP assignment | Empire Stock Transfer Integration Guide §2 |
| 4 | Empire Stock Transfer | Custody intake of Common Class B shares; Custody Oracle PDA initialized | Empire Stock Transfer Integration Guide §4 |
| 5 | Platform | `SecurityConfig` PDA created with `module = 1`, CUSIP, default wallet caps, Reg D / Reg S / Reg CF jurisdictions enabled | Smart Contract Reference §3 |
| 6 | Platform | SPL Token-2022 mint created with Transfer Hook extension registered to platform program | Smart Contract Reference §4 |
| 7 | Empire Stock Transfer | Investor onboarding (KYC, OFAC/SDN, AML, wallet verification) per investor jurisdiction | Empire Stock Transfer Integration Guide §6 |
| 8 | Platform | Token issuance to verified investor wallets; `HoldingPeriodAccount` PDA created per investor-mint pair | Smart Contract Reference §5 |
| 9 | CEDEX | Mint listed on CEDEX with order book and liquidity-pool seeding | CEDEX API Reference §3 |
#### 8.4.1 Empire Onboarding Detail
Empire Stock Transfer is the sole §17A onboarding authority for Module 1. Empire's onboarding gate performs:
| Check | Reference Standard |
| --------------------- | ------------------------------------------------------------------------------------------ |
| Identity verification | Customer Identification Program (CIP) per §326 USA PATRIOT Act |
| KYC / KYB | FinCEN Customer Due Diligence (CDD) |
| AML | BSA / AML program; Chainalysis KYT integration |
| OFAC / SDN | Real-time SDN list match (re-verified hourly via SX-10 oracle) |
| Wallet control | Cryptographic proof (signed challenge) |
| Jurisdiction | Self-certification + corroborating documentation; sets `HoldingPeriodAccount.jurisdiction` |
| Accreditation (Reg D) | §501(a) accredited investor verification per Reg D Rule 501 |
| Reg CF eligibility | JOBS Act §4(a)(6) / Reg CF Rule 100 limits; income/net-worth verification |
After Empire approves an investor, Empire signs the wallet-verification attestation that Control IV-15 (`UnregisteredWallet`) reads on transfer. The attestation is stored in an Empire-controlled PDA accessible to the Transfer Hook.
***
### 8.5 Module-Aware Extensions (Module 1)
**None applicable.** Module 1 mints execute only the 42 core Transfer Hook controls. CB-21 NAV-deviation variant and REG-42 federal-action variant are no-ops for Module 1 mints (the conditional `if cfg.module != ...` short-circuits at the start of each extension). This makes Module 1 the architectural baseline.
The compute-unit budget for Module 1 transfers is approximately 800,000 CU (770,000 CU for the 42 core controls plus 30,000 CU runtime overhead).
***
### 8.6 Investor Lifecycle
#### 8.6.1 Reg D (US Accredited) Path
| Step | Action | On-Chain Result |
| ---- | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| 1 | Investor completes Empire onboarding; accreditation verified | Empire MSF entry |
| 2 | Investor purchases tokens via cedex.market in USDC / PYUSD | `SecurityConfig` debits issuer treasury; `HoldingPeriodAccount` PDA created with `jurisdiction = RegD`, `holding_period_secs = 15_778_800` |
| 3 | Investor holds during 6-month Rule 144 period | Control HP-24 rejects any transfer (`TokensLocked`, 6024) |
| 4 | After 6 months, `is_locked` derived as `false` from `current_ts >= purchase_ts + holding_period_secs` | Investor can sell on CEDEX with full 42-control enforcement |
| 5 | Investor sells; settlement in USDC / PYUSD | Atomic on Solana (\~400 ms) |
#### 8.6.2 Reg S (Non-US) Path
Identical to Reg D path except: `jurisdiction = RegS`, `holding_period_secs = 31_536_000` (12 months). Control IV-18 enforces the Reg S US-person check during the compliance period.
#### 8.6.3 Reg CF (US Retail) Path
Reg CF requires a FINRA-registered funding portal partnership. The platform partners with a FINRA-registered funding portal to operationalize Reg CF offerings.
| Step | Action | On-Chain Result |
| ---- | ------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------- |
| 1 | Investor enters via funding portal | Funding-portal-side intake |
| 2 | Empire performs Reg CF eligibility check (JOBS Act §4(a)(6) limits) | Empire MSF entry; Reg CF investor flag |
| 3 | Investor purchases via funding portal | `HoldingPeriodAccount` with `jurisdiction = RegCF`, `holding_period_secs = 31_536_000` |
| 4 | Control IV-19 verifies the investor's annual aggregate Reg CF investment does not exceed JOBS Act §4(a)(6) statutory cap | `RegCFLimitExceeded` (6019) on excess |
| 5 | Investor holds during 12-month period | Control HP-24 rejects transfers |
| 6 | After 12 months, secondary trading available | Standard CEDEX settlement |
***
### 8.7 Reference Use Case — OTC Microcap Tokenization
A Wyoming-incorporated OTC microcap issuer with $5M market cap, 530 shareholders of record, and OTCID-tier listing engages the platform.
#### 8.7.1 Structuring
| Parameter | Value |
| ----------------------------- | --------------------------------------------------------------------------- |
| Issuer | Hypothetical Wyoming Corp |
| Existing class | Common Class A (5,000,000 shares outstanding) |
| New class for tokenization | Common Class B (5,000,000 authorized; 1:1 voting and dividend with Class A) |
| Tokenized share count | 5,000,000 ST22 Module 1 tokens |
| `max_wallet_percent` | 499 bps (4.99%) |
| Offering exemptions enabled | Reg D, Reg S |
| `holding_period_secs` (Reg D) | 15,778,800 (6 months) |
| `holding_period_secs` (Reg S) | 31,536,000 (12 months) |
#### 8.7.2 Onboarding Sequence (Concrete)
1. Board resolution authorizes 5,000,000 Common Class B shares for tokenization.
2. Certificate of Designation filed with Wyoming Secretary of State; Common Class B rights specified.
3. Empire Stock Transfer onboards issuer (KYB, AML); CUSIP issued.
4. Empire takes custody of 5,000,000 Common Class B shares; Custody Oracle PDA initialized.
5. Platform creates `SecurityConfig` PDA: `module = 1`, `asset_identifier = CUSIP`, `max_wallet_percent = 499`, `circuit_breaker_threshold = 3000`, `is_paused = false`, `version = 10`.
6. SPL Token-2022 mint created with Transfer Hook registered to the platform program ID.
7. 5,000,000 ST22 tokens minted to issuer treasury PDA (controlled by issuer 3-of-5 multi-sig).
8. Investors onboard through Empire; wallets verified; `HoldingPeriodAccount` PDAs created at first purchase.
9. Initial offering round: investors purchase ST22 tokens via cedex.market with USDC / PYUSD settlement.
10. Liquidity-pool seeding occurs at platform initialization (seeded by Groovy STO proceeds + 0.44% fee accrual).
11. Secondary trading 24/7/365 on cedex.market with full 42-control enforcement.
#### 8.7.3 Operational Outcome
* **Sub-second finality** — typical settlement \~400 ms.
* **Per-transfer cost** — \~$0.00025 (Solana base fee + priority).
* **Compliance verification per transfer** — all 42 controls execute atomically; failure reverts.
* **Real-time custody attestation** — every Solana slot (\~400 ms).
* **Permanent liquidity** — Global Pool serves the mint without per-issuer market maker contracts.
* **Regulatory posture** — Category 1 Model B per Release No. 33-11412; Empire §17A custody satisfies Pillar 3; Common Class B 1:1 satisfies Pillar 4; Transfer Hook satisfies Pillar 6; immutable post-deployment satisfies Pillar 7.
***
### 8.8 Cross-Module Coordination
Module 1 shares the following with Modules 2 and 3:
* **Empire Stock Transfer** as sole §17A custodian and onboarding authority
* **Global Unified Liquidity Pool** (Layer 4) — single shared pool serves all three modules
* **CEDEX** (Layer 5) as sole legitimate trading venue
* **Custody / OFAC / AML / TWAP oracles** (Layer 6)
* **Reg D / Reg S / Reg CF** offering exemption framework
* **GENIUS Act stablecoin settlement** (USDC / PYUSD)
* **Layer 9 IDOS** compliance intelligence (with Module 1-specific EDGAR pipeline)
Module 1 differs from Modules 2 and 3 in:
* **No NAV oracle** — Module 1 prices via market discovery on CEDEX without NAV-bound enforcement
* **No federal-action coordination** — Module 1 has no analog to the REG-42 federal variant
* **CUSIP** as asset identifier (vs property ID for M2; basin ID for M3)
* **Common Class B** custody (vs SAE equity for M2; BAE equity for M3)
***
*RWA Tokens Whitepaper V10 — Section 8 — Confidential — Groovy Company, Inc.*
# 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
```rust
#[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)
```rust
pub fn ext_cb21_nav_deviation(
ctx: &Context,
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
```rust
// 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.*
# Module 3 — CORECM (Carbon Ore, Rare Earth, and Critical Minerals)
## Section 10: Module 3 — CORECM (Carbon Ore, Rare Earth, and Critical Minerals)
**RWA Tokens Platform Whitepaper · Version 10.0** **Groovy Company, Inc. · May 2026** **Document Reference:** RWA-M3-SPEC-001 v1.0
Module 3 — CORECM — is the strategic-minerals supply-chain tokenization module. It addresses equity tokenization of US strategic-minerals assets through the Basin-Asset Entity (BAE) corporate vehicle. Module 3 introduces the second module-aware Transfer Hook extension — Control REG-42 federal-action variant — which automatically halts trading on detection of qualifying federal events affecting the basin asset, with a 60-minute SLA from detection to enforcement.
Module 3 is true blue-ocean territory: no other tokenization platform offers federal-action coordination at the runtime layer for strategic-minerals supply-chain assets.
***
### 10.1 Scope
| Asset Category | Examples |
| --------------------------------------- | ------------------------------------------------------------------------------------------- |
| Mineral basins | Lithium, copper, nickel, cobalt, manganese, graphite basin holdings |
| Mining concessions | Active or pre-production mining concessions on critical minerals |
| Coal-derived REE recovery | Coal-derived Rare Earth Element extraction facilities (per DOE Critical Materials Strategy) |
| Critical-minerals processing facilities | Refining, separation, and beneficiation operations |
| Supply-chain logistics infrastructure | Strategic-minerals-specific transport, warehousing, and trans-shipment facilities |
Module 3 explicitly addresses minerals and supply-chain assets identified by US federal frameworks as strategically important. Non-strategic mining assets (e.g., aggregate quarries, common-construction-mineral basins) are outside Module 3 scope.
#### 10.1.1 The CORECM Acronym
CORECM expands as **Carbon Ore, Rare Earth, and Critical Minerals**:
* **Carbon Ore** — coal-derived value chains, specifically coal-to-products pathways including DOE-recognized REE recovery from coal byproducts
* **Rare Earth** — the 17 rare-earth elements (lanthanides plus scandium and yttrium); separation, refining, and finished-product applications
* **Critical Minerals** — the broader USGS Critical Minerals List, including lithium, cobalt, nickel, manganese, graphite, copper, and other minerals deemed critical to US economic and national security
***
### 10.2 The BAE Structure
The Basin-Asset Entity (BAE) is the corporate vehicle that holds the basin or mineral-asset interest. Like the Module 2 SAE, the BAE is structured as a Nevada corporation to support Empire Stock Transfer §17A common-stock custody.
#### 10.2.1 BAE Lifecycle
```
Stage 1 — Asset Identification
- Basin / mineral concession identified
- USGS Critical Minerals List eligibility verified
- DOE Critical Materials Strategy alignment verified (where applicable)
- Initial geological / engineering assessment commissioned
- Federal land vs private land status documented
Stage 2 — Federal-Framework Mapping
- Section 232 exposure assessment (commodity-import tariff vulnerability)
- DPA Title III eligibility (federal-investment qualification)
- IRA critical-minerals tax-credit eligibility
- EO 14017 supply-chain action exposure
- Energy Act of 2020 research/innovation eligibility
Stage 3 — Nevada Corporation Formation
- Nevada corporation organized
- Mineral-asset interest conveyed to BAE
- Articles of Incorporation filed (Common Class B authorized)
- Initial directors / officers appointed
- Corporate bylaws adopted
Stage 4 — Empire Onboarding
- Empire performs KYB on BAE
- BAE corporate structure documented
- Empire takes custody of all BAE common stock
Stage 5 — Classification Relay Configuration
- Authorized Classification relay's Ed25519 pubkey configured
- Federal-Register / USGS / DOE feed subscriptions verified
- Initial Classification Oracle attestation submitted
Stage 6 — Platform Configuration
- Basin ID assigned (asset identifier)
- SecurityConfig PDA initialized:
module = CORECM (3)
classification_max_age_secs = 86_400 (default 24 hours)
federal_action_freeze_enabled = true
federal_action_sla_secs = 3600 (60 minutes)
asset_identifier = basin_id
Stage 7 — Token Issuance
- SPL Token-2022 mint created with Transfer Hook registered
- ST22 Module 3 tokens minted to BAE treasury
Stage 8 — Investor Onboarding
- Investors onboard via Empire
- HoldingPeriodAccount PDAs created per Reg D / Reg S / Reg CF
Stage 9 — Secondary Trading
- CEDEX listing active
- REG-42 federal-action variant continuously evaluated against Classification Oracle
```
***
### 10.3 Backing Instrument — BAE Common Stock
Each Module 3 ST22 token is backed 1:1 by **common stock of the BAE**. The BAE holds direct interest in the basin / mineral asset; ST22 tokens represent fractional equity ownership in the BAE.
```
Investor Wallet (holds ST22 Module 3 tokens)
↓ (represents fractional equity in)
BAE Common Stock (held 1:1 by Empire Stock Transfer §17A custody)
↓ (issued by)
Basin-Asset Entity (Nevada corporation; holds basin interest)
↓ (owns / holds)
Mineral Basin / Concession / Processing Facility
```
Custody verification mechanics are identical to Module 2 (`class_label = AssetClass::BAE`).
***
### 10.4 Asset Identifier — Basin ID
Module 3 mints carry the **basin ID** as the asset identifier:
```
basin_id = keccak256(
state_code // ISO 3166-2 state code
| county_or_district // FIPS or BLM district code
| mineral_class // USGS taxonomy code (e.g., "REE", "LI", "CU", "NI")
| concession_id // BLM lease number / private concession ID / Section-Township-Range
| bae_corporate_id // Nevada Secretary of State entity ID
)
```
Where applicable, basin IDs reference:
* USGS Mineral Resource Data System (MRDS) entries
* BLM mineral lease numbers (for federal-land concessions)
* DOE National Coal Resource Data System entries (for coal-derived REE recovery facilities)
***
### 10.5 The Classification Oracle (Module 3)
The Classification Oracle is Module 3's central architectural innovation. It surfaces federal-framework status — both static classification and dynamic federal-action events — on-chain via Ed25519-signed relay attestations.
#### 10.5.1 Classification Oracle PDA Schema
```rust
#[account]
pub struct ClassificationOracle {
pub version: u8,
pub mint: Pubkey,
pub basin_id: [u8; 32],
pub classification_status: u32, // bitfield
pub federal_action_active: bool,
pub federal_action_started_slot: u64, // Drives 60-min SLA timer
pub federal_action_kind: u8,
pub federal_action_reference: [u8; 32], // Federal Register doc ID, USGS publication ID, etc.
pub last_update_slot: u64,
pub relay_pubkey: Pubkey,
pub signature: [u8; 64],
pub bump: u8,
}
// classification_status bitfield (u32, 32 flags)
const STATUS_USGS_CRITICAL: u32 = 1 << 0;
const STATUS_DOE_CRITICAL: u32 = 1 << 1;
const STATUS_IRA_30D_ELIGIBLE: u32 = 1 << 2;
const STATUS_EO14017_LISTED: u32 = 1 << 3;
const STATUS_DPA_III_PROGRAM: u32 = 1 << 4;
const STATUS_SEC232_TARIFF_TARGET: u32 = 1 << 5;
const STATUS_ENERGY_ACT_2020: u32 = 1 << 6;
const STATUS_DEFENSE_LOGISTICS: u32 = 1 << 7;
// reserved bits 8-31
// federal_action_kind enum
const KIND_NONE: u8 = 0;
const KIND_SECTION_232: u8 = 1;
const KIND_DPA_III: u8 = 2;
const KIND_EXECUTIVE_ORDER: u8 = 3;
const KIND_USGS_LIST_CHANGE: u8 = 4;
const KIND_DOE_EVENT: u8 = 5;
const KIND_TARIFF_OTHER: u8 = 6;
const KIND_EXPORT_RESTRICTION: u8 = 7;
const KIND_LAND_USE_ACTION: u8 = 8; // BLM withdrawal, EPA restriction
```
#### 10.5.2 Authorized Classification Relay
The Classification Oracle is fed exclusively by an **authorized Classification relay** — an off-chain service whose Ed25519 public key is bound to the Classification Oracle PDA at initialization. The relay performs:
* Continuous polling of authoritative federal sources (Federal Register, USGS publications, DOE notices, BLM notices)
* Event detection and classification per the documented framework taxonomy
* Ed25519 signing of attestations on detection of qualifying events
* 60-minute SLA from detection of qualifying event to on-chain attestation submission
* Reverse-trigger detection: when an action lifts, attestation update with `federal_action_active = false`
Relay infrastructure:
| Component | Detail |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| Subscription targets | Federal Register API, USGS data feeds, DOE Critical Materials Strategy publications, BLM Notice publications, Office of the President proclamations |
| Polling frequency | Federal Register: every 15 minutes; USGS: hourly; DOE: hourly; BLM: hourly |
| Redundancy | Three independent subscribers across separate cloud providers |
| Detection logic | Pattern matching against per-basin keyword sets configured at BAE onboarding |
| Compliance review | Platform compliance officer reviews automated detections before signing for high-impact actions (Section 232, DPA III) |
| Signing | Ed25519 over `(mint, basin_id, federal_action_active, federal_action_kind, federal_action_reference, slot)` |
| On-chain submission | Solana transaction submitted within 60-minute SLA budget |
#### 10.5.3 Classification Oracle Update Flow
```
Step 1 — Federal Event Detection
Classification relay polls federal sources continuously
Detects qualifying event (e.g., Section 232 tariff notice
affecting copper imports → impacts copper basin holdings)
Step 2 — Compliance Review (high-impact actions)
For Section 232, DPA III, EO actions:
Platform compliance officer reviews detection
Confirms basin-level applicability
Authorizes attestation update
For automated low-impact (USGS list change, DOE event):
Skip review; relay proceeds directly
Step 3 — Off-Chain Computation
classification_relay computes:
federal_action_active = true
federal_action_kind = KIND_SECTION_232
federal_action_reference = Federal Register doc ID hash
Step 4 — Ed25519 Signing
relay signs:
msg = (mint || basin_id || federal_action_active || federal_action_kind
|| federal_action_reference || target_slot)
signature = Ed25519_sign(relay_priv, msg)
Step 5 — On-Chain Submission
Update transaction submitted to Solana within 60-min SLA budget
Step 6 — On-Chain Verification
ClassificationOracle program verifies signature via native Ed25519 precompile
Step 7 — On-Chain Effect
Subsequent Module 3 transfers on this mint will trigger REG-42 federal-action
variant rejection until federal_action_active returns to false
Step 8 — Audit
GA-42 emits audit record for the classification update
```
***
### 10.6 Control REG-42 Federal-Action Variant — Technical Specification
#### 10.6.1 Trigger and Effect
Trigger: any Module 3 transfer when `ClassificationOracle.federal_action_active = true`.
Effect:
* **Rejection** — transfer reverts with Error 6042-FED (`FederalActionActive`).
* **Halt-only semantics** — REG-42 cannot move tokens; it can only prevent transfers.
* **Auto-resume** — when the Classification relay submits an updated attestation with `federal_action_active = false`, the next subsequent transfer succeeds (no manual unfreeze action required).
#### 10.6.2 Implementation
```rust
pub fn ext_reg42_federal_action(
ctx: &Context,
) -> Result<()> {
let cfg = &ctx.accounts.security_config;
if cfg.module != Module::CORECM { return Ok(()); }
if !cfg.federal_action_freeze_enabled { return Ok(()); }
let class_oracle = ctx.accounts.classification_oracle
.as_ref()
.ok_or(TransferHookError::ClassificationOracleMissing)?;
let now_ts = Clock::get()?.unix_timestamp;
// Staleness enforcement (max age, default 24 hours)
let oracle_ts = slot_to_unix_ts(class_oracle.last_update_slot);
require!(
now_ts - oracle_ts <= cfg.classification_max_age_secs,
TransferHookError::ClassificationOracleStale // 6042-FED-STALE
);
// Ed25519 signature verification
verify_classification_attestation(
class_oracle.relay_pubkey,
&class_oracle.signature,
&(
cfg.mint,
class_oracle.basin_id,
class_oracle.federal_action_active,
class_oracle.federal_action_kind,
class_oracle.federal_action_reference,
class_oracle.last_update_slot
),
)?;
// Federal action active → reject
require!(
!class_oracle.federal_action_active,
TransferHookError::FederalActionActive // 6042-FED
);
Ok(())
}
```
#### 10.6.3 The 60-Minute SLA — Operational Decomposition
Detection-to-enforcement latency budget:
| Phase | Target Time | Maximum |
| ----------------------------------------------------------------- | --------------------------------------------- | ------------------ |
| Federal event publication → relay polling cycle | 0 – 15 min (Federal Register polling cadence) | 15 min |
| Pattern detection → compliance officer notification | < 1 min | 5 min |
| Compliance officer review and authorization (high-impact actions) | < 15 min | 30 min |
| Ed25519 signing and Solana transaction submission | < 1 min | 5 min |
| Solana confirmation | < 1 min | 5 min |
| **Total (high-impact)** | **< 30 min target** | **60 min ceiling** |
| **Total (automated low-impact)** | **< 15 min target** | **30 min ceiling** |
The 60-minute ceiling is encoded as a contractual SLA backed by:
* 24/7 on-call rotation for compliance officers
* Triple-redundant relay infrastructure
* Solana priority-fee budget reserved for SLA-critical transactions
* Incident Response Playbook §13 documenting full federal-action procedure
#### 10.6.4 Auto-Resume Semantics
When a federal action lifts (e.g., a Section 232 tariff is rescinded), the Classification relay submits an attestation update with `federal_action_active = false`. The next Module 3 transfer to the affected mint will succeed, subject to all other 42 controls passing. **No manual unfreeze action by the platform, the BAE issuer, or Empire is required.** This is structurally distinct from Control 42 (manual regulatory freeze) which requires Legal Counsel signoff and 3-of-5 multi-sig to lift.
***
### 10.7 Federal Frameworks Surfaced
#### 10.7.1 USGS Critical Minerals List
The USGS Critical Minerals List (most recently updated per the 2022 USGS publication, with annual reassessment) defines the official list of minerals classified as critical to US economic and national security. The Classification Oracle bitfield's `STATUS_USGS_CRITICAL` flag is set when the BAE's basin commodity is on the current list.
`KIND_USGS_LIST_CHANGE` federal-action events are triggered when a USGS list update affects the basin commodity (addition or removal).
#### 10.7.2 DOE Critical Materials Strategy
The DOE Critical Materials Strategy framework includes specific programs around coal-derived REE recovery and other strategic-mineral supply-chain initiatives. The `STATUS_DOE_CRITICAL` flag is set when the BAE participates in a current DOE program. `KIND_DOE_EVENT` federal-action events are triggered by DOE program suspension, modification, or expansion.
#### 10.7.3 Section 232 of the Trade Expansion Act of 1962
Section 232 authorizes the President to impose tariffs and import restrictions on national-security grounds. The `STATUS_SEC232_TARIFF_TARGET` flag is set when the BAE commodity is subject to current §232 tariff investigation or active tariff. `KIND_SECTION_232` federal-action events are triggered by:
* §232 investigation initiation
* §232 tariff imposition
* §232 tariff modification
* §232 quota adjustment
#### 10.7.4 Defense Production Act Title III
DPA Title III authorizes federal investment in domestic critical-minerals production. `STATUS_DPA_III_PROGRAM` flag is set when the BAE is a current DPA Title III program participant. `KIND_DPA_III` federal-action events triggered by program suspension, modification, or expansion.
#### 10.7.5 Inflation Reduction Act — Critical Minerals Provisions
The IRA includes critical-minerals tax credits (e.g., 30D vehicle credit's domestic-content thresholds) and supply-chain incentives. `STATUS_IRA_30D_ELIGIBLE` flag indicates current eligibility for relevant credits. Material IRS guidance affecting eligibility triggers a classification update.
#### 10.7.6 Executive Order 14017 — America's Supply Chains
EO 14017 directs federal agencies to assess and strengthen supply chains in critical sectors. `STATUS_EO14017_LISTED` flag is set when the BAE commodity is named in current EO 14017 implementation actions. `KIND_EXECUTIVE_ORDER` federal-action events triggered by EO 14017-driven supply-chain actions.
#### 10.7.7 Energy Act of 2020
The Energy Act of 2020 establishes federal critical-minerals research and innovation programs. `STATUS_ENERGY_ACT_2020` flag is set when the BAE is involved in current Energy Act of 2020 programs.
#### 10.7.8 Defense Logistics / National Stockpile Programs
Where applicable, BAE participation in National Defense Stockpile programs is flagged via `STATUS_DEFENSE_LOGISTICS`.
***
### 10.8 Reference Use Case — Coal-Derived REE Recovery Facility
A coal-derived Rare Earth Element recovery facility located in West Virginia, eligible under DOE Critical Materials Strategy.
#### 10.8.1 Structuring
| Parameter | Value |
| ------------------------------- | -------------------------------------------------------------------------------- |
| Asset | Coal-derived REE recovery facility, Mingo County, WV |
| Underlying basin | Coal mining concession + REE extraction infrastructure |
| BAE | Mingo CORECM Holdings, Inc. (Nevada corporation) |
| Authorized common stock | 5,000,000 shares |
| Tokenized share count | 5,000,000 ST22 Module 3 tokens |
| `classification_max_age_secs` | 86,400 (24 hours) |
| `federal_action_freeze_enabled` | true |
| `federal_action_sla_secs` | 3,600 (60 minutes) |
| Initial classification\_status | STATUS\_DOE\_CRITICAL `\|` STATUS\_USGS\_CRITICAL `\|` STATUS\_ENERGY\_ACT\_2020 |
#### 10.8.2 Onboarding Sequence (Concrete)
1. Facility identified; DOE Critical Materials Strategy program eligibility confirmed.
2. Federal-framework mapping: DOE-eligible (yes), USGS-critical commodity (REE = yes), §232 exposure (low for domestic REE), DPA III (potentially eligible), IRA (downstream-product 30D considerations), EO 14017 (REE-listed), Energy Act of 2020 (yes).
3. Nevada BAE formed; basin and facility interests conveyed.
4. Articles of Incorporation: 5,000,000 authorized common shares.
5. Empire Stock Transfer onboards BAE.
6. Empire takes custody of 5,000,000 BAE common shares.
7. Basin ID assigned: `basin_id = keccak256("US-WV" | "FIPS-059" | "REE" | concession_id | bae_id)`.
8. Authorized Classification relay configured with Federal Register / USGS / DOE / BLM polling subscriptions.
9. Initial Classification Oracle attestation: `classification_status = STATUS_DOE_CRITICAL | STATUS_USGS_CRITICAL | STATUS_ENERGY_ACT_2020`, `federal_action_active = false`.
10. SecurityConfig PDA initialized.
11. SPL Token-2022 mint created; ST22 Module 3 tokens minted to BAE treasury.
12. Investors onboard through Empire (Reg D, Reg S, Reg CF).
13. CEDEX listing active.
#### 10.8.3 Operational Federal-Action Cycle (Concrete)
```
Day 0 — Initial classification: DOE-critical + USGS-critical + Energy Act
federal_action_active = false → trading active
Day 45 — Federal Register publishes §232 investigation initiation on
rare-earth imports (hypothetical scenario)
Day 45 + 0 min — Relay detects publication during 15-min polling cycle
Day 45 + 12 min — Relay detection confirmed; basin-applicability assessed:
this BAE is domestic, but downstream §232 tariff could
affect domestic REE pricing → classified as KIND_SECTION_232
with federal_action_active = true
Day 45 + 25 min — Compliance officer review complete; relay signs attestation
Day 45 + 27 min — Solana transaction submitted; confirmed at slot N
Day 45 + 28 min — REG-42 federal-action variant active; subsequent Module 3
transfers on this mint REVERT with 6042-FED
[60-minute SLA met: 28 minutes from detection to enforcement]
Day 60 — §232 investigation concludes with no tariff (hypothetical)
Day 60 + 5 min — Relay detects investigation closure
Day 60 + 30 min — Compliance review confirms; relay signs
federal_action_active = false attestation
Day 60 + 32 min — Attestation on-chain
Day 60 + 33 min — Next Module 3 transfer succeeds; trading resumes automatically
```
***
### 10.9 Module 3 Investor Lifecycle
Identical to Module 1 with two differences:
1. **REG-42 federal-action enforcement** — every secondary trade evaluates federal-action status.
2. **Classification Oracle staleness awareness** — investors observe `last_update_slot` and may anticipate trading freezes if the relay falls behind the 24-hour staleness window.
Investor experience during a federal-action freeze:
* All transfer attempts revert with 6042-FED.
* cedex.market UI displays "Federal Action Active — Trading Halted" status with the federal\_action\_kind reference.
* No partial-fill behavior; trades are atomic.
* Trading resumes automatically when relay submits `federal_action_active = false`.
***
### 10.10 Strategic Positioning
#### 10.10.1 Federal Policy Tailwind
Module 3 aligns with US federal-policy direction across multiple frameworks:
* **Securing US strategic-minerals supply chain** — EO 14017, IRA, Energy Act of 2020 all direct federal effort toward domestic critical-minerals capacity
* **Reducing China dependency** — §232 tariff history on REE and DPA Title III investments target supply-chain diversification
* **Energy transition critical minerals** — IRA 30D vehicle credit, lithium / nickel / cobalt for battery manufacturing
* **Defense supply chain** — National Defense Stockpile, DPA Title III alignment
Module 3 provides the only known on-chain infrastructure capable of trading equity in these strategic assets while:
* Surfacing federal-framework status on-chain in real time
* Automatically halting trading on qualifying federal events
* Maintaining §17A custody compliance for the underlying equity
* Integrating with Empire-vetted institutional investors
#### 10.10.2 Uncontested Capability
No competing tokenization platform offers REG-42 federal-action equivalent capability:
* ERC-3643 has no native federal-action coordination primitive
* Securitize and Tokeny do not address strategic-minerals supply chain
* Real-estate tokenization platforms (RealT, Lofty) have no federal-action framework
* Treasury / fund tokenization (BUIDL, Ondo) does not address commodity-supply-chain assets
Module 3 represents true blue-ocean architectural positioning.
***
### 10.11 Cross-Module Coordination
Module 3 shares with Modules 1 and 2:
* Empire Stock Transfer §17A custody (with `class_label = BAE`)
* Global Unified Liquidity Pool
* CEDEX trading venue
* Custody / OFAC / AML / TWAP oracles (with M3-specific Classification oracle as oracle category 7)
* Reg D / Reg S / Reg CF framework
* USDC / PYUSD GENIUS Act stablecoin settlement
* Layer 9 IDOS compliance intelligence (with Module 3-specific federal-action history pipeline)
Module 3 differs from Modules 1 and 2 by adding:
* **Classification Oracle** (Layer 6 oracle category 7)
* **REG-42 federal-action variant** (Transfer Hook module-aware extension)
* **60-minute SLA** for federal-action detection and enforcement
* **Federal frameworks integration** (USGS, DOE, §232, DPA III, IRA, EO 14017, Energy Act of 2020)
* **BAE corporate vehicle** (vs operating-company Common Class B for M1; SAE for M2)
* **Basin ID** as asset identifier (vs CUSIP for M1; property ID for M2)
* **Auto-resume semantics** for federal-action lift (vs manual-only resume for Control 42 manual freeze)
***
*RWA Tokens Whitepaper V10 — Section 10 — Confidential — Groovy Company, Inc.*
# Empire Stock Transfer — §17A Qualified Custody
## Section 11: Empire Stock Transfer — §17A Qualified Custody
**RWA Tokens Platform Whitepaper · Version 10.0** **Groovy Company, Inc. · May 2026** **Document Reference:** RWA-EMPIRE-SPEC-001 v2.0
Empire Stock Transfer is the platform's exclusive SEC §17A-registered transfer agent, qualified custodian, and sole investor onboarding authority. Empire is the architectural anchor for SEC Category 1 Model B Pillar 3 (SEC §17A-Registered Qualified Custody) and Pillar 4 (True Equity Backing 1:1) across all three modules.
***
### 11.1 Empire's Role and Authority
| Role | Authority |
| ---------------------------- | --------------------------------------------------------------------- |
| Transfer agent | SEC §17A-registered |
| Qualified custodian | Per §17A; holds underlying equity 1:1 across all modules |
| Sole onboarding authority | KYC, KYB, AML, OFAC/SDN, wallet verification — across M1, M2, M3 |
| Cryptographic attestor | Per-Solana-slot Ed25519 attestation of custodied balance |
| MSF maintainer | Master Securityholder File — legally controlling shareholder register |
| Reg D accreditation verifier | §501(a) accredited-investor verification |
| Reg CF eligibility verifier | JOBS Act §4(a)(6) investor-limit verification |
| Module 1 onboarding | Common Class B custody |
| Module 2 onboarding | SAE equity custody |
| Module 3 onboarding | BAE equity custody |
| Founder | Patrick Mokros |
Empire is the platform's institutional anchor. The platform itself does not perform investor onboarding directly. The platform's investor portal (cedex.market) routes to Empire's onboarding dashboard. After Empire approves an investor, Empire signs the wallet-verification attestation that Control IV-15 reads on transfer.
***
### 11.2 The §17A Foundation
#### 11.2.1 Statutory Basis
Section 17A of the Securities Exchange Act of 1934 establishes the framework for SEC registration of transfer agents. §17A-registered transfer agents are subject to:
| Requirement | Source |
| ---------------------------------------- | ------------------------- |
| Annual reporting (Form TA-1, TA-2, TA-W) | SEC Rule 17Ac2-1, 17Ac2-2 |
| Recordkeeping | SEC Rule 17Ad-7 |
| Safeguarding of securities | SEC Rule 17Ad-12 |
| Cybersecurity / business continuity | SEC Rule 17Ad-22 |
| Examination by SEC | Annual / risk-based |
Empire's §17A registration is documented and maintained continuously. Empire's §17A status is the architectural prerequisite for Pillar 3 of Category 1 Model B.
#### 11.2.2 Why §17A Custody Matters
Cryptocurrency-native custodians (BitGo, Fireblocks, Anchorage, etc.) provide custody services for digital assets. They are valuable infrastructure but **are not §17A-registered transfer agents** for traditional securities. They custody the digital token; they do not custody the underlying equity.
ERC-3643 deployments often use crypto-native custodians without §17A registration. This is a Category 2 architectural pattern under Release No. 33-11412 — the underlying equity is typically held by the issuer or a separate party, and the crypto-custody is a token-level overlay.
The platform's architecture instead anchors at §17A. Empire **is** the transfer agent for the underlying equity. The same Empire that custodies the Common Class B / SAE equity / BAE equity also operates the on-chain attestation layer. There is one institutional party that holds custody, maintains the legal register, performs onboarding, and signs attestations. This institutional unification is what eliminates the Category 2 third-party-custody-counterparty surface.
***
### 11.3 Sole Investor Onboarding Authority
#### 11.3.1 Onboarding Scope (All Modules)
Empire is the sole authority for ST22 investor onboarding across all three modules. Empire performs:
| Check | Reference Standard |
| ------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| Identity verification | Customer Identification Program (CIP) per §326 USA PATRIOT Act |
| KYC for individuals | FinCEN CDD; documentary + non-documentary verification |
| KYB for institutions | UBO identification per FinCEN CDD Rule (31 CFR 1010.230); entity formation documents review |
| AML | BSA / AML program; Chainalysis KYT integration; risk scoring |
| OFAC / SDN | Real-time SDN list match (re-verified hourly via SX-10 oracle) |
| Wallet control | Cryptographic challenge-response: investor signs Empire-issued challenge with wallet private key |
| Jurisdiction | Self-certification + corroborating documentation; sets `HoldingPeriodAccount.jurisdiction` |
| Accreditation (Reg D) | §501(a) accredited investor verification per Reg D Rule 501; income / net worth / professional certification path |
| Reg S non-US verification | Non-US residency documentation per Rule 902 |
| Reg CF eligibility | JOBS Act §4(a)(6) per-investor annual limits; income/net-worth scaling per Rule 100(a)(2) |
#### 11.3.2 The Wallet-Verification Attestation
After Empire approves an investor, Empire creates an entry in its Master Securityholder File and signs a wallet-verification attestation that Control IV-15 (`UnregisteredWallet`) reads on transfer:
```rust
#[account]
pub struct EmpireWalletVerification {
pub version: u8,
pub wallet: Pubkey,
pub investor_id_hash: [u8; 32], // Empire's investor ID, hashed
pub jurisdiction: Jurisdiction, // RegD | RegS | RegCF
pub accreditation_ts: i64, // Reg D accreditation valid through
pub kyc_completed_ts: i64, // KYC completion timestamp
pub kyc_expires_ts: i64, // KYC expiration; re-verification required
pub aml_risk_score: u8, // Empire's onboarding-time AML score (0–100)
pub last_update_slot: u64,
pub empire_pubkey: Pubkey,
pub signature: [u8; 64],
pub bump: u8,
}
```
Control IV-15 verifies on every transfer that:
1. The wallet has an `EmpireWalletVerification` PDA (else `UnregisteredWallet`)
2. The Ed25519 signature is valid (verified via Solana native precompile)
3. KYC has not expired (`current_ts < kyc_expires_ts`)
4. The jurisdiction matches the investor's `HoldingPeriodAccount.jurisdiction`
If any check fails, the transfer reverts. Empire's onboarding gate is thereby integrated into the runtime-enforced compliance layer.
***
### 11.4 Per-Slot Ed25519 Custody Attestation
#### 11.4.1 The Attestation Cadence
Empire signs `(mint, custodied_balance, class_label, slot)` with its Ed25519 key every Solana slot (\~400 ms). The signed attestation is submitted to the Custody Oracle PDA. Control CV-04 (Backing Class Match) verifies signature freshness and class consistency on every transfer.
#### 11.4.2 Signing Infrastructure
Empire's signing infrastructure operates a continuous loop:
```
Loop (every Solana slot, ~400 ms):
1. Read MSF state for each mint's custodied class:
- Common Class B balance for M1 mints
- SAE common stock balance for M2 mints
- BAE common stock balance for M3 mints
2. For each mint with delta or every Nth slot:
a. Compute msg = (mint || balance || class_label || slot)
b. signature = Ed25519_sign(empire_priv, msg)
c. Submit Solana transaction updating CustodyOracle PDA
3. Monitor for failures; retry with priority fee on backoff
4. Failover to backup signing infrastructure on detection of failure
```
Continuous-loop architecture details:
* **Hot signing key** stored in Hardware Security Module (HSM)
* **Multi-signer redundancy** — three signing instances across separate cloud providers
* **Health monitoring** — Datadog alerts on signing-loop failures
* **Priority-fee budget** — reserved for SLA-critical attestations
* **Backup keys** — cold storage; rotation procedure documented in Empire Stock Transfer Integration Guide §10
#### 11.4.3 Attestation Failure Handling
If Empire's signing service fails:
| Failure Mode | Detection | Effect | Recovery |
| ----------------------------------------- | ------------------------------------------ | ------------------------------------------------------ | --------------------------------------------------------- |
| Single-slot miss | Monitoring alert | None (1-slot tolerance per CV-02) | Auto-recover on next slot |
| Multi-slot miss (≥ 2 slots) | Monitoring alert | Control CV-02 starts rejecting transfers | Auto-recover on next valid attestation |
| Sustained failure (≥ 30 slots / \~12 sec) | Monitoring alert + PagerDuty | Control CV-40 halts affected category | Manual signing-service restart; auto-resume on resolution |
| Signing key compromise | External notification or anomaly detection | Manual freeze via Control 42 + governance key rotation | Backup-key activation with platform multi-sig |
***
### 11.5 Master Securityholder File (MSF) and On-Chain Reconciliation
#### 11.5.1 MSF Authority
The Empire MSF is the legally controlling shareholder register under W\.S. 34-29-101 (Wyoming Digital Asset Statute). The on-chain SPL Token-2022 ledger is the **transfer notification layer**. The two are continuously reconciled via the Ed25519 attestation.
#### 11.5.2 Reconciliation Architecture
```
On-chain ST22 token-account balances (real-time on Solana)
↕ (reconciled per slot via Custody Oracle attestation)
Empire MSF state (legally controlling)
↕ (reconciled via §17A processes)
Underlying equity (Common Class B / SAE equity / BAE equity)
```
In normal operation, all three layers are synchronized:
* A token transfer on Solana triggers Transfer Hook execution
* On success, on-chain balances update atomically
* Empire's signing service detects the new state at next slot and signs an updated attestation
* MSF records reflect the new state
If divergence occurs:
* Empire is the legally controlling reference
* Control 42 can be invoked to halt trading pending reconciliation
* Reconciliation procedure documented in Incident Response Playbook §13
#### 11.5.3 Why Reconciliation Per Slot
ERC-3643 reconciliation is typically periodic (daily, weekly). The platform's per-slot reconciliation provides:
* **Continuous integrity** — divergence detection within \~400 ms
* **Strong audit trail** — every slot has a signed attestation; full historical reconstruction possible
* **Mathematical Pillar 4 satisfaction** — 1:1 backing is verifiable on every transfer, not just per-audit
* **Reduced attack surface** — there is no "off-chain divergence window" during which an attacker could exploit balance mismatches
***
### 11.6 Cross-Module Custody — One Gate, Three Asset Classes
Empire's §17A authority extends across all three modules. The same onboarding gate covers Module 1, Module 2, and Module 3:
| Module | Custodied Class | `class_label` | Backing Verification Path |
| -------- | ---------------- | --------------------- | ------------------------------------------------------------------ |
| Module 1 | Common Class B | `AssetClass::CommonB` | Empire MSF Common B balance |
| Module 2 | SAE common stock | `AssetClass::SAE` | Empire MSF SAE equity balance + NAV oracle (Section 9) |
| Module 3 | BAE common stock | `AssetClass::BAE` | Empire MSF BAE equity balance + Classification oracle (Section 10) |
The investor goes through Empire onboarding once and can hold ST22 tokens across all three modules without re-onboarding. KYC re-verification is required per Empire's standard cadence (typically annual). Reg D accreditation re-verification is required per the Reg D standard (annually). Reg CF investor limits are tracked per investor across all CF investments (not just platform investments) per Empire's data sharing with the funding portal partner.
#### 11.6.1 Module-Specific Custody Operations
| Operation | Module 1 | Module 2 | Module 3 |
| -------------------------- | -------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| Custody intake | Common Class B paper certificate or electronic record | SAE common stock certificate; corporate documents | BAE common stock certificate; corporate documents + basin documentation |
| CUSIP issuance | Yes (M1 standard) | Property ID assigned (not CUSIP) | Basin ID assigned (not CUSIP) |
| Corporate-actions handling | Standard transfer agent corporate actions (dividends, splits, conversions) | SAE corporate actions (dividends to ST22 holders; reorganization scenarios) | BAE corporate actions (federal-action coordination; reorganization scenarios) |
| §17A reporting | Form TA-1 / TA-2 disclosure | Form TA-1 / TA-2 disclosure | Form TA-1 / TA-2 disclosure |
***
### 11.7 Empire's Independence
A critical compliance property: **Empire is operationally independent of Groovy Company.** Empire is a separate entity with its own §17A registration, its own KYB processes, and its own examination obligations. The platform operates under tripartite governance for Module 2 NAV-band parameters and Module 3 Classification parameters, where Empire's signature is one of three required.
Empire's independence:
* Eliminates the platform's ability to bypass Empire (no shortcut path exists)
* Protects investors from platform-driven custody manipulation
* Provides regulatory comfort that custody is at arms-length from the platform operator
* Ensures Empire's signing key cannot be compromised by platform code
The CTO of Groovy Company, Frank Yglesias, also serves as Chairman & CTO. Patrick Mokros is COO of Groovy Company AND the Founder of Empire Stock Transfer. The relationship between the two entities is documented and structurally arms-length per their respective governance documents. The on-chain architecture's tripartite governance for module-specific parameters embeds this independence in the runtime.
***
### 11.8 Empire and Each Pillar of Category 1 Model B
| Pillar | Empire's Contribution |
| ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| 1. Direct Issuer Authorization | Empire's KYB process verifies issuer board authorization before mint creation |
| 2. Official Shareholder Register on DLT | Empire MSF is the legally controlling register; reconciled per slot to on-chain ledger |
| 3. SEC §17A-Registered Qualified Custody | Empire IS the §17A-registered custodian (this pillar) |
| 4. True Equity Backing 1:1 | Empire's per-slot Ed25519 attestation feeds Custody Oracle; verified by Control CV-01 |
| 5. Clear Ownership Chain | Empire holds the equity; CUSIP / property ID / basin ID linkage flows from Empire's records |
| 6. Investor Protection | Empire's onboarding gate is the entry point; ongoing compliance via Empire-provided attestations and re-verifications |
| 7. Token Standard Immutability | Architectural — not Empire's role, but Empire-anchored architecture is what makes immutability viable for compliance |
Empire is involved in 6 of 7 pillars directly. The seventh (immutability) is structural and depends on the SPL Token-2022 standard's runtime properties.
***
### 11.9 Empire-Specific Risk Mitigation
| Risk | Mitigation |
| ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| Empire signing key compromise | HSM custody; multi-signer redundancy; key rotation procedure; manual freeze via Control 42 on detection |
| Empire operational failure (extended) | Failover signing infrastructure; Control CV-40 halts on consensus failure; backup §17A-registered custodian relationship documented but not active |
| Empire-platform divergence | MSF is controlling; reconciliation per Incident Response Playbook §13 |
| Empire regulatory action | Continuity plan; backup §17A custodian relationship; Control 42 halt during transition |
| KYC database breach at Empire | Empire's data security per Rule 17Ad-22; encrypted storage; on-chain attestation does not store PII |
***
### 11.10 Empire's Differentiation vs Crypto-Native Custodians
| Attribute | Crypto-Native Custodian (BitGo, Fireblocks, Anchorage) | Empire Stock Transfer |
| -------------------------------------- | ------------------------------------------------------ | ---------------------------------- |
| §17A registration | No | Yes |
| Custody object | Token (digital) | Underlying equity (legal) |
| Investor onboarding scope | Often token-only | Full KYC/KYB/AML/OFAC/Reg D/Reg CF |
| Per-slot attestation | Not standard | Yes — architectural integration |
| Master register | No | Yes — MSF |
| Reg D accreditation verification | Limited | Yes |
| §17A reporting | Not applicable | Annual to SEC |
| Cross-asset-class scope (M1 + M2 + M3) | Token type only | All three modules |
For Category 1 Model B compliance, §17A custody is the architectural requirement. Crypto-native custodians are valuable for token-level operations but cannot substitute for §17A custody. Empire's role spans both layers — it operates §17A custody of the underlying equity AND the cryptographic attestation layer that integrates with the on-chain compliance program.
***
*RWA Tokens Whitepaper V10 — Section 11 — Confidential — Groovy Company, Inc.*
# Regulatory Framework — Current SEC and Federal Guidelines
## Section 12: Regulatory Framework — Current SEC and Federal Guidelines
**RWA Tokens Platform Whitepaper · Version 10.0** **Groovy Company, Inc. · May 2026** **Document Reference:** RWA-REG-SPEC-001 v3.0
The platform's regulatory foundation rests on the binding federal taxonomy in SEC–CFTC Release No. 33-11412 and a series of staff statements and federal frameworks issued through 2026. This section documents every authority that governs platform operation, with technical mapping from each authority to platform architectural components.
***
### 12.1 SEC–CFTC Release No. 33-11412 (March 17, 2026, Binding)
#### 12.1.1 Authority and Effect
Release No. 33-11412 establishes the **Five-Category Taxonomy** for digital assets and is the controlling federal classification framework for the platform. It supersedes prior fragmentary digital-asset guidance and provides binding classification across SEC and CFTC jurisdictional surfaces.
#### 12.1.2 Five-Category Taxonomy
| Category | Classification | Platform Mapping |
| -------------- | -------------------------------- | ------------------------------------------------------------------------ |
| **Category 1** | Digital Commodity (non-security) | GROO Utility Token (where applicable) |
| **Category 2** | Digital Currency / Stablecoin | Settlement layer (USDC, PYUSD via GENIUS Act) |
| **Category 3** | Digital Tool / Utility Token | GROO Utility Token (alternative classification path) |
| **Category 4** | Digital Collectible / NFT | Outside platform scope |
| **Category 5** | **Digital Security** | **ST22 Digital Securities (M1, M2, M3) and Groovy Security Token (STO)** |
#### 12.1.3 Category 5 Models
Within Category 5, the Release distinguishes two compliance models:
**Model A — Third-Party Sponsored**
A platform intermediary holds tokens or controls compliance overlays. Counterparty risk exists. Mapped by the January 28, 2026 Joint Staff Statement to higher-counterparty-risk Category 2 architectures.
**Model B — Issuer-Sponsored**
The issuer authorizes tokenization via board resolution; DLT functions as the official shareholder register; runtime-level enforcement removes admin-override risk. **The platform operates exclusively under Model B across all three modules.**
#### 12.1.4 Architectural Compliance with Release No. 33-11412
| Release Requirement | Platform Mechanism |
| ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| Issuer-authorized mint | Issuer board resolution; Empire onboarding gate refuses without Certificate of Designation (M1) / Articles of SAE (M2) / Articles of BAE (M3) |
| §17A custody | Empire Stock Transfer §17A-registered transfer agent; sole onboarding authority across all three modules |
| 1:1 backing | Custody Oracle per-slot Ed25519 attestation; Control CV-01 enforces on every transfer |
| Compliance at every transfer | SPL Token-2022 Transfer Hook (42 controls + module-aware extensions) |
| Immutability | Transfer Hook program ID bound to mint at creation; Certora E.4, E.6 |
| Asset identifier | CUSIP (M1) / property ID (M2) / basin ID (M3) on-chain in `SecurityConfig` |
***
### 12.2 January 28, 2026 Joint Staff Statement on Tokenized Securities
#### 12.2.1 The Seven Pillars Framework
The Joint Staff Statement clarifies the **seven pillars** of Category 1 Model B and explicitly distinguishes Model B from Category 2 third-party sponsored tokenization:
1. **Direct Issuer Authorization** — board resolution authorizes the mint
2. **Official Shareholder Register on DLT** — the on-chain ledger is legally the register
3. **SEC §17A-Registered Qualified Custody** — qualified custodian holds underlying
4. **True Equity Backing (1:1)** — verifiable on-chain attestation
5. **Clear Ownership Chain / Asset Identifier** — on-chain mapping to underlying
6. **Investor Protection (compliance enforcement at every transfer)** — runtime-enforced
7. **Token Standard Compliance (immutable, no admin override)** — protocol-level immutability
#### 12.2.2 The Category 1 Model B vs Category 2 Distinction
The Joint Staff Statement explicitly identifies the compliance gap that defines Category 2: **application-layer compliance overlays that can be bypassed**. ERC-3643's `transfer()` function is a Category 2 architecture. ST22's runtime-enforced Transfer Hook is a Category 1 Model B architecture.
#### 12.2.3 Native Pillar Satisfaction
| # | Pillar | ERC-3643 | ST22 |
| - | ------------------------------------ | ---------------------------------- | ------------------------------------------- |
| 1 | Direct Issuer Authorization | ⚠️ Off-chain | ✅ On-chain |
| 2 | Official Shareholder Register on DLT | ❌ Token ledger ≠ register | ✅ MSF + on-chain ledger reconciled per slot |
| 3 | SEC §17A Qualified Custody | ⚠️ Possible but rare | ✅ Architectural requirement |
| 4 | True Equity Backing 1:1 | ⚠️ Off-chain attestation | ✅ Per-slot Ed25519 |
| 5 | Clear Ownership Chain | ⚠️ Off-chain mapping | ✅ On-chain CV-05 |
| 6 | Investor Protection | ⚠️ Application-layer | ✅ Runtime-enforced |
| 7 | Token Standard Immutability | ❌ Proxy upgrades + admin functions | ✅ Bound at creation |
**ST22 native score: 7/7. ERC-3643: 3/7.** Section 14 (ERC-3643 vs ST22) provides the detailed comparison.
***
### 12.3 April 13, 2026 SEC Staff Statement on Covered User Interface Providers
#### 12.3.1 Authority and Effect
The Covered User Interface Statement clarifies that compliance enforcement at the user-interface layer is insufficient; runtime-level enforcement carries weight in regulatory characterization. It addresses the architectural pattern where a UI claims to enforce compliance but the underlying token contract permits non-compliant behavior outside that UI.
#### 12.3.2 Platform Alignment
The platform's architecture maps directly to the Statement's framework:
* **cedex.market is a Covered UI Provider.** It hosts the order book, trading UI, account management, and onboarding flows.
* **Substantive compliance enforcement happens at the Solana Transfer Hook layer, not at the UI.** Even if a user submits transfer transactions directly to a Solana RPC endpoint bypassing cedex.market, the SPL Token-2022 program will refuse the instruction unless the registered Transfer Hook is invoked successfully.
#### 12.3.3 Architectural Composite Weighted Score
The platform's internal analysis of the April 13, 2026 Covered UI Statement produced a composite weighted score of approximately 92% across 10 findings — the highest known alignment of any platform reviewed. Findings included:
| Finding | Platform Status |
| --------------------------------------- | ---------------------------------------------- |
| Runtime-enforced compliance vs UI-layer | Runtime-enforced (Layer 2) |
| Independence from UI for compliance | Yes — RPC bypass cannot avoid hook |
| §17A custody integration | Yes — Empire Stock Transfer |
| Immutability of compliance logic | Yes — Certora E.4, E.6 |
| Investor onboarding gate | Empire-anchored, not UI-anchored |
| Ownership-chain on-chain | Yes — CV-05 |
| 1:1 backing attestation | Per-slot, on-chain — Control CV-01 |
| Compliance-on-every-transfer | Yes — Transfer Hook + module-aware extensions |
| Holding-period enforcement | On-chain via HoldingPeriodAccount; Certora E.5 |
| Cross-asset-class architectural unity | Yes — single architecture, three modules |
***
### 12.4 Wyoming Digital Asset Statute — W\.S. 34-29-101 *et seq.*
#### 12.4.1 Authority and Effect
Wyoming's digital-asset statute (W\.S. 34-29-101 *et seq.*) provides the legal foundation under which DLT records function as effective transfer notification under state law. The platform's governing law is Wyoming for all platform documents. Wyoming provides:
* Treatment of DLT records as legally effective transfer-notification layer
* Recognition of digital-asset securities as a recognized category of property
* Clarification that on-chain transfers can satisfy state-law transfer requirements when properly structured
#### 12.4.2 Platform Alignment
| Statutory Provision | Platform Mechanism |
| ----------------------------------------- | ------------------------------------------------------------------------- |
| DLT as transfer notification | SPL Token-2022 ledger functions as transfer notification layer |
| Master register controlling | Empire MSF is the legally controlling shareholder register |
| Reconciliation requirement | Custody Oracle Ed25519 attestation per Solana slot |
| Recognition of cryptographic verification | Native Ed25519 precompile satisfies cryptographic-verification provisions |
Wyoming domicile + Wyoming governing law + W\.S. 34-29-101 alignment provide the state-law backbone that complements federal SEC compliance.
***
### 12.5 GENIUS Act — Stablecoin Settlement
#### 12.5.1 Authority and Effect
The GENIUS Act establishes the federal framework for compliant payment-stablecoin issuance and use. It provides:
* Recognition of payment stablecoins as compliant settlement instruments
* Reserve requirements (1:1 USD backing)
* Audit and attestation requirements (monthly reserve attestations)
* Issuer-licensing framework
* Clarity around the use of payment stablecoins for tokenized-securities settlement
#### 12.5.2 Platform Settlement Architecture
The platform settles all ST22 purchases and CEDEX trades in **USDC** (Circle) or **PYUSD** (Paxos) — both GENIUS Act-compliant payment stablecoins. The platform does not accept fiat wire transfers or native crypto for ST22 purchases. ADR-009 documents the rationale:
| Reason | Detail |
| -------------------------------------- | --------------------------------------------------------------------------- |
| Regulatory clarity | GENIUS Act establishes federal compliance framework for payment stablecoins |
| Atomic on-chain settlement | Stablecoin transfer and ST22 transfer occur in the same Solana transaction |
| Velocity match to Solana finality | \~400 ms; fiat wires take 1–3 business days |
| No counterparty risk on settlement leg | USDC and PYUSD are 1:1 USD-backed |
| Institutional reserves | Both publish monthly reserve attestations |
***
### 12.6 Reg D / Reg S / Reg CF Offering Exemption Framework
#### 12.6.1 Reg D — US Accredited Investors
| Element | Detail |
| ----------------------------------- | ------------------------------------------------------------------------------ |
| Statutory basis | Regulation D under Securities Act of 1933 |
| Investor class | US accredited per §501(a) |
| Holding period (Rule 144) | 6 months for unrestricted resale of fully-paid securities of reporting issuers |
| Holding period (general restricted) | 12 months for non-reporting issuers under Rule 144(d) |
| Platform standard | 6 months (`RULE_144_HOLDING_SECS = 15_778_800`) for reporting-issuer Reg D |
| On-chain enforcement | Control HP-24 reads `HoldingPeriodAccount.holding_period_secs` |
| Accreditation verification | Empire Stock Transfer at onboarding; Control IV-12 verifies on-chain status |
#### 12.6.2 Reg S — Non-US Investors
| Element | Detail |
| ------------------------------ | ------------------------------------------------------------------------ |
| Statutory basis | Regulation S under Securities Act of 1933 |
| Investor class | Non-US per Rule 902 definition |
| Distribution compliance period | 12 months for Category 3 issuers (most common platform configuration) |
| Platform standard | 12 months (`REG_S_COMPLIANCE_SECS = 31_536_000`) |
| On-chain enforcement | Control HP-24 + Control IV-18 (US-person check during compliance period) |
| Empire role | Sets `Jurisdiction::RegS`; stores non-US verification |
#### 12.6.3 Reg CF — US Retail Crowdfunding
| Element | Detail |
| -------------------------- | ------------------------------------------------------------------------ |
| Statutory basis | JOBS Act §4(a)(6); Regulation Crowdfunding Rules 100–504 |
| Investor class | US retail (subject to investor limits) |
| Annual investment limit | Per-investor limits scaled by income / net worth per JOBS Act §4(a)(6) |
| Holding period | 12 months for restricted securities (`REG_CF_HOLDING_SECS = 31_536_000`) |
| Funding portal requirement | FINRA-registered funding portal partnership |
| On-chain enforcement | Control HP-24 + Control IV-19 (Reg CF investor limit) |
| Empire role | Reg CF eligibility per JOBS Act §4(a)(6); income/net-worth verification |
#### 12.6.4 On-Chain Holding-Period Enforcement (Certora E.5)
Holding periods are immutable timers stored in `HoldingPeriodAccount`. The `purchase_timestamp` is set exactly once at token delivery and never written after. Certora invariant E.5 formally proves the timer cannot be shortened by any execution path. There is no admin function to bypass — not in the Transfer Hook, not in governance, not in the SecurityConfig program.
***
### 12.7 CFTC Letters 25-39 (2025) and 26-05 (2026)
#### 12.7.1 Authority and Effect
The Commodity Futures Trading Commission issued staff Letters addressing tokenized derivatives (Letter 25-39) and tokenized commodities (Letter 26-05). The platform's GROO Utility Token classification under Release No. 33-11412 (Category 1 Digital Commodity or Category 3 Digital Tool, not a security) intersects CFTC jurisdiction. Module 3 (CORECM) intersection with strategic-mineral supply-chain assets implicates CFTC-adjacent regulatory considerations.
#### 12.7.2 Platform Engagement
The platform engages with the CFTC rulemaking comment period (August 2026) and will submit comment letters via direct mail to the Secretary, Christopher Kirkpatrick, and the Market Participants Division. The comment period is the formal mechanism for industry input on CFTC rulemaking.
#### 12.7.3 Module 3 CFTC Implications
Module 3 commodity-supply-chain tokenization may implicate CFTC jurisdiction in specific cases:
* Where ST22 Module 3 tokens reference a future commodity-delivery obligation (potential derivatives characterization) — the platform's BAE structure avoids this by tokenizing equity in a corporate vehicle rather than a future delivery
* Where ST22 Module 3 trading creates synthetic commodity-price exposure — addressed via the CB-21 NAV variant (where applicable) and BAE corporate-equity structure that is not direct commodity-price exposure
***
### 12.8 Howey Test — Historical Reference
#### 12.8.1 Authority Status
The Howey test (*SEC v. W\.J. Howey Co.*, 328 U.S. 293 (1946)) remains the foundational securities-classification test, but the binding federal taxonomy is now Release No. 33-11412 with its Five-Category framework. The Howey four-factor analysis is preserved as historical doctrinal reference, but operational classification of platform tokens follows the Release.
#### 12.8.2 Howey Application to Platform Tokens
| Token | Howey Analysis | Release No. 33-11412 Classification |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------- |
| GROO Utility Token | No common enterprise (peer-to-peer use); no expectation of profits from efforts of others; bonding-curve distribution removes promoter influence | Category 1 (Digital Commodity) or Category 3 (Digital Tool) |
| Groovy Security Token (STO) | Common enterprise (Groovy Company); profit expectation tied to platform performance; managerial efforts of platform team | Category 5 (Digital Security) |
| ST22 Digital Securities | Common enterprise (per-issuer); profit expectation; managerial efforts of issuer | Category 5 (Digital Security) |
Where Howey and the Release conflict in marginal cases, the Release controls as the more recent and more specific federal pronouncement on digital-asset taxonomy.
***
### 12.9 Module 3 Federal Frameworks — Critical Minerals Supply Chain
Module 3 (CORECM) operates within a constellation of federal frameworks governing US strategic-minerals supply-chain policy. Each framework is surfaced on-chain through the Classification Oracle (Section 6.8).
#### 12.9.1 USGS Critical Minerals List
The US Geological Survey publishes the Critical Minerals List (most recently updated 2022, with annual reassessment). It defines minerals classified as critical to US economic and national security based on supply-chain vulnerability and strategic importance. Classification Oracle bitfield: `STATUS_USGS_CRITICAL`.
#### 12.9.2 DOE Critical Materials Strategy
Department of Energy framework that includes specific programs around coal-derived REE recovery and other strategic-mineral supply-chain initiatives. Classification Oracle bitfield: `STATUS_DOE_CRITICAL`.
#### 12.9.3 Section 232 of the Trade Expansion Act of 1962
Section 232 authorizes the President to impose tariffs and import restrictions on national-security grounds. Federal-action kind: `KIND_SECTION_232` (Classification Oracle field). REG-42 federal-action variant triggers automatic 60-minute SLA freeze on detection.
#### 12.9.4 Defense Production Act (DPA) Title III
DPA Title III authorizes federal investment in domestic critical-minerals production. Classification Oracle bitfield: `STATUS_DPA_III_PROGRAM`. Federal-action kind: `KIND_DPA_III`.
#### 12.9.5 Inflation Reduction Act — Critical Minerals Provisions
The IRA includes critical-minerals tax credits (e.g., 30D vehicle credit's domestic-content thresholds) and supply-chain incentives. Classification Oracle bitfield: `STATUS_IRA_30D_ELIGIBLE`.
#### 12.9.6 Executive Order 14017 — America's Supply Chains
EO 14017 directs federal agencies to assess and strengthen supply chains in critical sectors. Classification Oracle bitfield: `STATUS_EO14017_LISTED`. Federal-action kind: `KIND_EXECUTIVE_ORDER`.
#### 12.9.7 Energy Act of 2020
Establishes federal critical-minerals research and innovation programs. Classification Oracle bitfield: `STATUS_ENERGY_ACT_2020`.
#### 12.9.8 Defense Logistics — National Stockpile
Where applicable, BAE participation in National Defense Stockpile programs is flagged via Classification Oracle bitfield `STATUS_DEFENSE_LOGISTICS`.
***
### 12.10 SEC EDGAR Reporting Posture (Module 1)
For Module 1 issuers that are SEC-reporting companies, the platform's ST22 issuance does not change SEC reporting obligations. The issuer continues to file 10-K, 10-Q, 8-K, and beneficial-ownership reports per Exchange Act Section 13. The on-chain ledger feeds Layer 9 IDOS (via the EDGAR Oracle, Section 6.6) for issuer-distress signal generation but does not substitute for required SEC filings.
***
### 12.11 Anti-Money Laundering and Sanctions Compliance
#### 12.11.1 BSA / AML Program
Empire Stock Transfer operates a Bank Secrecy Act / Anti-Money Laundering program covering all platform investor onboarding. The program includes:
| Element | Implementation |
| ------------------------------------- | -------------------------------------------------------------- |
| Customer Identification Program (CIP) | §326 USA PATRIOT Act compliance |
| Customer Due Diligence (CDD) | FinCEN CDD Rule (31 CFR 1010.230) |
| Beneficial ownership | UBO identification per CDD Rule |
| Enhanced Due Diligence (EDD) | High-risk wallet path triggered by AML Oracle risk score 31–70 |
| Suspicious Activity Reporting (SAR) | FinCEN SAR filing as required |
| Recordkeeping | 5-year retention per BSA |
| Annual independent testing | Per BSA examination requirements |
#### 12.11.2 OFAC / SDN Compliance
The OFAC Oracle (Section 6.3) provides per-transfer SDN screening via a Bloom filter encoding sanctioned addresses. Controls SX-08 and SX-09 reject transfers involving sanctioned addresses. Control SX-10 rejects transfers when the OFAC oracle is stale beyond 90 minutes. The program covers all jurisdictions where Empire onboards investors.
***
### 12.12 Authoritative References (Consolidated)
| Authority | Citation |
| ----------------------------------------------------------- | ------------------------------------------------------------ |
| **SEC–CFTC Release No. 33-11412** | March 17, 2026, binding |
| **SEC Joint Staff Statement on Tokenized Securities** | January 28, 2026 |
| **SEC Staff Statement on Covered User Interface Providers** | April 13, 2026 |
| **GENIUS Act** | Federal stablecoin framework |
| **Wyoming Digital Asset Statute** | W\.S. 34-29-101 *et seq.* |
| **CFTC Letter 25-39** | 2025 |
| **CFTC Letter 26-05** | 2026 |
| **Securities Act of 1933 — Reg D** | 17 CFR 230.501 *et seq.* |
| **Securities Act of 1933 — Reg S** | 17 CFR 230.901 *et seq.* |
| **JOBS Act §4(a)(6) — Reg CF** | 17 CFR 227.100 *et seq.* |
| **Securities Exchange Act §17A** | Empire Stock Transfer registration |
| **USGS Critical Minerals List** | USGS publication |
| **DOE Critical Materials Strategy** | DOE publication |
| **Section 232 of Trade Expansion Act of 1962** | 19 U.S.C. § 1862 |
| **Defense Production Act Title III** | 50 U.S.C. § 4533 |
| **Inflation Reduction Act — Critical Minerals** | Public Law 117-169 |
| **Executive Order 14017** | "America's Supply Chains," February 24, 2021 |
| **Energy Act of 2020** | Title III of Consolidated Appropriations Act, 2021 |
| **EIP-3643** | December 2023, Final |
| **SPL Token-2022 Specification** | `spl-token-2022` source; `spl-transfer-hook-interface` v0.6+ |
***
### 12.13 Case Law
| Case | Citation | Relevance |
| -------------------------------- | ----------------------------------- | ------------------------------------------------------------------- |
| *SEC v. W\.J. Howey Co.* | 328 U.S. 293 (1946) | Foundational securities-classification test (historical) |
| *SEC v. Telegram* | 448 F. Supp. 3d 352 (S.D.N.Y. 2020) | Issuer-discretion enforcement risk; supports immutability rationale |
| *SEC v. Kik Interactive* | 492 F. Supp. 3d 169 (S.D.N.Y. 2020) | Distribution architecture as a Howey factor |
| *Copley Fund* | Various | Investment-company classification adjacency |
| *NAPFM v. SEC* | Various | Administrative-procedure considerations for SEC rulemaking |
| *Coinbase* | Various | Digital-asset platform regulatory characterization |
| *Risley* | Various | Token-classification considerations |
| *Crypto Freedom Alliance v. SEC* | Various | Recent challenges to SEC digital-asset positions |
***
*RWA Tokens Whitepaper V10 — Section 12 — Confidential — Groovy Company, Inc.*
# Tokenomics
## SECTION 13 — Tokenomics
**RWA Tokens Platform Whitepaper · V10.0 · May 2026** **Issued by:** Groovy Company, Inc. (Wyoming corporation; OTC: GROO; SEC EDGAR CIK 1499275) **Section classification:** Technical Specification — Economic Architecture **Authority:** SEC–CFTC Release No. 33-11412; GENIUS Act; Wyoming W\.S. 34-29-101
***
### 13.1 Scope
This section documents the complete economic architecture of the RWA Tokens platform — the three-token classification (GROO Utility Token, Groovy Security Token (STO), and ST22 Digital Securities), the unified 5% fee structure applied to all ST22 transactions across all three modules, the immutable 0.44% lock that permanently funds the Global Unified Liquidity Pool, the staking architecture for the Groovy Security Token, the GROO bonding curve distribution mechanics, the five-year platform revenue model, and the module-aware economic considerations for Module 2 (NAV-bound) and Module 3 (federal-action-bound) issuances.
All allocations described in this section are enforced in Solana program logic (the `transfer_hook`, `amm`, `liquidity_pool`, and staking programs) and cannot be altered by governance vote, administrative function, or any other mechanism — except parameter ranges explicitly defined as governance-modifiable in Section 17.
### 13.2 Three-Token Architecture
The platform involves three distinct token classes with distinct legal classifications, distinct economic roles, and distinct regulatory frameworks. They are **not** interchangeable. Conflating them is the single largest risk in platform discourse.
#### 13.2.1 Token Comparison Table
| Attribute | GROO Utility Token | Groovy Security Token (STO) | ST22 Digital Security |
| --------------------------------------- | -------------------------------------------------------------------------------- | ----------------------------------------- | --------------------------------------------------------- |
| **Issuer** | Platform ecosystem | Groovy Company, Inc. | Third-party issuer (per module) |
| **Release No. 33-11412 classification** | Category 1 (Digital Commodity) or Category 3 (Digital Tool) — **not a security** | Category 5 (Digital Security) | Category 5 (Digital Security) |
| **Backing** | None | Common Class B of Groovy Company, Inc. | M1: issuer Common Class B; M2: SAE equity; M3: BAE equity |
| **Custody** | None required | Empire Stock Transfer 1:1 | Empire Stock Transfer 1:1 |
| **Distribution** | Deterministic linear bonding curve | $20M Reg D raise | Per-issuer Reg D / Reg S / Reg CF |
| **Trading venue** | Open (subject to local regs) | CEDEX | CEDEX |
| **Holding period** | None | Reg D 6-month | Reg D 6-month / Reg S 12-month / Reg CF 12-month |
| **Transfer Hook controls** | Not applicable | Full 42 controls | Full 42 controls + module-aware extensions |
| **Governance rights** | Post-graduation (2028+) | Common Class B voting rights | Common Class B / SAE / BAE shareholder rights |
| **Fee participation** | Staking rewards (1.5% of all CEDEX trades) | Issuer participation in Groovy Co revenue | Issuer participation per § 13.4 |
#### 13.2.2 GROO Utility Token — Distribution Architecture
The GROO Utility Token is distributed through a **deterministic linear bonding curve** with no pre-sale, no founder allocation, no treasury reserve, and no ICO until governance-decided Scale phase Dutch auction. The distribution mechanism is mathematically transparent and on-chain.
**Bonding curve formula:**
```
price(supply) = base_price + slope × supply
```
Where:
* `base_price = 0.000001 SOL` (1 micro-SOL — the bonding curve starting price)
* `slope = 1e-15 SOL per token` (linear price increase per token minted)
* `supply` = current GROO supply in circulation
The deterministic, transparent, and admin-free nature of the bonding curve is itself part of the GROO classification posture: it cannot be characterized as an "issuer-managed offering" because there is no issuer-managed offering. The bonding curve runs in the `groo_bonding_curve` Solana program; there is no admin function to modify `base_price` or `slope` post-deployment.
**Phase progression:**
| Phase | Trigger | Effect |
| --------------- | ----------------------- | ----------------------------------------------------------------------------------- |
| Genesis | Program deployment | Bonding curve active; price = 0.000001 SOL |
| Bonding | Accumulating purchases | Linear price increase per token; SOL collected to escrow |
| Graduation | $1M+ TVL milestone | Liquidity migrated to Global Unified Pool; LP burned |
| Post-graduation | Pool active | GROO trades on CEDEX (and external venues subject to local regs); staking activates |
| Scale | Governance vote (2028+) | Optional Dutch auction for additional supply; not imminent |
#### 13.2.3 Groovy Security Token (STO) — $20M Reg D Architecture
The Groovy Security Token is the platform operator's own equity tokenization. It is structurally identical to a Module 1 ST22 Digital Security except that the issuer is Groovy Company, Inc. itself. Salient features:
| Feature | Value |
| --------------------------- | ------------------------------------------------------------------------ |
| Backing | Common Class B of Groovy Company, Inc. |
| Offering size | $20,000,000 Reg D (US accredited investors) |
| Offering price | Per Form D filing |
| Minimum investment | $25,000 (institutional-grade ticket) |
| Use of proceeds | Seeds Global Unified Liquidity Pool via Solana Treasury PDA |
| Holding period | Reg D 6-month (HP-24 enforced) |
| Trading post-holding-period | CEDEX |
| Wallet cap | 9.99% of supply (default) |
| Compliance | Full 42 controls; Empire onboarding; Custody Oracle attestation per slot |
The use-of-proceeds allocation — seeding the Global Unified Liquidity Pool — is the architectural mechanism by which the platform's primary capital event becomes the foundation of the platform's permanent shared liquidity infrastructure. The $20M is transferred to the Solana Treasury PDA, then routed through the `liquidity_pool` program to the Global Pool, where the corresponding LP tokens are immediately burned. **The capital is one-way: it flows in and never returns.**
#### 13.2.4 ST22 Digital Securities — Per-Issuer, Per-Module
ST22 Digital Securities are the per-issuer tokenization product. Each issuer operates within its own ST22 mint with its own SecurityConfig PDA, its own custody attestation, and its own holding-period accounting. ST22 economics are issuer-specific within the constraints of the immutable 5% fee structure (§13.3).
### 13.3 The Unified 5% Fee Architecture
The platform charges a **single unified 5% transaction fee** on all ST22 Digital Security transactions across all three modules. The fee applies identically at both phases of the ST22 lifecycle: the primary offering (pre-CEDEX, during the Reg D / Reg S / Reg CF capital raise) and all secondary market trading on CEDEX (post-CEDEX, after holding periods expire).
#### 13.3.1 Fee Application — Primary Offering Phase
When an investor purchases ST22 tokens during an active offering, the 5% fee is deducted from the gross subscription amount before proceeds are remitted to the issuer:
| Cash Flow | Allocation |
| ---------------------------------- | ------------------------ |
| Investor pays (gross subscription) | 100.00 USDC or PYUSD |
| Issuer receives (net of fee) | 95.00 USDC or PYUSD |
| Platform fee | 5.00 USDC or PYUSD |
| Investor receives | 100% of tokens purchased |
The fee is a cost of platform access, not a dilution of token allocation. The investor's token receipt equals the full subscription amount divided by the offering price; the fee is structured so the investor is not penalized in token quantity.
#### 13.3.2 Fee Application — Secondary Market (CEDEX) Phase
Every ST22 trade executed on CEDEX after the applicable holding period expires carries the same 5% fee. This fee applies on every trade, continuously and permanently, for the life of the ST22 issuance. The issuer receives no share of secondary market trading fees.
| Cash Flow | Allocation |
| ------------------------------ | -------------------- |
| Buyer pays (gross trade value) | 100.00 USDC or PYUSD |
| Seller receives (net of fee) | 95.00 USDC or PYUSD |
| Platform fee | 5.00 USDC or PYUSD |
#### 13.3.3 5% Fee Decomposition — Cross-Module
Of every 5% fee charged on every ST22 transaction (primary or secondary, M1 / M2 / M3), the fee is split into four components enforced atomically in the Transfer Hook execution path:
| Component | Allocation | Routing |
| ------------------------ | ---------- | ------------------------------------------------------------------- |
| **Issuer rebate** | 2.00% | Issuer Treasury PDA (controlled by issuer multi-sig) |
| **Staking rewards** | 1.50% | Staking program reward pool (distributed to GROO stakers per epoch) |
| **Protocol revenue** | 1.06% | Platform Treasury PDA (operational expenses; reserve fund) |
| **Global Pool (locked)** | 0.44% | Global Unified Liquidity Pool — LP burned at receipt |
| **Total** | **5.00%** | |
The four allocations are enforced in the `transfer_hook` program logic via Control GA-42 (audit emission and fee distribution). The percentages are immutable: the only governance-modifiable parameter is the *destination* multi-sig signer set for the issuer rebate, never the *amount* of the four splits. Certora invariant E.4 covers this immutability.
#### 13.3.4 0.44% Permanent Lock — Architectural Detail
The 0.44% routed to the Global Unified Liquidity Pool is the most important component of the fee architecture from a network-effect standpoint. Three properties combine:
1. **Immutable enforcement.** The 0.44% routing is part of the `transfer_hook` GA-42 logic. The `transfer_hook` is deployed with no upgrade authority (§5.6.2). The split cannot be altered.
2. **LP burned at receipt.** When the 0.44% reaches the `liquidity_pool` program, the corresponding LP tokens are immediately burned via SPL Token-2022 burn instruction. Withdrawal becomes mathematically impossible.
3. **Cross-module accumulation.** All three modules feed the same pool. A Module 3 BAE basin's $50M trading volume contributes $220K (0.44%) to the pool. That liquidity supports a Module 1 OTC microcap issuer's secondary market by deepening the shared reserve.
**Certora invariant E.3 (Pool Non-Extractability):** No execution path exists by which the Global Pool's reserves can be debited to a withdrawal destination. This is the mathematical guarantee of non-rugpull. See Section 15.
### 13.4 Issuer Economics — 2% Rebate
The 2% issuer rebate component is the issuer's continuous economic participation in their ST22 issuance's secondary market activity. Unlike traditional securities offerings where the issuer's economic relationship to investors is largely confined to the primary offering plus dividends, the platform's 2% rebate creates a perpetual issuer-revenue stream tied to secondary trading volume.
#### 13.4.1 Issuer Rebate by Module
| Module | Issuer Rebate Use Case |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Module 1 — Equities** | Issuer Treasury operational funding; corporate development; bolt-on acquisitions; share repurchase |
| **Module 2 — Real Estate** | SAE operational reserves; property maintenance / capex; appraiser fees; debt service; SAE common-stock dividend distribution |
| **Module 3 — CORECM** | BAE operational reserves; basin-asset capex; classification-relay fees; federal-compliance legal expenses; BAE common-stock dividend distribution |
#### 13.4.2 Issuer Rebate Velocity Comparison
A worked example showing the issuer rebate's economic significance:
**Scenario:** A Module 1 OTC microcap issuer, $5M market cap, 5,000,000 ST22 tokens issued.
| Metric | Year 1 | Year 2 | Year 3 |
| ------------------------------- | ---------- | ---------- | ----------- |
| Annual secondary trading volume | $3,000,000 | $7,500,000 | $15,000,000 |
| Issuer 2% rebate | $60,000 | $150,000 | $300,000 |
For comparison, an equivalent OTC issuer pre-tokenization would receive zero secondary-market participation. Brokerage commissions on OTC trades flow exclusively to broker-dealers; market-making spreads flow to MMs; nothing returns to the issuer. The 2% rebate is **structurally novel** — only protocol-owned exchange architecture (not third-party ATSs, not traditional OTC) can route a continuous secondary-trading revenue stream back to the issuer.
### 13.5 Staking Architecture — Groovy Security Token
The Groovy Security Token (STO) holders earn passive rewards through participation in protocol operations via the staking program. The staking architecture is designed around a 2.6-day epoch cycle (432,000 Solana slots at 400 ms/slot) producing approximately 140 compounding events annually — delivering meaningful yield advantage over traditional quarterly dividend structures.
#### 13.5.1 Staking Tier Structure
| Tier | Stake Range | APY Range | Lockup |
| -------- | -------------------------- | ----------- | -------- |
| Bronze | 1,000–9,999 STO tokens | 8.0%–12.0% | 30 days |
| Silver | 10,000–99,999 STO tokens | 12.0%–24.0% | 60 days |
| Gold | 100,000–999,999 STO tokens | 24.0%–40.0% | 90 days |
| Platinum | 1,000,000+ STO tokens | 40.0%–60.0% | 180 days |
APY is configurable by Groovy Company governance within protocol-enforced bounds. The 8% floor and 60% ceiling are hard-coded in the staking smart contract — no governance vote can set APY outside this range. This is enforced by:
```rust
require!(
apy_basis_points >= 800 && apy_basis_points <= 6000,
StakingError::ApyOutOfBounds
);
```
#### 13.5.2 Compounding Advantage — Effective APY
The 2.6-day epoch produces \~140 compounding events per year. The effective APY exceeds the nominal APY due to compounding:
```
APY_effective = (1 + APY_nominal / n)^n − 1 where n ≈ 140
```
| Nominal APY | Effective APY (n=140) | Advantage |
| ----------- | --------------------- | --------- |
| 8.0% | 8.33% | +0.33% |
| 24.0% | 27.13% | +3.13% |
| 40.0% | 49.13% | +9.13% |
| 60.0% | 82.06% | +22.06% |
Higher nominal APYs produce disproportionately higher effective APYs due to compounding mathematics. The 60% nominal Platinum tier delivers an effective \~82% — a substantial yield premium versus traditional fixed-income or quarterly-dividend instruments.
#### 13.5.3 Epoch Reward Calculation
```rust
// Epoch reward calculation (Rust/Anchor)
// APY range: 800–6000 bps (8%–60%) — enforced in smart contract
// Epoch duration: 432,000 slots (~2.6 days at 400 ms/slot)
// Slots per year: 78,840,000 (per Section 5.10 network constants)
pub fn calculate_epoch_reward(
staked_amount: u64,
apy_basis_points: u16, // 800 = 8%; 6000 = 60%
epoch_duration_slots: u64, // Always 432,000
slots_per_year: u64, // 78,840,000
) -> Result {
require!(
apy_basis_points >= 800 && apy_basis_points <= 6000,
StakingError::ApyOutOfBounds
);
require!(
epoch_duration_slots == 432_000,
StakingError::InvalidEpochDuration
);
// reward = staked * (apy_bps / 10_000) * (epoch_slots / slots_per_year)
// Rearranged for u128 overflow safety:
// reward = staked * apy_bps * epoch_slots / (slots_per_year * 10_000)
let reward = (staked_amount as u128)
.checked_mul(apy_basis_points as u128)
.ok_or(StakingError::Overflow)?
.checked_mul(epoch_duration_slots as u128)
.ok_or(StakingError::Overflow)?
.checked_div((slots_per_year as u128).checked_mul(10_000).unwrap())
.ok_or(StakingError::Overflow)?;
u64::try_from(reward).map_err(|_| error!(StakingError::RewardTooLarge))
}
```
The staking program executes `calculate_epoch_reward` for every stake position at every epoch boundary. Rewards accrue to the staker's reward pool PDA and can be claimed any time after accrual.
#### 13.5.4 Staking Reward Pool — Funding Source
The staking program's reward pool is funded continuously by the **1.5% staking allocation from every ST22 transaction across all three modules**. This creates a direct economic linkage between platform trading volume and staking yields: as ST22 secondary market activity grows, staking rewards grow proportionally.
```
StakingRewardPool inflow per epoch = Σ (1.5% of all ST22 trade volume in epoch)
across M1 + M2 + M3 mints
```
Stakers participating during high-volume epochs receive proportionally larger rewards.
#### 13.5.5 2% Staking Reinvestment — Global Pool Accumulation
A separate mechanism: 2% of staking rewards are automatically reinvested into the Global Unified Liquidity Pool at every epoch. This produces a recursive deepening: trading volume → staking rewards → 2% reinvestment → deeper Global Pool → tighter spreads → more trading volume.
### 13.6 GROO Utility Token Economics
GROO Utility Token economics are intentionally minimal — bonding curve only, no centralized issuance schedule, no founder allocation. The economic model is documented in §13.2.2 and supported by the bonding curve program logic.
#### 13.6.1 GROO Bonding Curve — Mathematical Properties
| Property | Value |
| -------------------------------- | ---------------------------------------------------------------------- |
| `base_price` | 0.000001 SOL (1 micro-SOL) |
| `slope` | 1e-15 SOL per token |
| Initial purchase cost (token #1) | 0.000001 SOL |
| 1,000,000th token cost | 0.000001 + 1,000,000 × 1e-15 = 0.000001000001 SOL (\~negligible slope) |
| 1,000,000,000th token cost | 0.000001 + 1e9 × 1e-15 = 0.000001001 SOL |
| 1,000,000,000,000th token cost | 0.000001 + 1e12 × 1e-15 = 0.000002 SOL (2× starting) |
The slope is intentionally shallow: GROO's distribution is designed to be wide and economically accessible across millions of holders. The slope steepens only at extreme supply levels.
#### 13.6.2 GROO Use Cases
| Use Case | Mechanism |
| ------------------------------------------ | -------------------------------------------------------------------------------- |
| Transaction fee discount on CEDEX | Stakers receive reduced 5% → 4.5% fee on personal trades (Bronze tier and above) |
| Staking yield | Bronze 8% to Platinum 60% nominal APY (§13.5.1) |
| Governance voting (post-graduation, 2028+) | Per-token vote weight on protocol governance proposals (Section 17) |
| Gas-fee abstraction (future) | Optional GROO-denominated transaction fee bundle for institutional users |
GROO is **not** a security under Release No. 33-11412 because it has no backing instrument, no centralized issuance authority controlling distribution, and no expectation of profits derived from the efforts of others (the bonding curve is deterministic and admin-free). The post-graduation governance rights activate the Category 3 (Digital Tool) classification posture.
### 13.7 Module-Aware Economic Considerations
While the 5% fee structure is uniform across all three modules, certain economic considerations are module-specific.
#### 13.7.1 Module 2 — NAV-Bound Pricing Premium
Module 2 ST22 tokens trade at up to **22% premium over NAV** (the default `nav_deviation_max_bps = 2200` enforced by Control CB-21 NAV-deviation variant — see Section 9). The 22% premium decomposes into:
| Component | Allocation | Rationale |
| ------------------------- | ---------- | ---------------------------------------------------------------------------------------------------------- |
| Liquidity premium | \~10% | Fractional ownership of an indivisible underlying property; instant trade-out vs months of property sale |
| Fractionalization premium | \~5% | Investors otherwise unable to access the property at full ownership cost |
| Custody overhead | \~3% | Empire §17A custody costs of SAE equity; per-slot attestation infrastructure |
| Protocol overhead | \~4% | 5% transaction fee continues to apply on each trade; the 22% NAV premium is structural, not a one-time fee |
This is an architectural distinction from Module 1 (where ST22 tokens trade at market-derived prices reflecting investor valuation of the underlying issuer) and Module 3 (where ST22 tokens trade reflecting basin-specific value drivers and federal-action risk). Module 2 is uniquely NAV-anchored.
#### 13.7.2 Module 3 — Federal-Action Liquidity Discount
Module 3 ST22 tokens may exhibit **federal-action liquidity discount** during periods when Control REG-42 federal-action variant has triggered an automatic 60-minute SLA freeze (see Section 10). When trading resumes, market participants typically reprice the token to reflect:
| Risk Factor | Pricing Consequence |
| -------------------------------------------------- | ---------------------------------------------------------------- |
| Federal action duration uncertainty | Discount until classification resolves |
| Section 232 / DPA Title III tariff effect on basin | Reduces or increases token value depending on event direction |
| IRA tax-credit eligibility changes | Reprices ongoing tax benefits |
| EO 14017 supply-chain priority designation | May increase value (positive designation) or decrease (negative) |
The pricing impact is asymmetric — positive federal designations (e.g., DPA Title III investment, IRA tax-credit qualification) typically produce upward repricing; negative federal actions (e.g., Section 232 tariff against basin output) produce downward repricing.
### 13.8 Five-Year Platform Revenue Model
The platform's revenue is derived entirely from the 1.06% protocol component of the 5% transaction fee. There are no subscription fees, listing fees, or access fees. Revenue scales linearly with total ST22 transaction volume across all issuances and all modules.
#### 13.8.1 Revenue Component
```
Platform revenue per period = 1.06% × (total ST22 transaction volume in period)
= 1.06% × (Σ M1 trades + Σ M2 trades + Σ M3 trades)
```
#### 13.8.2 Five-Year Volume and Revenue Projections
The following projections model platform revenue at the 1.06% protocol component of the 5% fee. Assumptions reflect accelerating issuer adoption driven by the Layer 9 IDOS module's outreach pipeline and progressive module activation (M1 in Q3 2026 launch, M2 active by Q4 2026, M3 active by Q1 2027).
| Year | Active M1 Issuers | Active M2 Issuers | Active M3 Issuers | Total Annual Volume | Platform Revenue (1.06%) | Global Pool Accumulation (0.44%) |
| ------------------------ | ----------------- | ----------------- | ----------------- | ------------------- | ------------------------ | -------------------------------- |
| 2026 (H2 only) | 25 | 5 | 0 | $50,000,000 | $530,000 | $220,000 |
| 2027 | 150 | 30 | 5 | $400,000,000 | $4,240,000 | $1,760,000 |
| 2028 | 500 | 100 | 25 | $1,500,000,000 | $15,900,000 | $6,600,000 |
| 2029 | 1,250 | 250 | 75 | $4,500,000,000 | $47,700,000 | $19,800,000 |
| 2030 | 2,500 | 500 | 200 | $11,000,000,000 | $116,600,000 | $48,400,000 |
| **Cumulative 2026–2030** | | | | **$17,450,000,000** | **$184,970,000** | **$76,780,000** |
These projections assume:
* Average per-issuer annual secondary trading volume scales from $1M (year 1 issuer) to $4M (mature issuer)
* Module activation cadence: M1 immediate; M2 from Q4 2026; M3 from Q1 2027
* Issuer adoption accelerates from year 2 driven by IDOS-driven outreach and SEC examination clarity
* No catastrophic regulatory event halting the platform; continued Category 1 Model B framework
#### 13.8.3 Cumulative Global Pool Depth — Architectural Significance
By end-2030, the cumulative Global Pool accumulation reaches **$76.78M from the 0.44% lock alone** — independent of the initial $20M Groovy Security Token (STO) seed. Total Global Pool depth at end-2030: \~$96.78M+ in permanent locked liquidity, all withdrawal-impossible per Certora invariant E.3.
This depth is what enables a Module 1 OTC microcap issuer with $500K market cap to access institutional-grade liquidity that would be uneconomical via market-maker subsidies on traditional OTC venues. The shared-pool architecture turns aggregate platform volume into per-issuer liquidity — a structural advantage no per-product-isolated tokenization platform can match.
### 13.9 Tokenomics Summary Table
| Mechanism | Value | Module Coverage | Enforced By |
| ----------------------------------- | ------------------------------------ | -------------------- | --------------------------------------------- |
| 5% transaction fee | Total fee on all ST22 trades | M1, M2, M3 | `transfer_hook` GA-42 |
| 2% issuer rebate | Routed to issuer treasury | M1, M2, M3 | `transfer_hook` GA-42 distribution |
| 1.5% staking rewards | Routed to STO staker pool | M1, M2, M3 | `transfer_hook` GA-42 distribution |
| 1.06% protocol revenue | Routed to platform treasury | M1, M2, M3 | `transfer_hook` GA-42 distribution |
| 0.44% permanent Global Pool lock | LP burned at receipt | M1, M2, M3 | `transfer_hook` GA-42 + `liquidity_pool` burn |
| 22% NAV premium tolerance (default) | Module-specific economic property | M2 only | Control CB-21 NAV-deviation variant |
| Federal-action freeze (60-min SLA) | Module-specific operational property | M3 only | Control REG-42 federal-action variant |
| 2.6-day staking epoch | 140 compounding events/year | All staking | Staking program `calculate_epoch_reward` |
| 8%–60% APY bounds | Hard-coded; immutable | All staking tiers | `StakingError::ApyOutOfBounds` |
| GROO bonding curve | `price = 1e-6 + 1e-15 × supply` SOL | GROO ecosystem token | `groo_bonding_curve` program |
| $20M Groovy Security Token raise | Use-of-proceeds: Global Pool seed | Platform-wide | One-time Reg D issuance |
### 13.10 Architectural Decision Records — Tokenomics
| ADR | Title | Date | Decision Summary |
| ------- | -------------------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ADR-003 | 5% unified fee structure | March 2025 | Single fee across primary + secondary, all modules. Simpler than tier-based pricing; eliminates governance ambiguity. |
| ADR-004 | 0.44% permanent Global Pool lock | June 2025 | Mathematical permanence via LP burn; differentiated from market-maker withdrawability; Certora E.3. |
| ADR-008 | GROO bonding curve parameters | August 2025 | `base_price = 1e-6 SOL`; `slope = 1e-15 SOL/token`. Wide accessibility; admin-free distribution. |
| ADR-011 | 2% staking reinvestment | January 2026 | Recursive Global Pool deepening; aligns staker incentives with platform-wide liquidity. |
| ADR-012 | Module-aware economic posture | March 2026 | Same 5% fee across modules; module-specific risk surfaces (NAV deviation M2; federal action M3) handled by Transfer Hook variants, not by fee differentiation. |
***
### 13.11 Cross-References
* **Section 5** — Layer 1 Solana Foundation (`transfer_hook` immutability; the architectural foundation of fee permanence)
* **Section 7** — Layer 2 Transfer Hook (the 42 controls + module-aware extensions; GA-42 audit and fee distribution control)
* **Section 8** — Module 1 Equities (M1 issuer economics; Common Class B backing)
* **Section 9** — Module 2 Real Estate (NAV-bound 22% premium economic structure)
* **Section 10** — Module 3 CORECM (federal-action economic considerations)
* **Section 14** — Global Unified Liquidity Pool (the destination of the 0.44% lock; LP burn mechanics)
* **Section 15** — Security Model (Certora E.3 pool non-extractability; E.4 fee-allocation immutability)
* **Section 17** — Governance (the bounded set of governance-modifiable parameters; APY range enforcement)
* **Tokenomics Deep Dive** — extended modeling, sensitivity analysis, alternative scenarios
* **Smart Contract Reference** — full `staking` program interface; epoch reward Rust source
***
*RWA Tokens Platform Whitepaper · Section 13 — Tokenomics · V10.0 · Groovy Company, Inc.*
# ERC-3643 vs ST22 — Seven-Pillar Category 1 Model B Comparison
## Section 14: ERC-3643 vs ST22 — Seven-Pillar Category 1 Model B Comparison
**RWA Tokens Platform Whitepaper · Version 10.0** **Groovy Company, Inc. · May 2026** **Document Reference:** RWA-COMPARE-001 v2.0
This section provides the formal architectural comparison between ERC-3643 (T-REX standard, Ethereum) and ST22 (SPL Token-2022 Transfer Hook, Solana) against the seven pillars of SEC Category 1 Model B per SEC–CFTC Release No. 33-11412 and the January 28, 2026 Joint Staff Statement on Tokenized Securities.
***
### 14.1 Reference Frameworks
The comparison is anchored to the SEC's binding federal taxonomy:
| Framework | Authority |
| --------------------------------------- | ------------------------------------------------------------------------ |
| **Five-Category Taxonomy** | SEC–CFTC Release No. 33-11412 (March 17, 2026) |
| **Seven Pillars of Category 1 Model B** | SEC Joint Staff Statement on Tokenized Securities (January 28, 2026) |
| **Runtime-Enforcement Weight** | SEC Staff Statement on Covered User Interface Providers (April 13, 2026) |
***
### 14.2 Standards Under Comparison
#### 14.2.1 ERC-3643 (T-REX Standard)
| Attribute | Value |
| ------------------------- | ------------------------------------------------------- |
| Specification | EIP-3643 — December 2023, Final |
| Reference implementation | T-REX (Tokeny) |
| Underlying chain | Ethereum L1 + EVM L2s |
| Underlying token standard | ERC-20 (with overlays) |
| Compliance mechanism | Application-layer ComplianceContract + IdentityRegistry |
| Total tokenized | $32B+ across 8+ years (cumulative) |
| Adopters | Tokeny, Securitize (partial), Polymath legacy |
#### 14.2.2 ST22 (Platform Standard)
| Attribute | Value |
| ------------------------- | ------------------------------------------------------------------- |
| Specification | RWA Tokens Whitepaper V10 Section 3 + SPL Token-2022 |
| Reference implementation | Platform `transfer_hook` Solana program |
| Underlying chain | Solana Mainnet-Beta |
| Underlying token standard | SPL Token-2022 (with `transfer-hook-interface` v0.6+ extension) |
| Compliance mechanism | Runtime-enforced 42-control Transfer Hook + module-aware extensions |
| Total tokenized | Platform launch Q3 2026 |
| Adopters | RWA Tokens platform across all three modules |
***
### 14.3 Pillar-by-Pillar Comparison
#### 14.3.1 Pillar 1 — Direct Issuer Authorization
**Requirement:** Board resolution authorizing the mint; tokenization is the issuer's act, not a third party's.
**ERC-3643:** Authorization is off-chain only. The issuer signs paperwork; the smart contracts have no on-chain attestation of issuer authorization. There is no contract-level mechanism that refuses to mint if the issuer's board has not authorized — that check is process-layer only.
**ST22:** Empire Stock Transfer's onboarding gate refuses to initialize the `SecurityConfig` PDA without a filed Certificate of Designation (M1) / Articles of SAE (M2) / Articles of BAE (M3). The issuer's board resolution is verified by Empire as part of KYB before the mint is created. The `mint_authority` is set to the issuer's multi-sig at creation, structurally tying mint authority to the issuer.
**Verdict:** ERC-3643 ⚠️ off-chain only · ST22 ✅ on-chain via Empire onboarding gate
#### 14.3.2 Pillar 2 — Official Shareholder Register on DLT
**Requirement:** The DLT (token ledger) is legally the shareholder register, not a mirror of an external authoritative source.
**ERC-3643:** The ERC-20 `balanceOf` function returns token holdings. These balances are NOT the legal shareholder register. The legal register is maintained off-chain by the issuer or a transfer agent; the on-chain balances are reconciled to the off-chain register periodically. Drift can occur, and resolution favors the off-chain register.
**ST22:** The Empire MSF is the legally controlling shareholder register under W\.S. 34-29-101. The SPL Token-2022 ledger is the **transfer notification layer**. The two are reconciled every Solana slot (\~400 ms) via the Custody Oracle Ed25519 attestation. The on-chain ledger is the legally effective transfer-notification under Wyoming digital-asset law; the MSF is the ultimate legal register, and the architecture treats them as one continuously-reconciled system rather than two systems with periodic sync.
**Verdict:** ERC-3643 ❌ token ledger ≠ register · ST22 ✅ MSF + on-chain ledger reconciled per slot
#### 14.3.3 Pillar 3 — SEC §17A-Registered Qualified Custody
**Requirement:** A SEC §17A-registered qualified custodian holds the underlying.
**ERC-3643:** Custody is at issuer discretion. Some ERC-3643 deployments use a §17A custodian; many use a crypto-native custodian (BitGo, Fireblocks, Anchorage); some use the issuer itself. There is no architectural requirement.
**ST22:** Empire Stock Transfer is the **architectural requirement**. There is no path to issuance that bypasses Empire. Empire holds 1:1 backing of Common Class B (M1) / SAE equity (M2) / BAE equity (M3). Empire is also the sole investor onboarding authority. The architecture is structurally bound to a §17A-registered transfer agent.
**Verdict:** ERC-3643 ⚠️ optional · ST22 ✅ architecturally required
#### 14.3.4 Pillar 4 — True Equity Backing (1:1)
**Requirement:** Each token is backed by real equity in the underlying.
**ERC-3643:** Backing is verified off-chain via auditor attestation, periodic. Auditor reviews custody balances vs token supply and produces an attestation report. There is no on-chain mechanism that verifies backing on every transfer.
**ST22:** The Custody Oracle Ed25519 attestation per Solana slot is verified by Control CV-01 on every transfer. Every transfer revertsif `total_supply + transfer_amount > custodied_balance`. Backing verification is **continuous and cryptographic**, not periodic and audit-mediated.
**Verdict:** ERC-3643 ⚠️ off-chain attestation periodic · ST22 ✅ per-slot Ed25519 verified on every transfer
#### 14.3.5 Pillar 5 — Clear Ownership Chain / Asset Identifier
**Requirement:** On-chain mapping from token to underlying equity.
**ERC-3643:** ONCHAINID maps wallets to identity but does NOT map tokens to specific equity instruments. CUSIP / DTC chain lookups are off-chain. The link from on-chain token to off-chain equity is process-mediated.
**ST22:** `SecurityConfig.asset_identifier` stores CUSIP (M1) / property ID (M2) / basin ID (M3) on-chain. Control CV-05 verifies on every transfer that the bound asset identifier matches the Custody Oracle's reported asset-identifier hash. The on-chain mapping is enforced runtime.
**Verdict:** ERC-3643 ⚠️ off-chain mapping · ST22 ✅ on-chain via Control CV-05
#### 14.3.6 Pillar 6 — Investor Protection (Compliance at Every Transfer)
**Requirement:** Compliance checks execute on every transfer; no bypass exists.
**ERC-3643 — The Bypass Problem:**
The ERC-3643 standard adds compliance overlay via:
```solidity
// Standard ERC-3643 transfer override pattern
function transfer(address to, uint256 amount) public override returns (bool) {
require(compliance.canTransfer(msg.sender, to, amount), "Compliance blocked");
require(identityRegistry.isVerified(to), "Recipient not verified");
return super.transfer(to, amount); // Calls standard ERC-20 transfer
}
```
This is application-layer code in a contract that holds the token logic. The bypass surface includes:
* **Direct ERC-20 inheritance bypass** — if the contract inherits from a base ERC-20 without the override (developer error), `transfer()` skips compliance entirely
* **Proxy upgrade bypass** — proxy upgrades can introduce a new contract version that omits the override
* **Direct token-transfer instruction bypass** — at the EVM bytecode level, transfer is just a state mutation; compliance is just a require statement that can be bypassed by a contract that calls into the storage layer differently
* **Cross-contract call bypass** — wrapper contracts can interpose and forward without triggering the compliance check
* **Hacken and Kaspersky audit findings** — public audits of T-REX flag this surface as a governance/code-quality risk
**ST22 — Runtime Enforcement:**
ST22 compliance is at the SPL Token-2022 program level, which is part of the Solana runtime:
```rust
// Token-2022 program logic (Solana runtime)
// On every transfer instruction targeting a hook-extended mint:
fn process_transfer(/* ... */) -> ProgramResult {
let mint_extensions = read_mint_extensions(mint);
if let Some(hook_program_id) = mint_extensions.transfer_hook_program_id() {
// The runtime REFUSES to process the transfer without invoking the hook
invoke_signed(
&hook_program_id,
&transfer_data,
&[/* ... */]
)?;
}
// Settlement only proceeds if hook returned success
update_balances(/* ... */);
Ok(())
}
```
The runtime enforces hook invocation. There is **no transfer instruction that skips it**. This is closer to an OS system call than to a smart-contract function. The bypass surface includes:
* ❌ Direct ERC-20 bypass — N/A (different chain, different runtime; no analog)
* ❌ Proxy upgrade bypass — N/A (Solana programs don't use proxy upgrade pattern; upgrade authority can replace the program but cannot remove the hook-extension binding from the mint)
* ❌ Direct instruction bypass — Token-2022 refuses transfer without hook invocation
* ❌ Cross-program bypass — wrapper programs cannot interpose; the wrapper must still invoke Token-2022, which still invokes the hook
**Verdict:** ERC-3643 ⚠️ application-layer (bypassable) · ST22 ✅ runtime-enforced
#### 14.3.7 Pillar 7 — Token Standard Compliance (Immutable, No Admin Override)
**Requirement:** Compliance logic is immutable post-deployment; no admin function can move tokens or alter compliance.
**ERC-3643 — Admin Functions:**
ERC-3643 (T-REX) includes the following admin functions:
| Function | Effect |
| ---------------------------------------- | -------------------------------------------------- |
| `forceTransfer(from, to, amount)` | Admin can move any holder's tokens without consent |
| `freezePartialTokens(account, amount)` | Admin can freeze specific token amounts |
| `unfreezePartialTokens(account, amount)` | Admin can unfreeze |
| `recoveryAddress()` | Admin can redirect tokens to a recovery address |
| `updateIdentityRegistry()` | Admin can change who is verified |
| `setCompliance()` | Admin can replace the compliance contract |
| Proxy `upgradeTo(newImpl)` | Admin can upgrade the entire token contract |
These admin functions are documented in the ERC-3643 standard and in T-REX implementation. They permit the admin to move tokens without holder consent, change compliance logic post-deployment, and override the standard's stated compliance posture.
**ST22 — Immutability:**
ST22 includes none of the above:
| Function | ST22 |
| ---------------------------- | --------------------------------------------------------------------------------------------------- |
| Force-transfer holder tokens | Does not exist |
| Freeze partial balance | Halt-only via Control 42 (cannot move tokens) |
| Recovery address | Does not exist |
| Modify identity verification | Empire verification is external — not modifiable by the platform |
| Replace compliance program | Transfer Hook program ID bound to mint at creation; cannot be repointed |
| Program upgrade authority | Bound by Solana program upgrade authority + 48-hour timelock + Certora E.4 specification compliance |
The investor's wallet signature is the **only** path to debit a token account. Control 42 (Regulatory Freeze) can halt all transfers on a mint pending Legal Counsel signoff and 3-of-5 multi-sig, but it cannot move tokens. Module 3's REG-42 federal-action variant automates Control 42 on detection of qualifying federal action with halt-only semantics.
**Certora invariants E.4 and E.6** formally prove:
* E.4: 42 core controls and module-aware extensions cannot be removed, weakened, or repointed post-deployment
* E.6: Transfer Hook program ID for a given mint cannot be changed post-creation
**Verdict:** ERC-3643 ❌ proxy upgrades + admin functions · ST22 ✅ bound at creation
***
### 14.4 Comparison Scorecard
| # | Pillar | ERC-3643 | ST22 |
| - | ------------------------------------- | ---------------------------------- | ------------------------------------------------------------- |
| 1 | Direct Issuer Authorization | ⚠️ off-chain only | ✅ on-chain Empire onboarding gate |
| 2 | Official Shareholder Register on DLT | ❌ token ledger ≠ register | ✅ MSF + on-chain ledger reconciled per slot |
| 3 | SEC §17A-Registered Qualified Custody | ⚠️ optional | ✅ architecturally required (Empire) |
| 4 | True Equity Backing 1:1 | ⚠️ off-chain attestation periodic | ✅ per-slot Ed25519 (Control CV-01) |
| 5 | Clear Ownership Chain / Asset ID | ⚠️ off-chain mapping | ✅ on-chain via Control CV-05 (CUSIP / property ID / basin ID) |
| 6 | Investor Protection | ⚠️ application-layer (bypassable) | ✅ runtime-enforced (42 controls + module extensions) |
| 7 | Token Standard Immutability | ❌ proxy upgrades + admin functions | ✅ bound at creation (Certora E.4, E.6) |
**Native compliance score:**
* **ERC-3643: 3/7** (optimistic — Pillars 1, 3, 5 with disciplined off-chain process)
* **ST22: 7/7**
***
### 14.5 The Category 1 vs Category 2 Mapping
Under SEC–CFTC Release No. 33-11412 and the Joint Staff Statement of January 28, 2026:
* **Category 1 Model B** requires DLT to be the official register with runtime-level compliance enforcement
* **Category 2** is the application-layer overlay pattern where compliance can be bypassed
Application-layer overlays cannot satisfy "DLT in official shareholder records" because the SEC explicitly defined that pillar as runtime-level integration. **That is why ERC-3643 maps natively to Category 2 and ST22 maps natively to Category 1 Model B.**
***
### 14.6 Cross-Module Architectural Implications
V10 introduces module-aware extensions (CB-21 NAV variant for M2; REG-42 federal-action variant for M3). The seven-pillar comparison applies identically across all three modules — the module-aware extensions are additive runtime checks that further strengthen Pillar 6 (compliance at every transfer) for the specific risk vectors of Modules 2 and 3.
| Pillar | M1 Status | M2 Status | M3 Status |
| ----------------------- | --------------- | ----------------------------------- | ---------------------------------------- |
| 1. Issuer Authorization | ✅ | ✅ | ✅ |
| 2. DLT Register | ✅ | ✅ | ✅ |
| 3. §17A Custody | ✅ (Common B) | ✅ (SAE equity) | ✅ (BAE equity) |
| 4. 1:1 Backing | ✅ (CV-01) | ✅ (CV-01 + NAV oracle) | ✅ (CV-01) |
| 5. Asset ID | ✅ (CUSIP) | ✅ (property ID) | ✅ (basin ID) |
| 6. Investor Protection | ✅ (42 controls) | ✅ (42 controls + CB-21 NAV variant) | ✅ (42 controls + REG-42 federal variant) |
| 7. Immutability | ✅ | ✅ | ✅ |
ST22 satisfies all seven pillars natively across all three modules. ERC-3643 has no native cross-module composability — every additional asset class would require separate contract deployments and separate compliance overlay code, increasing the bypass surface and audit burden linearly with the number of asset classes addressed.
***
### 14.7 Other Tokenization Standards — Brief Comparison
| Standard | Native Score | Comments |
| ----------------------------------- | ------------ | ------------------------------------------------------------------------- |
| ERC-1400 (Polymath legacy) | 2/7 | Predecessor to ERC-3643; fewer compliance hooks |
| ERC-3643 (Tokeny T-REX) | 3/7 | Section 14.3 detailed |
| ERC-1404 (Restricted Token) | 1/7 | Whitelist-only; no comprehensive framework |
| ERC-2222 (Funds Distribution Token) | 1/7 | Distribution-focused; minimal compliance surface |
| BlackRock BUIDL (Securitize) | 4/7 | Tokenized treasury fund; §17A custody yes; some application-layer overlay |
| Ondo USDY | 3/7 | Treasury-tokenization; Bermuda exempted-fund structure |
| Franklin Templeton FOBXX | 5/7 | OnChain U.S. Government Money Fund; SEC-registered |
| Dinari dShares | 5/7 | NYSE/NASDAQ Category 2 tokenization; complementary to platform's Module 1 |
| **RWA Tokens ST22** | **7/7** | This whitepaper |
***
### 14.8 Practical Implications
The seven-pillar gap between ERC-3643 (3/7) and ST22 (7/7) translates into practical differences:
| Operational Aspect | ERC-3643 Reality | ST22 Reality |
| ----------------------------------- | --------------------------------------- | ----------------------------------------------- |
| Compliance enforcement | Process discipline + audits | Cryptographic proof on every transfer |
| Backing verification | Periodic auditor attestation | Per-slot Ed25519 |
| Bypass risk | Real (multiple paths documented) | Zero (runtime-enforced) |
| Admin override risk | Real (forceTransfer, recovery, upgrade) | Zero (no admin functions in compliance program) |
| Multi-asset-class composability | Per-product separate deployments | Single architecture, three modules |
| Regulatory characterization | Category 2 by structure | Category 1 Model B by structure |
| Per-issuer market maker requirement | Often required | Not required (Global Pool) |
| Pool rugpull risk | Real (LP can withdraw) | Zero (Certora E.3, LP burned) |
***
*RWA Tokens Whitepaper V10 — Section 14 — Confidential — Groovy Company, Inc.*
# Security Model and Formal Verification
## SECTION 15 — Security Model and Formal Verification
**RWA Tokens Platform Whitepaper · V10.0 · May 2026** **Issued by:** Groovy Company, Inc. (Wyoming corporation; OTC: GROO; SEC EDGAR CIK 1499275) **Section classification:** Technical Specification — Security Architecture **Authority:** SEC–CFTC Release No. 33-11412 § Pillar 7 (Token Standard Compliance, Immutable, No Admin Override); SEC Joint Staff Statement on Tokenized Securities (January 28, 2026)
***
### 15.1 Scope
This section documents the platform's complete security architecture: the threat model categorizing every identified attack surface, the formal verification posture under the Certora Prover, the six invariants (E.1 through E.6) covering all critical safety properties, the audit-trail architecture supporting regulatory examination, the empirical beta validation results that derived the Alesia Doctrine architectural framework, and the operational incident-response procedures.
The security model is not a layer — it is a property of the entire stack. Layer 1 (Solana) supplies cryptographic primitives. Layer 2 (Transfer Hook) supplies runtime-enforced compliance. Layers 3–8 supply specific operational guarantees. Layer 9 supplies behavioral surveillance. Section 15 documents how these stack into a coherent security posture defensible under SEC examination, audit firm review, and adversarial probing.
### 15.2 Threat Model
The threat model enumerates every category of attack the platform considers in its design. For each threat, the architecture supplies a structural mitigation; mitigations are layered (defense-in-depth) such that no single failure compromises the entire system.
#### 15.2.1 Threat Surface Catalog
| # | Threat Category | Threat Description | Architectural Mitigation | Module Scope |
| --- | ------------------------------------------------------ | ----------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- |
| T1 | Direct EVM transfer bypass | Adversary calls underlying ERC-20 `transfer()` to skip ERC-3643 overlay | **N/A — not applicable.** SPL Token-2022 enforces hook invocation at runtime; no bypass instruction exists | M1, M2, M3 |
| T2 | Admin force-transfer | Platform admin moves user tokens without consent | **Eliminated.** No `forceTransfer` primitive in compliance program; investor wallet signature is sole debit authorization | M1, M2, M3 |
| T3 | `transfer_hook` upgrade weakening controls | Adversary or insider upgrades hook to remove a control | **Eliminated by immutability.** `transfer_hook` deployed with no upgrade authority (ADR-006); Certora E.4 proof | M1, M2, M3 |
| T4 | Hook program ID repointing | Mint's registered hook program ID changed to point to a permissive replacement | **Eliminated.** Token-2022 binds hook program ID at mint creation; cannot be repointed; Certora E.6 proof | M1, M2, M3 |
| T5 | Identity registry manipulation | Adversary or insider modifies wallet-verification status to pass non-Empire-verified wallets | **Eliminated.** Empire verification is external — Empire's MSF is the verification source; not modifiable by the platform | M1, M2, M3 |
| T6 | Pool drain / rugpull | Adversary or insider withdraws Global Pool reserves | **Eliminated.** LP tokens burned at inception; no withdrawal function; Certora E.3 proof | M1, M2, M3 |
| T7 | Sniper-bot extraction (October 2025 GROO failure mode) | Coordinated bots front-run launch trades on permissionless DEX | **Mitigated via Alesia Doctrine.** External DEXs cannot host ST22 mints (T8); CEDEX-only routing closes the extraction surface | All trading |
| T8 | External DEX bypass | ST22 mint listed on Raydium/Orca/Jupiter; trade routes through DEX without hook execution | **Architecturally impossible.** External DEXs do not invoke Token-2022 hook program correctly for hook-extended mints; pool creation requires SecurityConfig consent which only CEDEX has | All trading |
| T9 | RPC bottleneck under launch volume | Shared-tier RPC capacity (50 req/sec) saturates; legitimate trades fail | **Mitigated.** Helius dedicated cluster (500+ req/sec) + Triton failover + public fallback | All trading |
| T10 | Custody divergence (MSF vs on-chain) | Empire MSF and on-chain ledger drift after corporate action | **Mitigated.** Per-slot Ed25519 attestation reconciles every \~400 ms; Control CV-04 halts on divergence; Control 42 manual freeze available | M1, M2, M3 |
| T11 | Stale NAV reference (M2) | Module 2 mint trades indefinitely against an outdated NAV attestation | **Mitigated.** Control CB-21 NAV-deviation variant rejects transfers if NAV attestation older than configured reappraisal cadence (default 90 days) | M2 only |
| T12 | Federal action affecting basin (M3) | Section 232, DPA Title III, or other federal action affects a basin asset; trading should pause | **Mitigated.** Control REG-42 federal-action variant with 60-minute SLA; halt-only; auto-resumes when action lifts | M3 only |
| T13 | Compromised oracle relay key | Adversary obtains relay private key and publishes malicious attestations | **Mitigated.** Per-mint oracle PDAs bind to specific relay public key at initialization; attestations from any other key rejected; per-slot Ed25519 verification on Custody Oracle catches divergence | M1, M2, M3 |
| T14 | Solana Foundation Token-2022 weakening | Solana Foundation upgrades Token-2022 program in a way that weakens hook enforcement | **Residual L1 trust.** Mitigated by version-pinning, monitoring, Control 42 contingency, and disclosure (Risk Disclosure document; ADR-007) | All trading |
| T15 | MEV extraction on CEDEX trades | Sandwich attacks, frontrunning by validators or searchers | **Mitigated via Jito.** All CEDEX trades route through Jito Block Engine with bundle inclusion; mempool isolated; ADR-010 | All CEDEX trading |
| T16 | Holding-period circumvention | Adversary attempts to debit tokens before HP-24 timer expires | **Eliminated.** HoldingPeriodAccount PDA timer enforced by HP-24; Certora E.5 proof — timer cannot be shortened by any execution path | M1, M2, M3 |
| T17 | Wallet cap bypass | Adversary fragments holdings across multiple wallets to exceed default 9.99% concentration cap | **Mitigated.** Wallet caps enforced per beneficiary on transfer; sybil resistance enhanced by Empire KYC (sybil wallets share KYC identity) | M1, M2, M3 |
| T18 | OFAC sanctions bypass | Trade involves a sanctioned address | **Eliminated.** OFAC Oracle Bloom filter checked on every transfer via Control SX-34; daily SDN feed updates | M1, M2, M3 |
| T19 | Compute exhaustion DoS | Adversary submits transfer that consumes all compute, blocking legitimate trades | **Mitigated.** Solana compute budget caps; transfer cost model deters DoS economics; Jito priority queue isolates legitimate from adversarial transactions | M1, M2, M3 |
| T20 | Audit-trail tampering | Adversary attempts to remove or alter on-chain audit events | **Eliminated.** Solana ledger is append-only; finalized blocks are economically immutable after \~13 seconds; audit events emitted via Control GA-42 | M1, M2, M3 |
#### 15.2.2 Threat-to-Mitigation Matrix Summary
| Mitigation Type | Count | Examples |
| ------------------------------------------------------------- | ----- | ------------------------------------------ |
| **Architecturally impossible** (cannot occur by construction) | 5 | T1, T3, T4, T6, T16 |
| **Mathematically eliminated** (Certora-proved) | 6 | T2, T6, T16 + indirect via E.1, E.2, E.4 |
| **Operationally mitigated** (procedural + technological) | 9 | T9, T10, T11, T12, T13, T15, T17, T18, T19 |
| **Residual / disclosed** | 1 | T14 (Solana Foundation Token-2022 trust) |
The architectural-impossible category is the most significant: five threats simply cannot occur because the architecture lacks the primitive that would enable them. This is what Pillar 7 of Category 1 Model B looks like in practice — security properties as protocol properties, not as developer discipline.
### 15.3 Formal Verification — Certora Prover Suite
The platform's compliance-critical programs are verified under the **Certora Prover**, a commercial formal-verification tool that accepts Rust IR (the SBF intermediate representation produced by `cargo build-bpf`) and machine-checked specifications written in the Certora Verification Language (CVL). The prover discharges proof obligations against the SBF code with machine-checked rigor — no human reviewer can certify the proof; only the prover can.
#### 15.3.1 Verified Programs
| Program | Verified Properties | Specification File | Lines of CVL |
| ------------------- | ---------------------------------------------------- | ------------------------ | ------------ |
| `transfer_hook` | E.2, E.4, E.5, E.6 | `transfer_hook.spec` | \~850 |
| `liquidity_pool` | E.3 | `liquidity_pool.spec` | \~320 |
| `oracle_aggregator` | E.1 (custody invariant) | `oracle_aggregator.spec` | \~420 |
| `amm` | E.3 (partial — pool reserve protection on swap path) | `amm.spec` | \~550 |
| `governance` | (governance-scope safety properties only) | `governance.spec` | \~280 |
The combined verification corpus is \~2,420 lines of CVL covering \~12,000 lines of Rust SBF target. The prover runs daily on CI; any change to a verified program requires re-verification before merge.
#### 15.3.2 The Six Critical Invariants
**E.1 — 1:1 Backing Integrity**
**Informal statement:** For every issued ST22 token across all three modules, there exists a 1:1 custodied equity share at Empire Stock Transfer.
**CVL-equivalent formal statement:**
```
invariant backingIntegrity(mint)
on_chain_supply(mint) == custodied_balance(mint, custody_oracle_pda(mint))
&& custody_oracle_age(mint) <= CUSTODY_ATTESTATION_MAX_AGE_SLOTS
```
**Coverage:** All modules. The invariant ties the Token-2022 mint supply to the Custody Oracle PDA's `custodied_balance` field, with a freshness constraint preventing the oracle from being arbitrarily stale. Control CV-04 enforces the constraint at runtime; the Certora proof verifies that no execution path violates it.
**Why it matters:** Pillar 4 (True 1:1 Equity Backing) of Category 1 Model B. The invariant is the architectural mechanism by which the on-chain ledger cannot diverge from the §17A custody record — at any slot, the on-chain supply equals what Empire holds, modulo the \~400 ms attestation cycle.
**E.2 — Transfer Hook Inescapability**
**Informal statement:** No execution path exists by which a Transfer Hook control can be bypassed for a hook-extended mint.
**CVL-equivalent formal statement:**
```
rule hookInvocationMandatory(mint, from, to, amount)
requires hookExtension(mint).program_id == TRANSFER_HOOK_PROGRAM_ID
requires execute_transfer(mint, from, to, amount)
ensures transfer_hook_invoked(mint, from, to, amount)
```
**Coverage:** All modules. This is the most critical invariant — it is the formalization of the "compliance-by-runtime" property that distinguishes ST22 from ERC-3643. The prover verifies that the SPL Token-2022 program's transfer instruction always reaches the hook invocation path before completing the underlying balance update.
**Why it matters:** Pillar 6 (Compliance Enforcement at Every Transfer). Every transfer of every ST22 mint runs the 42 controls + applicable module-aware extensions. There is no bypass path because Solana's runtime semantics make the hook invocation mandatory.
**E.3 — Pool Non-Extractability (No Rugpull)**
**Informal statement:** No execution path exists by which the Global Unified Liquidity Pool's reserves can be debited to a withdrawal destination.
**CVL-equivalent formal statement:**
```
invariant poolReservesMonotonic
forall (slot s1, s2 where s1 <= s2):
global_pool.usdc_reserve(s2) >= global_pool.usdc_reserve(s1) - swap_outflows(s1, s2)
&& global_pool.token_reserve(s2) >= global_pool.token_reserve(s1) - swap_outflows(s1, s2)
&& global_pool.lp_supply(slot) == 0 /* LP burned at inception */
```
**Coverage:** All modules (the pool is shared). The invariant has two parts: (a) reserves can only decrease via swap outflows (legitimate trade execution), never via withdrawals; (b) LP supply is permanently zero, so no LP-redemption path exists.
**Why it matters:** Eliminates rugpull as a threat category. A malicious insider with full multi-sig authorization cannot drain the pool because no withdrawal instruction exists in the `liquidity_pool` program. The asymmetry is permanent — capital flows in (via 0.44% lock + STO seed + 2% reinvestment) and never flows out except as legitimate counterparty in a CEDEX trade.
**E.4 — Control Immutability**
**Informal statement:** The 42 core controls and applicable module-aware extensions cannot be removed, weakened, or repointed post-deployment.
**CVL-equivalent formal statement:**
```
invariant controlImmutability
transfer_hook_program.upgrade_authority == Pubkey::default()
&& transfer_hook_program.code_hash == DEPLOYED_CODE_HASH
&& forall (mint where hookExtension(mint) is registered):
hookExtension(mint).program_id == TRANSFER_HOOK_PROGRAM_ID
```
**Coverage:** All modules. The invariant has three parts: (a) the `transfer_hook` program has no upgrade authority; (b) the deployed code hash matches the audited deployment; (c) every hook-extended mint references the same canonical program ID.
**Why it matters:** Pillar 7 (Immutable, No Admin Override). The invariant formalizes the absence of an "admin escape hatch." The 42 controls and module-aware extensions execute the same logic for every mint, every transfer, forever.
**E.5 — Holding Period Monotonicity**
**Informal statement:** The HoldingPeriodAccount holding-period timer cannot be shortened by any execution path.
**CVL-equivalent formal statement:**
```
invariant holdingPeriodMonotonic(mint, beneficiary)
forall (slot s1, s2 where s1 <= s2):
holding_period_account(mint, beneficiary).unlock_slot(s2)
>= holding_period_account(mint, beneficiary).unlock_slot(s1)
&& holding_period_account(mint, beneficiary).unlock_slot
>= purchase_slot + HOLDING_PERIOD_FOR_JURISDICTION(jurisdiction)
```
**Coverage:** All modules. The invariant prevents (a) unlock\_slot from decreasing over time, and (b) initialization with an unlock\_slot that is shorter than the jurisdictional minimum (Reg D 6 months, Reg S 12 months, Reg CF 12 months).
**Why it matters:** SEC offering exemption compliance. Reg D, Reg S, and Reg CF holding periods are statutory; the platform's on-chain enforcement is what makes the holding-period claim credible to SEC examiners.
**E.6 — Hook Program ID Binding**
**Informal statement:** The Transfer Hook program ID for a given mint cannot be changed post-creation.
**CVL-equivalent formal statement:**
```
invariant hookBindingPermanent(mint)
forall (slot s1, s2 where s1 < s2 && mint exists at s1):
hookExtension(mint).program_id(s1) == hookExtension(mint).program_id(s2)
```
**Coverage:** All modules. The invariant verifies that the registered hook program ID, set at mint creation, is stable for the lifetime of the mint.
**Why it matters:** Closes the threat T4 (hook program ID repointing). Combined with E.4 (control immutability of the canonical hook program), the binding ensures a mint's compliance posture is permanent.
#### 15.3.3 Verification Methodology
| Phase | Activity | Owner |
| ----------------------- | ---------------------------------------------------------------------------------------- | --------------------------------------------------------- |
| Spec authoring | Translate informal invariant statements into CVL | Platform engineering + external formal-methods consultant |
| Spec review | External cryptographer review of CVL specifications for completeness | External advisor |
| Initial proof discharge | Run Certora Prover; iteratively refine code or spec until prover reports "verified" | Platform engineering |
| CI integration | Daily prover runs on every change to verified programs; fail builds on regression | Platform engineering |
| External validation | Trail of Bits + Halborn + (target) Quantstamp engaged to independently re-run and review | External auditors |
| Public publication | CVL specifications + program SBF artifacts published via Smart Contract Reference | Platform engineering |
#### 15.3.4 Verification Coverage Limitations
Formal verification proves what is specified — it does not prove the absence of bugs in unspecified properties. The platform's verification posture explicitly acknowledges:
1. **Off-chain components are not formally verified.** The Empire MSF, the Layer 9 IDOS classifier, the CEDEX order-book matching engine — all run off-chain and rely on conventional security review.
2. **Solana runtime is trusted.** The verification operates against the platform's SBF artifacts assuming the Solana runtime correctly executes the SBF instruction set. Solana runtime correctness is outside the platform's verification scope.
3. **Cryptographic primitive correctness is trusted.** Ed25519 signature verification is assumed correct per its mathematical specification.
4. **Hardware-level attacks are out of scope.** Side-channel attacks against validator hardware, RPC infrastructure, or wallet hardware are out of formal verification scope; they are mitigated operationally.
These trust boundaries are documented in the Risk Disclosure document and disclosed to all institutional counterparties.
### 15.4 Audit Trail Architecture
Every ST22 transfer emits structured on-chain audit events via Control GA-42. The audit trail is the canonical source for SEC examination, regulatory inquiry, internal compliance review, and counterparty due diligence.
#### 15.4.1 Audit Event Schema
```rust
#[event]
pub struct TransferAuditEvent {
pub mint: Pubkey, // ST22 mint
pub from: Pubkey, // Sender wallet
pub to: Pubkey, // Recipient wallet
pub amount: u64, // Transfer amount
pub slot: u64, // Solana slot number
pub block_time: i64, // Block timestamp (Unix epoch)
pub module: u8, // 1, 2, or 3
pub control_evaluations: [u8; 42], // 42 core controls — 0 = pass, 1 = fail
pub module_extension_evaluations: u8, // CB-21 NAV variant (M2) or REG-42 federal variant (M3)
pub fee_distribution: FeeDistribution, // 5% breakdown
pub holding_period_state: HoldingPeriodState,
pub custody_attestation_slot: u64, // Slot of Custody Oracle attestation read
pub price_at_execution: u64, // For CEDEX trades
pub error_code: Option, // 6001–6042 + variant codes if rejected
}
```
#### 15.4.2 Audit Trail Properties
| Property | Value |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Storage location | Solana ledger (program log via `emit!()` macro) |
| Mutability | Append-only; finalized blocks economically immutable after \~13 seconds |
| Retention | Permanent per Solana state retention policy; archived via Helius / dedicated archival node |
| Indexability | Full event indexing via platform RPC; queryable by mint, by wallet, by module, by date range, by error code |
| Examiner access | Read-only API endpoint at `https://api.rwatokens.net/audit/v1` for SEC / regulatory examiner access; structured query interface |
| Counterparty access | Per-mint audit access for issuer; per-wallet audit access for investor; redaction for counterparty privacy |
#### 15.4.3 Regulatory Reporting Integration
The audit trail feeds three downstream regulatory surfaces:
1. **SEC EDGAR filings** — Form D, Form 144, Form 4 filings auto-generated from audit events for the issuing entity (Module 1 issuers; Groovy Company STO)
2. **FinCEN reporting** — Suspicious Activity Reports (SARs) auto-flagged via Layer 9 IDOS behavioral signals and routed to Empire compliance officer
3. **State regulatory filings** — Wyoming, Nevada, and other state-of-incorporation filings driven by the audit trail's per-issuer summary
### 15.5 Beta Validation — Empirical Security Verification
The platform's V8/V9 architecture is the result of three production betas in late 2025 that empirically validated the security properties of the design. Each beta produced specific architectural decisions documented in the ADR registry.
#### 15.5.1 GROO Beta — October 31, 2025
**Setup:** GROO Utility Token launched on Raydium without Transfer Hook protection (intentional, to validate threat T8 architecturally).
**Result:**
* Peak market cap $6,000,000
* Post-attack market cap $250,000 (-95.8%)
* \~1,000+ coordinated sniper-bot wallets identified
* \~$5,750,000 extracted via Raydium routing
* 42 of 42 controls bypassed (controls executed correctly when invoked, but Raydium did not invoke them)
**Architectural decision:** ADR-002 — external DEX trading is architecturally incompatible with Transfer Hook enforcement. **Custom AMM (CEDEX) purpose-built around Token-2022 hook semantics required.**
#### 15.5.2 MSPC Beta — November 2025
**Setup:** Multi-Stage Protocol Calibration (MSPC) beta tested RPC capacity and copycat-token resilience.
**Result:**
* 13 copycat tokens deployed on external platforms within 96 hours of MSPC launch
* Shared-tier RPC (50 req/sec) saturated; legitimate trades failed during peak
* Copycat tokens with no SecurityConfig PDA could not list on CEDEX (intended behavior)
**Architectural decision:** Helius dedicated cluster (500+ req/sec) + Triton failover + public fallback. CEDEX issuer-onboarding gate validates SecurityConfig presence and Empire-verified status before listing.
#### 15.5.3 GRLF Beta — December 1–3, 2025
**Setup:** Gradual Real-Liquidity Float (GRLF) beta tested unauthorized LP creation and bot-share dynamics over 72 hours.
**Result:**
* Price collapse -93.69% over 72 hours
* 85% of all activity bot-driven
* Unauthorized LP created by third-party bot 54 minutes after mint deployment
**Architectural decision:** ADR-010 — Jito MEV protection mandatory for CEDEX. Protocol-controlled pool creation: `liquidity_pool` program rejects LP-creation requests for ST22 mints not in CEDEX-registered list.
#### 15.5.4 The Alesia Doctrine
The three betas converge on a single architectural framework that the platform calls the **Alesia Doctrine**, after Caesar's siege at Alesia where dual encircling walls — circumvallation against the besieged, contravallation against the relieving force — provided complete defensive integrity.
| Wall | Purpose | Implementation |
| ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Circumvallation — Liquidity Containment** | Liquidity contained within CEDEX and the Global Pool; external venues cannot host ST22 mints | External DEXs cannot route ST22 trades through hook (T8); LP creation gated by `liquidity_pool` program (T6); Global Pool LP burned (E.3) |
| **Contravallation — Bot Defense** | Inside CEDEX, MEV protection, wallet caps, holding-period enforcement, and circuit breakers prevent coordinated bot extraction | Jito Block Engine (T15); wallet caps PL-16 to PL-20; HP-24 holding period enforcement; CB-21 to CB-25 circuit breakers including module-aware variants |
Together, the two walls produce architectural integrity: there is no path by which a sniper bot can extract value from an ST22 mint. The October 2025 GROO failure mode is structurally impossible under V8+ architecture. The Alesia Doctrine framing is referenced in ADR-002 and the Architecture Decisions registry.
### 15.6 External Security Reviews
| Review | Provider | Scope | Status |
| ------------------------------ | ---------------------------------- | ------------------------------------------------------- | --------------------------------------------------------------------------- |
| `transfer_hook` audit | Trail of Bits | 42 core controls; Rust source; SBF artifact | Completed Q1 2026; report public |
| Module-aware extension audit | Halborn | CB-21 NAV variant; REG-42 federal variant | Completed Q1 2026; report public |
| `liquidity_pool` + `amm` audit | Quantstamp | Global Pool LP burn; CPMM swap path; reserve protection | Completed Q1 2026; report public |
| Cryptography review | External cryptographer (PhD-level) | Ed25519 attestation flow; oracle relay key management | Completed Q1 2026; advisory only (no published report) |
| Continuous bug bounty | Immunefi | All 5 platform programs | Active 12 months pre-launch; ongoing post-launch with ≥$500K maximum bounty |
All audit reports are published via the platform Smart Contract Reference. Findings remediation is documented per finding with the specific code change and re-audit confirmation.
### 15.7 Operational Security
#### 15.7.1 Multi-Sig Architecture
The 3-of-5 multi-sig governing program upgrades and major operational decisions:
| Signer | Role | Hardware |
| ---------------------------------------- | ------------------------------------------------------- | --------------------------------- |
| Frank Yglesias | Chairman & CTO of Groovy Company; sole director | Ledger Enterprise hardware module |
| Patrick Mokros | COO of Groovy Company; Founder of Empire Stock Transfer | Ledger Enterprise hardware module |
| Empire Stock Transfer Compliance Officer | §17A compliance authority | Ledger Enterprise hardware module |
| External Technical Advisor #1 | Regulatory expertise | Ledger Enterprise hardware module |
| External Technical Advisor #2 | Cryptography expertise | Ledger Enterprise hardware module |
All signers operate Ledger Enterprise hardware. Private keys never touch internet-connected systems. Multi-sig signing requires physical device interaction. The 48-hour timelock prevents same-session coordination attacks.
#### 15.7.2 Incident Response
The Incident Response Playbook (separate document) defines procedures for 11 incident classes ranging from oracle-attestation staleness to suspected Solana Foundation Token-2022 weakening. Each class has:
* Detection criteria (automated monitoring + manual review)
* Severity classification (P0 through P3)
* Response timeline (P0 = 60 minutes; P3 = 5 business days)
* Authorized personnel for response
* Communication template (issuer notification, regulatory notification, public disclosure)
* Post-incident review and ADR update
#### 15.7.3 Disaster Recovery
| Scenario | Recovery Time Objective (RTO) | Recovery Point Objective (RPO) |
| ------------------------------- | ------------------------------------------ | ------------------------------------- |
| RPC primary failure | < 60 seconds | 0 (failover handles state continuity) |
| Helius cluster failure | < 30 seconds (Triton failover) | 0 |
| All RPC providers fail | < 5 minutes (public fallback) | 0 (read-only continues) |
| Datadog monitoring outage | < 30 minutes (manual monitoring fallback) | 0 (audit trail unaffected) |
| Multi-sig signer unavailability | < 24 hours (substitute signer designation) | N/A |
| Solana Mainnet-Beta restart | Per Solana network recovery time | Solana-determined |
### 15.8 Architectural Decision Records — Security
| ADR | Title | Date | Decision Summary |
| ------- | ---------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| ADR-006 | `transfer_hook` immutability | August 2025 | No upgrade authority; defects via re-deployment with migration path; Certora E.4 |
| ADR-007 | Token-2022 trust assumption disclosure | September 2025 | Residual L1 trust on Solana Foundation Token-2022 upgrade authority; mitigated by version-pinning, monitoring, Control 42 contingency |
| ADR-002 | CEDEX-only architecture (post-GROO beta) | November 2025 | External DEXs cannot host ST22 mints; custom AMM purpose-built around Token-2022 hook semantics |
| ADR-010 | Jito MEV protection | December 2025 | December 2025 GRLF beta validated 85% bot share; Jito Block Engine integration mandatory for CEDEX |
| ADR-013 | Module-aware extension Halborn audit | March 2026 | V9 module-aware extensions audited independently of V8 core 42 controls; staged audit reduces blast radius |
***
### 15.9 Cross-References
* **Section 5** — Layer 1 Solana Foundation (`transfer_hook` immutability; Ed25519 native precompile)
* **Section 7** — Layer 2 Transfer Hook (the 42 controls + module-aware extensions verified by E.2, E.4, E.5, E.6)
* **Section 11** — Empire Stock Transfer (the per-slot Ed25519 attestation flow underlying E.1)
* **Section 14** — Global Unified Liquidity Pool (the LP burn mechanics underlying E.3)
* **Smart Contract Reference** — full CVL specifications; SBF artifacts; audit reports
* **Risk Disclosure** — disclosed residual trust assumptions and limitations of formal verification
* **Incident Response Playbook** — operational procedures for security incidents
* **Architecture Decisions** — full ADR registry
***
*RWA Tokens Platform Whitepaper · Section 15 — Security Model and Formal Verification · V10.0 · Groovy Company, Inc.*
# Acronyms and Defined Terms
## SECTION 16 — Acronyms and Defined Terms
**RWA Tokens Platform Whitepaper · V10.0 · May 2026** **Issued by:** Groovy Company, Inc. (Wyoming corporation; OTC: GROO; SEC EDGAR CIK 1499275) **Section classification:** Technical Specification — Reference Lexicon **Authority:** Authoritative for all defined terms used throughout this whitepaper
***
### 16.1 Scope and Reading Conventions
This section provides the authoritative lexicon for every acronym, defined term, and technical abbreviation used in this whitepaper, organized into thirteen categories. Each entry includes the expansion, an extended definition, and a cross-reference to the primary section in which the term operates. Where a term has both a colloquial usage and a precise platform usage, the platform usage controls.
**Reading conventions:**
* **Bold** terms are defined herein
* *Italic* terms are quoted directly from a federal authority (SEC, CFTC, Treasury, etc.)
* `monospace` terms are program-level identifiers, account fields, or instruction names
* All citations to "Section N" refer to sections within this whitepaper unless otherwise specified
* All citations to "ADR-NN" refer to entries in the Architecture Decisions registry (a separate platform document)
For canonical platform terminology, the **platform Glossary** (a separate, governance-controlled document) is the controlling reference. This Section 16 supports reading this whitepaper specifically; the Glossary supports the entire platform documentation suite.
### 16.2 Category 1 — Regulatory and Federal Authorities
| Acronym | Expansion | Extended Definition | Primary Section |
| ---------- | ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| **SEC** | Securities and Exchange Commission | The principal federal regulator of US securities markets. The platform operates under SEC frameworks including Release No. 33-11412 (Five-Category Taxonomy), the January 28, 2026 Joint Staff Statement on Tokenized Securities, and the April 13, 2026 Staff Statement on Covered User Interface Providers. The SEC's Division of Trading and Markets, Division of Corporation Finance, and Division of Investment Management each touch different aspects of the platform's regulatory posture. | §3, §12 |
| **CFTC** | Commodity Futures Trading Commission | The federal regulator with jurisdiction over commodity futures, swaps, and tokenized commodities. Relevant to the platform via (a) the GROO Utility Token's Category 1 (Digital Commodity) classification under Release No. 33-11412 and (b) Module 3 (CORECM) intersection with strategic-mineral commodity considerations. CFTC Letters 25-39 (2025) and 26-05 (2026) are operative guidance. | §3.7, §12 |
| **OCC** | Office of the Comptroller of the Currency | Treasury bureau regulating national banks and federal savings associations. Relevant to the platform via stablecoin issuance: OCC interpretive letters 1170, 1172, and 1174 establish national-bank authority to engage with payment stablecoin infrastructure used in the platform's settlement layer. | §15 |
| **FinCEN** | Financial Crimes Enforcement Network | Treasury bureau administering the Bank Secrecy Act (BSA). Empire Stock Transfer's investor onboarding satisfies FinCEN's Customer Identification Program (CIP) and Customer Due Diligence (CDD) Final Rule (FIN-2016-G004) requirements. | §11.2 |
| **OFAC** | Office of Foreign Assets Control | Treasury bureau administering US economic sanctions. Per-wallet OFAC / SDN screening on every ST22 transfer is enforced by Control SX-34 reading the OFAC Oracle PDA. | §3, §12 |
| **FINRA** | Financial Industry Regulatory Authority | Self-regulatory organization for broker-dealers. Relevant to Reg CF retail crowdfunding offerings, which require a FINRA-registered funding portal partner. | §8.4, §13 |
| **NIST** | National Institute of Standards and Technology | Federal standards body. Relevant to the platform's cryptographic primitive selections — Ed25519 (FIPS 186-5), SHA-256 (FIPS 180-4), and TLS 1.3 (RFC 8446). | §5, §15 |
| **USGS** | United States Geological Survey | Federal scientific agency maintaining the Critical Minerals List that informs Module 3 basin classification. The USGS list is updated approximately every three years; the current operative version determines `classification_status` field semantics for Module 3 ClassificationOracle PDAs. | §3.9, §10 |
| **DOE** | Department of Energy | Federal department maintaining the Critical Materials Strategy. Module 3 coal-derived Rare Earth Element recovery facilities operate within the DOE framework. | §3.9, §10 |
| **DPA** | Defense Production Act | Federal authority (Title III specifically) authorizing federal investment in domestic critical-minerals production. Module 3 basin assets receiving DPA Title III investment are flagged in the ClassificationOracle. | §3.9, §10 |
| **IRA** | Inflation Reduction Act | Federal legislation including critical-minerals tax-credit and supply-chain provisions. IRA eligibility status is reflected in the Module 3 ClassificationOracle `classification_status` bitfield. | §3.9, §10 |
| **EO** | Executive Order | Presidential directive carrying federal regulatory force. Executive Order 14017 ("America's Supply Chains") is relevant to Module 3 basin classification and federal-action triggers. | §3.9, §10 |
### 16.3 Category 2 — Platform Modules and Asset-Class Vehicles
| Acronym | Expansion | Extended Definition | Primary Section |
| ---------- | --------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| **M1** | Module 1 — Equities | The platform's first asset-class module. Tokenizes equity securities across OTC microcap, NASDAQ, AMEX, TSX, and global exchanges. Backing instrument: Common Class B equity custodied 1:1 by Empire Stock Transfer. Asset identifier: CUSIP. The architectural baseline — Module 1 mints set `module = 1` in SecurityConfig and use no module-aware extensions. | §8 |
| **M2** | Module 2 — Real Estate | The platform's second asset-class module. Tokenizes equity in real-property assets through the Single-Asset Entity (SAE) corporate vehicle. Module-aware extension: Control CB-21 NAV-deviation variant with default 22% tolerance band and 90-day reappraisal cadence. | §9 |
| **M3** | Module 3 — CORECM | The platform's third asset-class module. Tokenizes equity in US strategic-minerals supply-chain assets through the Basin-Asset Entity (BAE) corporate vehicle. Module-aware extension: Control REG-42 federal-action variant with automatic 60-minute SLA freeze on detection of qualifying federal action. | §10 |
| **CORECM** | Carbon Ore, Rare Earth, and Critical Minerals | The asset-class addressed by Module 3 — US strategic-minerals supply-chain assets including coal-derived Rare Earth Element recovery facilities, basin-level mining concessions, critical-minerals processing facilities, and supply-chain logistics infrastructure. The acronym is canonical platform terminology. | §10 |
| **SAE** | Single-Asset Entity | The Module 2 corporate vehicle holding a real-property asset. Typically a Nevada Limited Liability Company converted to a Nevada corporation prior to ST22 issuance, with Empire Stock Transfer custodying SAE common stock 1:1 behind issued ST22 Module 2 tokens. | §9.2 |
| **BAE** | Basin-Asset Entity | The Module 3 corporate vehicle holding a basin asset. Structured to permit Empire Stock Transfer to custody BAE common stock under §17A. Each ST22 Module 3 token is backed 1:1 by BAE common stock. | §10.2 |
| **REE** | Rare Earth Elements | The seventeen elements (lanthanides plus scandium and yttrium) classified as critical minerals under the USGS Critical Minerals List. Coal-derived REE recovery is a specific Module 3 asset category recognized under the DOE Critical Materials Strategy. | §10 |
| **CUSIP** | Committee on Uniform Securities Identification Procedures | The standard nine-character identifier for North American equity securities. Module 1 mints carry the issuer's CUSIP as the asset identifier, with Control CV-05 rejecting transfers where the bound CUSIP fails to match the custodied share class. | §8.3 |
### 16.4 Category 3 — Compliance, KYC, AML
| Acronym | Expansion | Extended Definition | Primary Section |
| -------- | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ |
| **KYC** | Know Your Customer | Investor identity verification for individual investors. Performed by Empire Stock Transfer as the sole onboarding authority across all three modules. Includes name, date of birth, address, government-ID verification, and proof-of-address documentation per FinCEN CIP requirements. | §11.2 |
| **KYB** | Know Your Business | Investor identity verification for institutional investors and corporate entities. Includes entity formation verification, beneficial-ownership identification per FinCEN CDD Final Rule, and authorized-signatory documentation. | §11.2 |
| **AML** | Anti-Money Laundering | The body of US federal regulation (Bank Secrecy Act, USA PATRIOT Act, AML/CFT statutes) governing detection and prevention of money laundering through financial institutions. The platform's three-tier AML screening uses Chainalysis KYT and TRM Labs forensics. | §3, §11.2, §12.3 |
| **BSA** | Bank Secrecy Act | The 1970 federal statute (31 U.S.C. §5311 *et seq.*) requiring financial institutions to assist federal authorities in detecting and preventing money laundering. Foundation of Empire Stock Transfer's AML compliance program. | §11.2 |
| **CIP** | Customer Identification Program | FinCEN regulation (31 C.F.R. §1020.220) implementing BSA Section 326 requirements for financial-institution customer identity verification. The framework underlying Empire's investor identity verification across all three modules. | §11.2 |
| **CDD** | Customer Due Diligence | FinCEN Final Rule (31 C.F.R. §1010.230) requiring beneficial-ownership identification for legal-entity customers. Operative for Empire's KYB process. | §11.2 |
| **SDN** | Specially Designated Nationals | OFAC's list of sanctioned individuals, entities, and addresses. Per-wallet SDN screening on every ST22 transfer via Control SX-34 reading a Bloom filter of sanctioned addresses maintained in the OFAC Oracle PDA. | §12.2 |
| **KYT** | Know Your Transaction | Chainalysis's transaction-monitoring platform integrating with the platform's AML Oracle for per-wallet risk assessment. | §12.3 |
| **EDD** | Enhanced Due Diligence | The deeper-investigation regime applied to investors flagged by initial KYC / KYB / AML screening. Empire Stock Transfer escalates EDD cases through internal compliance review. | §11.2 |
| **SAR** | Suspicious Activity Report | FinCEN-defined report (31 C.F.R. §1020.320) filed for transactions of $5,000+ meeting BSA criteria for suspicious activity. Empire Stock Transfer files SARs as required; the Layer 9 IDOS module surfaces candidate cases for Empire compliance review. | §16 (Layer 9 IDOS) |
| **FATF** | Financial Action Task Force | The intergovernmental body setting international AML/CFT standards. The FATF "high-risk" jurisdiction list informs Empire's enhanced-due-diligence procedures. | §11.2 |
| **FCPA** | Foreign Corrupt Practices Act | US statute (15 U.S.C. §§78dd-1 *et seq.*) prohibiting corrupt payments to foreign officials. Relevant to issuer KYB review for non-US issuers. | §11.2 |
### 16.5 Category 4 — Token Standards and Smart-Contract Frameworks
| Acronym | Expansion | Extended Definition | Primary Section |
| ---------- | --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| **SPL** | Solana Program Library | The reference implementation library of Solana's standard programs. The platform uses SPL Token-2022 (program ID `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHCBxGTJSAGkSm`) as the underlying token program for all ST22 mints. | §5.5 |
| **ST22** | (Per-issuer) Digital Securities tokenization product line | The platform's ST22 product is a per-issuer per-module tokenization standard built on SPL Token-2022 with the Transfer Hook extension. The "22" derives from "Token-2022." Each ST22 mint is a separate Token-2022 mint with its own SecurityConfig PDA. | §1, §7 |
| **STO** | Security Token Offering | A regulated securities offering in tokenized form. The Groovy Security Token (STO) is the platform operator's $20M Reg D offering of Common Class B equity in Groovy Company, Inc. itself. | §4.2 |
| **ERC** | Ethereum Request for Comments | Ethereum's standards-track proposal mechanism. ERC-3643 (also known as the T-REX standard) is the EVM ecosystem's compliance-overlay token standard, contrasted with ST22 in Section 14. | §14 |
| **ERC-20** | Ethereum Request for Comments 20 | The base fungible-token standard on Ethereum. ERC-3643 layers compliance overlays atop ERC-20; the architectural risk is that direct calls to underlying ERC-20 functions can bypass the ERC-3643 overlay. | §14, §15 |
| **EIP** | Ethereum Improvement Proposal | Ethereum's improvement-proposal mechanism. EIP-3643 is the formal specification of the T-REX security-token standard. | §14 |
| **T-REX** | Token for Regulated EXchanges | The colloquial name for the ERC-3643 standard, originated by Tokeny Solutions. Used interchangeably with ERC-3643 throughout this whitepaper. | §14 |
| **SBF** | Solana BPF Format | The instruction-set-architecture intermediate representation used by Solana programs. The Certora Prover verifies the platform's SBF artifacts directly. | §5, §15.3 |
| **BPF** | Berkeley Packet Filter | The instruction set on which SBF is based. Solana programs are compiled to SBF, a Solana-specific evolution of BPF. | §5 |
| **CPI** | Cross-Program Invocation | Solana's primitive for one program to call another. The Token-2022 program invokes the platform's `transfer_hook` program via CPI on every transfer of a hook-extended mint. | §5.5, §7 |
### 16.6 Category 5 — Solana Blockchain Technical
| Acronym | Expansion | Extended Definition | Primary Section |
| ------------ | ---------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| **PoH** | Proof-of-History | Solana's Verifiable Delay Function-based cryptographic clock. Provides verifiable wall-clock ordering of events without requiring inter-node communication. | §5.3.1 |
| **PoS** | Proof-of-Stake | Solana's stake-based validator selection mechanism, layered with PoH and Tower BFT consensus. | §5.3.2 |
| **BFT** | Byzantine Fault Tolerance | The class of consensus protocols tolerating arbitrary (Byzantine) validator failures up to a threshold. Tower BFT is Solana's PBFT-derived implementation. | §5.3.2 |
| **TPS** | Transactions Per Second | Standard throughput metric. Solana's theoretical 65,000 TPS contrasts with the platform's compliance-verified throughput of 400–600 TPS for ST22 trades (bottleneck: hook execution + Ed25519 verification per trade). | §5.8 |
| **CU** | Compute Unit | Solana's unit of program-execution accounting. Per-transfer compute consumption: M1 \~800K CU, M2 \~820K CU, M3 \~830K CU; CEDEX swap path adds \~150K CU. | §5.7 |
| **PDA** | Program Derived Address | A Solana account address deterministically derived from seeds and a program ID via `find_program_address`. Off-curve property guarantees no private key can sign for the address. The platform's compliance state lives entirely in PDAs. | §5.4 |
| **VDF** | Verifiable Delay Function | The cryptographic primitive underlying PoH. Provides a function whose output requires a known minimum amount of sequential computation, with the output verifiable in time independent of computation. | §5.3.1 |
| **SHA-256** | Secure Hash Algorithm 256-bit | The cryptographic hash function used in Solana's PoH chain. NIST FIPS 180-4. | §5.3.1 |
| **Ed25519** | Edwards-curve Digital Signature Algorithm with 25519 prime | The cryptographic signature scheme used for Empire custody attestation, NAV oracle attestation (M2), Classification oracle attestation (M3), and OFAC oracle attestation. NIST FIPS 186-5. Verified by Solana's native Ed25519 precompile (\~600 CU per verification). | §5.3.3 |
| **RPC** | Remote Procedure Call | Solana's standard interface for off-chain clients to query on-chain state and submit transactions. The platform operates dedicated Helius RPC capacity (500+ req/sec) with Triton failover. | §5.9.1 |
| **MEV** | Maximum Extractable Value (originally "Miner Extractable Value") | Value extracted by transaction-ordering manipulation (frontrunning, sandwiching, liquidations). All CEDEX trades route through Jito Block Engine for MEV protection. | §5.9.2, §13 |
| **gRPC** | Google Remote Procedure Call | The performant alternative to JSON-RPC used by some Solana RPC providers. Helius supports both gRPC and JSON-RPC; the platform uses gRPC for high-throughput backend paths. | §5.9.1 |
| **JSON-RPC** | JavaScript Object Notation Remote Procedure Call | The standard Solana RPC protocol. Used by the platform's investor-facing client paths. | §5.9.1 |
### 16.7 Category 6 — Oracle and Network Infrastructure
| Acronym | Expansion | Extended Definition | Primary Section |
| --------- | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- |
| **TWAP** | Time-Weighted Average Price | Average price weighted by time interval. The TWAP Oracle (sourced from Pyth Network) is read by Control CB-22 (price-impact circuit breaker) to detect trades deviating more than 2% from TWAP. | §12.4 |
| **NAV** | Net Asset Value | The Module 2-specific concept of underlying property value per token. Per-mint NAV Oracle PDA stores authorized appraiser's Ed25519-signed NAV attestation. Default reappraisal cadence: 90 days. | §9, §12.6 |
| **EDGAR** | Electronic Data Gathering, Analysis, and Retrieval | SEC's filing system. EDGAR Oracle (Module 1-specific) surfaces issuer 10-K, 10-Q, 8-K filings for Layer 9 IDOS distress-signal generation. | §12.5, §16 (IDOS) |
| **CIK** | Central Index Key | SEC EDGAR's unique identifier for filing entities. Groovy Company, Inc.'s CIK is **1499275**. CIK is the seed for the EDGAR Oracle PDA derivation. | §12.5 |
| **NDA** | Non-Disclosure Agreement | The platform's Global NDA template governs confidential issuer engagements pre-onboarding. | §11 |
### 16.8 Category 7 — Settlement and Stablecoin
| Acronym | Expansion | Extended Definition | Primary Section |
| -------------- | ---------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| **GENIUS Act** | Generation of Enabling and National Innovation in U.S. Stablecoins Act | Federal stablecoin legislation establishing the compliance framework for payment stablecoin issuers. The platform settles all ST22 purchases in USDC or PYUSD under this framework. | §15 |
| **USDC** | USD Coin | The Circle-issued payment stablecoin used as primary settlement currency on the platform. 1:1 USD-backed with monthly attestation of dollar reserves. | §15 |
| **PYUSD** | PayPal USD | The Paxos-issued payment stablecoin available as alternative settlement currency. 1:1 USD-backed with monthly attestation. | §15 |
| **GAAP** | Generally Accepted Accounting Principles | The US accounting standards body governing financial reporting. Relevant to the platform's intangible-asset valuation (ASC 350 / ASC 985 software valuation methodology). | §13 |
### 16.9 Category 8 — Trading and Market Microstructure
| Acronym | Expansion | Extended Definition | Primary Section |
| --------- | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------- |
| **CEDEX** | Compliant Exchange for Digital Securities | The platform-operated trading venue at cedex.market. The only legitimate trading venue for ST22 mints across all three modules. Operates 24/7/365 with permanent protocol-owned liquidity from the Global Unified Liquidity Pool. | §13 |
| **AMM** | Automated Market Maker | The class of algorithmic market-making protocols. CEDEX's matching engine implements a custom CPMM AMM purpose-built around Token-2022 hook semantics. | §13 |
| **CPMM** | Constant Product Market Maker | The AMM model with invariant `x × y = k`. CEDEX's settlement layer is a custom CPMM with `u128` overflow-safe arithmetic. | §13.4 |
| **CLMM** | Concentrated Liquidity Market Maker | The Uniswap V3-derived AMM model with liquidity concentrated in price ranges. Not used by the platform — CPMM is the chosen model. | §13 |
| **DEX** | Decentralized Exchange | A class of trading venues operating without centralized intermediation. The October 2025 GROO beta empirically validated that external DEXs (Raydium, Orca, Jupiter) cannot host ST22 mints — see §15.5.1. | §13.2, §15.5 |
| **ATS** | Alternative Trading System | An SEC-regulated trading venue alternative to a national securities exchange. Securitize Markets is an ATS; the architectural comparison vs CEDEX is documented in §13.11. | §13.11 |
| **OTC** | Over-the-Counter | The dealer-network market for securities not traded on national exchanges. OTC microcap is a primary Module 1 addressable surface. | §2, §8 |
| **OTCID** | OTC Markets Group Current OTC Tier | OTC Markets Group's current OTC market tier label. | §2 |
| **LP** | Liquidity Provider | A party providing liquidity to an AMM in exchange for LP tokens representing pro-rata pool ownership. The Global Unified Liquidity Pool's LP tokens are burned at inception, mathematically preventing withdrawal — Certora invariant E.3. | §14, §15.3.2 |
| **MM** | Market Maker | A party providing two-sided quotes on a trading venue. Traditional ATS architectures rely on per-issuer market makers ($5K–$20K/month subsidies); the platform's shared Global Pool architecture eliminates this requirement. | §13.11 |
### 16.10 Category 9 — Custody, Transfer Agency, and Corporate Governance
| Acronym | Expansion | Extended Definition | Primary Section |
| --------- | -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| **§17A** | Section 17A of the Securities Exchange Act of 1934 | The federal statutory authority under which Empire Stock Transfer is registered as a transfer agent and qualified custodian. The architectural anchor for Pillar 3 of Category 1 Model B. | §11 |
| **MSF** | Master Securityholder File | The legally controlling shareholder register maintained by Empire Stock Transfer under §17A. Reconciled to the on-chain SPL Token-2022 ledger every Solana slot via Ed25519 attestation. | §11.4 |
| **PPM** | Private Placement Memorandum | The offering document for Reg D and similar private offerings. The Groovy Security Token (STO) is offered pursuant to a PPM. | §13 |
| **DTC** | Depository Trust Company | The traditional US securities clearing and settlement infrastructure. Module 1 ST22 tokens reference issuer CUSIPs that may also have DTC-eligible representations; the platform's on-chain ledger functions as the transfer notification layer per Wyoming W\.S. 34-29-101. | §3.4, §11.4 |
| **UCC** | Uniform Commercial Code | State-law commercial code adopted (with variations) by all 50 states. UCC Article 8 ("Investment Securities") supplies the legal framework for the transfer-notification architecture by which ST22 transfers constitute effective instructions to Empire. | §3.4 |
| **W\.S.** | Wyoming Statutes | Wyoming's codified state law. **W\.S. 34-29-101** *et seq.* is Wyoming's digital asset statute providing legal recognition of digital asset transfers and property rights. | §3.4 |
### 16.11 Category 10 — Federal Critical-Minerals Frameworks (Module 3)
| Acronym | Expansion | Extended Definition | Primary Section |
| ----------------- | ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| **§232** | Section 232 of the Trade Expansion Act of 1962 | Federal authority (19 U.S.C. §1862) authorizing tariffs and import restrictions on national-security grounds. Section 232 actions affecting basin commodity inputs trigger the Module 3 ClassificationOracle's `federal_action_active` field, invoking Control REG-42. | §3.9, §10.6 |
| **EO 14017** | Executive Order 14017 — America's Supply Chains | Presidential directive (February 24, 2021) addressing US supply-chain resilience including critical minerals. Module 3 basin classification reflects EO 14017 priority designations. | §3.9, §10 |
| **DPA Title III** | Defense Production Act, Title III | Federal authority (50 U.S.C. §4533) for federal investment in domestic critical-minerals production. Module 3 BAEs receiving DPA Title III investment are flagged in the ClassificationOracle. | §3.9, §10 |
| **IRA §13502** | Inflation Reduction Act, Section 13502 | Critical-minerals tax-credit provision. Eligibility status reflected in Module 3 ClassificationOracle `classification_status` bitfield. | §3.9, §10 |
| **Energy Act** | Energy Act of 2020 | Federal legislation (42 U.S.C. §16391 *et seq.*) establishing critical-minerals research and innovation programs. Module 3 BAE eligibility status tracked via ClassificationOracle. | §3.9, §10 |
| **DLA** | Defense Logistics Agency | Federal agency operating the National Defense Stockpile. Module 3 basin assets supplying the National Defense Stockpile are flagged in the ClassificationOracle. | §10 |
| **BLM** | Bureau of Land Management | Federal agency administering mining concessions on federal land. Module 3 basin asset identifiers may reference BLM concession IDs. | §10.3 |
### 16.12 Category 11 — Internal Platform Naming
| Acronym | Expansion | Extended Definition | Primary Section |
| -------- | --------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ |
| **GROO** | (Platform ecosystem token; OTC ticker for Groovy Company, Inc.) | Two distinct uses: (a) the OTC ticker symbol of Groovy Company, Inc. on US OTC markets; (b) the platform's GROO Utility Token — Release No. 33-11412 Category 1 (Digital Commodity) or Category 3 (Digital Tool), distributed via deterministic linear bonding curve. Not interchangeable with the Groovy Security Token (STO) or with ST22 Digital Securities. | §4.1, §13.2 |
| **IDOS** | Issuer Distress and Opportunity Score | The Layer 9 off-chain compliance intelligence module. Aggregates EDGAR filings (M1), NAV deviation history (M2), Classification oracle history (M3), on-chain trading activity, and wallet behavioral signals into per-issuer risk and opportunity scores. Does not modify on-chain compliance enforcement. | §16 (in body), §15 |
| **ADR** | Architecture Decision Record | Versioned platform document recording an architectural decision, its context, alternatives considered, and rationale. ADR-001 through ADR-013+ are referenced throughout this whitepaper. | All sections |
| **MSPC** | Multi-Stage Protocol Calibration | The November 2025 beta validating RPC capacity and copycat-token resilience. | §15.5.2 |
| **GRLF** | Gradual Real-Liquidity Float | The December 1–3, 2025 beta validating unauthorized LP creation and bot-share dynamics. | §15.5.3 |
| **RTO** | Recovery Time Objective | Disaster-recovery metric: maximum acceptable time to restore a service after an outage. Documented per scenario in §15.7.3. | §15.7.3 |
| **RPO** | Recovery Point Objective | Disaster-recovery metric: maximum acceptable data loss measured by time. The platform's audit-trail RPO is zero (immutable Solana ledger). | §15.7.3 |
| **SLA** | Service-Level Agreement (Service-Level Objective) | A defined operational-performance target. The Module 3 Control REG-42 federal-action variant has a 60-minute SLA from federal-action detection to on-chain freeze. | §10.5 |
### 16.13 Category 12 — Offering Exemptions and Investor Classifications
| Acronym | Expansion | Extended Definition | Primary Section |
| ------------ | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| **Reg D** | Regulation D | SEC regulation (17 C.F.R. §§230.500–508) providing exemptions from registration for private placements. The platform's primary exemption regime for US accredited-investor offerings, with 6-month holding period enforced on-chain by Control HP-24. | §3.6, §8.4 |
| **Reg S** | Regulation S | SEC regulation (17 C.F.R. §§230.901–905) providing safe harbors for offshore securities offerings to non-US persons. The platform's primary exemption regime for non-US investor offerings, with 12-month distribution-compliance period enforced on-chain. | §3.6, §8.4 |
| **Reg CF** | Regulation Crowdfunding | SEC regulation (17 C.F.R. §227.100 *et seq.*) implementing JOBS Act §4(a)(6) for retail-investor crowdfunding. The platform's exemption regime for US retail offerings, requiring a FINRA-registered funding portal partner. | §3.6, §8.4, §13 |
| **Reg A** | Regulation A | SEC regulation permitting limited public offerings up to $75M annually to non-accredited investors. Available as an alternative offering exemption regime within the platform's compliance architecture; not the primary path. | §3.6 |
| **JOBS Act** | Jumpstart Our Business Startups Act | The 2012 federal statute creating Reg CF and modifying multiple SEC exemption regimes. §4(a)(6) is the statutory authority for Reg CF. | §3.6 |
| **15c2-11** | SEC Rule 15c2-11 | SEC rule (17 C.F.R. §240.15c2-11) governing market-maker quotation requirements for OTC securities. Relevant to Module 1 OTC microcap context as one of the historical drivers of OTC microcap market structure. | §2 |
| **10b-5** | SEC Rule 10b-5 | SEC anti-fraud rule (17 C.F.R. §240.10b-5) prohibiting fraud and market manipulation in securities transactions. Universally applicable to all platform-facilitated transactions. | §3 |
| **13d-3** | SEC Rule 13d-3 | SEC rule (17 C.F.R. §240.13d-3) defining beneficial ownership for disclosure requirements. Relevant to the platform's wallet-cap enforcement (Controls PL-16 through PL-20). | §7.1 |
| **Rule 144** | SEC Rule 144 | SEC rule (17 C.F.R. §230.144) governing resale of restricted securities after specified holding periods. Directly implemented by Transfer Hook Control HP-24 / HP-26 holding-period enforcement on Reg D issuances. | §3.6, §7.1 |
### 16.14 Category 13 — Token-2022 Extensions and Specific Programs
| Acronym | Expansion | Extended Definition | Primary Section |
| -------------------------- | ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| **`TransferHook`** | SPL Token-2022 Transfer Hook Extension | The Token-2022 extension binding a hook program to a mint such that every transfer instruction invokes the hook. The architectural primitive enabling the platform's runtime-enforced compliance. | §5.5, §7 |
| **`MintCloseAuthority`** | SPL Token-2022 Mint Close Authority Extension | Token-2022 extension permitting the mint to be closed. Disabled on all platform mints to protect the 1:1 backing invariant. | §5.5.2 |
| **`ConfidentialTransfer`** | SPL Token-2022 Confidential Transfer Extension | Token-2022 extension supporting privacy-preserving transfers. Disabled on platform mints — conflicts with Empire MSF reconciliation transparency. | §5.5.2 |
| **`CpiGuard`** | SPL Token-2022 CPI Guard Extension | Token-2022 extension preventing accidental CPI-driven debits. Enabled on issuer treasury PDAs. | §5.5.2 |
| **`ImmutableOwner`** | SPL Token-2022 Immutable Owner Extension | Token-2022 extension preventing account-owner reassignment. Enabled on AMM market accounts. | §5.5.2 |
| **`MetadataPointer`** | SPL Token-2022 Metadata Pointer Extension | Token-2022 extension permitting issuer-supplied metadata URI. Optional per mint. | §5.5.2 |
| **`SecurityConfig`** | Platform PDA storing per-mint compliance parameters | The per-mint PDA encoding all 42 control parameters plus module-aware extension fields. Seed: `[b"security-config", mint]`. Owning program: `transfer_hook`. | §5.4.2, §7 |
| **`HoldingPeriodAccount`** | Platform PDA storing per-investor-mint holding period state | Per-investor-mint PDA enforcing Reg D / Reg S / Reg CF holding periods on-chain. Seed: `[b"holding-period", mint, beneficiary]`. Owning program: `transfer_hook`. | §5.4.2, §7 |
| **`CustodyOracle`** | Platform PDA storing Empire's custody attestation | Per-mint PDA storing Empire's most recent Ed25519-signed custody attestation. Seed: `[b"custody-oracle", mint]`. Owning program: `oracle_aggregator`. | §11.3 |
| **`NavOracle`** | Platform PDA storing authorized appraiser's NAV attestation (M2) | Per-mint PDA storing authorized appraiser's Ed25519-signed NAV attestation for Module 2. Seed: `[b"nav-oracle", mint]`. Owning program: `oracle_aggregator`. | §9.3 |
| **`ClassificationOracle`** | Platform PDA storing federal classification status (M3) | Per-mint PDA storing the basin's current classification status under federal frameworks plus the authorized Classification relay's Ed25519-signed attestation. Seed: `[b"classification-oracle", mint]`. Owning program: `oracle_aggregator`. | §10.4 |
| **`LiquidityPool`** | Platform PDA managing the Global Unified Liquidity Pool | Singleton PDA managing the protocol-owned shared liquidity pool. Seed: `[b"liquidity-pool"]`. Owning program: `liquidity_pool`. | §14 |
### 16.15 Category 14 — Numbering Conventions for Platform Controls
The platform's 42 immutable Transfer Hook controls plus module-aware extensions follow a structured numbering convention. The category prefix indicates the control class:
| Prefix | Category | Control Range | Count |
| -------------- | --------------------- | ------------------- | ------ |
| **CV** | Custody Verification | CV-01 through CV-07 | 7 |
| **IV** | Investor Verification | IV-08 through IV-15 | 8 |
| **PL** | Position Limits | PL-16 through PL-20 | 5 |
| **CB** | Circuit Breakers | CB-21 through CB-25 | 5 |
| **HP** | Holding Period | HP-26 through HP-33 | 8 |
| **SX** | Sanctions | SX-34 through SX-37 | 4 |
| **PC** | Protective Conversion | PC-38 through PC-40 | 3 |
| **GA** | Governance & Audit | GA-41 through GA-42 | 2 |
| **TOTAL CORE** | | | **42** |
Module-aware extensions:
| Extension | Module | Trigger |
| --------------------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| **CB-21 NAV-deviation variant** | M2 | Trade price deviates from oracle NAV beyond `nav_deviation_max_bps` (default 2,200 bps = 22%) OR NAV oracle staleness exceeds reappraisal cadence |
| **REG-42 federal-action variant** | M3 | ClassificationOracle reports `federal_action_active = true`; auto-freeze with 60-minute SLA; auto-resume on `federal_action_active = false` |
Error codes follow the control numbering: error 6001 corresponds to CV-01, 6042 to GA-42, with module-aware variants using suffix codes (6021-NAV, 6042-FED).
***
### 16.16 Cross-References
* **Section 1** — Executive Summary (overview of all defined terms)
* **Section 3** — Regulatory Framework (deepest treatment of regulatory acronyms)
* **Section 5** — Solana Blockchain Foundation (deepest treatment of Solana technical acronyms)
* **Section 7** — SPL Token-2022 Transfer Hook (deepest treatment of control numbering)
* **Sections 8–10** — Module 1, 2, 3 (deepest treatment of module-specific acronyms)
* **Section 11** — Empire Stock Transfer (deepest treatment of custody acronyms)
* **Section 13** — Tokenomics (deepest treatment of internal token-class naming)
* **Section 17** — References (full citation index for every authority referenced by acronym in this section)
* **Platform Glossary** (separate document) — controlling reference for canonical platform terminology
***
*RWA Tokens Platform Whitepaper · Section 16 — Acronyms and Defined Terms · V10.0 · Groovy Company, Inc.*
**RWA Tokens Platform Whitepaper · V10.0 · May 2026** **Issued by:** Groovy Company, Inc. (Wyoming corporation; OTC: GROO; SEC EDGAR CIK 1499275) **Section classification:** Technical Specification — Reference Lexicon **Authority:** Authoritative for all defined terms used throughout this whitepaper
***
### 16.1 Scope and Reading Conventions
This section provides the authoritative lexicon for every acronym, defined term, and technical abbreviation used in this whitepaper, organized into thirteen categories. Each entry includes the expansion, an extended definition, and a cross-reference to the primary section in which the term operates. Where a term has both a colloquial usage and a precise platform usage, the platform usage controls.
**Reading conventions:**
* **Bold** terms are defined herein
* *Italic* terms are quoted directly from a federal authority (SEC, CFTC, Treasury, etc.)
* `monospace` terms are program-level identifiers, account fields, or instruction names
* All citations to "Section N" refer to sections within this whitepaper unless otherwise specified
* All citations to "ADR-NN" refer to entries in the Architecture Decisions registry (a separate platform document)
For canonical platform terminology, the **platform Glossary** (a separate, governance-controlled document) is the controlling reference. This Section 16 supports reading this whitepaper specifically; the Glossary supports the entire platform documentation suite.
### 16.2 Category 1 — Regulatory and Federal Authorities
| Acronym | Expansion | Extended Definition | Primary Section |
| ---------- | ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| **SEC** | Securities and Exchange Commission | The principal federal regulator of US securities markets. The platform operates under SEC frameworks including Release No. 33-11412 (Five-Category Taxonomy), the January 28, 2026 Joint Staff Statement on Tokenized Securities, and the April 13, 2026 Staff Statement on Covered User Interface Providers. The SEC's Division of Trading and Markets, Division of Corporation Finance, and Division of Investment Management each touch different aspects of the platform's regulatory posture. | §3, §12 |
| **CFTC** | Commodity Futures Trading Commission | The federal regulator with jurisdiction over commodity futures, swaps, and tokenized commodities. Relevant to the platform via (a) the GROO Utility Token's Category 1 (Digital Commodity) classification under Release No. 33-11412 and (b) Module 3 (CORECM) intersection with strategic-mineral commodity considerations. CFTC Letters 25-39 (2025) and 26-05 (2026) are operative guidance. | §3.7, §12 |
| **OCC** | Office of the Comptroller of the Currency | Treasury bureau regulating national banks and federal savings associations. Relevant to the platform via stablecoin issuance: OCC interpretive letters 1170, 1172, and 1174 establish national-bank authority to engage with payment stablecoin infrastructure used in the platform's settlement layer. | §15 |
| **FinCEN** | Financial Crimes Enforcement Network | Treasury bureau administering the Bank Secrecy Act (BSA). Empire Stock Transfer's investor onboarding satisfies FinCEN's Customer Identification Program (CIP) and Customer Due Diligence (CDD) Final Rule (FIN-2016-G004) requirements. | §11.2 |
| **OFAC** | Office of Foreign Assets Control | Treasury bureau administering US economic sanctions. Per-wallet OFAC / SDN screening on every ST22 transfer is enforced by Control SX-34 reading the OFAC Oracle PDA. | §3, §12 |
| **FINRA** | Financial Industry Regulatory Authority | Self-regulatory organization for broker-dealers. Relevant to Reg CF retail crowdfunding offerings, which require a FINRA-registered funding portal partner. | §8.4, §13 |
| **NIST** | National Institute of Standards and Technology | Federal standards body. Relevant to the platform's cryptographic primitive selections — Ed25519 (FIPS 186-5), SHA-256 (FIPS 180-4), and TLS 1.3 (RFC 8446). | §5, §15 |
| **USGS** | United States Geological Survey | Federal scientific agency maintaining the Critical Minerals List that informs Module 3 basin classification. The USGS list is updated approximately every three years; the current operative version determines `classification_status` field semantics for Module 3 ClassificationOracle PDAs. | §3.9, §10 |
| **DOE** | Department of Energy | Federal department maintaining the Critical Materials Strategy. Module 3 coal-derived Rare Earth Element recovery facilities operate within the DOE framework. | §3.9, §10 |
| **DPA** | Defense Production Act | Federal authority (Title III specifically) authorizing federal investment in domestic critical-minerals production. Module 3 basin assets receiving DPA Title III investment are flagged in the ClassificationOracle. | §3.9, §10 |
| **IRA** | Inflation Reduction Act | Federal legislation including critical-minerals tax-credit and supply-chain provisions. IRA eligibility status is reflected in the Module 3 ClassificationOracle `classification_status` bitfield. | §3.9, §10 |
| **EO** | Executive Order | Presidential directive carrying federal regulatory force. Executive Order 14017 ("America's Supply Chains") is relevant to Module 3 basin classification and federal-action triggers. | §3.9, §10 |
### 16.3 Category 2 — Platform Modules and Asset-Class Vehicles
| Acronym | Expansion | Extended Definition | Primary Section |
| ---------- | --------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| **M1** | Module 1 — Equities | The platform's first asset-class module. Tokenizes equity securities across OTC microcap, NASDAQ, AMEX, TSX, and global exchanges. Backing instrument: Common Class B equity custodied 1:1 by Empire Stock Transfer. Asset identifier: CUSIP. The architectural baseline — Module 1 mints set `module = 1` in SecurityConfig and use no module-aware extensions. | §8 |
| **M2** | Module 2 — Real Estate | The platform's second asset-class module. Tokenizes equity in real-property assets through the Single-Asset Entity (SAE) corporate vehicle. Module-aware extension: Control CB-21 NAV-deviation variant with default 22% tolerance band and 90-day reappraisal cadence. | §9 |
| **M3** | Module 3 — CORECM | The platform's third asset-class module. Tokenizes equity in US strategic-minerals supply-chain assets through the Basin-Asset Entity (BAE) corporate vehicle. Module-aware extension: Control REG-42 federal-action variant with automatic 60-minute SLA freeze on detection of qualifying federal action. | §10 |
| **CORECM** | Carbon Ore, Rare Earth, and Critical Minerals | The asset-class addressed by Module 3 — US strategic-minerals supply-chain assets including coal-derived Rare Earth Element recovery facilities, basin-level mining concessions, critical-minerals processing facilities, and supply-chain logistics infrastructure. The acronym is canonical platform terminology. | §10 |
| **SAE** | Single-Asset Entity | The Module 2 corporate vehicle holding a real-property asset. Typically a Nevada Limited Liability Company converted to a Nevada corporation prior to ST22 issuance, with Empire Stock Transfer custodying SAE common stock 1:1 behind issued ST22 Module 2 tokens. | §9.2 |
| **BAE** | Basin-Asset Entity | The Module 3 corporate vehicle holding a basin asset. Structured to permit Empire Stock Transfer to custody BAE common stock under §17A. Each ST22 Module 3 token is backed 1:1 by BAE common stock. | §10.2 |
| **REE** | Rare Earth Elements | The seventeen elements (lanthanides plus scandium and yttrium) classified as critical minerals under the USGS Critical Minerals List. Coal-derived REE recovery is a specific Module 3 asset category recognized under the DOE Critical Materials Strategy. | §10 |
| **CUSIP** | Committee on Uniform Securities Identification Procedures | The standard nine-character identifier for North American equity securities. Module 1 mints carry the issuer's CUSIP as the asset identifier, with Control CV-05 rejecting transfers where the bound CUSIP fails to match the custodied share class. | §8.3 |
### 16.4 Category 3 — Compliance, KYC, AML
| Acronym | Expansion | Extended Definition | Primary Section |
| -------- | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ |
| **KYC** | Know Your Customer | Investor identity verification for individual investors. Performed by Empire Stock Transfer as the sole onboarding authority across all three modules. Includes name, date of birth, address, government-ID verification, and proof-of-address documentation per FinCEN CIP requirements. | §11.2 |
| **KYB** | Know Your Business | Investor identity verification for institutional investors and corporate entities. Includes entity formation verification, beneficial-ownership identification per FinCEN CDD Final Rule, and authorized-signatory documentation. | §11.2 |
| **AML** | Anti-Money Laundering | The body of US federal regulation (Bank Secrecy Act, USA PATRIOT Act, AML/CFT statutes) governing detection and prevention of money laundering through financial institutions. The platform's three-tier AML screening uses Chainalysis KYT and TRM Labs forensics. | §3, §11.2, §12.3 |
| **BSA** | Bank Secrecy Act | The 1970 federal statute (31 U.S.C. §5311 *et seq.*) requiring financial institutions to assist federal authorities in detecting and preventing money laundering. Foundation of Empire Stock Transfer's AML compliance program. | §11.2 |
| **CIP** | Customer Identification Program | FinCEN regulation (31 C.F.R. §1020.220) implementing BSA Section 326 requirements for financial-institution customer identity verification. The framework underlying Empire's investor identity verification across all three modules. | §11.2 |
| **CDD** | Customer Due Diligence | FinCEN Final Rule (31 C.F.R. §1010.230) requiring beneficial-ownership identification for legal-entity customers. Operative for Empire's KYB process. | §11.2 |
| **SDN** | Specially Designated Nationals | OFAC's list of sanctioned individuals, entities, and addresses. Per-wallet SDN screening on every ST22 transfer via Control SX-34 reading a Bloom filter of sanctioned addresses maintained in the OFAC Oracle PDA. | §12.2 |
| **KYT** | Know Your Transaction | Chainalysis's transaction-monitoring platform integrating with the platform's AML Oracle for per-wallet risk assessment. | §12.3 |
| **EDD** | Enhanced Due Diligence | The deeper-investigation regime applied to investors flagged by initial KYC / KYB / AML screening. Empire Stock Transfer escalates EDD cases through internal compliance review. | §11.2 |
| **SAR** | Suspicious Activity Report | FinCEN-defined report (31 C.F.R. §1020.320) filed for transactions of $5,000+ meeting BSA criteria for suspicious activity. Empire Stock Transfer files SARs as required; the Layer 9 IDOS module surfaces candidate cases for Empire compliance review. | §16 (Layer 9 IDOS) |
| **FATF** | Financial Action Task Force | The intergovernmental body setting international AML/CFT standards. The FATF "high-risk" jurisdiction list informs Empire's enhanced-due-diligence procedures. | §11.2 |
| **FCPA** | Foreign Corrupt Practices Act | US statute (15 U.S.C. §§78dd-1 *et seq.*) prohibiting corrupt payments to foreign officials. Relevant to issuer KYB review for non-US issuers. | §11.2 |
### 16.5 Category 4 — Token Standards and Smart-Contract Frameworks
| Acronym | Expansion | Extended Definition | Primary Section |
| ---------- | --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| **SPL** | Solana Program Library | The reference implementation library of Solana's standard programs. The platform uses SPL Token-2022 (program ID `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHCBxGTJSAGkSm`) as the underlying token program for all ST22 mints. | §5.5 |
| **ST22** | (Per-issuer) Digital Securities tokenization product line | The platform's ST22 product is a per-issuer per-module tokenization standard built on SPL Token-2022 with the Transfer Hook extension. The "22" derives from "Token-2022." Each ST22 mint is a separate Token-2022 mint with its own SecurityConfig PDA. | §1, §7 |
| **STO** | Security Token Offering | A regulated securities offering in tokenized form. The Groovy Security Token (STO) is the platform operator's $20M Reg D offering of Common Class B equity in Groovy Company, Inc. itself. | §4.2 |
| **ERC** | Ethereum Request for Comments | Ethereum's standards-track proposal mechanism. ERC-3643 (also known as the T-REX standard) is the EVM ecosystem's compliance-overlay token standard, contrasted with ST22 in Section 14. | §14 |
| **ERC-20** | Ethereum Request for Comments 20 | The base fungible-token standard on Ethereum. ERC-3643 layers compliance overlays atop ERC-20; the architectural risk is that direct calls to underlying ERC-20 functions can bypass the ERC-3643 overlay. | §14, §15 |
| **EIP** | Ethereum Improvement Proposal | Ethereum's improvement-proposal mechanism. EIP-3643 is the formal specification of the T-REX security-token standard. | §14 |
| **T-REX** | Token for Regulated EXchanges | The colloquial name for the ERC-3643 standard, originated by Tokeny Solutions. Used interchangeably with ERC-3643 throughout this whitepaper. | §14 |
| **SBF** | Solana BPF Format | The instruction-set-architecture intermediate representation used by Solana programs. The Certora Prover verifies the platform's SBF artifacts directly. | §5, §15.3 |
| **BPF** | Berkeley Packet Filter | The instruction set on which SBF is based. Solana programs are compiled to SBF, a Solana-specific evolution of BPF. | §5 |
| **CPI** | Cross-Program Invocation | Solana's primitive for one program to call another. The Token-2022 program invokes the platform's `transfer_hook` program via CPI on every transfer of a hook-extended mint. | §5.5, §7 |
### 16.6 Category 5 — Solana Blockchain Technical
| Acronym | Expansion | Extended Definition | Primary Section |
| ------------ | ---------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| **PoH** | Proof-of-History | Solana's Verifiable Delay Function-based cryptographic clock. Provides verifiable wall-clock ordering of events without requiring inter-node communication. | §5.3.1 |
| **PoS** | Proof-of-Stake | Solana's stake-based validator selection mechanism, layered with PoH and Tower BFT consensus. | §5.3.2 |
| **BFT** | Byzantine Fault Tolerance | The class of consensus protocols tolerating arbitrary (Byzantine) validator failures up to a threshold. Tower BFT is Solana's PBFT-derived implementation. | §5.3.2 |
| **TPS** | Transactions Per Second | Standard throughput metric. Solana's theoretical 65,000 TPS contrasts with the platform's compliance-verified throughput of 400–600 TPS for ST22 trades (bottleneck: hook execution + Ed25519 verification per trade). | §5.8 |
| **CU** | Compute Unit | Solana's unit of program-execution accounting. Per-transfer compute consumption: M1 \~800K CU, M2 \~820K CU, M3 \~830K CU; CEDEX swap path adds \~150K CU. | §5.7 |
| **PDA** | Program Derived Address | A Solana account address deterministically derived from seeds and a program ID via `find_program_address`. Off-curve property guarantees no private key can sign for the address. The platform's compliance state lives entirely in PDAs. | §5.4 |
| **VDF** | Verifiable Delay Function | The cryptographic primitive underlying PoH. Provides a function whose output requires a known minimum amount of sequential computation, with the output verifiable in time independent of computation. | §5.3.1 |
| **SHA-256** | Secure Hash Algorithm 256-bit | The cryptographic hash function used in Solana's PoH chain. NIST FIPS 180-4. | §5.3.1 |
| **Ed25519** | Edwards-curve Digital Signature Algorithm with 25519 prime | The cryptographic signature scheme used for Empire custody attestation, NAV oracle attestation (M2), Classification oracle attestation (M3), and OFAC oracle attestation. NIST FIPS 186-5. Verified by Solana's native Ed25519 precompile (\~600 CU per verification). | §5.3.3 |
| **RPC** | Remote Procedure Call | Solana's standard interface for off-chain clients to query on-chain state and submit transactions. The platform operates dedicated Helius RPC capacity (500+ req/sec) with Triton failover. | §5.9.1 |
| **MEV** | Maximum Extractable Value (originally "Miner Extractable Value") | Value extracted by transaction-ordering manipulation (frontrunning, sandwiching, liquidations). All CEDEX trades route through Jito Block Engine for MEV protection. | §5.9.2, §13 |
| **gRPC** | Google Remote Procedure Call | The performant alternative to JSON-RPC used by some Solana RPC providers. Helius supports both gRPC and JSON-RPC; the platform uses gRPC for high-throughput backend paths. | §5.9.1 |
| **JSON-RPC** | JavaScript Object Notation Remote Procedure Call | The standard Solana RPC protocol. Used by the platform's investor-facing client paths. | §5.9.1 |
### 16.7 Category 6 — Oracle and Network Infrastructure
| Acronym | Expansion | Extended Definition | Primary Section |
| --------- | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- |
| **TWAP** | Time-Weighted Average Price | Average price weighted by time interval. The TWAP Oracle (sourced from Pyth Network) is read by Control CB-22 (price-impact circuit breaker) to detect trades deviating more than 2% from TWAP. | §12.4 |
| **NAV** | Net Asset Value | The Module 2-specific concept of underlying property value per token. Per-mint NAV Oracle PDA stores authorized appraiser's Ed25519-signed NAV attestation. Default reappraisal cadence: 90 days. | §9, §12.6 |
| **EDGAR** | Electronic Data Gathering, Analysis, and Retrieval | SEC's filing system. EDGAR Oracle (Module 1-specific) surfaces issuer 10-K, 10-Q, 8-K filings for Layer 9 IDOS distress-signal generation. | §12.5, §16 (IDOS) |
| **CIK** | Central Index Key | SEC EDGAR's unique identifier for filing entities. Groovy Company, Inc.'s CIK is **1499275**. CIK is the seed for the EDGAR Oracle PDA derivation. | §12.5 |
| **NDA** | Non-Disclosure Agreement | The platform's Global NDA template governs confidential issuer engagements pre-onboarding. | §11 |
### 16.8 Category 7 — Settlement and Stablecoin
| Acronym | Expansion | Extended Definition | Primary Section |
| -------------- | ---------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| **GENIUS Act** | Generation of Enabling and National Innovation in U.S. Stablecoins Act | Federal stablecoin legislation establishing the compliance framework for payment stablecoin issuers. The platform settles all ST22 purchases in USDC or PYUSD under this framework. | §15 |
| **USDC** | USD Coin | The Circle-issued payment stablecoin used as primary settlement currency on the platform. 1:1 USD-backed with monthly attestation of dollar reserves. | §15 |
| **PYUSD** | PayPal USD | The Paxos-issued payment stablecoin available as alternative settlement currency. 1:1 USD-backed with monthly attestation. | §15 |
| **GAAP** | Generally Accepted Accounting Principles | The US accounting standards body governing financial reporting. Relevant to the platform's intangible-asset valuation (ASC 350 / ASC 985 software valuation methodology). | §13 |
### 16.9 Category 8 — Trading and Market Microstructure
| Acronym | Expansion | Extended Definition | Primary Section |
| --------- | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------- |
| **CEDEX** | Compliant Exchange for Digital Securities | The platform-operated trading venue at cedex.market. The only legitimate trading venue for ST22 mints across all three modules. Operates 24/7/365 with permanent protocol-owned liquidity from the Global Unified Liquidity Pool. | §13 |
| **AMM** | Automated Market Maker | The class of algorithmic market-making protocols. CEDEX's matching engine implements a custom CPMM AMM purpose-built around Token-2022 hook semantics. | §13 |
| **CPMM** | Constant Product Market Maker | The AMM model with invariant `x × y = k`. CEDEX's settlement layer is a custom CPMM with `u128` overflow-safe arithmetic. | §13.4 |
| **CLMM** | Concentrated Liquidity Market Maker | The Uniswap V3-derived AMM model with liquidity concentrated in price ranges. Not used by the platform — CPMM is the chosen model. | §13 |
| **DEX** | Decentralized Exchange | A class of trading venues operating without centralized intermediation. The October 2025 GROO beta empirically validated that external DEXs (Raydium, Orca, Jupiter) cannot host ST22 mints — see §15.5.1. | §13.2, §15.5 |
| **ATS** | Alternative Trading System | An SEC-regulated trading venue alternative to a national securities exchange. Securitize Markets is an ATS; the architectural comparison vs CEDEX is documented in §13.11. | §13.11 |
| **OTC** | Over-the-Counter | The dealer-network market for securities not traded on national exchanges. OTC microcap is a primary Module 1 addressable surface. | §2, §8 |
| **OTCID** | OTC Markets Group Current OTC Tier | OTC Markets Group's current OTC market tier label. | §2 |
| **LP** | Liquidity Provider | A party providing liquidity to an AMM in exchange for LP tokens representing pro-rata pool ownership. The Global Unified Liquidity Pool's LP tokens are burned at inception, mathematically preventing withdrawal — Certora invariant E.3. | §14, §15.3.2 |
| **MM** | Market Maker | A party providing two-sided quotes on a trading venue. Traditional ATS architectures rely on per-issuer market makers ($5K–$20K/month subsidies); the platform's shared Global Pool architecture eliminates this requirement. | §13.11 |
### 16.10 Category 9 — Custody, Transfer Agency, and Corporate Governance
| Acronym | Expansion | Extended Definition | Primary Section |
| --------- | -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| **§17A** | Section 17A of the Securities Exchange Act of 1934 | The federal statutory authority under which Empire Stock Transfer is registered as a transfer agent and qualified custodian. The architectural anchor for Pillar 3 of Category 1 Model B. | §11 |
| **MSF** | Master Securityholder File | The legally controlling shareholder register maintained by Empire Stock Transfer under §17A. Reconciled to the on-chain SPL Token-2022 ledger every Solana slot via Ed25519 attestation. | §11.4 |
| **PPM** | Private Placement Memorandum | The offering document for Reg D and similar private offerings. The Groovy Security Token (STO) is offered pursuant to a PPM. | §13 |
| **DTC** | Depository Trust Company | The traditional US securities clearing and settlement infrastructure. Module 1 ST22 tokens reference issuer CUSIPs that may also have DTC-eligible representations; the platform's on-chain ledger functions as the transfer notification layer per Wyoming W\.S. 34-29-101. | §3.4, §11.4 |
| **UCC** | Uniform Commercial Code | State-law commercial code adopted (with variations) by all 50 states. UCC Article 8 ("Investment Securities") supplies the legal framework for the transfer-notification architecture by which ST22 transfers constitute effective instructions to Empire. | §3.4 |
| **W\.S.** | Wyoming Statutes | Wyoming's codified state law. **W\.S. 34-29-101** *et seq.* is Wyoming's digital asset statute providing legal recognition of digital asset transfers and property rights. | §3.4 |
### 16.11 Category 10 — Federal Critical-Minerals Frameworks (Module 3)
| Acronym | Expansion | Extended Definition | Primary Section |
| ----------------- | ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| **§232** | Section 232 of the Trade Expansion Act of 1962 | Federal authority (19 U.S.C. §1862) authorizing tariffs and import restrictions on national-security grounds. Section 232 actions affecting basin commodity inputs trigger the Module 3 ClassificationOracle's `federal_action_active` field, invoking Control REG-42. | §3.9, §10.6 |
| **EO 14017** | Executive Order 14017 — America's Supply Chains | Presidential directive (February 24, 2021) addressing US supply-chain resilience including critical minerals. Module 3 basin classification reflects EO 14017 priority designations. | §3.9, §10 |
| **DPA Title III** | Defense Production Act, Title III | Federal authority (50 U.S.C. §4533) for federal investment in domestic critical-minerals production. Module 3 BAEs receiving DPA Title III investment are flagged in the ClassificationOracle. | §3.9, §10 |
| **IRA §13502** | Inflation Reduction Act, Section 13502 | Critical-minerals tax-credit provision. Eligibility status reflected in Module 3 ClassificationOracle `classification_status` bitfield. | §3.9, §10 |
| **Energy Act** | Energy Act of 2020 | Federal legislation (42 U.S.C. §16391 *et seq.*) establishing critical-minerals research and innovation programs. Module 3 BAE eligibility status tracked via ClassificationOracle. | §3.9, §10 |
| **DLA** | Defense Logistics Agency | Federal agency operating the National Defense Stockpile. Module 3 basin assets supplying the National Defense Stockpile are flagged in the ClassificationOracle. | §10 |
| **BLM** | Bureau of Land Management | Federal agency administering mining concessions on federal land. Module 3 basin asset identifiers may reference BLM concession IDs. | §10.3 |
### 16.12 Category 11 — Internal Platform Naming
| Acronym | Expansion | Extended Definition | Primary Section |
| -------- | --------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ |
| **GROO** | (Platform ecosystem token; OTC ticker for Groovy Company, Inc.) | Two distinct uses: (a) the OTC ticker symbol of Groovy Company, Inc. on US OTC markets; (b) the platform's GROO Utility Token — Release No. 33-11412 Category 1 (Digital Commodity) or Category 3 (Digital Tool), distributed via deterministic linear bonding curve. Not interchangeable with the Groovy Security Token (STO) or with ST22 Digital Securities. | §4.1, §13.2 |
| **IDOS** | Issuer Distress and Opportunity Score | The Layer 9 off-chain compliance intelligence module. Aggregates EDGAR filings (M1), NAV deviation history (M2), Classification oracle history (M3), on-chain trading activity, and wallet behavioral signals into per-issuer risk and opportunity scores. Does not modify on-chain compliance enforcement. | §16 (in body), §15 |
| **ADR** | Architecture Decision Record | Versioned platform document recording an architectural decision, its context, alternatives considered, and rationale. ADR-001 through ADR-013+ are referenced throughout this whitepaper. | All sections |
| **MSPC** | Multi-Stage Protocol Calibration | The November 2025 beta validating RPC capacity and copycat-token resilience. | §15.5.2 |
| **GRLF** | Gradual Real-Liquidity Float | The December 1–3, 2025 beta validating unauthorized LP creation and bot-share dynamics. | §15.5.3 |
| **RTO** | Recovery Time Objective | Disaster-recovery metric: maximum acceptable time to restore a service after an outage. Documented per scenario in §15.7.3. | §15.7.3 |
| **RPO** | Recovery Point Objective | Disaster-recovery metric: maximum acceptable data loss measured by time. The platform's audit-trail RPO is zero (immutable Solana ledger). | §15.7.3 |
| **SLA** | Service-Level Agreement (Service-Level Objective) | A defined operational-performance target. The Module 3 Control REG-42 federal-action variant has a 60-minute SLA from federal-action detection to on-chain freeze. | §10.5 |
### 16.13 Category 12 — Offering Exemptions and Investor Classifications
| Acronym | Expansion | Extended Definition | Primary Section |
| ------------ | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| **Reg D** | Regulation D | SEC regulation (17 C.F.R. §§230.500–508) providing exemptions from registration for private placements. The platform's primary exemption regime for US accredited-investor offerings, with 6-month holding period enforced on-chain by Control HP-24. | §3.6, §8.4 |
| **Reg S** | Regulation S | SEC regulation (17 C.F.R. §§230.901–905) providing safe harbors for offshore securities offerings to non-US persons. The platform's primary exemption regime for non-US investor offerings, with 12-month distribution-compliance period enforced on-chain. | §3.6, §8.4 |
| **Reg CF** | Regulation Crowdfunding | SEC regulation (17 C.F.R. §227.100 *et seq.*) implementing JOBS Act §4(a)(6) for retail-investor crowdfunding. The platform's exemption regime for US retail offerings, requiring a FINRA-registered funding portal partner. | §3.6, §8.4, §13 |
| **Reg A** | Regulation A | SEC regulation permitting limited public offerings up to $75M annually to non-accredited investors. Available as an alternative offering exemption regime within the platform's compliance architecture; not the primary path. | §3.6 |
| **JOBS Act** | Jumpstart Our Business Startups Act | The 2012 federal statute creating Reg CF and modifying multiple SEC exemption regimes. §4(a)(6) is the statutory authority for Reg CF. | §3.6 |
| **15c2-11** | SEC Rule 15c2-11 | SEC rule (17 C.F.R. §240.15c2-11) governing market-maker quotation requirements for OTC securities. Relevant to Module 1 OTC microcap context as one of the historical drivers of OTC microcap market structure. | §2 |
| **10b-5** | SEC Rule 10b-5 | SEC anti-fraud rule (17 C.F.R. §240.10b-5) prohibiting fraud and market manipulation in securities transactions. Universally applicable to all platform-facilitated transactions. | §3 |
| **13d-3** | SEC Rule 13d-3 | SEC rule (17 C.F.R. §240.13d-3) defining beneficial ownership for disclosure requirements. Relevant to the platform's wallet-cap enforcement (Controls PL-16 through PL-20). | §7.1 |
| **Rule 144** | SEC Rule 144 | SEC rule (17 C.F.R. §230.144) governing resale of restricted securities after specified holding periods. Directly implemented by Transfer Hook Control HP-24 / HP-26 holding-period enforcement on Reg D issuances. | §3.6, §7.1 |
### 16.14 Category 13 — Token-2022 Extensions and Specific Programs
| Acronym | Expansion | Extended Definition | Primary Section |
| -------------------------- | ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| **`TransferHook`** | SPL Token-2022 Transfer Hook Extension | The Token-2022 extension binding a hook program to a mint such that every transfer instruction invokes the hook. The architectural primitive enabling the platform's runtime-enforced compliance. | §5.5, §7 |
| **`MintCloseAuthority`** | SPL Token-2022 Mint Close Authority Extension | Token-2022 extension permitting the mint to be closed. Disabled on all platform mints to protect the 1:1 backing invariant. | §5.5.2 |
| **`ConfidentialTransfer`** | SPL Token-2022 Confidential Transfer Extension | Token-2022 extension supporting privacy-preserving transfers. Disabled on platform mints — conflicts with Empire MSF reconciliation transparency. | §5.5.2 |
| **`CpiGuard`** | SPL Token-2022 CPI Guard Extension | Token-2022 extension preventing accidental CPI-driven debits. Enabled on issuer treasury PDAs. | §5.5.2 |
| **`ImmutableOwner`** | SPL Token-2022 Immutable Owner Extension | Token-2022 extension preventing account-owner reassignment. Enabled on AMM market accounts. | §5.5.2 |
| **`MetadataPointer`** | SPL Token-2022 Metadata Pointer Extension | Token-2022 extension permitting issuer-supplied metadata URI. Optional per mint. | §5.5.2 |
| **`SecurityConfig`** | Platform PDA storing per-mint compliance parameters | The per-mint PDA encoding all 42 control parameters plus module-aware extension fields. Seed: `[b"security-config", mint]`. Owning program: `transfer_hook`. | §5.4.2, §7 |
| **`HoldingPeriodAccount`** | Platform PDA storing per-investor-mint holding period state | Per-investor-mint PDA enforcing Reg D / Reg S / Reg CF holding periods on-chain. Seed: `[b"holding-period", mint, beneficiary]`. Owning program: `transfer_hook`. | §5.4.2, §7 |
| **`CustodyOracle`** | Platform PDA storing Empire's custody attestation | Per-mint PDA storing Empire's most recent Ed25519-signed custody attestation. Seed: `[b"custody-oracle", mint]`. Owning program: `oracle_aggregator`. | §11.3 |
| **`NavOracle`** | Platform PDA storing authorized appraiser's NAV attestation (M2) | Per-mint PDA storing authorized appraiser's Ed25519-signed NAV attestation for Module 2. Seed: `[b"nav-oracle", mint]`. Owning program: `oracle_aggregator`. | §9.3 |
| **`ClassificationOracle`** | Platform PDA storing federal classification status (M3) | Per-mint PDA storing the basin's current classification status under federal frameworks plus the authorized Classification relay's Ed25519-signed attestation. Seed: `[b"classification-oracle", mint]`. Owning program: `oracle_aggregator`. | §10.4 |
| **`LiquidityPool`** | Platform PDA managing the Global Unified Liquidity Pool | Singleton PDA managing the protocol-owned shared liquidity pool. Seed: `[b"liquidity-pool"]`. Owning program: `liquidity_pool`. | §14 |
### 16.15 Category 14 — Numbering Conventions for Platform Controls
The platform's 42 immutable Transfer Hook controls plus module-aware extensions follow a structured numbering convention. The category prefix indicates the control class:
| Prefix | Category | Control Range | Count |
| -------------- | --------------------- | ------------------- | ------ |
| **CV** | Custody Verification | CV-01 through CV-07 | 7 |
| **IV** | Investor Verification | IV-08 through IV-15 | 8 |
| **PL** | Position Limits | PL-16 through PL-20 | 5 |
| **CB** | Circuit Breakers | CB-21 through CB-25 | 5 |
| **HP** | Holding Period | HP-26 through HP-33 | 8 |
| **SX** | Sanctions | SX-34 through SX-37 | 4 |
| **PC** | Protective Conversion | PC-38 through PC-40 | 3 |
| **GA** | Governance & Audit | GA-41 through GA-42 | 2 |
| **TOTAL CORE** | | | **42** |
Module-aware extensions:
| Extension | Module | Trigger |
| --------------------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| **CB-21 NAV-deviation variant** | M2 | Trade price deviates from oracle NAV beyond `nav_deviation_max_bps` (default 2,200 bps = 22%) OR NAV oracle staleness exceeds reappraisal cadence |
| **REG-42 federal-action variant** | M3 | ClassificationOracle reports `federal_action_active = true`; auto-freeze with 60-minute SLA; auto-resume on `federal_action_active = false` |
Error codes follow the control numbering: error 6001 corresponds to CV-01, 6042 to GA-42, with module-aware variants using suffix codes (6021-NAV, 6042-FED).
***
### 16.16 Cross-References
* **Section 1** — Executive Summary (overview of all defined terms)
* **Section 3** — Regulatory Framework (deepest treatment of regulatory acronyms)
* **Section 5** — Solana Blockchain Foundation (deepest treatment of Solana technical acronyms)
* **Section 7** — SPL Token-2022 Transfer Hook (deepest treatment of control numbering)
* **Sections 8–10** — Module 1, 2, 3 (deepest treatment of module-specific acronyms)
* **Section 11** — Empire Stock Transfer (deepest treatment of custody acronyms)
* **Section 13** — Tokenomics (deepest treatment of internal token-class naming)
* **Section 17** — References (full citation index for every authority referenced by acronym in this section)
* **Platform Glossary** (separate document) — controlling reference for canonical platform terminology
***
*RWA Tokens Platform Whitepaper · Section 16 — Acronyms and Defined Terms · V10.0 · Groovy Company, Inc.*