Можно ли доверять симуляции транзакции в MetaMask?

Когда dApp — сайт или приложение, подключённое к кошельку, — отправляет запрос в MetaMask, кошелёк открывает окно подтверждения. Симуляция транзакции в MetaMask ещё до подписи показывает, как операция может изменить ваш баланс: например, «+1 240 USDC» и «-0,5 ETH». Это прогноз, рассчитанный по текущему состоянию сети.

Симуляция помогает заметить не тот токен, неожиданную сумму или списание, которого вы не планировали. Но она только прогнозирует результат: симуляция не проверяет безопасность контракта и не гарантирует, что в блоке всё произойдёт точно так же. Состояние сети может измениться, вредоносный контракт может специально вести себя безопасно во время симуляции, а некоторые подписи и разрешения вообще не меняют баланс в момент подтверждения. Поэтому одного взгляда на Estimated changes недостаточно: нужно понимать, что показывает этот блок и что ещё проверить перед Confirm.

Что показывает симуляция транзакции в MetaMask перед подписью

В справке MetaMask эта функция называется estimated balance changes, а в окне подтверждения отображается блок Estimated changes. MetaMask заранее рассчитывает ожидаемое движение активов до отправки транзакции в сеть.

Чтобы правильно читать этот блок, учитывайте две вещи:

• Расчёт выполняется на сервере MetaMask. Во время симуляции могут передаваться данные транзакции и/или IP-адрес. В расширении переключатель Estimated balance changes находится в Settings → Privacy, а в мобильном приложении — в Settings → Security & Privacy. Если отключить Estimated balance changes, «Added protection» тоже перестанет работать.
• Estimated changes в первую очередь показывает движение активов. В этом блоке можно увидеть изменения баланса ERC-20, перемещение NFT стандартов ERC-721 и ERC-1155, а также ETH или другую нативную монету сети. Но он не объясняет всё, что может сделать смарт-контракт.

Стандартные симуляции включены по умолчанию, но MetaMask прямо предупреждает: результат симуляции может отличаться от результата в блоке. Между проверкой и реальным выполнением состояние сети может измениться.

Почему прогноз может не совпасть с результатом

Симуляция видит сеть такой, какой она была в момент проверки. До включения транзакции в блок могут пройти секунды или минуты. За это время другой пользователь может совершить своп в том же пуле, цена изменится, ликвидность уменьшится или обновится состояние самого контракта.

На свопах это заметнее всего: MetaMask может показать одну сумму на выходе, а в блоке вы получите немного другую — в пределах заданного проскальзывания (slippage). Симуляция не может «заморозить» цену или ликвидность до момента выполнения транзакции.

Есть и другая причина расхождения: контракт можно написать так, чтобы во время симуляции он вёл себя безопасно, а при реальном выполнении запускал другую логику.

Когда контракт намеренно обманывает симуляцию

MetaMask называет такой сценарий red pill attack. Вредоносный контракт пытается определить, выполняется ли сейчас только симуляция. Если да, он показывает безопасный результат; когда та же транзакция попадает в реальный блок, контракт переходит к другой ветке кода.

В исследовании «Blockchain Transaction Simulation Phishing», опубликованном в июле 2026 года, авторы разделили такие атаки на шесть технических типов. Для пользователя важны три основных признака, по которым контракт может отличить симуляцию от реального выполнения:

• Состояние контракта. После симуляции злоумышленник меняет данные в своём или связанном контракте, и тот начинает вести себя иначе.
• Параметры gas. Контракт может реагировать на доступный gas или его цену, если во время симуляции и реального выполнения эти значения отличаются.
• Данные блока. Номер блока и время его создания постоянно меняются, поэтому контракт может использовать их как условие для другой логики.

В реальных фишинговых контрактах авторы встретили все три принципа: изменение состояния контракта, проверку gas и привязку ко времени блока. Остальные варианты они воспроизвели экспериментально. Зелёный «плюс» в Estimated changes означает только то, что симуляция увидела выгодный результат. Безопасность самого контракта он не подтверждает.

