Проєкт переходить на новий контракт, ви відкриваєте сторінку міграції, і ще до того, як зрушив хоча б один токен, гаманець просить схвалити старий. Запит виглядає як зайвий крок, який хтось додав до процесу. Це не так. В ERC-20 це єдиний спосіб передати баланс комусь, окрім вас самих, і вміння читати цей запит відділяє міграцію від спустошеного гаманця.
Що насправді дає схвалення
Схвалення — це запис у реєстрі, який живе всередині контракту старого токена. Воно фіксує одне число для однієї пари адрес: скільки цього токена названій витратній адресі дозволено вивести з вашого рахунку. Підпис нічого не переміщує, нічого не надсилає проєкту й ні до якого обміну вас не зобов'язує.
У стандарті токен ERC-20 до цього реєстру звертаються дві функції. `approve` дозволяє витратній адресі знімати з вашого рахунку багаторазово, аж до заданої суми, а `transferFrom` — це виклик, який справді переміщує токени з однієї адреси на іншу. Специфікація подає цю пару як процедуру зняття, що дозволяє контрактам переказувати токени від вашого імені, і контракт міграції — один із таких контрактів, без жодного особливого статусу.
Де зберігається запис, важить більше, ніж здається. Дозвіл лежить у старому токені, а не в контракті міграції, тож він переживає і сторінку міграції, і сам обмін, і проєкт. Закрита вкладка його не прибирає.
Чому контракт обміну зобов'язаний питати
Обмін має спершу прийняти старі одиниці, щоб зарахувати нові. Контракт не може сам залізти на ваш рахунок, а про ваш баланс контракт токена слухає лише той акаунт, який цим балансом володіє.
Уявна альтернатива — надіслати старі токени контракту самостійно звичайним переказом. Токени справді підуть, і це теж не спрацює: звичайний переказ приходить як баланс без супровідного виклику, тож контракту ніхто не повідомляє про переказ і зараховувати йому нема проти чого. Стандарт ERC-223 написано саме навколо цієї поломки. Забір через `transferFrom` дає контракту один виклик, у якому він приймає старі одиниці й виплачує нові, а цьому виклику спершу потрібен дозвіл.
Дві транзакції, і обмінює лише друга
Схвалення й обмін — окремі транзакції, кожна зі своїм газом. ERC-2612 описує цю форму прямо: якщо користувачеві треба взаємодіяти зі смартконтрактом, то йому доводиться робити 2 транзакції, `approve` і сам виклик контракту, який усередині викличе `transferFrom`.
Саме тому, що вони окремі, перша може пройти, а друга все одно впасти. Зачинене вікно обміну, спустошений резерв виплат, поставлений на паузу контракт — нічого з цього схвалення не бачить, воно лише пише число й повертається. Підтверджене схвалення не доводить, що міграція за ним працює.
Зворотна пастка чекає на крок далі. Обмін після успішної симуляції все ще може відкотитися в мережі, бо симуляція відповідає на питання про стан в один момент, а не про стан, у який потрапляє ваша транзакція. Коли обмін відкочується, виданий вами дозвіл лишається недоторканим і далі діє.
Міграції, яким немає навіщо питати
Не кожна міграція працює на дозволі. Форма, про яку вам повідомили, має збігатися із запитом, який ви отримали.
| Як влаштована міграція | Що надсилаєте ви | Чи доречне тут схвалення |
|---|---|---|
| Контракт обміну забирає ваші старі одиниці | Схвалення, потім виклик обміну | Так |
| Ви переказуєте старі токени на оприлюднену адресу | Один звичайний переказ | Ні |
| Власникам зі знімка нараховують за реєстром | Нічого | Ні |
| Платформа конвертує власний об'єднаний баланс | Нічого | Ні |
Зупинити вас має третій рядок. У роздачі, оголошеній автоматичною, немає механізму, якому потрібен ваш дозвіл, тож сторінка, що його вимагає, просить те, чого описана міграція не використовує. Помітити цю невідповідність нічого не коштує, і вона не залежить від чиїхось суджень про сайт.
Три поля запиту, які вирішують усе
Будь-який запит на схвалення несе ті самі три поля, хоч як їх називає ваш гаманець.
| Поле | Що воно надає | З чим звіряти |
|---|---|---|
| Токен | У реєстр якого контракту піде запис | Адреса старого контракту з власного оголошення проєкту |
| Витратна адреса | Яка адреса може списувати з вашого рахунку | Адреса контракту міграції з того самого оголошення |
| Сума | Стеля того, що ця адреса може забрати | Транш, який ви маєте намір обміняти зараз |
Звіряйте адреси цілком. Схожа адреса може збігатися зі справжньою за першими та останніми символами, а різниця сидить посередині.
Поле витратної адреси і є тим, що несе збиток, і саме тому drainer гаманців не мусить нічого зламувати. Він ставить у це поле власну адресу й дає вам підписати схвалення, дійсне та правильно оформлене. Транзакція проходить рівно так, як записана, а баланс іде пізніше, за розкладом атакувальника, а не за вашим.
Коли просять підпис, а не транзакцію
Дозвіл приходить не завжди у вигляді транзакції. 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
