📈 Section 5: CEDEX — Centralized-Decentralized Exchange Layers 4 & 5

📈 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 for Digital Securities compliance.

💡 5.1 Architectural Innovation

CEDEX (Centralized-Decentralized Exchange) represents a fundamental reimagining of decentralized exchange architecture, purpose-built from inception 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 — financial instruments formatted as crypto assets with ownership recorded on a crypto network. CEDEX is the only exchange built to enforce every compliance obligation that classification entails on every single trade.

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

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

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

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.

⚠️ 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

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)

🏗️ 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:

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.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 delivers Web2-grade user experience with Web3-grade settlement finality.

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.2 Compliance Verification Layer

Before any trade executes on-chain, CEDEX runs a pre-flight compliance check against the investor's current verification status. This check queries 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 gas.

🔹 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 code enabling rapid diagnosis.

🔹 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). This synchronization ensures no price discrepancy between displayed quotes and executable on-chain prices during 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

/// Overflow-safe CPMM swap output calculation
/// 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% 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 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. 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:

// Price Impact 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()

}

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

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:

// 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. Large sellers must split orders across multiple transactions, 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:

// Volume-Based Halt Implementation

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>,

}

pub fn check_volume_limit(

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.5.3 Coordinated Activity Detection

CEDEX implements machine learning-based detection of coordinated selling patterns suggesting manipulative intent. The algorithm analyzes four correlation dimensions:

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

The TWAP oracle provides manipulation-resistant price data for circuit breaker calculations:

// TWAP Oracle Implementation

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 {
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.6 Order Types and Execution

CEDEX 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
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

Limit orders specify maximum buy price or minimum sell price, executing only when pool price reaches specified threshold:

// Limit Order Data Structure

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 (lamports per token)

pub expiry: i64, // Unix timestamp

pub status: OrderStatus,

}

pub enum OrderSide {

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.7 Fee Structure and Distribution

CEDEX 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), distributed as follows:

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 for depth
TOTAL	5.00%	Complete fee structure

🔹 5.7.2 Fee Distribution Mechanism

// 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 exceeds traditional DEX fees, it includes comprehensive compliance verification ($2-5 per transaction in oracle costs), issuer revenue sharing, and permanent liquidity growth. For institutional securities trading, this represents significant cost savings versus traditional broker-dealer infrastructure.

🤖 5.8 MEV Protection

🔹 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
Bundle Submission	All CEDEX trades submitted as Jito bundles with guaranteed atomicity
Private Mempool	Transactions invisible until block inclusion (no public mempool exposure)
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.0 | Applies To: All CEDEX trade submissions

Bundle Construction Architecture

Every CEDEX trade is submitted as a Jito bundle — a group of transactions that are atomically included in a block or entirely excluded. This eliminates the mempool visibility window that enables frontrunning and sandwich attacks.

typescript

interface JitoBundleConfig {
  // 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 Handling

Failure 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: 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 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.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

CEDEX security combines smart contract hardening, economic attack resistance, and operational security measures:

Smart Contract Security

Formal verification using Certora Prover
Security audits by Quantstamp, Halborn, and 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 parameter changes
Real-time monitoring and alerting
Incident response playbooks ---