Перевірка смарт-контракту токена перед підписом: чек-лист із 8 кроків

Коротко (TL;DR)

Перевірити смарт-контракт токена — це два різні завдання, і зазвичай роблять лише перше. Перше: подивитися на сам контракт (хто ним керує, чи можна додрукувати монети, чи можна заблокувати вашу адресу). Друге: прочитати те, що гаманець просить підписати просто зараз. Гроші частіше зникають на другому.

• Verified source не дорівнює «безпечно». Позначка означає лише те, що опублікований код збігається з байткодом у мережі. Про права власника вона не говорить нічого — а у найбільших токенів збіг узагалі частковий.
• Proxy обнуляє будь-яку перевірку коду. Власник апгрейду змінює логіку після того, як ви все передивилися. Автоматичні сканери за proxy не заглядають: по USDC ми отримали порожні значення одразу за сімома полями.
• Набір «небезпечних функцій» із типових чек-листів позначає USDT як скам. У нього є і додрук, і чорний список, і пауза, і змінна комісія. Сама собою функція не вирок — важить те, хто нею володіє і що про це сказано публічно.
• Найнебезпечніший запит — той, що не коштує газу. Підпис permit виглядає як «підтвердьте вхід», комісії не бере і в симуляцію транзакції не потрапляє. За звітом Scam Sniffer за 2025 рік на Permit і Permit2 припало 38% суми крадіжок понад мільйон доларів.
• Половина інструментів зі старих добірок мертва. bscheck.eu переадресовує на соцмережу, Wallet Guard закритий 31 березня 2025 року, Harpie — 27 березня 2025 року, Stelo — ще у 2023-му. Дані про живість сервісів — станом на 15 серпня 2026 року.

Нижче — чек-лист повністю, з чесною межею на кожному кроці: що він ловить і чого не ловить.

Транзакція і підпис: чому небезпечніший той, що не коштує газу

Гаманець показує два принципово різні типи вікна, і зовні вони схожі.

Транзакція — це запис, який піде в мережу. За неї платять комісію, її видно в експлорері, її можна змоделювати заздалегідь. Купівля токена, надсилання монет, виклик функції контракту — усе це транзакції.

Підпис повідомлення — це криптографічний автограф під шматком даних. У блокчейн він не потрапляє, газу не коштує і в історії гаманця не відображається. Саме тому такі вікна мають невинний вигляд: комісії немає, кнопки «надіслати» немає, натомість часто є слово на кшталт «Verify» або «Sign in».

Ігри з виводом грошей: скільки виходить за годину і що дійде до картки

Play to earn: звідки гра бере гроші на виплати і чому їх перестає вистачати

Крипторинок 10–16 серпня: $16,3 млрд у біткоїн-ETF і продажі Strategy у збиток

SafePal розкрив витік 39 798 клієнтів: дірка в плагіні жила понад рік

Децентралізовані соціальні мережі: 3,3 млн акаунтів Farcaster і 40–60 тис. активних

Різниця в тому, що підпис може бути готовим дозволом на виведення ваших токенів. Його кладуть у кишеню і пред’являють контракту тоді, коли захочуть. Ви вже закрили вкладку й забули про сайт, а папір із вашим автографом лежить і чекає.

За річним звітом Scam Sniffer за 2025 рік загальні втрати від фішингу підписів упали до $83,85 млн проти $494 млн роком раніше, кількість постраждалих — до 106 106 проти 332 000. Падіння вшестеро має вигляд перемоги, але структура великих крадіжок говорить інше: серед випадків дорожчих за мільйон доларів на підписи Permit і Permit2 припало $8,72 млн у трьох епізодах — 38% суми цих великих крадіжок. Найбільша одинична крадіжка року — $6,50 млн у stETH і aEthWBTC у вересні, теж через Permit. Вектор не зник, він звузився до найдорожчих гаманців.

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

Verified source в Etherscan: що позначка доводить, а що ні

