Section 5: Custom AMM Engine & CEDEX — Layers 4 and 5

📈OTCM ThePROTOCOL Comprehensive Technical Whitepaper  —  Version 7.0 ST22 Digital Securities Platform  |  March 2026  |  Groovy Company, Inc. dba OTCM tradingProtocol interface

 

Section 5: Custom AMM Engine & CEDEX — aLayers 4 and 5

Layer 4 provides the mathematical trading engine that powers all ST22 secondary market activity. Layer 5 — CEDEX — is the purpose-built Centralized-DecentralizedCompliant Exchange combiningfor Digital Securities that combines Web2 order matching with Web3 settlement finality, natively supportingenforcing all 42 Transfer Hook security controls on every trade.

 

Layer	Component	Function
Layer 4	Custom AMM Engine	Constant Product Market Maker (CPMM) operating against the Global Unified CEDEX Liquidity Pool — purpose-built for SPL Token-2022 Transfer Hook compatibility
Layer 5	CEDEX	Compliant Exchange for Digital Securities — dual-layer execution: centralized order matching + decentralized Solana settlement with full 42-control Transfer Hook enforcement

 

PART A — LAYER 4: CUSTOM AMM ENGINE

 

5.1  Why a Custom AMM Is Required

The Custom AMM Engine exists because every major decentralized exchange on Solana — Raydium, Orca, Jupiter, Meteora — was built before SPL Token-2022 Transfer Hooks forexisted. Their smart contracts interact directly with the original SPL Token Program, which lacks Transfer Hook extensions. This is not a configuration gap. It is a fundamental architectural incompatibility.

When an ST22 token is transferred through any external DEX, the DEX's swap program calls the Token Program directly, bypassing the Transfer Hook entirely. This would disable all 42 security controls — including the Empire Stock Transfer custody verification, OFAC/SDN screening, AML risk scoring, accreditation check, and the Rule 144 / Reg S holding period enforcement — on every trade. The token would cease to be a compliant Digital Security at the moment of its first exchange-executed trade.

 

DEX Platform	Token-2022 Support	Transfer Hook Support	ST22 Compatible?
Raydium	Partial — basic transfers only	None — hooks disabled at swap	No
Orca	Limited — whitelist	None — not implemented	No
Jupiter	Aggregates underlying DEXs	None — inherits DEX limitations	No
Meteora	Basic support	None — bypassed	No
CEDEX (OTCM Protocol)	Full native support	Full — all 42 controls per transfer	Yes — only compliant venue

 

Critical: SEC Compliance Consequence If ST22 Digital Securities compliance.tokens were traded on external DEXs, Transfer Hooks would be bypassed during swap execution. This would disable custody verification (Control 1), OFAC/SDN screening (Controls 8–10), AML scoring (Control 11), accreditation verification (Control 12), and the Rule 144 / Reg S holding period lock (Control 24) — making the tokens non-compliant Digital Securities under SEC Release No. 33-11412 and the January 28, 2026 Joint Staff Statement.

 

💡5.2  Custom AMM Architecture

5.2.1  Constant Product Market Maker (CPMM) — Mathematical Foundation

The Custom AMM implements the Constant Product Market Maker formula (x × y = k), operating against the Global Unified CEDEX Liquidity Pool. The CPMM provides continuous, algorithmically determined pricing without requiring traditional order books or external market makers. Pricing is entirely a function of pool reserve ratios — as one asset is bought, it becomes more expensive; as it is sold, it becomes cheaper.

 

Variable	Definition
x	SOL reserve in the Global Unified CEDEX Liquidity Pool
y	ST22 token reserve in the pool for the given issuer
k	Constant product invariant — maintained (or increased by fees) after every swap
fee	5% protocol fee (500 bps) — applied before invariant calculation, ensuring k grows with every trade

 

Example swap — buying ST22 tokens with 10 SOL from a pool with 100 SOL and 1,000,000 token reserves:

 

Initial state:  x = 100 SOL  |  y = 1,000,000 tokens  |  k = 100,000,000   Input: 10 SOL  →  after 5% fee: 9.5 SOL effective input   new_x = 100 + 9.5 = 109.5 SOL new_y = k / new_x = 100,000,000 / 109.5 = 913,242 tokens   tokens_received = 1,000,000 - 913,242 = 86,758 tokens effective_price  = 10 SOL / 86,758 tokens = 0.0001153 SOL/token   k_after = 109.5 × 913,242 = 99,999,999 ≥ original k  ✓  invariant preserved

 

5.2.2  u128 Overflow-Safe Arithmetic

The CPMM formula requires multiplying two u64 reserve values. The maximum u64 value is 2⁤ − 1 ≈ 18.4 × 10¹⁸. Multiplying two maximum u64 values produces a value requiring 128 bits. All intermediate CPMM calculations use u128 arithmetic to prevent overflow:

 