Сколько потеряли пользователи

Чтобы найти такие контракты в сети, авторы создали инструмент SimGuard и проверили Ethereum, BNB Smart Chain, Avalanche и Polygon. За период с августа 2024 по июнь 2025 года они зафиксировали:

• 4 224 фишинговых контракта: Avalanche — 3 136, Ethereum — 480, Polygon — 315, BNB Smart Chain — 293;
• 5 742 адреса жертв и 6 223 транзакции с потерями;
• около $3,48 млн потерь по оценке авторов, из них $3,19 млн — в Ethereum;
• более 143,4 ETH — крупнейшая потеря в одной транзакции.

Больше всего было контрактов, которые ориентировались на gas, но на них пришлось лишь около 6% потерь в выборке. Основную сумму собрали 16 контрактов, состояние которых злоумышленник мог менять уже после симуляции: примерно $2,97 млн, или более 85% всех потерь.

Один из таких случаев команда Scam Sniffer описала ещё в январе 2025 года. Сайт предлагал получить якобы положенную пользователю награду через функцию Claim, а симуляция показывала выгодный результат. После проверки злоумышленник менял состояние контракта, поэтому в реальной транзакции срабатывала уже другая логика. В результате с адреса вывели более 143 ETH. Этот кейс важен именно для темы симуляций: вредоносная операция выглядела безопасной в тот момент, когда пользователь решал, подтверждать её или нет.

Исследователи также проверили 11 популярных кошельков, среди них MetaMask, Rabby и Phantom. Большинство показывали вводящий в заблуждение или неточный результат. В одном из тестов MetaMask показывал небольшой плюс к балансу, хотя транзакция отправляла 0,5 ETH в фишинговый контракт и возвращала всего 1 wei — минимальную единицу ETH.

Когда баланс не меняется, но вы уже даёте разрешение

Не каждый запрос сразу переводит токены. Иногда сначала вы даёте право на будущее списание, а средства остаются на месте. В таком подтверждении проверяйте само разрешение: кому оно выдаётся, на какую сумму и как долго будет действовать.

Permit и Permit2: подпись может дать право на будущую операцию

В Permit по EIP-2612 и Permit2 вы подписываете сообщение вместо отдельной approve-транзакции. В момент подписи средства не двигаются. В зависимости от типа запроса эту подпись позже можно использовать, чтобы создать разрешение на списание или перевести токены.

MetaMask уже распознаёт часть таких Permit-запросов и может показывать в подтверждении данные о разрешении и сумме. Это полезно, но такой экран не показывает, когда именно подпись используют в будущем. Если подпись попала к злоумышленнику и ещё действует, списание может произойти позже. Разницу между approve, Permit, Permit2 и WalletConnect мы подробно разбирали в материале «Approve, Permit и WalletConnect: как разрешения могут привести к краже токенов».

Permit-запросы обычно оформлены как структурированная подпись EIP-712, поэтому MetaMask может показать отдельные поля в более понятном виде. Дополнительно работают Security Alerts — предупреждения MetaMask о подозрительных запросах. Для Ethereum и других EVM-сетей проверка проходит через серверы MetaMask, а для других поддерживаемых сетей используется сервис Blockaid. Эти проверки помогают заметить известные угрозы, но не гарантируют, что опасная подпись будет обнаружена. Даже после предупреждения пользователь может продолжить и подтвердить запрос.

Approve: разрешение на будущее списание

approve — это ончейн-транзакция, которая задаёт лимит разрешения (allowance): сколько токенов определённый адрес или контракт сможет списать позже. В технических полях такой получатель разрешения называется spender. Во время самого approve токены не переводятся, поэтому проверяйте, кому вы даёте доступ и на какую сумму.

