Skip to main content
Base throughput is constrained by gas limits, data availability throughput, fee market parameters, and endpoint limits. There is no single transactions-per-second value that applies to every workload, because transactions consume different amounts of gas and data. Base has sustained multiple bursts of over 5,000 TPS, and throughput continues to increase as the chain scales. For more context, see Introducing Base Azul.

​
Current Limits

The full block gas budget is split across Flashblocks while the block is being built. Flashblock 1 can use 1/10 of the block gas limit, Flashblock 2 can use 2/10, and so on until Flashblock 10 has access to the full limit. See Transaction Ordering for how this affects transaction ordering.

​
Flashblock Performance

Flashblocks stream incremental block updates roughly every 200ms, giving apps sub-second preconfirmations within the standard 2-second block. See the Flashblocks Reference for reorg handling and other common questions.

​
Per-Transaction Gas Maximum

As of the Azul hardfork, Base enforces a protocol-level per-transaction gas maximum of 16,777,216 gas (2^24) via EIP-7825. Transactions that specify a gas limit above this value are rejected during block validation. eth_sendTransaction or eth_sendRawTransaction will return a JSON-RPC error (for example: exceeds maximum per-transaction gas limit).
Deposit transactions are exempt from this cap. They are limited by the maximum gas includable in an L1 block (20,000,000 gas).
Bundler operators for smart contract wallets must configure their systems to limit the bundle size to fit within this cap.

​
Fee Parameters

Fees affect practical throughput because they determine whether transactions can be included when demand approaches available capacity. For current fee parameters, see Minimum Base Fee and EIP-1559 Fee Parameters on the Network Fees page.

​
Data Availability Throughput

Base transaction data is posted to Ethereum for data availability. If data availability throughput becomes constrained, the sequencer can limit L2 transaction throughput while the batcher catches up. During DA throttling, even transactions with high priority fees may be delayed. There is no RPC endpoint that calculates priority fee estimates with throttling in mind. See Troubleshooting Transactions for the transaction-submission implications.

​
Endpoint Limits

Public endpoints are rate-limited and are not suitable for production traffic. Hosted RPC providers can also apply request-per-second limits, compute-unit limits, method restrictions, archive-data limits, or WebSocket subscription limits. Endpoint limits do not change Base protocol capacity, but they can become the practical bottleneck for apps, wallets, indexers, and monitoring systems. For production use, choose an RPC provider from the Builder Stack or run a Base node.