MetaMask Added Protection is designed for a subtle Web3 threat: a malicious contract that behaves safely during simulation but changes its behavior when the real transaction reaches the blockchain. Instead of treating the preview as an informal estimate, the feature makes the expected outcome a condition of execution. If the actual result no longer matches that protected outcome, the transaction is rejected before the attacker receives the assets.

Last reviewed: October 1, 2026. MetaMask introduced this feature in Extension 13.45 for supported EVM networks with EIP-7702 smart accounts. Availability, supported networks, interface labels and mobile support may change. Verify the current status in official MetaMask documentation. This independent guide is educational and does not replace checking every transaction yourself.

Quick answer: Added Protection helps when transaction simulation is deliberately deceived. It binds the real transaction to the previewed result and rejects execution when the result changes. It does not validate your intent, recover stolen credentials, remove existing token approvals or eliminate every scam. A rejected transaction can also consume network gas.

What is MetaMask Added Protection?

Wallets commonly simulate a transaction before signing so the user can see likely balance and asset changes. That preview is useful, but a sophisticated malicious contract may identify that it is running inside a simulation and return an innocent-looking result. During real execution, the same contract can attempt a different transfer.

Added Protection strengthens the connection between those two stages. MetaMask describes it as an enforcement mechanism: the result shown during the protected simulation is included as a condition for execution. If the onchain result diverges, the transaction fails rather than completing the altered action.

Simulation and execution are not the same event

Stage What happens What can go wrong
Transaction preparation A dapp constructs contract calls, values and permissions The request may already contain an unsafe action
Simulation The wallet or security service predicts the likely result without committing it A contract may detect the simulated environment and behave differently
User confirmation The wallet presents available details and asks for approval The user may overlook an address, approval or unexpected asset change
Onchain execution Validators execute the submitted transaction against current state State, pricing or malicious contract logic can produce a different result

A simulation is a forecast based on a particular state and execution context. Added Protection is important because it turns selected preview information into a constraint instead of asking the user to trust the forecast unconditionally.

What is a red-pill attack?

A red-pill attack is a form of simulation evasion. The expression refers to contract logic that tries to determine whether it is being inspected in a simulated environment. When inspection is detected, the contract displays the harmless path. When the transaction is real, it reveals the malicious path.

  1. A user visits a deceptive or compromised dapp.
  2. The dapp prepares a transaction that appears routine.
  3. A wallet simulation calls the malicious contract.
  4. The contract detects clues associated with simulation and returns a safe-looking outcome.
  5. The user signs because the preview does not expose the intended theft.
  6. During real execution, the contract attempts a different asset transfer.

The core problem is not simply a missing preview. It is an adversarial preview: the attacker intentionally supplies one behavior to the safety check and another behavior to the blockchain.

How Added Protection changes the sequence

  1. MetaMask simulates the proposed transaction.
  2. The wallet determines the protected expected outcome.
  3. That expected result is enforced as part of the smart-account execution.
  4. The signed transaction reaches the network.
  5. Execution checks whether the real result matches the protected preview.
  6. If it matches, the transaction can proceed.
  7. If it does not match, execution is rejected and the targeted assets remain in the wallet.

This approach does not require a user to recognize the red-pill technique from contract code. It creates a technical boundary around the result the user was shown.

Why EIP-7702 smart accounts matter

EIP-7702 allows an externally owned account to set executable code for its account in supported environments. In practical wallet use, this makes smart-account features possible while keeping an existing address. MetaMask uses supported EIP-7702 smart-account capabilities to enforce the protected transaction outcome.

The important distinction is where the guarantee lives. A normal preview is information displayed before a regular transaction. Added Protection uses account execution logic so the real transaction must satisfy the expected condition. EIP-7702 is the enabling account mechanism; it is not, by itself, a guarantee that every transaction or dapp is safe.

Availability and network support

At MetaMask’s September 17, 2026 announcement, Added Protection was available in MetaMask Extension 13.45 on 13 EVM networks that supported its EIP-7702 smart-account implementation. MetaMask said mobile support was planned.

Treat that list as a dated release statement rather than a permanent compatibility promise. Before relying on the feature:

  • confirm the installed MetaMask version;
  • confirm that Added Protection is shown for the selected account and network;
  • check whether the account has the required smart-account functionality;
  • read the confirmation screen for the specific transaction;
  • consult the current official support page after an extension or network update.

What Added Protection can protect

Scenario Protection value Reason
Contract looks harmless only during simulation Directly relevant A changed real outcome can cause rejection
Previewed asset result is manipulated at execution Directly relevant The protected outcome must still match
Malicious dapp attempts a hidden different result Potentially protective Execution is constrained by the enforced preview
Contract execution differs from the protected simulation Transaction should fail The guarantee rejects the mismatch