На экране разрешения MetaMask показывает поле spending cap, где вы задаёте лимит. Проверяйте кому даёте разрешение и какую сумму позволяете потратить. Если лимит заметно выше необходимого, адрес или контракт с таким разрешением сможет списать больше токенов — вплоть до всего доступного баланса, пока разрешение действует.

Как работает «Added protection»

Обычная симуляция только показывает прогноз. «Added protection» добавляет проверку уже во время выполнения транзакции: если результат в сети не соответствует защищённой симуляции, транзакция завершается с ошибкой (revert), а изменения не применяются. То есть если контракт попытается выполнить другую операцию, проверка должна остановить транзакцию. Сетевую комиссию (gas) за неудачную операцию всё равно придётся заплатить.

У этого режима есть несколько ограничений:

• «Added protection» появляется не для каждого запроса. MetaMask показывает переключатель только там, где эта проверка поддерживается. Если его нет в окне подтверждения, для этой операции режим недоступен.
• Поддержка зависит от сети. По состоянию на сентябрь 2026 года ончейн-проверка симуляции доступна в 15 сетях: Ethereum, Optimism, BNB, Polygon, Monad, HyperEVM, Sei, Tempo, MegaETH, Robinhood, Arc, Base, Arbitrum, Avalanche и Linea.
• Комиссия может быть выше. Ончейн-проверка требует больше gas, хотя отдельную плату за эту функцию MetaMask не берёт.
• Начиная с версии 13.48.0, переключатель не всегда включён по умолчанию. Если внутренняя проверка MetaMask не видит явных признаков риска, «Added protection» стартует выключенным. Если система показывает предупреждение или считает запрос вредоносным, защита остаётся включённой.

Что даёт аппаратный кошелёк

Симуляцию, предупреждения MetaMask и данные dApp вы видите на компьютере. Если сайт или интерфейс скомпрометирован, на экране могут показать одни данные, а на подпись передать другие. У аппаратного кошелька есть отдельный экран, на котором можно проверить то, что действительно поступило на устройство для подписи.

Хороший пример — взлом Bybit 21 февраля 2025 года. Биржа использовала Safe{Wallet} — мультиподписной кошелёк, где операцию должны подтвердить несколько подписантов. По данным расследования Sygnia, всё началось с компрометации рабочей станции разработчика Safe. После этого злоумышленники внедрили вредоносный JavaScript в веб-интерфейс: подписанты видели ожидаемую операцию, но в запрос на подпись подставлялись другие данные. В результате из одного холодного кошелька Bybit вывели активы примерно на $1,46 млрд, включая 401 347 ETH.

После такой подмены данные в браузере уже не могут быть единственным ориентиром: интерфейс способен показывать не ту операцию, которая ушла на подпись. Аппаратный кошелёк даёт отдельный экран для проверки, но сложный вызов смарт-контракта и на нём может оставаться непонятным. Одного адреса контракта и нескольких технических полей иногда недостаточно, чтобы оценить последствия подписи. EIP-712 структурирует сообщение, но сам по себе не объясняет пользователю смысл вложенной операции.

Для обычного перевода проверяйте на устройстве адрес получателя, сумму и сеть. Если браузер и аппаратный кошелёк показывают разные данные, запрос нужно отклонить. При работе со смарт-контрактом смотрите ещё и на само действие и его параметры. Если устройство показывает только длинную шестнадцатеричную строку (hex) или непонятные поля, вы не видите, что именно подтверждаете.

ERC-7730 задаёт формат JSON-описания контракта. По нему кошелёк может превратить технические данные вызова — в том числе calldata (закодированные параметры вызова) или сообщение EIP-712 — в понятное описание действия и его параметров. По состоянию на сентябрь 2026 года ERC-7730 всё ещё имеет статус Draft.

12 мая 2026 года Ethereum Foundation объявила, что присоединяется к нейтральному управлению реестром Clear Signing. ERC-7730 v2 также добавил поддержку кроссчейн-сценариев и программных кошельков.

