Order Book Trading

After graduation, markets transition from the bonding curve to a Central Limit Order Book (CLOB) for secondary trading.

---

Order Book vs AMM

BaseCase uses an order book post-graduation rather than an automated market maker:

Characteristic	Order Book	AMM (e.g., Uniswap)
Liquidity source	User limit orders	Protocol-seeded pool
Capital required	None	Significant
Price discovery	Supply/demand matching	Formula-based
Spread control	Competitive makers	Tick configuration
Limit orders	Native	Indirect
Gas efficiency	Moderate	High

---

Order Book Structure

Dual Books

Each market maintains two order books:

Price Constraint

Binary outcome markets enforce:

YES_price + NO_price = $1.00

An order to buy YES at $0.65 is equivalent to selling NO at $0.35.

---

Order Types

Limit Orders

Place an order at a specific price. Executes when a matching order arrives.

Limit Buy: "Buy 500 YES at $0.60 or better"
├── If ask exists at $0.60 → Immediate fill
├── If no match → Order rests in book
└── Cancellable until filled

Market Orders

Execute immediately against best available prices.

Market Buy: "Buy 500 YES at best available"
├── Takes from lowest asks
├── May execute across multiple price levels
└── Subject to slippage on large orders

---

Order Matching

Matching Engine

Orders match according to price-time priority:

1. PRICE: Best price executes first
2. TIME: Among equal prices, earliest order executes first

Execution Example

Book State:

ASKS: $0.65 × 200, $0.67 × 300, $0.70 × 500

Incoming Order: Market buy 400 YES

Execution:

Fill 200 @ $0.65 = $130.00
Fill 200 @ $0.67 = $134.00
────────────────────────────
Total: 400 YES for $264.00
Avg price: $0.66/share

---

Complete Sets

After graduation, users can mint and redeem complete sets to provide liquidity:

Mint Complete Set

Deposit $1 USDC, receive 1 YES + 1 NO token:

mintCompleteSet(amount):
├── User deposits: amount × $1 USDC
├── User receives: amount YES tokens
├── User receives: amount NO tokens
└── Vault increases by: amount

Redeem Complete Set

Burn 1 YES + 1 NO token, receive $1 USDC:

redeemCompleteSet(amount):
├── User burns: amount YES tokens
├── User burns: amount NO tokens
├── User receives: amount × $1 USDC
└── Vault decreases by: amount

[!TIP] Market Making Strategy: Mint complete sets, then sell one side on the order book to take a position while providing liquidity.

Use Cases

Use Case	How
Enter market	Mint sets, sell NO on the book to go long YES
Exit position	Buy opposite side, redeem sets for USDC
Arbitrage	If YES + NO < $1, buy both and redeem
Market making	Mint sets, place bids/asks on both sides

Fee Structure

Action	Fee	Recipient
Limit order (maker)	0%	N/A
Market order (taker)	0.1%	50% Protocol / 50% Creator
Order cancellation	0%	N/A

Maker orders (adding liquidity) are free to incentivize tight spreads. Taker fees are split equally between the protocol and the market creator.

---

Comparison: Bonding Curve vs Order Book

Aspect	Bonding Curve	Order Book
Phase	Pre-graduation	Post-graduation
Pricing	CPMM formula	Supply/demand
Fee	0%	0-0.2%
Slippage	Formula-determined	Depth-dependent
Limit orders	Not available	Native
Token type	Soulbound ERC-20	Transferable ERC-20

---

Implementation Architecture

On-Chain Components

struct Order {
    address maker;
    bool isYes;      // YES or NO token
    bool isBuy;      // Buy or sell
    uint256 price;   // Price in basis points (0-10000)
    uint256 amount;  // Token quantity
    uint256 filled;  // Amount already filled
    uint256 timestamp;
}

mapping(uint256 => Order) public orders;
uint256 public nextOrderId;

Off-Chain Components

For gas efficiency, matching occurs off-chain:

1. User signs order intent
2. Relayer collects matching orders
3. Relayer submits matched batch on-chain
4. Contract verifies signatures and settles

This hybrid approach reduces gas costs while maintaining settlement security.

---

Integration with Resolution

Pre-Resolution Trading

Market active:
├── Order book trading enabled
├── Prices reflect probability
└── Users can enter/exit positions

Resolution Event

Oracle settles outcome:
├── Trading halted
├── Fixed $1/share redemption enabled
└── Winners also share OG bonus pool

Redemption (Fixed $1 + OG Bonus)

function claimWinnings() external {
    require(resolved, "Market not resolved");
    
    uint256 winningShares = winningToken.balanceOf(msg.sender);
    
    // Fixed $1 per share + OG bonus for bonding participants
    uint256 payout = winningShares; // $1/share
    uint256 bonus = (ogShares * ogBonusPool) / totalOGShares;
    
    winningToken.burn(msg.sender, winningShares);
    usdc.transfer(msg.sender, payout + bonus);
}

---

Advantages of Order Book Design

1. No Liquidity Requirements

Protocol does not need to seed liquidity. Users provide liquidity through limit orders.

2. Better Price Efficiency

Near resolution, prices can approach 0% or 100% with tight spreads, unlike AMM asymptotic limits.

3. Native Limit Orders

Users can set exact entry/exit prices without workarounds.

4. Competitive Spreads

Market makers compete to offer best prices, reducing trading costs.

5. Transparency

Full order book visibility shows market depth and sentiment.