MantanetworkMantanetwork gas fees can be estimated before signing and traced through the receipt when a Manta Pacific transaction fails
Mantanetwork gas fees on Manta Pacific are estimated from the exact transaction’s gas demand and fee fields, then confirmed from its mined receipt. The gas limit is a spending boundary, not the final charge. After inclusion, gas used, effective gas price, any separately reported rollup data fee, and receipt status explain both cost and outcome. A failed receipt can consume ETH because execution work occurred even though the state change reverted.
The short version: Estimate the exact call before signing, then use receipt status, gas consumed, and fee fields to explain the final ETH cost.
Cost inputs appear at two different moments
A useful estimate starts with the transaction request, while the final cost comes from the receipt created after inclusion. Mixing those moments can make a maximum allowance look like money already spent.
Before signing
The wallet or application supplies the sender, target address, ETH value, calldata, nonce, gas limit, and fee caps. An RPC node can simulate that exact request with eth_estimateGas to estimate execution units. The estimate can change when the sender, calldata, contract state, or pending block changes. A generic ETH transfer estimate does not describe a contract call with different computation and storage work.
The network identity is a prerequisite rather than a pricing input. Manta Pacific mainnet uses chain ID 169. A quote obtained from another chain describes another execution environment, even when the account address and token symbols look familiar. The sender also needs enough native ETH to cover the transaction’s value and applicable fee allowance.
After inclusion
The receipt replaces estimates with observed execution data. Its gasUsed field reports the work consumed, while effectiveGasPrice reports the price actually applied per execution unit. The receipt or explorer may also expose a separate rollup data charge. Read the explorer’s total carefully because some interfaces combine components and others present them separately.
A receipt must exist before fee reconciliation
A transaction can be reconciled only after a receipt ties it to a block. A wallet notification or transaction hash proves that a request was formed or broadcast, but neither proves inclusion.
For a mined Manta Pacific transaction, collect the fields that answer separate questions:
- The transaction hash identifies the submitted transaction.
- The block number confirms inclusion in a specific block.
- The receipt status distinguishes successful execution from a revert.
-
gasUsedandeffectiveGasPricedetermine the execution charge. - A separately reported rollup fee completes the total when the interface has not already included it.
If no receipt exists, classify the transaction as pending, replaced, or absent before discussing a final charge. An estimate remains provisional until the network produces the execution record.
How is the final fee reconstructed?
Multiply the receipt’s gas used by its effective gas price, then add any separately charged rollup component that is not already included in the displayed total.
For an included EIP-1559 transaction, the execution charge equals gas used multiplied by effective gas price. Both inputs are denominated in gas units and wei per gas, so their product is wei. Divide by 10 18 to express that result in ETH. This calculation uses the actual price, not the transaction’s maximum price cap.
Manta Pacific tooling can expose a rollup fee separately, including through the Gas Price Oracle interface used for unsigned transaction estimates. A receipt or explorer may label that component l1Fee. Add it only when it sits outside the execution product. If an interface already displays a combined transaction fee, adding the field again would double count the same cost.
Failed execution leaves evidence for diagnosis
An included failure can be diagnosed from its receipt, including consumed gas, the resulting state, and any available trace data. Each source answers a different part of the diagnosis.
Receipt status
A status of zero means the top-level transaction did not complete successfully. Status one means execution finished without a top-level revert, though it does not prove that the application produced the result the sender expected. Contract state, balances, allowances, and emitted logs provide that separate confirmation.
State rollback
A reverted EVM call rolls back its state changes but still charges for gas consumed before the revert. An attached ETH transfer and token changes inside the failed call therefore do not complete. The fee remains because the network still processed the instructions that led to the failure.
Trace output
The standard receipt does not contain a full explanation of the revert. A raw trace or a simulation against the relevant state can identify the failing call and may return encoded revert data. A known contract interface can decode a named error or failed condition. Without that interface, the trace still shows where execution stopped, but guessing a cause from gas cost alone is unreliable.
A worked fee check separates a revert from an out-of-gas failure
Use the receipt to decide whether to raise the execution limit or correct the call that reverted.
Hypothetical fee and failure check. Every numeric value, balance, fee field, and outcome in this example is hypothetical. A wallet holds 20,000,000,000 wei of ETH. Its exact call estimates 68,218 gas, uses a gas limit of 72,908, sets maxFeePerGas to 520,000 wei, and estimates a separate rollup charge of 8,731,000,000 wei.
The execution ceiling is 72,908 × 520,000, or 37,912,160,000 wei. Adding the estimated rollup component produces an upper planning amount of 46,643,160,000 wei. The starting balance is below that amount, so insufficient ETH is the missing prerequisite. Broadcasting repeatedly cannot repair the balance.
After the balance is increased, the exact call is estimated again and submitted. Its hypothetical receipt has status zero, gasUsed of 64,318, effectiveGasPrice of 420,000 wei, and a recorded rollup fee of 8,731,000,000 wei. The execution charge is 27,013,560,000 wei. The total recorded cost is therefore 35,744,560,000 wei, or 0.00000003574456 ETH.
Gas used stayed below the 72,908 limit, and the trace returns application revert data. Raising the limit is not supported by that evidence. Correct the failed input or prerequisite state, estimate the revised request, and create a new transaction. Completion requires a status-one receipt and the intended application state.
Pending, dropped, and reverted transactions are different states
Only an included transaction has an execution receipt and a settled gas charge. Wallet interfaces sometimes group several unfinished or unsuccessful states under one failure label.
Pending without a receipt
A pending transaction has been broadcast but has not yet appeared in a block. Its fee fields describe an offer, not an observed charge. The wallet may reserve part of the displayed balance locally while the transaction waits. That reservation is not an onchain payment.
Dropped or replaced
A transaction that never enters a block does not consume execution gas. It may disappear from a node’s pending pool or lose to another transaction using the same sender nonce. Once a replacement is included, the original transaction cannot later execute with that already consumed nonce.
Included and reverted
A reverted transaction has a block number and receipt even though its intended state change failed. It consumes the nonce and charges the recorded fee. Repeating the same call without changing the failing condition can create another paid revert, so diagnosis belongs before resubmission.
What does gas used reveal about a failure?
Gas used shows how much execution work occurred and whether the transaction reached its limit, but it does not identify every contract error by itself.
When status is zero and gasUsed reaches the gas limit, exhaustion is a strong lead. Confirm it with the trace because nested calls and exceptional halts can complicate the visible pattern. A fresh estimate of the same call may also fail before submission and return useful revert data.
When status is zero but gas used remains materially below the limit, a logical revert is more likely than an inadequate cap. Common categories include a failed authorization, expired condition, invalid argument, or contract state that no longer satisfies the call. The trace and decoded contract error, not a higher fee cap, distinguish those causes.
Similar fee fields serve different purposes
The gas limit caps execution units. Gas used records units actually consumed. Unused units are not charged as though they were spent, so increasing the limit does not automatically increase the final fee. It does increase the maximum execution exposure available to the transaction.
maxFeePerGas is the highest per-unit price the sender authorizes for an EIP-1559 transaction. maxPriorityFeePerGas limits the priority portion, while effectiveGasPrice records the per-unit price applied in the included block. The first two fields help define admission and spending bounds; the last one belongs in the final calculation.
A rollup data charge covers a different resource from EVM computation. Its estimate depends on the serialized transaction and live network parameters, so calldata changes can affect it even when execution gas is similar. Use the network-provided estimate before signing and the recorded field after inclusion rather than treating either value as permanent.
Completion needs execution and application evidence
Fee reconciliation shows what the network charged. The resulting state shows what the transaction achieved.
For a successful contract call, compare the receipt with the expected balance, allowance, ownership record, or contract value. Logs can support that check when the contract is expected to emit them. For a failed call, verify that the intended state change did not occur and retain the receipt as the cost record.
Fee analysis is complete when the execution product and any separate rollup component match the displayed total. Transaction analysis is complete when status and application state agree. A status value of 1 closes the execution question; the intended balance, allowance, or contract record closes the task.
Mantanetwork gas fees: common questions
Does changing the RPC endpoint reduce Manta Pacific transaction costs?
Changing the RPC endpoint does not alter the fee rules of Manta Pacific. Different endpoints can return estimates at slightly different moments or lag behind the latest block, which may change a wallet’s quote. The final included transaction follows the network state in its block. Confirm chain ID 169 so an endpoint mismatch is not mistaken for a pricing difference.
What happens to the sender nonce after a reverted Manta Pacific transaction?
An included reverted transaction consumes the sender’s nonce. Its receipt has a block number and failure status, so another transaction from that account must use the next available nonce. A transaction that remains pending or is dropped has not necessarily consumed the nonce. A replacement can use the same nonce until one of the competing transactions is included.
Can a successful gas estimate guarantee that the transaction will execute?
A successful gas estimate does not guarantee successful execution. Estimation simulates the supplied call against a particular state, while balances, allowances, deadlines, contract storage, and block conditions can change before inclusion. Keep the sender, target, value, and calldata identical when comparing the estimate with the signed request. The mined receipt remains the authoritative execution result.
Will a reverted contract call transfer its attached ETH value?
A reverted call does not complete its attached ETH value transfer. The EVM rolls back state changes made by that failed execution, including the value movement inside the call. The sender still pays the gas recorded by the receipt because the network performed computation before the revert. Compare the post-transaction balance with the fee as a separate deduction.
Updated on