Clear signing помогает только тогда, когда для конкретного контракта есть корректное описание и кошелёк правильно его применяет. Для нового или неизвестного контракта такого описания может не быть. Понятное отображение на экране заметно снижает риск ошибки, но домен, контракт и само действие всё равно нужно проверять.

Если вы только выбираете устройство для работы с DeFi, мы отдельно сравнили актуальные модели и подходы к проверке подписи в гайде «Какой аппаратный кошелек выбрать в 2026 году».

Что проверить перед подтверждением

Перед подтверждением сначала определите, какой запрос показывает MetaMask и что он позволяет сделать. Обычный перевод, approve и Permit работают по-разному и по-разному отображаются в кошельке, поэтому проверять их нужно тоже по-разному.

В MetaMask:

1. Разберитесь, что просит dApp. Это перевод, approve или подпись сообщения? Для Permit и Permit2 проверьте токен, сумму, адрес или контракт, который получает право на списание (spender), и срок действия разрешения. Названия полей могут отличаться, но смысл проверки именно такой.
2. Просмотрите Estimated changes целиком. Сверьте актив, направление и сумму. Если видите списание, которого не ожидали, или незнакомый токен, не подтверждайте операцию, пока не разберётесь, откуда они взялись.
3. Если есть «Added protection», проверьте, включён ли он. MetaMask рекомендует использовать этот режим при работе с новыми или незнакомыми dApp, сложными транзакциями и значительными суммами. Начиная с версии 13.48.0 для запросов без явных признаков риска переключатель может быть выключен по умолчанию.
4. В approve проверьте, кому даёте разрешение, и spending cap. Слишком большой лимит позволит списать намного больше токенов, чем нужно для текущей операции, хотя во время самого approve баланс не меняется.

На аппаратном кошельке:

1. Для перевода сверьте весь адрес, сумму и сеть. Проверять только начало и конец адреса недостаточно: при атаке с отравлением истории адресов (address poisoning) злоумышленник специально подсовывает похожий адрес, который легко перепутать при быстрой проверке.
2. Для смарт-контракта смотрите на действие и параметры. Один адрес контракта не объясняет, что именно разрешит сделать транзакция.
3. Не подтверждайте непонятный запрос. Если вместо ожидаемого действия устройство показывает длинную шестнадцатеричную строку (hex), поле data без понятного пояснения или другие незнакомые параметры, сначала выясните, что именно вам предлагают подписать.

Если данные в MetaMask и на аппаратном кошельке не совпадают, отклоните запрос, проверьте домен и контракт и выясните, откуда он пришёл. Если вы уже выдали слишком широкое или подозрительное разрешение либо подписали сомнительный Permit2, проверьте активные разрешения и при необходимости отзовите их через revoke.cash. Если есть признаки, что приватный ключ или seed-фраза попали к постороннему, отзыв разрешений проблему не решит: средства нужно перевести на новый кошелёк с новой резервной копией.

Если аппаратный кошелёк у вас новый, перед первым крупным переводом пройдите наш чек-лист первых 30 минут с аппаратным кошельком: там отдельно разобраны проверка устройства, резервная копия и тестовая транзакция.

Можно ли доверять симуляции MetaMask?

Симуляция транзакции в MetaMask полезна перед подтверждением: Estimated changes показывает ожидаемое движение активов и часто помогает заметить ошибку ещё до подписи. Однако этот блок не подтверждает, что контракт безопасен и что результат в сети обязательно будет таким же. При red pill-атаке контракт может вести себя по-разному в симуляции и в реальном блоке, а approve, Permit или Permit2 могут дать право на будущее списание без заметного изменения баланса в момент подтверждения.

«Added protection» добавляет ончейн-проверку для поддерживаемых транзакций, а аппаратный кошелёк даёт отдельный экран для сверки данных. Перед подтверждением проверьте, какое действие вы разрешаете, куда могут уйти средства, кто получит право их списывать и в каких пределах.