Custom Network Gas Limit Estimation

[dlebee]

Dear MetaMask Team,

I noticed the function getGas:

async function getGas(
  request: UpdateGasRequest,
): Promise<[string, TransactionMeta['simulationFails']?, string?]> {
  const { isCustomNetwork, chainId, txMeta } = request;

  if (txMeta.txParams.gas) {
    log('Using value from request', txMeta.txParams.gas);
    return [txMeta.txParams.gas, undefined, txMeta.txParams.gas];
  }

  if (await requiresFixedGas(request)) {
    log('Using fixed value', FIXED_GAS);
    return [FIXED_GAS, undefined, FIXED_GAS];
  }

  const { blockGasLimit, estimatedGas, simulationFails } = await estimateGas(
    txMeta.txParams,
    request.ethQuery,
  );

  if (isCustomNetwork || simulationFails) {
    log(
      isCustomNetwork
        ? 'Using original estimate as custom network'
        : 'Using original fallback estimate as simulation failed',
    );
    return [estimatedGas, simulationFails, estimatedGas];
  }

  const bufferMultiplier =
    GAS_BUFFER_CHAIN_OVERRIDES[
      chainId as keyof typeof GAS_BUFFER_CHAIN_OVERRIDES
    ] ?? DEFAULT_GAS_MULTIPLIER;

  const bufferedGas = addGasBuffer(
    estimatedGas,
    blockGasLimit,
    bufferMultiplier,
  );

  return [bufferedGas, simulationFails, estimatedGas];
}

I appreciate the use of gas buffering in this function as it helps improve the chances of transaction acceptance. However, I noticed that when adding a custom network, there is currently no option to configure a gas buffer or even apply one to the gas limit. This creates challenges for platforms that integrate with MetaMask but don’t estimate gas or add a buffer before sending transactions to the extension. As a result, many integrations fail, leading to a suboptimal user experience.

I believe it would significantly enhance usability if MetaMask allowed users to configure gas buffering as part of the custom network setup. This could be either:

A toggle to enable gas buffering for a specific network in the network setup.
An option in the advanced network settings to apply a configurable buffer multiplier.

I understand that some networks already buffer gas during the estimateGas RPC call, and the behavior can vary between networks. However, enabling this feature at the user or network level would reduce the need for manual gas limit adjustments, saving users 2-3 extra clicks every time they edit the gas limit for transactions, also it can be disabled by default.

I hope you find this feedback constructive and consider introducing these options to further improve the user experience.

Thank you for your time and effort in building an amazing platform. I look forward to seeing how MetaMask continues to evolve!

[kevinnguyen17]

As we are in the era of booming new chains, this capability is crucial for Metamask's adaptability to

• Ensure Metamask can support diverse network behaviors, especially for the new networks or specialized network
• Allow dynamic gas estimation based on smart contract operations to optimize buffering, as some functions require minimal buffering, making large gas reserves inefficient.

[bschorchit]

Hey @kevinnguyen17, thank you for your report. We're currently looking it optimizing our buffering indeed. Could you share more why users need to manually adjust gas limit on every transaction? Is it because with the buffer, the fee exceeds their funds and they have to manually reduce it?

[dlebee]

@bschorchit hello i think the question was directed to me.

Similar to ethereum, rpc’s estimate gas and return the amount or gas that the function took to execute, but different computers with different strength of computers or variation of specs may estimate gas differently because of the different node implementations.

So its typically recommended to add a little bit of buffer to the gas estimation to guarantee that there is enough gas limit and that the execution does not get reverted. This buffer removes the risk of variation of local estimations by different nodes.

Like it can be seen in the function supported network all add a 35% more gas to the estimation returned by the rpc to guarantee that the transaction is successful, but custom network do not add this 35% buffer, because of this the user will experience alot of reverted transactions, so it forces users to add more gas limit everytime they send a transaction manually which is about 3-5 additional clicks.

So the proposal is to allow custom networks to configure if they want to add a buffer to the estimation like the officially supported network which is the recommended practice.

[dlebee]

I also wanted to add that if you don’t adjust the estimation and the transaction gets reverted, the fee is still paid by the user even if the transaction is failed which makes the user waste some native currency. (Ex: ETH, BNB, MATIC, which is used to pay for gas fees)

Even though buffering may require a bigger native balance (35% more) its better than wasting native token on a reverted transaction, this is especially true for layer 1’s which have higher transaction fees.

that’s why the supported network conditions always add 35%, but custom network also needs this.

Other discussions:

• https://docs.chain.link/ccip/tutorials/ccipreceive-gaslimit
• Add buffer on default gas limit for transactions to minimize risk of transactions being reverted ethers-io/ethers.js#3627

https://ethresear.ch/t/overcoming-gas-estimation-challenges/15463
a) Out-of-gas errors: If a transaction’s gas limit is set too low, the transaction may run out of gas during execution, causing it to fail. Out-of-gas errors can be particularly problematic for users, as they not only result in failed transactions but also lead to the loss of the gas fees paid to initiate the transaction. Accurate gas estimation can help prevent out-of-gas errors by ensuring that the gas limit is set high enough to cover the transaction’s gas requirements.

[dlebee]

bump ^?