Dual Block Architecture

GX EVM uses a dual-block system that produces two types of blocks at different intervals. This design balances low-latency execution with high-throughput batch processing.

Overview

Both block types are part of the same canonical chain. They share sequential block numbers and a unified state tree.

Fast Blocks

Fast blocks are produced every second and have a 2M gas limit. They are designed for transactions that benefit from low confirmation latency.

Characteristics

• 1-second block time — transactions confirm within 1-2 seconds
• 2,000,000 gas limit — sufficient for most individual transactions
• Priority-fee ordered — transactions are ordered by gas price within the block
• Ideal for: token transfers, simple contract calls, oracle price updates, DEX swaps

Gas Pricing

Fast blocks use a standard EIP-1559 fee model:

Slow Blocks

Slow blocks are produced every minute and have a 30M gas limit. They are designed for transactions that require more gas or can tolerate higher latency.

Characteristics

• 1-minute block time — transactions confirm within 60-120 seconds
• 30,000,000 gas limit — supports complex contract deployments and batch operations
• Lower gas price — slow blocks have lower base fees due to the larger gas budget
• Ideal for: contract deployments, large batch transfers, complex DeFi operations

Transaction Routing

Transactions are automatically routed to the appropriate block type based on gas requirements:

You can explicitly request a slow block by including a specific gas price hint (documented in the RPC section).

Block Numbering

Fast and slow blocks share a unified block number sequence:

Block 1000 (fast, t=0s)
Block 1001 (fast, t=1s)
Block 1002 (fast, t=2s)
...
Block 1059 (fast, t=59s)
Block 1060 (slow, t=60s)   <-- slow block with 30M gas
Block 1061 (fast, t=61s)
...

Every 60th block is a slow block. The remaining blocks are fast blocks.

State Consistency

Both block types operate on the same state tree. A transaction in a fast block can read state written by a previous slow block and vice versa. There is no state fragmentation between block types.

Implications for Developers

Contract Deployment

Most contract deployments require more than 2M gas and will be routed to slow blocks. Expect deployment transactions to confirm within 1-2 minutes.

// Deployment will automatically route to a slow block if gas > 2M
const factory = new ethers.ContractFactory(abi, bytecode, wallet);
const contract = await factory.deploy();
await contract.waitForDeployment(); // May take up to ~2 minutes

Time-Sensitive Operations

For latency-critical operations (e.g., arbitrage, liquidation bots), ensure your transactions fit within the 2M fast-block gas limit. Optimize contract code to minimize gas consumption.

Block Confirmations

For most applications, 1 block confirmation is sufficient on GX Chain. The L1 consensus provides immediate finality — there are no reorgs or uncle blocks.

// No need to wait for multiple confirmations
const tx = await contract.someFunction();
const receipt = await tx.wait(1); // 1 confirmation is final

Querying Block Type

Use eth_getBlockByNumber to inspect a block. The gas limit field indicates the block type:

const block = await provider.getBlock("latest");
const isFastBlock = block.gasLimit <= 2_000_000n;
const isSlowBlock = block.gasLimit > 2_000_000n;