Перше, що радять усі статті на цю тему, — відкрити контракт в експлорері й переконатися, що код верифіковано. Порада слушна, але її зазвичай розуміють неправильно.

Верифікація вихідників — це звірка: експлорер наново компілює надісланий код і порівнює результат із байткодом, який реально працює в мережі. Усе, що доводить зелена позначка, — «опублікований код відповідає запущеному». Ані аудиту, ані перевірки логіки, ані оцінки намірів розробника за нею немає.

Далі починається деталь, про яку не пише ніхто з топу видачі. Збіг буває двох видів. Повний (full match) — сходиться і байткод, і хеш метаданих: тоді, як формулює документація ethereum.org, ми впевнені, що це рівно той вихідник, «не відрізняється жодного байта». Частковий (partial match) — сходиться лише байткод. І там же пряме застереження: за часткового збігу «можливо вставити шкідливий код, який не відобразиться у верифікованому вихіднику».

Наскільки це теорія? Ми запросили розбір контракту USDT через API експлорера Blockscout 15 серпня 2026 року. Відповідь: is_verified: true, is_fully_verified: false. Тобто у найпоширенішого стейблкоїна мережі верифікація неповна. У USDC — та сама картина, і у proxy, і в контракті реалізації.

Що це означає на практиці: позначка verified — це дозвіл читати код, а не висновок про його безпеку. Відсутність позначки, навпаки, вирок майже остаточний: якщо розробник не опублікував вихідник, перевіряти немає чого й далі йти немає сенсу.

Що перевірка ловить: підміну — коли на сайті проєкту показано один код, а працює інший. Чого не ловить: злого наміру в самому коді, прав власника, змін після апгрейду.

Що таке смарт-контракт і чому його код неможливо тихо підмінити, ми розбирали в окремому матеріалі про смартконтракти — якщо базова механіка не очевидна, почніть із нього.

Proxy-контракт: чому USDC не знаходиться за стандартним слотом

Proxy — це контракт-пустишка, який сам нічого не обчислює, а переадресовує всі виклики на другий контракт із логікою. Сенс у тому, що адресу другого контракту можна змінити. Токен лишається за тією самою адресою, баланс нікуди не дівається, а правила роботи стають іншими.

Для перевірки це ключовий момент. Ви прочитали код, переконалися, що додруку немає, — а власник proxy викликав upgradeTo, і в новій версії додрук з’явився. Ваша перевірка стала історичним документом.

Стандарт ERC-1967 задає три фіксовані комірки сховища, де proxy зобов’язаний тримати службові адреси: реалізація (implementation), адміністратор (admin) і маяк (beacon). Адреса слота обчислюється як keccak256('eip1967.proxy.implementation') - 1, для реалізації це 0x360894a1…2bbc, для адміна — 0xb5312768…6103. Прочитати комірку можна безпосередньо, викликом eth_getStorageAt у будь-якої публічної ноди.

Тут ми натрапили на знахідку, заради якої варто перевіряти руками. Читаємо стандартний слот реалізації у USDC 15 серпня 2026 року — отримуємо нуль. За цією перевіркою USDC не proxy. Але USDC — proxy, і один із найвідоміших: контракт називається FiatTokenProxy, а логіка живе у FiatTokenV2_2 за адресою 0x43506849…02dd. Просто слоти у нього старі, з часів ZeppelinOS: адреса адміна лежить у 0x10d6a54a…390b, адреса реалізації — у 0x7050c9e0…f8c3. Адресу реалізації ми отримали двома незалежними шляхами — прямим читанням комірки через публічну ноду і розбором контракту в Blockscout, — і значення збіглися. Адресу адміна прочитано окремим запитом до іншої ноди; експлорер її не віддає взагалі, і це саме собою показово: найважливішу для власника токенів адресу доводиться діставати руками.

Практичний висновок простий. Не перевіряйте proxy одним способом:

