Mantle
Mantle gas fees include execution, data, and operator charges payable in MNT
Updated on
Mantle gas fees cover transaction execution, data publication, and any configured operator charge, with native MNT paying the network bill. Under Arsia accounting, gas units measure the execution workload. A complete estimate adds the data and operator components. The wallet also needs enough MNT for any native value the transaction sends.
The balance needed to submit can exceed the expected final charge because transaction validation checks fee reservations. Application charges and bridge costs require separate accounting whenever the selected operation includes them.
The short version: The execution fee cap controls gas pricing, while data and operator charges still contribute to the required MNT balance.
Execution, data, and operator charges
A comparable fee quote needs the actual contract input, the estimated execution gas, and fee parameters from the same block. The execution price and gas quantity determine one component. Data size and fee configuration determine the other charges. Adding amounts requires a consistent MNT denomination. A lower gas price does not establish a cheaper transaction when the workload or data differs.
Execution consumes gas for operations such as computation and storage access. Data charging accounts for the encoded transaction's contribution to rollup publication costs. Arsia uses a compression-based size estimate with Ethereum base-fee and blob-fee inputs. The execution client converts this ETH-denominated data amount into MNT using the network's
tokenRatio. A changed ratio can change the MNT charge without changing the transaction's contents. Two calls with similar execution requirements can therefore carry different data charges when their encoded contents differ.
The operator component uses a configurable constant and a charge proportional to execution gas.
GasPriceOracle
exposes the applicable operator parameters. Their configuration can produce a zero charge. A zero value in one estimate establishes the applicable charge for that estimate; it does not establish a permanent network policy.
A wallet may display these components as one fee. That combined amount needs no second addition of the same data or operator charge.
Native MNT balance and transaction value
Spendable gas balance
The payer needs native MNT on Mantle to fund an ordinary transaction's network charges. An asset balance on another chain does not supply this balance. Neither does a token balance held inside an application automatically become spendable native currency. The transaction's payer and attached native value determine which balance validation checks apply.
Expected charge and required reservation
A transaction sending MNT needs funding for both its attached value and its fees. With EIP-1559 pricing, execution affordability checks use the gas limit and maximum fee per gas. Rollup charges also contribute to the required funds. The expected fee can be lower than this reservation because execution may consume less gas or pay a lower effective price. A transfer leaving only the expected fee available can still fail affordability checks.
Arsia-aware gas and fee estimates
Arsia changed the meaning of Mantle's execution-gas accounting, which affects older calculators and integrations. Under Arsia, the transaction receipt's gasUsed field excludes L1 data and operator costs. Multiplying an execution estimate by its gas price consequently omits those other components. Older combined-gas calculations follow different accounting, so applying an additional data charge to them can count the same cost twice.
The
eth_estimateTotalFee
RPC method estimates the combined network fee for a supplied transaction on a supporting endpoint at a block where Arsia applies. Its result is a monetary amount in native currency base units, not a gas limit. The estimate uses the selected block's state and fee inputs. Sender, recipient, native value, contract input, and fee settings must match the intended transaction. A different call or a later block can change the amount.
Which gas settings change the execution bill?
The gas limit bounds available execution units, while EIP-1559 fee settings bound the MNT price the transaction permits per execution gas unit.
Gas limit
The gas limit must allow the intended contract execution to finish. Reducing it does not reduce the work the contract requires. An insufficient limit can exhaust execution gas and cause failure. Increasing it permits more work without charging for every unused unit. Contract deployment requires an estimate reflecting its creation bytecode and constructor execution; a limit copied from a simple transfer does not describe that workload.
Price cap and priority fee
The
maxFeePerGas
field caps the execution price, and
maxPriorityFeePerGas
caps the priority portion. For a valid EIP-1559 transaction, the effective price is the smaller of the maximum fee and the block's base fee plus the priority cap. The maximum fee must cover the applicable base fee. This price cap does not impose an all-in limit on the separately calculated data and operator charges.
Submitting now or refreshing the quote
The complete estimated network fee must fit your budget before you submit, whether you use the current quote or wait for a refreshed one. Immediate submission uses the present inputs. Waiting requires another estimate and an action that remains valid. An application deadline or changing contract state can make postponement unsuitable, even if a later fee might be lower.
- Compare the full MNT estimate with the chosen network-fee budget.
- Confirm the estimate uses the intended sender, recipient, native value, contract input, and fee settings.
- Check the native balance covers value and the required fee reservation.
- Refresh the quote after changing the transaction or delaying submission.
- Check that the call remains valid under any application deadline and contract execution conditions.
An estimate above the budget rules out submission under that spending condition. You can submit when the current or refreshed estimate fits the budget and the call and balance checks pass. The estimate remains a forecast. After inclusion, the receipt supplies execution status and fee information to compare with the quote; a transaction hash alone does not confirm successful execution.
Does a reverted Mantle transaction still incur fees?
A Mantle transaction included in a block can incur network charges even when contract execution reverts and its intended state changes fail. Execution still consumes resources, and the included transaction still has a data footprint. Standard execution accounting returns unused gas, while an out-of-gas failure can consume the available execution allowance.
An error during fee estimation does not itself create an onchain transaction. Likewise, a node rejecting an unaffordable transaction before inclusion differs from a transaction executing unsuccessfully in a block. More execution gas can address an insufficient allowance; it cannot repair a missing permission or an unmet contract condition. Repeatedly submitting an unchanged reverting call can produce repeated charges.
Receipt fields and the final network charge
Execution cost
The receipt records the transaction's execution usage and effective price. For an ordinary post-Arsia user transaction, gasUsed multiplied by effectiveGasPrice gives its execution fee. The gas limit describes the permitted allowance, so substituting it for actual usage overstates this component when units remain unused. Receipt status separately indicates whether execution succeeded.
Data and operator entries
The receipt's
l1Fee
field supplies the data charge. Arsia's operator calculation adds
operatorFeeConstant
to
gasUsed
multiplied by
operatorFeeScalar
and 100. These receipt parameters describe that transaction's applicable configuration. Adding the execution, data, and operator amounts in the same native units reconstructs its network charge. Deposit transactions have different handling, so this calculation concerns ordinary user transactions. If a provider omits required fee fields, the execution amount alone cannot establish the total.
Bridge costs and recurring fee budgets
A bridge operation can involve charges on different chains, each with its own fee currency and execution conditions. An Ethereum transaction pays gas in ETH; a Mantle transaction uses MNT. Mantle's L1 data component is part of rollup transaction billing. It does not replace the fee for a separate Ethereum transaction the selected bridge operation requires. Any service fee the chosen application charges also belongs in the operation's budget.
Recurring budgets benefit from transaction records showing the call type, estimation block, quoted fee, and receipt total. The same application can invoke different contract paths as its state changes. Updating a contract or changing its input can alter execution and data requirements. Recent completed transactions help explain past charges, while a fresh estimate describes the next call. A wallet with insufficient native MNT cannot fund the next ordinary transaction, even if it holds other tokens.
Common questions, answered
Do read-only contract calls incur Mantle gas fees?
Read-only RPC calls do not incur an onchain Mantle transaction fee. The eth_call method simulates execution without publishing a transaction, and balance queries need no signing. An RPC provider can have separate service pricing or usage limits. A function invoked inside an actual submitted transaction contributes to that transaction's execution cost.
Is a testnet gas quote a reliable mainnet cost estimate?
A testnet quote does not establish the MNT charge a mainnet transaction will incur. Testnet and mainnet have separate state, fee inputs, and balances. A rehearsal can reveal execution requirements for its particular contract state, but different deployed code or storage can change those requirements. Mainnet budgeting needs an estimate on mainnet for the intended call. Testnet currency cannot fund the mainnet fee reservation.
Does an ERC-20 approval add another network charge?
An ERC-20 approval adds a network charge when the workflow submits it as a separate transaction. A swap estimate may cover only the swap call. An existing sufficient allowance can remove the need for another approval. Some contracts support signature-based authorization, with their own requirements, so authorization does not always require a separate transaction. Count the transactions the selected workflow actually submits when budgeting its gas.
What does a method not found error mean for eth_estimateTotalFee?
A method not found error means the selected endpoint does not expose that RPC method. It does not establish a zero transaction fee. Endpoint support and node software determine which methods a provider serves. A compatible endpoint can supply the combined estimate; otherwise, a Mantle-aware integration must account for execution, data, and applicable operator charges. An execution-gas estimate alone remains an incomplete network-fee estimate under Arsia.
Will replacing a pending transaction charge both gas estimates?
Competing transactions from the same sender using the same nonce cannot both execute in the canonical chain. A replacement can change the fee terms, and the included transaction determines the actual charge. Sending a new transaction with a different nonce creates a separate operation and can incur another fee. A cancellation attempt also uses a replacement transaction; it needs inclusion before the original and does not guarantee cancellation.