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

OTCM PROTOCOL Comprehensive Technical Whitepaper  —  Version 7.0 ST22 Digital Securities Platform  |  March 2026  |  Groovy Company, Inc. dba OTCM Protocol

 

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

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

 

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

 

PART A — LAYER 4: CUSTOM AMM ENGINE

 

5.1  Why a Custom AMM Is Required

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

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

 

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

 

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

 

5.2  Custom AMM Architecture

5.2.1  Constant Product Market Maker (CPMM) — Mathematical Foundation

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

 

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

 

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

 

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

 

5.2.2  u128 Overflow-Safe Arithmetic

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

 

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

 

5.2.3  Rounding Policy

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

 

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

 

5.2.4  Maximum Safe Operating Parameters

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

 

5.3  GROO Token Bonding Curve — GROO Only

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

 

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

 

5.3.1  Linear Bonding Curve Mathematics

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

 

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

 

5.3.2  GROO Graduation Criteria

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

 

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

 

5.3.3  Graduation State Transition

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

 

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

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

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

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

 

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

 

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

 

5.4  CEDEX Architectural Innovation

CEDEX — Compliant Exchange for Digital Securities — is the exclusive trading venue for all ST22 tokens. It is the only exchange built to enforce every compliance obligation that SEC Digital Securities classification entails on every single trade. Under the January 28, 2026 Joint Staff Statement and Release No. 33-11412, ST22 tokens are Digital Securities. Their trading venue must be capable of enforcing the compliance obligations that status entails. CEDEX was built to be that venue.

 

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

 

5.4.1  Compliance-First vs. Compliance-Retrofitted

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

 

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

 

5.5  Dual-Layer Execution Architecture

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

 

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

 

5.5.1  Compliance Verification Layer

Before any trade executes on-chain, CEDEX runs a pre-flight compliance check against the investor's current verification status in the Empire Stock Transfer registry. Investors with lapsed KYC, expired accreditation certification, flagged AML status, or OFAC/SDN matches are blocked at order entry — before any on-chain transaction is attempted, preventing failed transactions and wasted fees. The pre-flight check is in addition to, not a replacement for, the on-chain Transfer Hook enforcement.

 

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

 

5.5.2  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. The transaction either completes fully with all compliance verified, or it does not complete at all.

 

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

 

5.5.3  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 under normal network conditions.

 

Atomicity Guarantee If compliance verification completes but execution fails — for example, slippage exceeded, deadline passed, or insufficient balance — the entire transaction reverts atomically. No partial state changes persist. Investors never face a situation where compliance verification succeeds but tokens transfer incorrectly, or where a fee is collected without a trade executing.

 

5.6  Circuit Breaker Architecture

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

 

5.6.1  Price Impact Limit — Control 25

Any single transaction causing greater than 2% price movement against the Time-Weighted Average Price (TWAP) oracle is automatically rejected. This forces large sellers to split orders across multiple transactions, allowing the market to absorb supply incrementally rather than experiencing sudden price dislocations.

 

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

 

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

 

5.6.2  Volume-Based Halt — Control 27

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

 

pub const MAX_DAILY_SELL_PERCENT: u8  = 30;   // 30% of circulating supply pub const HALT_DURATION_SECONDS:  i64 = 86_400; // 24 hours   pub struct WalletTrackingState {     pub wallet:                Pubkey,     pub daily_sell_amount:     u64,     pub tracking_window_start: i64,     pub is_halted:             bool,     pub halt_expiry:           Option<i64>, }

 

5.6.3  Coordinated Activity Detection

CEDEX implements ML-based detection of coordinated selling patterns. Four correlation dimensions are analyzed on every trade:

 

Dimension	Analysis Method	Suspicious Threshold
Wallet clustering	Graph analysis of common funding sources	More than 5 wallets sharing a funding source
Timing correlation	Transaction timestamp clustering	More than 3 sells within a 10-second window
Amount correlation	Statistical analysis of sale sizes	Less than 5% variance across multiple coordinated sales
Price impact correlation	Sequential impact accumulation	Cumulative impact exceeding 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. Confirmed coordinated manipulation results in permanent blacklisting via Transfer Hook Control 34 (account frozen).

 

5.6.4  TWAP Oracle

The TWAP oracle provides manipulation-resistant price data for all circuit breaker calculations. The oracle maintains a rolling 1-hour window of price observations with a minimum of 60 observations required for a valid TWAP calculation. Any attempt to manipulate the spot price — for example, to create artificial circuit breaker conditions — is absorbed by the time-weighted average, which requires sustained manipulation across the full observation window to move.

 