The feature is most valuable when the preview itself is the attack surface. It is not a universal Web3 antivirus and should not be described as one.

What Added Protection does not protect

Risk Why it remains Better control
Stolen Secret Recovery Phrase or private key An attacker can control the account directly Offline backup and uncompromised devices
User knowingly approves the harmful result The real result may match the preview exactly Read asset changes, spender and destination
Unlimited token allowance A legitimate approval may grant excessive future authority Set practical limits and revoke unused approvals
Old malicious approval The authority may have been granted in an earlier transaction Audit allowances and revoke suspicious spenders
Address poisoning The user may select the wrong address before simulation Verify the full destination independently
Fake support or phishing Social engineering can obtain secrets or persuade a valid signature Use verified channels and never disclose recovery words
Compromised browser or device The environment can manipulate what the user sees Clean device, updates and hardware-wallet verification
Market movement and normal slippage Prices and blockchain state can change naturally Review slippage, minimum output and deadlines
Wrong network or wrong token The transaction may execute exactly as requested Verify chain ID, contract address and token identity

A safe preview can still describe an unsafe transaction

Suppose a transaction preview accurately says that a dapp will receive permission to spend an unlimited amount of a token. There is no mismatch: the warning is accurate, and the blockchain can execute exactly that permission. Added Protection is not meant to overrule a user’s confirmed choice.

The user must still decide whether the requested action is appropriate. Protection against simulation deception and protection against poor authorization are different layers.

Why a blocked transaction may still cost gas

A transaction that is rejected during onchain execution has still consumed validator computation and block space. For that reason, the network may charge gas even though the asset transfer did not complete. MetaMask states that it does not add an extra fee for Added Protection, but the network fee for a failed attempt can remain.

Before retrying a failed transaction:

  • do not assume the failure is a temporary wallet error;
  • read the wallet warning and transaction details;
  • disconnect from the dapp if its behavior is unexpected;
  • check the destination and calldata through a trusted explorer where appropriate;
  • review recent approvals;
  • avoid repeated submissions that can waste additional gas.

Added Protection versus ordinary transaction failure

Transactions fail for many reasons: insufficient gas, changed nonce, contract conditions, slippage limits, deadline expiry or an explicit revert. A failure alone does not prove that MetaMask stopped a red-pill attack.

Use the confirmation message, MetaMask activity details and block explorer status together. If the wallet explicitly reports that the protected outcome changed, treat the dapp as potentially hostile until independently verified.

Should you disable Added Protection?

MetaMask allows users to disable the feature from the confirmation flow. That can help with an incompatible transaction, but it also removes the guarantee for that submission. Disabling it should be a deliberate security decision, not a routine fix whenever a dapp fails.

Before proceeding without protection, determine:

  • why the transaction cannot use the protected route;
  • whether the dapp and exact domain are authentic;
  • whether an official source documents the incompatibility;
  • which assets and permissions are exposed;
  • whether a separate low-value wallet can reduce the risk;
  • whether waiting for support is safer than signing now.

A prompt from a website telling users to “turn off wallet protection” is a strong reason to stop. The dapp cannot make that risk decision on your behalf.

Transaction confirmation checklist

  1. Origin: verify the complete website domain and access it from a trusted bookmark.
  2. Account: confirm that the selected wallet is appropriate for the activity.
  3. Network: verify the chain and expected network fee token.
  4. Action: distinguish a transfer, swap, approval, permit and typed-data signature.
  5. Assets out: inspect every token and NFT leaving the account.
  6. Assets in: compare minimum output, recipient and expected token.
  7. Spender: for approvals, verify the contract and requested allowance.
  8. Protection state: confirm that Added Protection is active when available.
  9. Device display: if using a hardware wallet, compare critical details on its trusted screen.
  10. Uncertainty: reject the request when its purpose cannot be explained clearly.

Added Protection and token approvals

A token approval grants a spender contract authority that can survive after the original session ends. Added Protection may protect the transaction creating or using an approval from a changed simulated outcome, but it does not automatically make an excessive allowance sensible or revoke it later.

Keep approvals narrow when the dapp supports limits, remove permissions that are no longer needed and investigate unfamiliar spenders. Our MetaMask token approvals guide explains allowance checks and revocation without exposing recovery credentials.

Added Protection and Security Alerts

Wallet security controls answer different questions. A security alert may flag a known malicious actor, suspicious signature or risky interaction. Transaction simulation estimates balance changes. Added Protection enforces a protected simulated result. Blockaid-style threat detection, user review and smart-account enforcement complement one another; none makes the others unnecessary.

Use a separate wallet for unfamiliar dapps

