Enforced simulations replace the dapp's gas limit with a zero-margin estimate (issue #46334)

Feature Requests
1

Hello,

We build a DeFi dapp on Ethereum and Base, and we have hit a MetaMask behaviour that makes user transactions fail. We filed it as issue #46334 on GitHub, where the triage bot labelled it a regression against 13.46.1. Posting here as well in case other dapp developers are seeing the same thing.

When our interface sends a transaction with an explicit gas limit, MetaMask discards it and substitutes a fresh eth_estimateGas result with no margin. It does this whenever the contract being called is not rated Trusted by the address scan, Benign included, and it happens as soon as the confirmation opens, whether or not the user turns on “Added protection”.

In the extension source (v13.50.0):

  • shared/lib/transaction/enforced-simulations.ts: isEnforcedSimulationsEligible() is true when a recipient’s cached verdict is anything other than Trusted.
  • ui/pages/confirmations/components/rows/enforced-simulations-row/enforced-simulations-row.tsx: when eligible, calls applyTransactionContainersExisting() on load, with an empty container list when Added protection is off.
  • app/scripts/lib/transaction/containers/util.ts, applyTransactionContainers(): deletes gas and gasLimit, re-estimates, and writes the raw estimate back even when no container is applied.

Why a zero-margin limit fails in practice: our vaults deposit into Aave, Compound and Morpho, which update interest on the first transaction in each block. The gas a deposit needs therefore rises 5-12% between the estimate and the block it lands in. We set our limit to the estimate x 1.3 for exactly that reason. In fork tests across 18 of our vaults on both chains, every deposit sent with a zero-margin limit ran out of gas, while every deposit and withdrawal sent with our limit succeeded, even an hour after the estimate. A failing transaction is linked in the issue.

What we think the fix looks like:

  1. When no container is applied, leave the dapp’s gas limit alone.
  2. When a container is applied, treat the dapp’s limit as a floor and add a margin to the new estimate.

This affects any protocol whose gas use moves between estimate and inclusion, so it is unlikely to be only us. Has anyone else run into it, and is there a recommended workaround in the meantime?

Thanks,
The ACCRUE team

2

Hello, if you’ve already reported this issue, could you please wait a little for a response? You can also create a topic about the issue and share it with other developers :slightly_smiling_face:

1 Like