📈 Section 5: CEDEX — Centralized-Decentralized Exchange

📈 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

SPLCEDEX Token-2022(Centralized-Decentralized TransferExchange) Hooks representrepresents a fundamental architecturalreimagining innovationof indecentralized blockchain-basedexchange architecture, purpose-built from inception for trading tokenized securities infrastructure, enabling execution of arbitrary smart contract code during token transfers on the Solana blockchain. This capability transforms compliance from a discretionary administrative function into an immutable, mathematically-enforced property of the token itself.

OTCM Protocol leverages Transfer Hooks to implementwithin federal securities law requirementsframeworks. Unlike existing DEX platforms that were designed for permissionless cryptocurrency trading and subsequently face irreconcilable conflicts with securities regulation, CEDEX implements compliance verification as non-discretionarya smartfoundational contractarchitectural code,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 astrong paradigmarchitectural wherepressure regulatoryagainst 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 mattertechnical limitation that can be solved with additional development. It represents a fundamental architectural conflict where the design goals of corporatepermissionless policytrading butand ofregulated cryptographicsecurities certainty.trading Everyare mutually exclusive.

🔹 5.1.2 Why Existing DEXs Cannot Support ST22 transfer triggers sequential execution of six independent verification hooks, completing comprehensive compliance verification before transaction settlement.

---

5.1.1 📋 SPL Token-2022 Standard OverviewTokens

SPLBeyond Token-2022philosophical (alsodesign knownconflicts, asexisting TokenDEX Extensionscodebases Program)face isconcrete Solana'stechnical next-generationbarriers preventing ST22 token standard, introducing programmable extensions that enable sophisticated token functionality impossible with the original SPL Token Program:support:

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

🔑custody

Permanentverification, Delegate

IrrevocableOFAC transferscreening, authority

Protocol-leveland recoveryAML capability

🔒

Confidential Transfers

Zero-knowledge encrypted amounts

Future: Privacy-preserving compliance

💵

Transfer Fee

Protocol-level fee collection

5% fee distribution automation

📋

Metadata Pointer

On-chain token metadata

Security details, issuer info, CUSIP

🎫

Non-Transferable

Soulbound token capability

Compliance NFTs, investor credentials

5.1.2 ⚙️ Transfer Hook Extension Mechanism

The Transfer Hook extension enables token mints to specify a program that must be invoked during every token transfer. This mechanism operates atchecks—making the Solana runtime level, making it impossible to transfer tokens withoutnon-compliant executing the hook program:securities.

rust

🔹

// Transfer Hook Extension Data Structure
pub struct TransferHook {
    /// The program ID that implements the transfer hook
    pub program_id: Pubkey,
    /// Optional: Authority that can update the hook program
    pub authority: Option<Pubkey>,
}

// When a transfer occurs, Solana runtime automatically:
// 1. Checks if mint has TransferHook extension
// 2. If yes, invokes the specified program_id with transfer context
// 3. If hook returns error, ENTIRE transaction reverts
// 4. If hook succeeds, transfer completes

// ⚠️ This is MANDATORY - there is no way to bypass the hook
// The token literally cannot move without hook approval

---

5.1.3 📜The Compliance-as-CodeCEDEX Design Philosophy

OTCM'sCEDEX Transferinverts Hooktraditional implementationDEX embodiesdesign 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."

"Compliance-as-Code"This philosophical inversion creates three categorical advantages:

• Compliance regulatoryIntegration requirementsat areDesign translatedPhase: intoVerification deterministiclogic integrates at system design phase rather than being retrofitted. Every smart contract logic that executes identicallyinstruction, every time,data withoutstructure, humanevery discretion,execution administrativepath override,was ordesigned interpretation variability.

  "Traditionalwith compliance asks:verification 'Didas youa followfirst-class therequirement.

• Optimized rules?'Smart OTCM'sContract TransferArchitecture: HooksSmart ask:contract 'Canarchitecture youoptimizes mathematicallyfor provecompliance 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.

The answerdistinction isbetween alwayscompliance-first verifiableand on-chain."compliance-retrofitted architecture has profound implications for system reliability, security, and regulatory acceptance:

4.2

5.1.4Custom ⚖️AMM Regulatory Advantages

TransferCEDEX Hookimplements executiona providesmodified regulatoryAutomated advantagesMarket unattainableMaker through(AMM) traditionalarchitecture complianceengineered procedures:

