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

📈 SECTION 5: CEDEX — CENTRALIZED-DECENTRALIZED EXCHANGE

💡 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<u64> {
// 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<Graduate>) -> 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.

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

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

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

⚡ 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 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━