Troubleshooting Transactions

This guide walks through the common reasons Base transactions stall, fail, or revert, and explains how to fix each one.

Pending transactions

If a transaction is sitting in the mempool longer than expected, work through the following.

maxFeePerGas too low

If your maxFeePerGas is below the current base fee, the transaction stays pending until the base fee drops below your value.

Fix: maxFeePerGas must cover both the base fee and the priority fee. Because the base fee can move between blocks, set maxFeePerGas high enough to remain valid even if the base fee climbs while the transaction is queued. A common formula:

maxFeePerGas = baseFee * 2 + maxPriorityFeePerGas

This pattern (used by ethers.js) provides headroom for the base fee to double before the transaction becomes uneconomical. You only pay the actual base fee at inclusion, not the maximum.

Note

Base enforces a minimum base fee. Transactions with maxFeePerGas below that floor will never be included.

Priority fee too low

When the network is busy, transactions compete for inclusion via priority fees. Submitting a low priority fee against active demand delays inclusion.

Fix: Most users wait for congestion to ease. For time-sensitive transactions, query eth_maxPriorityFeePerGas for an estimate that should outbid recent transactions.

Note

When DA throttling is active, no RPC accounts for it when estimating priority fees. Even high-fee transactions may be delayed while the sequencer caps L2 throughput to manage L1 data availability.

Nonce gap

A pending transaction at nonce N blocks every transaction at nonce N+1 or higher, regardless of fees.

Fix: Wait for the pending transaction, or replace it by submitting a new transaction with the same nonce and a fee bump of at least 10% on both maxPriorityFeePerGas and maxFeePerGas.

Nonce too low

Submitting a transaction with a nonce that has already been used results in a rejection.

Fix: Query the next available nonce with eth_getTransactionCount and the pending tag.

Rejected transactions

Gas limit exceeds the maximum

Base enforces a per-transaction gas maximum of 25,000,000 gas. Higher limits are rejected by the mempool before inclusion.

Error: exceeds maximum per-transaction gas limit

Fix: Reduce the gas limit to 25,000,000 or lower. If the transaction genuinely needs more gas, split it into multiple transactions.

Included but failed transactions

Out of gas

The transaction exhausted its gas during execution.

Fix: Increase the gas limit. Estimate with eth_estimateGas and add a safety margin (for example, 20%) to absorb variability.

Reverted by contract

Contract logic triggered a revert.

Fix: Inspect the transaction on Basescan to find the revert reason. Common causes include failed require checks, arithmetic errors, and invalid state transitions.

Slow confirmations

Confirmation tiers

Base produces an L2 block every 2 seconds, while Flashblocks emit preconfirmations every 200ms.

Confirmation level	Time	Description
Flashblock preconfirmation	~200ms	Transaction included in a preconfirmation
L2 block inclusion	~2s	Transaction included in a sealed L2 block
L1 batch inclusion	~2m	Transaction posted to Ethereum
L1 finality	~20m	Ethereum batch is finalized

See Transaction Finality for the full breakdown.

Use a Flashblocks-aware endpoint

For the fastest possible confirmation, point your client at the Flashblocks RPC endpoint:

Network	Flashblocks RPC
Mainnet	https://mainnet-preconf.base.org
Sepolia	https://sepolia-preconf.base.org

These endpoints return receipts as soon as the transaction lands in a Flashblock instead of waiting for the full L2 block.

Debugging tools

• Basescan — Inspect status, logs, and revert reasons
• Tenderly — Simulate and debug transactions
• eth_call — Test contract calls without submitting a transaction
• eth_estimateGas — Estimate gas usage before submitting

Getting help

If you are still stuck, ask in the #developer-chat channel on the Base Discord.