Как отозвать разрешения токенов в 2026 году: approve, Permit2, NFT и безопасность

Как отозвать разрешения токенов — значит изменить записанное в блокчейне полномочие, которое позволяет стороннему адресу или смарт-контракту перемещать активы от имени владельца. Такая операция нужна после работы с DEX, bridge, маркетплейсом NFT, staking- или lending-протоколом, а особенно после подключения кошелька к подозрительному сайту. Простого закрытия вкладки, выхода из WalletConnect или удаления приложения недостаточно: разрешение продолжает существовать в состоянии токена или специального контракта, пока не будет израсходовано, не истечёт по правилам конкретного механизма либо не будет отозвано on-chain.

Практическая сложность состоит в том, что словом «разрешение» называют разные конструкции. У ERC‑20 это allowance между owner и spender; у ERC‑721 — разрешение на конкретный NFT либо полномочие оператора на всю коллекцию; у ERC‑1155 — setApprovalForAll; у EIP‑2612 — подпись permit; у Permit2 — базовое одобрение самого Permit2 и отдельные лимиты приложениям; у TRC‑20 действует близкая к ERC‑20 модель; у Solana делегирование хранится в token account. Поэтому универсальная кнопка «отменить всё» может не увидеть часть рисков или показать их без достаточного контекста.

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

Материал построен как рабочий регламент. Сначала объясняется архитектура approvals, затем — классификация риска и инвентаризация, пошаговый отзыв в EVM-сетях, отдельная работа с Permit2 и NFT, действия после фишинга, особенности TRON и Solana, сложные случаи с proxy и vault, профилактика и документирование. Интерфейсы сервисов меняются, поэтому названия кнопок могут отличаться, но проверяемые on-chain-состояния остаются теми же.

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

Что именно отзывается и почему это важно

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

Разрешение ERC‑20 — это право spender использовать transferFrom

В классическом ERC‑20 владелец вызывает approve и записывает лимит для конкретного spender. После этого spender может вызывать transferFrom и перемещать токены в пределах оставшегося allowance, даже если владелец больше не открыт на сайте приложения. Проверять нужно тройку owner–token–spender, а не только название dApp. Один и тот же протокол может иметь несколько router, vault или proxy-адресов, а одинаковый spender в другой сети является отдельной записью.

Отзыв обычно устанавливает allowance в ноль. После подтверждения транзакции значение allowance(owner, spender) должно стать нулевым, а событие Approval — отражать новое значение. Запись считается обработанной только после того, как новое состояние подтверждено в нужной сети и сохранено вместе с transaction hash.

Spender — не обязательно сам сайт

Домен отвечает за интерфейс, но on-chain-полномочие получает адрес контракта. Легитимный сайт может направлять approve на router, Permit2, vault или proxy; фишинговый сайт способен запросить разрешение собственному контракту под знакомым логотипом. Если назначение spender нельзя объяснить через фактическую операцию и документацию, безопаснее отозвать разрешение и при необходимости выдать новое ограниченное полномочие позже.

Имя в approval checker является меткой индексатора, а не криптографическим доказательством. Сверяйте полный адрес, сеть, verified source, назначение контракта и официальный deployment из независимого источника. В спорной ситуации сначала ограничивают потенциальный ущерб, а затем восстанавливают удобство работы новым минимальным разрешением.

Disconnect и revoke решают разные задачи

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

Проверка должна включать две независимые процедуры: удалить неизвестные dApp-сессии в кошельке и отдельно просмотреть on-chain approvals во всех использованных сетях. После инцидента полезно сделать и то и другое. Только disconnect оставляет spender с прежним лимитом, а только revoke не прекращает фишинговую сессию, которая может продолжить показывать новые опасные подписи. Такой порядок защищает от двух противоположных ошибок: сохранения опасного доступа и бессмысленного отзыва разрешения, которое относится к другому активу или сценарию.

Нативная монета обычно не использует ERC‑20 allowance

ETH, BNB, MATIC, TRX, TON и SOL в нативной форме переводятся самой транзакцией и не требуют approve по модели ERC‑20. Поэтому approval checker токенов не показывает право списывать нативный баланс как обычный allowance. Это не означает, что нативная монета защищена от вредной подписи. Пользователь может подписать прямую отправку, вызов контракта с value, делегирование аккаунта или пакет операций, где нативный актив уходит немедленно. При расследовании разделяйте остаточные разрешения токенов и уже подписанные переводы. Revoke предотвращает будущие transferFrom, но не возвращает актив, который был отправлен в подтверждённой транзакции.

Практический контроль завершается сравнением исходного и итогового состояния. В журнале указывают owner, сеть, token contract, spender или operator, старое значение, новое значение и причину решения.

Почему разрешение может жить годами

Обычный ERC‑20 allowance не имеет срока действия, если токен не реализует дополнительную логику. Он сохраняется после закрытия сайта, смены браузера, переустановки кошелька и даже после полного расходования текущего баланса, если лимит был unlimited. Риск становится видимым позже: пользователь снова получает тот же токен, а старый spender всё ещё имеет право его переместить. Поэтому нулевой баланс сегодня не делает разрешение безопасным навсегда.

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

Какие виды approvals нужно различать

Классификация определяет максимальный ущерб и правильную функцию отзыва. Одинаковое слово approval может означать лимит суммы, право на один NFT, управление коллекцией или подпись с nonce и сроком.

Точный allowance ERC‑20

Точный лимит ограничивает сумму, которую spender может переместить. Если разрешено 100 USDT и 70 уже израсходовано, доступный остаток обычно равен 30 USDT, хотя особенности конкретного токена следует проверять по функции allowance. Такой лимит снижает максимальный ущерб, но не подтверждает добросовестность spender. Если контракт скомпрометирован до использования лимита, оставшаяся сумма всё равно доступна. После завершения разовой операции сравните allowance с нулём. Небольшой остаток не следует игнорировать: он может быть использован автоматически или накопиться при повторном пополнении кошелька.

Практический контроль завершается сравнением исходного и итогового состояния. В журнале указывают owner, сеть, token contract, spender или operator, старое значение, новое значение и причину решения.

Unlimited approval

Unlimited approval обычно записывает максимально возможное uint256-значение либо другое очень большое число, которое интерфейс показывает как «без ограничений». Это уменьшает число approve-транзакций, но переносит риск на весь будущий баланс токена. Оценивайте не только текущую стоимость, но и вероятные будущие поступления. Unlimited allowance на пустом адресе может стать критичным после перевода крупной суммы того же актива.

Для редко используемых протоколов разумнее exact approval. Если unlimited нужен для регулярной стратегии, используйте отдельный операционный кошелёк с ограниченным капиталом и контролируемым пополнением. Запись считается обработанной только после того, как новое состояние подтверждено в нужной сети и сохранено вместе с transaction hash.

ERC‑721 approve для одного NFT

ERC‑721 позволяет одобрить конкретный tokenId одному адресу. Такое разрешение обычно сбрасывается при передаче NFT, но до передачи approved-адрес может управлять именно этим объектом. Для отзыва конкретного разрешения используется установка approved address в нулевой адрес по логике контракта. После транзакции getApproved(tokenId) должен возвращать отсутствие approved-адреса.