💡 SEC Modernization Alignment: OTCM's Transfer Hook architectureintegration. alignsUnlike withtraditional SECAMMs Chairthat Gensler'sexecute statedtoken goalswaps ofas 'bringingatomic cryptooperations, CEDEX separates compliance verification from trading execution into compliance'distinct andarchitectural thelayers, SECenabling Crypto Task Force's exploration of blockchain-nativeasynchronous compliance mechanisms.

5.2 🔄 Transfer Hook Execution Flow

This section details the precise execution sequence when an ST22 token transfer is initiated, fromblocking user action through final settlement.interaction.

🔹

5.2.1 🪝Dual-Layer HookExecution Invocation SequenceModel

WhenThe adual-layer userexecution initiatesmodel anrepresents ST22CEDEX's transfer,core thearchitectural followinginnovation: sequencesegregating executes:compliance verification from trading execution while maintaining atomic transaction guarantees.

// Dual-Layer Architecture Diagram
┌─────────────────────────────────────────────────────────────────────────┐
│                   🪝CEDEX ST22 TRANSFER HOOKDUAL-LAYER EXECUTION SEQUENCEMODEL                      │
└─────────────────────────────────────────────────────────────────────────┘

User InitiatesRequest

│
▼
┌────────────────────────────────────────────────────────────────────┐
│              ☀️COMPLIANCE SOLANAVERIFICATION RUNTIME: Detects TransferHook extension on ST22 mintLAYER                         │
│  Invokes┌──────────────────────────────────────────────────────────────┐  OTCM│
Transfer│  │  Asynchronous Execution (2,000-3,000ms)                      │  │
│  │                                                              │  │
│  │  Hook Program1: Custody ──► Hook 2: OFAC ──► Hook 3: AML            │  │
│  │  Hook 4: KYC ──► Hook 5: Price Impact ──► Hook 6: LP Ratio   │  │
│  │                                                              │  │
│  │  Result: VERIFIED | REJECTED (with transfererror contextcode)               │  │
│  └────────────────────────────┬──────────────────────────────────┘  │
└────────────────────────────────┬───────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────────────────┐
│                🔍TRADING HOOKEXECUTION 1: CUSTODY VERIFICATIONLAYER                             │
│  ⏱️ (100-150ms)┌──────────────────────────────────────────────────────────────┐  │
│  Query│  EmpireSynchronous StockExecution Transfer(400-600ms)                           →│  Verify│
1:1│  backing│                                                              →│  Error│
6001│  │  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:

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

🔹 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 HOOK 2: OFAC SCREENING                     │
│                         ⏱️ (200-500ms)                           │
│  Check SDN List → Address clustering → Error 6002                │
└────────────────────────────┬─────────────────────────────────────┘
                             │ ✅ PASS
                             ▼
┌──────────────────────────────────────────────────────────────────┐
│                    🕵️ HOOK 3: AML ANALYTICS                      │
│                         ⏱️ (300-400ms)                           │
│  ML risk scoring → 200+ features → Error 6003                    │
└────────────────────────────┬─────────────────────────────────────┘
                             │ ✅ PASS
                             ▼
┌──────────────────────────────────────────────────────────────────┐
│                    🪪 HOOK 4: REDEMPTION ELIGIBILITY             │
│                         ⏱️ (50-100ms)                            │
│  KYC status → Accreditation → 72hr cooling → Error 6004          │
└────────────────────────────┬─────────────────────────────────────┘
                             │ ✅ PASS
                             ▼
┌──────────────────────────────────────────────────────────────────┐
│                    📉 HOOK 5:CURVE PRICE IMPACT LIMIT                 │
│                         ⏱️ (50-100ms)                            │
│  Calculate impact → Compare TWAP → 2% threshold → Error 6006     │
└────────────────────────────┬─────────────────────────────────────┘
                             │ ✅ PASS
                             ▼
┌──────────────────────────────────────────────────────────────────┐
│                    💧 HOOK 6: LIQUIDITY SUFFICIENCY              │
│                         ⏱️ (50-100ms)                            │
│  Check LP ratio → 150% minimum → Error 6007                      │
└────────────────────────────┬─────────────────────────────────────┘
                             │ ✅ PASS
                             ▼
┌──────────────────────────────────────────────────────────────────┐
│                    ✅ ALL HOOKS PASSED                           │
│              Transfer executes, transaction commits              │
│                 Settlement: ~13 seconds (32 blocks)DISCOVERY                        │
└─────────────────────────────────────────────────────────────────────────┘