1. Відкрийте контракт в експлорері й подивіться, чи є вкладка «Read as Proxy» або позначка про тип proxy.
2. Прочитайте стандартний слот ERC-1967 — нуль ще нічого не доводить.
3. Подивіться перелік функцій контракту: upgradeTo, upgradeToAndCall, changeAdmin, admin, implementation — це підпис proxy, хоч би як він зберігав адреси.
4. З’ясуйте, хто такий адмін. Якщо це звичайна адреса з одним підписом, а не мультипідпис чи таймлок, апгрейд забирає одну транзакцію і відбувається без попередження.

Що перевірка ловить: сам факт, що контракт оновлюваний, і того, хто це може зробити. Чого не ловить: намірів адміна і того, що буде в наступній версії коду.

Небезпечні функції: mint, blacklist, pause і змінний податок

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

Ось що справді варто шукати в коді токена і що кожна функція означає.

А тепер замір, який перевертає звичний чек-лист. Ми прогнали USDT через автоматичну перевірку GoPlus 15 серпня 2026 року й отримали: додрук є, чорний список є, пауза є, комісія змінна, а власник може змінювати баланс власника токенів. За переліком вище це п’ять прапорців із восьми — і це найбільший стейблкоїн із 16 065 176 адресами власників.

Розбір ABI через Blockscout підтверджує це порядково: у контракті TetherToken є issue, pause, unpause, addBlackList, removeBlackList, setParams і destroyBlackFunds. Тобто емітент справді може додрукувати монети, зупинити мережу переказів, внести адресу до чорного списку і знищити її баланс.

Для порівняння ми взяли SHIB — контракт без власника: додрук, чорний список, пауза і змінна комісія повернулися нулями, адреса власника порожня, власників токена 1 683 370, у пулу ліквідності 236 тримачів LP-токенів. Перевірка не позначає небезпечним усе поспіль; вона чесно відображає те, що записано в коді.

Звідси правило, якого немає в чужих чек-листах: небезпечна функція — це питання «хто нею володіє», а не сигнал «це скам». У Tether права емітента описані публічно, є юридична особа й репутаційні витрати. У безіменного мемкоїна тижневої давності ті самі права означають, що одна анонімна адреса може обнулити вашу позицію, і спитати буде ні з кого.

Owner не renounced: чим це загрожує і коли це норма

Окремий міф, який варто розібрати, — renounce ownership. Розробник викликає renounceOwnership(), адреса власника стає нульовою, і на скріншотах у чатах це подають як доказ чесності.

Що відбувається насправді: власник втрачає доступ до функцій, захищених модифікатором onlyOwner. Не до всіх адміністративних функцій контракту, а саме до цих. І це не завжди хороша новина.

• Renounce не скасовує proxy. Якщо апгрейдом керує окрема роль адміна proxy, а не власник токена, відмова від володіння не змінює нічого — логіку й далі можна замінити цілком.
• Renounce не скасовує прав інших ролей. У контрактах на основі AccessControl буває по п’ять ролей: MINTER_ROLE, PAUSER_ROLE, BLACKLISTER_ROLE. Відмова від owner їх не чіпає.
• Renounce можна інсценувати. Автоматичні перевірки окремо шукають прапорець «володіння можна повернути» і «прихований власник» — тобто код, де нульова адреса показується назовні, а фактичний контроль лишається.
• Renounce ламає аварійний рубильник. Якщо в контракті знайшли помилку, а pause більше нікому викликати, гроші витечуть до кінця.

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

Honeypot: як переконатися, що токен вдасться продати

Honeypot — токен, який можна купити, але не можна продати. Механік кілька: продаж дозволено лише адресам із білого списку, усі інші потрапляють до чорного після першої купівлі, або податок на продаж виставлено на рівні 99%, і продаж технічно проходить, але грошей не приносить.

Перевіряють це не читанням коду, а симуляцією: сервіс робить пробну купівлю і пробний продаж на форку мережі й дивиться, що вийшло.

