Hide approvals in batch transactions when simulation fails

[cursor]

Description

When a batch transaction fails simulation (e.g., eth_estimateGas returns "execution reverted"), but the batch contains an approval, the UI renders the approval details instead of showing the "Transaction is likely to fail" warning. This can be misleading as users see approval UI when the transaction is actually going to fail.

Current Behavior

1. User initiates a batch transaction (e.g., on Jumper Exchange)
2. eth_estimateGas fails with "execution reverted"
3. Because simulation fails, an extremely high gas limit is set
4. The UI shows the approval details (e.g., "You approve 1 USDC")
5. The "Transaction is likely to fail" warning is not shown because the decoded approval takes precedence
6. User sees "Network fee: Unavailable" and possibly "Not enough ETH for fees" but no clear warning about the transaction likely failing

Expected Behavior

When a batch transaction simulation fails, the "Transaction is likely to fail" warning should be shown instead of (or in addition to) the decoded approval information. The simulation failure should not be masked by successfully decoded approval data.

---

Scenario

• GIVEN a user is on a dApp that submits batch transactions (e.g., Jumper Exchange)
• WHEN the dApp submits a batch transaction that includes an approval
• AND the eth_estimateGas call fails with "execution reverted"
• THEN the confirmation UI should display a clear warning that the transaction is likely to fail
• AND the warning should NOT be hidden just because an approval was successfully decoded from the transaction data

---

Technical Details

• When eth_estimateGas fails, we currently set a high fallback gas limit
• Batch transactions may contain multiple operations including approvals
• The decoded approval is currently rendered, which "swallows" the simulation failure warning
• The simulation failure state should take precedence over decoded approvals for user safety

Relevant error returned from eth_estimateGas:

{
    "jsonrpc": "2.0",
    "id": 2642369348948336,
    "error": {
        "code": 3,
        "message": "execution reverted",
        "data": "0x90bfb865..."
    }
}

---

Threat Modeling Framework

• What are we working on? Improving the confirmation UI to properly warn users when batch transactions are likely to fail, even when they contain decodable approvals.
• What can go wrong? Users proceed with transactions that will fail and lose gas fees. Users may not understand why their transaction failed because they only saw approval UI.
• What are we going to do about it? Show the "Transaction is likely to fail" warning when simulation fails, regardless of whether approvals were decoded.
• Did we do a good job? Acceptance criteria below will validate this.

---

Acceptance Criteria

• When a batch transaction simulation fails, the "Transaction is likely to fail" warning is shown
• The warning should not be hidden or replaced by decoded approval information
• Users should see a clear indication that the transaction may revert
• The gas fee should show "Unavailable" or "Cost unknown" rather than an inflated fiat value from the fallback gas limit
• Consider making failed gas estimation a "danger" severity requiring user acknowledgment

---

Stakeholder Review

• Engineering (needed in most cases)
• Design
• Product
• QA
• Security
• Legal
• Marketing
• Management
• Other

---

References

• Observed on MetaMask versions 13.20 and 13.21 RC
• Reproduced using Jumper Exchange on Base network
• Related to batch transaction handling and gas estimation fallback logic
• Internal Slack discussion in #priv-metamask-confirmations (March 4, 2026)