5.2.2 📊 Sequential vs Parallel Execution

OTCM implements sequential hook execution rather than parallel for critical security reasons:

Sequential│ execution╭──╯ ensures$0.001│______________╭───╯ that if Hook 1 (Custody Verification) fails, Hooks 2-6 never execute—saving oracle costs and compute resources. It also provides deterministic error reporting: users always know which specific hook rejected their transaction.

5.2.3 ⚛️ Atomic Transaction Guarantees

Solana's account model provides atomic transaction guarantees: if any hook fails, the entire transaction reverts as if it never occurred. There is no intermediate state where tokens have transferred but compliance verification is incomplete.

┌└──────────────┴──────────────────────────────────────────────►

Tokens Issued (millions)

│◄── Early Buyers ──►│◄──── Growth Phase ────►│◄─ Graduation ──────────┐► │

🔹 ATOMIC5.4.2 EXECUTIONLinear GUARANTEEBonding │Curve └─────────────────────────────────────────────────────────────────┘Mathematics

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

// Bonding Curve Price Formula
// ScenarioLinear A:Bonding AllCurve hooksFormula

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

// Parameters:
// Result:initialPrice Transaction= commits,$0.001 tokensper move,token state(starting updatesprice)
// ScenariopriceGradient B:= Hook0.001% 3per (AML)token rejects due to risk score ❌sold
// Result:Example ENTIRE transaction revertscalculations:
// •At No0 tokens movedsold:      P = $0.001 + (0.00001 × 0) = $0.001
// •At No1M feestokens chargedsold:     P = $0.001 + (0.00001 × 1,000,000) = $0.011
// •At No10M statetokens changessold:    P = $0.001 + (0.00001 × 10,000,000) = $0.101
// •At Error25M returnedtokens tosold:    user:P 6003= $0.001 + (AML_RISK_EXCEEDED)0.00001 × 25,000,000) = $0.251

Implementation

// Bonding Curve Implementation (Rust)

