Проект переезжает на новый контракт, вы открываете страницу миграции, и ещё до того, как сдвинулся хоть один токен, кошелёк просит одобрить старый. Запрос выглядит как лишний шаг, который кто-то добавил в поток. Это не так. В ERC-20 это единственный способ передать баланс кому-либо, кроме вас самих, и умение читать этот запрос отделяет миграцию от опустошённого кошелька.
Что на самом деле даёт одобрение
Одобрение — это запись в реестре, который живёт внутри контракта старого токена. Оно фиксирует одно число для одной пары адресов: сколько этого токена названному расходующему адресу разрешено вывести с вашего счёта. Подпись ничего не перемещает, ничего не отправляет проекту и ни к какому обмену вас не обязывает.
В стандарте токен ERC-20 к этому реестру обращаются две функции. `approve` разрешает расходующему адресу снимать с вашего счёта многократно, вплоть до заданной суммы, а `transferFrom` — это вызов, который действительно перемещает токены с одного адреса на другой. Спецификация подаёт эту пару как процедуру снятия, позволяющую контрактам переводить токены от вашего имени, и контракт миграции — один из таких контрактов, без какого-либо особого статуса.
Где хранится запись, важнее, чем кажется. Разрешение лежит в старом токене, а не в контракте миграции, поэтому оно переживает и страницу миграции, и сам обмен, и проект. Закрытая вкладка его не убирает.
Почему контракт обмена обязан спрашивать
Обмен должен сначала принять старые единицы, чтобы зачислить новые. Контракт не может сам залезть на ваш счёт, а о вашем балансе контракт токена слушает только тот аккаунт, который этим балансом владеет.
Кажущаяся альтернатива — отправить старые токены контракту самостоятельно обычным переводом. Токены действительно уйдут, и это тоже не сработает: обычный перевод приходит как баланс без сопровождающего вызова, поэтому контракту никто не сообщает о переводе и зачислять ему не на что. Стандарт ERC-223 написан вокруг ровно этой поломки. Забор через `transferFrom` даёт контракту один вызов, в котором он принимает старые единицы и выплачивает новые, и этому вызову сначала нужно разрешение.
Две транзакции, и меняет только вторая
Одобрение и обмен — отдельные транзакции, каждая со своим газом. ERC-2612 описывает эту форму прямо: если пользователю нужно взаимодействовать со смарт-контрактом, то ему приходится делать 2 транзакции — `approve` и сам вызов контракта, который внутри вызовет `transferFrom`.
Именно потому, что они отдельные, первая может пройти, а вторая всё равно упасть. Закрывшееся окно обмена, опустошённый резерв выплат, поставленный на паузу контракт — ничего из этого одобрение не видит, оно лишь пишет число и возвращается. Подтверждённое одобрение не доказывает, что миграция за ним работает.
Обратная ловушка ждёт шагом позже. Обмен после успешной симуляции всё ещё может откатиться в сети, потому что симуляция отвечает на вопрос о состоянии в один момент, а не о состоянии, в которое попадает ваша транзакция. Когда обмен откатывается, выданное вами разрешение остаётся нетронутым и продолжает действовать.
Миграции, которым незачем спрашивать
Не всякая миграция работает на разрешении. Форма, о которой вам сообщили, должна совпадать с запросом, который вы получили.
| Как устроена миграция | Что отправляете вы | Уместно ли здесь одобрение |
|---|---|---|
| Контракт обмена забирает ваши старые единицы | Одобрение, затем вызов обмена | Да |
| Вы переводите старые токены на опубликованный адрес | Один обычный перевод | Нет |
| Держателям из снимка начисляют по реестру | Ничего | Нет |
| Платформа конвертирует собственный пулированный баланс | Ничего | Нет |
Остановить вас должна третья строка. У раздачи, объявленной автоматической, нет механизма, которому нужно ваше разрешение, поэтому страница, требующая его, просит то, чего описанная миграция не использует. Заметить это несовпадение ничего не стоит, и оно не зависит от чьих-либо суждений о сайте.
Три поля запроса, которые решают всё
В любом запросе на одобрение есть одни и те же три поля, как бы их ни называл ваш кошелёк.
| Поле | Что оно выдаёт | С чем сверять |
|---|---|---|
| Токен | В реестр какого контракта пойдёт запись | Адрес старого контракта из собственного объявления проекта |
| Расходующий адрес | Какой адрес может списывать с вашего счёта | Адрес контракта миграции из того же объявления |
| Сумма | Потолок того, что этот адрес может забрать | Транш, который вы намерены обменять сейчас |
Сверяйте адреса целиком. Похожий адрес может совпадать с настоящим по первым и последним символам, а различие сидит в середине.
Поле расходующего адреса и есть то, что несёт убыток, и поэтому дрейнеру кошельков не нужно ничего взламывать. Он ставит в это поле собственный адрес и даёт вам подписать одобрение, действительное и корректно оформленное. Транзакция проходит ровно так, как записана, а баланс уходит позже, по расписанию атакующего, а не по вашему.
Когда просят подпись, а не транзакцию
Разрешение приходит не всегда в виде транзакции. ERC-2612 расширяет стандарт ERC-20 функцией `permit`, которая позволяет пользователям менять отображение allowance подписанным сообщением, а не через `msg.sender`; действительный permit устанавливает разрешение для указанного расходующего адреса на заявленное значение, увеличивает nonce и выпускает событие одобрения.
Отсюда следствие: экран, где нужно лишь подписать сообщение, без газа и без ожидающей транзакции, способен выдать ровно то же, что и транзакция одобрения. В момент подписи он к тому же ничего не оставляет в вашей собственной истории транзакций, потому что подписанное сообщение отправляет кто-то другой.
Поэтому запрос подписи читайте по тем же трём полям. Permit называет расходующий адрес и значение, которое он выставляет, плюс deadline, до которого спецификация требует уложить текущее время блока. Если страница выдаёт подпись за вход или подтверждение, а в типизированных данных стоят расходующий адрес и сумма, исполнено будет именно то, что в данных.
Точная сумма или безлимит, и разрешение, которое остаётся
Разберём пример. В кошельке 10 000 старых единиц, и проект открыл обмен. Одобрить 2 500, обменять этот транш и сверить пришедшее с объявленным коэффициентом — значит превратить миграцию в то, что вы наблюдали, а не предположили. Оставшимся 7 500 затем понадобится второе одобрение: ещё один платёж за газ, и это вся цена такого подхода.
Безлимитное одобрение снимает второй платёж и заменяет его постоянным разрешением на этот токен на всё время жизни записи. Контракт миграции сохраняет право забрать любые старые единицы, попавшие на ваш счёт позже, включая остаток старых токенов, который вы найдёте в давнем кошельке спустя годы.
Завершите тем, что уберёте остаток. Точное одобрение расходуется тем обменом, ради которого выдано, а всё сверх того оставляет живую запись, и одобрение токенов, пережившее свою задачу, — это разрешение, за которым уже никто не следит. Обнуление разрешения само по себе транзакция со своим газом, поэтому сделайте её осознанно, когда миграция закончена.
Итог
Миграция просит одобрение потому, что ERC-20 не даёт ей другого способа забрать ваши старые токены. Само одобрение — число, записанное в контракт старого токена, с именем адреса и потолком: оно ничего не перемещает, ничего не доказывает о стоящей за ним миграции и не истекает, когда вы закрываете страницу.
Это сводит всю работу к трём проверкам. Нужно ли вообще разрешение такой форме миграции, тот ли расходующий адрес, который опубликовал проект, и та ли сумма, которую вы собирались обменять. Запрос подписи отвечает на те же три, а выданное разрешение переживает всё вокруг, поэтому уберите его, когда обмен сделан. Чтобы продолжать изучать основы, следите за материалами Bitbase Academy.
Похожие материалы
Другие материалы Bitbase по этой теме:
- Как отозвать делегирование в управлении
- Как рассчитать запас хода казны токен-проекта
- Механика предложения токенов
- ATR и измерение волатильности
- Полосы Боллинджера объяснены
Дисклеймер: эта статья — образовательный материал Bitbase Academy, только для информационных целей. Она не является инвестиционным, торговым, налоговым или финансовым советом. Криптоактивы волатильны — оценивайте риски самостоятельно. Написано в сентябре 2026 года; сверяйтесь с актуальной официальной информацией.
Источники
[1] Ethereum Improvement Proposals, ERC-20: Token Standard, методы approve и transferFrom (статус: Final) eips.ethereum.org
[2] Ethereum Improvement Proposals, ERC-2612: Permit Extension for EIP-20 Signed Approvals, разделы Abstract и Specification (статус: Final) eips.ethereum.org
[3] Ethereum Improvement Proposals, ERC-223: Token with transaction handling model, раздел Motivation (статус: Final) eips.ethereum.org