Проверка должна показывать contract коллекции, tokenId и approved address. Название коллекции и картинка легко подделываются, поэтому ориентируйтесь на полный контракт и принадлежность NFT. В спорной ситуации сначала ограничивают потенциальный ущерб, а затем восстанавливают удобство работы новым минимальным разрешением.

ERC‑721 setApprovalForAll

setApprovalForAll предоставляет operator право управлять всеми NFT владельца в рамках конкретного контракта коллекции. Это шире, чем approve одного tokenId, и потому особенно опасно при поддельном marketplace.

Проверяйте owner, operator, адрес коллекции и булево значение. Разрешение одной коллекции не распространяется на все NFT в кошельке, но может охватывать каждый текущий и будущий NFT этой коллекции. Отзыв выполняется setApprovalForAll(operator, false). Затем isApprovedForAll(owner, operator) должен вернуть false, а событие ApprovalForAll — подтвердить изменение. Такой порядок защищает от двух противоположных ошибок: сохранения опасного доступа и бессмысленного отзыва разрешения, которое относится к другому активу или сценарию.

ERC‑1155 operator approval

ERC‑1155 объединяет множество tokenId в одном контракте и стандартно использует operator approval на весь набор активов владельца. Один operator способен управлять разными экземплярами и количествами внутри коллекции. Не делайте вывод по одному видимому NFT. Нужно проверить сам contract ERC‑1155 и isApprovedForAll для каждого подозрительного operator. Отзыв также устанавливает false. После него operator теряет стандартное полномочие перемещать активы этого контракта, но отдельная логика приложения или подписанный ордер может потребовать дополнительного анализа.

Практический контроль завершается сравнением исходного и итогового состояния. В журнале указывают owner, сеть, token contract, spender или operator, старое значение, новое значение и причину решения.

EIP‑2612 permit

Permit изменяет allowance по EIP‑712-подписи, поэтому пользователь может не видеть отдельной on-chain approve-транзакции от своего адреса. Relayer или приложение передаёт подпись в контракт, и разрешение появляется после исполнения permit. Важны owner, spender, value, nonce, deadline, chain ID и verifying contract. Подпись до исполнения может оставаться опасной, а после исполнения превращается в обычный allowance, который проверяют и отзывают в контракте токена.

Если подозрительная permit-подпись ещё не исполнена, простое отсутствие allowance не гарантирует безопасность. При высокой сумме рассматривают перенос активов, инвалидацию nonce по механике токена или срочную консультацию с техническим специалистом. Запись считается обработанной только после того, как новое состояние подтверждено в нужной сети и сохранено вместе с transaction hash.

Permit2: два уровня полномочий

Permit2 разделяет базовое одобрение ERC‑20 токена контракту Permit2 и дальнейшие полномочия конкретным приложениям. Пользователь может увидеть unlimited allowance к Permit2 и отдельные amount, expiration и nonce для spender внутри Permit2. После подозрительной подписи проверяйте оба уровня. Для полного прекращения доступа конкретному приложению отзывают его Permit2 allowance; для полного отказа токена от Permit2 дополнительно обнуляют обычный ERC‑20 allowance к Permit2.

Отзыв только внутреннего Permit2-разрешения оставляет базовый token→Permit2 allowance. Отзыв только базового allowance блокирует использование Permit2 для токена, но внутренние записи могут остаться видимыми. В спорной ситуации сначала ограничивают потенциальный ущерб, а затем восстанавливают удобство работы новым минимальным разрешением.

Proxy, router и vault

Протокол может использовать router для обменов, vault для хранения, staking contract для депозитов и proxy для обновляемой логики. Несколько разрешений одного бренда не обязательно являются дублями.

Сопоставляйте каждую запись с конкретной функцией: swap, deposit, repay, bridge, migration или marketplace. Особое внимание уделяйте upgradeable proxy, где адрес остаётся прежним, а implementation может измениться. Если вы больше не используете функцию, отзывайте связанный allowance. Для продолжающейся работы документируйте адрес, назначение, официальный источник и дату последней проверки. Такой порядок защищает от двух противоположных ошибок: сохранения опасного доступа и бессмысленного отзыва разрешения, которое относится к другому активу или сценарию.

Как провести инвентаризацию разрешений

Инвентаризация проводится до массовых транзакций. Без исходного снимка легко отозвать не ту запись, пропустить другую сеть или потерять доказательства инцидента.

Начните с полного списка адресов и сетей

Один seed может порождать несколько аккаунтов, а один 0x-адрес существовать в Ethereum, Arbitrum, Base, BNB Smart Chain, Polygon и других EVM-сетях. Approval в каждой сети независим.

Составьте таблицу: кошелёк, account, chain ID, нативный баланс для gas, основные токены, использованные dApp и дата последней активности. Не ограничивайтесь сетью, где сейчас виден самый большой баланс. Если кошелёк давно не используется, всё равно проверьте сети, куда когда-либо мостили или выводили активы. Старая approval-запись может стать опасной при будущем возвращении токена. Такой порядок защищает от двух противоположных ошибок: сохранения опасного доступа и бессмысленного отзыва разрешения, которое относится к другому активу или сценарию.

Проверяйте token contract, а не тикер

USDT, USDC, WETH и другие тикеры могут использоваться поддельными или мостовыми токенами. Approval относится к конкретному token contract в конкретной сети. Перед отзывом убедитесь, что выбрали правильный контракт и decimals. Ошибка обычно не крадёт актив, но приводит к отзыву не той записи и ложному ощущению безопасности. Официальный идентификатор берут из надёжного источника и сопоставляют с explorer. Логотип, символ и название в checker используются только как подсказка.

Практический контроль завершается сравнением исходного и итогового состояния. В журнале указывают owner, сеть, token contract, spender или operator, старое значение, новое значение и причину решения.

Определите spender и его роль

Полный адрес spender — главный объект анализа. Он может быть router, vault, bridge, marketplace, aggregator, Permit2, proxy или неизвестный EOA/contract. Откройте адрес в explorer, проверьте contract creation, verified source, proxy, labels, историю транзакций и связь с протоколом. Метка индексатора помогает, но не заменяет независимое подтверждение.

Неизвестный spender с unlimited allowance получает наивысший приоритет. Известный и активно используемый контракт оценивают по лимиту, типу актива, обновляемости и потребности бизнеса. Запись считается обработанной только после того, как новое состояние подтверждено в нужной сети и сохранено вместе с transaction hash.

Сравните allowance с балансом и будущими поступлениями

Текущий баланс показывает немедленный возможный ущерб, а allowance — верхнюю границу полномочия. Но будущие поступления могут увеличить фактический риск до лимита. Если актив используется как расчётный, зарплатный или treasury-токен, старое разрешение на пустом кошельке нельзя оставлять без контроля. Оно должно быть отозвано до следующего пополнения.

Разделите записи на четыре категории: allowance ноль; точный лимит меньше баланса; лимит больше баланса; unlimited. Для каждой отметьте, ожидаются ли новые поступления токена. В спорной ситуации сначала ограничивают потенциальный ущерб, а затем восстанавливают удобство работы новым минимальным разрешением.

Учитывайте время и экономический смысл

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

Сопоставьте transaction hash approve, последующие transferFrom, фактический результат сделки и последний контакт с протоколом. Если история не объясняется, разрешение рассматривают как избыточное. Для корпоративного кошелька экономический смысл фиксируют в реестре: владелец процесса, протокол, лимит, срок пересмотра и основание сохранения. Такой порядок защищает от двух противоположных ошибок: сохранения опасного доступа и бессмысленного отзыва разрешения, которое относится к другому активу или сценарию.

