Approve, Permit и WalletConnect: как разрешения могут привести к краже токенов

Approve, Permit и WalletConnect — привычные для DeFi механизмы, с помощью которых пользователь может дать контракту право работать со своими активами. Защита криптовалют обычно начинается с seed-фразы: её хранят офлайн, не вводят на сторонних сайтах и никому не передают. Но этого недостаточно, если владелец кошелька сам подтвердит разрешение или подпись, не проверив их содержание.

Approve, Permit, Permit2, WalletConnect и делегации EIP-7702 работают по-разному, но во всех этих сценариях решающим часто становится один момент: пользователь видит знакомую кнопку Confirm или Sign и подтверждает запрос, не разобравшись в его содержании. Приватные ключи при этом могут оставаться в безопасности, хотя выданное разрешение уже позволяет списать токены.

В статье разберём то, что действительно нужно знать перед подтверждением запроса: как работают approve и Permit, чем опасен Unlimited approval, почему Disconnect не заменяет Revoke, какую роль играет WalletConnect и что изменил EIP-7702. Отдельно рассмотрим проверку активных разрешений и порядок действий после подозрительной подписи.

Approve, Permit и WalletConnect: где возникает риск

Само по себе открытие сайта не даёт смарт-контракту права списывать ваши ERC-20 токены. Для этого обычно нужен заранее выданный allowance — разрешение определённому адресу или контракту потратить до указанной суммы через transferFrom.

Без этого механизма не работали бы обычные swap, стейкинг и лендинг. При первой операции с новым токеном dApp часто сначала запрашивает approve, а уже затем выполняет сам swap, поэтому перед подтверждением стоит проверить кому выдаётся разрешение, на какую сумму и на какой срок.

По данным Scam Sniffer, в 2024 году дрейнеры похитили около $494 млн с 332 тысяч адресов, а в крупных инцидентах заметная доля потерь приходилась на вредоносные Permit-подписи. В 2025 году сумма таких краж существенно снизилась, однако сам способ атаки остался актуальным: получить от владельца нужную подпись часто проще, чем завладеть его приватным ключом.

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

Как выглядит типичная атака через разрешение

Типичная атака выглядит вполне обычно: пользователь переходит на фейковый airdrop, mint или копию знакомого DeFi-сервиса, подключает кошелёк и получает запрос, который выглядит логичным продолжением действия на странице — Claim, Continue, Verify или Sign.

За такой кнопкой может скрываться approve на адрес злоумышленника, Permit на крупную сумму или другое разрешение. Риск возникает в момент подтверждения конкретного запроса: после подписи выданным правом можно воспользоваться без нового подтверждения с вашей стороны.

Какие подписи вы видите в кошельке

Кнопка Sign может относиться к совершенно разным действиям: входу на сайт, структурированному Permit или подписи raw hash, содержание которого кошелёк почти не объясняет. Поэтому полезно различать хотя бы самые распространённые форматы.

eth_sign: подпись без понятного контекста

eth_sign подписывает сырое 32-байтное значение, которое пользователь не может содержательно проверить в обычном интерфейсе. Именно из-за отсутствия понятного контекста этот метод считается опасным для повседневной работы с dApp, а современные кошельки часто ограничивают его или прячут за отдельными настройками.

Если сайт просит отдельно включить eth_sign, чтобы продолжить работу, лучше не подтверждать запрос. Современные DeFi-сервисы обычно используют форматы, в которых кошелёк может показать больше информации о действии.

personal_sign: часто используется для входа

personal_sign часто используют для авторизации или подтверждения владения адресом. Такая подпись не является обычной Ethereum-транзакцией, однако её содержание всё равно нужно читать: сервис может использовать подписанное сообщение как подтверждение определённого действия в собственном протоколе.

EIP-712: структурированная подпись

EIP-712 позволяет кошельку показывать структурированные поля вместо нечитаемого набора hex-данных — например, spender, сумму, deadline, сеть и контракт. Этот формат используют Permit и многие сценарии Permit2.

Структурированный формат упрощает проверку, однако безопасность зависит от значений внутри него. Если spender указывает на адрес злоумышленника, а value позволяет списать чрезмерную сумму, понятное отображение поможет заметить риск только в том случае, если пользователь действительно проверит эти поля.

Approve: классическое разрешение ERC-20

Функция approve(spender, amount) записывает в контракте токена, какую сумму может потратить указанный spender. Во время самого approve токены остаются на вашем балансе; движение средств начинается только тогда, когда получатель разрешения вызывает transferFrom.

Почему Unlimited approval создаёт проблему

Чтобы не запрашивать approve перед каждой операцией, dApp нередко устанавливают очень большой или фактически неограниченный allowance. Это сокращает количество подтверждений при следующих swap, но одновременно оставляет контракту широкое право на списание, которое может действовать годами.

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

Для NFT похожую роль выполняет setApprovalForAll, который даёт оператору право управлять всеми NFT определённой коллекции от вашего имени. На фейковых mint- и claim-сайтах такой запрос могут выдавать за обычный шаг для получения NFT, хотя объём разрешения значительно шире.

Permit: когда разрешение выдаётся через подпись

Обычный approve требует on-chain транзакции и оплаты gas. EIP-2612 Permit позволяет сначала подписать сообщение офчейн, после чего сервис, релеер или другая сторона передаёт эту подпись в контракт токена.

Сообщение содержит, в частности, owner, spender, value, deadline и nonce. Проверив подпись, контракт создаёт allowance без отдельной approve-транзакции, поэтому процесс получается быстрее и не требует gas от пользователя на этапе подписания. Из-за этого Permit легко принять за обычное сообщение, хотя его результатом может стать полноценное разрешение на списание.

В момент подписания Permit может не оставить ни одной транзакции в истории кошелька. Валидную подпись можно отправить в сеть позже, пока не истёк deadline и соответствующий nonce ещё не использован.

В марте 2026 года публично разбирали случай, когда после вредоносной Permit-подписи из кошелька вывели около $1,76 млн в USDC. По данным GoPlus, устройство пользователя было скомпрометировано, что позволило злоумышленникам подменить запрос и получить валидную подпись; уязвимости самого Permit в этом случае не было.

Отсутствие нового allowance в block explorer не исключает риск: пока Permit-подпись не отправлена on-chain, обычный список approvals её не покажет.

Что даёт domain separator

Domain separator в EIP-712 привязывает Permit к конкретной сети и контракту, снижая риск повторного использования той же подписи в другом контексте. При этом он не проверяет, правильно ли вы выбрали spender: подпись, намеренно или по ошибке выданная опасному адресу, останется технически корректной.

Permit2: одна система разрешений для разных токенов

Не все ERC-20 токены поддерживают EIP-2612, поэтому Uniswap создал Permit2 как отдельный универсальный слой разрешений. Пользователь сначала выдаёт контракту Permit2 базовый on-chain approve, а затем может предоставлять отдельным dApp разрешения через подписи.

При проверке Permit2 нужно смотреть на два уровня: базовый approve токена на контракт Permit2 и разрешения, которые через него получили отдельные приложения. Отзыв одного из таких разрешений не обязательно убирает базовый allowance.

Структурированные Permit2-подписи могут содержать немало технических полей, поэтому их проще подтвердить механически, не проверив, кому выдано разрешение и в каком объёме. На этом и строятся фишинговые сценарии, замаскированные под знакомый DeFi-интерфейс.

WalletConnect: подключение без прямого доступа к токенам

WalletConnect иногда ошибочно воспринимают как отдельное разрешение на работу с активами. Его роль другая: протокол соединяет кошелёк с dApp и передаёт между ними запросы, а подключение через QR-код или deep link само по себе не создаёт allowance на токены.

После установки сессии dApp может отправить approve, Permit, транзакцию или запрос на подпись сообщения. Каждый такой запрос кошелёк показывает отдельно, поэтому решающим становится содержание запроса, который пользователь подтверждает.

Когда об инциденте говорят «украли через WalletConnect», причиной часто оказывается вредоносный запрос, переданный через открытую сессию и подтверждённый пользователем; сам протокол WalletConnect при этом не был скомпрометирован.

Почему старые сессии лучше закрывать

Закрытие вкладки браузера не обязательно завершает WalletConnect-сессию, поэтому старое подключение может оставаться активным и дальше принимать запросы от dApp. Ненужные и незнакомые сессии лучше периодически закрывать, даже если сами по себе они не создают никаких on-chain разрешений.

Disconnect завершает WalletConnect-сессию с dApp, тогда как Revoke изменяет или отменяет on-chain allowance. Если контракт ранее получил Unlimited approval, отключение WalletConnect-сессии на это разрешение не повлияет.

Что остаётся после Disconnect

После Disconnect dApp исчезает из списка активных сессий, но ранее выданный approve продолжает действовать, поскольку allowance хранится on-chain в контракте токена. Закрытие вкладки, очистка cookies или отключение сайта эту запись не меняют.

Revoke разрешения тоже не обязательно завершает WalletConnect-сессию. Поэтому после работы с ненужным сервисом стоит отдельно проверить и активные подключения, и on-chain approvals.

EIP-7702: новый риск после Pectra

EIP-7702 заработал в Ethereum вместе с обновлением Pectra 7 мая 2025 года. Стандарт позволяет EOA-адресу делегировать выполнение логики другому контракту, сохраняя тот же адрес, благодаря чему становятся возможны batching, оплата gas третьей стороной, ограничения расходов и другие функции smart account.

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