5.7  Order Types and Execution

5.7.1  Market Orders

Parameter	Specification
Execution speed	Immediate — subject to compliance pre-flight (~2–3 seconds total)
Price guarantee	None — executes at current CPMM pool price
Slippage protection	Configurable (default 1%, maximum 5%)
Partial fills	Not supported — all-or-nothing execution
Circuit breaker	Rejects if price impact exceeds 2% TWAP deviation

 

5.7.2  Limit Orders

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

 

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

 

5.8  Fee Structure and Distribution

5.8.1  Transaction Fee Breakdown

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

 

Fee Recipient	Rate	BPS	Purpose	Lock Status
Issuer treasury	2.00%	200	Revenue to tokenizing company — accrues per trade	Withdrawable by issuer
OTCM staking pool	1.50%	150	Distributed to OTCM stakers — 8–60% APY	Distributed per epoch
Protocol operations	1.06%	106	Infrastructure, compliance oracles, development	Withdrawable by OTCM Protocol
Global Unified CEDEX Pool	0.44%	44	Permanent pool depth — routes to Global Pool	PERMANENTLY LOCKED
TOTAL	5.00%	500	—	—

 

5.8.2  Fee Justification

CEDEX's 5% fee significantly exceeds standard DEX fees. The premium reflects the genuine infrastructure cost and value delivered: each trade incurs $2–5 in oracle verification costs (Empire custody attestation, OFAC/SDN screening, AML scoring, TWAP price feed), funds issuer revenue sharing that makes the platform commercially viable for tokenizing companies, contributes permanent liquidity depth to the Global Pool, and enforces the full Digital Securities compliance framework that makes the tokens legally tradeable in the first place. For institutional securities trading, 5% compares favorably to the 7–10% all-in cost of traditional broker-dealer infrastructure for comparable compliance-grade execution.

 

5.9  MEV Protection

Maximum Extractable Value (MEV) attacks pose a material risk to institutional investors in any blockchain trading environment. CEDEX implements multiple independent protection layers making MEV extraction economically unfeasible against ST22 trades.

 

5.9.1  Jito Bundle Integration

Feature	Implementation
Bundle submission	All CEDEX trades submitted as Jito bundles with guaranteed atomicity — the trade either executes as a complete unit or not at all
Private mempool	Transactions are invisible to searchers until block inclusion — no public mempool exposure window
Priority fees	Dynamic priority fee calculation ensures reliable block inclusion under network congestion
Backrun protection	Bundle structure prevents insertion of any transaction between compliance verification and trade execution

 

5.9.2  Sandwich Attack Prevention — Structural Proof

A sandwich attack requires inserting a buy transaction before and a sell transaction after the victim's trade. Jito bundle architecture makes this structurally impossible:

 

•       Private relay — The victim's transaction is invisible in the public mempool — it exists only in Jito's private relay network until block inclusion

•       Atomic bundle — No transaction can be inserted between bundle transactions by any party, including validators

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

•       Circuit breaker backstop — Even in the worst case, the 2% price impact circuit breaker (Control 25) limits the economic value extractable from any individual trade, making sandwich attacks unprofitable even if technically executable

 

5.9.3  Fallback Mode

If the Jito block engine is unavailable for more than 30 seconds, CEDEX automatically falls back to standard priority-fee RPC submission via Helius. In fallback mode, MEV protection is degraded. CEDEX displays a 'MEV Protection Degraded' banner in the trading interface and logs all fallback transactions for post-incident compliance review.

 

5.10  Performance Specifications

 

Metric	Specification	Notes
Throughput	400–600 TPS	Limited by compliance verification oracle latency
Pre-flight compliance	2,000–3,000ms	Six primary hooks + oracle queries — runs before on-chain submission
Execution latency	400–600ms	CPMM swap post-verification
Block finality	~13 seconds	32 Solana block confirmations
Compute units	~800,000 CU	Per complete swap transaction including all 42 Transfer Hook controls
Network fee	~$0.01–$0.05	Solana base fee + dynamic priority fee
Order book sync	400ms	One Solana block — Helius RPC cluster synchronization

 

5.11  Security Architecture

5.11.1  Smart Contract Security

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

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

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

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

 

5.11.2  Economic Security

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

•       Price manipulation resistance — TWAP oracle requires sustained manipulation across a 60-observation, 1-hour window to move the circuit breaker reference price

•       Coordinated dump prevention — Volume halt (30% daily limit per wallet) and coordinated activity detection prevent the multi-wallet strategies used in organized market manipulation

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

 

5.11.3  Operational Security

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

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

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

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

 

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