Отдельно проверьте approvals NFT

Checker ERC‑20 может не показывать ERC‑721 и ERC‑1155 operators. После взаимодействия с marketplace или mint-сайтом необходим отдельный обзор NFT approvals. Ищите approve конкретных tokenId и setApprovalForAll. Второй тип шире и часто используется маркетплейсами, но также является популярной целью фишинга. Если коллекция дорогая или редкая, анализируйте каждый contract и operator отдельно. Не подписывайте массовый revoke на неизвестном сайте без проверки calldata.

Практический контроль завершается сравнением исходного и итогового состояния. В журнале указывают owner, сеть, token contract, spender или operator, старое значение, новое значение и причину решения.

Проверьте Permit2 и подписи

Обычный token approval checker показывает базовое разрешение токена Permit2, но может не раскрывать все внутренние allowances и подписанные, ещё не исполненные сообщения. Откройте проверенный интерфейс, который показывает Permit2 owner–token–spender, amount, expiration и nonce. Сопоставьте адрес Permit2 и сеть с официальными deployment-данными.

Если вы не понимаете, зачем конкретному spender нужен доступ, отзовите внутреннее разрешение. После фишинговой EIP‑712-подписи действуйте быстрее, чем при обычной инвентаризации. Запись считается обработанной только после того, как новое состояние подтверждено в нужной сети и сохранено вместе с transaction hash.

Аппаратный кошелёк не отменяет approvals

Hardware signer защищает приватный ключ от извлечения, но подтверждённый approve всё равно записывается в блокчейн. Если пользователь одобрил вредный calldata или blind signing, spender получает полномочие независимо от места хранения ключа. После отзыва аппаратный кошелёк должен подписать on-chain-транзакцию. Никогда не вводите seed в revoke-сервис ради совместимости.

Проверяйте критические параметры на доверенном экране: адрес контракта, spender, amount и сеть. Если устройство показывает только hash или «contract data», используйте декодирование и симуляцию до подписи. В спорной ситуации сначала ограничивают потенциальный ущерб, а затем восстанавливают удобство работы новым минимальным разрешением.

Пошаговый отзыв в EVM-сетях

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

Подготовьте безопасную среду

Откройте официальный кошелёк и explorer из закладок или независимого источника, обновите приложение, отключите подозрительные расширения и убедитесь, что активен нужный account. Сохраните исходный список approvals до изменений: сеть, token, spender, amount, время и transaction hash. Это позволит доказать состояние и проверить, что все критические записи обработаны.

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

Откройте approval checker правильной сети

Используйте встроенный инструмент кошелька, официальный block explorer или проверенный сервис. Сначала убедитесь в домене и chain ID, затем подключите только публичный адрес или кошелёк без передачи seed.

Если сервис позволяет просматривать адрес без подключения, начните с read-only режима. Подключение нужно лишь для формирования и подписи revoke-транзакции. Список должен включать ERC‑20, ERC‑721 и ERC‑1155. Если один интерфейс не поддерживает нужный стандарт или сеть, используйте другой проверенный источник и сверяйте результаты. Такой порядок защищает от двух противоположных ошибок: сохранения опасного доступа и бессмысленного отзыва разрешения, которое относится к другому активу или сценарию.

Проверьте будущую транзакцию

Для ERC‑20 revoke обычно вызывает approve(spender, 0). В calldata должны совпасть token contract, spender и нулевое значение. Для NFT ожидается approve нулевому адресу для конкретного tokenId либо setApprovalForAll(operator, false). Любое иное действие требует объяснения. Проверьте gas, nonce и отсутствие дополнительных вызовов. Если интерфейс формирует multicall, декодируйте каждый элемент и убедитесь, что пакет не содержит transfer, permit или нового approve.

Практический контроль завершается сравнением исходного и итогового состояния. В журнале указывают owner, сеть, token contract, spender или operator, старое значение, новое значение и причину решения.

Подпишите revoke и дождитесь включения в блок

Отзыв является обычной on-chain-транзакцией и требует нативной монеты. Нажатие кнопки без подтверждённого receipt не меняет allowance. Сохраните transaction hash и откройте его в explorer. Статус должен быть success, а вызванная функция — соответствовать отзыву.

Если транзакция pending, не считайте разрешение закрытым. Следите за nonce и gas; при необходимости используйте безопасную замену с тем же nonce через кошелёк, а не неизвестный ускоритель. Запись считается обработанной только после того, как новое состояние подтверждено в нужной сети и сохранено вместе с transaction hash.

Проверьте новое состояние напрямую

После подтверждения заново запросите allowance(owner, spender) либо isApprovedForAll. Не полагайтесь только на всплывающее сообщение интерфейса. Сделайте снимок результата и отметьте запись в реестре. Если разрешение снова появилось, найдите новую транзакцию или подпись, которая его восстановила.

Explorer и второй checker должны показать ноль или false. Индексатор может обновляться с задержкой, поэтому при расхождении ориентируйтесь на чтение контракта в актуальном блоке. В спорной ситуации сначала ограничивают потенциальный ущерб, а затем восстанавливают удобство работы новым минимальным разрешением.

Отзывайте в порядке риска

При ограниченном газе сначала обрабатывают unknown spender с unlimited allowance на дорогой ликвидный токен, затем NFT operator approvals и Permit2-полномочия, после — небольшие или неактивные записи.

Сумма на кошельке, возможность будущего пополнения и скорость потенциального списания важнее возраста approval. Разрешение на стейблкоин обычно приоритетнее доступа к неликвидному dust-токену. Если подозрительный spender уже совершает transferFrom, обычный revoke может конкурировать с атакующей транзакцией. Тогда нужен аварийный план, а не последовательный ручной аудит. Такой порядок защищает от двух противоположных ошибок: сохранения опасного доступа и бессмысленного отзыва разрешения, которое относится к другому активу или сценарию.

Не используйте batch вслепую

Пакетный revoke экономит время, но увеличивает объём calldata и вероятность не заметить лишний вызов. Некоторые кошельки показывают только общий запрос без расшифровки каждого элемента. Для значимых активов лучше несколько понятных транзакций либо проверенный multicall с полной симуляцией. Убедитесь, что failure одного элемента не откатывает весь пакет неожиданным образом. После batch всё равно проверяют каждую запись. Успешный transaction status не гарантирует, что все внутренние операции выполнились, если контракт допускает частичное выполнение.

Практический контроль завершается сравнением исходного и итогового состояния. В журнале указывают owner, сеть, token contract, spender или operator, старое значение, новое значение и причину решения.

Оставьте минимальный резерв gas

Без ETH, BNB, POL или другой нативной монеты владелец не сможет быстро отозвать allowance. Это превращает небольшую экономию на остатке gas в операционный риск. Для hot-кошелька держите резерв, достаточный для нескольких emergency-транзакций при повышенной нагрузке сети. Точный размер зависит от chain и сложности вызова.

Не отправляйте gas с неизвестного сервиса, требующего seed или предварительный депозит. Пополнение должно идти с контролируемого адреса или проверенной биржи. Запись считается обработанной только после того, как новое состояние подтверждено в нужной сети и сохранено вместе с transaction hash.

