Все новости крипты
в одном месте!
Больше не нужно искать — необходимые
обучающие материалы и подсказки всегда под рукой
Больше не нужно искать — необходимые
обучающие материалы и подсказки всегда под рукой
Вы делаете своп на Uniswap, и кошелёк вдруг показывает не привычный approve, а что-то другое — запрос на подпись, в котором мелькает слово Permit2. Что это? Опасно ли? Это тот же approve, только с другим названием, или принципиально другая механика? Именно здесь у большинства пользователей DeFi заканчивается понимание и начинается тревога. Эта статья написана для того, чтобы тревога уступила место ясности.
Permit2 — это не «новый тип монеты» и не «новая сеть». Это отдельный смарт-контракт от Uniswap, который создаёт промежуточный уровень между вашим кошельком и dApp при работе с разрешениями на токены. Он объединяет две разные модели: одноразовые подписи на конкретные операции и настраиваемые allowances с лимитом суммы и срока.
Permit2 удобнее стандартного approve с точки зрения гибкости и UX. Но он не делает разрешения «невидимыми» или «автоматически безопасными». Понять разницу — значит принимать осознанные решения при каждом взаимодействии с DeFi.
Давайте начнём с самого начала — без технического жаргона, но с достаточной точностью, чтобы модель в голове сложилась правильно.
В мире EVM-совместимых блокчейнов (Ethereum, BNB Chain, Polygon, Arbitrum и другие) действует жёсткое правило: смарт-контракт не может взять ваши ERC-20 токены без вашего явного разрешения. Никак. Это не недостаток системы — это архитектурная защита.
Когда вы хотите что-то сделать через dApp — обменять токен, добавить ликвидность, занять под залог — контракт должен иметь право «взять» ваш токен и что-то с ним сделать. Для этого существует механизм approve: вы подписываете транзакцию, которая записывает в блокчейн: «Контракту X разрешено тратить N токенов от моего имени».
Это работало. Но у стандартного approve есть несколько неудобств, которые со временем стали ощутимее. И Permit2 появился именно как ответ на эти неудобства.
Permit2 — это развёрнутый Uniswap набор смарт-контрактов, который создаёт промежуточный слой управления разрешениями. Вместо того чтобы давать approve напрямую каждому dApp, пользователь один раз одобряет сам Permit2-контракт, а дальше взаимодействие с различными протоколами происходит через него — более гибко и с дополнительными опциями контроля.
Думайте об этом так: раньше вы давали ключ от квартиры каждому курьеру отдельно. Теперь вы сдаёте ключ консьержу (Permit2), а консьерж пропускает курьеров на строго определённых условиях: только этот человек, только в это время, только до этой комнаты.
Permit2 официально описывается как механизм, объединяющий SignatureTransfer и AllowanceTransfer — две внутренние логики работы с разрешениями. Понимание каждой из них и есть ключ к пониманию всего Permit2.
Это главный блок статьи. Именно здесь прячется вся путаница — и именно здесь она разрешается.
Стандартный approve — это транзакция в блокчейне вида approve(spender, amount):
spender — адрес контракта, которому вы выдаёте разрешениеamount — сколько токенов он может потратитьЭта запись живёт в самом контракте токена. Она бессрочна — пока вы её не отзовёте через revoke. Она ничем не ограничена по времени. Если сумма была выставлена в «максимум» (unlimited) — contракт может тратить сколько угодно ваших токенов этого типа в любой момент.
Чтобы понять, что такое approve и как работают allowances, — там разобрана вся механика стандартных разрешений от базы до revoke.
Главные ограничения стандартного approve:
Именно для решения этих ограничений появился Permit2.
С Permit2 схема выглядит иначе. Один раз пользователь выдаёт approve токена самому Permit2-контракту. Это обязательный шаг — без него transfer-функции Permit2 работать не будут.
После этого все взаимодействия с dApp, которые интегрировали Permit2, могут происходить через него — двумя способами:
Первый способ — SignatureTransfer. Это одноразовая подпись, привязанная к конкретной операции. Она действует только в рамках той транзакции, в которой была использована. После этого — сгорает. Никакого постоянного allowance не создаётся.
Второй способ — AllowanceTransfer. Это allowance, выданный через Permit2, с настраиваемым лимитом суммы и сроком действия. Ближе к стандартному approve, но более контролируемый: есть лимит по времени, можно задать точную сумму, можно ограничить spender.
Принципиальная разница с обычным approve заключается в том, что Permit2 добавляет гибкость: возможность выдавать как одноразовые, так и долгосрочные разрешения, с явными ограничениями.
| Параметр | Стандартный ERC-20 approve | Permit2 SignatureTransfer | Permit2 AllowanceTransfer |
|---|---|---|---|
| Тип действия | Ончейн-транзакция | Офчейн-подпись | Офчейн-подпись + ончейн-запись |
| Срок действия | Бессрочно | Только текущая транзакция | Настраиваемый срок |
| Одноразовость | Нет | Да | Нет |
| Газ при выдаче | Да | Нет (только газ на сам перевод) | Нет |
| Риск «забытого» allowance | Высокий | Нет | Есть (но с дедлайном) |
| Нужен approve Permit2? | Нет | Да | Да |
Это сердце всей архитектуры. Разберём каждую часть отдельно — без программного кода, но с пониманием логики.
Представьте, что вы выдаёте доверенность на конкретную сделку — не на все будущие сделки, а именно на эту, прямо сейчас, один раз. Документ подписан, передан, использован — и уничтожен автоматически.
Именно так работает SignatureTransfer в Permit2.
Пользователь подписывает сообщение (офчейн-подпись — без газа), которое содержит:
Эта подпись действительна только в рамках одной транзакции. Как только транзакция выполнена — подпись «сгорает». Спустер не может использовать её снова. Нет постоянного allowance. Нет «вечно открытой двери».
Ключевое преимущество SignatureTransfer: разрешение живёт ровно столько, сколько длится транзакция. После этого оно перестаёт существовать. Никакого накопленного риска.
Важная оговорка: это не значит, что подпись безопасна «по умолчанию». Если пользователь подписывает фишинговое сообщение — атакующий получает рабочую подпись и может выполнить через Permit2 транзакцию с вашими токенами. Механизм не защищает от подписи «не того».
AllowanceTransfer — более привычный механизм для тех, кто знаком со стандартным approve. Это тоже allowance, но через Permit2, и с дополнительными параметрами контроля.
Когда pользователь использует AllowanceTransfer, он задаёт:
Это принципиально отличается от стандартного ERC-20 approve: там нет встроенного срока. Здесь — есть. Это значит, что даже если вы забудете сделать revoke — в определённый момент разрешение автоматически истечёт.
Где AllowanceTransfer особенно полезен: в регулярных операциях, где нужно выдать разрешение на несколько операций в течение определённого периода — например, для подписки или периодических платежей в DeFi. Один раз подписываете — и несколько операций проходят без повторного approve, но с ограниченным горизонтом.
В обоих механизмах Permit2 используется nonce — уникальный идентификатор, который предотвращает «replay attack». Атакующий не может взять уже использованную подпись и применить её повторно: каждая подпись имеет свой nonce, и после использования он помечается как «отработанный».
В SignatureTransfer это особенно важно: одноразовость подписи гарантируется именно через механизм nonce.
Чтобы по-настоящему понять Permit2, полезно понять, какую именно проблему он решал. Это не техническая история — это история о пользователе, который делает DeFi.
В мире стандартного ERC-20 approve перед каждым взаимодействием с новым dApp нужен отдельный approve. Зашли на новый DEX — approve. Решили попробовать новый bridge — approve. Новый стейкинг-протокол — approve. Каждый approve — это отдельная ончейн-транзакция, которая стоит газа.
Для активного DeFi-пользователя это накапливается в сотни транзакций в год. И каждая из них оставляет запись в блокчейне, которую впоследствии нужно отслеживать.
Современные DeFi-операции всё реже бывают «простыми». Swap через несколько пулов, bridge с автоматической конвертацией, сложный yield-маршрут — всё это требует, чтобы несколько контрактов последовательно получали доступ к токену.
При стандартном approve вам нужен approve для каждого контракта в цепочке. С Permit2 достаточно одного approve самого Permit2-контракта, а дальше маршрут строится через него — без необходимости делать approve для каждого роутера.
Uniswap прямо объясняет интеграцию Permit2 с Universal Router именно через эту логику: убрать необходимость в прямых token approvals к самому роутеру. Пользователь approve’ирует один раз — и сложный многошаговый маршрут работает через единый механизм.
Стандарт ERC-20 Permit (EIP-2612) позволяет выдавать разрешение через офчейн-подпись без отдельной ончейн-транзакции. Но не все токены его поддерживают. USDT, например, долгое время не имел нативного permit.
Permit2 решает эту проблему универсально: он работает с любым ERC-20 токеном, который уже одобрил Permit2-контракт. Не нужна нативная поддержка permit в самом токене.
Permit2 — это не маркетинг. Это реальное улучшение архитектуры разрешений для конкретных сценариев. Разберём, где улучшение ощутимо.
При использовании SignatureTransfer — разрешение на операцию выдаётся офчейн-подписью. Никакой отдельной approve-транзакции не нужно. Это означает: ноль дополнительного газа на само разрешение. Газ платится только за финальную операцию.
Для пользователей в Ethereum mainnet, где газ ощутим, — это экономия при каждой операции.
SignatureTransfer по природе одноразовый. Это значит, что после каждой операции не остаётся «хвоста» в виде активного allowance. Нет бесконечного списка approvals, который нужно ревокать. Нет накопленного риска от забытых разрешений.
Если вы понимаете, как работает revoke approve, вы оцените этот момент особенно: SignatureTransfer устраняет саму потребность в revoke для этого типа разрешений — потому что allowance не создаётся.
Там, где нужен постоянный allowance (частые операции через один dApp), AllowanceTransfer добавляет то, чего нет в стандартном approve: встроенный дедлайн. Вы сами решаете, до какого момента разрешение действует — и по истечении срока оно автоматически аннулируется.
Это означает меньше «зомби-разрешений» в вашем кошельке: AllowanceTransfer через Permit2 имеет встроенную дату смерти, которую стандартный ERC-20 approve не предусматривает.
Для dApp, которые строят сложные маршруты через несколько протоколов, Permit2 означает: пользователь один раз approve’ирует Permit2-контракт для нужного токена — и дальше все интеграции используют его как посредника. Меньше approve-шума, более чистая история разрешений.
Честность требует говорить о рисках так же подробно, как о преимуществах. Permit2 не устраняет риски — он их перемещает и трансформирует.
Пользователь видит запрос на подпись (не approve-транзакцию) и думает: «Ладно, подпишу — это же бесплатно и, наверное, безобиднее». Это опасное упрощение.
Подпись через Permit2 может давать право на реальное списание токенов. SignatureTransfer позволяет spender-у выполнить transferFrom на основании этой подписи. Если вы подписываете мошенническое сообщение — атакующий получает рабочий инструмент для кражи.
Факт того, что действие оформлено как «подпись», а не как «транзакция», не меняет его последствий. Визуальная форма отличается, но результат — тот же.
По мере роста использования Permit2 в легитимных dApp мошенники стали создавать фишинговые сайты, которые имитируют интерфейс Uniswap или другого популярного DEX. Пользователь видит знакомый запрос подписи — и подписывает. Только это не Uniswap, и подпись уходит мошеннику.
Важно всегда проверять URL в строке браузера и убеждаться, что запрос подписи приходит именно от того dApp, которому вы доверяете.
Если вы использовали AllowanceTransfer — у вас остался allowance через Permit2. Он ограничен по времени, но до истечения срока он активен. Если вы хотите закрыть доступ раньше срока — нужен revoke.
Кроме того, у вас сохраняется базовый approve на сам Permit2-контракт. Это тот первоначальный approve, который вы дали при первом использовании Permit2. Он стандартный ERC-20 approve — и он не ограничен по времени сам по себе.
Это означает: если вы хотите полностью закрыть Permit2-доступ для конкретного токена, нужно:
Revoke.cash поддерживает оба уровня проверки и отзыва.
Стандартный approve — визуально понятен: «Вы разрешаете контракту X потратить N токенов». Permit2-запрос подписи часто выглядит иначе: там строки с параметрами, nonce, deadline, адреса. Новичок не всегда понимает, что именно подписывает.
Это создаёт риск «слепой подписи» — подписи без понимания содержимого. Именно так работает большинство DeFi-краж через Permit2: пользователь видит непонятный запрос и думает «это техническая часть Uniswap» — и подписывает.
Тема слепой подписи — отдельный и очень важный аспект безопасности кошелька, который напрямую связан с Permit2. Всегда читайте, что именно просит подписать dApp. Если видите запрос с параметрами spender, amount, nonce, deadline — это Permit2-подпись, и она имеет реальные последствия для ваших токенов.
Это один из самых частых вопросов по теме. Ответ зависит от того, какой именно механизм использовался.
Одноразовая подпись — одноразовое разрешение. После завершения транзакции разрешение сгорает. Нет allowance — нечего ревокать.
Единственное, что остаётся: базовый approve токена на Permit2-контракт (если он был дан). Он не «сгорает» вместе с подписью.
Здесь allowance создаётся — через Permit2, с дедлайном, но создаётся. До истечения срока он активен. Если вы хотите закрыть доступ раньше дедлайна — нужен revoke внутри Permit2.
Как проверить: Revoke.cash показывает Permit2-разрешения отдельным блоком. Если вы активно пользовались Uniswap v3/v4 или другими Permit2-интегрированными протоколами — обязательно посмотрите этот раздел.
Это стандартный ERC-20 approve, который пользователь выдаёт при первом использовании Permit2. Он записывается в блокчейне как обычный allowance и отображается в стандартных инструментах проверки (Etherscan Token Approvals, Revoke.cash).
Если вы хотите полностью закрыть Permit2-доступ для конкретного токена — ревокайте этот базовый approve. После этого SignatureTransfer и AllowanceTransfer для этого токена через Permit2 будут недоступны, пока вы снова не дадите approve.
| Механизм | Остаётся ли allowance | Нужен ли revoke |
|---|---|---|
| SignatureTransfer | Нет (одноразово) | Нет (для этой подписи) |
| AllowanceTransfer | Да, до дедлайна | Да, если хотите закрыть раньше |
| Базовый approve на Permit2 | Да, бессрочно | Да, если хотите полностью отключить |
Теория — это хорошо. Но давайте пройдёмся по реальным ситуациям, с которыми сталкивается пользователь.
Uniswap просит: «Разрешите USDT для Permit2». Это стандартный approve — вы разрешаете Permit2-контракту работать с вашими USDT. Это одноразовый шаг: в следующий раз при свапе USDT этот approve уже не нужен.
После этого — Uniswap просит подпись. Это уже SignatureTransfer: одноразовое разрешение именно на эту конкретную операцию. Подписываете — и своп выполняется.
Что осталось после: базовый approve USDT для Permit2-контракта. Никакого бесконечного allowance для Uniswap напрямую нет. В следующий раз — только подпись, без нового approve.
dApp объясняет: «Для удобства дайте разрешение на 30 дней». Это AllowanceTransfer — вы подписываете разрешение с лимитом суммы и сроком. Оно активно 30 дней, потом истекает автоматически.
Если через неделю вы захотите закрыть доступ — нужен revoke внутри Permit2 (через Revoke.cash). Если просто ждёте дедлайна — через 30 дней разрешение исчезнет само.
Вы перешли по ссылке из Telegram, сайт выглядит как Uniswap, просит «подписать разрешение». Это Permit2-запрос от мошенников. Подпись создаёт SignatureTransfer — и мошенник немедленно выполняет transferFrom на свой адрес.
Защита: всегда проверяйте URL. Если запрос подписи приходит с незнакомого или похожего-но-не-того домена — это фишинг. Permit2 не спасает от мошенничества — он только меняет форму векторов атаки.
Если случилось худшее и кошелёк был скомпрометирован — что делать если криптокошелёк взломали — там пошаговый алгоритм действий.
Важный нюанс: Permit2 — это не проприетарный механизм только для Uniswap. Другие протоколы также интегрируют его, особенно те, которые используют Uniswap Universal Router или построены на его инфраструктуре.
Это означает: когда вы видите Permit2-запрос — это не обязательно Uniswap. Это может быть любой dApp, который интегрировал этот механизм. Набор протоколов, использующих Permit2, расширяется.
Для пользователя это важно: базовый approve токена на Permit2-контракт выдаётся один раз и работает для всех dApp, интегрировавших Permit2. Это одновременно удобство (не нужно повторять approve) и риск (один контракт с широкими полномочиями).
Если вы активно работаете в DeFi-экосистеме и понимаете, как устроены децентрализованные финансы, — Permit2 станет логичным продолжением этого понимания.
Permit2 — это не изолированная тема. Он встроен в более широкий контекст управления разрешениями кошелька, и понимать его лучше в этом контексте.
Disconnect от dApp не отзывает Permit2-разрешения — точно так же, как не отзывает стандартные ERC-20 approvals. AllowanceTransfer-разрешения остаются активными до дедлайна или явного revoke. Базовый approve Permit2-контракта — тоже.
О том, почему disconnect не отменяет approvals и что реально нужно делать после отключения от dApp, — там детальный разбор всей этой логики.
Если скомпрометирована seed phrase или private key — Permit2 не помогает. Атакующий с доступом к ключу может сам выдавать подписи и использовать Permit2 без ограничений. Что такое seed phrase и почему это самое важное, что нужно защитить — базовый материал для понимания уровней безопасности кошелька.
Выстраивая стратегию безопасного хранения крипты в 2026 году, понимание Permit2 помогает принять правильное решение о том, какой кошелёк использовать для DeFi-операций, а какой — для хранения. Основные средства лучше держать на адресе без истории approve и без Permit2-интеграций.
Если вы пользовались Uniswap или другими Permit2-интегрированными dApp — самое время посмотреть, что у вас там.
Revoke.cash отдельно показывает Permit2-allowances рядом со стандартными ERC-20 approvals. Это важно: они отображаются в отдельном блоке, потому что технически являются разрешениями внутри Permit2-контракта, а не напрямую в контракте токена.
Алгоритм:
Базовый approve токена на Permit2-контракт виден в стандартном Token Approvals checker Etherscan. Spender в этом случае — адрес Permit2-контракта. Если видите его в списке — это нормально, если вы пользовались Uniswap. Можно оставить, если продолжаете пользоваться. Можно ревокнуть, если хотите полностью закрыть Permit2-доступ для этого токена.
Permit2 особенно актуален для тех, кто покупает первые альткоины на DEX. Именно в этом сценарии пользователи чаще всего видят незнакомые запросы подписи и не понимают, что именно подписывают.
Теперь вы знаете: запрос подписи с параметрами spender, value, nonce, deadline — это, скорее всего, Permit2 SignatureTransfer. Это нормальная часть свопа на Uniswap или других DEX с Permit2-интеграцией. Но тот же формат используют и мошенники — поэтому всегда проверяйте домен.
После прочтения этой статьи у вас должна сложиться простая и точная ментальная модель.
Permit2 — это не «более безопасный approve», это более гибкий механизм разрешений. Он предлагает инструменты для более осознанного управления доступом: одноразовые подписи, ограниченные по сроку allowances, единый approval layer.
Безопасность Permit2 определяется тем, как им пользуется конкретный dApp и насколько внимателен пользователь. Правильно интегрированный Permit2 с SignatureTransfer даёт меньше накопленных рисков, чем классический unlimited approve. Но мошеннический Permit2-запрос так же опасен, как мошеннический approve.
Для пользователя это означает: понимать, что именно вы подписываете, проверять Permit2-allowances отдельно при ревизии кошелька и не расслабляться только потому, что dApp использует «современный» механизм разрешений.
Permit2 — это набор смарт-контрактов от Uniswap, который создаёт промежуточный слой для управления разрешениями на ERC-20 токены. Он объединяет два механизма: SignatureTransfer (одноразовые подписи) и AllowanceTransfer (allowances с лимитом суммы и срока).
Нет. Обычный ERC-20 approve — это бессрочное разрешение конкретному контракту. Permit2 добавляет одноразовость (SignatureTransfer) и управляемые дедлайны (AllowanceTransfer). Это более гибкая архитектура, но не совсем «то же самое».
Зависит от механизма. Если использовалась SignatureTransfer — нет, allowance не создаётся. Если AllowanceTransfer — да, если хотите закрыть доступ раньше дедлайна. Плюс базовый approve на Permit2-контракт остаётся и может быть ревокнут через Revoke.cash или Etherscan.
Да. Подпись через SignatureTransfer даёт право на реальный transferFrom. Если вы подписываете мошенническое сообщение — токены могут быть украдены. Механизм не защищает от подписи «не того».
В запросе подписи от кошелька вы увидите параметры: spender, amount или value, nonce, deadline. Это характерные параметры Permit2-запроса. Стандартный approve выглядит иначе — как обычная транзакция с полями «контракт» и «сумма».
В Revoke.cash — там есть отдельный блок Permit2 Allowances. В Etherscan Token Approvals можно увидеть базовый approve на Permit2-контракт (spender будет адрес Permit2).
Если вы пользовались Uniswap — у вас, скорее всего, есть базовый approve токена на Permit2-контракт. Он не опасен сам по себе, пока Permit2-контракт ведёт себя как задумано. Но если вы хотите полностью убрать Permit2-доступ для токена — ревокните этот базовый approve.
Нет. Permit2-контракт задеплоен в нескольких сетях: Ethereum, Polygon, Arbitrum, Optimism, Base и других EVM-сетях, где работает Uniswap. Проверяйте Permit2-разрешения в каждой сети отдельно.
Нет. Disconnect не затрагивает ни AllowanceTransfer-разрешения, ни базовый approve на Permit2-контракт. Нужен явный revoke.
Главный индикатор: домен сайта. Если запрос приходит не с официального домена dApp (Uniswap, Aave и так далее) — это фишинг. Кроме того, смотрите на адрес spender в запросе: легитимный Permit2-запрос должен содержать адрес официального контракта, который можно проверить в блокчейн-эксплорере.
Permit2 — это шаг вперёд в архитектуре DeFi-разрешений. Но шаг вперёд для протоколов не всегда означает автоматическую безопасность для пользователей. Понимать механизм — значит управлять им, а не просто нажимать «Подписать» в надежде на лучшее.
Популярные лонгриды:
