Одобрения токенов: разрешения, которые вы продолжаете раздавать

Каждый раз, когда вы взаимодействуете с DeFi-приложением — обмениваете токены на DEX, кладёте депозит в кредитный рынок, переводите ERC-20 через мост — вы почти наверняка выдаёте одобрение токена. Большинство пользователей подписывают такие транзакции за секунды и забывают о них. Однако этот единственный approve — одно из самых значимых действий, которые вы делаете на Ethereum: он передаёт смарт-контракту постоянное разрешение распоряжаться вашими токенами, часто без дополнительного подтверждения. В этом гайде разбирается, что такое одобрение токена, зачем dApp его просят, в чём риски неограниченных allowance и что всё это означает, когда вы подписываете одобрения через SSP.

Зачем вообще нужны одобрения

Токены ERC-20 не хранятся "внутри" вашего кошелька так, как ETH. Контракт токена ERC-20 — это бухгалтерская книга: отображение адресов в балансы. Когда у вас 1 000 USDC, в блокчейне существует строка в контракте USDC, что ваш адрес владеет 1 000 единиц.

Поскольку баланс живёт внутри контракта токена, только этот контракт может его двигать. Когда вы отправляете USDC другу, ваш кошелёк напрямую вызывает функцию transfer токена.

Но DEX, где другой контракт (router) должен вытащить USDC с вашего адреса для выполнения свопа, не может залезть в контракт токена и забрать ваш баланс. ERC-20 решает это паттерном делегирования из двух шагов:

1. Вы вызываете approve(spender, amount) на контракте токена. Это устанавливает allowance: запись о том, что spender имеет право двигать до amount ваших токенов.
2. Spender позже вызывает transferFrom(yourAddress, destination, amount) на контракте токена. Контракт проверяет allowance, уменьшает его и двигает токены.

Одобрение — это ключ. Без него router вообще не может коснуться ваших USDC.

Что именно вы выдаёте

Прочитайте approve(spender, amount) буквально. Вы говорите ERC-20-контракту: "этот адрес может снять до такого-то количества моих токенов, в любой момент, в любом числе транзакций, пока я это не изменю."

Из этого следует несколько вещей:

• Постоянное разрешение, а не разовое действие. Будучи однажды выданным, allowance позволяет spender забирать токены без вашей повторной подписи, пока не будет израсходован или отозван.
• Для каждого токена отдельно. Одобрение router DEX для USDC не позволяет ему касаться вашего DAI; нужно отдельное одобрение для DAI.
• Для каждого spender отдельно. Другой контракт — даже из той же dApp — имеет собственный allowance.
• Без срока годности. В ERC-20 нет встроенного дедлайна. Allowance, выданный в 2023, всё ещё активен в 2026, если не был израсходован или отозван.

Любой allowance можно посмотреть в блок-эксплорере вроде etherscan, читая view-функцию allowance(owner, spender) контракта токена.

Паттерн бесконечного allowance

Если одобрения по сумме, то почему почти каждая DEX просит у вас огромное число — обычно 2^256 - 1, отображаемое как "unlimited" или MaxUint256 — вместо ровно той суммы, которую вы меняете прямо сейчас?

Ответ — UX и gas. Если бы DEX просила свежий allowance, равный размеру сделки, на каждый своп, вы бы платили approve-транзакцию каждый раз и подтверждали бы по две транзакции для того, что ощущается как одно действие. Запрос неограниченного allowance один раз позволяет вам потом свободно свопить с одной транзакцией на сделку.

Это действительно удобно. И действительно более рискованно. Неограниченный allowance означает, что spender-контракт уполномочен опустошить весь ваш текущий баланс этого токена — и любой будущий баланс — в любой момент, без каких-либо дополнительных подписей с вашей стороны.

Для известного, проаудированного, неизменяемого контракта практический риск обычно низок. Для свежевыкатанной dApp, апгрейдабельного прокси или незна��омого контракта неограниченный allowance — это поверхность куда шире, чем сделка, которую вы планировали.

Реальный риск: постоянный ключ к вашим токенам

Опасность одобрений не в самой approve-транзакции. А в том, что происходит после. Несколько сценариев:

• В spender-контракте баг. Атакующий эксплуатирует его логику transferFrom, и каждый кошелёк с ненулевым allowance оказывается слит.
• Spender-контракт апгрейдабельный. Тот, кто владеет ключами апгрейда, выкатывает новую логику, которая тянет токены у всех, у кого есть активный allowance.
• Вы одобрили вредоносный клон. Фишинговый сайт скопировал URL настоящей dApp, и контракт, который вы одобрили, всё это время был под контролем атакующего.
• Подписные ключи spender-а скомпрометированы. Официальный контракт в порядке; кошелёк оператора — нет, и allowance исполняются злоумышленником.

В любом случае при опустошении вы ничего не подписываете. Одобрение, выданное неделями раньше, — единственная авторизация, которая нужна атакующему. "Одобряй только то, что нужно, и отзывай то, что больше не используешь" — это не паранойя; это тот же принцип, по которому не оставляешь запасных ключей от дома у каждого мастера, которого когда-либо нанимал.

