Manta network
Manta network gas fees can diverge from wallet estimates when transaction inputs, RPC state, or cost coverage differ
Manta network gas fees differ from an earlier estimate when the submitted transaction no longer matches the simulated call, the RPC serves different state, or the interface counts only part of Manta Pacific's Layer 2 cost. Compare the same sender, destination, value, calldata, block state, and fee fields before resubmitting.
Last updatedInputs behind an estimate gap
A fee gap usually comes from unequal transaction inputs, unequal chain state, or unequal cost coverage. A changing gas price is only one possibility, and often isn't the first one worth testing.
The sender affects balance checks, allowance ownership, contract permissions, and the nonce used at submission. Leaving
from
out of a simulation can therefore exercise a different path. A changed
to
address or
value
field can also turn a valid estimate into a revert.
Calldata selects the contract function and supplies its encoded arguments. Changing an amount, recipient, deadline, or execution bound can alter both the contract path and the serialized transaction. Even a freshly generated request isn't comparable with an older estimate unless those bytes still match.
Manta Pacific mainnet identifies itself with
chain ID 169.
A wallet label alone doesn't establish this identity. Confirm the RPC's
eth_chainId
response before comparing balances, contract state, or gas values, since another EVM network can hold unrelated state at the same address.
Separate execution units from data costs
One gas number may describe EVM execution units while another describes the transaction's monetary total. Comparing them directly creates an apparent gap even when both values are internally correct.
Read the estimate as two components
Execution on Manta Pacific
eth_estimateGas
returns the estimated gas units needed for the call to complete. The execution charge depends on the units actually used and the effective price per unit. A wallet may add a gas-limit buffer, so its limit can exceed the receipt's eventual
gasUsed
value.
Data carried outside the execution meter
Manta Pacific gas tooling can expose total, L1, and L2 cost estimates for the same unsigned transaction. The additional component depends on the serialized transaction, including its calldata. A generic EVM estimate may report execution units without presenting this data-related cost as part of the same number.
For diagnosis, record units and wei separately. Compare
gasUsed × effectiveGasPrice
with the execution portion, then add the reported L1 or data component where the estimator supplies one. Don't compare a maximum wallet authorization with a receipt's final charge as though they represent the same quantity.
A six-stage pass from symptom to receipt
This sequence preserves reversibility until signing. It also captures enough evidence to distinguish a stale quote, a contract revert, an incomplete cost estimate, and a different transaction object.
| Stage | Evidence to capture | Commitment boundary |
|---|---|---|
| 1. Record the symptom | Displayed estimate, error text, time, and whether a transaction hash appeared | Observation only; don't retry yet |
| 2. Freeze the request |
from,
to,
value,
data, type, and fee fields
|
Keep private keys and seed phrases out of the record |
| 3. Confirm the chain |
eth_chainId
should return
0xa9
for Manta Pacific mainnet. This is chain ID 169 in hexadecimal; also record the block number
|
Read-only RPC calls require no signature |
| 4. Replay the call |
Run
eth_call
and
eth_estimateGas
with the same object and block tag
|
Simulation doesn't broadcast the transaction |
| 5. Split the cost | Compare execution units with total, L1, and L2 estimates for the same serialized request | Keep the comparison unsigned |
| 6. Commit and verify | Refresh state, sign once, submit, and inspect the receipt's status and gas fields | Broadcast is the state-changing boundary |
| Summary | Proceed only when chain identity, state, request bytes, and cost coverage agree | Sign after the reversible checks pass |
A mismatch found in stages two through five should change the next check, not trigger an automatic resubmission. Once a receipt exists, its status and recorded fee fields replace the earlier prediction as evidence of what executed.
Why does eth_estimateGas return an error?
The method returns an error when the supplied call can't complete under the node's simulated state. That failure often reveals a contract condition rather than a shortage of gas units.
The eth_estimateGas method estimates execution without adding the transaction to the blockchain. It still evaluates the specified sender, value, calldata, and current contract storage. A failed permission check, expired bound, missing allowance, paused function, or invalid argument can stop the simulation.
Increasing the gas limit doesn't repair a logical revert. It helps only when execution genuinely runs out of gas. Preserve any revert data returned by the RPC, since a decoded reason or custom-error selector can identify the contract condition the call failed to satisfy.
Replay the identical object with
eth_call
at the same block tag. If both methods fail, inspect the contract prerequisite and sender state before changing fee fields. If only one fails, retain both raw responses and compare another current Manta Pacific endpoint before signing.
Keep the transaction envelope identical
A comparison is valid only when both tools receive the same transaction object. Match the sender, destination, native value, calldata, transaction type, and applicable fee fields. For a type-2 transaction, distinguish
maxFeePerGas
from
maxPriorityFeePerGas.
For an ABI-encoded function call, the first four calldata bytes are the function selector, while the remaining bytes encode its arguments. Regenerating a quote can silently change a deadline, amount bound, recipient, or route data. Compare the full calldata rather than relying on an interface's action label.
An approval and the later contract action are separate transactions. They call different functions, change different storage, and consume separate fees. Don't compare an approval estimate with the action's receipt, even when the interface presents both steps as one workflow.
Finally, distinguish the gas limit from gas used. A buffered limit protects against modest execution variation, but it isn't a prediction that every allowed unit will be consumed. The receipt provides the measured execution amount after inclusion.
RPC state can move after a clean estimate
An estimate can become stale as soon as the state it read changes. Record the block number or block tag with the request, especially when the contract depends on balances, allowances, storage values, deadlines, or other transactions.
Stale endpoint clues
A lagging endpoint may return an older block, balance, nonce, or contract state. Compare
eth_blockNumber
and the relevant reads through another Manta Pacific endpoint. A one-block difference isn't proof of failure, but persistent lag explains why two otherwise identical simulations disagree.
State-race clues
Another included transaction can change the condition your call expects. A contract quote may expire, available output may move, or an allowance may be consumed before inclusion. Refresh the exact unsigned request near signing, and stop when the updated simulation no longer satisfies its encoded bounds.
Bounded recovery after a failed estimate
Recovery should isolate one dependency per retry and keep every step read-only until the cause is known. Changing the RPC, sender, calldata, gas limit, and fee fields together destroys the comparison needed to identify the fault.
A wrong chain response calls for correcting the endpoint. A sender mismatch calls for a new estimate with the intended account. A contract revert calls for repairing its named prerequisite or encoded argument. An execution-only quote calls for a Layer 2-aware total-cost method, not a larger arbitrary gas limit.
Keep signing material outside every diagnostic record. An RPC request can reveal the account, destination, value, and calldata it receives, but it never needs a seed phrase or private key. Build and inspect the unsigned request first, then sign locally only after its fields and cost coverage agree.
Stop repeated submission when the same deterministic revert survives a fresh state read. Preserve the request, block number, RPC error, and any decoded revert data for the application operator. Repeatedly raising the gas limit can spend more on failed attempts without changing the rejected contract condition.
Verification before one final submission
Before signing, confirm the RPC reports chain ID 169, the sender holds enough ETH on Manta Pacific, the destination and calldata match the successful simulation, and the total includes every reported fee component. After broadcast, inspect the receipt's status,
gasUsed, effective gas price, and any separate L1 or data fee field the receipt provides. Treat a missing hash as uncertain submission status.
What readers ask about Manta network gas fees
Does MANTA pay transaction fees on Manta Pacific?
No. Manta Pacific uses ETH as its native gas asset, so holding MANTA doesn't by itself fund a transaction on that chain. The wallet needs enough ETH on Manta Pacific, not merely ETH on Ethereum or an ERC-20 balance. Check the native balance under chain ID 169 before attempting the call again.
Can an Ethereum mainnet gas quote price a Manta Pacific call?
No. An Ethereum mainnet quote reflects mainnet execution and its own fee conditions. Manta Pacific has separate state, execution pricing, and a Layer 2 total that can include a data-cost component. Use the Manta Pacific transaction object and RPC for the estimate. A mainnet quote may describe a separate bridge leg, but it can't replace the destination-chain estimate.
Are unused units in the gas limit charged?
No. The gas limit caps how many execution units the transaction may consume; the execution charge uses the amount actually consumed. A wallet may display a maximum based on the full limit, while the receipt records a lower gas-used value. Any separately calculated L1 or data component still belongs in the total, and a reverted included transaction still consumes the gas it used.
Why can an approval estimate differ from the later contract call?
An approval and the later action execute different contract methods. The approval writes an allowance, while the subsequent call follows its own logic and may call additional contracts. Their calldata, storage access, and execution work therefore differ. Estimate each transaction separately, and wait for a successful approval receipt before simulating the later action against the updated allowance.