lx/hyperliquid/HYPERLIQUID_STUDY_NOTES.md

Hyperliquid vs Local Engines: Comprehensive Study Notes

Executive Summary

This document provides an in-depth technical comparison between Hyperliquid's production architecture and our local engine implementations (Go, C++, TypeScript). It identifies critical gaps, architectural patterns, and provides a roadmap for achieving feature parity with Hyperliquid while leveraging the strengths of each implementation language.

1. Architecture Comparison Matrix

Component	Hyperliquid	Go Engine	C++ Engine	TypeScript Engine	Gap Analysis
Core Architecture	Event-sourced, blockchain-based	Service-oriented, modular	Monolithic, high-performance	Browser/Node compatible	TS lacks event sourcing
State Management	Periodic snapshots + event log	In-memory with sync.Map	Arena allocators, RAII	Basic in-memory maps	TS needs persistence layer
Order Book	BTreeMap (Rust) + LinkedList	Sorted slices + binary search	AVL trees + custom allocators	Fibonacci heap/AVL tree	TS needs optimization
Consensus	Blockchain consensus	N/A	N/A	N/A	Consider distributed consensus
Performance	Block-based batching	400k+ ops/sec	2.7M+ ops/sec	~20k ops/sec	TS needs 20x improvement
Latency	~100μs (batched)	600-830μs	24-138ns	10-50μs	TS acceptable for low-freq
Protocol Support	Custom WebSocket + JSON	FIX 4.4, gRPC, WebSocket	FIX 4.4, custom binary	HTTP, Socket.IO	TS missing FIX protocol
Market Data	L2/L4 book, trades, candles	UDP multicast, WebSocket	Custom high-speed	Basic WebSocket	TS needs L4 book support

2. Hyperliquid's Unique Architectural Patterns

2.1 Event Sourcing with Blockchain

Hyperliquid Innovation:

// Events are the source of truth
struct NodeEvent {
    block_number: u64,
    timestamp: u64,
    event_type: EventType,
    payload: Vec<u8>,
}

// State is derived from events
fn rebuild_state(events: Vec<NodeEvent>) -> OrderBookState

Key Benefits:

• Auditability: Complete history of all state changes
• Deterministic Replay: Can rebuild state from any point
• Consensus: All nodes agree on event ordering
• Recovery: Fast recovery from crashes using snapshots + recent events

Implementation Gap in Our Engines:

• Go/C++: Have in-memory state without event log
• TypeScript: No persistence or event sourcing
• Required: Add event journal with periodic snapshots

2.2 L4Book Innovation

Hyperliquid's L4Book Protocol:

{
  "type": "l4Book",
  "snapshot": {
    "bids": [
      {"px": "100.5", "sz": "10", "oid": "0x123", "user": "0xabc", "ts": 1234567890}
    ]
  },
  "diffs": [
    {"action": "add", "side": "bid", "order": {...}}
  ]
}

Advantages over Standard L2:

• Full order transparency (order IDs, users)
• Enables advanced order tracking
• Supports order-level analytics
• Facilitates audit trails

Implementation Requirements for TS:

1. Extend order book to track order metadata
2. Implement snapshot + diff protocol
3. Add WebSocket subscription management
4. Optimize diff generation for performance

2.3 Conservative State Management

Hyperliquid's Approach:

// Exit on divergence rather than risk incorrect data
if local_state != authoritative_snapshot {
    panic!("State divergence detected");
}

Philosophy:

• Fail Fast: Better to stop than propagate errors
• Regular Validation: Periodic snapshot comparisons
• Conservative Design: No assumptions about consistency

Adoption Strategy:

• Add snapshot validation to all engines
• Implement health checks with automatic shutdown
• Add divergence metrics and alerting

3. Performance Deep Dive

3.1 Latency Breakdown

Operation	Hyperliquid	Go	C++	TypeScript	Target for TS
Order Insert	~50μs	0.37μs	24ns	10μs	<1μs
Order Match	~100μs	~1μs	50ns	20μs	<5μs
Order Cancel	~50μs	0.5μs	30ns	15μs	<2μs
Book Update	~20μs	0.2μs	10ns	5μs	<1μs
WebSocket Send	~100μs	50μs	20μs	100μs	<50μs

3.2 Throughput Analysis

Message Processing Rates:

