Проєкт переходить на новий контракт токена, оголошує вікно обміну, і вікно зачиняється. Через кілька місяців ви відкриваєте старий гаманець, а баланс старого токена все ще там. Чи можна його ще обміняти, це не одне питання з однією відповіддю. У міграції спливають три різні речі, кожна забезпечується в іншому місці, і лише одна з них забезпечується кодом.
Що міграція токена насправді переміщує
Міграція нікуди не переміщує ваші токени. Старий контракт далі працює за власною адресою, і ваш баланс лишається в його реєстрі доти, доки працює мережа. Міграція пропонує обмін: ви віддаєте старі одиниці контракту обміну або платформі, а вона записує вам рівноцінну вимогу в новому реєстрі.
Цей обмін іде звичайною токенною механікою. У стандарті ERC-20 `approve` дозволяє витратнику знімати з вашого рахунку до визначеної суми, а `transferFrom` переносить токени з однієї адреси на іншу; стандарт описує цю пару як процедуру зняття, що дозволяє контрактам переносити токени від вашого імені. Контракт обміну є одним із таких витратників, і мережа не дає йому жодного особливого статусу.
Звідси випливають дві речі. Ваш старий баланс не занепадає і не згасає сам собою, а строк ніколи не є властивістю тих токенів, які ви тримаєте. Строк належить тому, хто стоїть з іншого боку обміну і готовий платити. Отже, питання не в тому, чи спливли ваші токени. Питання в тому, що сталося з контрагентом.
Спливати можуть три речі, і це не одне й те саме
У звичайному оголошенні про міграцію слово строк виконує забагато роботи. Розкладіть його, і побачите кілька окремих годинників, кожен забезпечується деінде.
Перший це сама оголошена дата, рядок у блозі або банер у застосунку. У мережі її ніхто не читає. Другий це перевірка, вписана в контракт обміну: вона відмовляється виконуватися, щойно поточна позначка часу блоку перетинає значення, зафіксоване в коді. Третій це резерв нових токенів, з якого контракт платить і який той, хто його поповнив, може забрати, коли проєкт вважатиме міграцію завершеною.
| Що спливло | Де це забезпечується | Що потрібно, щоб відкрити знову |
|---|---|---|
| Оголошена дата | Ніде в мережі | Нічого, контракт її ніколи не перевіряв |
| Перевірка позначки часу в контракті обміну | Код контракту | Шлях оновлення, якщо його заклали |
| Резерв нових токенів | Баланс у мережі | Щоб хтось знову поповнив контракт |
| Служба міграції на платформі | Внутрішня політика цієї платформи | Рішення цієї платформи |
Усе, що нижче, це спосіб зрозуміти, у якому рядку ви перебуваєте.
Прочитайте контракт, перш ніж вважати його закритим
Перші два рядки ви можете з'ясувати самі й безкоштовно. Відкрийте контракт обміну в оглядачі блоків і прочитайте його верифікований вихідний код. Якщо у функції обміну немає жодного порівняння з позначкою часу блоку, то в коді немає строку, а оголошена дата завжди була лише повідомленням. У такому разі обмін, надісланий на рік пізніше, проходить так само, як надісланий першого дня.
Якщо перевірка позначки часу є, це інший висновок, і твердий. Код контракту робить те, що в нього вписали, і умова, яка відкочує транзакцію після визначеного моменту, відкочуватиме її й далі. Жодне звернення до підтримки цього не змінить, бо переконувати тут нікого: відмова це рядок коду, який працює як задумано.
Єдине застереження це оновлюваність. Якщо обмін стоїть за проксі, логіку якого можна замінити, строк у принципі може зняти той, хто має ці повноваження. Це рішення проєкту, а не ваше право, але саме воно відрізняє зачинені двері від заварених, і читати контракт треба саме для того, щоб їх розрізнити.
Коли контракт відкритий, а резерв порожній
Контракт без строку однаково не може платити з порожнього рахунку. Нові токени мають братися з резерву, що лежить за адресою обміну, і якщо проєкт написав функцію, яка вимітає залишок після закриття вікна, він може цей резерв спорожнити. Після такого вимітання функція обміну може й далі приймати ваші старі токени і далі давати збій, бо за платіжною ногою вже нічого немає.
Розгляньмо приклад. Проєкт консолідує по одній новій одиниці за кожні десять старих, а в гаманці лежить 25 000 старих одиниць, тож вимога становить 2 500 нових. Припустімо, що за час вікна пройшло 96% старої пропозиції; решта 4% і є та частина, на яку претендують запізнілі, а чи зможе контракт ці претензії задовольнити, визначається просто балансом нових токенів за адресою обміну. Цей баланс публічний. Перевірте його, перш ніж щось надсилати.
Саме цей випадок карає оптимізм. Надсилання старих токенів у контракт, який не може вам заплатити, не залишає вас там, де ви були: старі одиниці пішли на адресу, яку ніколи не писали так, щоб вона віддала їх назад, а нового ви не отримали. Спершу прочитайте резерв, і якщо він порожній, не надсилайте.
Міграції, які платформа зробила за вас
Деякі міграції взагалі не торкалися вашого гаманця. Якщо під час обміну ви тримали старий токен на централізованій платформі, платформа конвертувала власний об'єднаний баланс і переписала запис вашого рахунку, тож міграція виглядала у вашому акаунті як зміна тікера і більше нічого.
У цього шляху свій годинник, і це політика, а не правило мережі. Платформа оголошує вікно конвертації, зараховує баланси, що надійшли всередині нього, і в якийсь момент припиняє. Форма знайома з делістингу токенів: повідомлення, вікно, потім закритий доступ, а можливість щось виправити потім залежить від того, чи веде ця компанія ручний процес для запізнілих.
Отже, тут два питання, а не одне, і відповіді в них різні. Чи зарахує платформа пізній депозит старих токенів, це питання до підтримки. Чи заплатить ще контракт обміну в мережі, це питання до коду. Відповідайте на них окремо, бо відмова в одному нічого не каже про інше.
Що лишається, коли шлях у мережі закритий остаточно
Припустімо, код закритий, резерв виметений, і жодна служба не опрацює пізню вимогу. Старий токен не перестав існувати. Це баланс у контракті, який ще працює, його ще можна переказувати, а отже й продати будь-кому, хто готовий купити, за тією ціною, яку дасть ринок покинутого реєстру.
Не шукайте обхідного шляху, надсилаючи старі одиниці туди, де вам ввижається надія. Надіслати їх у новий контракт токена або в сам старий контракт це помилка того самого класу, що й надіслати криптовалюту не на ту адресу: у контракту немає приватного ключа, і якщо ніхто не написав функцію, яка витягує випадково потрапні токени, їх не дістане ніхто. Стандарт ERC-223 написано саме навколо цього збою: він зазначає, що токени, надіслані в контракт звичайним переказом, приходять як баланс, про який контракт ніколи не дізнається.
Чесний підсумок цього випадку в тому, що розмір втрати вже зафіксовано, а кожна наступна транзакція здатна лише його збільшити. Тримати позицію нічого не коштує. Вгадувати порятунок може коштувати решти.
Строк міграції це принада для шахраїв
Вікно, що спливає, створює поспіх, потік розгублених власників і законний привід для проєкту попросити людей підключити гаманець. Нападникам не треба нічого з цього вигадувати. Їм потрібен лише схожий сайт. Це і є форма шахрайства з видаванням себе за інших, і тому результат пошуку це неправильний спосіб дістатися до порталу міграції.
Механізм, який потрібен фальшивому порталу, той самий, що використовує справжній обмін. Справжня міграція просить дозвіл, щоб контракт міг забрати ваші старі токени, а схвалення токенів, видані нападнику, роблять рівно те, що написано: дозволяють цій адресі забрати схвалений вами баланс. Видавайте обмежений дозвіл замість безлімітного, звіряйте адресу контракту з власним опублікованим оголошенням проєкту і заходьте на сайт через свою закладку.
Одне правило проходить через усю цю категорію. Кожен факт, потрібний вам у пізній міграції, читається в публічному оглядачі безкоштовно: вихідний код контракту, перевірка позначки часу, баланс резерву. Той, хто бере плату за повторне відкриття закритої міграції або просить заради цього сід-фразу, продає вам другу втрату, а не розв'язання першої.
Підсумок
Старі токени не спливають. Спливають контрагенти. Оголошена дата не зобов'язує в мережі нікого; перевірка позначки часу в контракті обміну зобов'язує всіх, включно з проєктом; а виметений резерв зачиняє двері так само щільно, лишаючи ручку на місці. Ці три випадки виглядають однаково на екрані гаманця і всередині цілком різні.
Порядок роботи фіксований. Прочитайте контракт обміну в оглядачі, знайдіть перевірку позначки часу, потім прочитайте баланс резерву за цією адресою, а якщо була задіяна платформа, спитайте її окремо. Якщо все це повертає закрито, старий баланс і далі ваш і далі переказний, і жодний поспіх не має змусити вас надіслати його туди, звідки нічого не повернеться. Щоб продовжити вивчати основи, читайте інші матеріали Bitbase Academy.
Схожі матеріали
Інші матеріали Bitbase на цю тему:
- Як відкликати делегування в управлінні
- Чому міграція токена просить схвалення в гаманці
- Міграція токенів завершена, але нових токенів немає в гаманці
- Як розрахувати фінансовий запас скарбниці токен-проєкту
- Ф'ючерси з маржею в монеті чи в USDT: яким контрактом торгувати
Застереження: Ця стаття є освітнім матеріалом Bitbase Academy і надається лише для інформації. Вона не є інвестиційною, торговою, податковою чи фінансовою порадою. Криптоактиви волатильні — оцінюйте ризики самостійно. Написано станом на вересень 2026 року; орієнтуйтеся на найновішу офіційну інформацію.
Джерела
[1] Ethereum Improvement Proposals, ERC-20: Token Standard, методи approve та transferFrom (статус: Final) eips.ethereum.org
[2] Ethereum Improvement Proposals, ERC-223: Token with transaction handling model, розділ Motivation (статус: Final) eips.ethereum.org