Permit2, permit и подписи: отдельный порядок

Permit и Permit2 требуют отдельной проверки, потому что полномочие может появляться через подпись и существовать на нескольких уровнях. Здесь важны не только транзакции владельца, но и nonce, сроки и verifying contract.

Найдите базовое одобрение Permit2

ERC‑20 токен может иметь unlimited allowance на официальный Permit2 contract. Эта запись позволяет Permit2 работать с токеном, но сама по себе не указывает, какое приложение получит право использования. Проверьте token contract, Permit2 address и сеть. Поддельный контракт с похожим именем не является Permit2, даже если интерфейс показывает знакомый логотип.

Если вы больше не используете Permit2 для этого токена, обнулите обычный allowance token→Permit2. Это жёстко прекращает дальнейшие transferFrom через данный уровень. Запись считается обработанной только после того, как новое состояние подтверждено в нужной сети и сохранено вместе с transaction hash.

Проверьте внутренние AllowanceTransfer

Внутри Permit2 разрешение привязано к owner, token и spender и содержит amount, expiration и nonce. Оно может истечь, быть израсходовано или оставаться активным. Для точечного отзыва используйте функцию Permit2, уменьшающую или обнуляющую разрешение конкретному spender. После транзакции перечитайте запись.

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

Различайте SignatureTransfer и AllowanceTransfer

SignatureTransfer предназначен для одноразового исполнения по подписи и nonce; AllowanceTransfer создаёт лимит на период. Риск и способ проверки отличаются.

Для уже использованного SignatureTransfer nonce должен быть отмечен использованным. Для неисполненной подозрительной подписи существует риск до её истечения или инвалидации. Не публикуйте raw-подпись и не пересылайте её «поддержке». Если параметры неизвестны, переместите активы на новый безопасный адрес и получите профессиональный разбор. Такой порядок защищает от двух противоположных ошибок: сохранения опасного доступа и бессмысленного отзыва разрешения, которое относится к другому активу или сценарию.

EIP‑2612 permit превращается в обычный allowance

После вызова permit контракт токена записывает allowance для spender. Дальше его можно увидеть через allowance и отозвать approve(spender, 0), как стандартное разрешение. Проверьте nonce и deadline подписи. Если permit ещё не исполнен, текущий allowance может быть нулевым, но подпись всё ещё способна изменить его. Срочность зависит от срока и доступности подписи злоумышленнику. При компрометации подписи не ждите появления списания: ограничьте баланс и полномочия заранее.

Практический контроль завершается сравнением исходного и итогового состояния. В журнале указывают owner, сеть, token contract, spender или operator, старое значение, новое значение и причину решения.

Подписанный ордер может жить отдельно от allowance

Некоторые marketplace, DEX и RFQ-системы используют подпись ордера, а исполнение зависит от существующего operator approval или allowance. Отзыв allowance блокирует transfer, но сам подписанный ордер может оставаться валидным. Проверьте nonce, cancellation-механизм и срок ордера. Для полного прекращения намерения иногда нужны и revoke on-chain, и отмена ордера в протоколе.

После повторного approve старый ордер потенциально может стать исполнимым снова, если его nonce не отменён. Поэтому документируйте обе части. Запись считается обработанной только после того, как новое состояние подтверждено в нужной сети и сохранено вместе с transaction hash.

Не путайте signature deadline и expiration

Signature deadline ограничивает время, когда подпись можно предъявить, а expiration может определять срок уже выданного allowance. Эти даты способны различаться. Перед подтверждением переводите timestamps в точные дату и время. После подозрительной подписи проверяйте фактическое on-chain-состояние, а не текст кнопки.

Интерфейс должен раскрывать обе величины и chain ID. Подпись с коротким deadline не обязательно создаёт короткое полномочие, если внутренний expiration намного дальше. В спорной ситуации сначала ограничивают потенциальный ущерб, а затем восстанавливают удобство работы новым минимальным разрешением.

Что делать после подозрительного сайта или фишинга

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

Если кошелёк только подключили

Само подключение обычно раскрывает публичный адрес и позволяет сайту предлагать запросы, но не даёт права перемещать токены без подписи. Тем не менее сессия остаётся каналом для новых фишинговых окон. Отключите сайт в кошельке, закройте WalletConnect-сессию, очистите неизвестные разрешения домена и проверьте историю подтверждений. Затем проведите on-chain-инвентаризацию, потому что пользователь мог забыть ранее подписанный approve. Подробный аварийный порядок раскрывает материал о том, что делать, если вы подключили криптокошелёк к подозрительному сайту.

Практический контроль завершается сравнением исходного и итогового состояния. В журнале указывают owner, сеть, token contract, spender или operator, старое значение, новое значение и причину решения.

Если подписан approve

Сразу определите сеть, token contract, spender и amount. Не ориентируйтесь на название сайта: данные находятся в transaction input и событии Approval. При unknown spender или unlimited amount отзывайте полномочие как можно быстрее. Параллельно проверьте, не было ли transferFrom после approve.

Сохраните hash исходного approve и hash revoke. Эти две записи показывают интервал, в течение которого spender имел доступ, и помогают понять возможный ущерб. Запись считается обработанной только после того, как новое состояние подтверждено в нужной сети и сохранено вместе с transaction hash.

Если подписан permit или Permit2

Найдите typed data: verifying contract, spender, token, amount, nonce, expiration и deadline. Если подпись недоступна вам полностью, считайте неопределённость фактором риска. Пошаговое отличие транзакции, сообщения и approve разобрано в статье как проверить разрешения после подписи на сайте.

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

Если уже произошло списание

Revoke предотвращает будущие списания, но не возвращает подтверждённый transfer. Сначала остановите дальнейший доступ, затем фиксируйте адреса, token, amount, transaction hashes и маршрут активов.

Проверьте остальные токены и NFT, потому что вредный сайт мог запросить несколько подписей. Не взаимодействуйте с неизвестными airdrop-токенами, которые появились после инцидента. Для доказательств используйте чек-лист скриншотов, адресов и TXID и обращайтесь только в официальные каналы сервисов. Такой порядок защищает от двух противоположных ошибок: сохранения опасного доступа и бессмысленного отзыва разрешения, которое относится к другому активу или сценарию.

Если revoke конкурирует с атакой

Злоумышленник может мониторить баланс и отправлять transferFrom сразу после пополнения gas. Тогда обычная последовательность «пополнить — открыть checker — отозвать» создаёт окно атаки. Для EVM иногда применяют private transaction relay, bundle, специализированный rescue или перенос ценных активов в одной координированной последовательности. Такие действия требуют точного анализа и не должны выполняться по инструкции случайного человека в чате. Не раскрывайте приватный ключ ради rescue. Если ключ уже скомпрометирован, цель — переместить активы на новый seed, а не временно очистить approvals старого адреса.

Практический контроль завершается сравнением исходного и итогового состояния. В журнале указывают owner, сеть, token contract, spender или operator, старое значение, новое значение и причину решения.

Если скомпрометирована seed-фраза

Отзыв approvals не решает проблему, потому что злоумышленник может подписывать новые транзакции напрямую. Любой оставшийся актив и будущие поступления находятся под угрозой. Создайте новый кошелёк с новой seed-фразой на чистом устройстве, перенесите активы по приоритету и обновите адреса получения. Старый адрес больше не используют как хранилище.