• Hyperliquid: 100k+ events/second (batched by block)
• Go Engine: 400k+ operations/second
• C++ Engine: 2.7M+ operations/second
• TypeScript: ~20k operations/second

Bottleneck Analysis for TypeScript:

1. GC Pressure: Excessive object allocation
2. Data Structure: Inefficient heap operations
3. Serialization: JSON parsing overhead
4. Single-threaded: No parallelization

3.3 Memory Patterns

Hyperliquid (Rust):

// Zero-copy with careful lifetime management
struct OrderBook<'a> {
    orders: Vec<Order<'a>>,
    index: HashMap<OrderId, usize>,
}

C++ Engine:

// Custom allocators for cache locality
template<typename T>
class PoolAllocator {
    std::vector<T> pool;
    std::queue<T*> available;
};

TypeScript Optimization Needed:

// Current: Creates new objects frequently
const order = { id, price, size }; // Allocation

// Optimized: Reuse objects
class OrderPool {
    private available: Order[] = [];
    acquire(): Order { /* reuse */ }
    release(order: Order) { /* return to pool */ }
}

4. Feature Gap Analysis

4.1 Critical Missing Features in TypeScript Engine

Tier 1 - Essential for Production:

Feature	Hyperliquid	Go/C++	TypeScript	Implementation Effort
FIX Protocol	✓ (via gateway)	✓	✗	4-6 weeks
Event Sourcing	✓	Partial	✗	3-4 weeks
L4Book Support	✓	✗	✗	2-3 weeks
Multi-Instrument	✓	✓	✗	2-3 weeks
Persistence	✓	✗	✗	3-4 weeks
Stop Orders	✓	✓	✗	1-2 weeks
IOC/FOK Orders	✓	✓	✗	1 week

Tier 2 - Important for Scale:

Feature	Hyperliquid	Go/C++	TypeScript	Implementation Effort
Position Tracking	✓	✓	✗	2-3 weeks
Risk Limits	✓	Partial	✗	2-3 weeks
Market Data Stats	✓	✓	✗	1-2 weeks
Audit Trail	✓	✗	✗	2-3 weeks
Metrics/Monitoring	✓	✓	✗	1-2 weeks

4.2 Protocol Comparison

WebSocket Message Formats:

Hyperliquid:

{
  "channel": "l4Book",
  "data": {
    "coin": "ETH",
    "time": 1234567890,
    "snapshot": { /* full book */ },
    "diffs": [ /* incremental updates */ ]
  }
}

Our Current TS Implementation:

{
  "type": "orderbook",
  "symbol": "ETH",
  "bids": [[price, size]],
  "asks": [[price, size]]
}

Required Enhancement:

• Add order-level detail
• Implement snapshot + diff pattern
• Add block number/sequence tracking
• Support subscription management

5. Implementation Roadmap for TypeScript Engine

Phase 1: Core Infrastructure (Weeks 1-4)

// 1. Event Sourcing Foundation
interface Event {
    sequenceNumber: bigint;
    timestamp: bigint;
    type: EventType;
    payload: any;
}

class EventStore {
    async append(event: Event): Promise<void>;
    async replay(from: bigint): Promise<Event[]>;
    async snapshot(): Promise<State>;
}

// 2. Enhanced Order Book
class OrderBook {
    private bids: RBTree<Price, OrderQueue>;
    private asks: RBTree<Price, OrderQueue>;
    private orderIndex: Map<OrderId, OrderDetails>;
    
    // L4Book support
    getL4Snapshot(): L4BookSnapshot;
    getL4Diffs(since: bigint): L4BookDiff[];
}

// 3. Multi-Instrument Manager
class InstrumentManager {
    private books: Map<Symbol, OrderBook>;
    private eventStore: EventStore;
    
    async processOrder(order: Order): Promise<Trade[]>;
    async recover(): Promise<void>;
}

Phase 2: Protocol Support (Weeks 5-8)

// 1. FIX Protocol Implementation
class FIXSession {
    private sequenceIn: number;
    private sequenceOut: number;
    
    parse(message: Buffer): FIXMessage;
    send(message: FIXMessage): void;
    handleLogon(): void;
    handleNewOrder(order: NewOrderSingle): void;
}

// 2. Enhanced WebSocket Protocol
class L4BookSubscription {
    private symbol: string;
    private lastSequence: bigint;
    
    sendSnapshot(): void;
    sendDiff(diff: L4BookDiff): void;
    handleResubscribe(from: bigint): void;
}

