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:

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<u64> {
    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

// 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.

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.