Market Design

This document explains the market design of xBTC, including the trading model, order lifecycle, security mechanisms, and incentive design.

1. Trading Model
2. Order Lifecycle
3. Security Mechanisms
4. Incentive Design

1. Trading Model

1.1 Order Book Model

xBTC uses an on-chain order book model where sellers create orders by locking wrapped BTC in the smart contract. Buyers browse available orders and fulfill them by sending native BTC.

Order Structure

Field	Description
`tokenAmount`	Amount of wrapped BTC tokens being sold
`btcAmount`	Amount of BTC requested (in satoshis)
`btcAddress`	Seller's Bitcoin address to receive payment
`seller`	Seller's blockchain address
`status`	Current order status

1.2 Partial Fill Support

Orders can be partially filled, allowing buyers to purchase a portion of the available wrapped BTC:

Minimum Fill: Orders may specify a minimum fill amount
Pro-rata Pricing: Native BTC amount is calculated proportionally to the wrapped BTC amount purchased
Remaining Balance: Unfilled wrapped BTC remains in the order for future buyers

Example

If an order sells 1.0 wrapped BTC for 1.0 native BTC, a buyer can purchase 0.5 wrapped BTC for 0.5 native BTC. The remaining 0.5 wrapped BTC stays available at the same rate.

1.3 Price Discovery

Prices are determined by individual sellers when creating orders. The market achieves price discovery through:

Competition: Multiple sellers compete by offering better rates
Visibility: All orders are visible on-chain, enabling transparent comparison
Market Forces: Orders with better prices get filled first

2. Order Lifecycle

2.1 Order States

State	Description	Actions Available
Active	Order is open and available for purchase	Buy, Cancel
Pending	BTC payment sent, awaiting confirmation	Complete (after confirmation)
Completed	Order fully filled, wrapped BTC transferred to buyer(s)	None
Cancelling	Cancel requested, in waiting period	Wait for timeout
Cancelled	Order cancelled, wrapped BTC returned to seller	None

2.2 State Transitions

// Order State Machine createOrder() │ ▼ ┌─────────────────────────────────────────────────────────┐ │ ACTIVE │ │ - Wrapped BTC locked in contract │ │ - Available for purchase │ └─────────────────────────────────────────────────────────┘ │ │ buyOrder() │ │ cancelOrder() ▼ ▼ ┌───────────────────────┐ ┌───────────────────────────┐ │ PENDING │ │ CANCELLING │ │ - BTC tx broadcasted │ │ - Waiting period active │ │ - Awaiting confirms │ │ - Can still be purchased │ └───────────────────────┘ └───────────────────────────┘ │ │ completeOrder()│ │ timeout ▼ ▼ ┌───────────────────────┐ ┌───────────────────────────┐ │ COMPLETED │ │ CANCELLED │ │ - wBTC transferred │ │ - wBTC returned │ │ - Order closed │ │ - Order closed │ └───────────────────────┘ └───────────────────────────┘

2.3 Trading Flow

Create Order

Seller locks wrapped BTC in smart contract, specifies native BTC amount and receiving address.

Browse & Select

Buyer browses available orders and selects one with acceptable price.

Send BTC

Buyer sends native BTC to seller's address with OP_RETURN containing buyer's receiving address.

Wait for Confirmation

BTC transaction requires sufficient confirmations for security.

Complete Order

Anyone can submit the BTC block proof to complete the order and release wrapped BTC.

3. Security Mechanisms

3.1 Wrapped BTC Locking

When a seller creates an order, wrapped BTC is transferred to and held by the smart contract:

Wrapped BTC cannot be withdrawn except through order completion or cancellation
The contract holds wrapped BTC in escrow until conditions are met
No third party can access the locked wrapped BTC

3.2 Cancellation Waiting Period

To prevent front-running attacks, order cancellation has a mandatory waiting period:

How It Works

Seller initiates cancellation (order enters CANCELLING state)
Waiting period begins (configurable, e.g., 1 hour)
During this period, buyers can still complete purchases
After timeout, seller can finalize cancellation and reclaim wrapped BTC

Why This Matters

Without a waiting period, a seller could see an incoming native BTC transaction and quickly cancel the order before it confirms, stealing both the native BTC and keeping the wrapped BTC.

3.3 BTC Transaction Verification

The platform uses on-chain verification to ensure BTC payments are valid:

Block Header Verification: Validates the BTC block containing the transaction
Merkle Proof: Proves the transaction is included in the block
Output Verification: Confirms correct amount sent to correct address
OP_RETURN Parsing: Extracts buyer's receiving address from transaction

For detailed technical information, see BTC On-Chain Verification.

3.4 Confirmation Requirements

Transaction Size	Required Confirmations	Approximate Time
Small (< 0.1 BTC)	1-2 confirmations	~10-20 minutes
Medium (0.1-1 BTC)	3-4 confirmations	~30-40 minutes
Large (> 1 BTC)	6+ confirmations	~60+ minutes

4. Incentive Design

4.1 Block Verification Incentives

The SelfValidator contract includes an incentive mechanism for block verification challenges:

Role	Action	Incentive
Submitter	Submit block hash for verification	Deposit refunded if valid
Challenger	Challenge invalid block with valid blocks	Earn submitter's deposit as reward
Supporter	Support valid block with additional blocks	Share of challenger deposits if they win

Economic Security

The challenge mechanism creates economic incentives for honest behavior. Attempting to submit fake blocks results in losing deposits, while challenging fake blocks earns rewards.

4.2 Market Maker Incentives

Sellers (market makers) benefit from:

No Platform Fees: Keep 100% of the trading spread
Partial Fills: Orders can be filled incrementally
Competitive Pricing: Set your own rates based on market conditions

4.3 Buyer Incentives

Buyers benefit from:

Transparent Pricing: All orders visible on-chain
Trustless Execution: No counterparty risk after BTC confirmation
Competition: Multiple sellers compete for best rates

Win-Win Design

The market design aligns incentives so that honest participation is the most profitable strategy for all parties.