Order Flow

Complete Lifecycle: Client → Storage

Understanding how an order flows through Frontier Chain from submission to final storage is essential to appreciating the system's determinism, security, and performance.

┌──────────────┐
│   CLIENT     │
│              │
│ 1. Sign      │  EIP-712 signature with order parameters
│    Order     │  (pair, side, quantity, price, timestamp)
└──────┬───────┘
       │
       ▼
┌──────────────┐
│  API SERVER  │
│              │
│ 2. Validate  │  • Verify EIP-712 signature
│    Submit    │  • Check balance availability
│              │  • Assign order ID
└──────┬───────┘
       │
       ▼
┌──────────────┐
│    GOSSIP    │
│   PROTOCOL   │
│              │
│ 3. Propagate │  • Broadcast to all validators via QUIC
│              │  • Add to local mempool
│              │  • Track order age (must be >30ms old)
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ CONSENSUS    │
│   LEADER     │
│              │
│ 4. Propose   │  • Select orders >30ms old
│    Block     │  • Execute through Frontier-Core engine
│              │  • Create block with order hashes + state root
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ VALIDATORS   │
│              │
│ 5. Execute   │  • Receive block proposal
│    Validate  │  • Execute same orders by hash
│              │  • Vote if state roots match
└──────┬───────┘
       │
       ▼
┌──────────────┐
│  CONSENSUS   │
│   COMMIT     │
│              │
│ 6. Finalize  │  • Collect 2f+1 votes (QC)
│              │  • Mark block as finalized
│              │  • Update account balances
│              │  • Generate trade confirmations
└──────┬───────┘
       │
       ▼
┌──────────────┐
│   STORAGE    │
│ (Validators) │
│ 7. Persist   │  • Commit to memory (0.83ms)
│              │  • Async write to RocksDB
└──────────────┘
       │
       │ (API Server syncs separately)
       ▼
┌──────────────┐
│ PostgreSQL   │
│ (API Server) │
│              │  • Orders/trades queryable data
│              │  • Not required for consensus
└──────────────┘

---

Step 1: Client Order Signing

EIP-712 Signature Standard

All orders are signed using EIP-712, the Ethereum standard for typed structured data hashing and signing.

Why EIP-712?

• Industry standard supported by all major wallets (MetaMask, Ledger, etc.)

• Human-readable signing - users see what they're signing

• Replay protection via domain separator

• Type safety prevents signature misuse

Order Components

Orders contain the essential trading information:

• User: Ethereum address of the trader

• Trading Pair: Which market (BTC/USDC, ETH/USDC, etc.)

• Side: Buy or sell

• Order Type: Limit or market

• Quantity: Amount to trade (6 decimal precision)

• Price: Limit price (6 decimal precision)

• Timestamp: Order creation time

• Nonce: Timestamp-based for replay protection

Signing Process

1. Construct domain separator - Identifies the Frontier Chain instance

2. Hash the order data - Create cryptographic digest of order parameters

3. Sign with wallet - User signs the hash with their private key

4. Submit to API - Send signed order to REST endpoint

Nonce Management

Frontier Chain uses timestamp-based nonces:

• Orders must be submitted within 5 minutes of creation

• Prevents replay attacks across different time periods

• No need to track sequential nonces per account

• Enables parallel order submission from same account

---

Step 2: API Server Validation

The API server performs several validation checks before accepting an order:

Signature Verification

1. Reconstruct EIP-712 hash from the order data

2. Recover signer address from the signature using ECDSA

3. Verify the signer matches the order's user address

4. Reject if mismatch - prevents unauthorized order submission

Balance Validation

The API checks that the user has sufficient funds:

• Buy orders: Requires quote currency (USDC) equal to quantity × price

• Sell orders: Requires base currency (BTC, ETH, etc.) equal to quantity

If insufficient balance, the order is rejected immediately without entering the gossip network.

Order ID Assignment

Each accepted order receives a unique, sequential order ID for tracking and reference throughout its lifecycle.

---

Step 3: Gossip Propagation

QUIC Broadcast

Once validated, the API server broadcasts the order to all validators using QUIC networking:

1. Serialize order - Convert to efficient binary format

2. Broadcast concurrently - Send to all validators simultaneously

3. Wait for quorum - Ensure 2f+1 validators acknowledge receipt

