Проверка смарт-контракта токена перед подписью: чек-лист из 8 шагов

33 мин. чтения

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

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

  • Verified source не равно «безопасно». Значок означает только, что опубликованный код совпадает с байт-кодом в сети. Он ничего не говорит про права владельца — и у крупнейших токенов совпадение вообще частичное.
  • Прокси обнуляет любую проверку кода. Владелец апгрейда меняет логику после того, как вы всё посмотрели. Автоматические сканеры за прокси не заглядывают: по 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».

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

По годовому отчёту 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 — та же картина, и у прокси, и у контракта реализации.

Что это значит на практике: галочка verified — это разрешение читать код, а не заключение о его безопасности. Отсутствие галочки, наоборот, приговор почти окончательный: если разработчик не опубликовал исходник, проверять нечего и дальше идти незачем.

Что проверка ловит: подмену — когда на сайте проекта показан один код, а работает другой. Чего не ловит: злого умысла в самом коде, прав владельца, изменений после апгрейда.

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

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

Прокси — это контракт-пустышка, который сам ничего не считает, а переадресует все вызовы на второй контракт с логикой. Смысл в том, что адрес второго контракта можно поменять. Токен остаётся по тому же адресу, баланс никуда не девается, а правила работы становятся другими.

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

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

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

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

  1. Откройте контракт в эксплорере и посмотрите, есть ли вкладка «Read as Proxy» или пометка о типе прокси.
  2. Прочитайте стандартный слот ERC-1967 — ноль ещё ничего не доказывает.
  3. Посмотрите список функций контракта: upgradeTo, upgradeToAndCall, changeAdmin, admin, implementation — это подпись прокси, как бы он ни хранил адреса.
  4. Найдите, кто такой админ. Если это обычный адрес с одной подписью, а не мультиподпись или таймлок, апгрейд занимает одну транзакцию и происходит без предупреждения.

Что проверка ловит: сам факт, что контракт апгрейдится, и того, кто это может сделать. Чего не ловит: намерений админа и того, что будет в следующей версии кода.

Опасные функции: mint, blacklist, pause и изменяемый налог

Типовой список «красных флагов» кочует из статьи в статью почти без изменений. Проблема в том, что подаётся он как приговор, а работает как термометр: показывает температуру, но не ставит диагноз.

Вот что реально стоит искать в коде токена и что каждая функция означает.

Функция в кодеЧто она позволяет владельцуКогда это норма
mint, issue, configureMinterВыпустить новые токены и размыть долю держателейРегулируемый стейблкоин: эмитент обязан печатать монеты под поступившие доллары
blacklist, addBlackList, isBlacklistedЗапретить конкретному адресу отправлять токеныТот же стейблкоин: адреса под санкциями блокируются по требованию регулятора
pause, unpauseОстановить все переводы разомАварийный рубильник на случай найденной уязвимости
setFee, setParams, setTaxRateИзменить комиссию за перевод или продажуПочти никогда; в честных проектах ставка либо ноль, либо жёстко ограничена в коде
transferOwnership, ownerПередать управление другому адресуПереезд на мультиподпись или таймлок
destroyBlackFundsСписать баланс заблокированного адресаКрайне редко; у USDT такая функция есть
selfdestructУничтожить контрактНе норма ни в одном случае для токена
upgradeTo, upgradeToAndCallПолностью заменить логикуПрокси-архитектура с прозрачным управлением

А теперь замер, который переворачивает привычный чек-лист. Мы прогнали 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 не отменяет прокси. Если апгрейд управляется отдельной ролью админа прокси, а не владельцем токена, отказ от владения ничего не меняет — логику по-прежнему можно заменить целиком.
  • 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, исходники открыты, прокси нет, держателей 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, обычно неограниченный. После этого все дальнейшие права раздаются подписями.

