fix/mantle lack operator fee

[jeremytsng]

Explanation

We observed the confirmation screen showing 0.10 MNT for a transaction that ended up costing 0.12 MNT — the ~0.02 MNT delta is the operator-fee component of Mantle's Arsia gas model, which never reached the displayed total.

Root cause is in OracleLayer1GasFeeFlow.#getOperatorLayer1GasFee: the method skips the operator-fee oracle call whenever transactionMeta.gasUsed is unset. That field is populated by the transaction simulation backend, and Mantle is not in its supported-networks list — getBalanceChanges throws SimulationChainNotSupportedError, the catch returns gasUsed: undefined, and the operator-fee path silently collapses to zero for the entire pre-confirmation lifecycle (initial render, gas-fee poller re-poll, edit-gas). The UI sums layer1GasFee straight into the displayed total in useFeeCalculations.ts, so the dropped operator fee flows directly to the user.

The fix introduces a protected getOperatorFeeGas hook on OracleLayer1GasFeeFlow. The base default returns transactionMeta.gasUsed, so OptimismLayer1GasFeeFlow, ScrollLayer1GasFeeFlow, and any other current or future subclass keep their existing behaviour. MantleLayer1GasFeeFlow overrides the hook to fall back to txParams.gas ?? txParams.gasLimit when gasUsed is unavailable.

The transaction's gas limit is an upper bound on actual gas used (it carries the updateGas buffer when populated by the controller, and is the caller-supplied value otherwise). Mantle's operator-fee oracle is strictly linear in its input gas (verified on-chain at 0x420000000000000000000000000000000000000F — getOperatorFee(21000) = 2.1e14, getOperatorFee(500000) = 5e15, same per-gas rate), so the operator fee returned for a gas-limit input is an upper bound on the realised operator fee. The displayed total will be a hair above the actual on-chain cost rather than under-reporting it. This matches the over-estimate direction already used for the Optimism L1 data fee.

Caller coverage with the override in place:

• Confirmation screen (addTransaction flow): updateGas populates txParams.gas in #updateGasProperties before updateTransactionLayer1GasFee runs in the same method.
• GasFeePoller 10s re-poll: reads the same txParams.gas from state.
• updateEditableParams (user edits gas): uses the new txParams.gas after the edit.
• Bridge L1-fee path: bridge-controller's appendL1GasFees is allowlisted to Optimism + Base only today, so Mantle quotes don't reach this code. The ?? gasLimit arm future-proofs the bridge getLayer1GasFee call shape if Mantle is added later.

References

Fixes the operator-fee under-reporting flagged by the Mantle team following the Arsia gas model rollout.

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

Note

Medium Risk
Touches fee estimation logic used to display L1 gas costs; incorrect fallbacks could over/under-estimate user-facing fees on Mantle (and potentially other OP-stack subclasses if overridden in future).

Overview
Fixes Mantle L1 gas fee estimation so the operator-fee component is still included when simulated transactionMeta.gasUsed is unavailable.

OracleLayer1GasFeeFlow now routes the operator-fee oracle call through a new overridable hook, getOperatorFeeGas, and MantleLayer1GasFeeFlow overrides it to fall back to txParams.gas (then txParams.gasLimit) instead of skipping the operator fee entirely. Tests are updated/expanded to cover the new fallback and the “skip when no gas value exists” behavior, and the CHANGELOG.md documents the fix.

^{Reviewed by Cursor Bugbot for commit f7003fe. Bugbot is set up for automated code reviews on this repo. Configure here.}