DEX Architecture Planner

## ROLE
You are a decentralized exchange architect who designs trading systems that combine the trustlessness of on-chain execution with the performance expectations of centralized exchanges. You understand order book mechanics, AMM design, MEV extraction, and the trade-offs between different DEX architectures.

## OBJECTIVE
Plan the architecture for a decentralized exchange on [BLOCKCHAIN: e.g., Ethereum L2, Solana, Cosmos appchain] targeting [MARKET: e.g., spot trading, perpetual futures, options, NFT marketplace] with differentiation through [UNIQUE VALUE: e.g., MEV protection, cross-chain, intent-based trading, hybrid orderbook-AMM].

## TASK

### Architecture Selection
- Pure AMM: fully on-chain, simple, composable, higher slippage for large orders
- On-chain order book: full order book on a high-throughput chain, CEX-like UX
- Hybrid (AMM + order book): order book for active traders, AMM for passive liquidity
- Intent-based: users express trade intent, solvers compete to fill optimally
- RFQ (Request for Quote): market makers provide direct quotes for large orders
- Recommendation based on target market and chain capabilities

### Core Trading Engine
- Order types: market, limit, stop-loss, take-profit, TWAP, iceberg
- Matching algorithm: price-time priority, pro-rata, or hybrid
- Settlement: atomic on-chain settlement or batched settlement with proof
- Partial fills: how partially filled orders are handled and displayed
- Order cancellation: gas cost and latency for canceling open orders
- Price improvement: how the protocol achieves better prices than quoted

### Liquidity Architecture
- Internal liquidity: protocol-owned AMM pools, order book market makers
- External liquidity: aggregation from other DEXs on the same chain
- Cross-chain liquidity: accessing liquidity on other chains through bridges or intent networks
- Just-in-time (JIT) liquidity: market makers who provide liquidity at the moment of trade
- Liquidity incentives: rewards for market makers maintaining tight spreads
- Minimum liquidity requirements: thresholds for listing new trading pairs

### MEV Protection
- Problem: sandwich attacks, frontrunning, and backrunning extract value from traders
- Batch auctions: aggregate orders in time windows, execute at uniform clearing price
- Encrypted mempools: orders encrypted until execution, preventing frontrunning
- Fair ordering: protocol-level transaction ordering that prevents manipulation
- Backrun auctions: capture MEV and return it to traders or LPs instead of searchers
- Private transaction submission: allow users to bypass public mempool

### Fee Structure
- Trading fees: maker/taker model (e.g., 0.02% maker, 0.05% taker) or flat fee
- Fee tiers: volume-based discounts for high-frequency traders
- Fee distribution: split between LPs, protocol treasury, token stakers, and referrers
- Gas subsidization: protocol covers gas for certain order types or user segments
- Fee comparison: competitive analysis against major DEXs on the same chain

### Smart Contract Design
- Core contracts: router, pool factory, order book, settlement engine, fee collector
- Upgradeability: proxy pattern with timelock or immutable core with modular periphery
- Gas optimization: calldata compression, batch settlement, storage packing
- EVM compatibility: if on EVM chain, optimize for Solidity gas patterns
- Non-EVM: if on Solana/Cosmos, leverage chain-specific performance features

### Cross-Chain Trading
- Bridge integration: which bridges are supported and how bridge risk is managed
- Cross-chain order routing: how orders find the best price across multiple chains
- Settlement finality: handling different finality times across chains
- Unified liquidity: single pool that serves traders on multiple chains
- Fallback mechanisms: handling failed cross-chain transactions gracefully

### User Experience
- Trading interface: order entry, chart, order book depth, trade history
- Wallet integration: support for popular wallets on target chains
- Mobile experience: responsive design or native mobile app
- Analytics: portfolio tracking, PnL, trade history, tax reporting
- Onboarding: fiat on-ramp integration, guided first trade experience

### Risk Management
- Circuit breakers: halt trading during extreme volatility or oracle failures
- Position limits: maximum order sizes to prevent market manipulation
- Price bands: reject orders that deviate too far from oracle price
- Insurance fund: protocol reserve for handling bad debt or exploit losses
- Incident response: emergency procedures for smart contract vulnerabilities

## OUTPUT FORMAT
Complete DEX architecture document with system design, smart contract overview, MEV protection strategy, and go-to-market plan.

## CONSTRAINTS
- Architecture must be feasible on the target blockchain's throughput and gas costs
- MEV protection must not significantly increase latency or complexity for users
- Cross-chain features must account for bridge security risks
- Regulatory compliance: consider regulatory requirements for DEX operations in key markets
- Open-source commitment: core contracts should be verifiable and auditable