Чи можна довіряти симуляції транзакції в MetaMask?

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

Симуляція допомагає помітити не той токен, неочікувану суму або списання, якого ви не планували. Проте вона лише прогнозує результат: симуляція не перевіряє безпеку контракту й не гарантує, що в блоці все відбудеться так само. Стан мережі може змінитися, шкідливий контракт може навмисно поводитися безпечно під час симуляції, а під час деяких підписів або дозволів баланс узагалі не змінюється. Тому одного погляду на Estimated changes недостатньо: потрібно розуміти, що показує цей блок і що ще перевірити перед підтвердженням.

Що показує симуляція транзакції в 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, якщо під час симуляції та реального виконання ці значення відрізняються.
• За даними блока. Номер блока й час його створення постійно змінюються, тому контракт може використати їх як умову для іншої поведінки.

У реальних фішингових контрактах автори побачили всі три принципи: зміну стану контракту, перевірку 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. Якщо є ознаки, що приватний ключ або сід-фраза потрапили до сторонніх, відкликання дозволів проблему не вирішить: кошти потрібно перевести на новий гаманець із новою резервною копією.

Якщо апаратний гаманець у вас новий, перед першими великими переказами пройдіть наш чек-лист перших 30 хвилин з апаратним гаманцем: там окремо розібрані перевірка пристрою, резервна копія та тестова транзакція.

Чи можна довіряти симуляції MetaMask?

Симуляція транзакції в MetaMask корисна перед підтвердженням: Estimated changes показує очікуваний рух активів і часто допомагає помітити помилку ще до підпису. Однак цей блок не підтверджує, що контракт безпечний і що результат у мережі обов’язково буде таким самим. Під час red pill-атаки контракт може поводитися по-різному в симуляції та в реальному блоці, а approve, Permit або Permit2 можуть дати право на майбутнє списання без помітної зміни балансу в момент підтвердження.

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