Zatwierdziłeś kontrakt wymiany, wysłałeś saldo starego tokena, a eksplorator oznaczył transakcję na zielono. Dawny ticker zniknął i nic nie zajęło jego miejsca. Albo nowe jednostki nie istnieją, albo istnieją i nic ich nie rysuje. Te dwa przypadki wyglądają na ekranie portfela identycznie, a wymagają zupełnie różnych reakcji.
Co naprawdę potwierdza zakończona wymiana
Potwierdzona transakcja wymiany mówi ci, że twoje wywołanie trafiło do bloku i że najbardziej zewnętrzna część wykonania nie została wycofana. To wszystko. Pomyślny status potwierdzenia jest stwierdzeniem o wywołaniu, a nie spisem tego, co wywołanie zaksięgowało.
Wymiana migracyjna ma dwie nogi i dlatego ta różnica ma tu większe znaczenie niż gdzie indziej. Jedna noga zabiera twoje stare jednostki. Druga wypłaca nowe. Potwierdzenie obejmuje transakcję jako całość, a kontrakt można napisać tak, że druga noga zrobi mniej, niż oczekiwałeś, albo nic, a pierwsza się nie cofnie.
Pytanie do rozstrzygnięcia nie brzmi więc, czy wymiana zadziałała. Brzmi ono, czy nowe saldo jest teraz zapisane na twój adres, a jeśli tak, dlaczego nic go nie rysuje. To dwa osobne dochodzenia, a taka kolejność oszczędza ci sporu z obsługą o saldo, które już posiadasz.
Gdzie naprawdę zapisane jest nowe saldo
Nowy token to zwykły kontrakt z własną księgą, a standard tokenów ERC-20 zapisuje twoją pozycję w nim dwukrotnie: raz jako zdarzenie w chwili uznania i raz jako wartość, którą kontrakt zwraca na żądanie.
Zdarzeniem jest Transfer. Standard mówi, że MUSI ono zostać wywołane przy transferze tokenów, łącznie z transferami o wartości zerowej. Dodaje, że kontrakt tokena tworzący nowe tokeny POWINIEN wywołać zdarzenie Transfer z adresem nadawcy ustawionym na 0x0. Migracja, która emituje na twój adres, zostawia więc transfer z adresu zerowego do ciebie, a ta, która płaci z zasilonej wcześniej rezerwy, zostawia transfer z tej rezerwy. W obu przypadkach jest linia do znalezienia.
Wartością jest balanceOf, którą standard opisuje jako zwracającą saldo innego konta o podanym adresie właściciela. To odczyt, nic nie kosztuje i odpowiada na teraz, a nie na moment wymiany. Otwórz nowy kontrakt w eksploratorze bloków i wywołaj balanceOf ze swoim adresem. Zwrócona liczba jest odpowiedzią rozstrzygającą.
| Co możesz odczytać | Co to rozstrzyga |
|---|---|
| Status potwierdzenia wymiany | Tylko to, że zewnętrzne wywołanie się nie cofnęło |
| Zdarzenie transferu na twój adres | Że nowe jednostki zostały ci wtedy uznane |
| Odczyt balanceOf w nowym kontrakcie | Ile trzymasz w tej księdze teraz |
| Lista aktywów w portfelu | Nic o własności |
Dlaczego saldo może być twoje, a portfel nic nie pokazuje
Ostatni wiersz rozstrzyga tę wersję sytuacji, której naprawa nic nie kosztuje. Portfel nie skanuje każdego kontraktu w sieci pod kątem twojego adresu. Rysuje listę aktywów, które kazano mu śledzić, a kontrakt wdrożony w zeszłym tygodniu nie jest na tej liście, dopóki coś go tam nie wpisze.
To znana luka, a nie usterka. EIP-747, standard stojący za metodą wallet_watchAsset, opisuje ją jako sposób, by klient mógł zaproponować portfelowi użytkownika token do śledzenia, i stwierdza, że bez niej każdy portfel musi albo wstępnie ładować listę zatwierdzonych aktywów, albo użytkownicy muszą dodawać aktywa ręcznie. Migracja daje dokładnie ten przypadek.
Naprawą jest ręczne dodanie kontraktu, z adresem wziętym z własnego ogłoszenia projektu, a nie z wyniku wyszukiwania czy wiadomości na czacie. Gdy portfel zacznie go śledzić, saldo pojawi się od razu, jeśli tam było, bo w twojej pozycji nic się nie zmieniło. Jeśli nadal pokazuje zero, kwestia wyświetlania jest wykluczona, a wszystko pozostałe dzieje się w sieci.
Gdy wymiana uznała adres, który nie jest twój
Kontrakt wymiany musi zdecydować, komu zapłacić, a ten adres nie zawsze jest tym, o którym myślałeś. Jeśli kontrakt uznaje wywołującego, to konto, które podpisało, jest kontem, które otrzymało, a to niewłaściwe konto, gdy w jednym profilu przeglądarki otwarte są dwa.
Trudniejsza wersja dotyczy pośrednika. Stare jednostki trzymane na scentralizowanej platformie leżą pod jej adresem, a wymiana wysłana z adresu depozytowego płaci temu, do kogo ten adres należy. To samo dotyczy portfela kontraktowego lub multisiga. Odczytaj zdarzenie transferu i sprawdź pole odbiorcy: nazywa ono uznany adres, a jeśli to nie jeden z twoich, tokeny nigdy nie miały pojawić się tam, gdzie patrzysz.
Jeden przypadek porządkowy warto wykluczyć najpierw. Niektóre migracje emitują nowy token w innej sieci niż stary, więc uznanie trafia do sieci, na którą twój portfel nie jest przełączony. Zmiana sieci rozstrzyga to w kilka sekund.
Gdy stare jednostki odeszły i nic nie wróciło
Jeśli zdarzenia transferu nie ma, balanceOf zwraca zero, a stare saldo faktycznie zniknęło, to noga płatności nie zadziałała, a powodów jest niewiele.
Pierwszym jest pusta rezerwa. Wymiana płacąca z wcześniej wpłaconych tokenów, a nie emitująca ich, może przyjąć twój depozyt i nie zapłacić, bo konto, z którego płaci, zostało opróżnione. Przed taką awarią chroni termin okna wymiany i dlatego odczytanie rezerwy przed wysłaniem znaczy więcej niż odczytanie ogłoszenia.
Drugim jest kwota mniejsza od oczekiwanej, a nie jej brak. Zanim uznasz, że nic nie dotarło, sprawdź współczynnik konwersji i liczbę miejsc dziesiętnych obu kontraktów. Portfel z 40 000 starych jednostek przy konsolidacji jednej nowej jednostki za każde cztery stare ma prawo do 10 000 nowych jednostek, czyli 25% liczby, do której przywykł. W kontrakcie o innej wartości decimals poprawne uznanie może też wyświetlić się z przecinkiem w nieznanym miejscu.
Trzecim jest to, że stare jednostki trafiły tam, gdzie nie ma nogi płatności. Wysłanie tokenów wprost na adres kontraktu zamiast przez interfejs, który go wywołuje, nie uruchamia wymiany. Standard to umożliwia, bo approve pozwala wydającemu pobierać z twojego konta do ustalonej kwoty, a transferFrom służy procedurze pobrania, pozwalając kontraktom przenosić tokeny w twoim imieniu. Kontrakt wymiany oczekuje, że pobierze od ciebie, a nie że dostanie coś, o czym nigdy mu nie powiedziano.
Migracje przeprowadzone za ciebie przez platformę
Inna ścieżka rodzi tę samą skargę z zupełnie innych powodów. Jeśli w czasie migracji trzymałeś stary token na scentralizowanej platformie, przeliczyła ona własne saldo zbiorcze i przepisała wpis twojego konta, a całe zdarzenie objawiło się jako zmiana tickera bez żadnej twojej transakcji.
Na tej ścieżce nie ma transakcji wymiany do zbadania, więc żadna z kontroli w sieci nie ma zastosowania. Zastosowanie ma harmonogram samej platformy: zawieszenie wpłat i wypłat starego tokena, przeliczenie sald kont i wznowienie pod nowym tickerem. Saldo jeszcze nieprzeliczone w czasie takiego zawieszenia jest wstrzymane, a nie stracone.
Te dwie ścieżki eskalują się też inaczej. Platforma, która ci nie uznała, to sprawa obsługi z nazwanym kontrahentem. Wymiana w sieci, która nie zapłaciła, nie ma kontrahenta w pętli, bo kontrakt wykonał to, co w nim zapisano.
Co sprawdzić i w jakiej kolejności
| Kolejność | Co sprawdzić | Co wyklucza odpowiedź przecząca |
|---|---|---|
| 1 | Czy portfel jest w sieci, w której wydano nowy token | Problem wyświetlania z powodu złej sieci |
| 2 | Czy adres nowego kontraktu dodano ręcznie | To, że portfel nie śledzi nowego kontraktu |
| 3 | Czy balanceOf odpowiada dla twojego adresu | Każde pozostałe wyjaśnienie przez wyświetlanie |
| 4 | Czy wymiana niesie zdarzenie transferu do ciebie | Uznanie, które było i potem odeszło |
| 5 | Jaki adres nazywa to zdarzenie | Wypłatę na adres depozytowy |
| 6 | Czy współczynnik i decimals zgadzają się z wpływem | Poprawne uznanie odczytane jako błędne |
| 7 | Czy migrację przeprowadziła za ciebie platforma | Dochodzenie w sieci, które nigdy nie miało zastosowania |
Idź w dół tej listy, a nie w poprzek. Każdy wiersz usuwa klasę wyjaśnień, a wiersze niższe mają sens dopiero po rozstrzygnięciu wyższych. Pierwsze trzy nic nie kosztują.
Do całego ćwiczenia dołącza jedno ostrzeżenie. Portfel, który wygląda na taki, co stracił saldo, to dokładnie ten stan, którego szukają podszywacze, a każda kontrola powyżej jest publicznym odczytem, który wykonasz za darmo. Nikt nie potrzebuje twojej frazy odzyskiwania, by odczytać saldo, a oferta odzyskania brakujących migrowanych tokenów w zamian za nią to druga strata przebrana za naprawę pierwszej.
Podsumowanie
Zielona transakcja wymiany potwierdza, że wywołanie się wykonało, i nic więcej. Nowe saldo jest zapisane w nowym kontrakcie: jako zdarzenie transferu w chwili uznania i jako odczyt balanceOf później, a oba są czytelne bez pytania kogokolwiek. Dopóki ich nie odczytasz, nie wiesz, czy to problem wyświetlania, czy problem płatności.
Gdy jest to problem wyświetlania, sekwencja jest krótka: przełącz się na właściwą sieć, dodaj adres kontraktu ręcznie i saldo już tam jest. Gdy nie jest, zdarzenie transferu nazywa adres faktycznie uznany, a to pole oddziela płatność wysłaną na złe konto od płatności, której nie było. Rozstrzygnij, z którą z dwóch masz do czynienia, zanim wyślesz cokolwiek innego gdziekolwiek. Aby dalej poznawać podstawy, śledź kolejne materiały Bitbase Academy.
Powiązane artykuły
Inne artykuły Bitbase na ten temat:
- Jak obliczyć zapas finansowy skarbca projektu tokenowego
- Czym jest token kryptowalutowy? Tokeny a monety
- Mury kupna, mury sprzedaży i głębokość księgi
Zastrzeżenie: ten artykuł to treść edukacyjna Bitbase Academy, wyłącznie w celach informacyjnych. Nie stanowi porady inwestycyjnej, handlowej, podatkowej ani finansowej. Kryptoaktywa są zmienne — samodzielnie oceń ryzyko. Napisano w wrześniu 2026 r.; sprawdzaj aktualne oficjalne informacje.
Źródła
[1] Ethereum Improvement Proposals, ERC-20: Token Standard (EIP-20, status Final) eips.ethereum.org
[2] Ethereum Improvement Proposals, EIP-747: wallet_watchAsset RPC Method (status Final) eips.ethereum.org