Полный контур защиты описан в руководстве как защитить криптокошелёк от взлома и ошибок. Не переносите старую seed в новый интерфейс. Запись считается обработанной только после того, как новое состояние подтверждено в нужной сети и сохранено вместе с transaction hash.

Если пришёл неизвестный токен

Неизвестный airdrop может провоцировать пользователя открыть фальшивый сайт, подписать approve или обмен и тем самым выдать доступ к ценным активам. Не взаимодействуйте с активом до проверки. Используйте разбор неизвестного токена или airdrop в кошельке.

Сам факт отображения токена обычно не означает компрометацию. Опасность начинается при переходе по URL из metadata, попытке claim, swap или продаже через неизвестный интерфейс. В спорной ситуации сначала ограничивают потенциальный ущерб, а затем восстанавливают удобство работы новым минимальным разрешением.

Не платите за «очистку» кошелька

Recovery-мошенники обещают отменить контракт, синхронизировать кошелёк или вернуть активы после внесения комиссии. Они часто требуют seed, удалённый доступ или новую подпись.

Настоящий revoke — публичная транзакция, которую подписывает владелец. Для проверки read-only данных не нужны приватный ключ и перевод на тестовый адрес. Любой специалист должен назвать сеть, contract, function, calldata и ожидаемое новое состояние. Неспособность объяснить эти поля — причина прекратить контакт. Такой порядок защищает от двух противоположных ошибок: сохранения опасного доступа и бессмысленного отзыва разрешения, которое относится к другому активу или сценарию.

Особенности TRON, Solana, TON и Bitcoin

Разные сети используют разные модели делегирования. Термины EVM нельзя автоматически переносить на Solana, TON или Bitcoin.

TRC‑20 в сети TRON

TRC‑20 поддерживает approve, allowance и transferFrom по модели, близкой к ERC‑20. Spender может использовать разрешение в пределах лимита, а отзыв обычно вызывает approve(spender, 0).

Проверяйте base58-адрес токена и spender, а также Energy, Bandwidth и возможное сжигание TRX. Список approvals должен относиться к mainnet TRON, а не к тестовой сети. После revoke прочитайте allowance(owner, spender) и сохраните transaction ID. Не путайте разрешение TRC‑20 с обычным переводом USDT на адрес получателя. Такой порядок защищает от двух противоположных ошибок: сохранения опасного доступа и бессмысленного отзыва разрешения, которое относится к другому активу или сценарию.

Делегат SPL Token в Solana

Token account Solana может хранить одного текущего delegate и делегированную сумму. Delegate получает право переводить или сжигать ограниченный объём токенов данного token account. Проверять нужно не только owner wallet, но и конкретный associated token account, mint, delegate и delegated amount. Один владелец имеет отдельные token accounts для разных mint. Инструкция Revoke очищает delegate и сбрасывает делегированную сумму до нуля. После подтверждения прочитайте состояние token account через независимый RPC или explorer.

Практический контроль завершается сравнением исходного и итогового состояния. В журнале указывают owner, сеть, token contract, spender или operator, старое значение, новое значение и причину решения.

Permanent Delegate в Token‑2022

Расширение PermanentDelegate назначается на уровне mint и может разрешать переводы или сжигание для token accounts этого mint. Владелец отдельного token account не может отозвать такой глобальный delegate. Это свойство самого токена, а не пользовательское approval. Перед покупкой Token‑2022 проверяйте extensions mint и полномочия issuer.

Если permanent delegate неприемлем, решение состоит не в revoke кошелька, а в отказе от хранения токена или оценке доверия к эмитенту. Обычный delegate при этом проверяется отдельно. Запись считается обработанной только после того, как новое состояние подтверждено в нужной сети и сохранено вместе с transaction hash.

TON и Jetton не копируют ERC‑20 allowance автоматически

Стандартный Jetton переводит токены через jetton wallet и сообщения; универсального ERC‑20 allowance для любого spender в базовой модели нет. Однако конкретные приложения и контракты могут создавать собственные полномочия, депозиты или подписанные сообщения. Если кошелёк подписал подозрительный пакет, анализируйте trace и действия контрактов. Отключение dApp остаётся полезным, но не отменяет уже исполненные сообщения.

Не используйте EVM approval checker для TON как доказательство отсутствия риска. Проверяйте фактические сообщения, connected apps, ожидаемые transfers и адреса jetton master/wallet. В спорной ситуации сначала ограничивают потенциальный ущерб, а затем восстанавливают удобство работы новым минимальным разрешением.

Bitcoin UTXO не использует token allowance

В обычном Bitcoin нет approve/transferFrom. Расходование UTXO требует действительной подписи транзакции или заранее созданного script-условия.

Поэтому EVM revoke-сервис не должен просить подключить Bitcoin seed. Риски относятся к вредной PSBT, изменённому адресу, compromised key, multisig-policy или предварительно подписанной транзакции. Если ключ скомпрометирован, перемещайте UTXO на новый кошелёк. «Отзыв разрешений Bitcoin» без конкретного script или приложения обычно является маркетинговой или мошеннической формулировкой. Такой порядок защищает от двух противоположных ошибок: сохранения опасного доступа и бессмысленного отзыва разрешения, которое относится к другому активу или сценарию.

Биржевые API и торговые разрешения

API key биржи может иметь права чтения, торговли и вывода, но это off-chain контроль площадки, а не token allowance кошелька. Его отзывают в кабинете биржи. После инцидента проверяйте API keys, активные сессии, адреса whitelist, subaccounts и 2FA отдельно от блокчейн approvals. Не смешивайте два реестра. Один показывает право контракта тратить токены, другой — право ключа управлять учётной записью кастодиального сервиса.

Практический контроль завершается сравнением исходного и итогового состояния. В журнале указывают owner, сеть, token contract, spender или operator, старое значение, новое значение и причину решения.

Сложные случаи, из-за которых revoke проверяют дважды

Сложные протоколы создают несколько связанных полномочий. Проверка одного логотипа или одного allowance не показывает всю цепочку.

Upgradeable proxy

Approval выдан proxy-адресу, который сохраняется, даже когда implementation меняется. Старое доверие к версии протокола не гарантирует безопасность новой логики. Для treasury-кошелька установите триггер повторной проверки после каждого upgrade или governance proposal, затрагивающего spender.

Проверьте proxy standard, implementation, admin, историю upgrades и emergency-права. Если протокол больше не нужен, отзыв уменьшает зависимость от будущих обновлений. В спорной ситуации сначала ограничивают потенциальный ущерб, а затем восстанавливают удобство работы новым минимальным разрешением.

Пустой кошелёк и будущий баланс

Unlimited allowance на нулевом балансе часто игнорируют. Но transferFrom станет возможным сразу после нового поступления токена.

Перед пополнением старого адреса выполняйте pre-funding audit. Особенно это важно для стейблкоинов и wrapped assets, которые регулярно возвращаются на операционный кошелёк. Если адрес не нужен, не возобновляйте его использование. Новый чистый адрес иногда безопаснее и дешевле постоянной поддержки исторического набора approvals. Такой порядок защищает от двух противоположных ошибок: сохранения опасного доступа и бессмысленного отзыва разрешения, которое относится к другому активу или сценарию.

Vault, lending и collateral

