Перейти к содержанию
Financial Context Wiki

Риск подписи Permit2

Permit2 разделяет многократно используемые лимиты и одноразовые переводы по подписи; безопасное подписание требует точной проверки развертывания, домена, получателя разрешения, адресата, суммы, nonce, сроков, witness и calldata исполнения.

Обновлено

Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Краткий ответ

Permit2 объединяет две разные системы авторизации. AllowanceTransfer хранит многократно используемый лимит для пары владелец-токен-получатель разрешения вместе с суммой, сроком действия и упорядоченным nonce. SignatureTransfer расходует одноразовый подписанный максимум с неупорядоченным nonce в битовой карте и не создает постоянного лимита для последующего получателя разрешения. Обе системы по-прежнему зависят от ERC-20 allowance, который владелец токена выдал Permit2.

Подпись без оплаты газа владельцем может переместить активы, если исполнение оплачивает получатель разрешения или ретранслятор. Проверяйте точную цепочку, развернутый код Permit2, домен EIP-712, модуль, токен, получателя разрешения, подписанный максимум, calldata с адресатом, nonce и сроки. Подлинный контракт Permit2 не делает безопасными вредоносного получателя разрешения, адресата, маршрутизатор или witness.

Риск подписи Permit2
0 / 5
0 проверено; 5 осталось

Завершение этой проверки не доказывает безопасность актива, транзакции или системы.

Как это работает

  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 и подтвержденного состояния.

Похожие темы

Источники

Навигация

Поиск по вики...