Ви дали дозвіл контракту обміну, надіслали баланс старого токена, і оглядач позначив транзакцію зеленим. Колишній тикер зник, і його місце ніщо не зайняло. Або нових одиниць не існує, або вони існують і їх ніщо не відмальовує. Ці два випадки виглядають на екрані гаманця однаково, а потребують цілком різних дій.
Що насправді засвідчує завершений обмін
Підтверджена транзакція обміну каже вам, що ваш виклик потрапив у блок і що найзовнішня частина виконання не відкотилася. Це все. Успішний статус квитанції — твердження про виклик, а не опис того, що цей виклик зарахував.
В обміну під час міграції дві ноги, і саме тому цей розрив тут важить більше, ніж деінде. Одна нога забирає ваші старі одиниці. Друга виплачує нові. Квитанція охоплює транзакцію в цілому, а контракт можна написати так, що друга нога зробить менше, ніж ви очікували, або нічого, а перша при цьому не скасується.
Отже, відповідати треба не на питання, чи спрацював обмін. Відповідати треба на те, чи записаний тепер новий баланс на вашу адресу, і якщо так, чому його ніщо не відмальовує. Це дві окремі перевірки, і такий порядок позбавляє вас суперечки з підтримкою про баланс, яким ви вже володієте.
Де насправді записаний новий баланс
Новий токен — це звичайний контракт із власною книгою обліку, і стандарт токенів ERC-20 фіксує вашу позицію в ньому двічі: один раз як подію в момент зарахування і один раз як значення, яким контракт відповідає на запит.
Подія — це Transfer. Стандарт каже, що вона МУСИТЬ спрацьовувати під час переказу токенів, включно з переказами нульового обсягу. Він додає, що контракт токена, який створює нові токени, МАЄ супроводжувати це подією Transfer з адресою відправника, встановленою в 0x0. Тому міграція, яка карбує на вашу адресу, залишає переказ із нульової адреси до вас, а та, що платить із заздалегідь поповненого резерву, залишає переказ із цього резерву. В обох випадках є рядок, який можна знайти.
Значення — це balanceOf, яку стандарт описує як таку, що повертає баланс іншого рахунку за вказаною адресою власника. Це читання, воно нічого не коштує і відповідає про теперішній момент, а не про момент обміну. Відкрийте новий контракт в оглядачі блоків і викличте balanceOf зі своєю адресою. Повернуте число і є остаточною відповіддю.
| Що можна прочитати | Що це встановлює |
|---|---|
| Статус квитанції обміну | Лише те, що зовнішній виклик не відкотився |
| Подія переказу на вашу адресу | Що нові одиниці тоді вам зарахували |
| Показник balanceOf у новому контракті | Скільки ви тримаєте в цій книзі зараз |
| Список активів у гаманці | Нічого про володіння |
Чому баланс може бути вашим, а гаманець нічого не показує
Останній рядок вирішує той варіант ситуації, який виправляється безкоштовно. Гаманець не сканує кожен контракт мережі на вашу адресу. Він відмальовує список активів, який йому наказали відстежувати, а контракт, розгорнутий минулого тижня, у цьому списку відсутній, доки щось його туди не внесе.
Це відома прогалина, а не поломка. EIP-747, стандарт методу wallet_watchAsset, описує його як спосіб дозволити клієнту запропонувати гаманцю користувача токен для відстеження і прямо зазначає: без нього кожен гаманець має або заздалегідь завантажувати список схвалених активів, або користувачі мусять додавати активи вручну. Міграція дає саме цей випадок.
Виправлення — додати контракт вручну, взявши адресу з власного оголошення проєкту, а не з результату пошуку чи повідомлення в чаті. Щойно гаманець почне його відстежувати, баланс з'явиться одразу, якщо він там і був, бо у вашій позиції нічого не змінилося. Якщо він усе одно показує нуль, питання відображення знято і все інше відбувається в мережі.
Коли обмін зарахував на адресу, яка не є вашою
Контракт обміну має вирішити, кому платити, і ця адреса не завжди та, про яку ви думали. Якщо контракт зараховує тому, хто викликає, то рахунок, який підписав, і є рахунком, який отримав, а це не той рахунок, коли в одному профілі браузера відкрито два.
Складніший варіант пов'язаний із посередником. Старі одиниці, що лежать на централізованому майданчику, перебувають на його адресі, і обмін, надісланий з депозитної адреси, платить тому, кому ця адреса належить. Те саме стосується гаманця на смарт-контракті або мультипідпису. Прочитайте подію переказу і подивіться поле отримувача: воно називає зараховану адресу, і якщо це не ваша адреса, токени й не мали з'явитися там, куди ви дивитеся.
Один суто канцелярський випадок варто виключити першим. Деякі міграції випускають новий токен в іншій мережі, ніж старий, тож зарахування потрапляє в мережу, на яку ваш гаманець не переключений. Зміна мережі вирішує це за секунди.
Коли старі одиниці пішли, а назад нічого не прийшло
Якщо події переказу немає, balanceOf показує нуль, а старий баланс справді зник, то нога виплати не відпрацювала, і причин небагато.
Перша — порожній резерв. Обмін, який платить із заздалегідь внесених токенів, а не карбує їх, може прийняти ваш депозит і не заплатити, бо рахунок, з якого він платить, спорожнили. Саме від такої відмови захищає строк вікна обміну, і саме тому прочитати резерв перед надсиланням важливіше, ніж прочитати оголошення.
Друга — сума менша за очікувану, а не її відсутність. Перш ніж вирішити, що нічого не прийшло, перевірте коефіцієнт конвертації і десяткові розряди обох контрактів. Гаманець із 40 000 старих одиниць за консолідації одна нова одиниця за кожні чотири старі має право на 10 000 нових одиниць, тобто 25% від звичної йому цифри. У контракті з іншим значенням decimals коректне зарахування теж може відображатися з комою в незвичному місці.
Третя — старі одиниці пішли туди, де ноги виплати не передбачено. Надсилання токенів прямо на адресу контракту замість інтерфейсу, який його викликає, обмін не запускає. Стандарт робить це можливим, бо approve дозволяє витратній стороні списувати з вашого рахунку до заданої суми, а transferFrom слугує процедурі списання, дозволяючи контрактам переказувати токени від вашого імені. Контракт обміну розраховує забрати у вас, а не отримати щось, про що йому не повідомляли.
Міграції, які майданчик провів за ваш рахунок
Інший шлях дає ту саму скаргу з зовсім інших причин. Якщо під час міграції ви тримали старий токен на централізованому майданчику, він конвертував власний спільний баланс і переписав запис вашого рахунку, і вся подія виглядала як зміна тикера без жодної вашої транзакції.
На цьому шляху немає транзакції обміну для розбору, тож жодна з перевірок у мережі не застосовна. Застосовний розклад самого майданчика: призупинення введення та виведення старого токена, конвертація балансів рахунків і відновлення під новим тикером. Баланс, ще не конвертований під час такого призупинення, призупинений, а не втрачений.
Ці два шляхи й ескалуються по-різному. Майданчик, який вам не зарахував, — питання підтримки з названим контрагентом. У обміну в мережі, який не заплатив, контрагента в ланцюжку немає, бо контракт виконав те, що в нього записали.
Що перевіряти і в якому порядку
| Порядок | Що перевірити | Що виключає заперечна відповідь |
|---|---|---|
| 1 | Чи гаманець у тій мережі, де випущено новий токен | Проблему відображення через хибну мережу |
| 2 | Чи додано адресу нового контракту вручну | Те, що гаманець не відстежує новий контракт |
| 3 | Чи відповідає balanceOf для вашої адреси | Будь-яке інше пояснення через відображення |
| 4 | Чи має обмін подію переказу до вас | Зарахування, яке було і потім пішло |
| 5 | Яку адресу називає ця подія | Виплату на депозитну адресу |
| 6 | Чи сходяться коефіцієнт і decimals із тим, що прийшло | Коректне зарахування, прочитане як помилка |
| 7 | Чи проводив міграцію за вас майданчик | Розбір у мережі, який узагалі не застосовувався |
Ідіть цим списком згори вниз, а не впоперек. Кожен рядок прибирає клас пояснень, а нижні рядки мають сенс лише після того, як вирішено верхні. Перші три нічого не коштують.
До всієї вправи додається одне попередження. Гаманець, який виглядає таким, що втратив баланс, — саме той стан, який шукають самозванці, а кожна перевірка вище є публічним читанням, доступним вам безкоштовно. Нікому не потрібна ваша сид-фраза, щоб прочитати баланс, і пропозиція повернути зниклі мігровані токени в обмін на неї — це друга втрата, вбрана в ремонт першої.
Підсумок
Зелена транзакція обміну засвідчує, що виклик виконався, і не більше. Новий баланс записаний у новому контракті: як подія переказу в момент зарахування і як показник balanceOf після, і обидва читаються без звернення до когось. Доки ви їх не прочитали, ви не знаєте, це проблема відображення чи виплати.
Коли це проблема відображення, послідовність коротка: перемкнутися на потрібну мережу, додати адресу контракту вручну, і баланс уже там. Коли ні, подія переказу називає адресу, яку насправді зарахували, і це поле відділяє виплату не на той рахунок від виплати, якої не було. Визначте, з чим із двох ви маєте справу, перш ніж надсилати ще щось кудись. Щоб продовжити вивчати основи, читайте інші матеріали Bitbase Academy.
Схожі матеріали
Інші матеріали Bitbase на цю тему:
- Як розрахувати фінансовий запас скарбниці токен-проєкту
- Що таке криптотокен? Токени проти монет
- Стіни покупок, стіни продажів і глибина книги заявок
- Стратегія торгівлі на пробоях
Застереження: Ця стаття є освітнім матеріалом Bitbase Academy і надається лише для інформації. Вона не є інвестиційною, торговою, податковою чи фінансовою порадою. Криптоактиви волатильні — оцінюйте ризики самостійно. Написано станом на вересень 2026 року; орієнтуйтеся на найновішу офіційну інформацію.
Джерела
[1] Ethereum Improvement Proposals, ERC-20: Token Standard (EIP-20, статус Final) eips.ethereum.org
[2] Ethereum Improvement Proposals, EIP-747: wallet_watchAsset RPC Method (статус Final) eips.ethereum.org