Ось результат такої симуляції на реальному контракті. Ми звернулися до API honeypot.is по контракту USDT 15 серпня 2026 року й отримали: isHoneypot: false, податок на купівлю 0, на продаж 0, на переказ 0, газ на купівлю 182 037, на продаж 138 025, вихідники відкриті, proxy немає, власників 15 733 850, пара торгується на Uniswap V3 з ліквідністю близько $79,8 млн.

Зверніть увагу на розбіжність: той самий показник власників у GoPlus — 16 065 176, різниця близько двох відсотків. Це нормально, різні індексатори визначають кількість адрес по-різному. Але якщо в чужій статті вам називають таке число без дати і джерела, знайте, що це оцінка, а не факт.

Порядок дій щодо honeypot:

1. Прогнати адресу контракту через сервіс симуляції і подивитися податки на купівлю та продаж окремо.
2. Перевірити, що податок на продаж не вищий за податок на купівлю в рази — це класична пастка.
3. Переконатися, що комісію не можна змінити після розгортання (прапорець змінної ставки).
4. Подивитися, чи є в історії пари реальні продажі від різних адрес, а не лише купівлі.

Що перевірка ловить: неможливість продати просто зараз і поточні податки. Чого не ловить: майбутнього. Сам сервіс пише про це прямо: «Це не безвідмовний метод. Те, що токен не honeypot зараз, не означає, що він ним не стане».

approve, permit і Permit2: що йде в кожному запиті

Далі — найдорожча частина чек-листа. Три механізми видачі прав на ваші токени виглядають у гаманці по-різному, а результат дають один: чужа адреса отримує можливість забрати монети.

approve — звичайна транзакція. Ви платите газ, у мережі з’являється запис: адреса X може витрачати N ваших токенів. Часто N підставляється як максимально можливе число — це і є «unlimited approve». Дозвіл живе, доки ви його не знімете.

permit — той самий дозвіл, але виданий підписом, без транзакції і без газу. Стандарт ERC-2612 описує функцію permit(owner, spender, value, deadline, v, r, s), а підписується структура з п’яти полів: власник, отримувач прав, сума, лічильник підписів і термін придатності. Ключова небезпека в тому, що підпис існує офчейн: мережа про нього не знає, доки хтось не пред’явить його контракту.

Permit2 — окремий контракт Uniswap, який, за офіційною документацією, об’єднує два механізми: AllowanceTransfer (дозвіл із сумою і строком) та SignatureTransfer (разовий переказ за підписом, оминаючи дозвіл узагалі). Щоб ним користуватися, спершу видають звичайний approve самому контракту Permit2, зазвичай необмежений. Після цього всі подальші права роздаються підписами.

Що дивитися у вікні підпису, незалежно від механізму:

• Поле spender або to. Це адреса, яка отримає права. Якщо сайт називається одним іменем, а адреса не має до нього стосунку і створена вчора — закривайте.
• Поле value або amount. Число на кшталт 115792089237316195423570985008687907853269984665640564039457584007913129639935 — це і є unlimited. Ставте рівно ту суму, яку збираєтеся витратити.
• Поле deadline. Строк у п’ять хвилин — робочий сценарій обміну. Строк на десять років уперед — заготовка на майбутнє.
• Домен підпису. У структурі EIP-712 є блок з іменем контракту, версією, ідентифікатором мережі й адресою контракту-перевіряльника. Якщо мережа в підписі не та, у якій ви працюєте, це вже привід зупинитися.

Окрема деталь про EIP-7702: цей стандарт дозволяє звичайній адресі отримати виконуваний код, і делегування при цьому зберігається у стані акаунта, доки його не замінить нова авторизація. У 2025 році він став новим рядком у статистиці крадіжок — $2,54 млн у двох випадках за серпень. Специфікація в розділі про безпеку визнає проблему прямим текстом: безпечного інтерфейсу, у якому застосунок просить підписати таку авторизацію, не існує, а зазначений у ній код отримує необмежений доступ до акаунта.

