Limit Orders
Limit orders enable traders to place resting liquidity at specific price levels, combining the precision of traditional order books with the capital efficiency of concentrated liquidity AMMs. Unlike passive liquidity provision across ranges, limit orders represent directional bets at exact prices—buy orders below market, sell orders above market.
For RWA markets where professional collectors want precise execution at target prices (e.g., "buy FP Journe tokens at exactly $4,950"), limit orders provide familiar trading UX while maintaining full AMM composability and atomic settlement.
Why limit orders matter for RWAs
Traditional AMM liquidity provision requires:
- Two-sided capital: Provide both tokens (RWA + USDC)
- Range management: Monitor and adjust positions as price moves
- IL exposure: Accept impermanent loss from rebalancing
- Continuous engagement: Active management for optimal returns
This works well for professional market makers, but creates friction for occasional traders who simply want to:
- Buy at a target price: "I'll buy 50 tokens if price drops to $4,900"
- Sell at a profit target: "I'll sell 100 tokens if price hits $5,200"
- Set and forget: Place order and walk away until filled
Limit orders provide this functionality while maintaining the gas efficiency and atomicity of AMM trades.
How limit orders work in CL AMMs
Single-tick concentrated positions
A limit order is a one-tick-wide concentrated liquidity position placed entirely outside the current price:
Sell order (ask): Place liquidity in a single tick above current price
- You deposit only the token you want to sell (e.g., RWA tokens)
- When price crosses that tick, your tokens get swapped for USDC
- Order "fills" when price moves through that level
Buy order (bid): Place liquidity in a single tick below current price
- You deposit only the quote currency (e.g., USDC)
- When price crosses that tick, your USDC gets swapped for RWA tokens
- Order "fills" when price moves down through that level
This single-sided placement is a fundamental constraint of CL AMMs, not a design choice. In any CL AMM:
- Positions above current price can only hold the base asset (RWA tokens) → sell liquidity
- Positions below current price can only hold the quote asset (USDC) → buy liquidity
- Positions at current price require both assets to be immediately active
This is why limit orders naturally map to CL AMM mechanics: sell orders above market, buy orders below market. You cannot place buy orders above current price or sell orders below—that would require holding the "wrong" asset for that price range.
Example: Current RWA/USDC price is $5,000.
Sell order at $5,200:
- Deposit 50 RWA tokens at tick corresponding to $5,200
- When price rises to $5,200, tokens automatically swap for ~$260k USDC
- You've sold at your target price
Buy order at $4,900:
- Deposit $245k USDC at tick corresponding to $4,900
- When price falls to $4,900, USDC automatically swaps for ~50 RWA tokens
- You've bought at your target price
Automatic execution via swaps
Limit orders don't require matching engines or off-chain keepers. They execute atomically during normal swaps:
- Trader A submits market buy order (buying RWA with USDC)
- Swap routing hits resting limit orders (sell orders at various price levels)
- Limit orders provide liquidity, automatically "filling" in the process
- Trader A gets tokens, limit order owners get USDC at their target prices
This is pure on-chain execution with zero reliance on external infrastructure.
Batching for gas efficiency
A naive implementation where each limit order is a separate liquidity position would be gas-prohibitive—removing 100 small positions during a swap would cost hundreds of thousands of gas.
Instead, limit orders use epoch batching:
Epoch structure
All limit orders at the same (tick, side) combination are grouped into a single epoch:
- Same tick: e.g., all orders at $5,200
- Same side: e.g., all sell orders (0-for-1 direction)
Orders in the same epoch are fungible and fill pro-rata based on liquidity contribution.
Example: Three traders place sell orders at $5,200:
- Alice: 50 RWA tokens
- Bob: 30 RWA tokens
- Charlie: 20 RWA tokens
These combine into one epoch with 100 RWA tokens total liquidity. When price crosses $5,200 and 60 tokens fill:
- Alice receives: (50/100) × 60 = 30 tokens worth of USDC
- Bob receives: (30/100) × 60 = 18 tokens worth of USDC
- Charlie receives: (20/100) × 60 = 12 tokens worth of USDC
Gas efficiency: Filling 100 orders at the same price costs the same gas as filling 1 order—constant gas per tick crossed, regardless of number of individual orders batched.
Epoch lifecycle
Active epoch: Has unfilled liquidity, waiting for price to cross
- Orders can be placed (increasing epoch liquidity)
- Orders can be cancelled (decreasing epoch liquidity)
- Epoch provides liquidity during swaps
Filled epoch: Price has crossed, liquidity has been swapped
- No new orders accepted into this epoch (would start next epoch)
- Users claim their filled proceeds pro-rata
- Historical record remains for accounting
Anti-DoS protections
Gas efficiency depends on batching many orders into few epochs. A malicious actor could attack this by placing dust orders spread across many ticks, forcing swaps to cross dozens of epochs and pay high gas.
The protocol implements multiple defenses:
Minimum notional thresholds
Each limit order must meet a minimum size denominated in the deposited token. The threshold varies based on collection characteristics:
| Collection Liquidity | USDC Min | RWA Token Min | Rationale |
|---|---|---|---|
| Deep (>$10M TVL) | $10 | $10 equivalent | High volume collections, balance accessibility with spam protection |
| Standard (10M TVL) | $25 | $25 equivalent | Typical collections, moderate protection |
| Thin (<$1M TVL) | $100 | $100 equivalent | Low liquidity collections, strong spam protection needed |
Enforcement: When a user places an order, the protocol calculates the exact token amount owed to the pool for that one-tick position. If below the threshold, the transaction reverts.
Why this works: Prevents dust epochs from ever becoming active. An attacker would need to place minimum-sized orders (at least $10–$100) across many ticks, making the attack economically infeasible due to capital lockup and gas costs.
What determines the threshold? Collections with deeper liquidity can afford lower minimums because:
- Higher trading volume means more orders batch naturally
- Stronger network effects (more traders → more epoch batching)
- Lower relative cost of processing additional epochs
Smaller collections need higher minimums to compensate for:
- Fewer natural batching opportunities
- Higher gas cost relative to trading volume
- Greater vulnerability to spam attacks
Example: On a standard RWA collection ($5M TVL) with $25 USDC minimum:
- ✅ Alice places buy order for 5 tokens at $5,000 → deposits $25k USDC
- ✅ Bob places buy order for 1 token at $100 → deposits $100 USDC
- ❌ Charlie tries buy order for 0.2 tokens at $100 → deposits $20 USDC → reverts (below $25 minimum)
Placement stride (coarser tick grid)
Standard CL AMM pools allow liquidity placement at every tick (e.g., every 1 basis point). Limit orders use a coarser grid, restricting placement to every Nth tick:
| Pool Fee Tier | Base Tick Spacing | Limit Order Stride | Effective Spacing |
|---|---|---|---|
| 0.05% | 10 bps | 4× | 40 bps |
| 0.30% | 60 bps | 4× | 240 bps (~2.4%) |
| 1.00% | 200 bps | 2× | 400 bps (~4%) |
Mechanism: Only ticks where (tick / tickSpacing) % stride == 0 are valid for limit orders. Other ticks reject limit order placement.
Why this works: Collapses would-be dust spread across adjacent ticks into fewer, larger epochs. An attacker must concentrate capital into fewer price points to achieve the same number of epochs.
Trade-off: Slightly fewer price points available for limit orders (e.g., every ~40 bps instead of every 10 bps), but massively fewer epochs crossed per swap.
Example: Pool with 10 bp tick spacing and 4× stride:
- ✅ Tick 40 (4 × 10 bp): Valid limit order tick
- ✅ Tick 80 (8 × 10 bp): Valid limit order tick
- ❌ Tick 50 (5 × 10 bp): Invalid for limit orders (standard LP positions still allowed)
- ❌ Tick 70 (7 × 10 bp): Invalid for limit orders
This reduces the maximum number of limit order epochs a swap can cross by the stride factor (4×), making DoS attacks 4× more expensive.
Swapper rebates
Even with minimum notional and placement stride, crossing many epochs incurs gas costs for the swapper. To neutralize this friction, the protocol offers fill rebates:
Mechanism: When a limit order epoch fills during a swap, a small percentage (e.g., 5 basis points = 0.05%) of the filled proceeds is rebated to the swapper who triggered the execution.
Example: Swap crosses $5,200 sell epoch with 100 RWA tokens:
- Epoch receives $520k USDC from swap
- Rebate: 0.05% × $520k = $260 USDC → sent to swapper
- Epoch net proceeds: $519,740 USDC → distributed pro-rata to limit order owners
Gas offset: $260 rebate compensates swapper for marginal gas cost of processing that epoch. Large swaps crossing many epochs accumulate rebates, making routing through the pool attractive rather than penalizing.
Economic impact on limit order owners: Negligible—5 bps is smaller than typical bid-ask spread. Limit order owners still get favorable execution at their target price, just slightly reduced by the rebate (equivalent to a tiny execution fee).
Why this matters: Without rebates, swappers might avoid routing through pools with many resting limit orders to minimize gas. Rebates ensure that liquidity attracts flow rather than repelling it.
Limit orders vs. passive liquidity
While both use the same underlying CL AMM infrastructure, limit orders and passive liquidity provision serve different purposes:
| Dimension | Limit Orders | Passive Liquidity |
|---|---|---|
| Intent | Directional trade at target price | Earn fees on volatility |
| Capital | Single-sided (token to sell) | Two-sided (both tokens) |
| Duration | One-time execution ("fill and done") | Ongoing provision ("earn continuously") |
| Range | Single tick | Multi-tick range |
| Rebalancing | None (automatic removal on fill) | Active (move ranges as price shifts) |
| IL exposure | None (exact price execution) | High (rebalancing across range) |
| Fee revenue | Minimal (brief exposure before fill) | Primary objective |
| Use case | "Buy 50 tokens at $4,900" | "Earn fees on volatility around $5,000" |
Complementary, not competitive: Limit orders provide precision execution for directional traders, while passive liquidity provision captures fee revenue from volatility. Both improve overall market depth.
Limit order strategies for RWA traders
Accumulation at discount
Strategy: Place buy limit orders below current market to accumulate tokens during dips.
Example: Current price $5,000. Collector wants to accumulate 200 tokens over time at favorable prices:
- 50 tokens at $4,900 (2% discount)
- 50 tokens at $4,800 (4% discount)
- 50 tokens at $4,700 (6% discount)
- 50 tokens at $4,600 (8% discount)
Outcome: If price dips during volatility, orders fill automatically at predefined levels. Collector accumulates at average price of $4,750 (5% discount) without monitoring markets 24/7.
Capital requirement: $950k USDC locked across four orders.
Profit-taking at targets
Strategy: Place sell limit orders above current market to realize profits at target levels.
Example: Current price $5,000. Investor holds 400 tokens and wants to de-risk:
- Sell 100 tokens at $5,200 (4% premium, take some profit)
- Sell 100 tokens at $5,400 (8% premium, take more profit)
- Sell 100 tokens at $5,600 (12% premium, significant de-risking)
- Sell 100 tokens at $5,800 (16% premium, full exit)
Outcome: If price rises, investor realizes gains incrementally without needing to watch markets. Average sell price $5,500 (10% premium).
Set and forget: Orders remain active indefinitely until filled or cancelled.
Rebalancing between collections
Strategy: Simultaneously sell one RWA collection and buy another to rotate exposure.
Example: Investor holds 100 tokens of Collection A (Patek Philippe watches, currently $5,000) and wants to rotate into Collection B (Luxury sports cars, currently $8,000):
- Place sell limit orders: 100 Collection A at $5,100
- Place buy limit orders: 63 Collection B at $8,100 (uses ~$510k proceeds from sale)
Outcome: If both collections appreciate slightly, investor rotates exposure at favorable prices without actively trading. Net effect: $510k exposure to Collection A → $510k exposure to Collection B.
Interaction with mark-to-truth auctions
Limit orders respect the same pricing discipline as the broader protocol:
Before auctions
Limit order clustering can signal market sentiment:
- Heavy buy orders below current price → traders expect downward movement
- Heavy sell orders above current price → traders expect upward movement
- Sparse limit order depth → uncertainty about fair value
This clustering provides information to market participants considering triggering mark-to-truth auctions.
During auctions (RECENTER)
If a RECENTER auction moves the fair value price:
- Limit orders above new fair value (sell orders that were too high) remain active
- Limit orders below new fair value (buy orders that were too low) remain active
- Limit orders within the new fair value range may fill during post-auction trading
Limit orders are not cancelled by auctions—they represent users' target prices regardless of fair value shifts.
After auctions
Post-RECENTER flow caps (2-3% TVL/day) may temporarily slow limit order fills if trading volume is constrained. However, this is intentional—limiting velocity ensures price stability after major repricing events.
Gas efficiency vs. order book exchanges
Traditional order book exchanges maintain off-chain order matching with high gas costs for on-chain settlement. AMM limit orders achieve better efficiency:
| Approach | Placement Gas | Cancellation Gas | Execution Gas | Notes |
|---|---|---|---|---|
| Order book (on-chain) | ~150k gas | ~50k gas | ~200k gas | Each order separate |
| AMM limit orders (individual) | ~180k gas | ~60k gas | ~200k gas | Similar to order book |
| AMM limit orders (batched) | ~180k gas | ~60k gas | ~80k gas / 100 orders | Epoch batching wins |
Break-even: If 2+ orders batch into the same epoch, AMM limit orders are cheaper to execute. With dozens of orders per tick, execution cost approaches constant gas per price level rather than linear in number of orders.
Example: 100 traders place buy orders at $4,900. Order book execution: 100 × 200k = 20M gas. AMM limit order execution (batched): ~300k gas (one epoch fill).
Trust minimization
Limit orders maintain the same trust properties as the broader protocol:
No off-chain components
- No matching engine: Execution happens via normal swaps through pool manager
- No keepers: No external actors required to trigger fills
- No relayers: Users interact directly with pool contracts
- No operator privileges: Protocol is permissionless for placement and cancellation
Atomic settlement
- No settlement risk: Fill and token transfer happen in same transaction
- No counterparty risk: Liquidity locked in pool contracts until fill or cancellation
- No price improvement uncertainty: Exact tick price guaranteed (no hidden spread)
Composability
- DeFi integration: Other protocols can read limit order depth for risk assessment
- Programmatic trading: Smart contracts can place and manage limit orders
- Flash loan compatibility: Limit orders can be filled within flash loan transactions
Monitoring and analytics
Order book visualization
While limit orders are technically CL AMM positions, UIs present them as familiar order book depth charts:
Price | Bid Depth (USDC) | Ask Depth (RWA tokens)
---------|------------------|----------------------
$5,200 | | 150 tokens ($780k)
$5,100 | | 300 tokens ($1.53M)
$5,000 | ← current price
$4,900 | $2.4M (490 tok) |
$4,800 | $1.9M (395 tok) |
This visualization helps traders understand resting liquidity at each price level and gauge market sentiment.
Fill history
Protocols should track:
- Fill rate: Percentage of limit orders that execute vs. cancel
- Time to fill: Distribution of how long orders wait before execution
- Slippage: Difference between placed tick and actual execution tick (should be zero for true limit orders)
High fill rates and tight execution accuracy indicate healthy, liquid markets.
Why this matters
Limit orders bridge the gap between AMM simplicity and order book precision:
Without limit orders:
- Traders must actively monitor markets for target prices
- Market orders experience slippage on thin liquidity
- Directional traders forced to provide two-sided liquidity
With limit orders:
- Set and forget execution at exact prices
- Deep resting liquidity visible to all market participants
- Familiar UX for traders from traditional markets
- Gas-efficient batching scales to hundreds of concurrent orders
For RWA markets where collectors want precise execution without constant monitoring, limit orders provide institutional-grade trading UX while maintaining full on-chain atomicity and composability.
Related reading
- CL AMM Primer for how concentrated liquidity enables single-tick positions
- Pricing for how limit order depth affects RWAP and market quality
- Liquidity Management for professional market maker strategies that complement limit orders