Small EVM Block is one of two execution block types in Hyperliquid's HyperEVM environment. Produced at high frequency (currently approximately every second), small EVM blocks are designed for regular transactions and lightweight smart contract interactions. This block type enables responsive user experiences for standard DeFi operations while the larger, less frequent Large EVM Blocks handle heavier computational loads.

Hyperliquid's Block Architecture

Hyperliquid has a single L1 block sequence finalized by HyperBFT. All HyperCore financial state transitions are anchored to this L1 block stream. On top of this timeline, HyperEVM execution is scheduled using two types of blocks:

• Small EVM Blocks: ~1 second cadence, lightweight operations
• Large EVM Blocks: ~1 minute cadence, heavy operations

This design decouples block speed from block size for EVM execution while maintaining a single, coherent L1 state and consensus.

When Small EVM Blocks Are Produced

Not every L1 block produces an EVM block. The system schedules small EVM blocks at regular intervals (currently ~1s) to process pending HyperEVM transactions. When a small EVM block is produced, it is derived from and finalized under the same L1 block ordering and consensus that governs HyperCore.

What Belongs in Small EVM Blocks

Small EVM blocks are optimized for:

Token Transfers: Standard ERC-20 transfers and approvals execute quickly in small blocks.

Simple Contract Calls: Functions with moderate gas usage—swaps, deposits, withdrawals, claims—fit naturally in small blocks.

Read-Heavy Operations: Contracts that primarily read state and perform minimal computation benefit from the frequent block production.

Time-Sensitive Operations: Applications requiring responsive user experience (within ~1 second) should design for small block execution.

What Does NOT Belong in Small EVM Blocks

Certain operations are routed to Large EVM Blocks instead:

• Contract deployments
• Complex initialization logic
• Operations exceeding small block gas limits
• Batch operations processing many state changes

Attempting to execute heavy operations in small blocks may result in transactions being delayed or failing.

Execution Ordering with HyperCore

The relationship between HyperCore and HyperEVM block production follows strict ordering:

1. L1 block N is finalized by HyperBFT
2. HyperCore processes all financial operations for block N
3. Financial state becomes final and deterministic
4. If a small EVM block is scheduled, it executes with visibility into finalized HyperCore state
5. EVM state changes are committed under the same consensus

This guarantees that smart contracts always observe finalized financial state—there's no race condition where a contract sees a trade before it's final.

Gas Considerations

Small EVM blocks have gas limits appropriate for their intended use case. Developers should:

Optimize for Small Blocks: Design frequently-called functions to fit within small block gas limits.

Batch Appropriately: If an operation requires significant gas, consider whether it should be split or designed for large block execution.

Test Gas Usage: Use standard EVM tools (Foundry, Hardhat) to measure gas consumption and ensure critical paths fit in small blocks.

Timing Implications for Developers

The ~1 second cadence of small EVM blocks means:

Response Time: Users can expect transaction confirmation within ~1-2 seconds for standard operations.

State Freshness: Contract state updates propagate quickly, enabling responsive DApp experiences.

Block Inclusion: Transactions submitted during a block period are included in the next small block (assuming gas price is sufficient).

Cross-Engine Timing: When reading HyperCore state, you're seeing the most recent finalized state, updated at L1 block frequency.

Comparison with Large EVM Blocks

Security Considerations

Gas Griefing: Malicious contracts could attempt to consume all small block gas, delaying legitimate transactions. Gas pricing and limits provide natural rate limiting.

Timing Attacks: The predictable ~1s cadence could theoretically enable timing-based strategies. However, HyperCore execution order is consensus-determined, limiting MEV opportunities.

Front-Running: Unlike HyperCore (which doesn't compete for gas), small EVM blocks use gas-based prioritization. Standard EVM front-running vectors apply.

Best Practices

1. Design for small blocks: Keep frequently-called functions lightweight
2. Handle failures gracefully: If gas limits are exceeded, transactions will revert
3. Consider batching: For multiple operations, evaluate small block series vs. single large block
4. Test thoroughly: Verify gas usage under realistic conditions
5. Monitor block inclusion: Track whether transactions land in expected blocks

Understanding small EVM blocks helps developers design applications that leverage Hyperliquid's responsive execution while respecting the system's resource constraints.