---
title: "Риск подписи Permit2"
description: "Permit2 разделяет многократно используемые лимиты и одноразовые переводы по подписи; безопасное подписание требует точной проверки развертывания, домена, получателя разрешения, адресата, суммы, nonce, сроков, witness и calldata исполнения."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Риск подписи Permit2
> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Краткий ответ
Permit2 объединяет две разные системы авторизации. `AllowanceTransfer` хранит многократно используемый лимит для пары владелец-токен-получатель разрешения вместе с суммой, сроком действия и упорядоченным nonce. `SignatureTransfer` расходует одноразовый подписанный максимум с неупорядоченным nonce в битовой карте и не создает постоянного лимита для последующего получателя разрешения. Обе системы по-прежнему зависят от ERC-20 allowance, который владелец токена выдал Permit2.
Подпись без оплаты газа владельцем может переместить активы, если исполнение оплачивает получатель разрешения или ретранслятор. Проверяйте точную цепочку, развернутый код Permit2, домен EIP-712, модуль, токен, получателя разрешения, подписанный максимум, calldata с адресатом, nonce и сроки. Подлинный контракт Permit2 не делает безопасными вредоносного получателя разрешения, адресата, маршрутизатор или witness.
## Как это работает
1. Зафиксируйте `chainId`, сеть, `verifyingContract` Permit2, развернутый исполняемый код, адрес и decimals токена, тип кошелька владельца и предполагаемое приложение. Используйте официальный реестр развертываний; знакомого адреса или ярлыка недостаточно.
2. Прочитайте исходящий ERC-20 allowance владельца для Permit2 и баланс. Определите конечное или безлимитное разрешение и особенности перевода токена; этот реестр сохраняется после истечения подписи Permit2 или хранимого нижестоящего лимита.
3. Определите точный путь и подписанный основной тип: `PermitSingle` или `PermitBatch` для AllowanceTransfer либо `PermitTransferFrom`, его пакетный и witness-варианты для SignatureTransfer. Не считайте `transferFrom` подписанным типом.
4. Декодируйте домен EIP-712 и каждый элемент сообщения. Для AllowanceTransfer проверьте токен, `uint160 amount`, `expiration`, упорядоченный nonce, получателя разрешения и `sigDeadline`. Для SignatureTransfer проверьте разрешенные токен и сумму, неупорядоченный nonce, срок и получателя разрешения, связанного с контекстом вызывающей стороны.
5. Отдельно декодируйте calldata исполнения. В базовом SignatureTransfer `SignatureTransferDetails.to` и `requestedAmount` являются параметрами исполнения, а не полями базового подписанного разрешения; запрошенная сумма должна лишь укладываться в подписанный максимум. Проверьте каждый индекс пакета, а также точные хеш witness и строку типа, если они есть.
6. Запросите текущий упорядоченный nonce лимита либо слово и бит неупорядоченной карты, затем смоделируйте точные вызывающую сторону, calldata, цепочку и состояние. Сверьте адресата, действия маршрутизатора, особенности токена, баланс и оба реестра разрешений; результат симуляции меняется вместе с состоянием, порядком или реорганизацией.
7. Минимизируйте суммы и сроки. При подозрении сохраните типизированные данные и через доверенный путь отправьте правильный отзыв исходного разрешения, нижестоящего лимита или инвалидирование nonce, рассматривая это как гонку в мемпуле; дождитесь подтверждения и сверяйте переводы, балансы, лимиты и биты карты.
В AllowanceTransfer `sigDeadline` ограничивает время, когда подписанное разрешение может создать или обновить хранимые полномочия; `expiration` ограничивает период их расходования. Deadline SignatureTransfer ограничивает его одноразовое исполнение. EIP-712 предоставляет типизированное хеширование и разделение доменов, но не защиту от повторного использования и не безопасность намерения; эти границы задают правила nonce и сроков Permit2.
Для контрактного кошелька действительность ERC-1271 зависит от текущей политики `isValidSignature`, модулей, порогов и кода кошелька. Ярлыки, усеченный экран аппаратного кошелька и успешная симуляция являются исходными данными, а не гарантиями. Отключение интерфейса не отзывает разрешения или подписи.
## Пример
- **Два реестра разрешений.** Конечный лимит токена для Permit2 изначально равен `1,000 USDC`; `PermitSingle` записывает `600 USDC` для получателя S. После перевода S суммы `225 USDC` хранимый остаток составляет `600 - 225 = 375 USDC`, а стандартный конечный исходящий allowance становится `1,000 - 225 = 775 USDC`. Истечение или отзыв 375 само по себе не обнуляет 775; нестандартные токены могут вести себя иначе.
- **Адресат и сумма одноразового перевода.** SignatureTransfer подписывает максимум `250 USDC`; calldata запрашивает `180 USDC` торговцу. При достаточных балансе и исходящем allowance исполнение может перевести 180. Nonce расходуется, поэтому оставшиеся `70 USDC` повторно использовать нельзя. Если calldata указывает адресатом злоумышленника, базовое разрешение само по себе не препятствует такому перенаправлению связанным получателем разрешения.
- **Битовая карта неупорядоченного nonce.** Для nonce `513` значения равны `wordPos = 513 >> 8 = 2`, `bitPos = 513 & 255 = 1` и `mask = 1 << 1 = 2`. Исполнение устанавливает бит 1 слова 2; повторное использование 513 завершается ошибкой, а nonce `512` в бите 0 остается независимым.
- **Гонка отзыва.** Хранимый лимит равен `400 USDC`. Владелец публикует отзыв до нуля, но первым исполняется перевод `300 USDC`, оставляя `100 USDC`; последующий отзыв устанавливает остаток в `0`. Нулевой итоговый allowance не отменяет реализованную потерю `300 USDC`, поэтому требуется сверить порядок транзакций и балансы.
## Риски
- Неверный ID цепочки, развертывание или исполняемый код
- Поддельный или неожиданный проверяющий контракт
- Смешение AllowanceTransfer и SignatureTransfer
- Вредоносный или ошибочный получатель разрешения либо вызывающая сторона
- Выбор адресата через calldata исполнения
- Запрошенная сумма близка к подписанному максимуму
- Неверный адрес, символ, decimals или сырые единицы токена
- Постоянное или безлимитное исходящее разрешение ERC-20
- Избыточная нижестоящая сумма или срок действия
- Смешение deadline, срока подписи и срока разрешения
- Устаревший или участвующий в гонке упорядоченный nonce
- Повторное использование бита или чрезмерная маска инвалидирования
- Несовпадение хеша witness или точной строки типа
- Скрытый, повторный или неверно индексированный элемент пакета
- Расхождение интерфейса или calldata с намерением
- Проигрыш отзыва в гонке мемпула или MEV
- Изменение модуля, подписанта, порога или обновления ERC-1271
- Токен с комиссией за перевод, ребейзом, паузой, блокировкой или обратным вызовом
- Дрейф состояния, сбой симуляции или реорганизация
- Ошибочное принятие подтверждения аппаратным кошельком или отключения за безопасность
## Распространенные заблуждения
- **Подпись без запроса газа не может перемещать токены.** Газ за исполнение может оплатить другая сторона.
- **Официальный адрес Permit2 доказывает безопасность получателя разрешения и адресата.** Permit2 способен точно исполнить вредоносные полномочия.
- **SignatureTransfer и AllowanceTransfer создают одинаковое постоянное разрешение.** Первое одноразовое, второе хранит многократно используемый лимит.
- **Отключение или отзыв одного уровня отменяет все пути и ожидающие подписи.** Состояния исходящего, нижестоящего разрешения и nonce раздельны, а гонки сохраняются.
- **EIP-712, аппаратный кошелек или успешная симуляция доказывают намерение и финальность.** Они улучшают отображение или тестирование, но не заменяют проверку полей, calldata и подтвержденного состояния.
## Похожие темы
- [Типизированная подпись EIP-712](/ru/crypto/eip712-typed-signature/)
- [Разрешение кошелька](/ru/crypto/wallet-approval/)
- [Подпись кошелька](/ru/crypto/wallet-signature/)
## Источники
- [Overview](https://developers.uniswap.org/docs/protocols/permit2/overview) - Uniswap Developers (дата обращения: 2026-08-13)
- [Allowance Transfer](https://developers.uniswap.org/docs/protocols/permit2/concepts/allowance-transfer) - Uniswap Developers (дата обращения: 2026-08-13)
- [Signature Transfer](https://developers.uniswap.org/docs/protocols/permit2/concepts/signature-transfer) - Uniswap Developers (дата обращения: 2026-08-13)
- [Deployments](https://developers.uniswap.org/deployments) - Uniswap Developers (дата обращения: 2026-08-13)
- [PermitHash.sol](https://github.com/Uniswap/permit2/blob/main/src/libraries/PermitHash.sol) - Uniswap Permit2 (дата обращения: 2026-08-13)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (дата обращения: 2026-08-13)
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (дата обращения: 2026-08-13)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (дата обращения: 2026-08-13)
Source: https://wiki.fcontext.com/ru/crypto/permit2-signature-risk/index.mdx