4. Fail if timeout - Retry if propagation fails

QUIC provides fast, reliable delivery with built-in encryption and stream multiplexing.

Mempool Insertion

Each validator adds the received order to its local mempool:

Mempool Properties:

• Capacity: 100,000 orders maximum

• Tracking: Records arrival time for each order

• Eviction: Removes oldest orders when full

• Eligibility: Only orders >30ms old can be proposed

The mempool ensures all validators have the same set of orders before consensus begins.

Why 30ms Minimum Age?

Purpose: Ensure fair ordering and prevent leader advantage

Rationale:

1. Network Propagation: Orders need time to reach all validators (10-20ms typical)

2. Fair Ordering: Leader cannot propose orders they just received (others don't have)

3. Prevents Front-Running: Leader can't insert own orders immediately

4. BFT Safety: All validators must have all orders to execute identically

Measured Propagation Times:

• Same datacenter: 5-10ms

• Cross-region (US): 20-30ms

• Cross-continent: 50-100ms

For production, 30ms is conservative (could be increased to 50ms for global deployment).

---

Step 4: Consensus Proposal

Leader Order Selection

The consensus leader (rotating each view) selects orders for the next block:

1. Get eligible orders - Only orders >30ms old in mempool

2. Sort deterministically - By timestamp (oldest first), then by hash (tiebreaker)

3. Limit quantity - Maximum 20,000 orders per block

4. Execute locally - Run orders through Frontier-Core matching engine

5. Compute state root - Hash of resulting state

6. Create proposal - Package order hashes and state root

The leader sends this proposal to all validators for verification.

Execution Through Frontier-Core

The matching engine processes the batch of orders:

For Each Order:

• Limit orders: Add to order book or match against existing orders

• Market orders: Execute immediately at best available price

• Update balances: Debit buyers, credit sellers

• Record trades: Log all fills with price and quantity

Result: Complete batch execution with all trades and balance changes.

---

Step 5: Validator Execution

Follower Validation

Non-leader validators (followers) verify the leader's proposal:

1. Check mempool - Verify all order hashes are in local mempool

2. Execute identically - Run orders through matching engine in same sequence

3. Compute state root - Hash the resulting state

4. Compare roots - Must match leader's state root exactly

5. Accept or reject - Only vote if state roots match

This ensures all validators reach identical state through deterministic execution.

Vote Submission

If validation succeeds, the validator votes:

1. Create vote message - Contains block hash, view number, and validator ID

2. Sign with Ed25519 - Cryptographically sign the vote

3. Send to next leader - Broadcast vote to all validators

Validators that detect a mismatch do not vote, preventing invalid blocks from being committed.

---

Step 6: Consensus Finality

Quorum Certificate Formation

The next leader collects votes from all validators:

Quorum Requirements:

• Need 2f+1 votes out of 3f+1 total validators

• Example: With 10 validators, need 7 votes (can tolerate 3 Byzantine)

• Each vote includes validator ID and Ed25519 signature

Once quorum is reached, a Quorum Certificate (QC) is formed proving the block has consensus.

Block Commit

When a QC is formed, the block is committed (100ms):

1. Verify QC - Check all signatures are valid

2. Mark committed - Block is now confirmed

3. Apply state - Balance updates and trade records become active

4. Clear mempool - Remove processed orders

5. Notify clients - Orders are "filled" at this point

The block is committed but not yet finalized (requires 3-chain rule for finality at 300ms).

---

Step 7: Storage Persistence

Frontier Chain validators use a two-tier storage system for blockchain data:

Memory Commit (0.83ms)

Block data is immediately committed to memory:

What's Stored:

• Block metadata (number, timestamp, leader)

• Order hashes for this block

• Individual order details

• Execution results (trades, balance updates)

Performance: Average 0.83ms commit time (consensus-critical path)

Retention: Last 100 blocks (~10 seconds) kept in memory for fast access

Async RocksDB Persistence

A background worker persists blocks to disk without blocking consensus:

Process:

1. Serialize block data to binary format (Borsh encoding)

2. Write to RocksDB key-value store

3. Store both full blocks and individual orders

4. Maintain complete blockchain history

Performance: Async writes don't delay consensus (1-12ms depending on batch size)

Purpose: Provides durable storage for the entire blockchain history

---

API Server Data Layer

Separate from consensus: The API server (not validators) optionally maintains PostgreSQL/TimescaleDB for analytics.

PostgreSQL/TimescaleDB (API Server Only)

The API server syncs blockchain data to PostgreSQL for efficient querying:

Orders Table:

• Order details (user, pair, side, quantity, price)

• Order status tracking (open, filled, cancelled)

• Enables REST API queries for order history

Trades Table:

• Trade execution records

• Maker/taker addresses and fees

• Powers trade history endpoints

Balance Tracking:

• User balances across all assets

• Balance history for auditing

• Real-time balance queries

Important: This database is for API queries only - validators do not require PostgreSQL and rely solely on Memory + RocksDB for consensus.

---

Order Execution Determinism

Critical Deterministic Factors

1. Order Sequence

• Orders executed in hash order (from leader's proposal)

• All validators execute in identical sequence

• No variability in order processing

2. Fixed-Precision Arithmetic

// All calculations use 6 decimal precision
const PRECISION: u128 = 1_000_000;

// Price calculation (deterministic)
fn calculate_cost(quantity: u128, price: u128) -> u128 {
    (quantity * price) / PRECISION
}

// No floating point (non-deterministic rounding)

3. Block Timestamp (Not System Time)

// ❌ WRONG - Different per validator
let timestamp = SystemTime::now().as_millis();

// ✅ CORRECT - Same for all validators
let timestamp = block.timestamp;

4. No External State

• Matching engine is pure (no external dependencies)

• No network calls during execution

• No file I/O

• No random numbers

Determinism Verification

// Test: Execute 1000 times, expect identical results
#[test]
fn test_deterministic_execution() {
    let orders = create_test_orders();

    // Execute 1000 times
    let mut results = Vec::new();
    for _ in 0..1000 {
        let mut engine = MatchingEngine::new();
        let result = engine.execute_batch(&orders);
        results.push(result.state_root);
    }

    // All state roots must be identical
    assert!(results.iter().all(|r| r == &results[0]));
}

---

Performance Metrics

Order Flow Latency

Stage	Latency	Cumulative
Colocated submission	<100μs	<0.1ms (direct validator connection)
Client signing	10-50ms	10-50ms
API validation	2-5ms	12-55ms
Gossip propagation	10-30ms	22-85ms
Mempool age requirement	30ms	52-115ms
Consensus proposal	5-10ms	57-125ms
Validator execution	10-20ms	67-145ms
QC formation	10-20ms	77-165ms
Memory commit	0.83ms	78-166ms
Total order-to-commit	~100-200ms
3-chain finality	+300ms	(irreversible)

Throughput Capacity

Per Block:

• 20,000 orders maximum

• 100ms block time

• 200,000 orders/second theoretical

Measured Performance:

• 369,000 operations/second sustained

• Includes deposits, withdrawals, cancellations, trades

• 40% headroom under maximum capacity

---

Failure Scenarios and Recovery

Order Rejected at API

Causes:

• Invalid signature

• Insufficient balance

• Malformed order data

Client Action:

• Immediate rejection response (HTTP 400)

• Fix and resubmit

Gossip Failure

Causes:

• Network partition

• Validator offline

• QUIC connection issues

System Action:

• Retry propagation to failed validators

• Order remains in API mempool

• Resubmit in next gossip round

Consensus Timeout

Causes:

• Leader offline/slow

• Network partition

• State root mismatch

System Action:

• View change triggered

• New leader selected

• Orders remain in mempools

• Retry in next view

Execution Divergence

Causes:

• Non-deterministic execution bug

• Corrupted state

• Malicious leader

System Action:

• Validators refuse to vote

• View change triggered

• Orders remain valid

• Leader rotates

---

Conclusion

The order flow through Frontier Chain demonstrates careful design for determinism, security, and performance. From EIP-712 signature verification to memory-first storage, each stage is optimized to provide institutional-grade execution with full transparency and Byzantine fault tolerance.

Key Flow Properties:

1. Cryptographic Security: EIP-712 signatures at every step

2. Fair Ordering: 30ms gossip age prevents leader advantage

3. Deterministic Execution: All validators compute identical results

4. Fast Finality: 100-200ms order-to-confirmation

5. Fault Tolerance: Automatic recovery from failures