eth_sign, personal_sign і signTypedData: як розрізнити в гаманці

Жоден матеріал з української та російськомовної видачі за нашою темою не пояснює, чим ці три запити відрізняються. А відрізняються вони принципово — рівнем того, що ви фізично здатні прочитати.

Розберемо, чому eth_sign небезпечніший за інші. Він підписує довільний хеш — тобто тим самим автографом можна підписати і транзакцію. Документація MetaMask формулює це без пом’якшень: метод «дозволяє підписувати довільний хеш, а отже, ним можна підписати транзакцію або будь-які інші дані», що робить його «небезпечним фішинговим ризиком». Метод позначений як застарілий і за замовчуванням вимкнений.

personal_sign додає до даних текстовий префікс, через який підпис уже не можна видати за транзакцію. Це стандартний спосіб авторизації на сайтах: ви бачите звичайний текст і розумієте, що підтверджуєте.

eth_signTypedData_v4 реалізує EIP-712 — типізовані дані. Мотивацію стандарту сформульовано прямо: до нього повідомлення для підпису були «непрозорим шістнадцятковим рядком без контексту». Саме цей метод використовується і для permit, і для Permit2. Хороша новина — ви бачите поля. Погана — читабельність означає лише те, що дані показані; розуміти сенс полів усе одно доводиться самому.

Практичний орієнтир: якщо гаманець показує суцільний hex — не підписуйте взагалі. Сучасний протокол не потребує підпису сирого хеша.

Механіку того, як один підпис спустошує гаманець із ключем на пристрої, ми розбирали в матеріалі про гарячий гаманець.

Симуляція транзакції: що показують MetaMask, Rabby і Tenderly

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

MetaMask робить це разом із Blockaid. Схема підкреслено приватна: запит іде на сервер MetaMask, а не безпосередньо сторонньому вендору. За небезпечної операції гаманець показує попередження про те, що запит оманливий. Спочатку функція працювала лише в основній мережі Ethereum, згодом перелік мереж розширився.

Rabby проганяє операцію через власний механізм правил. В офіційному анонсі гаманця це сформульовано так: «Rabby надсилає кожну транзакцію в механізм безпеки на перевірку до того, як ви її підпишете», і окремо — що гаманець «показує розрахункову зміну балансу до підпису». Серед прикладів правил у тому самому анонсі: контракт, який уже атакували, і адреса отримувача, якої в мережі не існує.

Tenderly — інструмент розробника, а не розширення. Він дозволяє прогнати довільний виклик на форку і подивитися трасування цілком. Для разового розбору підозрілої транзакції підходить, для щоденного захисту — ні.

І головне обмеження, якого не називає ніхто. Симуляція показує транзакцію. Офчейн-підпис транзакцією не є. Коли сайт просить вас підписати permit, у мережу нічого не йде — симулювати нічого. Частина гаманців навчилася розбирати типізовані дані і попереджати окремо, але це вже інший механізм, а не симуляція. Висновок: там, де симуляція найкорисніша, її якраз може не бути.

Інструменти перевірки токена: що ловить кожен і чого не ловить

Окрема біда чужих добірок — їх не перевіряють на живість. Нижче — стан на 15 серпня 2026 року, кожен сервіс перевірено зверненням, а не за чужим списком.

Останні чотири рядки — не прискіпливість, а ілюстрація. Сервіс bscheck.eu досі стоїть у рекомендаціях і матеріалу з топу видачі, і найбільшої української статті на цю тему. Фактично домен відповідає постійною переадресацією на акаунт у соцмережі, а захищеним протоколом не відповідає взагалі.