Что подписываетеСтоит ли газаВидно ли в эксплорере сразуЧто уходитКак отменить
approveДаДаПраво тратить N токенов до отзываТранзакция с суммой 0
permit (ERC-2612)НетНет, пока не предъявятТо же право, но выданное офчейнПрактически никак — нужно успеть сжечь nonce
Permit2 AllowanceTransferНетНетПраво с суммой и сроком истеченияОтозвать в интерфейсе Permit2
Permit2 SignatureTransferНетНетРазовый перевод конкретной суммыПрактически никак
Авторизация EIP-7702НетНетПраво исполнять код от имени вашего адресаНовой авторизацией

Что смотреть в окне подписи, независимо от механизма:

  • Поле spender или to. Это адрес, который получит права. Если сайт называется одним именем, а адрес не имеет к нему отношения и создан вчера — закрывайте.
  • Поле value или amount. Число вида 115792089237316195423570985008687907853269984665640564039457584007913129639935 — это и есть unlimited. Ставьте ровно ту сумму, которую собираетесь потратить.
  • Поле deadline. Срок в пять минут — рабочий сценарий обмена. Срок на десять лет вперёд — заготовка на будущее.
  • Домен подписи. В структуре EIP-712 есть блок с именем контракта, версией, идентификатором сети и адресом контракта-проверяющего. Если сеть в подписи не та, в которой вы работаете, это уже повод остановиться.

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

eth_sign, personal_sign и signTypedData: как различить в кошельке

Ни один материал из русской и украинской выдачи по нашей теме не объясняет, чем эти три запроса отличаются. А отличаются они принципиально — уровнем того, что вы физически способны прочитать.

МетодЧто подписываетсяЧто видит пользовательСтатус
eth_signПроизвольный хеш, в том числе хеш транзакцииСтроку из шестнадцатеричных символовУстарел, в MetaMask выключен по умолчанию
personal_signТекст с защитным префиксомЧитаемый текст, если он в UTF-8Работает, годится для входа на сайт
eth_signTypedData_v4Структуру с полями и типами по EIP-712Поля с названиями и значениямиРекомендованный вариант

Разберём, почему 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 года, каждый сервис проверен обращением, а не по чужому списку.

ИнструментЧто реально даётЧего не ловитСостояние на 15.08.2026
Etherscan / BscScanИсходник, ABI, историю, держателей, вкладку проксиЛогику кода, намерения владельцаРаботает
BlockscoutТо же плюс явный флаг полноты верификации и тип проксиТо жеРаботает, открытый API
GoPlus Token SecurityДвадцать с лишним флагов: mint, blacklist, pause, налоги, honeypotЗа прокси возвращает «неизвестно», а не предупреждениеРаботает, бесплатный API
honeypot.isСимуляцию покупки и продажи, реальные налогиИзменения контракта после проверкиРаботает: Ethereum, BNB Chain, Base
Token SnifferБалльную оценку и типовые проверкиПрокси, запрос на подписьРаботает, автоматическим запросам отвечает отказом
De.Fi ScannerНабор детекторов по контрактуТо жеСайт отвечает, интерфейс целиком на JavaScript
Revoke.cashСписок выданных разрешений и их отзывПодписи, которые вы поставили, — сервис их не видит в принципеРаботает
Kerberus / Pocket UniverseБлокировку известных фишинговых сайтов и симуляциюНовые домены до попадания в базуРаботает под брендом Kerberus
bscheck.euМёртв: домен редиректит на соцсеть
Wallet GuardЗакрыт 31.03.2025, функции перенесены в MetaMask
HarpieЗакрыт 27.03.2025
SteloЗакрыт 31.10.2023

