An Ethereum transaction whose maxFeePerGas is below a block's base fee cannot be included in that block. Increasing the gas limit does not fix this price-per-unit mismatch. First check whether the wallet's attempt was rejected before broadcast or remains pending, then compare its signed fee cap with a fresh base-fee reading for the same network. A suitable fee cap is necessary for inclusion, but it is not a promise of immediate confirmation.
Read the error as a comparison between two prices
The relevant comparison is maxFeePerGas versus baseFeePerGas. Both are prices per unit of gas, commonly displayed in gwei. The gas limit instead describes the maximum quantity of gas the transaction may use. Raising that quantity leaves the per-unit cap unchanged and may increase the maximum balance requirement. The general Ethereum gas guide explains the units if your wallet shows several similar-looking fields.
The inclusion rule appears in EIP-1559. Geth also checks the fee cap against the block base fee in its state-transition implementation. This is not a message that the receiving address needs activation or that the token contract requires a larger transfer. Preserve the actual error text before changing anything: a different gas-related error can require a different diagnosis.
Use a fee worksheet before editing the transaction
| Illustrative case | Base fee | Maximum fee | Maximum tip | Interpretation |
|---|---|---|---|---|
| A: cap below floor | 20 gwei | 18 gwei | 2 gwei | Not eligible for this block regardless of the proposed tip |
| B: little room for tip | 20 gwei | 21 gwei | 3 gwei | Effective tip is capped at 1 gwei |
| C: cap has headroom | 20 gwei | 30 gwei | 2 gwei | Effective price would be 22 gwei under these assumptions |
| D: inconsistent caps | 20 gwei | 21 gwei | 25 gwei | Maximum tip exceeds maximum fee; fields are inconsistent |
These are fictional values, not current network estimates or recommended settings. For a valid ordinary EIP-1559 transaction, the effective price per gas is the base fee plus the smaller of the maximum tip and the remaining space under the maximum fee. In case B that space is 21 minus 20, so the effective tip is 1 rather than the requested ceiling of 3. A priority-fee setting cannot independently override the total per-gas cap.
If case C used 50,000 gas, its execution charge under those assumptions would be 50,000 times 22 gwei, or 0.0011 ETH. That is a worked calculation, not a claim that your transfer needs 50,000 gas. Do not substitute the configured gas limit for actual gas used when reconciling a completed transaction's cost. The maximum authorized cost and the final charge are different figures.
Determine whether there is an accepted transaction to manage
A wallet can surface this error while estimating, submitting or managing a previously pending attempt. Look for a transaction hash and inspect it on the appropriate explorer. Save the sender and nonce if the transaction exists. A rejected submission is not an included contract execution that reverted; do not assume a gas charge was incurred merely because the interface displayed a failure. Conversely, a local error does not prove that every earlier attempt is absent.
Check the sender's outgoing history as well as the single hash. Another attempt may already have used that nonce. Our Etherscan field guide helps locate the execution result, fee and actual movement. If the confirmed record already paid the recipient, resolve any stale wallet display rather than treating the old fee error as a reason to pay again.
Choose between waiting and a documented replacement
A pending transaction can become eligible if the base fee later falls below its cap, but there is no assured waiting time. It may also be dropped by a node or delayed by earlier outgoing nonces. Compare the payment deadline and the current transaction state before relying on that possibility. A quote or invoice expiring is a receiving-service issue, not a reason to assume the blockchain transaction has disappeared.
If you choose to update a pending attempt, use your wallet's documented replacement or speed-up controls. The signed fee fields of an existing transaction cannot be changed in place: an updated signed transaction is a different candidate. Replacement acceptance rules and supported controls depend on the wallet and node. Do not treat a generic percentage increase found online as a universal protocol guarantee.
- Confirm the network and retain the exact error message.
- Compare a recent base-fee reading with the attempt's maxFeePerGas in matching units.
- Check maxPriorityFeePerGas separately and leave the estimated execution quantity as a distinct field.
- Find whether an attempt is pending, already included or absent from the observed history.
- If managing a pending attempt, use the wallet's documented procedure and preserve its nonce relationship.
- After any change, verify the actual execution and recipient before retrying the payment.
Why a fresh estimate can still fail later
The base fee can change between preparation and inclusion. A transaction prepared during one set of conditions may no longer meet a later block's floor. An app can also retain an old estimate or apply the wrong chain's settings. Refresh through the trusted wallet or documented application flow; do not switch to an unknown RPC endpoint sent by a stranger simply because it promises lower fees.
For developers, log chain ID, timestamp, fee fields, nonce and the actual RPC response without logging private keys or signed secrets. Tatum's error documentation provides a concrete example of the cap mismatch. Its service-specific construction details do not automatically apply to another wallet. Keep submission rejection, mempool acceptance and included execution as separate states in the application's payment record.
Recheck the order only after the chain evidence is clear
For a no-account swap, compare the executed transfer with the current order instructions and contact official support about an expired or mismatched order. Raising a network fee does not change the receiving service's rules. A useful incident note contains the original error, network, attempted hashes and final result. That lets you resolve a fee-cap problem without turning it into an accidental duplicate payment.
FAQ
What does max fee per gas less than block base fee mean?
The transaction's per-unit ceiling is below the applicable base fee. It cannot be included in that block unless the relevant conditions change; a larger gas quantity does not fix that comparison.
How is max priority fee per gas different from the maximum fee?
The priority field caps the tip, while maxFeePerGas caps the combined price per unit. The tip can be constrained by the room remaining after the base fee.
Can Ethereum's base fee change while my transaction is pending?
Yes, the base fee changes with block conditions. A fixed signed cap can therefore be insufficient later, and waiting does not provide a guaranteed confirmation time.