Решта закрилися по-різному, але однаково повчально. Stelo залучила $6 млн під лідом a16z і зупинилася 31 жовтня 2023 року, маючи 1500 активних користувачів на день. Harpie підняла $4,5 млн від Dragonfly, Coinbase Ventures та OpenSea і закрилася 27 березня 2025 року з формулюванням команди про те, що побудувати сталу бізнес-модель навколо захисту від крадіжок не вдалося. Wallet Guard купила Consensys, а 31 березня 2025 року розширення, дашборд і MetaMask Snap вимкнули — функції переїхали всередину самого гаманця. Fire і Pocket Universe скупив Kerberus: другу угоду закрили 21 серпня 2025 року разом із базою на 200 000 користувачів.

Практичний висновок: не прив’язуйтеся до одного розширення. Перевірте, що сервіс живий, просто перед використанням — на це йде десять секунд.

Ще один шар захисту — гігієна самого гаманця: розділення адрес, окрема адреса під експерименти, регулярний аудит. Про це у нас є окремий розбір щодо безпеки криптогаманця.

Чек-лист перед підписом: вісім кроків по порядку

Збираємо все в послідовність. Перші п’ять кроків роблять один раз на токен, останні три — щоразу перед підтвердженням.

1. Узяти адресу контракту з першоджерела — з офіційного сайту проєкту, з його документації або з картки на великому агрегаторі. Не з чату, не з пошуку, не з рекламного оголошення. Близько 30 секунд.
2. Відкрити контракт в експлорері й перевірити верифікацію. Немає вихідника — далі не йдемо. Є — дивимося, повний збіг чи частковий. Близько 30 секунд.
3. Визначити, чи це proxy. Вкладка proxy в експлорері, слот ERC-1967, наявність upgradeTo і changeAdmin у переліку функцій. Якщо proxy — з’ясувати, хто адмін. Близько хвилини.
4. Прогнати адресу через автоматичну перевірку. Відзначити для себе додрук, чорний список, паузу, змінну комісію. Пам’ятати, що порожнє поле означає «не перевірено», а не «безпечно». Близько 20 секунд.
5. Перевірити можливість продажу симуляцією. Податок на продаж і податок на купівлю — окремо. Близько 20 секунд.
6. Прочитати тип запиту у вікні підпису. Суцільний hex — відмова. Читабельний текст — авторизація на сайті, зазвичай безпечно. Поля з назвами — розбираємо далі. Близько 10 секунд.
7. Звірити три поля: отримувач прав, сума, строк. Незнайома адреса, необмежена сума або далекий строк — привід не підписувати. Близько 20 секунд.
8. Подивитися на результат симуляції, якщо вона є. Іде більше, ніж ви розраховували, — відмова. Близько 10 секунд.

Разом близько трьох хвилин на перший контакт із токеном і менше хвилини на кожен наступний підпис. Для порівняння: якщо поділити загальні втрати 2025 року на кількість постраждалих, у середньому на кожного припадає близько $790 — ціна трьох хвилин уваги виявляється помітно нижчою.

Межі перевірки: ризики, які чек-лист не знімає

Чесний розділ, без якого чек-лист перетворюється на хибне відчуття безпеки.

• Апгрейд після перевірки. Усе, що ви подивилися в коді, чинне до наступного виклику upgradeTo. У USDC адреса реалізації живе в окремій комірці і змінюється рішенням адміна — жодного повідомлення власникам токенів при цьому не передбачено.
• Підписаний permit майже не скасовується. Revoke.cash формулює своє обмеження прямо: платформа «ніколи не може визначити, які підписи ви поставили», і все, що показано у вкладці підписів, — лише потенційні дозволи. Скасувати підпис до його активації теоретично можна, але, як пише той самий сервіс, «на практиці це дуже важко, оскільки шахраї намагаються активувати дозвіл якнайшвидше».
• Симулятор не бачить офчейн-підпис. Найнебезпечніший клас запитів проходить повз найнадійніший інструмент.
• Підміна адреси в буфері. Ви перевірили правильний контракт, а вставили в гаманець інший. Проти цього працює лише звірка перших і останніх символів адреси перед кожною операцією.
• Апаратний гаманець не скасовує сліпого підтвердження. Пристрій захищає ключ від крадіжки з комп’ютера, але якщо ви підтверджуєте на ньому нечитабельні дані, він чесно підпише шкідливу операцію. Різниця між пристроями тут якраз у тому, наскільки детально вони показують вміст запиту — на це варто дивитися, коли обираєте пристрій, наприклад в огляді апаратного гаманця Ledger Nano X.
• Інструмент може зникнути. Чотири сервіси з типових добірок мертві; ваша схема перевірки не має триматися на одному розширенні.