Wallet separation limits consequences when a control fails. Keep long-term holdings away from routine experiments, use a low-value interaction account for unfamiliar applications and avoid granting valuable token allowances from a treasury wallet.

This design also improves clarity. A transaction that requests access to assets unrelated to the dapp is easier to reject when the active account contains only the assets required for that task.

Hardware wallets remain useful

A hardware wallet can keep signing keys off the browser computer and provide a separate confirmation display. It does not automatically understand whether a complex contract is economically safe. Added Protection can strengthen execution integrity, while the hardware device protects key use. Both still depend on careful review.

Never approve an unexplained blind-signing request merely because the account is protected by hardware. Verify that the device, MetaMask and dapp show a consistent action.

What to do after a suspicious rejection

  1. Stop interacting with the site and reject any new requests.
  2. Save the public transaction hash or error details, but never copy recovery words.
  3. Check the official dapp domain through an independent source.
  4. Inspect recent account activity on a reputable block explorer.
  5. Review token and NFT approvals associated with the account.
  6. Disconnect suspicious connected sites in MetaMask.
  7. If secrets may be exposed, use a clean device and an uncompromised wallet for asset migration.
  8. Report the domain through official MetaMask and project channels.

Revoking approvals requires onchain transactions and fees. If the Secret Recovery Phrase itself is compromised, revocation is not enough because the attacker has direct key control.

Common misunderstandings

  • “A green preview means the dapp is legitimate.” A preview explains an expected result; it does not certify the operator.
  • “Added Protection blocks every wallet drain.” It targets outcome manipulation, not every source of unauthorized access.
  • “A failed protected transaction is free.” Onchain rejection can still consume gas.
  • “EIP-7702 makes my account permanently safe.” It enables account logic; safety depends on the implementation and each authorization.
  • “If MetaMask allows disabling it, the difference is minor.” Disabling removes the execution guarantee for that transaction.
  • “Protection replaces approval management.” Existing and excessive allowances remain separate risks.
  • “The same feature must work on every chain and device.” Availability depends on wallet version, platform, network and account support.

A layered MetaMask security setup

  • Install MetaMask only from an official source and verify the browser extension.
  • Keep the browser, operating system and extension current.
  • Store the Secret Recovery Phrase offline and never enter it into a website.
  • Use a hardware wallet for material long-term balances where appropriate.
  • Separate savings, active trading and experimental dapp accounts.
  • Verify domains, recipient addresses, contracts and networks.
  • Review simulations and all asset changes before signing.
  • Keep Added Protection enabled when it is available and compatible.
  • Limit and periodically revoke token approvals.
  • Stop when a transaction or signature cannot be explained.

Frequently asked questions

What does MetaMask Added Protection do?

It enforces the protected outcome produced during transaction simulation. If real execution produces a different result, the transaction is rejected.

What is a MetaMask red-pill attack?

It is a malicious-contract technique that detects simulation, displays harmless behavior to the preview system and attempts a different action during real onchain execution.

Does Added Protection stop all malicious contracts?

No. It is designed for divergence between protected simulation and execution. A harmful transaction that accurately matches its preview can still be signed by the user.

Will my assets remain safe if the protected transaction fails?

MetaMask says the targeted asset movement is prevented when the enforced result does not match. However, the failed onchain attempt may still cost network gas.

Does MetaMask charge a fee for Added Protection?

MetaMask’s launch announcement states that the feature has no additional MetaMask fee. Ordinary blockchain gas rules still apply.

Why does Added Protection use EIP-7702?

EIP-7702 provides smart-account capabilities for an existing externally owned account. MetaMask can use that execution layer to enforce the expected transaction outcome.

Can I turn Added Protection off?

MetaMask says it can be disabled in the confirmation screen. Doing so removes the added execution guarantee, so verify the reason and risk before proceeding.

Does Added Protection revoke old token approvals?

No. Existing allowances remain active until they expire, are consumed or are revoked according to the token contract.

Does it protect a stolen Secret Recovery Phrase?

No. Anyone with the recovery phrase or private key can control the account. Move assets to a wallet created with uncompromised credentials.

How do I know whether my transaction is protected?

Check the current MetaMask confirmation interface, extension version, account and network. Do not assume support solely because another account or chain displayed the feature.

Final security checklist

  • Added Protection is available and enabled for this account and network.
  • The domain, recipient and contract are independently verified.
  • The preview matches the action you intended to perform.
  • Outgoing assets and approval amounts are acceptable.
  • Slippage, minimum return, deadline and network fee are understood.
  • No website or support agent asked for recovery words.
  • You understand that a rejected transaction may still spend gas.
  • You will not disable protection only because a site demands it.
  • Unused permissions will be reviewed after the interaction.

Official sources

Visit MetaMask ↗Official website