Lending-протокол может требовать allowance для deposit или repay, а vault — для стратегии. Отзыв не выводит уже депонированный актив и не закрывает позицию автоматически. Сначала определите, находится ли токен в кошельке или уже учтён внутри протокола. Проверьте здоровье займа, обязательства и возможность emergency withdrawal. Не отзывайте критичное разрешение в середине автоматизированного процесса без понимания последствий. Но после закрытия позиции удалите избыточный доступ.

Практический контроль завершается сравнением исходного и итогового состояния. В журнале указывают owner, сеть, token contract, spender или operator, старое значение, новое значение и причину решения.

LP-токены и staking

Для добавления ликвидности разрешают оба актива, а для staking — LP-токен или receipt token. В результате у одного сценария возникает несколько spender и token contracts. Составьте цепочку: asset A, asset B, router, LP token, gauge или staking contract. Проверяйте allowance каждого звена.

После выхода из стратегии отзывайте approvals, которые больше не нужны. Нулевой LP-баланс не гарантирует отсутствия будущего риска, если токен снова будет получен. Запись считается обработанной только после того, как новое состояние подтверждено в нужной сети и сохранено вместе с transaction hash.

NFT marketplace и подписанные listings

Marketplace может иметь operator approval, а listing — отдельную подпись. Отзыв operator блокирует стандартный transfer, но listing может остаться записанным off-chain. Перед повторным включением operator убедитесь, что старые подписанные listings не станут исполнимыми по нежелательной цене.

Проверьте коллекцию, operator, tokenId, price, nonce и срок. Для полного прекращения продажи отмените listing по правилам площадки и уберите operator approval. В спорной ситуации сначала ограничивают потенциальный ущерб, а затем восстанавливают удобство работы новым минимальным разрешением.

Multisig и smart account

В multisig revoke формируется как предложение и становится действительным только после достижения threshold и исполнения. Черновик или собранные подписи без execution не меняют allowance.

Проверьте nonce Safe или другого smart account, owners, modules, guards и полный batched calldata. Злоумышленник может использовать модуль, даже если обычный approval отозван. Сохраните executed transaction hash и перечитайте allowance от имени самого smart account, а не EOA-подписанта. Такой порядок защищает от двух противоположных ошибок: сохранения опасного доступа и бессмысленного отзыва разрешения, которое относится к другому активу или сценарию.

Checker продолжает показывать отозванную запись

Индексатор может хранить историческую запись или обновляться с задержкой. Также пользователь мог отозвать approval в другой сети либо для другого token contract. Сначала прочитайте allowance напрямую на актуальном блоке. Затем сравните owner, spender, token и chain ID с записью checker. Если on-chain значение ноль, но UI не обновился, сохраните доказательство и дождитесь индексации. Если значение не ноль, найдите фактическую транзакцию и исправьте ошибку.

Практический контроль завершается сравнением исходного и итогового состояния. В журнале указывают owner, сеть, token contract, spender или operator, старое значение, новое значение и причину решения.

Нестандартный токен

Некоторые токены требуют сначала установить allowance в ноль перед новым значением, возвращают нестандартные данные или имеют pause, blacklist и fee-логику. Revoke-интерфейс может завершиться ошибкой, хотя calldata выглядит правильно. Изучите verified source и существующие успешные Approval-транзакции.

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

Как снизить риск будущих разрешений

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

Выдавайте минимальный необходимый лимит

Exact approval ограничивает максимальный ущерб конкретной суммой. Для разового swap лимит должен соответствовать ожидаемому spend с разумным техническим запасом, а не всему балансу. Учитывайте decimals и отображение кошелька. Ошибка в порядке величины может превратить точный лимит в фактически unlimited для пользователя.

После операции проверяйте остаток и отзывайте его. Если протокол регулярно используется, определите допустимый cap и пересматривайте его при изменении оборота. Запись считается обработанной только после того, как новое состояние подтверждено в нужной сети и сохранено вместе с transaction hash.

Используйте отдельный dApp-кошелёк

Рабочий кошелёк для bridge, mint и новых протоколов должен хранить только сумму, необходимую для текущих операций. Основной резерв не подключают к случайным dApp. Пополняйте его перед задачей и выводите остаток после завершения. Не превращайте временный hot wallet в долгосрочное хранилище.

Такое разделение ограничивает последствия вредного approve, Permit2-подписи и уязвимости протокола. Но отдельный кошелёк всё равно требует backup и контроля gas. В спорной ситуации сначала ограничивают потенциальный ущерб, а затем восстанавливают удобство работы новым минимальным разрешением.

Проводите регулярный обзор

Для активного DeFi-пользователя разумен ежемесячный просмотр, а также проверка после каждого нового протокола, bridge, marketplace или подозрительного события.

Корпоративные кошельки проверяют по расписанию и при изменении ролей, smart-contract deployments и лимитов treasury. Список approvals должен быть воспроизводимым: дата, snapshot block, инструмент, networks и решение по каждой записи. Без истории невозможно понять, что изменилось. Такой порядок защищает от двух противоположных ошибок: сохранения опасного доступа и бессмысленного отзыва разрешения, которое относится к другому активу или сценарию.

Проверяйте адреса до подписи

Домен, token contract, spender и chain ID должны подтверждаться независимо. Фальшивый front-end может использовать настоящий токен и вредный spender. Сравнивайте адрес полностью либо через доверенный аппаратный экран и локальный allowlist. Метка интерфейса не заменяет адрес. Перед новым взаимодействием используйте общую проверку рисков криптооперации и не продолжайте, если назначение вызова непонятно.

Практический контроль завершается сравнением исходного и итогового состояния. В журнале указывают owner, сеть, token contract, spender или operator, старое значение, новое значение и причину решения.

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

Симуляция показывает ожидаемые token transfers, approvals, operator changes и recipient. Она не гарантирует безопасность будущего состояния, но помогает обнаружить явное несоответствие. Декодируйте calldata и EIP‑712 typed data. Важны spender, amount, token, expiration, nonce и дополнительные calls.

Если кошелёк показывает blind signing, остановитесь. Для значимой суммы нужен второй инструмент или технический reviewer. Запись считается обработанной только после того, как новое состояние подтверждено в нужной сети и сохранено вместе с transaction hash.

Храните резерв gas для аварии

Операционный адрес без нативной монеты не может быстро revoke, cancel или transfer. Минимальный резерв является частью безопасности, а не неиспользуемым остатком. Не храните избыточный нативный баланс на рискованном dApp-кошельке: резерв должен обеспечивать восстановление, но не увеличивать потенциальную потерю без необходимости.

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

Создайте allowlist для treasury

Организация должна хранить утверждённые token и spender addresses с назначением, сетью, владельцем процесса, лимитом и датой пересмотра.

Новый approve вне allowlist требует отдельного согласования и симуляции. Изменение proxy implementation также считается событием повторной проверки. Такой реестр не заменяет on-chain аудит, но сокращает время реакции: неизвестная запись сразу становится исключением, а не предметом догадок. Такой порядок защищает от двух противоположных ошибок: сохранения опасного доступа и бессмысленного отзыва разрешения, которое относится к другому активу или сценарию.

Применяйте принцип четырёх глаз