Phase 3: Advanced Features (Weeks 9-12)

// 1. Advanced Order Types
class StopOrder extends Order {
    triggerPrice: Decimal;
    triggered: boolean;
    
    checkTrigger(marketPrice: Decimal): boolean;
}

// 2. Risk Management
class RiskManager {
    private positions: Map<Account, Position>;
    private limits: Map<Account, Limits>;
    
    validateOrder(order: Order): ValidationResult;
    updatePosition(trade: Trade): void;
    checkLimits(account: Account): boolean;
}

// 3. Performance Optimizations
class ObjectPool<T> {
    private available: T[] = [];
    
    acquire(): T;
    release(obj: T): void;
}

// Use TypedArrays for performance
class FastOrderBook {
    private bids: Float64Array;  // Price levels
    private asks: Float64Array;
    private orderData: Uint8Array; // Packed order data
}

Phase 4: Production Hardening (Weeks 13-16)

// 1. Monitoring and Metrics
class MetricsCollector {
    orderLatency: Histogram;
    throughput: Counter;
    bookDepth: Gauge;
    
    recordOrder(latency: number): void;
    export(): PrometheusMetrics;
}

// 2. High Availability
class ReplicatedOrderBook {
    private primary: OrderBook;
    private replicas: OrderBook[];
    
    async replicate(event: Event): Promise<void>;
    async failover(): Promise<void>;
}

// 3. Testing Infrastructure
class MarketSimulator {
    generateRandomOrders(rate: number): AsyncIterator<Order>;
    replayHistoricalData(file: string): AsyncIterator<Order>;
    validateInvariants(book: OrderBook): boolean;
}

6. Performance Optimization Strategy

6.1 TypeScript-Specific Optimizations

Memory Management:

// Bad: Creates garbage
function processOrder(order: any) {
    const normalized = {
        id: order.id,
        price: new Decimal(order.price),
        size: new Decimal(order.size)
    };
}

// Good: Reuses objects
const orderPool = new ObjectPool<Order>();
function processOrder(order: any) {
    const normalized = orderPool.acquire();
    normalized.id = order.id;
    normalized.price.set(order.price);
    normalized.size.set(order.size);
    // ... use normalized
    orderPool.release(normalized);
}

Data Structure Selection:

// Current: O(log n) heap operations
class FibonacciHeap { /* ... */ }

// Optimized: O(1) best price access
class IndexedOrderBook {
    private priceToOrders: Map<number, Order[]>;
    private bestBid: number;
    private bestAsk: number;
    
    // Maintain best prices incrementally
    updateBestPrices(): void {
        // O(1) in common case
    }
}

Avoiding V8 Deoptimization:

// Bad: Polymorphic function
function processMessage(msg: any) {
    if (msg.type === 'order') { /* ... */ }
    else if (msg.type === 'cancel') { /* ... */ }
}

// Good: Monomorphic functions
const processors = {
    order: processOrder,
    cancel: processCancel
};
function processMessage(msg: Message) {
    processors[msg.type](msg);
}

6.2 Concurrency Strategy

Worker Threads for CPU-Intensive Tasks:

// Main thread
const matchingWorker = new Worker('./matching-worker.js');
matchingWorker.postMessage({ type: 'match', orders });

// matching-worker.js
parentPort.on('message', (msg) => {
    const result = performMatching(msg.orders);
    parentPort.postMessage(result);
});

SharedArrayBuffer for Zero-Copy:

// Shared memory for order book
const sharedBuffer = new SharedArrayBuffer(1024 * 1024);
const orderBook = new Int32Array(sharedBuffer);

// Worker can read without copying
const worker = new Worker('./reader.js');
worker.postMessage({ orderBook: sharedBuffer });

7. Testing and Validation Strategy

7.1 Comprehensive Test Suite

Unit Tests:

describe('OrderBook', () => {
    it('should maintain price-time priority', () => {
        // Test FIFO at same price level
    });
    
    it('should handle self-match prevention', () => {
        // Test wash trading prevention
    });
    
    it('should correctly trigger stop orders', () => {
        // Test stop order activation
    });
});

Integration Tests:

describe('FIX Gateway', () => {
    it('should handle session recovery', () => {
        // Test sequence number gaps
    });
    
    it('should maintain message ordering', () => {
        // Test concurrent message handling
    });
});

