GXCore

GXCore is the native Rust matching engine and execution environment within GX Chain. It handles all performance-critical operations — order matching, perpetual futures settlement, spot trading, RWA perpetuals, prediction markets, risk management, liquidations, and oracle price aggregation — outside of any virtual machine.

Why Native Execution?

Traditional decentralized exchanges run as smart contracts inside an EVM or WASM runtime. Every operation pays the overhead of virtual machine interpretation, gas metering, and storage abstraction. GXCore eliminates this overhead entirely by executing exchange logic as native compiled Rust code within the validator binary.

This design choice delivers:

Sub-microsecond single-match latency — Orders are matched in native memory, not through VM opcodes
Industry-leading throughput — GXCore matching engine benchmarked on production-equivalent hardware
Deterministic execution — Every validator produces identical state transitions for the same input
Zero gas costs for trading — Trading operations are not metered by EVM gas; only EVM contract interactions consume gas

Components

Component	Description	Documentation
Matching Engine	Price-time priority order book with BTreeMap structure	Order Book
Perps Clearinghouse	Perpetual futures margin, funding, and settlement	Clearinghouse
Oracle	Weighted median of 8 CEX price feeds	Oracle
Bridge	GXVault on Arbitrum, multi-validator quorum	Bridge
API Servers	REST, WebSocket, EVM JSON-RPC	API Servers
Staking	Fee-sharing staking with 7-day cooldown	Staking
Multi-Sig	Native L1 multi-signature wallets	Multi-Sig
Lending	Algorithmic interest rate lending	Lending and Borrowing
Vaults	Protocol vaults and AI trading vaults	Vaults

Architecture

GXCore runs inside a single Rust binary alongside the consensus layer and GX EVM (EVM-compatible runtime). The execution flow for a trade is:

User signs EIP-712 order
       |
Validator receives order via REST API (port 4001)
       |
Order enters semantic mempool (priority-sorted)
       |
Block producer batches orders into a block proposal
       |
GX BFT consensus finalizes the block (near-instant finality)
       |
GXCore applies the block:
  - Match orders against the order book
  - Update positions and margin
  - Apply funding rate payments
  - Check liquidation thresholds
  - Persist state to RocksDB
  - Index fills/candles to PostgreSQL
       |
WebSocket (port 4000) broadcasts updates to subscribers

State Management

Layer	Technology	Purpose
Hot state	In-memory (Rust `HashMap`/`BTreeMap`)	Active order books, account balances, positions
Persistent state	RocksDB	Block-level state snapshots, recovery after restart
Historical data	PostgreSQL	Fill history, candle aggregation, block metadata

All state transitions are deterministic. Given the same genesis state and the same sequence of blocks, every validator produces byte-identical state.

Performance Benchmarks

Operation	Latency	Throughput
Single order match	Sub-microsecond	Millions of operations/sec
Place resting order	Sub-microsecond	Millions of operations/sec
Cancel order	Sub-microsecond	Millions of operations/sec
Batch 1,000 orders	Sub-millisecond	Millions of operations/sec
Realistic mixed workload (10K ops)	Sub-millisecond	Industry-leading throughput
End-to-end with auth (EIP-712)	—	Industry-leading throughput