Что на самом деле разрешает токен-одобрение в крипто-кошельке

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

Что происходит в момент approve() на уровне блокчейна

Стандарт ERC-20 содержит функцию approve(address spender, uint256 amount). Вызывая её, вы записываете в хранилище смарт-контракта токена собственную строку в маппинге allowance. Структура этого хранилища проста: allowance[owner][spender] = amount. Владелец — ваш адрес. Спендер — адрес контракта, которому вы даёте право распоряжаться. Amount — лимит, который контракт сможет списать через transferFrom().

Дальше начинается то, что большинство пользователей пропускает. Разрешение не привязано к конкретной транзакции. Оно не истекает по времени. Оно не отзывается автоматически после того, как приложение выполнило свою операцию. Пока в маппинге стоит ненулевое значение, спендер может вызвать transferFrom() в любой момент — хоть через минуту, хоть через год, хоть после того как вы удалили приложение из закладок и забыли его название.

Unlimited approve: удобство, которое стало нормой

Технически можно одобрить ровно ту сумму, которая нужна для операции. Но большинство DeFi-протоколов просят approve с максимальным значением uint256 — это 2^256-1, число с 78 цифрами. Причина прагматичная: каждый approve — отдельная транзакция с газом. Если пользователь торгует на DEX регулярно, ему пришлось бы подписывать approve перед каждым свапом. Протоколы решили это одним разрешением «на всё».

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

Сравните с тем, как это устроено в других архитектурах. ERC-2612 добавил permit() — подпись вне сети, которая не требует отдельной транзакции approve. EIP-2612 позволяет совместить одобрение и действие в одном вызове, экономя газ. Но принцип тот же: разрешение существует, пока его не отозвали. Стандарт ERC-1155 для мультитокенов использует setApprovalForAll() — одну флаг-переменную на весь контракт, которая даёт спендеру доступ ко всем вашим токенам этого стандарта. Один вызов — и весь портфель NFT или игровых активов под угрозой.

Почему отзыв одобрений — не паранойя, а гигиена

Уязвимость сидит не в вашем кошельке, а в контракте-спендере. Если в логике протокола есть баг, если его админ-ключ скомпрометирован, если контракт оказался фишинговым — разрешение превращается в открытую кассу. Злоумышленнику не нужен ваш приватный ключ. Достаточно вызвать transferFrom() от имени контракта, которому вы сами выдали право.

Именно так работают массовые дренажи кошельков: пользователь подписывает approve на поддельный сайт, а через часы или дни с адреса уходит всё, что было одобрено. Никаких взломов seed-фразы. Чистая механика allowance.

Инструменты для аудита разрешений существуют. Revoke.cash, Etherscan Token Approvals, встроенные функции в Rabby и MetaMask — все они читают маппинг allowance и показывают список активных спендеров. Отзыв — это вызов approve(spender, 0), который обнуляет строку. Простая операция. Но её делают единицы.

Что за кадром остаётся в разговорах о «подключении кошелька»

WalletConnect, MetaMask SDK, Coinbase Wallet SDK — все они используют один и тот же паттерн: запрос на подключение через eth_requestAccounts возвращает только адрес. Никаких прав на движение средств. Дальше приложение показывает интерфейс, читает балансы через eth_call к контрактам токенов, строит транзакции. Каждая транзакция — отдельная подпись. Каждый approve — отдельное решение пользователя, даже если интерфейс делает его незаметным.

Опасность в том, что UX стёр границу между «подключиться» и «разрешить». Кнопка Connect Wallet и кнопка Approve выглядят одинаково привычно. Пользователь нажимает вторую, думая что делает первую.

Рынок сегодня это подтверждает косвенно. Fear & Greed Index на отметке 74 — зона жадности. BTC держится у $83 958, ETH — $2 691, SOL прибавил 3,57% за сутки и торгуется по $121,90, NEAR вырос на 7,41% до $4,93, DOT — на 6,98% до $1,24. Когда альткоины растут двузначными темпами за неделю, активность в DeFi-протоколах подскакивает, и количество approve растёт пропорционально. Каждый новый протокол, каждая новая ферма, каждый аирдроп-чекер просит разрешение. Портфель разрешений растёт быстрее, чем портфель токенов.

Что может пойти не так на уровне протокола

Первый риск — прокси-контракты. Многие DeFi-протоколы используют паттерн upgradeable proxy: логика сидит за адресом, который может быть заменён владельцем. Вы одобрили спендер с одной логикой. Через месяц владелец залил другую. Разрешение осталось, логика изменилась.

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

Третий риск — реентрантность и ошибки в transferFrom-хуках. ERC-777 и некоторые ERC-20 с хуками позволяют выполнить код до и после перевода. Если спендер-контракт не защищён reentrancy guard, один вызов может инициировать цепочку списаний.

Четвёртый — approval phishing через подмену адреса спендера. Пользователь видит знакомый интерфейс, но адрес контракта в поле spender отличается на один символ.

Как это решают в других экосистемах

Solana обходится без approve вовсе. Там модель другая: транзакция подписывается целиком, и программа не может списать токены без валидной подписи владельца. Нет долгоживущих разрешений — нет класса атак через allowance. Но есть свои trade-off: composability DeFi на Solana строится иначе, и часть паттернов, привычных в EVM, там просто не работает.

Cosmos с его модулем authz даёт granular grants с явным сроком действия и списком разрешённых типов сообщений. Можно выдать право на конкретную операцию на конкретный период. Гибче, чем ERC-20 approve, но требует поддержки на уровне приложения.

Bitcoin и UTXO-модель вообще не имеют концепции allowance. Каждая транзакция — явное перемещение конкретных выходов. Никаких «разрешений на будущее».

Вопрос, который стоит задать себе сегодня

А что будет с вашим портфелем, когда очередной протокол, которому вы выдали unlimited approve полгода назад, объявит о миграции контракта — и старый адрес останется активным в блокчейне навсегда? Разрешение не удаляется вместе с интерфейсом. Оно живёт в состоянии сети, пока кто-то не вызовет approve(spender, 0). И этот кто-то — только вы.