Как одобрения тихо накапливаются

Кошелёк, активный в DeFi год-два, накапливает десятки одобрений: каждая DEX, каждый агрегатор, каждый депозит в кредитный рынок, каждый NFT-маркетплейс, каждый мост. Пользователи почти никогда не возвращаются, чтобы отозвать. В итоге получается длинный хвост постоянных разрешений, многие из которых неограниченные, многие выданы контрактам, с которыми пользователь больше не взаимодействует.

Это и есть тихая поверхность атаки. Она не видна ни в одной отдельной транзакции; это кумулятивный осадок обычного использования. Аудит и подрезка этого списка — одна из самых эффективных привычек безопасности в самокастоди — следующая статья показывает, как именно это сделать в отзыв одобрений токенов из SSP.

Более новый паттерн: EIP-2612 permit

ERC-20 появился раньше большой части современного DeFi, и двухтранзакционный танец approve-затем-swap давно считался неудобным. EIP-2612 ввёл альтернативу для токенов, которые её поддерживают: вместо отправки approve on-chain пользователь подписывает off-chain-сообщение (permit), авторизующее конкретного spender, сумму и дедлайн. dApp отправляет эту подпись вместе со свопом в одной транзакции.

permit экономичен по gas, ограничен (несёт явную сумму и срок) и его сложнее оставить висящим, потому что дедлайн заставляет его истечь. Не каждый ERC-20 это поддерживает — USDC и DAI поддерживают, многие более старые токены нет — но там, где доступен, он обычно безопаснее, чем долгоживущий approve allowance. При этом сами подписи permit тоже можно фишить: вредоносный сайт, просящий вас "войти", может подсунуть под этим permit. Читайте, что вы подписываете.

Что всё это значит внутри SSP

SSP — самокастодиальный 2-из-2 multisig-кошелёк: каждая on-chain-транзакция со-подписывается браузерным расширением SSP и мобильным приложением SSP Key. На Ethereum и поддерживаемых SSP EVM-сетях (Polygon, Base, BNB Smart Chain, Avalanche) это реализовано как ERC-4337 smart account с агрегированной подписью Schnorr — но на уровне приложений одобрение выглядит как любая другая транзакция.

Несколько вещей, которые стоит помнить:

• Одобрение — это транзакция, которую ваш 2-из-2 обязан со-подписать. Когда dApp запрашивает approve, SSP показывает её как любую другую tx. Вы видите адрес spender и запрошенную сумму на обоих устройствах перед подтверждением.
• После выдачи spender уже не нуждается в SSP, чтобы действовать. Multisig защищает момент одобрения, а не постоянное разрешение после. Если вы выдадите неограниченный allowance вредоносному контракту, multisig не спасёт вас от последующего опустошения.
• Следите за адресом spender. dApp иногда обновляют router; если spender на экране одобрения не совпадает с ожидаемым контрактом, остановитесь и проверьте.
• Одобрения, инициированные через WalletConnect, выглядят так же. Запрашивает ли dApp одобрение прямо на странице или через WalletConnect, процесс и риски идентичны.

Привычки, которые стоит выработать

Несколько конкретных практик удерживают поверхность одобрений в рабочих рамках:

• Предпочитайте наименьший рабочий allowance. Когда dApp предлагает выбор между "точной суммой" и "unlimited", точная — более безопасный вариант по умолчанию для контрактов, которыми вы не пользуетесь регулярно.
• Относитесь к неограниченным одобрениям как к обязательствам. Резервируйте их для небольшого набора контрактов, которым доверяете и которыми часто пользуетесь. Для остального — ограничивайте сумму.
• Регулярно аудируйте. Раз в квартал просматривайте активные одобрения на каждой сети и отзывайте всё, чем больше не пользуетесь. Инструменты вроде revoke.cash делают это рутиной.
• Остерегайтесь незнакомых dApp. Новый протокол без истории аудитов, просящий неограниченный allowance, — самая рискованная комбинация в DeFi.
• Защищайте ключи, которые выдают одобрения. Multisig в SSP поднимает планку, но базовая гигиена по-прежнему обязательна — см. лучшие практики работы с seed-фразой.

Ментальная модель, которую стоит вынести

Одобрение токена — это не клик; это ключ. Каждое остаётся в замке, пока вы его не уберёте, и каждое даёт его держателю возможность двигать токены, которые вы ещё даже не заработали. При аккуратном использовании allowance — это сантехника, благодаря которой DeFi вообще работает. Если же относиться к ним как к одноразовым кликам, они становятся медленным накоплением рисков, которые вы забыли, что взяли на себя.

Понимайте разрешение, которое выдаёте, предпочитайте ограниченные выдачи там, где dApp позволяет, и стригите свои постоянные одобрения по расписанию. Для более глубоких деталей протокола канонической ссылкой является документация стандарта ERC-20 на ethereum.org. Если вы новичок в использовании SSP на Ethereum, наш гайд Ethereum в SSP покрывает основы.