pub struct BondingCurve {

pub token_mint: Pubkey,

pub initial_price: u64, // ⚠️In Therelamports is(0.001 NOSOL partial= execution1,000,000 statelamports)

pub price_gradient: u64, // ThisPrice isincrease guaranteedper bytoken Solana(in runtime,lamports)

pub OTCMtokens_issued: codeu64, // 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.2.43.3 ⏱️Graduation ExecutionCriteria

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

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.34.4 🔍Transition Hookto 1:Permanent Custody Verification Oracle

TheUpon Custodygraduation, Verificationthe Oraclefollowing confirmsirreversible thatstate alltransitions circulatingoccur:

• Bonding tokensCurve areDeactivation: backedSmart 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 equivalentany equityparty sharesincluding heldprotocol atadministrators

5.3.1 🏗️ Oracle Architecture

The custody oracle operates as a cryptographically-signed data feed from Empire Stock Transfer's registry systems:

rust

// CustodyGraduation Oracle Data Structure
pub struct CustodyOracleData {
    /// CIK number of the issuing company
    pub issuer_cik: [u8; 10],
    /// CUSIP identifier for the security
    pub cusip: [u8; 9],
    /// Share class (Series M preferred)
    pub share_class: ShareClass,
    /// Total shares held in custody
    pub custodied_balance: u64,
    /// Total ST22 tokens in circulation
    pub circulating_tokens: u64,
    /// Ed25519 signature from Empire's HSM
    pub attestation_signature: [u8; 64],
    /// Merkle root of current shareholder registry
    pub registry_hash: [u8; 32],
    /// Unix timestamp of attestation
    pub attestation_timestamp: i64,
    /// Block height when attestation was recorded
    pub attestation_slot: u64,
}

5.3.2 🏛️ Empire Stock Transfer Integration

Empire Stock Transfer provides real-time custody attestations through a dedicated API integration:

5.3.3 ⚠️ Discrepancy Detection

The hook implements strict discrepancy detection with configurable thresholds:

rust

// Custody Verification ImplementationFunction (Rust/Anchor)
pub const MAX_DISCREPANCY_BPS: u64 = 1;  // 0.01% maximum discrepancy

pub fn verify_custody(graduate_to_amm(ctx: oracle_data: &CustodyOracleData,
    transfer_amount: u64,
Context<Graduate>) -> Result<()> {
let curve = &mut ctx.accounts.bonding_curve;
let pool = &mut ctx.accounts.cpmm_pool;
// Verify signaturegraduation authenticitycriteria verify_ed25519_signature(met
&oracle_data.attestation_signature,require!(

curve.check_graduation_criteria()?,

CedexError::GraduationCriteriaNotMet

);

// CheckPermanently attestationdisable freshnessbonding (maxcurve

curve.is_graduated = true;

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

// current_timeInitialize -CPMM oracle_data.attestation_timestamppool <with migrated liquidity

pool.sol_reserve = 600,curve.sol_reserve;

pool.token_reserve = curve.tokens_issued;

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

pool.liquidity_locked = true; // 6001PERMANENT - 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
// CalculatePre-swap discrepancystate:

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 expected_tokensspot_price = oracle_data.custodied_balance;output_reserve letas actual_tokens = oracle_data.circulating_tokens;
    let discrepancy = if expected_tokens > actual_tokens {
        expected_tokens - actual_tokens
    } else {
        actual_tokens - expected_tokens
    };
    
    let discrepancy_bps = discrepancy * 10000f64 / expected_tokens;input_reserve require!(as discrepancy_bps <= MAX_DISCREPANCY_BPS,
        CustodyError::CustodyDiscrepancyf64;
// 6001Effective );
    
    // Verify sufficient custodyprice for this transfertrade
require!(let oracle_data.custodied_balanceoutput_amount >= transfer_amount,calculate_output(input_amount, CustodyError::InsufficientCustodyinput_reserve, output_reserve);
let effective_price = output_amount as f64 / input_amount as f64;
// 6001Price );impact Ok(as percentage
let impact = ())spot_price }- effective_price) / spot_price * 100.0;

📋 Regulatory Reference: 17 CFR Section 240.17a-1 et seq. — Transfer Agent Custody Requirements

❌ Error Code 6001: CUSTODY_VERIFICATION_FAILED Indicates custody verification failure. Possible causes: stale attestation (>10 min), discrepancy >0.01%, insufficient custodied shares, or invalid Empire signature. User should wait for fresh attestation or contact issuer.

5.4 🚫 Hook 2: OFAC Sanctions Screening

The OFAC Sanctions Screening hook prevents transactions to or from wallets associated with the Office of Foreign Assets Control's Specially Designated Nationals (SDN) list, implementing federal sanctions law requirements at the protocol level.

5.4.1 📋 SDN List Integration

OTCM maintains an on-chain oracle updated hourly from OFAC's official SDN list, supplemented by blockchain-specific address intelligence:impact.abs()

rust

// OFAC Screening Implementation
pub struct OfacOracleData {
    /// Merkle root of current SDN list
    pub sdn_merkle_root: [u8; 32],
    /// Number of entries in SDN list
    pub sdn_entry_count: u32,
    /// Blockchain-specific blocked addresses
    pub crypto_sdn_addresses: Vec<Pubkey>,
    /// Last update timestamp
    pub last_update: i64,
    /// OFAC publication reference
    pub publication_id: [u8; 16],
}

// Screening checks BOTH sender and recipient
pub fn screen_ofac(
    sender: &Pubkey,
    recipient: &Pubkey,
    oracle: &OfacOracleData,
) -> Result<OfacScreeningResult> {
    // Direct address matching
    let sender_blocked = oracle.crypto_sdn_addresses.contains(sender);
    let recipient_blocked = oracle.crypto_sdn_addresses.contains(recipient);
    
    if sender_blocked || recipient_blocked {
        return Err(OfacError::SanctionedAddress.into());  // 6002
    }
    
    // Address clustering analysis (see 5.4.2)
    check_cluster_association(sender, recipient, oracle)?;
    
    Ok(OfacScreeningResult::Clear)
}

5.4.2 🔗 Address Clustering Analysis

Beyond direct SDN address matching, OTCM implements sophisticated address clustering analysis to detect wallets associated with sanctioned entities:

5.4.3 📜 Implementation

rust

// Cluster Analysis Implementation
pub fn check_cluster_association(
    sender: &Pubkey,
    recipient: &Pubkey,
    oracle: &OfacOracleData,
) -> Result<()> {
    // Query clustering oracle for both addresses
    let sender_cluster = get_cluster_data(sender)?;
    let recipient_cluster = get_cluster_data(recipient)?;
    
    // Check for SDN cluster membership
    if sender_cluster.sdn_association_score > 70 {
        return Err(OfacError::ClusterAssociation {
            address: *sender,
            score: sender_cluster.sdn_association_score,
            reason: "High SDN cluster association".to_string(),
        }.into());
    }
    
    if recipient_cluster.sdn_association_score > 70 {
        return Err(OfacError::ClusterAssociation {
            address: *recipient,
            score: recipient_cluster.sdn_association_score,
            reason: "High SDN cluster association".to_string(),
        }.into());
    }
    
    Ok(())
}

📋 Regulatory Reference: 31 CFR § 500-598 — OFAC Sanctions Administration Regulations

❌ Error Code 6002: OFAC_SANCTIONS_MATCH Indicates wallet is blocked due to OFAC sanctions. This is a PERMANENT block—the wallet cannot transact ST22 tokens. There is no appeal process through OTCM; affected parties must resolve sanctions status with OFAC directly.

5.5 🕵️ Hook 3: Blockchain Analytics Screening

The Blockchain Analytics Screening hook implements Bank Secrecy Act Anti-Money Laundering (AML) requirements through machine learning-based risk assessment, analyzing 200+ transaction features to identify money laundering patterns, sanctions evasion, theft proceeds, and coordinated suspicious activity.

5.5.1 🤖 ML Risk Assessment

OTCM integrates with institutional-grade blockchain analytics providers to execute real-time risk assessment on every transfer:

rust

// AML Risk Assessment Data Structure
pub struct AmlRiskAssessment {
    /// Overall risk score (0-100)
    pub risk_score: u8,
    /// Risk category breakdown
    pub categories: AmlRiskCategories,
    /// Specific risk flags triggered
    pub triggered_flags: Vec<AmlFlag>,
    /// Confidence in assessment
    pub confidence: u8,
    /// Model version used
    pub model_version: [u8; 8],
}

pub struct AmlRiskCategories {
    pub sanctions_evasion: u8,      // 0-100
    pub money_laundering: u8,       // 0-100
    pub theft_proceeds: u8,         // 0-100
    pub darknet_exposure: u8,       // 0-100
    pub mixer_exposure: u8,         // 0-100
    pub gambling_exposure: u8,      // 0-100
    pub coordinated_activity: u8,   // 0-100
}

5.5.2 📊 Risk Scoring Model

The risk scoring model classifies transactions into three tiers with automated responses:

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

🔹 5.5.4.3 🔬Slippage Chainalysis/TRM IntegrationProtection

OTCMCEDEX integratesprovides withconfigurable industry-leadingslippage blockchainprotection analyticsensuring providers:users receive expected value:

5.5.4 📜 Implementation

rust

// AMLSlippage ScreeningProtection Implementation

pub conststruct LOW_RISK_THRESHOLD:SwapParams u8{

pub constinput_amount: HIGH_RISK_THRESHOLD:u64,

pub fn screen_aml( sender: &Pubkey, recipient: &Pubkey, amount:min_output: u64, ) -> Result<AmlScreeningResult> { // QueryMinimum analyticsacceptable providersoutput

pub sender_riskmax_slippage_bps: = query_chainalysis(sender)?; let recipient_risk = query_chainalysis(recipient)?;u16, // UseMaximum higher of two risk scores let max_risk = sender_risk.risk_score.max(recipient_risk.risk_score); match max_risk { 0..=30 => Ok(AmlScreeningResult::AutoApprove), 31..=70 => { // Queue for enhanced review but allow transaction emit!(EnhancedReviewQueued { sender: *sender, recipient: *recipient, risk_score: max_risk, amount, }); Ok(AmlScreeningResult::ApproveWithReview) }, 71..=100 => { // Auto-reject high-risk transactions Err(AmlError::RiskThresholdExceeded { score: max_risk, threshold: HIGH_RISK_THRESHOLD, }.into()) // 6003 }, _ => unreachable!(), } }

📋 Regulatory Reference: 31 CFR § 1010 — Bank Secrecy Act AML Requirements

❌ Error Code 6003: AML_RISK_EXCEEDED Transaction rejected due to high AML risk score (71-100). Wallet may have exposure to: money laundering, sanctions evasion, theft proceeds, darknet markets, or coordinated suspicious activity. Appeal requires compliance review.

5.6 🪪 Hook 4: Redemption Eligibility Verification

The Redemption Eligibility Verification hook implements a critical distinctionslippage in OTCM'sbasis compliance architecture: while permissionless trading allows any wallet to purchase and transfer ST22 tokens, redemption (conversion to underlying equity shares) requires investor verification in accordance with federal securities law.

5.6.1 📋 KYC/AML Requirements

Before a wallet can redeem ST22 tokens for underlying shares, the beneficial owner must complete comprehensive verification:

5.6.2 🎖️ Accredited Investor Verification

For offerings conducted under SEC Regulation D Rule 506(c), additional accreditation verification is required:points

rust

// Accreditation Status Types
pub enum AccreditationStatus {
    /// Not verified - cannot redeem Reg D offerings
    NotVerified,
    /// Verified accredited investor
    Accredited {
        method: AccreditationMethod,
        verification_date: i64,
        expiration_date:deadline: i64, // TypicallyUnix 90timestamp days
        verifier: String,      // e.g., "VerifyInvestor.com"
    },
    /// Non-accredited but permitted (Reg A+ or Reg CF)
    NonAccreditedPermitted {
        regulation: OfferingRegulation,
        investment_limit: u64,
    },
}

pub enum AccreditationMethod {
    Income,         // $200K/$300K annual income
    NetWorth,       // $1M+ net worth excluding residence
    Professional,   // Series 7, 65, or 82 license
    Entity,         // Qualified entity (bank, trust, etc.)
    KnowledgeTest,  // SEC proposed "accreditation exam"
}

5.6.3 📜 Implementation

rustexpiry

}

// Redemption Eligibility Verification
pub fn verify_redemption_eligibility(execute_swap_with_protection(

ctx: &Pubkey,Context<Swap>,

params: &Pubkey,SwapParams,

) -> Result<()> {

// LoadCheck investordeadline
recordrequire!(

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

SwapError::DeadlineExceeded

);

// Calculate output
let investoroutput = get_investor_record(wallet)calculate_output(...)?;
// CheckVerify KYCslippage completiontolerance
require!(

output >= cooling_period,params.min_output,

SwapError::SanctionsCoolingPeriodSlippageExceeded

);

// 6004Execute );swap

execute_swap(output)?;

Ok(())
}

📋}

Regulatory

🔹 Reference:5.4.4 17Liquidity CFRDepth 230.506(c)Analysis

—

Pool Regulationliquidity Ddepth Accrediteddetermines Investortrading Requirementsefficiency. CEDEX targets minimum liquidity levels ensuring acceptable price impacts:

❌Pool ErrorTVL	Max Code 6004: REDEMPTION_ELIGIBILITY_FAILED Wallet not eligible for redemption. Possible causes: KYC incomplete, sanctions cooling period activeTrade (<72h)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), accreditationthese expired/missingprotections foroperate Regat Dthe offerings.smart Note:contract Tradinglevel iswith stillno permitted;administrative onlyoverride redemptioncapability.

to

🔹 shares is blocked.

5.7 📉 Hook 5:5.1 Price Impact Circuit Breaker

TheCEDEX Priceenforces Impacta Circuithard Breakerlimit preventson price impact per transaction. Any single transactions from causing excessive market movement, implementing regulatory objectives prohibiting manipulative trading devices. Any transaction causing greater than 2% price movement against the Time-Weighted Average Price (TWAP) oracle is automatically rejected.rejected:

// 
5.7.1Price 📊Impact Limit Implementation

pub fn check_price_impact(

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!(

Ok(())

// Volume-Based Halt Implementation

pub fn check_volume_limit(

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;

// Check if halt is active

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

Ok(())

// TWAP Oracle Implementation

pub fn get_reference_price(calculate_twap(&self) -> Result<u64> {
//let Usecurrent_time shorter= TWAPClock::get()?.unix_timestamp;
forlet morewindow_start responsive= circuitcurrent_time breakers- self.observation_window;
// but require minimumFilter observations towithin preventwindow
manipulationlet valid_observations: Vec<_> = self.price_observations

require!(

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

let time_delta = valid_observations[i].timestamp -

Ok((weighted_sum / total_time) as u64)

// Limit Order Data Structure

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

// Response includes compliance verification status

// Fee Distribution Implementation
pub const MAX_PRICE_IMPACT_BPS: u64 = 200;  // 2.00%

pub fn check_price_impact(distribute_fees(

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

// Calculate individual amounts
let twapissuer_amount = pool.twap_oracle.get_reference_price()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

emit!(new_sol_reserve, new_token_reserve) = match trade_directionFeeDistributed { TradeDirection::Buy => (
            pool.sol_reserve + trade_amount,
            pool.token_reserve - calculate_output(trade_amount, pool)?,
        ),
        TradeDirection::Sell => (
            pool.sol_reserve - calculate_output(trade_amount, pool)?,
            pool.token_reserve + trade_amount,
        ),... };
    
    let post_trade_price = new_sol_reserve * 1_000_000_000 / new_token_reserve;
    
    // Calculate deviation from TWAP
    let deviation = if post_trade_price > twap {
        (post_trade_price - twap) * 10000 / twap
    } else {
        (twap - post_trade_price) * 10000 / twap
    };
    
    require!(
        deviation <= MAX_PRICE_IMPACT_BPS,
        CircuitBreakerError::PriceImpactExceeded {
            expected_impact_bps: deviation,
            max_allowed_bps: MAX_PRICE_IMPACT_BPS,
        }  // 6006
    );
Ok(())
}

📋}

Regulatory

🔹 Reference:5.7.3 17Fee CFRComparison 240.10b-5(b)Analysis

—

Platform	Swap ProhibitionFee	Compliance	LP onRewards	Issuer ManipulativeRev
CEDEX	5.00%	✓ TradingFull	8-60% DevicesAPY	2.00%
Raydium	0.25%	✗ None	❌Variable	0%
Orca	0.30%	✗ ErrorNone	Variable	0%
Pump.fun	1.00%	✗ CodeNone	None	0%

6006:

💡 PRICE_IMPACT_EXCEEDEDFee 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 wouldSubmission: causeTransactions >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 movementimpact limit prevents large frontrun trades from TWAP.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 shouldwants reduceto buy 10,000 tokens
// 2. Attacker frontruns: Buys 50,000 tokens (price increases)
// 3. User trade sizeexecutes: orBuys splitat into multiple smaller transactions. This protects all market participants from suddenhigher price
manipulation.

🔹 5.8.13 📊Jito 150%Bundle Ratio RequirementIntegration

TheCEDEX 150%integrates over-collateralizationwith providesJito's ablock-building safetyinfrastructure bufferfor ensuringinstitutional-grade redemptionsMEV can always be honored:protection:

⚡

5.8.2 📜 Implementation

rust

// Liquidity Sufficiency Check
pub const MIN_SUFFICIENCY_RATIO_BPS: u64 = 15000;  // 150%

pub fn check_liquidity_sufficiency(
    pool: &UnifiedLiquidityPool,
    redemption_amount: u64,
) -> Result<()> {
    // Calculate current ratio
    let locked_capital = pool.total_sol_reserve;
    let circulating_value = calculate_total_circulating_value(pool)?;
    
    // Add redemption impact
    let post_redemption_capital = locked_capital - redemption_amount;
    let post_redemption_ratio = post_redemption_capital * 10000 / circulating_value;
    
    require!(
        post_redemption_ratio >= MIN_SUFFICIENCY_RATIO_BPS,
        LiquidityError::InsufficientLiquidity {
            current_ratio: post_redemption_ratio,
            required_ratio: MIN_SUFFICIENCY_RATIO_BPS,
        }  // 6007
    );
    
    Ok(())
}

📋 Regulatory Reference: Securities Exchange Act Rule 15c2-11 — Capital Adequacy Requirements

❌ Error Code 6007: LIQUIDITY_INSUFFICIENT Pool ratio below 150% threshold. Redemptions temporarily paused until trading volume rebuilds reserves. Regular ST22 trading (non-redemption) remains permitted. Users can wait for ratio recovery or reduce redemption amount.

5.9 🛡️ Thirty-Six Supplementary Security Controls

Beyond the six primary Transfer Hooks, OTCM implements thirty-six supplementary security controls integrated into the transfer hook logic, creating a comprehensive 42-point security framework.

5.9.1 📜 Smart Contract Controls (1-6)

5.9.2 🔐 Access Control Framework (7-12)

5.9.3 ⚛️ Transaction Integrity Controls (13-18)

5.9.4 🔮 Oracle & Data Controls (19-24)

5.9.5 👁️ Monitoring & Alerting (25-30)

5.9.6 🏛️ Governance & Recovery (31-36)

5.10 ⚠️ Error Handling and Recovery

5.11 📊 Performance Specifications

🏗️

5.12 🔍10 Security Audit StatusArchitecture

rewards)