Large EVM Block is one of two execution block types in Hyperliquid's HyperEVM environment. Produced at lower frequency (currently approximately every minute), large EVM blocks are designed for heavier transactions that exceed the gas limits of Small EVM Blocks—most notably contract deployments and complex initialization logic. This two-tier block structure allows Hyperliquid to maintain responsive execution for regular operations while accommodating computationally intensive tasks.

The Two-Block Architecture

Hyperliquid's L1 block sequence is finalized by HyperBFT, with HyperCore financial state transitions anchored to this stream. HyperEVM execution is then scheduled using:

• Small EVM Blocks: ~1 second cadence, gas-limited for regular operations
• Large EVM Blocks: ~1 minute cadence, higher gas limits for heavy operations

This design decouples block speed from block size, allowing the system to process lightweight transactions quickly while still supporting resource-intensive operations on a predictable schedule.

When Large EVM Blocks Are Produced

Large EVM blocks are produced at regular intervals (currently ~1 minute). Not every L1 block triggers a large EVM block—they're scheduled independently to batch heavy operations efficiently. When produced, large EVM blocks are derived from and finalized under the same L1 block ordering and consensus as all other Hyperliquid operations.

What Belongs in Large EVM Blocks

Large EVM blocks are designed for:

Contract Deployments: Deploying new smart contracts requires significant gas that exceeds small block limits. All deployments are routed to large blocks.

Complex Initialization: Setting up a new protocol with multiple storage writes, token distributions, or configuration parameters fits naturally in large blocks.

Batch Operations: Processing many state changes in a single transaction (airdrops, migrations, bulk updates) benefits from large block gas limits.

Heavy Computation: Operations with significant loop iterations, complex calculations, or deep call stacks that would fail in small blocks.

Timing Implications

The ~1 minute cadence means developers must design accordingly:

Deployment Latency: After submitting a contract deployment, expect up to ~1 minute before it's included in a large block and confirmed.

User Communication: DApps should clearly indicate when operations require large block execution and set appropriate expectations.

Sequencing: If your operation depends on a deployed contract, plan for the deployment delay before dependent transactions can execute.

Batching Strategy: Group related heavy operations to execute in the same large block rather than spreading across multiple blocks.

Execution Ordering

Large EVM blocks follow the same ordering guarantees as small blocks:

1. L1 block is finalized by HyperBFT
2. HyperCore processes all financial operations
3. Financial state becomes final and deterministic
4. Large EVM block executes with visibility into finalized HyperCore state
5. EVM state changes are committed under consensus

Smart contracts in large blocks always observe finalized HyperCore state—there's no race condition or stale data.

Gas Limits and Pricing

Large EVM blocks have higher gas limits than small blocks, enabling:

• Full contract deployments (often 1-5M+ gas)
• Complex multi-step transactions
• Batch operations with many storage writes

Gas pricing follows standard EVM mechanics—higher gas prices increase priority for block inclusion. However, since large blocks are less frequent, transactions may wait longer for inclusion regardless of gas price.

Comparison with Small EVM Blocks

Development Workflow

When deploying to HyperEVM:

1# Using Foundry
2forge create --rpc-url $HYPEREVM_RPC --private-key $KEY src/MyContract.sol:MyContract
3
4# Deployment will be included in next large EVM block (~1 min max)

Testing Considerations:

• Local testing won't reflect the small/large block distinction
• Integration tests should account for deployment timing
• Monitor mainnet behavior during initial deployments

Security Considerations

Deployment Frontrunning: The ~1 minute window between submission and execution could theoretically allow monitoring and competing deployments. Use CREATE2 for deterministic addresses if frontrunning is a concern.

Gas Estimation: Large block gas limits may differ from other EVM chains. Test deployments thoroughly and include gas buffers.

Initialization Timing: If deployment and initialization are separate transactions, ensure initialization can't be frontrun between blocks.

Upgrade Safety: Proxy upgrades execute in large blocks. Plan upgrade sequences accounting for the timing constraints.

Best Practices

1. Design for the delay: Build UX that clearly communicates large block timing
2. Batch deployments: Deploy related contracts together when possible
3. Use CREATE2: Deterministic addresses reduce deployment timing risks
4. Atomic initialization: Combine deployment and init in constructor when feasible
5. Monitor gas usage: Ensure operations fit within large block limits
6. Plan dependencies: Sequence operations accounting for small/large block timing

Why This Design?

Hyperliquid's two-tier block structure optimizes for the common case (fast, lightweight operations) while still supporting necessary heavy operations. Rather than forcing all transactions to compete in one block type, the system separates concerns:

• Small blocks: Maximize responsiveness for user interactions
• Large blocks: Provide adequate resources for infrastructure operations

This design reflects Hyperliquid's broader philosophy of purpose-built components—just as HyperCore and HyperEVM serve different roles, small and large blocks serve different operational needs within the EVM environment.