Перевірка до підпису і відкликання approvals — це різні завдання

Їх постійно плутають, а розв’язують вони протилежні проблеми.

Обидва завдання потрібні, але замінити одне одного не можуть. Відкликання — це прибирання після того, як ви вже щось роздали; воно не допоможе, якщо дозвіл видано підписом і його встигли пред’явити. Перевірка перед підписом — це те, що відбувається до, і саме вона вирішує, чи потрапить новий дозвіл до вашого переліку взагалі.

Як знайти і зняти все, що вже видано, ми докладно розбирали в гайді про сплячі approvals. Логіка проста: спершу перестаємо видавати зайве, потім прибираємо накопичене.

FAQ

Чи можна довіряти токену, якщо контракт verified в Etherscan?

Ні. Верифікація доводить лише одне: опублікований вихідник збігається з байткодом, який працює в мережі. Вона нічого не говорить про права власника, про наявність додруку чи чорного списку. У USDT і USDC збіг узагалі частковий, а не повний. Відсутність верифікації — майже напевно привід не зв’язуватися; її наявність — лише дозвіл читати код далі.

Як скасувати підпис permit, якщо я вже його поставив?

Швидко й надійно — майже ніяк. Підпис існує поза блокчейном, і сервіси відкликання його не бачать: Revoke.cash прямо пише, що показує лише потенційні підписи. Теоретично можна витратити той самий лічильник підписів іншою операцією і тим самим обнулити старий, але зловмисники активують дозвіл у перші хвилини. Якщо сума велика — швидше переказати активи на іншу адресу.

Чому гаманець просить підпис без комісії — це безпечно?

Відсутність комісії не гарантує нічого. Газ не беруть тому, що запис у блокчейн не створюється, а не тому, що операція нешкідлива. Саме так працюють permit і Permit2: підпис безкоштовний для вас, а дозвіл на виведення токенів він дає повноцінний. За статистикою 2025 року на такі підписи припало 38% суми крадіжок дорожчих за мільйон доларів.

Що робити, якщо сканер показує «немає даних» щодо функцій токена?

Вважати це попередженням, а не зеленим світлом. У документації GoPlus прямо сказано: одиниця означає «так», нуль — «ні», відсутність значення — «невідомо». Найчастіше порожнеча виникає у proxy-контрактів: автоматичний розбір не заглядає за переадресацію. Ми отримали порожніми одразу сім полів по USDC, хоча всі ці функції в контракті реалізації є. Перевіряйте такий токен руками.

Чи обов’язково давати approve на unlimited, якщо так пропонує сайт?

Ні, суму майже завжди можна відредагувати просто у вікні гаманця. Необмежений дозвіл потрібен інтерфейсу для зручності: не доведеться підтверджувати знову за наступної угоди. Плата за цю зручність — відкритий доступ до вашого балансу цього токена на невизначений строк. Розумний компроміс: ставити суму угоди плюс невеликий запас.

Чи врятує апаратний гаманець від шкідливого підпису?

Лише частково. Пристрій захищає приватний ключ: він не покидає чип, і шкідлива програма на комп’ютері його не вкраде. Але якщо ви підтверджуєте на екрані пристрою дані, яких не розумієте, він підпише їх так само слухняно, як будь-яку іншу операцію. Дивіться на те, наскільки детально пристрій показує вміст запиту, і не підтверджуйте нечитабельне.