Skip to content

feat(transaction-pay-controller): Add shared EIP-7702 quote gas estimation#8145

Open
pedronfigueiredo wants to merge 1 commit intomainfrom
pnf/cor-across-metric
Open

feat(transaction-pay-controller): Add shared EIP-7702 quote gas estimation#8145
pedronfigueiredo wants to merge 1 commit intomainfrom
pnf/cor-across-metric

Conversation

@pedronfigueiredo
Copy link
Contributor

@pedronfigueiredo pedronfigueiredo commented Mar 9, 2026

Explanation

Add a shared quote gas estimator that switches between per-transaction and EIP-7702 batch estimation, reuses Across’s ordered submission transaction list at quote time, and falls back to the single-transaction path when batch estimation is unsupported or fails.

References

https://github.com/MetaMask/MetaMask-planning/issues/7098

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
Medium risk because it changes gas limit/cost calculation and batching behavior for Across and Relay, including optional EIP-7702 estimateGasBatch and 7702 batch submission paths. Incorrect estimation ordering or fallback handling could lead to failed transactions or mispriced fees on supported chains.

Overview
Adds a new shared estimateQuoteGasLimits utility to compute per-transaction gas limits, optionally using EIP-7702 estimateGasBatch on supported chains with buffering and safe fallback to individual estimation/fallback gas.

Across quoting now uses a single ordered transaction list (getAcrossOrderedTransactions) and can return a combined gasLimits.batch for multi-tx quotes; Across submission detects this and submits a 7702 batch (gasLimit7702, disables hook/sequential) while omitting per-tx gas.

Relay quoting replaces bespoke single/batch gas estimation with the shared estimator, including placeholder/fallback param population when quote items omit fields, and updates feature-flag helpers by adding getEIP7702SupportedChains (used by isEIP7702Chain). Tests are expanded to cover batch usage, fallbacks, and edge cases (missing swap gas, missing approval chainId, non-7702 chains).

Written by Cursor Bugbot for commit 33c04a7. This will update automatically on new commits. Configure here.

@pedronfigueiredo pedronfigueiredo self-assigned this Mar 9, 2026
@pedronfigueiredo pedronfigueiredo requested a review from a team as a code owner March 9, 2026 11:30
@pedronfigueiredo pedronfigueiredo requested a review from a team as a code owner March 9, 2026 11:32
Copy link
Contributor

@cryptotavares cryptotavares left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewing as @cryptotavares's AI assistant

Overall this is a clean refactor — the shared estimator logic is well-structured, fallbacks are correctly wired, and the batch/individual split in estimateQuoteGasLimits is sound. A few things worth addressing before merge:


Bug: Missing chainId fallback in getAcrossOrderedTransactions

File: src/strategy/across/transactions.ts + src/strategy/across/across-quotes.ts

getAcrossOrderedTransactions spreads approval transactions directly from the Across API response:

const approvalTransactions = (quote.approvalTxns ?? []).map((approval) => ({
  ...approval,
  kind: 'approval' as const,
  type: TransactionType.tokenMethodApprove,
}));

If the Across API omits chainId on an approval transaction (which the old code explicitly guarded against with quote.approvalTxns?.[index]?.chainId ?? swapTx.chainId), then transaction.chainId will be undefined at runtime despite the type saying number. The gas estimation call in calculateSourceNetworkCost then does:

chainId: toHex(transaction.chainId),  // toHex(undefined) → likely '0x0'

This would target the wrong chain for gas estimation. The cost calculation later in calculateSourceNetworkCost still has the correct fallback (quote.approvalTxns?.[index]?.chainId ?? swapTx.chainId), but that doesn't help if estimation ran against chain 0x0.

The old fallback was intentional. Either:

  • Add the fallback inside getAcrossOrderedTransactions (pass swapTx.chainId and use approval.chainId ?? swapChainId), or
  • Add it at the call site in calculateSourceNetworkCost when building the transactions array

Logic concern: useBuffer skips buffer when batch API echoes provided gas

File: src/utils/quote-gas.ts (~L105)

const useBuffer =
  gasLimits.length === 1 || paramGasLimits[index] !== gasLimit;

