Все новости крипты
в одном месте!
Больше не нужно искать — необходимые
обучающие материалы и подсказки всегда под рукой
Больше не нужно искать — необходимые
обучающие материалы и подсказки всегда под рукой
Вы открываете DEX, нажимаете кнопку обмена — и кошелёк неожиданно просит подтвердить что-то под названием Approve. Большинство пользователей жмут «Подтвердить», не задумываясь. Это одна из самых распространённых и дорогостоящих ошибок в криптовалютном мире. Кнопка approve в крипте — это не просто технический шаг перед обменом. Это выдача юридически значимого разрешения: конкретному смарт-контракту, на конкретный токен, на конкретную сумму, на неопределённый срок. Иногда — без всякого ограничения суммы вообще.
Именно это делает апрув токенов одним из главных векторов атаки в DeFi-пространстве 2026 года. Не взлом кошелька, не кража сид-фразы — просто пользователь сам, добровольно, подписал разрешение. А потом забыл. Или не понял, что именно подписал.
Эта статья — практический разбор механизма approve: как он работает изнутри, почему unlimited allowance представляет реальную угрозу, чем отличается approve от connect wallet, что такое Permit2 и как правильно делать revoke. Если вы хотите понимать Web3 на уровне, достаточном для безопасной работы — читайте внимательно. Если вы уже что-то подписали и теперь хотите проверить и отозвать доступ — здесь есть пошаговые инструкции.
Для контекста: прежде чем разбирать approve, убедитесь, что понимаете базовую структуру кошельков — это поможет правильно выстроить защиту. Разбор того, как выбрать криптокошелёк в 2026 году, и советы о том, как не потерять крипту из-за типичных ошибок новичков, — необходимая база перед погружением в тему разрешений.
Стандарт ERC-20, на котором построено большинство токенов в сети Ethereum и совместимых с ней сетях, содержит важное ограничение по дизайну: смарт-контракт не может самостоятельно взять ваши токены без явного разрешения. Это принципиальное архитектурное решение в пользу безопасности. Никакой DEX, протокол стейкинга, лендинговая платформа или пул ликвидности не вправе тронуть ваши токены, пока вы сами не скажете «разрешаю».
Именно поэтому при первом использовании любого токена в любом протоколе вы видите запрос Approve. Это не баг, не лишний шаг, не проблема с интерфейсом. Это обязательная транзакция в блокчейне, которая записывает ваше разрешение в состояние смарт-контракта токена.
Без этого шага невозможно: сделать swap на DEX, внести токен в протокол стейкинга или лендинга, добавить ликвидность в liquidity pool, участвовать в фарминге или любой другой DeFi-операции, где контракт должен перемещать токены «за вас».
Когда вы подтверждаете транзакцию approve, в блокчейн записывается следующая информация: адрес spender (тот, кому разрешено тратить), allowance (лимит суммы), адрес токена (конкретный контракт ERC-20) и адрес владельца (ваш кошелёк). Это не широкое разрешение «на всё». Это строго адресованное разрешение на конкретный токен конкретному адресу до конкретной суммы.
Представьте простой пример: у вас 500 USDT. Вы хотите обменять 100 USDT на ETH через Uniswap. Вместо того чтобы сразу переводить деньги, вы выдаёте контракту Uniswap «доверенность»: «разрешаю тебе взять до X USDT из моего кошелька, когда понадобится для обмена». Это и есть token approval — не перевод, а право на списание.
Это различие принципиально важно, и его не понимает большинство новичков. Когда вы нажимаете Approve, токены никуда не уходят. Ваш баланс не меняется. Единственное, что происходит — в блокчейне появляется запись: «адрес X имеет право списать у меня до Y единиц токена Z». Реальный перевод токенов происходит позже, отдельной транзакцией — через механизм transferFrom.
Именно это и делает approve потенциально опасным: вы разрешили, но не сразу видите последствий. Если вы дали разрешение честному протоколу — всё хорошо. Если мошенническому или взломанному — ваши токены в опасности, хотя в момент подписания вы ничего не почувствовали.
Важная хорошая новость: approve токена для DeFi — это не разрешение «на весь кошелёк». Если вы одобрили право на USDT контракту Uniswap, это не означает, что Uniswap может взять ваш ETH, BTC или любой другой токен. Каждый approve — это точечное разрешение. Токен A отдельно, токен B отдельно, каждый spender отдельно.
Это архитектурная защита, встроенная в ERC-20. Но она не исключает риска: если вы дали unlimited allowance на USDT мошенническому spender’у — он может вывести весь ваш USDT, хотя ETH останется нетронутым. Подробнее о том, что такое DeFi и как устроены децентрализованные финансы в целом, — в отдельном разборе.
Allowance — это просто цифра. Число, хранящееся в смарт-контракте токена, которое говорит: «владелец A разрешил spender’у B потратить до N единиц токена». После каждой операции, которую выполняет spender через transferFrom, это число уменьшается на потраченную сумму. Когда allowance достигает нуля — spender больше ничего не может взять без нового approve.
Чтобы проверить текущий allowance, достаточно вызвать функцию allowance(owner, spender) в контракте токена — это публичная информация, доступная на любом блокчейн-эксплорере. Что важно понять: allowance не «истекает» автоматически. Если вы дали разрешение год назад и не отозвали его — оно до сих пор действует.
Spender в контексте ERC-20 — это адрес смарт-контракта, который получил право использовать transferFrom для списания ваших токенов. В роли spender’а может выступать контракт DEX (Uniswap, Curve, dYdX), контракт протокола лендинга (Aave, Compound), мост между блокчейнами, контракт фарминга или стейкинга, агрегатор (1inch, Paraswap) — и, к сожалению, мошеннический контракт, если вы дали ему разрешение.
Именно поэтому одна из первых вещей, которую нужно проверять при любом approve, — это адрес spender’а. Не только «что за протокол», но и «это тот адрес контракта, которому я доверяю?».
Это два взаимосвязанных механизма стандарта ERC-20, которые работают в паре. Approve устанавливает разрешение. TransferFrom использует это разрешение для фактического перемещения токенов. Без approve выполнить transferFrom невозможно — контракт токена отклонит транзакцию.
Классическая цепочка действий: пользователь вызывает approve(spender, amount) → контракт DEX вызывает transferFrom(user, recipient, amount) → токены перемещаются → allowance уменьшается. Именно эта цепочка работает при каждом обмене токенов на DEX, при депозите в лендинговый протокол и при добавлении в пул ликвидности.
Это ключевой момент, который упускают новички. Approve устанавливает лимит, а не «одноразовое разрешение». Если вы одобрили 1000 USDT, контракт может несколько раз вызывать transferFrom: сначала на 200 USDT, потом ещё на 300 USDT, потом ещё — пока суммарное списание не достигнет 1000 USDT. При этом вы не будете получать запрос на подтверждение при каждом таком шаге.
Если же вы дали unlimited allowance (технически это максимальное значение uint256 — огромное число), контракт теоретически может вызывать transferFrom бесконечное количество раз на любые суммы в пределах вашего реального баланса. Понимание этого механизма — половина пути к безопасной работе с DeFi.
Интерфейс большинства кошельков и dapp до недавнего времени скрывал детали одобрения за лаконичной кнопкой. Пользователь видел «Approve USDT» — и жал подтвердить. Сколько именно USDT разрешено? На какой срок? Какому конкретно адресу? Что произойдёт, если этот адрес окажется мошенническим? Эти вопросы даже не возникали.
Проблема не только в интерфейсах — она в самой природе разрешений, которые существуют «невидимо». После того как вы нажали кнопку Approve и вышли с сайта, разрешение никуда не делось. Оно живёт в блокчейне столько, сколько нужно. Неделю, год, десять лет. До тех пор, пока вы явно не отзовёте его через revoke.
Unlimited allowance — это approve на максимально возможное значение. Технически это type(uint256).max, число настолько большое, что на практике оно никогда не исчерпается вашим балансом. Многие dapp запрашивают именно его по умолчанию: удобно для UX, не нужно каждый раз платить газ за новый approve.
Но что происходит при взломе протокола или при мошенничестве? Если spender — взломанный или изначально мошеннический контракт, и у него есть unlimited approval на ваш USDT, он может вывести весь ваш баланс одним вызовом transferFrom. Ваш кошелёк при этом не выдаст никакого предупреждения: транзакция технически легитимна. Именно это и называют approve scam — кража через уже выданное разрешение.
Чем опасен unlimited allowance для новичка в 2026 году — это не абстрактный риск. Взломы протоколов происходят регулярно; список пострадавших исчисляется миллиардами долларов совокупных потерь. Причём пострадавшие — это не только те, кто активно использовал протокол в момент взлома, но и те, кто давал approve год назад и давно забыл о нём.
Представим реальный сценарий. Вы использовали легитимный протокол год назад, дали ему unlimited approval на USDT. Позже протокол был скомпрометирован: хакеры получили контроль над контрактом-spender’ом. Ваш кошелёк никуда не подключён, приватный ключ в безопасности — но разрешение всё ещё висит. Хакеры вызывают transferFrom на ваш адрес и забирают весь USDT.
Это не гипотетический сценарий. Это механизм, который реально применяется при крупных DeFi-взломах. Ваша личная безопасность — ключи, seed phrase, устройство — здесь совершенно ни при чём. Уязвимость лежит в области разрешений на списание.
Ещё более прямой сценарий — approve phishing и signature phishing. Пользователь переходит на фишинговый сайт, внешне идентичный реальному DEX или airdrop-странице. Сайт просит подключить кошелёк и «одобрить» токены. Пользователь одобряет — и на этом мошенничество завершено: spender получил разрешение на списание. Дальше — вопрос времени, когда и сколько будет выведено.
Это принципиально отличается от классической кражи приватного ключа или seed phrase. Здесь не нужно взламывать кошелёк — пользователь сам добровольно выдал разрешение. Именно поэтому фишинг через approve стал таким популярным: его невозможно заблокировать на уровне кошелька без специальных инструментов анализа транзакций. Подробнее о том, как распознать криптомошенничество в 2026 году — в отдельном материале.
«Я уже не пользуюсь этим протоколом» — не означает, что разрешение исчезло. Можно ли потерять токены из-за старых разрешений? Да, абсолютно реально. Каждый approve, который вы когда-либо выдали и не отозвали, — это потенциальная точка уязвимости. Даже если протокол был честным в момент использования, он мог быть взломан позже. Даже если вы думаете, что «это было небольшое разрешение» — возможно, это было unlimited allowance, о котором вы уже забыли.
С точки зрения протокола, unlimited approval — это решение UX-проблемы. Каждый новый approve стоит газа. При частом использовании платформы это накапливается в существенную сумму. Если пользователь даёт unlimited allowance один раз, он больше никогда не платит за одобрение этого токена на этом протоколе. Для активного трейдера на DEX это реальная экономия.
Именно поэтому большинство популярных протоколов устанавливают unlimited allowance по умолчанию. Это не злой умысел — это прагматика UX. Но протокол не несёт ответственности за последствия взлома, которые вытекают из вашего старого approve. Эту ответственность вы берёте на себя в момент подтверждения.
Если вы активно используете конкретный trusted-протокол: торгуете на Uniswap каждую неделю, регулярно делаете депозиты в Aave — unlimited allowance снимает необходимость платить за approve при каждой операции. Это разумный компромисс при условии, что: вы доверяете протоколу, вы регулярно мониторите его статус, вы знаете, как быстро сделать revoke при необходимости.
Если вы пробуете новый протокол впервые — никогда не давайте unlimited allowance. Ставьте ровно ту сумму, которую собираетесь использовать в конкретной операции. Да, при следующей операции нужен будет новый approve с газом. Но это — страховка от неизвестного. Неизвестный контракт не стоит доверия безлимитного доступа к вашим токенам.
Ответ однозначный: точный лимит. Для новичка, который ещё изучает DeFi и пробует разные протоколы, custom spend limit — это базовое правило гигиены. Да, вы будете чаще платить газ. Но вы сильно снижаете масштаб потенциального ущерба при любой проблеме. Современные кошельки типа MetaMask и Rabby позволяют вручную указать spending cap — используйте эту функцию.
Когда вы нажимаете «Connect Wallet» на сайте dapp, вы делаете следующее: разрешаете сайту видеть ваш публичный адрес, разрешаете интерфейсу предлагать вам транзакции для подписи, не даёте никаких прав на ваши токены. Connect Wallet — это сугубо интерфейсное действие. Оно не записывается в блокчейн, не стоит газа, не создаёт никаких разрешений на списание.
Это критически важное понимание, которое спасает от паники и от неправильных действий. Если вы «подключили кошелёк» к dapp — ваши токены в безопасности, пока вы не подтвердили транзакцию approve или permit.
Sign — более коварная операция. Когда dapp просит вас «подписать сообщение», вы создаёте криптографическую подпись вашим ключом, которая может иметь разные последствия в зависимости от содержания. Подпись может быть безобидной: просто доказательство владения адресом для авторизации на сайте. Но подпись может также содержать permit — изменение allowance без отдельной транзакции, или другие инструкции смарт-контракту.
Именно на этом строится signature phishing: мошенники показывают пользователю окно «подпиши сообщение», которое внешне выглядит как обычная авторизация, но внутри содержит permit на огромную сумму. Пользователь подписывает — и это обходится без газа и без явной транзакции в блокчейне, но последствия могут быть катастрофическими.
Approve в отличие от connect и sign — это полноценная ончейн-транзакция, которая стоит газа и постоянно хранится в блокчейне до явного отзыва. После approve spender может в любой момент вызвать transferFrom и забрать токены в рамках установленного allowance. Это реальное изменение состояния блокчейна, а не просто «авторизация» или «подпись».
Permit (EIP-2612) — это элегантное улучшение механизма approve. Вместо отдельной ончейн-транзакции, которая стоит газ, пользователь создаёт офчейн-подпись, которая содержит все параметры approve: owner, spender, value, deadline, nonce. Эту подпись контракт DEX принимает и сам вызывает permit() внутри своей транзакции.
Практический результат: пользователь экономит одну транзакцию и газ за approve. DEX делает всё в одной операции. Это удобно — но несёт новый вид риска: если вы подписали permit на фишинговом сайте, атакующий получил «бумагу с вашей подписью», которую может использовать в любой момент.
Интерфейсы большинства dapp и кошельков исторически плохо объясняли разницу между connect, sign, approve и permit. Всё сводилось к «нажмите кнопку для продолжения». В результате у пользователей сложилось ложное представление: «подключил кошелёк — значит, дал все права» или «нажал отмену — значит, ничего не дал». Обе концепции опасно неточны.
Реальность: connect не даёт прав, revoke кошелька от dapp не отменяет allowances, подпись сообщения может быть approve, а простой визуальный «disconnect» в интерфейсе MetaMask — не то же самое, что ончейн-отзыв разрешения.
Стандартный approve имеет один существенный недостаток: это отдельная транзакция, которая стоит газ и требует времени. Для пользователя, который хочет сделать простой swap, это два шага вместо одного: сначала approve, потом swap. EIP-2612 решил эту проблему, введя permit — функцию, которая принимает подпись и устанавливает allowance в одной транзакции с операцией.
По сути, permit переносит шаг «выдачи разрешения» с уровня отдельной транзакции на уровень подписи сообщения. Это уменьшает количество транзакций, снижает газовые затраты и улучшает UX. Но главный риск остаётся: если вы подписываете permit на большую сумму или в пользу неизвестного spender’а, последствия те же, что и при обычном approve.
До появления permit типичный DeFi-опыт выглядел так: шаг 1 — approve (транзакция + газ + ожидание), шаг 2 — swap или deposit (транзакция + газ + ожидание). С permit второй шаг включает подпись разрешения внутри себя: вы просто подписываете одно сообщение и подтверждаете одну транзакцию. Газ за approve не платится. Время сокращается вдвое.
Permit2 — это разработка Uniswap, которая пошла дальше EIP-2612. Идея: вместо того чтобы каждый протокол внедрял permit в свой токен (а старые токены EIP-2612 не поддерживают), создаётся единый посреднический контракт — сам Permit2. Пользователь один раз одобряет контракт Permit2 (часто через max approval), а дальше все протоколы, интегрированные с Permit2, работают через него, используя только подписи.
По-человечески: вы один раз говорите «Permit2, я доверяю тебе управлять моими USDT», а дальше каждый dapp, который работает через Permit2, просит уже не ончейн-approve, а подпись, которую Permit2 верифицирует. Это экономит газ, унифицирует опыт и добавляет функции срока действия.
Permit2 реализует две модели взаимодействия. SignatureTransfer — одноразовая схема: каждая операция требует отдельной подписи, которую нельзя использовать повторно (защита через nonce). Это близко к классическому permit: подписал один раз — один раз использовали. Идеально для разовых операций с максимальной безопасностью.
AllowanceTransfer — традиционная модель allowance, но с новыми параметрами: expiry (срок действия) и лимит суммы. Вы устанавливаете allowance на Uniswap через Permit2, указываете сумму и дату истечения. После этой даты разрешение автоматически недействительно — даже без явного revoke. Это expiring approvals — один из главных новшеств Permit2. Также важен batch revoke permit2: можно отозвать сразу несколько разрешений одной транзакцией, что экономит газ.
Permit2 не делает разрешения «невидимыми» или «неопасными». Удобство — это не синоним безопасности. Да, разрешения теперь могут иметь срок. Да, подписи одноразовые. Но: вы всё ещё должны понимать, что именно вы подписываете, кому именно вы даёте право через AllowanceTransfer, какой срок вы устанавливаете, и — главное — что первоначальный approve самого контракта Permit2 нередко делается через max approval.
Технически грамотный пользователь понимает: Permit2 — это более гибкий инструмент, но не волшебная защита. Если вы подписали allowance transfer с большим лимитом и длинным сроком в пользу протокола, который потом был взломан — Permit2 не спасёт. Спасут только правильно установленные параметры: минимально необходимый лимит и короткий срок expiry.
Ключевой момент: когда вы первый раз даёте approve на контракт Permit2 (часто через max approval ради UX) — вы фактически открываете «главный ключ». Дальнейшая безопасность полностью зависит от того, что именно вы подписываете при каждом использовании Permit2-совместимого протокола.
Мошеннический сайт может попросить вас подписать AllowanceTransfer в пользу мошеннического spender’а через Permit2. Внешне это выглядит как обычная подпись — «просто разрешить обмен». На деле вы даёте allowance мошеннику на всю сумму на длинный срок.
Типичные ошибки при работе с Permit2: принимать окно подписи как безобидную операцию без проверки параметров; не смотреть на поле spender в подписи (это может быть мошеннический адрес); не обращать внимания на поле expiry — некоторые протоколы ставят срок в несколько лет; не проверять, какой именно токен и какая сумма указаны.
Если операция разовая — лучше SignatureTransfer. Нет смысла создавать постоянный allowance ради одного свопа. Одноразовая подпись не оставляет «висящего» разрешения, которое нужно потом отзывать.
Существуют специализированные инструменты — token approval checkers — которые показывают все активные approvals по вашему адресу в конкретной сети. Они читают публичные данные блокчейна и отображают список: токен, spender, сумма, когда был выдан approve. Некоторые из них также показывают approvals Permit2 и позволяют делать batch revoke.
Важно: каждая сеть — отдельно. Approve в сети Ethereum не отображается в сети Polygon или BNB Chain. Если вы работали в нескольких сетях — проверяйте каждую отдельно.
При проверке активных апрувов смотрите в первую очередь: на amount — особенно на записи «unlimited» или максимальное значение; на spender — знаете ли вы этот контракт, это официальный адрес протокола или неизвестный адрес; на expiration — для Permit2 approvals есть срок; на токен — отдельное внимание стейблкоинам (USDT, USDC) и самым ликвидным позициям.
Приоритет отзыва: unlimited approvals на стейблкоины и ликвидные токены; разрешения в пользу неизвестных или забытых spender’ов; разрешения протоколам, которые были взломаны или закрыты; старые разрешения, выданные более 6–12 месяцев назад и больше не используемые.
Да, обязательно. Если вы когда-либо использовали Ethereum mainnet, Polygon, Arbitrum, Optimism, BNB Chain, Base или другие EVM-сети — у вас могут быть активные approvals в каждой из них. Это особенно актуально для пользователей, которые активно работали с DeFi в периоды высокой активности 2020–2022 годов. Понять, как устроены сети ERC-20 и другие форматы поможет отдельный материал.
Revoke — это ончейн-транзакция, которая устанавливает allowance для конкретного spender’а в ноль (или удаляет разрешение). После revoke spender больше не может вызвать transferFrom по вашим токенам. Это необратимо отменяет ранее выданное разрешение. Никакого «частичного revoke» нет — либо разрешение есть, либо его нет.
Технически revoke — это тот же вызов функции approve(spender, 0). Вы ставите allowance в ноль. Именно поэтому при изменении allowance (не только при обнулении) стандарт ERC-20 рекомендует сначала установить нулевое значение, а потом новое — чтобы избежать «гонки», когда в окне между двумя approve spender может использовать оба разрешения последовательно.
Revoke — это полноценная транзакция в блокчейне. Как любая транзакция, она требует оплаты газа. Обычно это небольшая сумма — операция не сложная. Но при массовом revoke нескольких approvals подряд затраты складываются. Именно поэтому удобен batch revoke в Permit2 — несколько отзывов за одну транзакцию.
Это, пожалуй, самое важное непонимание в теме безопасности кошельков. Когда вы «отключаете» dapp в MetaMask (или в любом другом кошельке) — вы просто убираете разрешение сайту видеть ваш адрес и предлагать транзакции. Это интерфейсное действие, которое не влияет на блокчейн.
Allowance, выданный spender-контракту, остаётся в силе. Spender-контракт не «подключён» к вашему кошельку в интерфейсном смысле — он работает напрямую с блокчейном. Disconnect не влияет на его способность вызвать transferFrom. Единственный способ убрать это право — revoke через ончейн-транзакцию.
Срочный revoke нужен в следующих ситуациях: вы подключили кошелёк к подозрительному сайту и подтвердили approve; вы узнали, что протокол, которому давали разрешение, был взломан; вы обнаружили approve в пользу неизвестного spender’а; вы случайно подписали permit с большой суммой. Действовать нужно быстро: пока ваши токены ещё на адресе.
Если вы активно пользуетесь протоколом, но unlimited allowance кажется избыточным — можно не удалять разрешение, а уменьшить его до разумного уровня. Например, с unlimited до суммы, которую вы планируете потратить в ближайший месяц. Это называется custom spend limit — ряд кошельков позволяет установить его прямо в интерфейсе. Но при любом изменении allowance помните про рекомендацию стандарта: сначала обнулить, потом выставить новое значение.
Первый приоритет — все unlimited approvals. Особенно на стейблкоины (USDT, USDC, DAI) и на наиболее ликвидные токены в вашем портфеле. Это наибольший потенциальный ущерб при любом сценарии: взломе, мошенничестве или случайном approve на фишинговом сайте.
Если протокол, которому вы давали разрешение, больше не существует, был закрыт, менял версии контрактов или просто не используется больше года — разрешение надо отозвать. Старые контракты — это техническая задолженность безопасности. Они могут оказаться устаревшими, уязвимыми или просто ненужными.
Если при проверке вы видите адрес spender’а, который не можете идентифицировать — это красный флаг. Возможно, это разрешение, выданное через мошеннический сайт или через подписанный permit, содержание которого вы не проверили. Такие разрешения надо отзывать немедленно.
Мосты между блокчейнами, DEX-агрегаторы, протоколы фарминга и лендинга — все они запрашивают approve при первом использовании. Если вы провели операцию и больше не планируете возвращаться — отзовите разрешение. Это чистая гигиена: не оставлять открытые разрешения протоколам, которые больше не используете.
Стейблкоины — главная цель мошенников именно потому, что их можно немедленно продать или перевести. Unlimited approval на USDT у мошеннического spender’а — это прямой доступ к вашим средствам. Среди всех токенов приоритет revoke стоит отдавать именно стейблкоинам. Вопрос о том, где хранить USDT и Bitcoin безопасно, напрямую связан с управлением апрувами.
Вы сделали своп на Uniswap месяц назад, дали unlimited approval на USDT — и забыли об этом. Разрешение до сих пор активно. Что делать: зайти в инструмент проверки approvals, найти это разрешение, сделать revoke. Если Uniswap — доверенный протокол, который вы продолжаете использовать, можно оставить, но уменьшить лимит до разумной суммы.
Это один из самых распространённых сценариев approve scam в 2026 году. Вы увидели рекламу airdrop, зашли на сайт, нажали «Connect» — и потом «Approve» или «Claim». Если вы не успели подтвердить транзакцию — всё хорошо, disconnect спасает. Если подтвердили approve — действуйте немедленно: проверьте адрес spender’а в approve, сразу отзовите разрешение, проверьте, не успел ли контракт вызвать transferFrom. Как действовать при других мошеннических схемах, разобрано в материале о том, как не потерять крипту в 2026 году.
Вы видели окно «Sign message» в кошельке, внутри которого было много непонятных полей. Нажали подписать, не разобравшись. Если это был permit через EIP-2612 или AllowanceTransfer через Permit2 — вы, возможно, только что выдали разрешение spender’у. Что делать: найти транзакцию в истории кошелька (или в эксплорере), определить параметры подписи, проверить активные approvals через инструмент, при необходимости сделать revoke. О том, что такое TXID и как читать транзакции в блокчейне, поможет отдельный материал.
После работы с Uniswap v3 или v4 (которые используют Permit2) у вас могут остаться как ончейн-approvals на сам контракт Permit2, так и AllowanceTransfer-разрешения внутри Permit2. Проверьте оба уровня: стандартный approve на Permit2 и разрешения внутри Permit2. Второй уровень виден только в инструментах, которые специально поддерживают permit2 revoke. Используйте batch revoke permit2 для экономии газа.
Это самое разумное решение для активных пользователей DeFi. Отдельный Web3-кошелёк — hot wallet с небольшим балансом, достаточным для конкретных операций — изолирует риски. Даже если вы дали неправильный approve, потери ограничены суммой на этом кошельке. Основной резерв хранится отдельно, в холодном хранении или кастодиальном кошельке. Логику организации нескольких кошельков для разных целей подробно разбирает отдельный материал.
Базовое правило: approve только той суммы, которую собираетесь потратить прямо сейчас. Если планируете обменять 100 USDT — ставьте custom spend limit 100 USDT, максимум 110–120 с небольшим запасом. Да, при следующей операции придётся снова платить газ за approve. Нет, это не катастрофа — это страховка.
Hot wallet для dapp-операций — обязательный элемент архитектуры безопасного хранения. Никогда не используйте для Web3-взаимодействий тот кошелёк, где хранится основной резерв. Разделение по назначению — один из ключевых принципов, который подробно раскрыт в материале о том, как хранить крипту безопасно.
Это логическое следствие предыдущего пункта. Web3-кошелёк должен содержать только операционные средства: сколько нужно для конкретных сессий в DeFi. Остальное — в холодном хранении или на кастодиальном счёте. Так потенциальный ущерб от любого неправильного approve ограничен.
Раз в месяц или раз в квартал — заходите в инструмент проверки approvals и очищайте ненужные разрешения. Это занимает 10–15 минут и несколько долларов на газ. Стоимость этой процедуры несопоставима с потенциальными потерями от старого unlimited allowance на взломанном протоколе.
При каждом новом approve четыре вопроса: кому (адрес spender — это официальный контракт?), что (какой токен я одобряю?), сколько (какой лимит — точный или unlimited?), срок (для Permit2 — какой expiry?). Эти четыре секунды внимания могут предотвратить потерю всего баланса токена.
Любое окно «Sign message» заслуживает внимательного изучения. Что именно в нём написано? Есть ли поля spender, value, deadline? Если есть — это, скорее всего, permit или Permit2 AllowanceTransfer, а не безобидная авторизация. Проверьте адрес spender’а, прежде чем подписывать.
«Я просто подключил кошелёк — ничего страшного не произошло» — это правда, если вы только нажали Connect. Но если потом был approve или sign — последствия уже зависят от содержания подписанного. Понимание разницы между connect и approve — базовая грамотность Web3.
Disconnect в интерфейсе кошелька убирает видимость адреса для сайта. Revoke allowance — отзывает ончейн-разрешение на списание токенов. Это два разных действия с разными последствиями. Первое бесплатно и мгновенно. Второе — ончейн-транзакция с газом. Disconnect без revoke не защищает токены от уже выданных allowances.
Скорость не стоит безопасности. Unlimited allowance удобен при регулярной работе с trusted-протоколом — и опасен при любом другом сценарии. Для новых протоколов, разовых операций и любых сервисов, в которых вы не уверены на 100% — только точный лимит.
Иногда фишинговые сайты конструируют approve так, что пользователь думает, что одобряет обмен одного токена, а на деле approves совершенно другой — более ценный. Всегда смотрите на название токена в окне подтверждения, не только на надпись на кнопке.
Это самая критичная ошибка. Даже если сайт выглядит как Uniswap — adres spender’а в approve может указывать на мошеннический контракт. Привычка проверять адрес контракта в блокчейн-эксплорере перед подтверждением approve — ключевой навык безопасной работы в DeFi. Понять, как читать адреса и проверять данные кошелька, помогает материал о том, что такое адрес кошелька в криптовалюте.
Если на кошельке, которым вы взаимодействуете с dapp, хранится весь ваш резерв — любой неудачный approve ставит под угрозу всё. Разделение кошельков по назначению — не параноя, а разумная архитектура безопасности. Подробнее об этом подходе рассказывает материал о том, как организовать криптокошельки новичку.
Approve — это нормальный, необходимый инструмент Web3. Без него невозможна работа ни одного DEX, ни одного DeFi-протокола, ни одного лендингового сервиса. Проблема не в кнопке как таковой. Проблема в непонимании: кому, на какой токен, на какую сумму и на какой срок вы даёте право расходования.
Unlimited allowance у доверенного протокола — это разумный компромисс ради UX. Тот же unlimited allowance у неизвестного spender’а на фишинговом сайте — это открытая дверь для кражи. Разница между этими двумя сценариями — несколько секунд внимания при подтверждении транзакции и привычка периодически проверять и отзывать доступ к токенам.
Permit2 делает опыт удобнее. Но «удобнее» не значит «безопаснее по умолчанию». SignatureTransfer, AllowanceTransfer, expiry, nonce — это инструменты, которые работают на вас, только если вы понимаете, что именно подписываете. Контекст о том, как купить крипту и не переплатить на всём маршруте, а также понимание устройства Ethereum и газа поможет выстроить полную картину безопасной работы в DeFi.
Что значит кнопка Approve в криптокошельке?
Approve — это ваше разрешение конкретному смарт-контракту (spender) расходовать ваши токены до установленного лимита через механизм transferFrom. Это не перевод токенов, а выдача права на списание.
Approve — это перевод токенов или только разрешение?
Только разрешение. При approve токены никуда не уходят, баланс не меняется. Реальное движение токенов происходит позже — через отдельную функцию transferFrom, которую вызывает контракт-spender.
Чем approve отличается от connect wallet?
Connect wallet — интерфейсное действие, которое позволяет сайту видеть ваш адрес. Approve — ончейн-транзакция, записывающая разрешение на расход токенов в блокчейн. Первое не стоит газа и не даёт никаких прав на токены; второе — даёт.
Что такое allowance простыми словами?
Allowance — это цифра, хранящаяся в контракте токена: «владелец A разрешил контракту B потратить до N токенов». Уменьшается при каждом transferFrom. Не исчезает автоматически с течением времени.
Что такое unlimited allowance и почему он опасен?
Unlimited allowance — это approve на максимально возможное значение (type(uint256).max), которое никогда не исчерпается. Опасен тем, что при взломе или мошенничестве spender может вывести весь баланс токена одной транзакцией.
Можно ли украсть USDT через approve?
Да. Если у мошеннического или взломанного контракта есть неотозванный approve на ваш USDT — он может вызвать transferFrom и перевести весь ваш USDT себе. Ваш приватный ключ и seed phrase при этом остаются нетронутыми.
Что такое Permit2 и чем он отличается от обычного approve?
Permit2 — это контракт-посредник от Uniswap, через который протоколы работают с вашими токенами по подписям, без отдельных ончейн-approve для каждого протокола. Он добавляет срок действия (expiry) и одноразовые подписи (SignatureTransfer), но требует одного стартового approve на сам Permit2-контракт.
Чем revoke отличается от disconnect?
Disconnect — убирает интерфейсный доступ сайта к вашему адресу, не влияет на блокчейн. Revoke — ончейн-транзакция, устанавливающая allowance в ноль. Только revoke действительно лишает spender’а права на ваши токены.
Нужно ли отзывать approve после каждого swap?
Не обязательно после каждого, но рекомендуется периодически. Если протокол доверенный и вы пользуетесь им регулярно — разумно оставить разрешение, но ограничить сумму. Если это был разовый опыт с новым протоколом — лучше отозвать.
Почему revoke требует gas?
Revoke — это ончейн-транзакция (вызов approve с нулевым значением). Любая запись в блокчейн требует оплаты вычислительных ресурсов сети — газа. Размер платы зависит от загруженности сети в момент отзыва.
Как проверить, кому я уже дал доступ к токенам?
Через специализированные инструменты token approval checker — они читают публичные данные блокчейна и отображают все активные approvals для вашего адреса: токен, spender, сумму, дату выдачи. Проверять нужно в каждой сети отдельно.
Какие approvals надо отзывать в первую очередь?
Unlimited approvals на стейблкоины и ликвидные токены; разрешения неизвестным или забытым spender’ам; разрешения протоколам, которые были взломаны или закрыты; старые разрешения, выданные более года назад.
Безопаснее ли approve на точную сумму, чем unlimited approval?
Да, значительно безопаснее. Точный лимит ограничивает максимальный ущерб при любом неблагоприятном сценарии — взломе протокола, мошенничестве, ошибке. Единственный минус — придётся чаще платить газ за новые approve.
Можно ли потерять токены из-за подписи permit?
Да. Подпись permit содержит параметры approve (spender, value, deadline) и позволяет spender’у установить allowance без отдельной ончейн-транзакции от вас. Если вы подписали permit на фишинговом сайте — мошенник получил «бумагу с вашей подписью», которую может предъявить контракту токена и получить разрешение на списание. Защита: всегда проверяйте поля spender, value и deadline в окне подписи, прежде чем нажимать «Подписать».
Что делать, если я уже дал approve подозрительному сайту?
Действуйте немедленно: откройте инструмент проверки approvals, найдите подозрительное разрешение по адресу spender’а или по времени выдачи, сделайте revoke — ончейн-транзакцию с установкой allowance в ноль. Если между approve и revoke прошло мало времени и контракт ещё не вызвал transferFrom — ваши токены в безопасности. Если списание уже произошло — токены восстановить невозможно, блокчейн необратим. Параллельно переведите оставшиеся активы на чистый кошелёк. Подробнее о том, как распознать криптомошенничество и не попасть в ловушку фишинга — в отдельном разборе.
Итоговый тезис: Approve — нормальный и необходимый инструмент Web3. Опасен не сам механизм, а непонимание его работы. Каждый раз, когда вы видите кнопку Approve в криптокошельке, задайте себе четыре вопроса: кому, на какой токен, на какую сумму и на какой срок. Это займёт десять секунд — и может сэкономить весь ваш баланс.
Популярные лонгриды:
