Interaction Timings

This page documents the latency characteristics of interactions between GX Core, GX EVM, and external chains. Understanding these timings is essential for building reliable integrations.

Internal Latencies

GX Core Operations

Operation	Latency	Description
Order placement	< 1 ms	Matching engine processing time
Order cancellation	< 1 ms	Immediate removal from orderbook
USD transfer	< 2 s	Processed in the next Core block
Leverage update	< 2 s	Processed in the next Core block
Agent approval	< 2 s	Processed in the next Core block

GX EVM Operations

Operation	Latency	Description
Fast block transaction	1-2 s	Confirmed in the next fast block
Slow block transaction	60-120 s	Confirmed in the next slow block
Contract deployment	60-120 s	Typically requires a slow block
Event log emission	Same as block confirmation	Logs are available when the block is mined

Cross-Layer Operations

Operation	Direction	Latency	Notes
Core to EVM transfer	Core -> EVM	1-2 s	Credited after next Core block
EVM to Core transfer	EVM -> Core	2-5 s	EVM block finality + next Core block
Precompile read	EVM -> Core	0 ms (view call)	Reads finalized Core state
Bridge deposit	External -> Core	1-5 min	Depends on source chain finality
Bridge withdrawal	Core -> External	5-30 min	Depends on destination chain

Block Production Timeline

Time    Event
────────────────────────────────────
t=0.0s  Fast block #N produced
t=0.0s  Core block processes: orders matched, transfers settled
t=1.0s  Fast block #N+1 produced
t=1.0s  EVM transactions from #N are finalized
...
t=59.0s Fast block #N+59 produced
t=60.0s Slow block #N+60 produced (30M gas limit)
t=60.0s Heavy EVM transactions confirmed
t=61.0s Fast block #N+61 produced

Precompile Data Freshness

When an EVM contract reads data from GX Core via a precompile, it accesses the state as of the last finalized Core block:

Data Type	Freshness	Update Frequency
Oracle prices	1-2 seconds stale	Updated every Core block
User positions	1-2 seconds stale	Updated on every fill/liquidation
Account values	1-2 seconds stale	Recalculated each Core block
Market metadata	Effectively static	Changes only on market listings

For time-critical decisions (e.g., liquidation), account for this staleness window. An oracle price read from EVM may be up to 2 seconds behind the real-time price used by the matching engine.

Optimizing Cross-Layer Interactions

Minimize Round Trips

If your application needs both EVM execution and Core trading:

Batch EVM operations into a single transaction where possible.
Use precompile reads within the same transaction to avoid separate RPC calls.
Pre-position assets in the correct layer before they are needed.

Event-Driven Architecture

For workflows that span both layers:

EVM Contract emits event
    -> Off-chain service detects event via WebSocket/polling
    -> Service calls GX Core API to place orders
    -> Service monitors fills via WebSocket
    -> Service calls EVM contract to settle

This pattern avoids the latency of cross-layer transfers during the critical path.

Asset Pre-Positioning

If your strategy requires rapid asset movement:

Keep a reserve balance in both GX Core and GX EVM.
Rebalance periodically during low-activity periods.
Avoid transferring assets in the critical path of a trade.

Confirmation Guarantees

Layer	Finality Model	Reorg Risk
GX Core	Immediate finality	None
GX EVM	Immediate finality (same consensus)	None
Bridge (source chain)	Depends on source chain	Wait for required confirmations

GX Chain provides immediate finality for both Core and EVM operations. Once a block is produced, it is final. There are no reorgs, uncle blocks, or chain reorganizations.

Timing Diagram: Full Cross-Layer Trade

t=0ms     User submits order via Core API
t=<1ms    Order matched by engine
t=0-2s    Fill confirmed in Core block
t=0-2s    User receives fill via WebSocket
t=2-4s    On-chain settlement (if EVM integration required)

Total end-to-end: under 5 seconds for a complete trade with EVM settlement.

GX Core <> GX EVM Transfers Wrapped GX