После Pectra EIP-7702 быстро начали использовать и дрейнеры: в отчётах за 2025 год описаны крупные потери после вредоносных batch-подписей, а исследователи также фиксировали sweeper-контракты, которые применяли 7702 на адресах с уже скомпрометированными ключами.

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

Незнакомая smart-account или EIP-7702 делегация требует проверки: выясните, какому контракту передано выполнение и когда это произошло. Неизвестная делегация сама по себе ещё не говорит об утечке seed-фразы, однако оставлять её без проверки не стоит.

Как проверить и отозвать разрешения

Для Approve, Permit и WalletConnect нет одной общей кнопки проверки: on-chain approvals смотрят в сервисах управления разрешениями или block explorer, а WalletConnect-сессии — непосредственно в кошельке. Для ERC-20 и NFT удобно использовать, например, revoke.cash, где видны активные разрешения и контракты, которым они выданы.

• ERC-20 approve. Проверьте Unlimited и крупные allowance, особенно если они выданы старым или уже ненужным контрактам.
• NFT-разрешения. Проверьте setApprovalForAll, если пользовались mint-сайтами, маркетплейсами или другими NFT-dApp.
• Permit2. Проверьте базовый approve для Permit2 и отдельные разрешения, выданные через него приложениям.
• WalletConnect. Завершите старые и ненужные сессии отдельно от проверки on-chain разрешений.

Отзыв on-chain разрешения — отдельная транзакция, для которой нужен gas, поэтому отменять каждый approval сразу после использования не всегда разумно. Вместо этого стоит периодически просматривать список и убирать разрешения, которые больше не нужны, особенно после экспериментов с новыми DeFi-сервисами, mint или airdrop.

С Permit ситуация другая: подписанное офчейн сообщение не появится среди on-chain approvals, пока его не используют. Если есть основания считать, что такая подпись попала к злоумышленнику, не стоит ждать появления новой записи в explorer, прежде чем защищать активы.

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

Что проверить перед подписью

Перед Confirm проверьте несколько полей, которые определяют реальный объём разрешения.

• Проверьте домен. Открывайте DeFi-сервисы из закладок или официальных источников и не полагайтесь на рекламные объявления или случайные ссылки.
• Сверьте spender и контракт. Если адрес вам незнаком, проверьте его по официальной документации сервиса или в block explorer.
• Проверьте amount и deadline. Unlimited или непропорционально долгий срок действия для одноразовой операции требуют дополнительной проверки.
• Не подписывайте нечитаемые данные. Если кошелёк показывает только набор hex-данных без понятного описания действия, полноценно проверить содержание подписи вы фактически не можете.
• Отделяйте основные средства от экспериментов. Для новых dApp, mint и airdrop лучше использовать отдельный кошелёк с небольшой суммой.
• Сверяйте данные на экране аппаратного кошелька. Перед подписью ориентируйтесь на информацию, которую показывает само устройство, и сопоставляйте её с действием на сайте.

Что делать, если вы уже подписали подозрительный запрос

Если вы только что подтвердили подозрительный approve, Permit или EIP-7702 делегацию и не уверены в её содержании, исходите из того, что выданное разрешение уже могут использовать. Сначала защитите активы, а детали инцидента выясняйте после этого.

1. Переведите ценные активы на безопасный адрес. Это особенно актуально для подозрительного офчейн Permit, который уже мог попасть к злоумышленнику.
2. Отзовите подозрительные on-chain approvals. Проверьте ERC-20 approve, NFT setApprovalForAll и разрешения Permit2.
3. Проверьте EIP-7702 и smart-account делегации. Незнакомую делегацию отмените; если одновременно есть признаки утечки приватного ключа, переведите средства на новый кошелёк со свежими ключами.
4. Завершите WalletConnect-сессии и прекратите любое взаимодействие с подозрительным сайтом.

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

Итог

Approve, Permit и WalletConnect, а также Permit2 и EIP-7702 выполняют разные функции. Approve создаёт allowance для токена, Permit позволяет выдать такое разрешение через офчейн-подпись, Permit2 централизует управление разрешениями, WalletConnect передаёт запросы между dApp и кошельком, а EIP-7702 позволяет EOA делегировать выполнение логики смарт-контракта.

Перед подписью проверяйте spender, сумму, срок действия и контракт, даже если сайт вам знаком и запрос выглядит привычно. Основные средства лучше не использовать для тестирования новых dApp, а старые approvals — периодически просматривать и отзывать, когда они больше не нужны.

Аппаратный кошелёк защищает приватные ключи, однако содержание запроса перед Confirm всё равно нужно проверять самостоятельно. Поэтому даже при надёжном хранении ключа важно контролировать, какие полномочия вы предоставляете контрактам.