Для крупных сумм один сотрудник подготавливает транзакцию, второй независимо сверяет chain ID, token, spender, amount и calldata, после чего подписанты подтверждают её. Проверяющий не должен использовать тот же скриншот или ссылку как единственный источник. Независимость каналов защищает от подмены и общей ошибки. Результат исполнения проверяет ещё один человек либо автоматический мониторинг. Процесс заканчивается чтением нового allowance, а не сбором подписей.

Практический контроль завершается сравнением исходного и итогового состояния. В журнале указывают owner, сеть, token contract, spender или operator, старое значение, новое значение и причину решения.

Документы, мониторинг и контроль результата

Документирование превращает revoke из одноразового клика в проверяемый контроль. Это особенно важно для значимых сумм и командных кошельков.

Сохраняйте исходный approve

Transaction hash approve показывает token contract, spender, amount, block и owner. Он связывает разрешение с конкретной датой и приложением. Сохраните также скрин или export интерфейса, но первичным доказательством остаётся блокчейн. Для permit добавьте typed data, если она доступна безопасно. Не публикуйте полный финансовый профиль и подписи в открытом чате. Доказательства передают только проверенной поддержке или специалисту по защищённому каналу.

Практический контроль завершается сравнением исходного и итогового состояния. В журнале указывают owner, сеть, token contract, spender или operator, старое значение, новое значение и причину решения.

Сохраняйте revoke и новое состояние

После отзыва фиксируют hash, block, function, status и значение allowance после исполнения. Для NFT — getApproved или isApprovedForAll. Это позволяет отделить задержку индексатора от неуспешной транзакции и установить точный момент прекращения полномочий.

В отчёте укажите сеть, owner, token, spender, old value, new value и причину. Для Permit2 добавьте уровень разрешения и expiration. Запись считается обработанной только после того, как новое состояние подтверждено в нужной сети и сохранено вместе с transaction hash.

Настройте мониторинг Approval и transferFrom

Для значимых кошельков можно отслеживать события Approval, ApprovalForAll и исходящие token transfers. Неожиданное новое разрешение требует немедленного разбора. Автоматический alert не заменяет подтверждение: проверьте transaction origin, calldata и фактическое состояние контракта.

Мониторинг должен учитывать proxy, Permit2 и несколько сетей. Уведомление по одному адресу Ethereum не покрывает тот же account в Base или Arbitrum. В спорной ситуации сначала ограничивают потенциальный ущерб, а затем восстанавливают удобство работы новым минимальным разрешением.

Проверяйте TXID списания

Если токены ушли, найдите transaction hash и разберите, был ли это transfer, transferFrom, Permit2, router multicall или прямой вызов владельца.

Сравните from, to, token, amount, initiator и events. Это определяет, поможет ли revoke и какие другие полномочия проверять. Для USDT и других переводов используйте руководство как проверить транзакцию по TXID в блокчейне. Такой порядок защищает от двух противоположных ошибок: сохранения опасного доступа и бессмысленного отзыва разрешения, которое относится к другому активу или сценарию.

Готовьте обращение в поддержку

Укажите официальный account, сеть, адрес кошелька, token contract, spender, hashes approve/revoke/transfer и время. Опишите ожидаемый и фактический результат. Не отправляйте seed, private key, 2FA-коды и необработанную Permit-подпись. Поддержке достаточно публичных данных и подтверждения владения безопасным способом. Запрос должен быть проверяемым: специалист открывает hashes и видит ту же цепочку событий, а не пытается восстановить её по одному скриншоту.

Практический контроль завершается сравнением исходного и итогового состояния. В журнале указывают owner, сеть, token contract, spender или operator, старое значение, новое значение и причину решения.

Определите критерий закрытия инцидента

Инцидент нельзя считать завершённым только после одного revoke. Нужно подтвердить отсутствие других approvals, подозрительных сессий, неизвестных modules, API keys и compromised seed. Закрывающий checklist включает новые balances, все сети, NFT, Permit2, Solana delegates, журнал действий и обновлённый безопасный адрес получения.

Если причина не установлена, сохраняйте повышенный мониторинг и не возвращайте крупный капитал на старый hot wallet. Запись считается обработанной только после того, как новое состояние подтверждено в нужной сети и сохранено вместе с transaction hash.

Практическая матрица решений

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

Разрешение известному DEX после разовой сделки

Если операция завершена и в ближайшее время протокол не нужен, exact или unlimited allowance становится избыточным. Отзыв уменьшает площадь атаки без потери уже полученного результата.

Проверьте, нет ли незавершённого limit order, liquidity position или автоматического действия, которому нужен доступ. После закрытия обязательств обнулите allowance и сохраните hash. Новую сделку начните с нового ограниченного approve. Такой порядок защищает от двух противоположных ошибок: сохранения опасного доступа и бессмысленного отзыва разрешения, которое относится к другому активу или сценарию.

Unlimited USDT неизвестному spender

Это критическая запись: ликвидный стейблкоин может быть списан сейчас и после будущих пополнений. Возраст approval не снижает риск. Сначала убедитесь в правильной сети и token contract, затем сформируйте approve(spender, 0), проверьте calldata и подпишите с достаточным gas. После success перечитайте allowance и проверьте историю transferFrom. Если списание уже началось, переходите к аварийному сценарию.

Практический контроль завершается сравнением исходного и итогового состояния. В журнале указывают owner, сеть, token contract, spender или operator, старое значение, новое значение и причину решения.

Operator approval на NFT marketplace

Для официального активно используемого marketplace разрешение может быть функционально необходимо, но охватывает всю коллекцию. Фишинговый operator требует немедленного revoke. Проверьте официальный operator address, подписанные listings и ценность коллекции. Не делайте вывод по логотипу.

После revoke отмените ненужные ордера и убедитесь, что isApprovedForAll возвращает false. Запись считается обработанной только после того, как новое состояние подтверждено в нужной сети и сохранено вместе с transaction hash.

Permit2 с истекающим лимитом

Короткий expiration и небольшой amount снижают риск, но не делают неизвестный spender безопасным. До истечения он может использовать полномочие. Проверьте остаток amount и nonce после транзакции. Не считайте старую подпись уничтоженной без анализа её срока и исполнения.

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

Approval на токен с нулевым балансом

Риск отложен, а не устранён. При следующем поступлении spender сможет использовать токены в пределах allowance.

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

Подозрительный approve и известная seed

Если seed остаётся секретной, быстрый revoke обычно эффективен против данного spender. Но нужно проверить все подписи и разрешения сессии. Отключите dApp, отзовите approvals, проверьте Permit2 и NFT, сохраните доказательства и установите мониторинг. Если есть признаки компрометации seed, не ограничивайтесь revoke: переносите активы на новый кошелёк.

Практический контроль завершается сравнением исходного и итогового состояния. В журнале указывают owner, сеть, token contract, spender или operator, старое значение, новое значение и причину решения.

Seed раскрыта или введена на сайте

Адрес считается полностью скомпрометированным. Злоумышленник не нуждается в старом allowance и может создавать новые операции. Создайте новый seed на чистом устройстве, перенесите активы и измените адреса получения. Сложные позиции и NFT спасают по приоритету с профессиональной помощью.

Старый кошелёк не используют для новых поступлений, даже если все approvals показывают ноль. Запись считается обработанной только после того, как новое состояние подтверждено в нужной сети и сохранено вместе с transaction hash.

Неясная запись в checker

