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
Construct domain separator - Identifies the Frontier Chain instance
Hash the order data - Create cryptographic digest of order parameters
Sign with wallet - User signs the hash with their private key
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
Reconstruct EIP-712 hash from the order data
Recover signer address from the signature using ECDSA
Verify the signer matches the order's user address
Reject if mismatch - prevents unauthorized order submission
Balance Validation
The API checks that the user has sufficient funds:
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
3. Block Timestamp (Not System Time)
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
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:
Cryptographic Security: EIP-712 signatures at every step
Fair Ordering: 30ms gossip age prevents leader advantage
Deterministic Execution: All validators compute identical results
// 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)
// ❌ WRONG - Different per validator
let timestamp = SystemTime::now().as_millis();
// ✅ CORRECT - Same for all validators
let timestamp = block.timestamp;
// 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]));
}
