Open Interest Beyond Current Pool Price
Open interest orderbook extends the concentrated liquidity AMM with a price-gated limit order layer that enables discrete buy and sell orders at fixed price levels. Unlike traditional orderbooks that match continuously, this system activates orders only when swap flow would push the AMM spot price past their levels—creating a hybrid architecture where limit orders and continuous AMM liquidity coexist and route together.
The design goal is straightforward: enable precision execution at target prices for traders with strong directional convictions, while maintaining the composability and capital efficiency of the underlying AMM. The orderbook enhances the AMM rather than replacing it, similar to how options markets layer on top of spot markets in traditional finance.
This architecture draws from hybrid orderbook-AMM designs where limit orders coexist with continuous liquidity pools. The key innovation is treating the AMM price path as both a price oracle and fallback liquidity source—the orderbook intercepts flow at price boundaries with fixed-price orders, creating a composable layer that enhances the AMM without fragmenting liquidity or requiring separate matching infrastructure.
The problem: Expressing directional conviction
What CL AMMs cannot do
Concentrated liquidity AMMs excel at providing continuous liquidity and enabling capital-efficient market making. But they struggle with a fundamental limitation: traders cannot place limit orders at discrete prices.
Scenario 1: Buy orders above current price
A collector believes a watch collection is undervalued at $5,000 and will reach $5,200. They want to place a buy order at $5,200 to capture any upward move. In a CL AMM:
- No mechanism to express buy interest above current price
- Must wait and watch for price to reach $5,200, then execute manually
- Risks missing execution if price moves quickly during low-liquidity periods
- Cannot express forward demand that would help new supply enter the market
Scenario 2: Sell orders at exact target prices
A holder wants to exit at exactly $5,200—no more, no less. In a CL AMM:
- Must provide liquidity in a range around $5,200 (not a single price)
- Exposed to impermanent loss as price moves through the range
- Capital locked across entire range, reducing efficiency
- Approximate behavior requires constant monitoring and rebalancing
The gap: CL AMMs force traders with directional views into one of three suboptimal choices:
- Provide two-sided liquidity (exposing them to impermanent loss)
- Execute market orders (accepting slippage and immediate execution)
- Monitor constantly (poor UX, requires active management)
None of these options serve traders who simply want: "Buy 50 tokens if price reaches $5,200" or "Sell 100 tokens at exactly $4,800."
How it works: Price-gated execution
The orderbook layer sits on top of the CL AMM, intercepting swap flow when prices would cross through limit order levels.
Execution flow
When a trader submits a swap:
- Router computes the price path using the AMM curve
- If the path crosses ticks with limit orders, those orders execute first at their fixed prices
- Orders fill atomically during the swap, no separate matching needed
- Remaining flow continues along the AMM curve as normal
- Fills accrue to claimable balances that users withdraw later (gas efficiency)
Key insight: The AMM curve determines which orders to execute (those that would be crossed by the price path), but the orders themselves provide fixed-price execution at discrete ticks.
Example: Hybrid execution
Setup: Watch collection trading at $5,000 per token
Orderbook state:
- Sell orders at $5,100: 300 tokens
- Sell orders at $5,200: 500 tokens
- Buy orders at $4,900: $50,000 USDC
Large buy order: Collector wants to buy 800 tokens
Execution:
- First 300 tokens fill from sell orders at $5,100 = $1,530,000 USDC
- Next 500 tokens fill from sell orders at $5,200 = $2,600,000 USDC
- All 800 tokens acquired via orderbook (no AMM execution needed)
- Average price: $5,162.50 per token
- No slippage within ticks: Each price level executed at exact fixed price
If the buy order had been larger (e.g., 1,500 tokens), the first 800 would fill from the orderbook at $5,100-$5,200, and the remaining 700 would execute along the AMM curve starting from $5,200.
Why this matters for RWAs
Solving the Case B problem
Recall from minting price dynamics that Case B (acquisition price below pool price) creates challenges:
- No upward liquidity: CL AMMs have no mechanism for buy orders above current price
- Supply dumping risk: New tokens must be sold into existing AMM liquidity, pushing price down
- Missed demand: Willing buyers at higher prices cannot express interest in advance
The orderbook solves this: Users can place buy orders above current pool price, creating:
- Forward demand signals that inform issuer acquisition decisions
- Capital commitment that will absorb new supply at specified prices
- Upward liquidity that enables orderly price discovery above current levels
- Merit-based allocation where those willing to pay more get priority
See Open Interest (Minting) for how this integrates with supply management.
Capital efficiency for collectors
Professional collectors and large holders can use the orderbook for efficient position management:
Accumulation strategy:
- Place buy orders at $4,900, $4,800, $4,700 (below current $5,000)
- Orders fill automatically during market dips
- Accumulate at favorable prices without monitoring 24/7
- No impermanent loss exposure
Profit-taking strategy:
- Place sell orders at $5,200, $5,400, $5,600 (above current $5,000)
- Orders fill automatically as price appreciates
- Realize gains at target levels without constant monitoring
- Exit at exact prices, not ranges
No impermanent loss: Unlike providing AMM liquidity across a range, limit orders execute at exact prices and do not rebalance. You buy or sell at your specified price, period.
Market depth visibility
The orderbook provides transparent depth information:
Price | Bid Depth (USDC) | Ask Depth (RWA tokens)
---------|------------------|----------------------
$5,200 | | 500 tokens ($2.6M)
$5,100 | | 300 tokens ($1.53M)
$5,000 | ← current price
$4,900 | $490k (100 tok) |
$4,800 | $960k (200 tok) |
This visibility helps:
- Traders gauge market sentiment and likely support/resistance levels
- Issuers see committed demand at various price levels before acquisitions
- Market makers position strategically around resting liquidity
- Risk managers assess potential price impact of large trades
Matching policy
The orderbook guarantees strict price priority: orders execute from best to worst price in the swap direction. Within each price level (tick), the protocol offers configurable time priority:
Pro-rata allocation (recommended)
Orders at the same price level fill proportionally based on each participant's contribution:
Example: Three traders place sell orders at $5,200:
- Alice: 50 tokens (50% of total)
- Bob: 30 tokens (30% of total)
- Charlie: 20 tokens (20% of total)
When 60 tokens fill at $5,200:
- Alice fills: 30 tokens (50% of 60)
- Bob fills: 18 tokens (30% of 60)
- Charlie fills: 12 tokens (20% of 60)
Benefits:
- Gas efficient: Constant gas per tick regardless of order count
- DoS resistant: Cannot spam tiny orders to game execution
- Fair: Proportional to capital committed
Trade-off: No strict time priority within a tick (earlier orders don't get preference).
FIFO allocation (optional)
Orders fill in first-in-first-out order within each tick:
Benefits:
- Time priority: Earlier orders fill first (traditional orderbook semantics)
- Predictable: Matches how traders expect limit orders to work
Trade-offs:
- Higher gas: Processing many orders at one tick becomes expensive
- DoS vulnerable: Attacker could place many tiny orders to increase gas costs
Recommended approach: Use pro-rata for V1 (gas-efficient, DoS-resistant), consider hybrid k-FIFO later (first k orders get FIFO, remainder pro-rata).
Settlement model
Deferred claims (pull-based)
Unlike traditional orderbooks that transfer tokens immediately on fill, this system uses deferred settlement:
- During swap: Order fills accrue to "claimable" balances (cheap storage update)
- After swap: Users claim their counter-assets in separate transactions (pull-based)
Example: Alice places a sell order for 50 tokens at $5,200. When a swap crosses that tick:
- Alice's 30 tokens fill (pro-rata allocation)
- $156,000 USDC accrues to Alice's claimable balance
- Alice's remaining 20 tokens stay in orderbook at $5,200
- Later: Alice calls
claim()to withdraw her $156,000 USDC
Why deferred settlement:
- Gas efficiency: One storage update per user per swap, not per order
- Bounded gas: Swap execution cost is predictable regardless of order count
- Safety: No external calls during swap execution (reentrancy-safe)
- Batch claiming: Users can accumulate fills and claim once
Claim deadline: Unclaimed balances expire after ~90 days to prevent state bloat. Users receive event notifications when orders fill, ensuring ample time to claim.
Gas efficiency through tick batching
A naive implementation where each limit order is a separate position would be gas-prohibitive—processing 100 individual orders during a swap would cost hundreds of thousands of gas.
Instead, the orderbook uses tick batching: all orders at the same (price, side) combination are aggregated into a single execution unit.
Example: 100 traders place sell orders at $5,200, totaling 5,000 tokens. From the execution perspective:
- One tick crossing: ~20k gas
- Orders fill pro-rata: All 100 traders receive fills proportional to their contribution
- Gas per order: ~200 gas (20k / 100), constant regardless of individual order sizes
Scalability: The orderbook can handle thousands of orders across hundreds of price levels without becoming gas-prohibitive. Most swaps cross 0-3 ticks, consuming ~30-60k gas for orderbook execution—far less than the AMM curve execution itself.
Anti-DoS protections
To prevent attacks that would make the orderbook unusable or gas-prohibitive, the protocol implements multiple defenses:
Minimum order size
Each order must meet a minimum notional value to prevent dust:
| Collection Liquidity | Minimum Order Size | Rationale |
|---|---|---|
| Deep (>$10M TVL) | $10-$25 | Balance accessibility and spam |
| Standard ($1-10M) | $25-$100 | Moderate protection |
| Thin (<$1M TVL) | $100-$1,000 | Strong spam protection needed |
Attack prevention: Cannot place thousands of $1 orders across many ticks—would require locking significant capital ($1,000+ per tick) and paying gas for each placement.
Tick spacing
Orders can only be placed at discrete tick intervals (e.g., every 10 bps = ~1% spacing):
- $5,000 (valid)
- $5,050 (valid, +10 bps from $5,000)
- $5,100 (valid, +10 bps from $5,050)
- $5,025 (invalid, not on 10 bp grid)
Attack prevention: Concentrates liquidity at predictable levels, prevents liquidity fragmentation across adjacent ticks. An attacker must concentrate capital into fewer price points.
Maximum ticks per swap
Swaps can cross at most 16-32 ticks per execution:
- Normal trades: Cross 0-3 ticks, no impact
- Large trades: Cross many ticks, but gas cost is bounded
- Attack prevention: Cannot force swaps to cross hundreds of ticks (would revert or complete partially)
Fallback: If a swap needs to cross more ticks than the limit, remaining flow continues on the AMM curve.
Integration with minting
The orderbook is critical for open interest minting because it solves the Case B liquidity problem:
Problem: When acquisition price < pool price, the CL AMM has no upward liquidity (no mechanism for buy orders above current price). New tokens must be sold into existing liquidity, pushing price down.
Solution: The orderbook provides standing buy interest above current price:
- Before acquisition: Issuers see committed demand at various price levels
- Acquisition decision: Acquire asset knowing market will absorb supply at target prices
- Token release: New tokens preferentially fill orderbook buy orders above acquisition price
- Orderly execution: Tokens absorbed by committed capital, not dumped into AMM
Example: Pool trading at $5,000. Issuer sees orderbook:
- Buy orders at $5,100: $500k
- Buy orders at $5,200: $300k
Issuer acquires asset at $4,800, mints 1,000 tokens. When released:
- First ~98 tokens fill buy orders at $5,100 ($500k / $5,100)
- Next ~58 tokens fill buy orders at $5,200 ($300k / $5,200)
- 156 tokens absorbed by orderbook at premium to acquisition price
- Remaining 844 tokens enter AMM or other mechanisms
This transforms minting from supply-push (dump into pool) to demand-pull (fill committed orders).
Comparison to traditional orderbooks
| Dimension | Traditional CLOB | Price-Gated Orderbook (This System) |
|---|---|---|
| Matching | Continuous, active matching loop | Triggered by AMM price crossings |
| Price path | Book-driven (bids/asks determine) | AMM-driven (curve determines crossings) |
| Execution | Immediate transfer per match | Deferred claims (accrued balances) |
| Liquidity | Standalone, can be fragmented | Composable with AMM (fallback liquidity) |
| Gas profile | High (per-order operations) | Bounded (per-tick operations) |
| Fairness | Price-time strict | Price strict, time configurable (pro-rata) |
| Infrastructure | Requires matching engine | Uses AMM routing (no separate matcher) |
| Fragmentation | Order books can be thin/illiquid | AMM backstop ensures continuous liquidity |
Key distinction: This is not a traditional orderbook with continuous matching. It's a price-gated interception layer where orders only execute when the AMM price path would cross them. The AMM provides the price discovery and fallback liquidity; the orderbook provides precision execution at discrete prices.
Privacy considerations
Public orders (V1)
Initial implementation uses fully transparent orders:
- Order placements are public events
- Sizes and prices visible to all participants
- Orderbook state readable by anyone
Benefits:
- Simple implementation (no cryptographic overhead)
- Easy router integration (aggregators see depth)
- Market participants can gauge depth and sentiment
Risks:
- Front-running: Sophisticated actors see incoming orders and position ahead
- Information leakage: Competitors see demand signals (especially important for issuers planning acquisitions)
- Strategic gaming: Traders may place and cancel orders to mislead others
Private orders (future enhancement)
As the protocol matures, private order placement becomes critical:
Commit-reveal orders:
- Users commit to order hash without revealing details
- Order reveals only when executing or after time delay
- Prevents front-running during placement
Zero-knowledge orders:
- Order prices and sizes hidden via ZK proofs
- Tree updates use homomorphic properties
- Execution reveals minimal information
Trade-off: Full privacy reduces router visibility (can't see depth off-chain), affecting routing efficiency. Hybrid approach might show that liquidity exists at price levels without revealing exact amounts.
Why this matters: As markets grow and order flow becomes more sophisticated, information leakage becomes a more serious concern. Private orders enable users to express demand without revealing intentions to competitors or front-runners.
Why this matters
The orderbook bridges the gap between AMM simplicity and orderbook precision:
Without the orderbook
- Traders must actively monitor markets for target prices (poor UX)
- Market orders experience slippage on thin liquidity
- Directional traders forced to provide two-sided liquidity (IL exposure)
- No forward demand signals for new supply (Case B problem unsolved)
- Position management requires constant monitoring and rebalancing
With the orderbook
- Set-and-forget execution at exact target prices
- Deep resting liquidity visible to all participants
- Familiar UX for traders from traditional markets
- Forward demand signals enable demand-pull minting
- Capital efficiency for directional bets without IL risk
- Composable with AMM routing and aggregators
For RWA markets where collectors want precise execution without constant monitoring, the orderbook provides institutional-grade trading UX while maintaining full on-chain atomicity and composability. Combined with the CL AMM, it creates a hybrid system that offers both continuous liquidity (AMM) and precision execution (orderbook) in a single, gas-efficient implementation.
Related reading
- Open Interest (Minting) — How the orderbook integrates with supply management to solve Case B
- Limit Orders — User-facing limit order interface and strategies
- Price Dynamics — Understanding Case A and Case B minting scenarios
- CL AMM Primer — Understanding the underlying AMM infrastructure
- Liquidity Management — Professional market making strategies
Implementation details
For developers interested in the technical implementation, data structures, gas optimization techniques, and security considerations, see:
Open Interest Implementation Notes — Comprehensive technical specification including:
- SumTree (Fenwick Tree) data structure and algorithms
- Gas cost analysis and optimization techniques
- Security considerations and attack vectors
- Testing strategy and monitoring metrics
- Detailed code examples and pseudocode