Не удаляйте и не сохраняйте её наугад. Сначала подтвердите owner, chain ID, token, spender, current allowance, creation transaction и protocol role. Документируйте решение и источник проверки, чтобы следующая инвентаризация не начиналась с нуля.

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

Итог: revoke — это управление полномочиями, а не кнопка успокоения

Правильный ответ на вопрос, как отозвать разрешения токенов, начинается с определения модели. Для ERC‑20 это owner–token–spender и allowance; для NFT — tokenId или operator; для Permit2 — базовый approve и внутренний лимит; для Solana — delegate конкретного token account. Только после идентификации формируется транзакция, которая меняет нужное состояние на ноль или false.

Безопасный процесс включает snapshot, проверку сети и адресов, декодирование calldata, достаточный gas, подтверждённый receipt, прямое чтение нового allowance и архив доказательств. Disconnect, удаление приложения или очистка браузера полезны для сессий, но не заменяют on-chain revoke. Если раскрыта seed-фраза, отзыв разрешений вообще не является восстановлением: активы переводят на новый кошелёк.

Регулярная инвентаризация особенно важна для стейблкоинов, DeFi и NFT. Старый unlimited approval способен оставаться опасным при нулевом балансе и сработать после будущего пополнения. Минимальные лимиты, отдельный dApp-кошелёк, контроль Permit2, мониторинг Approval-событий и принцип четырёх глаз уменьшают максимальный ущерб и ускоряют реакцию.

Перед каждой значимой подписью проверяйте, кто именно получает полномочие, какой актив и объём охвачены, в какой сети действует запись и как её можно будет отозвать. Если критические параметры нельзя объяснить до подтверждения, безопасное решение — отказаться от операции. После инцидента используйте публичные данные и официальные каналы; seed-фраза, private key и удалённый доступ для revoke не требуются.

Контрольный алгоритм для кошелька с большим числом approvals

Если список содержит десятки или сотни записей, не начинайте с хаотичного нажатия Revoke. Сначала выгрузите данные по всем сетям и нормализуйте их в одну таблицу: chain ID, owner, token contract, стандарт, spender, тип разрешения, лимит, текущий баланс и дата последней активности. Затем удалите явные дубли отображения и разделите реальные on-chain allowances от исторических событий. Такой подход экономит gas, уменьшает риск пропустить Permit2 или NFT operator и даёт исходный снимок, который можно повторно проверить после завершения работы.

Ранжирование удобно выполнять по потенциальному ущербу. На первом уровне находятся неизвестные spenders с unlimited доступом к ликвидным стейблкоинам, wrapped assets и дорогим NFT. Второй уровень — известные, но больше не используемые routers, bridges, marketplaces и vaults. Третий — точные небольшие лимиты, неликвидные токены и записи с нулевым фактическим полномочием. Возраст транзакции не должен быть главным критерием: старый allowance способен стать опаснее нового сразу после пополнения кошелька.

Для каждой строки заранее определите ожидаемую функцию отзыва. ERC‑20 требует нулевого allowance для конкретного spender; ERC‑721 может потребовать очистить approved address одного tokenId либо отключить operator; ERC‑1155 использует false для setApprovalForAll; Permit2 требует понять, отзывает ли транзакция внутренний лимит, базовый approve или оба уровня; Solana очищает delegate конкретного token account. Если интерфейс предлагает другую функцию, остановитесь и выясните причину до подписи.

Работу выполняют небольшими контролируемыми партиями. После нескольких транзакций дождитесь receipts, перечитайте состояния и обновите реестр. Это защищает от ситуации, когда десятки pending nonce образуют очередь, а пользователь не понимает, какие approvals уже закрыты. При высокой комиссии можно перенести низкоприоритетные записи, но критичные unlimited allowances на значимые активы нельзя откладывать только ради экономии. Решение о сроке должно учитывать текущий и ожидаемый баланс.

После технического отзыва проверьте операционные зависимости. Автоматический repay, recurring strategy, торговый bot, vault deposit или marketplace listing могут перестать работать. Это не означает, что approval нужно вернуть автоматически. Сначала подтвердите, что функция действительно необходима, затем создайте новое ограниченное разрешение официальному spender с документированным лимитом. Так аудит не только очищает старые риски, но и переводит кошелёк на более понятную модель полномочий.

При командном управлении результаты сверяют независимо. Один участник подготавливает список и транзакции, другой сравнивает адреса и calldata с исходным реестром, подписанты подтверждают действия, а отдельный контроль читает итоговое состояние. Все участники должны видеть одну и ту же сеть и полный адрес, а не только имя протокола. Для multisig особенно важно отличать созданное предложение от исполненной on-chain-транзакции: до execution allowance остаётся прежним.

Финальный аудит должен охватывать не только активные balances. Проверьте пустые token accounts, старые L2, сети после bridge, NFT collections, Permit2, Solana delegates, connected sessions и биржевые API. Затем выполните контрольный поиск новых Approval и ApprovalForAll событий, появившихся во время процедуры. Если неизвестное разрешение возникает повторно, причина может находиться в автоматизации, вредном расширении, другом signer или скомпрометированном ключе, и простое повторение revoke проблему не решает.

Закройте процедуру документом, который можно воспроизвести: дата и snapshot block, использованные инструменты, перечень сетей, исходные и итоговые значения, hashes всех revoke, исключения и причины сохранения отдельных approvals. Укажите дату следующего обзора и события для внеплановой проверки — новый dApp, изменение proxy implementation, incident протокола, смена сотрудников или крупное пополнение. Именно воспроизводимость отличает реальный контроль безопасности от одноразового просмотра интерфейса.

Отдельно проверьте адреса, которые используются для регулярных входящих платежей. Даже если на момент аудита они пусты, контрагенты, биржи или автоматические системы могут отправить туда стейблкоины позднее. Старый unlimited allowance тогда получит реальный объект для списания. До возобновления приёма средств либо очистите разрешения, либо замените реквизит на новый операционный адрес и официально уведомите отправителей. Такой pre-funding контроль особенно важен для публично размещённых адресов и бухгалтерских шаблонов.

Если часть approvals сохранена, сформулируйте причину не общими словами «нужно для работы», а проверяемым условием: конкретный protocol function, утверждённый spender, максимальный лимит, владелец процесса и дата окончания необходимости. Настройте сигнал при увеличении allowance или изменении implementation. Сохранённое разрешение является осознанным исключением из принципа минимальных полномочий и должно иметь более сильный мониторинг, чем полностью отозванная запись.

После завершения процедуры проведите небольшую безопасную проверку рабочего маршрута. Не нужно заново выдавать все старые полномочия: откройте только необходимое приложение из официального источника, сформируйте минимальный exact approval и убедитесь, что кошелёк ясно показывает spender и amount. Затем выполните тестовую операцию, проверьте transaction hash и остаточный allowance. Такой тест подтверждает, что безопасность не была достигнута ценой потери управляемости кошелька.

Любое новое разрешение после аудита должно рассматриваться как изменение конфигурации безопасности. Оно фиксируется до отправки значительной суммы, а не задним числом после инцидента. Пользователь или команда должны понимать способ отзыва ещё до approve: где будет видна запись, какая функция установит ноль, какая сеть оплатит gas и кто проверит результат. Если ответа нет, выдавать unlimited полномочие основному кошельку нельзя.