Performance Tests:

describe('Performance', () => {
    it('should handle 100k orders/second', () => {
        // Throughput test
    });
    
    it('should maintain <1ms latency at 99th percentile', () => {
        // Latency test
    });
});

7.2 Comparison Testing

Cross-Implementation Validation:

class CrossValidator {
    async compareWithGo(scenario: Scenario): Promise<Diff[]> {
        const tsResult = await runTypeScript(scenario);
        const goResult = await runGo(scenario);
        return findDifferences(tsResult, goResult);
    }
    
    async compareWithHyperliquid(data: HistoricalData): Promise<Diff[]> {
        // Replay historical data and compare results
    }
}

8. Migration Strategy

8.1 Incremental Rollout

Phase 1: Development Environment

• Run TypeScript engine in parallel with Go/C++
• Compare outputs for discrepancies
• No real money at risk

Phase 2: Staging Environment

• Handle subset of instruments
• Monitor performance metrics
• Validate against production data

Phase 3: Production Canary

• Route 1% of traffic to TypeScript engine
• Gradual increase based on metrics
• Instant rollback capability

Phase 4: Full Production

• Complete migration for suitable use cases
• Maintain Go/C++ for ultra-low latency needs
• TypeScript for flexibility and rapid development

8.2 Compatibility Layer

// Adapter for existing clients
class LegacyAdapter {
    private newEngine: ModernOrderBook;
    
    // Translate old API to new
    submitOrder(oldFormat: any): void {
        const newFormat = this.translate(oldFormat);
        this.newEngine.submitOrder(newFormat);
    }
}

9. Monitoring and Observability

9.1 Key Metrics to Track

Performance Metrics:

• Order processing latency (p50, p95, p99)
• Throughput (orders/second, trades/second)
• WebSocket message rate
• Memory usage and GC metrics

Business Metrics:

• Order fill rate
• Order-to-trade ratio
• Market depth
• Spread metrics

System Health:

• Event store lag
• Snapshot divergence count
• WebSocket connection count
• Error rates by type

9.2 Implementation

import { Counter, Histogram, Gauge, register } from 'prom-client';

class Metrics {
    private orderLatency = new Histogram({
        name: 'order_processing_duration_ms',
        help: 'Order processing latency',
        buckets: [0.1, 0.5, 1, 5, 10, 50, 100, 500]
    });
    
    private orderThroughput = new Counter({
        name: 'orders_processed_total',
        help: 'Total orders processed',
        labelNames: ['type', 'status']
    });
    
    private bookDepth = new Gauge({
        name: 'order_book_depth',
        help: 'Number of orders in book',
        labelNames: ['symbol', 'side']
    });
}

10. Security Considerations

10.1 Order Validation

class SecurityValidator {
    validateOrder(order: Order): ValidationResult {
        // Check for wash trading
        if (this.isSelfMatch(order)) {
            return { valid: false, reason: 'Self-match prevention' };
        }
        
        // Check for spoofing patterns
        if (this.isSpoofing(order)) {
            return { valid: false, reason: 'Spoofing detected' };
        }
        
        // Rate limiting
        if (this.exceedsRateLimit(order.account)) {
            return { valid: false, reason: 'Rate limit exceeded' };
        }
        
        return { valid: true };
    }
}

10.2 Data Protection

// Encrypt sensitive data at rest
class EncryptedEventStore {
    private cipher: Cipher;
    
    async append(event: Event): Promise<void> {
        const encrypted = this.cipher.encrypt(event);
        await this.store.write(encrypted);
    }
}

// Audit trail for compliance
class AuditLog {
    async record(action: AuditAction): Promise<void> {
        await this.append({
            timestamp: Date.now(),
            action,
            user: action.userId,
            ip: action.ipAddress,
            details: action.details
        });
    }
}

11. Conclusion and Recommendations

11.1 Strategic Recommendations

1. Immediate Actions (Week 1):

   • Set up comprehensive benchmarking suite
   • Create feature comparison matrix
   • Begin event sourcing implementation

2. Short Term (Weeks 2-8):

   • Implement L4Book protocol
   • Add FIX protocol support
   • Optimize critical path performance

3. Medium Term (Weeks 9-16):

   • Achieve feature parity with Go engine
   • Implement Hyperliquid-specific features
   • Deploy to staging environment

