Коротко
- Разрешение относится к конкретной сети, токену, владельцу и spender. Оно не даёт контракту универсальный доступ ко всему кошельку, но большой лимит позволяет списать доступный баланс этого токена в пределах allowance.
- Disconnect разрывает связь интерфейса с кошельком, а revoke меняет on-chain состояние. Для отзыва нужна отдельная транзакция и сетевая плата или ресурсы сети.
- После отзыва проверяют не только успешный статус транзакции, но и новое значение allowance для той же пары owner–spender. Если раскрыта seed-фраза или private key, одного revoke недостаточно.
1. Сайт отключён, а разрешение осталось
Представьте: вы обменяли токен через dapp, закончили операцию и нажали Disconnect. Сайт исчез из списка подключений, но ранее выданный allowance всё ещё записан в контракте токена. Если адрес spender снова вызовет transferFrom и остальные условия контракта выполнятся, одного отключения интерфейса недостаточно, чтобы остановить списание.
2. Как approve, allowance и transferFrom работают вместе
В стандарте ERC-20 владелец вызывает approve(spender, value). Так он разрешает адресу spender тратить токены до указанного лимита. Метод allowance(owner, spender) показывает оставшийся лимит, а transferFrom(from, to, value) позволяет уполномоченному адресу выполнить перевод от имени владельца. Успешный approve должен создать событие Approval.
Важно читать не только красивое имя приложения. Разрешение хранит контракт токена, а spender — обычный on-chain адрес: это может быть контракт обмена, мост, агрегатор или другой адрес. Один и тот же интерфейс может использовать разные spender в разных сетях и версиях протокола.
| Параметр | Почему он важен | Типичная ошибка |
|---|---|---|
| Сеть | Состояние Ethereum, BNB Chain и TRON хранится раздельно | Проверили знакомый адрес, но в другой сети |
| Owner | Разрешение выдал конкретный аккаунт | Открыли нужный кошелёк, но выбрали другой аккаунт |
| Token contract | Allowance относится к одному контракту токена | Поверили символу USDT и не сверили контракт |
| Spender | Именно этот адрес получает право вызвать transferFrom | Судили только по названию dapp |
| Value | Лимит задаёт верхнюю границу доступного списания | Приняли очень большое число за технический ноль |
- Параметр
- Сеть
- Почему он важен
- Состояние Ethereum, BNB Chain и TRON хранится раздельно
- Типичная ошибка
- Проверили знакомый адрес, но в другой сети
- Параметр
- Owner
- Почему он важен
- Разрешение выдал конкретный аккаунт
- Типичная ошибка
- Открыли нужный кошелёк, но выбрали другой аккаунт
- Параметр
- Token contract
- Почему он важен
- Allowance относится к одному контракту токена
- Типичная ошибка
- Поверили символу USDT и не сверили контракт
- Параметр
- Spender
- Почему он важен
- Именно этот адрес получает право вызвать transferFrom
- Типичная ошибка
- Судили только по названию dapp
- Параметр
- Value
- Почему он важен
- Лимит задаёт верхнюю границу доступного списания
- Типичная ошибка
- Приняли очень большое число за технический ноль
3. ERC-20, TRC-20 и permit: одинаковые слова, разные транзакции
TRC-20 использует знакомую модель approve, transferFrom и allowance. Документация TRON показывает approve как изменяющий состояние вызов, который нужно подписать и передать в сеть; allowance читается без изменения состояния. Но адреса, сеть, обозреватель, стоимость исполнения и способ подтверждения отличаются от EVM-сетей. Инструкция для Ethereum не становится инструкцией для TRON заменой одного логотипа.
ERC-2612 добавляет permit: владелец подписывает структурированное сообщение, а allowance может установить другой отправитель, передав подпись в контракт. В сообщении есть owner, spender, value, nonce и deadline; домен обычно связывает подпись с контрактом и chain ID. Это не обычный вход на сайт. Подпись permit способна изменить право на расходование токена после отправки в сеть.
4. Как проверить действующие разрешения
- 1Зафиксируйте сеть и аккаунт
Скопируйте только публичный адрес и выберите ту сеть, где лежит токен. Не вводите seed-фразу или private key в форму проверки.
- 2Сверьте контракт токена
Возьмите адрес контракта из официальной документации эмитента или подтверждённого интерфейса. Одинаковый символ не гарантирует, что перед вами тот же актив.
- 3Определите spender
Запишите полный адрес и выясните, к какому продукту и версии контракта он относится. Название, иконка и подпись в стороннем каталоге сами по себе не доказывают владельца адреса.
- 4Прочитайте allowance
Проверьте пару owner–spender в контракте выбранного токена. Переведите значение из минимальных единиц с учётом decimals; не округляйте большое число до понятной суммы на глаз.
- 5Сохраните исходное состояние
Перед изменением запишите сеть, owner, token contract, spender и allowance. Эти данные помогут проверить, что последующая транзакция изменила именно нужную запись.
Если адрес spender прислал незнакомец или он появился после подозрительной подписи, сначала стоит проверить адрес и источник реквизитов, а не доверять подписи интерфейса. Публичная метка помогает ориентироваться, но не заменяет сверку контракта и истории собственных действий.
5. Как отозвать разрешение без новой ошибки
- 1Откройте подтверждённый интерфейс
Используйте функцию самого кошелька, официальный обозреватель выбранной сети или проверенный интерфейс управления allowances. Адрес вводят публичный; импортировать seed-фразу ради revoke нельзя.
- 2Выберите точную запись
Ещё раз сопоставьте сеть, аккаунт, token contract и spender. Отзыв разрешения другого токена или другой сети не исправит исходную проблему.
- 3Прочитайте запрос кошелька
Ожидаемое действие изменяет allowance выбранного spender, обычно на ноль. Если запрос предлагает перевод токена, новый большой approve или непонятную подпись, отмените его и разберите данные заново.
- 4Подготовьте сетевую плату
Revoke изменяет блокчейн, поэтому требует gas в EVM-сети либо ресурсов и возможной платы в TRON. Не отправляйте комиссию человеку в чате: её рассчитывает сеть при вашей транзакции.
- 5Дождитесь исполнения и перечитайте allowance
Полученный hash — только идентификатор. Проверьте успешное исполнение, затем снова вызовите allowance для той же пары и убедитесь, что значение стало нулевым.
До подтверждения можно посмотреть сетевую комиссию и решить, достаточно ли нативного актива для транзакции. Низкий баланс ETH, BNB, TRX или другого ресурса не делает перевод третьему лицу обязательным: пополнять нужно собственный адрес в нужной сети через понятный источник.
6. Если разрешение уже использовали или ключ раскрыт
Начните с различия между вредным allowance и компрометацией ключа. В первом случае владелец всё ещё контролирует аккаунт, а риск связан с конкретным токеном и spender. Во втором посторонний знает seed-фразу или private key и может подписывать любые доступные этому ключу операции. Отзыв одного allowance не меняет ключ и не закрывает остальные пути вывода.
| Ситуация | Первое действие | Чего недостаточно |
|---|---|---|
| Подозрительный allowance, списаний нет | Отозвать разрешение, проверить результат и остальные токены в этой сети | Просто отключить сайт |
| Spender уже списал токены | Отозвать остаток, сохранить hash и обратиться в официальную поддержку затронутого протокола | Повторно подписать предложение о возврате из личного сообщения |
| Подписан непонятный permit | Зафиксировать данные и deadline, прекратить взаимодействие, наблюдать за allowance и защитить активы | Смотреть только на текущее нулевое значение |
| Раскрыта seed-фраза или private key | Создать новый кошелёк из доверенной среды и перенести оставшиеся активы после оценки безопасной последовательности | Отозвать один approve или сменить пароль приложения |
- Ситуация
- Подозрительный allowance, списаний нет
- Первое действие
- Отозвать разрешение, проверить результат и остальные токены в этой сети
- Чего недостаточно
- Просто отключить сайт
- Ситуация
- Spender уже списал токены
- Первое действие
- Отозвать остаток, сохранить hash и обратиться в официальную поддержку затронутого протокола
- Чего недостаточно
- Повторно подписать предложение о возврате из личного сообщения
- Ситуация
- Подписан непонятный permit
- Первое действие
- Зафиксировать данные и deadline, прекратить взаимодействие, наблюдать за allowance и защитить активы
- Чего недостаточно
- Смотреть только на текущее нулевое значение
- Ситуация
- Раскрыта seed-фраза или private key
- Первое действие
- Создать новый кошелёк из доверенной среды и перенести оставшиеся активы после оценки безопасной последовательности
- Чего недостаточно
- Отозвать один approve или сменить пароль приложения
Если инцидент начался с фальшивой поддержки, срочности или ссылки из сообщения, полезно разобрать мошенническую схему и сохранить домен, переписку, адреса и hash. Не вступайте в переговоры с «возвратчиком», который просит ещё одну подпись, секрет или предварительную оплату.
Для дальнейшего использования разделите повседневные операции и основное хранение, включите понятное отображение запросов и заранее выберите кошелёк с прозрачным управлением подключениями и разрешениями. Ни один интерфейс не компенсирует подпись непроверенных данных, но хороший кошелёк делает предмет подтверждения заметнее.
7. Короткие ответы на частые вопросы
Что стоит уточнить перед действием
Можно ли уменьшить лимит вместо полного отзыва?
Если контракт и интерфейс поддерживают изменение значения, approve обычно перезаписывает allowance. Но ERC-20 отдельно предупреждает о риске при смене ненулевого значения на другое ненулевое; безопасный интерфейс может сначала установить ноль. Читайте обе транзакции и проверяйте итоговое состояние.
Можно ли проверять allowance без подключения кошелька?
Да, значение является публичным on-chain состоянием и читается по owner, spender и token contract. Для самого отзыва владельцу всё равно нужно подписать изменяющую состояние транзакцию.
Revoke вернёт уже списанные токены?
Нет. Отзыв ограничивает будущие вызовы через это разрешение, но не отменяет исполненные переводы. Возврат зависит от владельца адреса, правил сервиса и обстоятельств инцидента.
Источники
Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.
- Ethereum Improvement Proposals — ERC-20 Token Standard Проверено 10 августа 2026 г.
- Ethereum Improvement Proposals — ERC-2612 Permit Проверено 10 августа 2026 г.
- TRON Developers — TRC-20 contract interaction Проверено 10 августа 2026 г.
- MetaMask Help Center — revoke smart contract allowances Проверено 10 августа 2026 г.