# 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:

{% @mermaid/diagram content="flowchart LR
subgraph YES\["YES/USDC"]
YA\["ASKS<br/>$0.72 × 200<br/>$0.70 × 500<br/>$0.68 × 1,000"]
YB\["BIDS<br/>$0.65 × 800<br/>$0.63 × 1,200<br/>$0.60 × 2,000"]
end

```
subgraph NO["NO/USDC"]
    NA["ASKS<br/>$0.32 × 150<br/>$0.30 × 400<br/>$0.28 × 800"]
    NB["BIDS<br/>$0.25 × 600<br/>$0.23 × 1,000<br/>$0.20 × 1,500"]
end

style YES fill:#f0fdf4,stroke:#22c55e,stroke-width:2px,color:#000000
style NO fill:#fef2f2,stroke:#ef4444,stroke-width:2px,color:#000000
style YA fill:transparent,color:#000000,stroke:none
style YB fill:transparent,color:#000000,stroke:none
style NA fill:transparent,color:#000000,stroke:none
style NB fill:transparent,color:#000000,stroke:none" %}
```

### 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

```solidity
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)

```solidity
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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.basecase.gg/core-concepts/order-book.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.