4. Long Term (3-6 months):

   • Production deployment for suitable use cases
   • Continuous optimization based on metrics
   • Expand feature set based on user needs

11.2 Technology Stack Recommendations

Core Dependencies:

{
  "dependencies": {
    "@types/node": "^20.0.0",
    "decimal.js": "^10.4.0",
    "quickfix": "^0.5.0",  // FIX protocol
    "ws": "^8.0.0",        // WebSocket
    "prom-client": "^15.0.0", // Metrics
    "winston": "^3.0.0",   // Logging
    "ioredis": "^5.0.0"    // State persistence
  }
}

Development Tools:

{
  "devDependencies": {
    "typescript": "^5.0.0",
    "jest": "^29.0.0",
    "artillery": "^2.0.0",  // Load testing
    "clinic": "^12.0.0"    // Performance profiling
  }
}

11.3 Success Metrics

Technical Success:

• Achieve 100k+ orders/second throughput
• Maintain <1ms latency at p99
• Zero message loss or corruption
• 99.99% uptime

Business Success:

• Feature parity with Hyperliquid
• Support institutional FIX clients
• Enable rapid feature development
• Reduce operational costs

11.4 Risk Mitigation

Technical Risks:

• Performance may not meet targets

  • Mitigation: Maintain Go/C++ engines as fallback

• State management complexity

  • Mitigation: Extensive testing and gradual rollout

• Integration challenges

  • Mitigation: Comprehensive adapter layer

Business Risks:

• Development timeline overrun

  • Mitigation: Incremental delivery and MVP approach

• User adoption resistance

  • Mitigation: Parallel running and gradual migration

Appendix A: Code Examples

A.1 Hyperliquid-Compatible L4Book Implementation

interface L4Order {
    oid: string;      // Order ID
    px: string;       // Price
    sz: string;       // Size
    user: string;     // User address
    ts: number;       // Timestamp
}

interface L4BookSnapshot {
    coin: string;
    time: number;
    bids: L4Order[];
    asks: L4Order[];
}

interface L4BookDiff {
    coin: string;
    time: number;
    action: 'add' | 'remove' | 'modify';
    side: 'bid' | 'ask';
    order: L4Order;
}

class L4BookManager {
    private snapshots: Map<string, L4BookSnapshot> = new Map();
    private diffs: Map<string, L4BookDiff[]> = new Map();
    private subscribers: Map<string, Set<WebSocket>> = new Map();
    
    subscribe(coin: string, ws: WebSocket): void {
        if (!this.subscribers.has(coin)) {
            this.subscribers.set(coin, new Set());
        }
        this.subscribers.get(coin)!.add(ws);
        
        // Send initial snapshot
        const snapshot = this.snapshots.get(coin);
        if (snapshot) {
            ws.send(JSON.stringify({
                channel: 'l4Book',
                type: 'snapshot',
                data: snapshot
            }));
        }
    }
    
    processUpdate(coin: string, diff: L4BookDiff): void {
        // Store diff
        if (!this.diffs.has(coin)) {
            this.diffs.set(coin, []);
        }
        this.diffs.get(coin)!.push(diff);
        
        // Broadcast to subscribers
        const subscribers = this.subscribers.get(coin);
        if (subscribers) {
            const message = JSON.stringify({
                channel: 'l4Book',
                type: 'diff',
                data: diff
            });
            
            subscribers.forEach(ws => {
                if (ws.readyState === WebSocket.OPEN) {
                    ws.send(message);
                }
            });
        }
    }
}

A.2 Event Sourcing Implementation

interface OrderEvent {
    eventId: string;
    sequenceNumber: bigint;
    timestamp: bigint;
    blockNumber?: bigint;
    type: 'OrderPlaced' | 'OrderCanceled' | 'OrderMatched' | 'OrderModified';
    payload: any;
}

class EventStore {
    private events: OrderEvent[] = [];
    private snapshots: Map<bigint, OrderBookState> = new Map();
    private currentSequence: bigint = 0n;
    
    async append(event: Omit<OrderEvent, 'sequenceNumber'>): Promise<void> {
        const sequencedEvent: OrderEvent = {
            ...event,
            sequenceNumber: ++this.currentSequence
        };
        
        this.events.push(sequencedEvent);
        
        // Persist to disk/database
        await this.persist(sequencedEvent);
        
        // Create snapshot every 10000 events
        if (this.currentSequence % 10000n === 0n) {
            await this.createSnapshot();
        }
    }
    