When estimateGasBatch returns per-transaction results (gasLimits.length === transactions.length), useBuffer is false if the batch API returns exactly the value that was passed in via transaction.gas. The intent seems to be "if the chain just echoed back our provided value, don't add a buffer on top." That's a reasonable interpretation, but paramGasLimits[index] is the parsed input gas; if the batch API happens to estimate the same number that was provided (not just echo it), buffer would also be skipped. Is that intentional? Worth adding a comment to clarify.


Minor: combinePostQuoteGas EIP-7702 detection heuristic

File: src/strategy/relay/relay-quotes.ts (~L480)

// TODO: Test EIP-7702 support on the chain as well before assuming single gas limit.
const isEIP7702 = gasLimits.length === 1;

A single-step Relay quote (one transaction, individual estimation) also produces gasLimits.length === 1, so this misidentifies it as a 7702 batch and combines the original tx gas into a single limit. I see this has a TODO already — just flagging it as something that becomes more load-bearing now that the shared estimator is in use for both strategies.


One merge blocker (the chainId fallback regression), one question (buffer logic intent), one pre-existing TODO that's worth tracking. Happy to look at a follow-up once the chainId question is resolved.

jpuri
jpuri previously approved these changes Mar 11, 2026
@pedronfigueiredo pedronfigueiredo force-pushed the pnf/cor-across-metric branch 2 times, most recently from ec0ec98 to e0c0649 Compare March 11, 2026 18:16
@pedronfigueiredo pedronfigueiredo force-pushed the pnf/cor-across-metric branch 2 times, most recently from 5317383 to 8a2e24a Compare March 11, 2026 18:39
Copy link

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.

params.length === 1
? await calculateSourceNetworkGasLimitSingle(params[0], messenger)
: await calculateSourceNetworkGasLimitBatch(params, messenger);
const fallbackChainId = params.find(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are all marked as required in the Relay type meaning we can assume they are present to simplify the code, and it can throw if they are not provided.

params.length === 1
? await calculateSourceNetworkGasLimitSingle(params[0], messenger)
: await calculateSourceNetworkGasLimitBatch(params, messenger);
const fallbackChainId = params.find(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are all marked as required in the Relay type meaning we can assume they are present to simplify the code, and it can throw if they are not provided.

)?.data;

const relayGasResult = await estimateQuoteGasLimits({
allowBatch: params.every(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we just assume this is always the case? Either the quote has valid calls we can process or we should throw?

fallbackGas: getFeatureFlags(messenger).relayFallbackGas,
fallbackOnSimulationFailure: true,
messenger,
transactions: params.map((singleParams) => ({
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor, should we define in variable for readability?

from:
singleParams.from ??
fallbackFrom ??
'0x0000000000000000000000000000000000000000',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also here, we shouldn't need these fallbacks since these aren't optional properties in the params?

} else if (gas.startsWith('0x')) {
parsedGas = new BigNumber(gas.slice(2), 16);
} else {
parsedGas = new BigNumber(gas);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are all of these not identical and already handled by the BigNumber constructor with no arguments such as base?

allowBatch &&
transactions.length > 1 &&
hasUniformBatchContext(transactions) &&
isEIP7702Chain(messenger, firstTransaction.chainId);
Copy link
Member

@matthewwalsh0 matthewwalsh0 Mar 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This flow and estimateGasBatch isn't just for 7702, it also supports sequential transactions by simulating them together to estimate gas for each one.

The 7702 check and all these fallbacks are already inside estimateGasBatch.

try {
return {
...(await estimateQuoteGasLimitsBatch(transactions, messenger)),
usedBatch: true,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this flow isn't just for 7702, we could change this to return is7702 to the submit phases know whether the single gas limit is because 7702 worked?

};
}

async function estimateQuoteGasLimitsIndividually({
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should just be for single via estimateGas, as the above batch flow already handles multiple non-7702 calls also.

} as QuoteGasLimit;
}

const gasLimitResult = await estimateGasLimit({
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can't estimate sequential calls since the latter would almost certainly revert since it requires state from the first, such as token approval then swap.

That's why estimateGasBatch does simulation on all the transactions to get sequential gas limits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants