Crypto swap exchanges enable direct token-to-token conversions without intermediate fiat settlement. They operate through two primary models: orderbook based centralized platforms that match maker and taker orders, and automated market maker (AMM) protocols that quote prices against onchain liquidity pools. The architecture choice determines execution speed, slippage behavior, and custody model. This article examines the technical mechanics, routing strategies, and operational considerations for practitioners selecting or integrating swap infrastructure.
Orderbook vs AMM Execution Models
Centralized swap exchanges maintain offchain orderbooks. They collect limit and market orders, match them through a matching engine running at microsecond latency, and settle net balances in internal databases. The exchange holds custody of deposited assets. Price discovery occurs through continuous order flow. Deep orderbooks on major pairs reduce slippage for large trades, but liquidity fragments across venues.
AMM protocols execute swaps onchain against liquidity pools using deterministic pricing formulas. The constant product model (x × y = k) remains the most common. Liquidity providers deposit paired assets into smart contracts. Traders swap against the pool, receiving a price determined by the current reserve ratio. Each trade shifts the ratio, moving the price along the bonding curve. Slippage increases nonlinearly with trade size relative to pool depth.
Hybrid models now exist. Some centralized platforms embed AMM logic for long-tail pairs while maintaining orderbooks for liquid markets. Certain decentralized exchanges aggregate multiple AMM pools and route orders across them to minimize price impact.
Routing and Price Aggregation
Sophisticated swap interfaces query multiple liquidity sources simultaneously and construct optimal execution paths. A router contract or offchain algorithm evaluates direct swaps, multihop routes through intermediate tokens, and splits across parallel pools.
A direct ETH-to-USDC swap might execute entirely in one pool. An ETH-to-obscure-token swap might route through WETH → USDC → target token if those intermediate pools offer better combined pricing than any direct pair. Split routing divides a large order: 60% through Pool A, 40% through Pool B to reduce per-pool slippage.
Routing algorithms must account for:
Gas costs per hop. Each additional pool interaction adds transaction overhead. On Ethereum mainnet during periods of elevated base fees, a three hop route might cost $50 to $150 in gas alone. Optimizing for price impact while ignoring gas can yield negative net returns.
Pool fee tiers. Uniswap v3 introduced multiple fee levels (0.01%, 0.05%, 0.30%, 1.00%) for the same pair. Lower fee pools attract more liquidity for stable pairs, higher fees compensate providers for volatile or exotic assets. Routers must evaluate effective price including fees.
Concentrated liquidity boundaries. Uniswap v3 and similar protocols allow providers to concentrate capital within specific price ranges. A large swap may exhaust liquidity in active ranges and move into sparse regions where slippage accelerates. Route evaluation requires querying liquidity distribution, not just total value locked.
Settlement and Atomicity Guarantees
Onchain AMM swaps settle atomically within a single transaction. The swap either completes at the quoted price (subject to slippage tolerance) or reverts entirely. No partial fills occur. This atomicity eliminates counterparty risk but creates new failure modes: front-running bots can observe pending transactions in the mempool, execute their own swap first to move the price, then profit when your transaction executes at a worse rate or reverts.
Centralized exchanges settle internally across multiple orders. You might receive partial fills as different makers provide liquidity. Settlement happens in the exchange database, with blockchain withdrawals occurring separately. This introduces custody risk and withdrawal latency but enables faster execution and order types (stop losses, trailing stops) impossible in simple AMM contracts.
Recent protocols implement request-for-quote (RFQ) systems where professional market makers provide signed quotes valid for short windows (a few seconds). The user accepts a quote, submits it onchain, and the contract verifies the signature and settles at the guaranteed rate. This combines offchain price discovery with onchain settlement finality.
Slippage Tolerance and Reversion Mechanics
AMM protocols require users to specify maximum acceptable slippage. You request a swap with a minimum output amount. If the actual execution price (after accounting for other transactions that settle first) would deliver less, the transaction reverts.
Setting tolerance too tight causes frequent reverts, especially on volatile pairs or congested networks where your transaction might wait several blocks. Setting it too loose exposes you to sandwich attacks: a bot front runs with a large buy, your swap executes at the inflated price, then the bot immediately sells back.
Some interfaces show estimated vs guaranteed output. The estimate assumes current pool state. The guarantee incorporates your slippage setting. On a 10 ETH to USDC swap with 0.5% tolerance and an estimate of 27,000 USDC, the transaction will revert if it would receive less than 26,865 USDC.
Advanced users query pool state directly before submitting transactions, calculate expected output using the bonding curve formula, apply their own tolerance buffer, and construct transaction calldata manually. This avoids interface bugs or stale price feeds.
Worked Example: Multihop Routing with Gas Optimization
You want to swap 5 ETH for TOKEN on Ethereum mainnet. Available routes:
Route A: ETH → TOKEN direct pool with 15 ETH and 45,000 TOKEN liquidity, 0.30% fee.
Route B: ETH → USDC (1,500 ETH / 4,050,000 USDC, 0.05% fee) → TOKEN (20,000 USDC / 40,000 TOKEN, 0.30% fee).
Calculate Route A output. After 0.30% fee, effective input is 4.985 ETH. Constant product: (15) × (45,000) = (15 + 4.985) × (45,000 – output). Solving gives approximately 11,220 TOKEN. Price impact: 16.8%.
Calculate Route B. First hop: 4.985 ETH into USDC pool yields approximately 13,350 USDC (minimal impact in deep pool). Second hop: 13,350 USDC into TOKEN pool yields approximately 13,160 TOKEN. Combined price impact: 8.7%.
Route B delivers 17% more tokens. However, it requires two swap calls. At 150 gwei and 150,000 gas per swap, total gas cost is roughly 0.045 ETH ($120 equivalent). For a 5 ETH trade, the 1,940 TOKEN improvement (worth perhaps $1,940 if TOKEN trades near $1) exceeds gas costs. Route B wins.
If you were swapping 0.5 ETH instead, the absolute token improvement shrinks to roughly 194 TOKEN. Gas costs remain the same. Route A becomes preferable despite worse price impact.
Common Mistakes and Misconfigurations
Approving unlimited token spend. Many interfaces request infinite approval to avoid repeated approval transactions. If the interface contract or connected router is compromised or contains a bug, an attacker can drain approved tokens. Approve exact amounts per transaction, or regularly revoke unused approvals.
Ignoring mempool visibility. Public transactions broadcast swap details before confirmation. Sophisticated actors monitor for large swaps and execute sandwich attacks. Use private relays (Flashbots Protect, MEV Blocker) or submit through RFQ systems for material trades.
Confusing quoted price with execution price. Interfaces show estimates based on current state. Between quote and execution, other transactions alter pool ratios. Always set explicit minimum output amounts. Do not rely on displayed estimates as guarantees.
Neglecting token tax mechanics. Some tokens implement transfer fees, burn mechanisms, or liquidity taxes in their contracts. A 10% transfer tax means swapping 1,000 tokens only delivers 900 to the pool, worsening your effective rate. Check token contract code before swapping unfamiliar assets.
Using stale price oracles for limit orders. Decentralized limit order protocols rely on keepers or off chain signers to execute when conditions meet. If the oracle lags or can be manipulated, your limit may execute at disadvantageous real market prices.
Failing to account for concentrated liquidity gaps. Uniswap v3 positions concentrate in ranges. A pool might show $10M TVL but only $500K active between current price ± 2%. Large swaps exhaust active liquidity and cross into ranges with extreme slippage.
What to Verify Before You Rely on This
- Current pool liquidity depth and distribution for your specific pair and size
- Active fee tier for the pool you intend to trade (fees vary by pool even for identical pairs)
- Router contract version and recent audit status (routers update frequently, introducing new code)
- Token contract for transfer taxes, pausability, or blacklist functions that could prevent settlement
- Gas price conditions and your break even threshold for multihop routing
- Whether the platform implements front running protection (private mempools, MEV redistribution)
- Withdrawal processing times and minimum thresholds for centralized platforms
- Protocol governance status (are admin keys still active, is the contract immutable)
- Chain congestion levels if executing time sensitive swaps
- Historical slippage for your pair and size using onchain transaction data, not interface estimates
Next Steps
- Simulate your intended swap using forking tools (Tenderly, Foundry) to observe exact gas costs and outputs before committing capital onchain.
- Build monitoring for liquidity depth across your preferred pairs and set alerts when active liquidity drops below thresholds that would cause unacceptable slippage for your typical trade sizes.
- Integrate multiple routing APIs (1inch, Matcha, Paraswap) in your execution stack and programmatically select the best quote after incorporating gas costs and slippage buffers for each route.
Category: Crypto Exchanges