pub fn calculate_output_amount(     input_amount:   u64,     input_reserve:  u64,     output_reserve: u64,     fee_bps:        u16,  // 500 = 5% ) -> Result<SwapResult> {     // Apply fee BEFORE invariant calculation     let fee_multiplier    = (10_000 - fee_bps as u64) as u128;     let input_with_fee    = (input_amount as u128)         .checked_mul(fee_multiplier)         .ok_or(SwapError::Overflow)?;       // u128 intermediate — prevents overflow on large reserves     let numerator         = input_with_fee         .checked_mul(output_reserve as u128)         .ok_or(SwapError::Overflow)?;     let denominator       = (input_reserve as u128)         .checked_mul(10_000)         .ok_or(SwapError::Overflow)?         .checked_add(input_with_fee)         .ok_or(SwapError::Overflow)?;       // Floor rounding — trader receives slightly less, k never decreases     let output_amount     = (numerator / denominator) as u64;       Ok(SwapResult { output_amount,         new_input_reserve:  input_reserve  + input_amount,         new_output_reserve: output_reserve - output_amount }) }

 

5.2.3  Rounding Policy

Operation	Rounding Direction	Rationale
amount_out calculation	Floor (truncate)	Trader receives slightly less — protocol never over-pays. Ensures k can only increase.
amount_in (exact output)	Ceiling	Trader pays slightly more — protocol never under-receives.
Fee calculation	Floor	Slightly less fee collected — conservative accounting.
LP share calculation	Floor	LP receives slightly less — prevents LP share inflation.

 

Invariant Guarantee Floor rounding on amount_out ensures new_k ≥ old_k after every swap. The product invariant can only increase or remain equal — it can never decrease. Because the 5% fee increases the effective input before the invariant calculation, k grows with every trade. The Global Unified CEDEX Liquidity Pool mathematically deepens with every ST22 transaction.

 

5.2.4  Maximum Safe Operating Parameters

Parameter	Maximum Safe Value	Notes
Single reserve	10¹⁵ tokens (u64)	Beyond this, consider reserve splitting
Single swap amount	20% of reserve	Circuit breaker enforces via Transfer Hook Control 16
k value	~10³⁰	Well within u128 range (3.4 × 10³⁸)
Cumulative k growth	Unbounded	k can only grow — no maximum, reflects permanent pool deepening

 

5.3  GROO Token Bonding Curve — GROO Only

The bonding curve price discovery mechanism applies exclusively to the GROO token — Groovy Company, Inc.'s own ST22 token. It does not apply to third-party issuer ST22 tokens. Third-party issuers distribute 100% of their tokens to verified accredited investors through Regulation D 506(c) private placements and trade directly against the Global Unified CEDEX Liquidity Pool via the CPMM upon the conclusion of their holding period.

 

Scope: GROO Token Only Sections 5.3.1 through 5.3.4 describe the bonding curve mechanics that govern the GROO token's initial price discovery phase. These mechanics do not apply to any other ST22 issuer. Third-party ST22 issuers have no bonding curve phase. Their tokens trade via the CPMM against the Global Unified CEDEX Liquidity Pool immediately upon completion of the Rule 144 / Reg S holding period.

 

5.3.1  Linear Bonding Curve Mathematics

The GROO token's bonding curve implements a linear formula providing predictable price appreciation as adoption increases:

 

P(n) = initialPrice + (priceGradient × tokensIssued)   Where:   initialPrice   = 0.000001 SOL  (1,000 lamports)   priceGradient  = 0.0000000079 SOL per token issued   tokensIssued   = current circulating supply   pub struct BondingCurve {     pub token_mint:           Pubkey,     pub initial_price:        u64,   // lamports     pub price_gradient:       u64,   // lamports per token     pub tokens_issued:        u64,   // current supply     pub sol_reserve:          u64,   // SOL collected     pub is_graduated:         bool,     pub graduation_timestamp: Option<i64>, }

 

5.3.2  GROO Graduation Criteria

The GROO token graduates from bonding curve to permanent CPMM trading upon satisfying any one of three criteria (OR logic):

 

Criterion	Threshold	Rationale
Market Cap	≥ $250,000 USD	Sufficient liquidity depth for stable CPMM operation
Holder Count	≥ 127,000 unique wallets	~0.5% of Solana active wallets — proof of genuine community adoption
Time Elapsed	≥ 72 hours since deployment	Minimum stabilization period regardless of volume

 

5.3.3  Graduation State Transition

Upon meeting any graduation criterion, the following irreversible state transitions execute atomically:

 

•       Bonding curve deactivation — Smart contract permanently disables bonding curve purchase and sale functions through an immutable state flag — enforced at bytecode level, not through administrative controls

•       Liquidity migration — All SOL accumulated in the bonding curve reserve transfers to the Global Unified CEDEX Liquidity Pool

•       CPMM pool initialization — CPMM pool initializes with the graduated token supply and migrated SOL reserve. liquidity_locked = true — permanent and immutable

•       Secondary trading activation — GROO tokens are now tradeable via CPMM on CEDEX with the same 42 Transfer Hook controls enforced on every transfer

 

pub fn execute_graduation(ctx: Context<Graduate>) -> Result<()> {     let curve = &mut ctx.accounts.bonding_curve;       require!(         curve.check_graduation_criteria()?,         CedexError::GraduationCriteriaNotMet     );       // Permanently disable bonding curve     curve.is_graduated         = true;     curve.graduation_timestamp = Some(Clock::get()?.unix_timestamp);       // Migrate all SOL to Global Unified CEDEX Liquidity Pool     let pool = &mut ctx.accounts.cedex_pool;     pool.sol_reserve      = curve.sol_reserve;     pool.token_reserve    = curve.tokens_issued;     pool.k_invariant      = pool.sol_reserve * pool.token_reserve;     pool.liquidity_locked = true;  // PERMANENT — cannot be unlocked       transfer_sol(curve.sol_reserve, &ctx.accounts.pool_vault)?;       emit!(GraduationComplete {         token_mint:      curve.token_mint,         sol_migrated:    curve.sol_reserve,         final_market_cap: calculate_market_cap(curve),     });     Ok(()) }

 

PART B — LAYER 5: CEDEX — COMPLIANT EXCHANGE FOR DIGITAL SECURITIES

 

5.4  CEDEX Architectural Innovation

CEDEX (Centralized-Decentralized— Exchange)Compliant represents a fundamental reimagining of decentralized exchange architecture, purpose-built from inceptionExchange for trading Digital Securities within federal securities law frameworks. Under the SEC's March 17, 2026 interpretation (Release No. 33-11412), ST22 tokens are formally classified as Digital Securities — financialis instrumentsthe formattedexclusive astrading cryptovenue assetsfor withall ownershipST22 recordedtokens. on a crypto network. CEDEXIt is the only exchange built to enforce every compliance obligation that SEC Digital Securities classification entails on every single trade. Under the January 28, 2026 Joint Staff Statement and Release No. 33-11412, ST22 tokens are Digital Securities. Their trading venue must be capable of enforcing the compliance obligations that status entails. CEDEX was built to be that venue.

Unlike existing DEX platforms designed for permissionless cryptocurrency trading, CEDEX implements compliance verification as a foundational architectural constraint rather than retrofitted functionality.

🔹

5.1.1The DEX Incompatibility Problem

Standard decentralized exchanges — including market leaders Raydium, Orca, Jupiter, and Meteora — were architected around three foundational design principles that create irreconcilable conflict with securities law compliance:

Principle 1: Computational Minimalism Traditional DEXs optimize for maximum throughput by minimizing computational overhead per transaction. A typical Raydium swap executes in approximately 200,000 compute units; adding six Transfer Hook verifications increases this to 800,000+ compute units — fundamentally changing the economic model.

Principle 2: Compliance Agnosticism DEX protocols intentionally refuse implementation of securities-specific procedures such as KYC verification, accreditation checking, OFAC screening, and investor qualification. This reflects ideological commitment to permissionless trading and practical recognition that compliance creates liability exposure for protocol developers.

Principle 3: Economic Incentive Misalignment Traditional DEX economics depend on maximizing trading volume with minimal friction. Compliance verification introduces latency, integration complexity, and oracle costs — factors that directly reduce profitability under existing DEX business models.

💡 Critical Insight: The incompatibility between existing DEXs and Digital Securities compliance is not a technical limitation that can be solved with additional development. It represents a fundamental architectural conflict where the design goals of permissionless trading and regulated securities trading are mutually exclusive.

---

🔹 5.1.2 Why Existing DEXs Cannot Support ST22 Tokens

"We didn't add compliance to a DEX. We built a compliance engine that happens to execute trades."

DEX Platform	Token-2022 Support	Transfer Hook Support
Raydium	Partial (basic transfers only)	None — hooks disabled
Orca	Limited (whitelist)	None — not implemented
Jupiter	Aggregates underlying DEXs	None — inherits limitations
Meteora	Basic support	None — bypassed
CEDEX	Full native support	Full — 6 hooks per transfer

Existing DEX codebases were written before SPL Token-2022 existed. Their smart contracts interact directly with the original SPL Token Program, which lacks Transfer Hook extensions. Retrofitting Transfer Hook support would require complete protocol rewrites — a multi-year effort these protocols have no economic incentive to undertake.

5.4.1⚠️  Critical Limitation: If ST22 Digital Securities tokens were traded on existing DEXs, Transfer Hooks would be bypassed during swaps. This would disable all 42 security controls — including custody verification, OFAC screening, and AML checks — making the tokens non-compliant Digital Securities.

---

🔹 5.1.3 Compliance-First vs. Compliance-Retrofitted

The distinction between compliance-first architecture and compliance-retrofitted architecture determines whether non-compliant trades can execute. CEDEX is compliance-first — it is structurally impossible for a non-compliant trade to complete:

 

	Aspect		Compliance-First (CEDEX)		Compliance-Retrofitted
Verification Timingtiming	Before execution (blocking)— blocking	After execution (— non-blocking)blocking
Non-Compliantcompliant Tradestrades	Cannot execute — structurally impossible	Execute then flag for review
Regulatory Postureposture	Preventive control	Detective control
Audit Trailtrail	Every trade verified on-chain — immutable	Off-chain logs (mutable)— mutable
System Complexitycomplexity	Integrated (— single system)compliance + trading system	Fragmented (— multiple systems)systems
Failure Modemode	Fail-safe (— no trade)trade if compliance fails	Fail-open (— trade executes)executes despite compliance failure
SEC Release 33-11412 alignment	Category 1 Model B — compliant	Category 2 exposure or non-compliant

---

 

🏗️5.5 5.2 Dual-Layer Execution Architecture

CEDEX implements a dual-layer architecture combining a centralized order management system with decentralized on-chain settlement. The centralized layer handles order matching, price discovery, and user interface at sub-100ms latency. The decentralized layer handles actual asset custody, Transfer Hook enforcement, and settlement finality on Solana.

Layer	Function	Technology
Centralized OMS	Order matching · price feeds · UI	OTCM matching engine + REST API
Compliance Verification	KYC/AML status · accreditation check	Layer 2 Transfer Hook pre-check
Decentralized Settlement	Asset transfer · Transfer Hook execution · finality	Solana + SPL Token-2022

---

🔹 5.2.1 Dual-Layer Execution Model

User Submits ST22 Trade Request
         ↓
Centralized OMS — Pre-flight compliance check
  ├── KYC status verified
  ├── Accreditation status verified
  └── AML flag check
         ↓ CLEAR
Compliance Verification Layer (750–1,350ms)
  ├── Hook 1: Custody Verification
  ├── Hook 2: OFAC Screening
  ├── Hook 3: AML Analytics
  ├── Hook 4: Redemption Eligibility
  ├── Hook 5: Price Impact Circuit Breaker
  └── Hook 6: Liquidity Pool Sufficiency
         ↓ ALL PASS
Trading Execution Layer — CPMM swap (400–600ms)
         ↓
Solana Settlement — 32 block finality (~13 seconds)
         ↓ ANY FAIL
Entire Transaction Reverts — Specific error code returned

---

🔹 5.2.2 Compliance Verification Layer

Before any trade executes on-chain, CEDEX runs a pre-flight compliance check against the investor's current verification status, querying the Issuers Portal compliance state in real-time. Traders with lapsed KYC, expired accreditation, or flagged AML status are blocked at the order entry stage — before any on-chain transaction is attempted — preventing failed transactions and wasted fees.

pub struct ComplianceVerification {
    pub transfer_id:         Pubkey,
    pub sender:              Pubkey,
    pub recipient:           Pubkey,
    pub token_mint:          Pubkey,
    pub amount:              u64,
    pub verification_start:  i64,
    pub hook_results:        [HookResult; 6],
    pub final_status:        VerificationStatus,
}

pub enum VerificationStatus {
    Pending,
    Verified,
    Rejected {
        hook_number: u8,
        error_code:  u16,
        reason:      String,
    },
}

Hook Execution Sequence:

Order	Hook Name	Oracle Source	Latency	Fail Action
1	Custody Verification	Empire Stock API	100–150ms	Revert 6001
2	OFAC Screening	SDN List Oracle	200–500ms	Revert 6002
3	AML Analytics	Chainalysis / TRM	300–400ms	Revert 6003
4	Redemption Eligibility	KYC Registry	50–100ms	Revert 6004
5	Price Impact Limit	TWAP Oracle	50–100ms	Revert 6006
6	Liquidity Ratio	Pool State	50–100ms	Revert 6007

---

🔹 5.2.3 Trading Execution Layer

Approved orders are submitted to the Solana network as signed transactions. The SPL Token-2022 Transfer Hook extensions execute atomically with settlement — there is no separation between trade execution and compliance enforcement.

CEDEX implements the constant product formula (x × y = k):

pub fn calculate_swap_output(
    input_amount:   u64,
    input_reserve:  u64,
    output_reserve: u64,
    fee_bps:        u16,   // 500 = 5%
) -> Result<SwapResult> {
    let fee_multiplier   = 10000u128 - fee_bps as u128;
    let input_with_fee   = (input_amount as u128)
        .checked_mul(fee_multiplier)
        .ok_or(SwapError::Overflow)?;
    let numerator        = input_with_fee
        .checked_mul(output_reserve as u128)
        .ok_or(SwapError::Overflow)?;
    let denominator      = (input_reserve as u128)
        .checked_mul(10000)
        .ok_or(SwapError::Overflow)?
        .checked_add(input_with_fee)
        .ok_or(SwapError::Overflow)?;
    let output_amount    = (numerator / denominator) as u64;  // Floor

    Ok(SwapResult {
        output_amount,
        fee_amount:        (input_amount as u128 * fee_bps as u128 / 10000) as u64,
        new_input_reserve: input_reserve + input_amount,
        new_output_reserve: output_reserve - output_amount,
    })
}

---

🔹 5.2.4 Layer Synchronization Protocol

The centralized OMS maintains a real-time synchronized view of on-chain state through OTCM's dedicated Helius RPC node cluster. Order book updates reflect confirmed on-chain settlements within 400ms (one Solana block) — ensuring no price discrepancy between displayed quotes and executable on-chain prices during normal network conditions.

💡 Atomicity Guarantee: If verification completes but execution fails (e.g., slippage exceeded), the entire transaction reverts. Users never face situations where compliance verification succeeds but tokens transfer incorrectly.

---

📉 5.3 Bonding Curve Bootstrap Phase

Upon deployment, each new ST22 Digital Securities token initially trades on a bonding curve rather than the permanent CPMM-based AMM. This bootstrap phase enables initial price discovery in a controlled environment, prevents flash crashes during early trading, and provides favorable entry prices for early community participants.

---

🔹 5.3.1 Linear Bonding Curve Mathematics

P(n) = initialPrice + (priceGradient × tokensIssued)

pub struct BondingCurve {
    pub token_mint:           Pubkey,
    pub initial_price:        u64,   // In lamports (0.000001 SOL)
    pub price_gradient:       u64,   // Price increase per token
    pub tokens_issued:        u64,
    pub sol_reserve:          u64,
    pub is_graduated:         bool,
    pub graduation_timestamp: Option<i64>,
}

impl BondingCurve {
    pub fn current_price(&self) -> u64 {
        self.initial_price + (self.price_gradient * self.tokens_issued / 1_000_000)
    }

    pub fn record_purchase(&mut self, tokens: u64, sol_amount: u64) {
        self.tokens_issued += tokens;
        self.sol_reserve   += sol_amount;
    }
}

---

🔹 5.3.2 Graduation Criteria

ST22 tokens graduate from bonding curve to permanent CPMM trading upon satisfying any of three criteria (OR logic):

Criterion	Threshold	Rationale
Market Cap	≥ $250,000 USD	Sufficient liquidity for CPMM stability
Holder Count	≥ 127,000 unique wallets	~0.5% of Solana active wallets — proof of genuine adoption
Time Elapsed	≥ 72 hours since deployment	Minimum stabilization period regardless of volume

---

🔹 5.3.3 Transition to Permanent AMM

Upon graduation, the following irreversible state transitions occur:

pub fn execute_graduation(ctx: Context<Graduation>) -> Result<()> {
    require!(
        curve.check_graduation_criteria()?,
        CedexError::GraduationCriteriaNotMet
    );

    // Permanently disable bonding curve — IMMUTABLE FLAG
    curve.is_graduated         = true;
    curve.graduation_timestamp = Some(Clock::get()?.unix_timestamp);
    curve.can_reactivate       = false;

    // Initialize CPMM pool with graduated reserves
    pool.sol_reserve    = curve.sol_reserve;
    pool.token_reserve  = curve.tokens_issued;
    pool.k_invariant    = pool.sol_reserve * pool.token_reserve;
    pool.liquidity_locked = true;  // PERMANENT — cannot be unlocked

    // Atomic transfer of all bonding curve reserves to CPMM pool
    transfer_sol(curve.sol_reserve, &ctx.accounts.pool_vault)?;

    emit!(GraduationCompleted {
        token_mint:      curve.token_mint,
        final_market_cap: calculate_market_cap(curve),
        holder_count:    get_holder_count(curve.token_mint)?,
        sol_migrated:    curve.sol_reserve,
    });

    Ok(())
}

⚠️ Irreversibility: Smart contract explicitly prevents bonding curve re-activation post-graduation through permanent disabling of bonding curve contract functions. This is enforced at the bytecode level — not through administrative controls that could be overridden.

---

🔢 CPMM Arithmetic Precision Specification

Version: 6.1 | Applies To: Layer 4 AMM — All swap calculations

u128 Overflow-Safe Arithmetic

The CPMM formula x × y = k requires multiplying two u64 reserve values. The maximum u64 value is 2⁶⁴ − 1 ≈ 18.4 × 10¹⁸. Multiplying two maximum u64 values produces a value requiring 128 bits. All intermediate CPMM calculations MUST use u128 arithmetic to prevent overflow.

Rounding Policy

Operation	Rounding Direction	Rationale
amount_out  calculation	Floor (truncate)	Trader receives slightly less — protocol never over-pays
amount_in  calculation (exact output)	Ceiling	Trader pays slightly more — protocol never under-receives
Fee calculation	Floor	Slightly less fee collected — conservative
LP share calculation	Floor	LP receives slightly less — prevents LP share inflation

Invariant guarantee: Floor rounding on amount_out ensures new_k ≥ old_k after every swap. The product invariant can only increase or stay equal, never decrease.

Maximum Safe Operating Parameters

Parameter	Maximum Safe Value	Notes
Single reserve	10¹⁵ tokens (u64)	Beyond this, consider reserve splitting
Single swap amount	20% of reserve	Circuit breaker enforces this (Hook 5)
k value	~10³⁰	Well within u128 range (3.4 × 10³⁸)
Cumulative k growth	Unbounded	k can only grow — no maximum

---

🔁 5.4 Constant Product Market Maker (CPMM)

Post-graduation, ST22 Digital Securities tokens trade on CEDEX's Constant Product Market Maker implementation. The CPMM model provides continuous liquidity at algorithmically determined prices without requiring traditional order books or market makers.

---

🔹 5.4.1 CPMM Mathematical Foundation

The CPMM maintains the invariant k = x × y, where:

• x = SOL reserve in the liquidity pool
• y = ST22 token reserve in the liquidity pool
• k = constant product (invariant)

Example swap — buying 10 SOL worth of tokens:

Initial state:
  k = 100 SOL × 1,000,000 tokens = 100,000,000

After 10 SOL buy:
  new_x = 100 + 10 = 110 SOL
  new_y = k / new_x = 100,000,000 / 110 = 909,091 tokens
  tokens_received = 1,000,000 − 909,091 = 90,909 tokens

Invariant check:
  k = 110 × 909,091 ≈ 100,000,000 ✓

---

🔹 5.4.2 Price Impact Calculation

pub fn calculate_price_impact(
    input_amount:   u64,
    input_reserve:  u64,
    output_reserve: u64,
) -> f64 {
    let spot_price    = input_reserve as f64 / output_reserve as f64;
    let new_input     = input_reserve as f64 + input_amount as f64;
    let new_output    = (input_reserve as f64 * output_reserve as f64) / new_input;
    let executed_price = input_amount as f64 / (output_reserve as f64 - new_output);
    let impact        = (executed_price - spot_price) / spot_price * 100.0;
    impact.abs()
}

Trade Size	% of Pool	Price Impact	Circuit Breaker
1 SOL	1%	~0.99%	✅ Allowed
2 SOL	2%	~1.96%	✅ Allowed
3 SOL	3%	~2.91%	❌ Blocked
5 SOL	5%	~4.76%	❌ Blocked

Examples assume 100 SOL pool reserve. Circuit breaker activates at >2% price impact.

---

🔹 5.4.3 Slippage Protection

pub struct SwapParams {
    pub input_amount:      u64,
    pub min_output:        u64,   // Minimum acceptable output
    pub max_slippage_bps:  u16,   // Maximum slippage in basis points
    pub deadline:          i64,   // Unix timestamp expiry
}

pub fn execute_swap(ctx: Context<Swap>, params: SwapParams) -> Result<()> {
    require!(
        Clock::get()?.unix_timestamp <= params.deadline,
        SwapError::DeadlineExceeded
    );
    let output = calculate_swap_output(params.input_amount, ...)?;
    require!(
        output >= params.min_output,
        SwapError::SlippageExceeded
    );
    execute_swap(output)?;
    Ok(())
}

---

🔹 5.4.4 Liquidity Depth Analysis

Pool TVL	Max Trade (2% impact)	Market Depth	Classification
$100K	~$2,000	Low	Early Stage
$500K	~$10,000	Moderate	Developing
$1M	~$20,000	Good	Mature
$5M+	~$100,000+	Deep	Institutional

---

🏗️ 5.5 Circuit Breaker Architecture

CEDEX implements a comprehensive circuit breaker system protecting Digital Securities markets from manipulation, flash crashes, and coordinated attacks. Inspired by traditional securities exchange mechanisms (NYSE Rule 80B, NASDAQ halt procedures), these protections operate at the smart contract level with no administrative override capability.

---

🔹 5.5.1 Price Impact Limits

pub const MAX_PRICE_IMPACT_BPS: u16 = 200;  // 2% maximum

pub fn check_price_impact(
    ctx:            Context<PriceImpactCheck>,
    proposed_trade: &SwapParams,
) -> Result<()> {
    require!(
        deviation_bps <= MAX_PRICE_IMPACT_BPS as u64,
        CedexError::PriceImpactExceeded  // Error 6006
    );
    Ok(())
}

This mechanism forces market participants to execute large trades gradually, allowing the market to absorb supply incrementally.

---

🔹 5.5.2 Volume-Based Halts

If any single wallet attempts to sell greater than 30% of circulating ST22 supply within a 24-hour period, transaction execution pauses for 24 hours:

pub const MAX_DAILY_SELL_PERCENT: u8  = 30;     // 30% max daily sale
pub const HALT_DURATION_SECONDS:  i64 = 86400;  // 24 hours

pub struct WalletTrackingState {
    pub wallet:                 Pubkey,
    pub daily_sell_amount:      u64,
    pub tracking_window_start:  i64,
    pub is_halted:              bool,
    pub halt_expiry:            Option<i64>,
}

---

🔹 5.5.3 Coordinated Activity Detection

CEDEX implements ML-based detection of coordinated selling patterns suggesting manipulative intent:

Dimension	Analysis Method	Suspicious Threshold
Wallet Clustering	Graph analysis of funding sources	>5 wallets sharing funding source
Timing Correlation	Transaction timestamp clustering	>3 sells within 10-second window
Amount Correlation	Statistical analysis of sale sizes	<5% variance across multiple sales
Price Impact Correlation	Sequential impact accumulation	Cumulative >5% within 1 hour

When coordinated activity is detected, affected wallets enter 24-hour cooldown periods and the compliance team receives alerts for manual review.

---

🔹 5.5.4 Time-Weighted Average Price (TWAP) Oracle

pub struct TwapOracle {
    pub token_mint:          Pubkey,
    pub price_observations:  Vec<PriceObservation>,
    pub observation_window:  i64,  // 1 hour in seconds
    pub min_observations:    u32,  // Minimum 60 observations
}

impl TwapOracle {
    pub fn calculate_twap(&self) -> Result<u64> {
        require!(
            valid_observations.len() >= self.min_observations as usize,
            OracleError::InsufficientObservations
        );

        let mut weighted_sum = 0u128;
        let mut total_time   = 0u128;
        for i in 1..valid_observations.len() {
            let time_delta  = valid_observations[i].timestamp
                            - valid_observations[i-1].timestamp;
            weighted_sum   += valid_observations[i-1].price as u128
                            * time_delta as u128;
            total_time     += time_delta as u128;
        }
        Ok((weighted_sum / total_time) as u64)
    }
}

---

📋 5.6 Order Types and Execution

---

🔹 5.6.1 Market Orders

Parameter	Specification
Execution Speed	Immediate (subject to compliance verification ~2–3 seconds)
Price Guarantee	None — executes at current pool price
Slippage Protection	Configurable (default 1% · max 5%)
Partial Fills	Not supported — all-or-nothing execution
Circuit Breaker	Rejects if price impact exceeds 2% TWAP deviation

---

🔹 5.6.2 Limit Orders

pub struct LimitOrder {
    pub order_id:    u64,
    pub owner:       Pubkey,
    pub token_mint:  Pubkey,
    pub side:        OrderSide,   // Buy or Sell
    pub amount:      u64,
    pub limit_price: u64,         // Price threshold (lamports per token)
    pub expiry:      i64,
    pub status:      OrderStatus,
}

pub enum OrderSide   { Buy, Sell }
pub enum OrderStatus { Open, Filled, Cancelled, Expired }

---

🔹 5.6.3 Swap Interface

interface SwapRequest {
  inputToken:       'SOL' | ST22Address;
  outputToken:      'SOL' | ST22Address;
  inputAmount:      bigint;
  minOutputAmount:  bigint;
  slippageTolerance: number;  // Basis points
  deadline:         number;   // Unix timestamp
}

interface SwapResponse {
  transactionId:   string;
  inputAmount:     bigint;
  outputAmount:    bigint;
  effectivePrice:  number;
  priceImpact:     number;
  fees: {
    protocol: bigint;
    network:  bigint;
  };
  complianceVerification: {
    status:   'VERIFIED' | 'PENDING' | 'REJECTED';
    hooks:    HookResult[];
    duration: number;  // milliseconds
  };
}

---

💸 5.7 Fee Structure and Distribution

---

🔹 5.7.1 Transaction Fee Breakdown

Every CEDEX swap incurs a 5% total transaction fee (500 basis points):

Fee Component	Rate	Purpose
Issuer Allocation	2.00%	Revenue share to issuing company treasury
Staking Rewards	1.50%	Distributed to OTCM token stakers (8–60% APY)
Protocol Operations	1.06%	Infrastructure · compliance oracles · development
Liquidity Pool Growth	0.44%	Permanently locked in OTCM LP
TOTAL	5.00%	Complete fee structure

---

🔹 5.7.2 Fee Distribution Smart Contract

pub fn distribute_fees(
    fee_amount:        u64,
    issuer_treasury:   &Pubkey,
    staking_pool:      &Pubkey,
    protocol_treasury: &Pubkey,
    liquidity_pool:    &Pubkey,
) -> Result<()> {
    const ISSUER_SHARE:   u64 = 4000;  // 40% of fee = 2.00% of trade
    const STAKING_SHARE:  u64 = 3000;  // 30% of fee = 1.50% of trade
    const PROTOCOL_SHARE: u64 = 2120;  // 21.2% of fee = 1.06% of trade
    const LP_SHARE:       u64 = 880;   // 8.8% of fee = 0.44% of trade

    transfer_sol(issuer_amount,   issuer_treasury)?;
    transfer_sol(staking_amount,  staking_pool)?;
    transfer_sol(protocol_amount, protocol_treasury)?;
    transfer_sol(lp_amount,       liquidity_pool)?;  // Permanently locked

    Ok(())
}

---

🔹 5.7.3 Fee Comparison Analysis

Platform	Swap Fee	Compliance	LP Rewards	Issuer Revenue
CEDEX	5.00%	✅ Full Digital Securities	8–60% APY	2.00%
Raydium	0.25%	❌ None	Variable	0%
Orca	0.30%	❌ None	Variable	0%
Pump.fun	1.00%	❌ None	None	0%

💡 Fee Justification: While CEDEX's 5% fee exceeds traditional DEX fees, it includes comprehensive compliance verification ($2–5 per transaction in oracle costs), issuer revenue sharing, permanent liquidity growth, and full Digital Securities classification enforcement. For institutional securities trading, this represents significant cost savings versus traditional broker-dealer infrastructure.

---

🤖 5.8 MEV Protection

Maximum Extractable Value (MEV) attacks represent one of the most significant threats to DeFi users, with an estimated $1.38 billion extracted from traders in 2023 alone. CEDEX implements multiple protection layers making MEV extraction economically unfeasible.

---

🔹 5.8.1 Frontrunning Prevention

• Private Transaction Submission — Transactions route through Jito's private mempool, invisible to searchers until block inclusion
• Slippage Enforcement — Strict slippage limits (default 1%) reduce profitability of frontrunning attempts
• Circuit Breaker Integration — 2% price impact limit prevents large frontrun trades from executing

---

🔹 5.8.2 Sandwich Attack Mitigation

Attack Requirement:          CEDEX Defense:
  Buy before victim     ──→  Private mempool (not visible)
  Victim trade          ──→  Jito bundle (atomic — cannot be inserted between)
  Sell after victim     ──→  2% circuit breaker limits residual profitability

---

🔹 5.8.3 Jito Bundle Integration

Feature	Implementation
Bundle Submission	All CEDEX trades submitted as Jito bundles with guaranteed atomicity
Private Mempool	Transactions invisible until block inclusion
Priority Fees	Dynamic priority fee calculation for reliable inclusion
Backrun Protection	Bundle structure prevents insertion between compliance verification and execution

---

⚡ Jito Bundle MEV Protection — Technical Specification

Version: 6.1 | Applies To: All CEDEX trade submissions

Bundle Failure Handling

Failure Mode	Cause	CEDEX Response
Bundle timeout (>10 slots)	Network congestion or low tip	Resubmit with 2× tip — up to 3 attempts
Bundle simulation failure	Transfer Hook rejection	Return hook error code to user — no resubmit
Block engine unreachable	Jito infrastructure outage	Fallback to standard RPC submission with priority fee
Bundle partially included	Should not occur (atomic guarantee)	Log as critical alert — investigate immediately

Fallback Mode: If Jito block engine is unavailable for >30 seconds, CEDEX automatically falls back to standard priority-fee RPC submission via Helius. In fallback mode, MEV protection is degraded — CEDEX displays a "MEV Protection Degraded" banner in the trading UI and logs all fallback transactions for post-incident review.

Sandwich Attack Prevention — Mathematical Proof

A sandwich attack requires inserting a buy transaction before and a sell transaction after the victim's trade. Jito bundles make this impossible because:

1. The victim's transaction is invisible in the public mempool — it exists only in Jito's private relay network
2. The bundle is atomic — no transaction can be inserted between bundle transactions by any party including validators
3. Even if the bundle contents leak, the attacker cannot front-run because the bundle tip gives the victim's bundle priority over unbundled transactions

Residual risk: A malicious Jito validator with block production rights could theoretically see bundle contents and sandwich around the entire bundle. This risk is mitigated by: (a) CEDEX's 2% price impact circuit breaker (Hook 5) limits sandwich profitability to near-zero, and (b) Jito's validator reputation system and slashing mechanisms disincentivize this behavior.

---

⚡ 5.9 Performance Specifications

Metric	Specification	Notes
Throughput (TPS)	400–600	Limited by compliance verification
Compliance Latency	2,000–3,000ms	Six hooks + oracle queries
Execution Latency	400–600ms	CPMM swap post-verification
Block Finality	~13 seconds	32 Solana blocks
Compute Units	~800,000 CU	Per complete swap transaction
Network Fee	~$0.01–$0.05	Solana base + priority fee

---

🏗️ 5.10 Security Architecture

Smart Contract Security

• Formal verification using Certora Prover
• Security audits by Quantstamp · Halborn · OtterSec
• Active bug bounty program (up to $100K rewards)
• Immutable core contracts post-deployment

Economic Security

• Circuit breakers prevent flash loan attacks
• TWAP oracle resists price manipulation
• Permanent liquidity locks prevent rug pulls
• Volume limits prevent coordinated dumps

Operational Security

• Multi-signature admin keys (4-of-7 threshold)
• 48-hour timelock on all parameter changes
• Real-time monitoring and alerting
• Incident response playbooks documented and tested

---

Groovy Company, Inc. dba OTCM Protocol · Wyoming Corporation · invest@otcm.io · otcm.io

📈 The OTCM trading interface — a purpose-built Centralized-Decentralized Exchange combining Web2 order matching with Web3 settlement finality, natively supporting SPL Token-2022 Transfer Hooks.

---

💡 5.1 Architectural Innovation

CEDEX (Centralized-Decentralized Exchange) represents a fundamental reimagining of decentralized exchange architecture, purpose-built from inception for trading tokenized securities within federal securities law frameworks. Unlike existing DEX platforms that were designed for permissionless cryptocurrency trading and subsequently face irreconcilable conflicts with securities regulation, CEDEX implements compliance verification as a foundational architectural constraint rather than retrofitted functionality.

This section provides comprehensive technical documentation of CEDEX's architectural innovations, explaining why existing DEX solutions cannot serve the tokenized securities market and how CEDEX's compliance-first design creates categorical advantages for institutional adoption.

🔹 5.1.1 The DEX Incompatibility Problem

Standard decentralized exchanges—including market leaders Raydium, Orca, Jupiter, and Meteora—were architected around three foundational design principles that create irreconcilable conflict with securities law compliance:

Principle 1: Computational Minimalism

Traditional DEXs optimize for maximum throughput by minimizing computational overhead per transaction. Every additional instruction reduces theoretical TPS capacity, creating strong architectural pressure against compliance verification. A typical Raydium swap executes in approximately 200,000 compute units; adding six Transfer Hook verifications would increase this to 800,000+ compute units, fundamentally changing the economic model.

Principle 2: Compliance Agnosticism

DEX protocols intentionally refuse implementation of securities-specific procedures such as KYC verification, accreditation checking, OFAC screening, and investor qualification. This design choice reflects ideological commitment to permissionless trading and practical recognition that compliance creates liability exposure for protocol developers.

Principle 3: Economic Incentive Misalignment

Traditional DEX economics depend on maximizing trading volume with minimal friction. Compliance verification introduces friction (latency), complexity (integration requirements), and cost (oracle fees). These factors directly reduce profitability under existing DEX business models, creating structural resistance to compliance implementation.

💡 Critical Insight

The incompatibility between existing DEXs and securities compliance is not a technical limitation that can be solved with additional development. It represents a fundamental architectural conflict where the design goals of permissionless trading and regulated securities trading are mutually exclusive.

🔹 5.1.2 Why Existing DEXs Cannot Support ST22 Tokens

Beyond philosophical design conflicts, existing DEX codebases face concrete technical barriers preventing ST22 token support:

DEX Platform	Token-2022 Support	Transfer Hook Support
Raydium	Partial (basic transfers only)	None — hooks disabled
Orca	Limited (whitelist)	None — not implemented
Jupiter	Aggregates underlying DEXs	None — inherits limitations
Meteora	Basic support	None — bypassed
CEDEX	Full native support	Full — 6 hooks per transfer

The core technical issue: existing DEX codebases were written before SPL Token-2022 existed. Their smart contracts interact directly with the original SPL Token Program, which lacks Transfer Hook extensions. Retrofitting Transfer Hook support would require complete protocol rewrites—a multi-year effort that these protocols have no economic incentive to undertake.

⚠️ Critical Limitation

If ST22 tokens were traded on existing DEXs (assuming technical compatibility), Transfer Hooks would be bypassed during swaps. This would disable all 42 security controls, including custody verification, OFAC screening, and AML checks—making the tokens non-compliant securities.

🔹 5.1.3 The CEDEX Design Philosophy

CEDEX inverts traditional DEX design priorities. Rather than implementing compliance verification as bolted-on functionality to existing trading infrastructure, CEDEX implements compliance verification as the foundational architectural constraint shaping every element of trading system design.

"We didn't add compliance to a DEX. We built a compliance engine that happens to execute trades."

This philosophical inversion creates three categorical advantages:

• Compliance Integration at Design Phase: Verification logic integrates at system design phase rather than being retrofitted. Every smart contract instruction, every data structure, every execution path was designed with compliance verification as a first-class requirement.
• Optimized Smart Contract Architecture: Smart contract architecture optimizes for compliance execution from inception. Compute budget allocation, account structure, and instruction ordering all prioritize successful compliance verification over raw trading speed.
• Aligned Economic Incentives: Economic incentive structure aligns operator profitability with successful compliance implementation. CEDEX generates revenue from compliant trades; non-compliant trades generate zero revenue because they cannot execute.

🔹 5.1.4 Compliance-First vs Compliance-Retrofitted

The distinction between compliance-first and compliance-retrofitted architecture has profound implications for system reliability, security, and regulatory acceptance:

Aspect	Compliance-First (CEDEX)	Compliance-Retrofitted
Verification Timing	Before execution (blocking)	After execution (non-blocking)
Non-Compliant Trades	Cannot execute (impossible)	Execute then flag for review
Regulatory Posture	Preventive control	Detective control
Audit Trail	Every trade verified on-chain	Off-chain logs (mutable)
System Complexity	Integrated (single system)	Fragmented (multiple systems)
Failure Mode	Fail-safe (no trade)	Fail-open (trade executes)

4.2 Custom AMM Architecture

CEDEX implements a modified Automated Market Maker (AMM) architecture engineered specifically for Transfer Hook integration. Unlike traditional AMMs that execute token swaps as atomic operations, CEDEX separates compliance verification from trading execution into distinct architectural layers, enabling asynchronous compliance checking without blocking user interaction.

🔹 5.2.1 Dual-Layer Execution Model

The dual-layer execution model represents CEDEX's core architectural innovation: segregating compliance verification from trading execution while maintaining atomic transaction guarantees.

// Dual-Layer Architecture Diagram
┌---┐
│                   CEDEX DUAL-LAYER EXECUTION MODEL                      │
└---┘

User Request

│
▼
┌---┐
│              COMPLIANCE VERIFICATION LAYER                         │
│  ┌---┐  │
│  │  Asynchronous Execution (2,000-3,000ms)                      │  │
│  │                                                              │  │
│  │  Hook 1: Custody ---► Hook 2: OFAC ---► Hook 3: AML            │  │
│  │  Hook 4: KYC ---► Hook 5: Price Impact ---► Hook 6: LP Ratio   │  │
│  │                                                              │  │
│  │  Result: VERIFIED | REJECTED (with error code)               │  │
│  └---┘  │
└---┬---┘
│
▼
┌---┐
│                TRADING EXECUTION LAYER                             │
│  ┌---┐  │
│  │  Synchronous Execution (400-600ms)                           │  │
│  │                                                              │  │
│  │  1. Receive verification confirmation                        │  │
│  │  2. Calculate CPMM output amount                             │  │
│  │  3. Update pool reserves atomically                          │  │
│  │  4. Execute token transfer                                   │  │
│  │  5. Distribute fees                                          │  │
│  │                                                              │  │
│  │  Result: EXECUTED | REVERTED                                 │  │
│  └---┘  │
└---┘

🔹 5.2.2 Compliance Verification Layer

The Compliance Verification Layer executes during every ST22 token transfer, implementing OTCM's six Transfer Hooks in sequential order. This layer operates asynchronously from the user's perspective—verification completion occurs independently of user action, enabling a responsive interface despite comprehensive compliance checking.

Verification Flow

// Compliance Verification Data Structure (Rust)

pub struct ComplianceVerification {

pub transfer_id: Pubkey, // Unique transfer identifier

pub sender: Pubkey, // Source wallet

pub recipient: Pubkey, // Destination wallet

pub token_mint: Pubkey, // ST22 token address

pub amount: u64, // Transfer amount

pub verification_start: i64, // Unix timestamp

pub hook_results: [HookResult; 6], // Results from each hook

pub final_status: VerificationStatus,

}

pub enum VerificationStatus {

Pending, // Verification in progress

Verified, // All hooks passed

Rejected { // At least one hook failed

hook_number: u8,

error_code: u16,

reason: String,

},

}

Hook Execution Sequence

Each Transfer Hook executes in strict sequence, with failure at any point causing immediate transaction reversion:

Order	Hook Name	Oracle Source	Latency	Fail Action
1	Custody Verification	Empire Stock API	100-150ms	Revert 6001
2	OFAC Screening	SDN List Oracle	200-500ms	Revert 6002
3	AML Analytics	Chainalysis/TRM	300-400ms	Revert 6003
4	Redemption Eligibility	KYC Registry	50-100ms	Revert 6004
5	Price Impact Limit	TWAP Oracle	50-100ms	Revert 6006
6	Liquidity Ratio	Pool State	50-100ms	Revert 6007

🔹 5.2.3 Trading Execution Layer

The Trading Execution Layer receives verified tokens and executes trades only upon successful completion of all compliance verification. This layer implements the Constant Product Market Maker (CPMM) formula for price discovery and liquidity provision.

CPMM Core Formula

CEDEX implements the constant product formula (x × y = k) where x represents SOL reserves, y represents ST22 token reserves, and k is the invariant constant:

// CPMM Swap Calculation (Rust)
pub fn calculate_swap_output(

input_amount: u64,

input_reserve: u64,

output_reserve: u64,

fee_bps: u16, // Basis points (500 = 5%)

) -> Result<SwapResult> {

// Apply fee to input
let fee_multiplier = 10000 - fee_bps as u64;
let input_with_fee = input_amount

.checked_mul(fee_multiplier)

.ok_or(SwapError::Overflow)?;

// Calculate output using constant product formula
// output = (input_with_fee × output_reserve) / (input_reserve × 10000 + input_with_fee)
let numerator = input_with_fee

.checked_mul(output_reserve)

.ok_or(SwapError::Overflow)?;

let denominator = input_reserve

.checked_mul(10000)

.ok_or(SwapError::Overflow)?

.checked_add(input_with_fee)

.ok_or(SwapError::Overflow)?;

let output_amount = numerator / denominator;
let fee_amount = input_amount - (input_amount * fee_multiplier / 10000);
Ok(SwapResult {

output_amount,

fee_amount,

new_input_reserve: input_reserve + input_amount,

new_output_reserve: output_reserve - output_amount,

})

}

🔹 5.2.4 Layer Synchronization Protocol

The two layers synchronize through a handoff protocol ensuring atomic execution guarantees:

• Verification Request: User initiates swap, generating unique transfer_id
• Parallel Processing: UI displays "Verifying compliance..." while hooks execute
• Verification Complete: All hooks pass, verification_status set to VERIFIED
• Execution Authorization: Trading layer receives signed verification confirmation
• Atomic Swap: CPMM calculation and token transfer execute in single transaction
• Settlement: Transaction finalizes after 32 Solana blocks (~13 seconds) 💡 Atomicity Guarantee

If verification completes but execution fails (e.g., slippage exceeded), the entire transaction reverts. Users never face situations where compliance verification succeeds but tokens transfer incorrectly.

🏗️ 5.2 Dual-Layer Execution Architecture

🔹 5.2.1 Dual-Layer Execution Model

CEDEX implements a dual-layer architecture combining a centralized order management system with decentralized on-chain settlement. The centralized layer handles order matching, price discovery, and user interface at sub-100ms latency. The decentralized layer handles actual asset custody, transfer execution, and Transfer Hook enforcement on Solana. This architecture deliversprovides Web2-grade user experience with— sub-100ms order matching, real-time price feeds, and a professional trading interface. The decentralized layer provides Web3-grade settlement finality.finality — atomic Transfer Hook enforcement and irreversible on-chain settlement on Solana.

 

	Layer		Function		Technology
Centralized OMS	Order matching,matching · price feeds,discovery UI· user interface	OTCM matching engine + REST API
Pre-flight Compliance Verification	KYC/AML status,status check · accreditation checkverification	Layer 2 Transfer Hook pre-check against Empire registry
Decentralized Settlement	Asset transfer,transfer · all 42 Transfer Hook execution,controls · finality	Solana + SPL Token-2022

 

🔹5.5.1 5.2.2 Compliance Verification Layer

Before any trade executes on-chain, CEDEX runs a pre-flight compliance check against the investor's current verification status.status This check queriesin the IssuersEmpire PortalStock complianceTransfer stateregistry. in real-time. TradersInvestors with lapsed KYC, expired accreditation,accreditation orcertification, flagged AML statusstatus, or OFAC/SDN matches are blocked at the order entry stage — before any on-chain transaction is attempted —attempted, preventing failed transactions and wasted gas.fees. The pre-flight check is in addition to, not a replacement for, the on-chain Transfer Hook enforcement.

 

Order	Hook	Oracle Source	Target Latency	Failure Action
1	Custody Verification — Control 1	Empire Stock Transfer API (~400ms refresh)	100–150ms	Revert 6001
2	OFAC Screening — Controls 8–10	OFAC SDN Oracle (hourly refresh)	200–500ms	Revert 6003–6005
3	AML Analytics — Control 11	Chainalysis / TRM Labs	300–400ms	Revert 6006
4	Accreditation & KYC — Controls 12–18	Empire investor registry	50–100ms	Revert 6004
5	Holding Period Lock — Control 24	On-chain HoldingPeriodAccount	< 10ms	Revert 6024
6	Price Impact Limit — Control 25	TWAP Oracle	50–100ms	Revert 6006
7–42	Extended Controls	Various	Parallel	Various 60XX

 

🔹5.5.2 5.2.3 Trading Execution Layer

Approved orders are submitted to the Solana network as signed transactions. The SPL Token-2022 Transfer Hook extensions execute atomically with settlement — there is no separation between trade execution and compliance enforcement. If any of the 42 Transfer Hook controls reject the transaction, it reverts entirely with a specific error codecode. enablingThe rapidtransaction diagnosis.either completes fully with all compliance verified, or it does not complete at all.

 

pub fn execute_swap(     ctx:         Context<Swap>,     input_amount: u64,     min_output:   u64,     deadline:     i64, ) -> Result<()> {     // Deadline check     require!(Clock::get()?.unix_timestamp <= deadline, SwapError::DeadlineExceeded);       // CPMM calculation     let result = calculate_output_amount(         input_amount,         ctx.accounts.pool.sol_reserve,         ctx.accounts.pool.token_reserve,         500, // 5% fee in bps     )?;       // Slippage check     require!(result.output_amount >= min_output, SwapError::SlippageExceeded);       // Distribute fee — 5 recipients     distribute_fees(result.fee_amount, &ctx.accounts.fee_recipients)?;       // Token transfer — Transfer Hook invoked here automatically by Token-2022     // All 42 controls execute atomically before this returns     token_transfer(result.output_amount, &ctx)?;       emit!(SwapExecuted { input: input_amount, output: result.output_amount });     Ok(()) }

 

🔹5.5.3 5.2.4 Layer Synchronization Protocol

The centralized OMS maintains a real-time synchronized view of on-chain state through OTCM's dedicated Helius RPC node cluster. Order book updates reflect confirmed on-chain settlements within 400ms (— one Solana block).block This— synchronization ensuresensuring no price discrepancy between displayed quotes and executable on-chain prices duringunder normal network conditions.

📉 5.3 Bonding Curve Bootstrap Phase

Upon deployment, each new ST22 token initially trades on a bonding curve rather than the permanent CPMM-based AMM. This bootstrap phase serves critical functions: enabling initial price discovery in a controlled environment, preventing flash crashes and wash trading during early trading, and providing favorable entry prices for early community participants.

🔹 5.4.1 Initial Price Discovery Mechanism

The bonding curve creates a mathematically predictable relationship between token supply and price, eliminating the need for external price oracles during the bootstrap phase. As tokens are purchased, the price increases along a predetermined curve; as tokens are sold, the price decreases.

// Bonding Curve Price Discovery
┌---┐
│                    BONDING CURVE PRICE DISCOVERY                        │
└---┘
Price │
(USD) │                                              ╭--- Graduation
│                                           ╭---╯     Threshold
$0.15│                                        ╭---╯        ($250K MC)
│                                     ╭---╯
$0.10│                                  ╭---╯
│                               ╭---╯
$0.05│                            ╭---╯
│                         ╭---╯
$0.01│_____________________╭---╯
│                  ╭---╯
$0.001│______________╭---╯
└---┴---►

Tokens Issued (millions)

│◄--- Early Buyers ---►│◄--- Growth Phase ---►│◄--- Graduation ---► │

🔹 5.4.2 Linear Bonding Curve Mathematics

CEDEX implements a linear bonding curve formula providing predictable price appreciation as token adoption increases:

// Bonding Curve Price Formula
// Linear Bonding Curve Formula

P(n) = initialPrice + (priceGradient × tokensIssued)

// Parameters:
// initialPrice = $0.001 per token (starting price)
// priceGradient = 0.001% per token sold
// Example calculations:
// At 0 tokens sold:      P = $0.001 + (0.00001 × 0) = $0.001
// At 1M tokens sold:     P = $0.001 + (0.00001 × 1,000,000) = $0.011
// At 10M tokens sold:    P = $0.001 + (0.00001 × 10,000,000) = $0.101
// At 25M tokens sold:    P = $0.001 + (0.00001 × 25,000,000) = $0.251

Implementation

// Bonding Curve Implementation (Rust)

pub struct BondingCurve {

pub token_mint: Pubkey,

pub initial_price: u64, // In lamports (0.001 SOL = 1,000,000 lamports)

pub price_gradient: u64, // Price increase per token (in lamports)

pub tokens_issued: u64, // Current tokens in circulation

pub sol_reserve: u64, // SOL collected from purchases

pub is_graduated: bool, // Whether curve has graduated

pub graduation_timestamp: Option<i64>,

}

impl BondingCurve {

pub fn current_price(&self) -> u64 {

self.initial_price + (self.price_gradient * self.tokens_issued / 1_000_000)

}

pub fn buy_tokens(&mut self, sol_amount: u64) -> Result {
// Calculate tokens receivable at current price
let current_price = self.current_price();
let tokens = sol_amount * 1_000_000_000 / current_price; // 9 decimals
// Update state

self.tokens_issued += tokens;

self.sol_reserve += sol_amount;

Ok(tokens)

}

}

🔹 5.3.3 Graduation Criteria

ST22 tokens graduate from bonding curve to permanent CPMM trading upon satisfying either of two criteria:

Criterion	Threshold	Rationale
Market Cap	≥ $250,000 USD	Sufficient liquidity for CPMM stability
Holder Count	≥ 127,000 unique wallets	Mathematical proof of community adoption (~0.5% of Solana active wallets)
Time Elapsed	≥ 72 hours since deployment	Minimum stabilization period regardless of volume

Graduation occurs automatically when ANY criterion is met (OR logic). The 127,000 holder threshold represents approximately 0.5% of Solana's active wallet base, providing mathematical proof of genuine community adoption rather than artificial inflation.

🔹 5.4.4 Transition to Permanent AMM

Upon graduation, the following irreversible state transitions occur:

• Bonding Curve Deactivation: Smart contract permanently disables bonding curve purchase/sale functions through immutable state flag
• Liquidity Migration: All SOL accumulated in bonding curve reserve transfers to CEDEX CPMM pool
• Pool Initialization: CPMM pool initializes with graduated token supply and migrated SOL reserve
• Permanent Lock: Liquidity becomes permanently locked—cannot be withdrawn by any party including protocol administrators

// Graduation Function (Rust/Anchor)
pub fn graduate_to_amm(ctx: Context) -> Result<()> {
let curve = &mut ctx.accounts.bonding_curve;
let pool = &mut ctx.accounts.cpmm_pool;
// Verify graduation criteria met
require!(

curve.check_graduation_criteria()?,

CedexError::GraduationCriteriaNotMet

);

// Permanently disable bonding curve

curve.is_graduated = true;

curve.graduation_timestamp = Some(Clock::get()?.unix_timestamp);

// Initialize CPMM pool with migrated liquidity

pool.sol_reserve = curve.sol_reserve;

pool.token_reserve = curve.tokens_issued;

pool.k_invariant = pool.sol_reserve * pool.token_reserve;

pool.liquidity_locked = true; // PERMANENT - cannot be unlocked

// Transfer SOL to pool

transfer_sol(curve.sol_reserve, &ctx.accounts.pool_vault)?;

emit!(GraduationEvent {

token_mint: curve.token_mint,

final_market_cap: calculate_market_cap(curve),

holder_count: get_holder_count(curve.token_mint)?,

sol_migrated: curve.sol_reserve,

});

Ok(())

}

⚠️ Irreversibility

Smart contract explicitly prevents bonding curve re-activation post-graduation through permanent disabling of bonding curve contract functions. This is enforced at the bytecode level—not through administrative controls that could be overridden.

🔁

🔢 CPMM ARITHMETIC PRECISION SPECIFICATION

Version: 6.0 | Applies To: Layer 4 AMM — All swap calculations

u128 Overflow-Safe Arithmetic

The CPMM formula x × y = k requires multiplying two u64 reserve values. The maximum u64 value is 2⁶⁴ − 1 = 18,446,744,073,709,551,615. Multiplying two maximum u64 values produces a value requiring 128 bits. All intermediate CPMM calculations MUST use u128 arithmetic to prevent overflow.

rust 

//

PriceImpact Calculation pub fn calculate_price_impact(

input_amount: u64,

input_reserve: u64,

output_reserve: u64,

) -> f64 {

// Spot price before trade
let spot_price = output_reserve as f64 / input_reserve as f64;
// Effective price for this trade
let output_amount = calculate_output(input_amount, input_reserve, output_reserve);
let effective_price = output_amount as f64 / input_amount as f64;
// Price impact as percentage
let impact = (spot_price - effective_price) / spot_price * 100.0;

impact.abs()

}

Atomicity Guarantee If ///compliance Overflow-safeverification CPMMcompletes swapbut outputexecution calculationfails /// Uses u128 intermediate arithmetic throughout pub fn calculate_swap_output( amount_in: u64, reserve_in: u64, reserve_out: u64, fee_bps: u16, // Fee in basis points (500 = 5%) ) -> Result { // Cast to u128 BEFORE any multiplication let amount_in_u128 = amount_in as u128; let reserve_in_u128 = reserve_in as u128; let reserve_out_u128 = reserve_out as u128; let fee_numerator = 10_000u128 - fee_bps as u128; // e.g. 9_500— for 5%example, slippage exceeded, deadline passed, or insufficient balance — the entire transaction reverts atomically. No partial state changes persist. Investors never face a situation where compliance verification succeeds but tokens transfer incorrectly, or where a fee // Apply fee to input amount (fee taken from input) let amount_in_with_fee = amount_in_u128 .checked_mul(fee_numerator) .ok_or(AmmError::Overflow)?; // Numerator: amount_in_with_fee × reserve_out × 10_000 // (multiply by 10_000 to preserve fee precision) let numerator = amount_in_with_fee .checked_mul(reserve_out_u128) .ok_or(AmmError::Overflow)?; // Denominator: (reserve_in × 10_000) + amount_in_with_fee let denominator = (reserve_in_u128 .checked_mul(10_000u128) .ok_or(AmmError::Overflow)?) .checked_add(amount_in_with_fee) .ok_or(AmmError::Overflow)?; // Division — floor (conservative — output slightly less than theoretical) let amount_out_u128 = numerator .checked_div(denominator) .ok_or(AmmError::DivisionByZero)?; // Safe downcast — output cannot exceed reserve_out (u64) u64::try_from(amount_out_u128).map_err(|_| error!(AmmError::Overflow)) } /// Maximum reserve size before precision degradation /// At reserve = 10^15 tokens (1 quadrillion), intermediate u128 values reach: /// numerator max ≈ (10^15)^2 × 10^4 = 10^34 → within u128 range (3.4 × 10^38) /// Maximum safe reserve per token: 10^15 units (with 9 decimal places = 10^6 whole tokens) pub const MAX_SAFE_RESERVE: u64 = 1_000_000_000_000_000; // 10^15 /// Invariant verification after every swap — must hold within rounding tolerance pub fn verify_invariant( old_k: u128, new_reserve_in: u64, new_reserve_out: u64, ) -> Result<()> { let new_k = (new_reserve_in as u128) .checked_mul(new_reserve_out as u128) .ok_or(AmmError::Overflow)?; // k should be equal or slightly larger (fees increase k) // Tolerance: 1 unit of precision (rounding) require!( new_k >= old_k.saturating_sub(1), AmmError::InvariantViolation ); Ok(()) } Rounding Policy Operation Rounding Direction Rationale amount_out  calculation Floor (truncate) Trader receives slightly less — protocol never over-pays amount_in  calculation (exact output) Ceiling Trader pays slightly more — protocol never under-receives Fee calculation Floor Slightly less feeis collected — conservative LP share calculation Floor LP receives slightly less — prevents LP share inflation Invariant guarantee: Floor rounding on amount_out ensures new_k ≥ old_k after every swap. This means the product invariant can only increase or stay equal, never decrease. This is a stronger guarantee than the theoretical constant product formula implies. Maximum Safe Operating Parameters Parameter Maximum Safe Value Notes Single reserve 10¹⁵ tokens (u64) Beyond this, consider reserve splitting Single swap amount 20% of reserve Circuit breaker enforces this (Hook 5) k value ~10³⁰ Well within u128 range (3.4 × 10³⁸) Cumulative k growth Unbounded (fees) k can only grow — no maximum 🔹 5.4 Constant Product Market Maker (CPMM) Post-graduation, ST22 tokens trade on CEDEX's Constant Product Market Maker implementation. The CPMM model, pioneered by Uniswap, provides continuous liquidity at algorithmically determined prices without requiring traditional order books or market makers. 🔹 5.4.1 CPMM Mathematical Foundation The CPMM maintains the invariant k = x × y, where: x = SOL reserve in the liquidity pool y = ST22 token reserve in the liquidity pool k = constant product (invariant) Every swap changes reserves while maintaining the invariant: // CPMM Swap Example // Pre-swap state: k = x × y = 100 SOL × 1,000,000 tokens = 100,000,000 // User swaps 10 SOL for tokens: new_x = 100 + 10 = 110 SOL new_y = k / new_x = 100,000,000 / 110 = 909,091 tokens tokens_received = 1,000,000 - 909,091 = 90,909 tokens // Post-swap state: k = 110 × 909,091 ≈ 100,000,000 (invariant maintained) 🔹 5.4.2 Price Impact Calculation Price impact measures how much a trade moves the market price. Larger trades relative to pool reserves create larger price impacts:executing.

Trade Size	% of Pool	Price Impact	Circuit Breaker
1 SOL	1%	~0.99%	✓ Allowed
2 SOL	2%	~1.96%	✓ Allowed
3 SOL	3%	~2.91%	✗ Blocked
5 SOL	5%	~4.76%	✗ Blocked

Note: Examples assume 100 SOL pool reserve. Circuit breaker activates at >2% price impact.

🔹

5.6 5.4.3 Slippage Protection

CEDEX provides configurable slippage protection ensuring users receive expected value:

// Slippage Protection Implementation

pub struct SwapParams {

pub input_amount: u64,

pub min_output: u64, // Minimum acceptable output

pub max_slippage_bps: u16, // Maximum slippage in basis points

pub deadline: i64, // Unix timestamp expiry

}

pub fn execute_swap_with_protection(

ctx: Context<Swap>,

params: SwapParams,

) -> Result<()> {

// Check deadline
require!(

Clock::get()?.unix_timestamp <= params.deadline,

SwapError::DeadlineExceeded

);

// Calculate output
let output = calculate_output(...)?;
// Verify slippage tolerance
require!(

output >= params.min_output,

SwapError::SlippageExceeded

);

// Execute swap

execute_swap(output)?;

Ok(())

}

🔹 5.4.4 Liquidity Depth Analysis

Pool liquidity depth determines trading efficiency. CEDEX targets minimum liquidity levels ensuring acceptable price impacts:

Pool TVL	Max Trade (2%)	Market Depth	Classification
$100K	~$2,000	Low	Early Stage
$500K	~$10,000	Moderate	Developing
$1M	~$20,000	Good	Mature
$5M+	~$100,000+	Deep	Institutional

🏗️ 5.5 Circuit Breaker Architecture

CEDEX implements a comprehensive circuit breaker system protecting Digital Securities markets from manipulation, flash crashes, and coordinated attacks. InspiredModeled byon traditional securities exchange mechanisms (— NYSE Rule 80B, NASDAQ halt procedures),procedures — these protections operate at the smart contract level withthrough the Transfer Hook architecture. There is no administrative override capability.

 

🔹5.6.1 5.5.1 Price Impact LimitsLimit — Control 25

CEDEX enforces a hard limit on price impact per transaction. Any single transaction causing greater than 2% price movement against the Time-Weighted Average Price (TWAP) oracle is automatically rejected:

rejected.

// Price Impact Limit Implementation

pub const MAX_PRICE_IMPACT_BPS: u16 = 200; // 2% maximum

pub fn check_price_impact(

ctx: Context<PriceImpactCheck>,

proposed_trade: &SwapParams,

) -> Result<()> {

let twap = ctx.accounts.twap_oracle.get_price()?;
let expected_price = calculate_expected_price(proposed_trade)?;
// Calculate deviation from TWAP
let deviation_bps = ((twap - expected_price).abs() * 10000) / twap;
require!(

deviation_bps <= MAX_PRICE_IMPACT_BPS as u64,

CedexError::PriceImpactExceeded // Error 6006

);

Ok(())

}

This mechanism forces market participants to provide liquidity gradually versus attempting sudden massive liquidation. Largelarge sellers mustto split orders across multiple transactions, allowing the market to absorb supply incrementally.incrementally rather than experiencing sudden price dislocations.

 

pub const MAX_PRICE_IMPACT_BPS: u16 = 200; // 2% maximum   pub fn check_price_impact(     proposed_trade: &SwapParams,     twap:           u64,     current_price:  u64, ) -> Result<()> {     let deviation_bps = ((current_price as i64 - twap as i64).abs() as u64)         .checked_mul(10_000)         .ok_or(CedexError::Overflow)?         / twap;       require!(         deviation_bps <= MAX_PRICE_IMPACT_BPS as u64,         CedexError::PriceImpactExceeded // Error 6006     );     Ok(()) }

 

Trade Size (% of pool)	Price Impact	Circuit Breaker Status
1%	~0.99%	✓ Allowed
2%	~1.96%	✓ Allowed
3%	~2.91%	✗ Blocked — 6006
5%	~4.76%	✗ Blocked — 6006

 

🔹5.6.2 5.5.2 Volume-Based HaltsHalt — Control 27

If any single wallet attempts to sell greatermore than 30% of circulating ST22 supply within a 24-hour period,window, transactiontrading executionfor pausesthat wallet is suspended for 24 hours:hours. This prevents coordinated dump scenarios while allowing normal institutional-size trading.

 

//Volume-BasedHaltImplementation
pub
fncheck_volume_limit(




pub const MAX_DAILY_SELL_PERCENT: u8  = 30;   // 30% maxof dailycirculating salesupply
pub const HALT_DURATION_SECONDS:  i64 = 86400;86_400; // 24 hours
 

pub struct WalletTrackingState {
    pub wallet:                Pubkey,
    pub daily_sell_amount:     u64,
    pub tracking_window_start: i64,
    pub is_halted:             bool,
    pub halt_expiry:           Option<i64>,
}





ctx: Context<VolumeCheck>,

sell_amount: u64,

) -> Result<()> {



let tracking = &mut ctx.accounts.wallet_tracking;
let circulating_supply = ctx.accounts.mint.supply;
// Reset tracking window if >24h elapsed
let current_time = Clock::get()?.unix_timestamp;

if current_time - tracking.tracking_window_start > HALT_DURATION_SECONDS {

tracking.daily_sell_amount = 0;

tracking.tracking_window_start = current_time;

}



// Check if halt is active

if tracking.is_halted {

if current_time < tracking.halt_expiry.unwrap() {

return Err(CedexError::WalletHalted.into());

}

tracking.is_halted = false;

}



// Check if this sale would exceed limit
let new_daily_total = tracking.daily_sell_amount + sell_amount;
let threshold = circulating_supply * MAX_DAILY_SELL_PERCENT as u64 / 100;

if new_daily_total > threshold {

tracking.is_halted = true;

tracking.halt_expiry = Some(current_time + HALT_DURATION_SECONDS);

return Err(CedexError::DailySellLimitExceeded.into());

}

tracking.daily_sell_amount = new_daily_total;



Ok(())

}
🔹5.6.3 5.5.3 Coordinated Activity Detection
CEDEX implements machine learning-ML-based detection of coordinated selling patternspatterns. suggesting manipulative intent. The algorithm analyzes fourFour correlation dimensions:dimensions are analyzed on every trade:

 



























Dimension



Analysis Method



Suspicious Threshold


Wallet Clusteringclustering


Graph analysis of common funding sources


>More than 5 wallets sharing a funding source


Timing Correlationcorrelation


Transaction timestamp clustering


>More than 3 sells within a 10-second window


Amount Correlationcorrelation


Statistical analysis of sale sizes


<Less than 5% variance across multiple coordinated sales


Price Impactimpact Correlationcorrelation


Sequential impact accumulation


Cumulative >impact exceeding 5% within 1 hour


 

When coordinated activity is detected, affected wallets enter 24-hour cooldown periods,periods and the compliance team receives alerts for manual review. Confirmed coordinated manipulation results in permanent blacklisting via Transfer Hook Control 34 (account frozen).

 
🔹5.6.4 5.5.4 Time-Weighted Average Price (TWAP)TWAP Oracle
The TWAP oracle provides manipulation-resistant price data for all circuit breaker calculations:
calculations. 

The 
//oracle TWAPmaintains Oraclea Implementation
rolling 
pub struct TwapOracle {

pub token_mint: Pubkey,

pub price_observations: Vec<PriceObservation>,

pub observation_window: i64, // 1 1-hour inwindow seconds
of 
pubprice min_observations:observations u32,with //a Minimumminimum of 60 observations required for a valid TWAP calculation. Any attempt to manipulate the spot price — for example, to create artificial circuit breaker conditions — is absorbed by the time-weighted average, which requires sustained manipulation across the full observation window to move.
}
 
impl TwapOracle {



pub fn calculate_twap(&self) -> Result {
let current_time = Clock::get()?.unix_timestamp;
let window_start = current_time - self.observation_window;
// Filter observations within window
let valid_observations: Vec<_> = self.price_observations

.iter()

.filter(|o| o.timestamp >= window_start)

.collect();



require!(

valid_observations.len() >= self.min_observations as usize,

OracleError::InsufficientObservations

);



// Time-weighted calculation
let mut weighted_sum: u128 = 0;
let mut total_time: u128 = 0;

for i in 1..valid_observations.len() {



let time_delta = valid_observations[i].timestamp -

valid_observations[i-1].timestamp;

weighted_sum += valid_observations[i-1].price as u128 * time_delta as u128;

total_time += time_delta as u128;

}



Ok((weighted_sum / total_time) as u64)

}

}
📋5.7 5.6 Order Types and Execution
CEDEX
5.7.1 supports multiple order types optimized for different trading strategies while maintaining compliance verification for all executions.

🔹 5.6.1 Market Orders




Market orders execute immediately at current pool prices, subject to slippage tolerance:Parameter
























Specification



Parameter
Specification
Execution Speedspeed


Immediate (— subject to compliance verificationpre-flight (~2-2–3 seconds)seconds total)


Price Guaranteeguarantee


None — executes at current CPMM pool price


Slippage Protectionprotection


Configurable (default 1%, maxmaximum 5%)


Partial Fillsfills


Not supported — all-or-nothing execution


Circuit Breakerbreaker


Rejects if price impact exceeds 2% TWAP deviation


 

🔹5.7.2 5.6.2 Limit Orders
Limit orders specify a maximum buy price or minimum sell price, executing only when the CPMM pool price reaches the specified threshold:threshold. All 42 Transfer Hook controls execute at the moment of limit order settlement — limit orders do not pre-authorize compliance status. If a wallet's KYC or accreditation has lapsed between order placement and execution, the settlement transaction reverts.

 
//LimitOrderData StructureenumOrderSide{




pub struct LimitOrder {
    pub order_id:    u64,
    pub owner:       Pubkey,
    pub token_mint:  Pubkey,
    pub side:        OrderSide,    // Buy or| Sell
    pub amount:      u64,          // Token amount
    pub limit_price: u64,          // Price threshold (lamportsLamports per token)token
    pub expiry:      i64,          // Unix timestamp
    pub status:      OrderStatus,  // Open | Filled | Cancelled | Expired
}
pub



Buy, // Execute when pool price <= limit_price

Sell, // Execute when pool price >= limit_price

}

pub enum OrderStatus {

Open,

Filled,

Cancelled,

Expired,

}

🔹 5.6.3 Swap Interface

The primary trading interface presents unified swap functionality:



// Swap Interface (TypeScript)
// User-facing swap interface

interface SwapRequest {

inputToken: 'SOL' | ST22Address;

outputToken: 'SOL' | ST22Address;

inputAmount: bigint;

minOutputAmount: bigint;

slippageTolerance: number; // Basis points

deadline: number; // Unix timestamp

}



// Response includes compliance verification status

interface SwapResponse {

transactionId: string;

inputAmount: bigint;

outputAmount: bigint;

effectivePrice: number;

priceImpact: number;

fees: {

protocol: bigint;

network: bigint;

};

complianceVerification: {

status: 'VERIFIED' | 'PENDING' | 'REJECTED';

hooks: HookResult[];

duration: number; // milliseconds

};

}
💸5.8 5.7 Fee Structure and Distribution
CEDEX
5.8.1 implements a transparent fee structure aligned with protocol sustainability and participant incentives. Unlike traditional exchanges with complex fee tiers, CEDEX applies uniform fees ensuring equal treatment of all market participants.

🔹 5.7.1 Transaction Fee Breakdown
Every CEDEX swap incurs a 5% total transaction fee (500 basis points), distributedconfigured asat follows:the SPL Token-2022 Transfer Fee Extension level — it cannot be bypassed by any wallet or trading interface. Distribution is automatic and on-chain:

 





































structure





Fee ComponentRecipient



Rate



BPS


Purpose


Lock Status


Issuer Allocationtreasury


2.00%


200


Revenue share to issuingtokenizing company treasury— accrues per trade


Withdrawable by issuer


StakingOTCM Rewardsstaking pool


1.50%


150


Distributed to OTCM token stakers (8-— 8–60% APY)APY


Distributed per epoch


Protocol Operationsoperations


1.06%


106


Infrastructure, compliance oracles, development


LiquidityWithdrawable Pool Growth
0.44%
Permanently locked inby OTCM LPProtocol
for

Global Unified CEDEX Pool


0.44%


44


Permanent pool depth — routes to Global Pool


PERMANENTLY LOCKED


TOTAL


5.00%


Complete500
fee

—


—


 

🔹5.8.2 5.7.2 Fee Distribution MechanismJustification


// Fee Distribution Implementation
pub fn distribute_fees(

fee_amount: u64,

issuer_treasury: &Pubkey,

staking_pool: &Pubkey,

protocol_treasury: &Pubkey,

liquidity_pool: &Pubkey,

) -> Result<()> {



// Fee distribution ratios (basis points of 5% fee)

const ISSUER_SHARE: u64 = 4000; // 40% of 5% = 2.00%

const STAKING_SHARE: u64 = 3000; // 30% of 5% = 1.50%

const PROTOCOL_SHARE: u64 = 2120; // 21.2% of 5% = 1.06%

const LP_SHARE: u64 = 880; // 8.8% of 5% = 0.44%



// Calculate individual amounts
let issuer_amount = fee_amount * ISSUER_SHARE / 10000;
let staking_amount = fee_amount * STAKING_SHARE / 10000;
let protocol_amount = fee_amount * PROTOCOL_SHARE / 10000;
let lp_amount = fee_amount * LP_SHARE / 10000;
// Execute transfers atomically

transfer_sol(issuer_amount, issuer_treasury)?;

transfer_sol(staking_amount, staking_pool)?;

transfer_sol(protocol_amount, protocol_treasury)?;

transfer_sol(lp_amount, liquidity_pool)?; // Permanently locked



emit!(FeeDistributed { ... });
Ok(())

}

🔹 5.7.3 Fee Comparison Analysis

Platform
Swap Fee
Compliance
LP Rewards
Issuer Rev
CEDEX
5.00%
✓ Full
8-60% APY
2.00%
Raydium
0.25%
✗ None
Variable
0%
Orca
0.30%
✗ None
Variable
0%
Pump.fun
1.00%
✗ None
None
0%

💡 Fee Justification

While CEDEX's 5% fee significantly exceeds traditionalstandard DEX fees,fees. itThe includespremium comprehensivereflects compliancethe verificationgenuine (infrastructure cost and value delivered: each trade incurs $2-2–5 per transaction in oracle costs)verification costs (Empire custody attestation, OFAC/SDN screening, AML scoring, TWAP price feed), funds issuer revenue sharing,sharing andthat makes the platform commercially viable for tokenizing companies, contributes permanent liquidity growth.depth to the Global Pool, and enforces the full Digital Securities compliance framework that makes the tokens legally tradeable in the first place. For institutional securities trading, this5% representscompares significantfavorably to the 7–10% all-in cost savings versusof traditional broker-dealer infrastructure.infrastructure for comparable compliance-grade execution.

 
🤖5.9 5.8 MEV Protection
Maximum Extractable Value (MEV) attacks representpose onea ofmaterial the most significant threatsrisk to DeFiinstitutional users, with an estimated $1.38 billion extracted from tradersinvestors in 2023any alone.blockchain trading environment. CEDEX implements multiple independent protection layers making MEV extraction economically unfeasible.unfeasible against ST22 trades.

 
🔹5.9.1 5.8.1 Frontrunning Prevention

Frontrunning occurs when malicious actors observe pending transactions and insert their own transactions ahead in the block order to profit from predictable price movements. CEDEX prevents frontrunning through:

Private Transaction Submission: Transactions route through Jito's private mempool, invisible to searchers until block inclusion
Slippage Enforcement: Strict slippage limits (default 1%) reduce profitability of frontrunning attempts
Circuit Breaker Integration: 2% price impact limit prevents large frontrun trades from executing

🔹 5.8.2 Sandwich Attack Mitigation

Sandwich attacks bracket victim transactions with buy-before and sell-after trades, extracting value through induced price movements. CEDEX's protection mechanisms:



// Sandwich Attack Prevention
// Sandwich Attack Scenario (Without Protection):
// 1. Attacker sees: User wants to buy 10,000 tokens
// 2. Attacker frontruns: Buys 50,000 tokens (price increases)
// 3. User trade executes: Buys at higher price
// 4. Attacker backruns: Sells 50,000 tokens (profit extracted)
// CEDEX Protection:
// 1. Transaction in private Jito mempool (invisible to attacker)
// 2. Even if visible, 2% circuit breaker blocks attacker's frontrun
// 3. User trade protected by slippage tolerance
// 4. Sequential large trades trigger coordinated activity detection

🔹 5.8.3 Jito Bundle Integration




CEDEX integrates with Jito's block-building infrastructure for institutional-grade MEV protection:Feature




















Implementation



Feature
Implementation
Bundle Submissionsubmission


All CEDEX trades submitted as Jito bundles with guaranteed atomicity — the trade either executes as a complete unit or not at all


Private Mempoolmempool


Transactions are invisible to searchers until block inclusion (— no public mempool exposure)exposure window


Priority Feesfees


Dynamic priority fee calculation forensures reliable block inclusion under network congestion


Backrun Protectionprotection


Bundle structure prevents insertion of any transaction between compliance verification and trade execution


⚡
 JITO
BUNDLE
5.9.2 MEV PROTECTIONSandwich Attack Prevention — TECHNICALStructural SPECIFICATION

Version: 6.0 | Applies To: All CEDEX trade submissions

Bundle Construction ArchitectureProof
EveryA CEDEXsandwich tradeattack isrequires submitted asinserting a buy transaction before and a sell transaction after the victim's trade. Jito bundle architecture makes this structurally impossible:

 

•       Private relay — aThe groupvictim's oftransaction is invisible in the public mempool — it exists only in Jito's private relay network until block inclusion

•       Atomic bundle — No transaction can be inserted between bundle transactions thatby areany atomicallyparty, includedincluding validators

•       Priority guarantee — Even if bundle contents were somehow leaked, the bundle tip gives the victim's transaction priority over any unbundled front-run attempt

•       Circuit breaker backstop — Even in athe blockworst or entirely excluded. This eliminatescase, the mempool2% visibilityprice windowimpact thatcircuit enablesbreaker frontrunning(Control and25) limits the economic value extractable from any individual trade, making sandwich attacks.attacks unprofitable even if technically executable
typescript 

5.9.3 
interface JitoBundleConfigFallback {
  // Jito block engine endpoints (regional for latency)
  blockEngineUrl: string;          // "https://mainnet.block-engine.jito.wtf"

  // Tip account — paid to Jito validators for bundle inclusion priority
  tipAccount: PublicKey;           // Jito tip account (rotated by Jito Labs)
  tipLamports: bigint;             // Dynamic — see tip calculation below

  // Bundle composition
  transactions: VersionedTransaction[];   // [0]: tip tx, [1..n]: trade txs

  // Expiry — bundle dropped if not included within window
  expirySlotOffset: number;        // 10 slots (~4 seconds) — configurable
}

// Tip calculation — proportional to trade size for priority
function calculateTipLamports(tradeSizeUsd: number): bigint {
  const BASE_TIP_LAMPORTS = 10_000n;          // ~$0.001 at $100 SOL
  const SIZE_MULTIPLIER = 0.0001;              // 0.01% of trade value
  const solPriceUsd = getCurrentSolPrice();
  const sizeTip = BigInt(
    Math.floor((tradeSizeUsd * SIZE_MULTIPLIER / solPriceUsd) * 1e9)
  );
  return BASE_TIP_LAMPORTS + sizeTip;
}

Bundle Failure HandlingMode
FailureIf Mode
Cause
CEDEX Response
Bundle timeout (>10 slots)
Network congestion or low tip
Resubmit with 2x tip — up to 3 attempts
Bundle simulation failure
Transfer Hook rejection
Return hook error code to user — no resubmit
Block engine unreachable
Jito infrastructure outage
Fallback to standard RPC submission with priority fee
Bundle partially included
Should not occur (atomic guarantee)
Log as critical alert — investigate immediately

Fallback Mode: Ifthe Jito block engine is unavailable for >more than 30 seconds, CEDEX automatically falls back to standard priority-fee RPC submission via Helius. In fallback mode, MEV protection is degraded —degraded. CEDEX displays a "'MEV Protection Degraded"Degraded' banner in the trading UIinterface and logs all fallback transactions for post-incident compliance review.
Sandwich
 Attack Prevention — Mathematical Proof

A sandwich attack requires an attacker to insert a buy transaction before and a sell transaction after the victim's trade. Jito bundles make this impossible because:

The victim's transaction is invisible in the public mempool — it exists only in Jito's private relay network
The bundle is atomic — no transaction can be inserted between bundle transactions by any party including validators
Even if the bundle contents leak, the attacker cannot front-run because the bundle tip gives the victim's bundle priority over unbundled transactions

Residual risk: A malicious Jito validator with block production rights could theoretically see bundle contents and sandwich around the entire bundle. This risk is mitigated by: (a) CEDEX's 2% price impact circuit breaker (Hook 5) limits sandwich profitability to near-zero, and (b) Jito's validator reputation system and slashing mechanisms disincentivize this behavior.
⚡5.10 5.9 Performance Specifications
 











































Metric



Specification



Notes


Throughput
(TPS)

400–600 TPS


400-600
Limited by compliance verification oracle latency


CompliancePre-flight Latencycompliance


2,000-000–3,000ms


Six primary hooks + oracle queries — runs before on-chain submission


Execution Latencylatency


400-400–600ms


CPMM swap post-verification


Block Finalityfinality


~13 seconds


32 Solana blocksblock confirmations


Compute Unitsunits


~800,000 CU


Per complete swap transaction including all 42 Transfer Hook controls


Network Feefee


~$0.01-01–$0.05


Solana base fee + dynamic priority fee


Order book sync


400ms


One Solana block — Helius RPC cluster synchronization


 

🏗️5.11 5.10 Security Architecture
CEDEX
5.11.1 security combines smart contract hardening, economic attack resistance, and operational security measures:

Smart Contract Security
•       Formal verification — CEDEX and Custom AMM pool logic formally verified using Certora Prover
Security prior to production deployment

•       Independent audits by— Quantstamp, Halborn, and OtterSec
Active bug— audit reports published publicly. CEDEX-specific scope: CPMM arithmetic, fee routing, circuit breaker logic, Transfer Hook integration points

•       Bug bounty program (up— Up to $100K rewards)
rewards for critical vulnerability reports. Priority targets: price impact calculation exploit, fee routing bypass, CPMM invariant violation, circuit breaker bypass

•       Immutable core contracts post-deployment— CEDEX and AMM pool contracts use no upgrade proxy pattern — eliminating the attack surface where an upgrade could introduce unauthorized fund extraction

 

5.11.2  Economic Security

•       Flash loan attack prevention — Circuit breakers (price impact + volume halt) prevent the large coordinated trades required to make flash loan attacks
 profitable

•       Price manipulation resistance — TWAP oracle resistsrequires sustained manipulation across a 60-observation, 1-hour window to move the circuit breaker reference price
manipulation
Permanent
•       liquidityCoordinated locksdump prevention — Volume halt (30% daily limit per wallet) and coordinated activity detection prevent rugthe pulls
Volumemulti-wallet limitsstrategies preventused coordinatedin dumpsorganized market manipulation

•       Wash trading detection — Timing correlation and amount correlation analysis identifies and blacklists wash trading patterns

 

5.11.3  Operational Security

•       Multi-signature admin keys— (4-of-7 threshold)
threshold for any parameter change — geographically distributed key holders

•       48-hour timelock on— All governance-approved parameter changes
 subject to 48-hour timelock before execution

•       Real-time monitoring and— alerting
Automated anomaly detection on all CEDEX order flow with incident escalation to compliance team

•       Incident response playbooks— ---
Documented and tested runbooks for P0 (active exploit), P1 (service degradation), P2 (partial failure), and P3 (monitoring alerts)

 








Groovy Company, Inc. dba OTCM Protocol  |  CIK: 1499275  |  Version 7.0  |  March 2026  |  Confidential




 
            
    

            
        
    

    

    

    

        

             Back to top