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

Low Risk
Localized gas-estimation change with default behavior unchanged for other chains; Mantle may show slightly high fees when using gas limit fallback.

Overview
Fixes Mantle confirmation totals omitting the Arsia operator fee when transactionMeta.gasUsed is missing (e.g. Mantle unsupported by simulation), which previously skipped getOperatorFee and under-reported layer1GasFee.

OracleLayer1GasFeeFlow now routes operator-fee oracle input through a protected getOperatorFeeGas hook (default still gasUsed). MantleLayer1GasFeeFlow overrides it with gasUsed ?? txParams.gas ?? txParams.gasLimit so pre-confirmation estimates still call the oracle; using gas limit slightly over-estimates rather than under-shows the fee. Tests and changelog updated accordingly.

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