Troubleshooting Transactions

Guide to diagnosing and resolving transaction issues on Base.

Transaction Not Being Included

If your transaction is pending for longer than expected, check the following:

Max Fee Too Low

If your maxFeePerGas is lower than the current base fee, your transaction will remain pending until the base fee drops to your specified level.

Solution: The maxFeePerGas must cover both the base fee and your priority fee. Since the base fee can change with each block, set maxFeePerGas high enough to remain valid even if the base fee rises while your transaction is pending. A common approach is:

maxFeePerGas = baseFee * 2 + maxPriorityFeePerGas

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

Base has a minimum base fee. Transactions with maxFeePerGas below this value will never be included, since the base fee cannot drop below the minimum.

Priority Fee Too Low

During periods of high demand, transactions compete for block space through priority fees. If your priority fee is too low relative to other transactions, yours may be delayed.

Solution: Most users simply wait for congestion to subside. For time-sensitive transactions, use eth_maxPriorityFeePerGas to get a priority fee estimate that can outbid enough recent transactions to be included.

If DA throttling is currently in effect, there’s no RPC endpoint that calculates priority fee estimates with throttling in mind. During DA throttling, even transactions with high priority fees may be delayed as the sequencer limits L2 transactions to manage its L1 data availability throughput.

Nonce Gap

If you have a pending transaction with nonce N, all transactions with nonce N+1 or higher will queue behind it, regardless of their fees.

Solution: Either wait for the pending transaction to be included, or replace it by submitting a new transaction with the same nonce and a higher fee (at least 10% higher maxPriorityFeePerGas and maxFeePerGas).

Nonce Too Low

If you submit a transaction with a nonce that has already been used, it will be rejected.

Solution: Query your current nonce using eth_getTransactionCount with the pending tag to get the next available nonce.

Transaction Rejected

Gas Limit Exceeds Maximum

Base enforces a per-transaction gas maximum. The active cap is network- and activation-dependent: Base Sepolia uses 16,777,216 gas, while Base Mainnet uses 25,000,000 gas until Azul activates on May 21, 2026 at 18:00 UTC and 16,777,216 gas after activation. Transactions specifying a higher gas limit are rejected by the mempool before inclusion.

Error: exceeds maximum per-transaction gas limit

Solution: Reduce the gas limit to the active per-transaction cap for the network. If your transaction genuinely requires more gas, you’ll need to break it into multiple transactions.

Transaction Included But Failed

If your transaction was included in a block but shows a failed status:

Out of Gas

The transaction ran out of gas during execution.

Solution: Increase the gas limit. Use eth_estimateGas to get a gas estimate, then add a buffer (e.g., 20%) to account for variability.

Reverted by Contract

The contract execution encountered a revert condition.

Solution: Check the transaction on Basescan to see the revert reason. Common causes include failed require statements, arithmetic errors, or invalid state transitions.

Slow Confirmation

Understanding Confirmation Times

First identify which confirmation stage your app or wallet is waiting for. The canonical lifecycle and timing from Flashblock preconfirmation through L1 finality is documented in Transaction Finality.

Using Flashblocks for Faster Confirmations

To get the fastest possible confirmation, use a Flashblocks-aware RPC endpoint:

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

These endpoints return transaction receipts as soon as a transaction is included in a Flashblock, rather than waiting for the full L2 block.

If a transaction appears on a Flashblocks-aware endpoint but not yet on a standard RPC endpoint, continue polling the standard endpoint before treating it as a regular L2 block inclusion. If neither endpoint returns a receipt, continue with the fee, nonce, and gas-limit checks above.

Debugging Tools

• Basescan: View transaction 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’re still experiencing issues, reach out in the #developer-chat channel in the Base Discord.