Последние четыре строки — не придирка, а иллюстрация. Сервис 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. Определить, прокси ли это. Вкладка прокси в эксплорере, слот ERC-1967, наличие upgradeTo и changeAdmin в списке функций. Если прокси — выяснить, кто админ. Около минуты.
  4. Прогнать адрес через автоматическую проверку. Отметить для себя допечатку, чёрный список, паузу, изменяемую комиссию. Помнить, что пустое поле означает «не проверено», а не «безопасно». Около 20 секунд.
  5. Проверить продаваемость симуляцией. Налог на продажу и налог на покупку — по отдельности. Около 20 секунд.
  6. Прочитать тип запроса в окне подписи. Сплошной hex — отказ. Читаемый текст — авторизация на сайте, обычно безопасно. Поля с названиями — разбираем дальше. Около 10 секунд.
  7. Сверить три поля: получатель прав, сумма, срок. Незнакомый адрес, неограниченная сумма или далёкий срок — повод не подписывать. Около 20 секунд.
  8. Посмотреть на результат симуляции, если она есть. Уходит больше, чем вы рассчитывали, — отказ. Около 10 секунд.

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

Пределы проверки: риски, которые чек-лист не снимает

Честный раздел, без которого чек-лист превращается в ложное чувство безопасности.

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

Проверка до подписи и отзыв approvals — это разные задачи

Их постоянно путают, а решают они противоположные проблемы.

Проверка перед подписьюОтзыв разрешений
КогдаДо подтвержденияПосле, иногда через год
Что защищаетДеньги, которые ещё у васДеньги от разрешений, выданных раньше
Стоит ли газаНетДа, каждый отзыв — транзакция
Работает ли на офчейн-подписиДа, это её основная задачаНет, подписанный permit отзыву не поддаётся
ПериодичностьКаждый разРаз в квартал, как ревизия

Обе задачи нужны, но заменить друг друга не могут. Отзыв — это уборка после того, как вы уже что-то раздали; он не поможет, если разрешение выдано подписью и его успели предъявить. Проверка перед подписью — это то, что происходит до, и именно она решает, попадёт ли новое разрешение в ваш список вообще.

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

FAQ

Можно ли доверять токену, если контракт verified на Etherscan?

Нет. Верификация доказывает только одно: опубликованный исходник совпадает с байт-кодом, который работает в сети. Она ничего не говорит о правах владельца, о наличии допечатки или чёрного списка. У USDT и USDC совпадение вообще частичное, а не полное. Отсутствие верификации — почти наверняка повод не связываться; её наличие — лишь разрешение читать код дальше.

Как отменить подпись permit, если я уже её поставил?

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

Почему кошелёк просит подпись без комиссии — это безопасно?

Отсутствие комиссии ничего не гарантирует. Газ не берётся потому, что запись в блокчейн не создаётся, а не потому, что операция безобидна. Именно так работают permit и Permit2: подпись бесплатна для вас, а разрешение на вывод токенов она даёт полноценное. По статистике 2025 года на такие подписи пришлось 38% суммы краж дороже миллиона долларов.

Что делать, если сканер показывает «нет данных» по функциям токена?

Считать это предупреждением, а не зелёным светом. В документации GoPlus прямо сказано: единица означает «да», ноль — «нет», отсутствие значения — «неизвестно». Чаще всего пустота возникает у прокси-контрактов: автоматический разбор не заглядывает за переадресацию. Мы получили пустыми сразу семь полей по USDC, хотя все эти функции в контракте реализации есть. Проверяйте такой токен руками.

Обязательно ли давать approve на unlimited, если так предлагает сайт?

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

Спасёт ли аппаратный кошелёк от вредной подписи?

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

Поделиться
Связаться:
Крипто- и data-аналитик, инженер-программист (факультет компьютерных наук ХНУРЭ). В IT с 2008 года: администрировал корпоративный мониторинг в «Vodafone Украина», семь лет разрабатывал и продвигал веб-проекты, пять лет руководил маркетингом на метриках — конверсия, CTR, ROI, LTV.Криптовалютными рынками занимаюсь с 2021 года: ончейн-метрики, токеномика, макроэкономические индикаторы. Разработал собственную data-driven модель анализа рынка на 30+ метрик. Стек — Python (pandas, NumPy, SciPy, matplotlib), математическая статистика и EDA; сбор и сверку данных автоматизирую AI-агентами.Принцип — «Don't trust, verify»: каждая цифра проверена по первоисточнику, ключевые — минимум по двум независимым; прогнозы — только сценарии с условиями. Тезис без данных не публикуется.