    async replay(from: bigint = 0n): Promise<OrderEvent[]> {
        // Find nearest snapshot
        let snapshotSeq = 0n;
        for (const seq of Array.from(this.snapshots.keys()).sort()) {
            if (seq <= from) {
                snapshotSeq = seq;
            }
        }
        
        // Load snapshot if available
        if (snapshotSeq > 0n) {
            await this.loadSnapshot(snapshotSeq);
        }
        
        // Replay events from snapshot
        return this.events.filter(e => e.sequenceNumber > snapshotSeq);
    }
    
    private async persist(event: OrderEvent): Promise<void> {
        // Write to append-only log
        // Implementation depends on storage backend
    }
    
    private async createSnapshot(): Promise<void> {
        // Serialize current state
        // Store with sequence number
    }
    
    private async loadSnapshot(sequenceNumber: bigint): Promise<void> {
        // Load and restore state
    }
}

A.3 High-Performance Order Pool

class OrderPool {
    private available: Order[] = [];
    private allocated: Set<Order> = new Set();
    private readonly maxSize: number = 10000;
    
    constructor() {
        // Pre-allocate orders
        for (let i = 0; i < this.maxSize; i++) {
            this.available.push(new Order());
        }
    }
    
    acquire(): Order {
        let order = this.available.pop();
        if (!order) {
            // Pool exhausted, create new
            console.warn('Order pool exhausted, creating new order');
            order = new Order();
        }
        
        this.allocated.add(order);
        order.reset(); // Clear previous data
        return order;
    }
    
    release(order: Order): void {
        if (!this.allocated.has(order)) {
            console.error('Attempting to release unallocated order');
            return;
        }
        
        this.allocated.delete(order);
        
        if (this.available.length < this.maxSize) {
            this.available.push(order);
        }
    }
    
    get stats() {
        return {
            available: this.available.length,
            allocated: this.allocated.size,
            total: this.available.length + this.allocated.size
        };
    }
}

Appendix B: Performance Benchmarks

B.1 Benchmark Suite

import { performance } from 'perf_hooks';

class BenchmarkSuite {
    async runOrderBookBenchmark(): Promise<BenchmarkResult> {
        const book = new OrderBook();
        const results: number[] = [];
        
        // Warm up
        for (let i = 0; i < 1000; i++) {
            book.addOrder(this.generateOrder());
        }
        
        // Benchmark
        for (let i = 0; i < 100000; i++) {
            const start = performance.now();
            book.addOrder(this.generateOrder());
            const end = performance.now();
            results.push(end - start);
        }
        
        return {
            mean: this.mean(results),
            median: this.median(results),
            p95: this.percentile(results, 95),
            p99: this.percentile(results, 99),
            throughput: 1000 / this.mean(results)
        };
    }
    
    private mean(values: number[]): number {
        return values.reduce((a, b) => a + b) / values.length;
    }
    
    private median(values: number[]): number {
        const sorted = [...values].sort((a, b) => a - b);
        return sorted[Math.floor(sorted.length / 2)];
    }
    
    private percentile(values: number[], p: number): number {
        const sorted = [...values].sort((a, b) => a - b);
        const index = Math.ceil((p / 100) * sorted.length) - 1;
        return sorted[index];
    }
}

Appendix C: Deployment Configuration

C.1 Docker Configuration

# Dockerfile
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .

# Enable corepack for better package management
RUN corepack enable

# Run with optimized V8 flags
CMD ["node", "--max-old-space-size=4096", "--optimize-for-size", "dist/index.js"]

C.2 Kubernetes Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ts-trading-engine
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ts-trading-engine
  template:
    metadata:
      labels:
        app: ts-trading-engine
    spec:
      containers:
      - name: engine
        image: trading-engine:latest
        resources:
          requests:
            memory: "2Gi"
            cpu: "1000m"
          limits:
            memory: "4Gi"
            cpu: "2000m"
        env:
        - name: NODE_ENV
          value: "production"
        - name: ENGINE_MODE
          value: "l4book"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5

---

Document Version: 1.0 Last Updated: 2024 Next Review: After Phase 1 Implementation

This comprehensive study provides the technical foundation for achieving feature parity between our TypeScript engine and both Hyperliquid's production system and our Go/C++ implementations. The roadmap prioritizes critical features while maintaining a path to production readiness.