Projekt przechodzi na nowy kontrakt tokena, ogłasza okno wymiany, a potem okno się zamyka. Kilka miesięcy później otwierasz stary portfel i saldo starego tokena wciąż tam jest. To, czy da się je jeszcze wymienić, nie jest jednym pytaniem z jedną odpowiedzią. W migracji wygasają trzy różne rzeczy, każda jest egzekwowana gdzie indziej, a tylko jedna z nich jest egzekwowana przez kod.
Co migracja tokena naprawdę przenosi
Migracja nigdzie nie przenosi twoich tokenów. Stary kontrakt dalej działa pod swoim adresem, a twoje saldo zostaje w jego rejestrze tak długo, jak długo działa łańcuch. Migracja oferuje wymianę: oddajesz stare jednostki kontraktowi wymiany albo platformie, a ona zapisuje ci równoważne roszczenie w nowym rejestrze.
Ta wymiana idzie zwykłą instalacją tokenową. W standardzie ERC-20 `approve` pozwala wydającemu pobierać z twojego konta do ustalonej kwoty, a `transferFrom` przenosi tokeny z jednego adresu na drugi; standard przedstawia tę parę jako procedurę wypłaty, która pozwala kontraktom przenosić tokeny w twoim imieniu. Kontrakt wymiany jest jednym z takich wydających i łańcuch nie daje mu żadnego szczególnego statusu.
Wynikają z tego dwie rzeczy. Twoje stare saldo samo z siebie nie niszczeje ani nie wygasa, a termin nigdy nie jest cechą tokenów, które trzymasz. Termin należy do tego, kto stoi po drugiej stronie wymiany i jest gotów zapłacić. Pytanie nie brzmi więc, czy twoje tokeny wygasły. Brzmi ono: co stało się z kontrahentem.
Wygasnąć mogą trzy rzeczy i nie są tym samym
W typowym ogłoszeniu o migracji słowo termin wykonuje zbyt dużo pracy. Rozłóż je na części, a zobaczysz kilka osobnych zegarów, z których każdy jest egzekwowany gdzie indziej.
Pierwszy to sama ogłoszona data, linijka we wpisie albo baner w aplikacji. Nic w łańcuchu jej nie czyta. Drugi to sprawdzenie wpisane w kontrakt wymiany, które odmawia wykonania, gdy bieżący znacznik czasu bloku minie wartość zapisaną w kodzie. Trzeci to rezerwa nowych tokenów, z której kontrakt płaci i którą ten, kto ją wpłacił, może wycofać, gdy projekt uzna migrację za zakończoną.
| Co wygasło | Gdzie jest egzekwowane | Czego trzeba, by otworzyć na nowo |
|---|---|---|
| Ogłoszona data | Nigdzie w łańcuchu | Niczego, kontrakt nigdy jej nie sprawdzał |
| Sprawdzenie znacznika czasu w kontrakcie wymiany | Kod kontraktu | Ścieżki aktualizacji, jeśli ją przewidziano |
| Rezerwa nowych tokenów | Saldo w łańcuchu | Żeby ktoś ponownie zasilił kontrakt |
| Obsługa migracji na platformie | Wewnętrzna polityka tej platformy | Decyzji tej platformy |
Wszystko poniżej to sposób na ustalenie, w którym wierszu jesteś.
Przeczytaj kontrakt, zanim uznasz go za zamknięty
Dwa pierwsze wiersze rozstrzygniesz sam i za darmo. Otwórz kontrakt wymiany w eksploratorze blockchaina i przeczytaj jego zweryfikowany kod źródłowy. Jeśli w funkcji wymiany nie ma żadnego porównania ze znacznikiem czasu bloku, to w kodzie nie ma terminu, a ogłoszona data była wyłącznie komunikatem. W takim przypadku wymiana wysłana rok później przechodzi dokładnie tak samo jak wysłana pierwszego dnia.
Jeśli sprawdzenie znacznika czasu jest, to inny wniosek i twardy. Kod kontraktu robi to, co w niego wpisano, a warunek cofający transakcję po ustalonym momencie będzie ją cofał dalej. Żadne zgłoszenie do wsparcia tego nie zmieni, bo nie ma tu kogo przekonywać: odmowa to linijka kodu działająca zgodnie z zamysłem.
Jedyne zastrzeżenie to możliwość aktualizacji. Jeśli wymiana stoi za proxy, którego logikę można podmienić, termin może w zasadzie zdjąć ten, kto ma takie uprawnienie. To decyzja projektu, a nie twoje prawo, ale właśnie ona odróżnia drzwi zamknięte od zaspawanych, a czytanie kontraktu jest sposobem, by je rozróżnić.
Gdy kontrakt jest otwarty, a rezerwa pusta
Kontrakt bez terminu i tak nie zapłaci z pustego konta. Nowe tokeny muszą pochodzić z rezerwy trzymanej pod adresem wymiany, a jeśli projekt napisał funkcję wymiatającą resztę po zamknięciu okna, może tę rezerwę opróżnić. Po takim wymieceniu funkcja wymiany może nadal przyjmować twoje stare tokeny i nadal się nie udawać, bo za nogą płatniczą nic już nie stoi.
Weźmy przykład. Projekt konsoliduje po jednej nowej jednostce za każde dziesięć starych, a w portfelu leży 25 000 starych jednostek, więc roszczenie wynosi 2 500 nowych. Załóżmy, że w oknie przeszło 96% starej podaży; pozostałe 4% to właśnie ta część, o którą upominają się spóźnieni, a to, czy kontrakt może te roszczenia zaspokoić, sprowadza się do salda nowych tokenów pod adresem wymiany. To saldo jest publiczne. Sprawdź je, zanim cokolwiek wyślesz.
To przypadek, który karze optymizm. Wysłanie starych tokenów do kontraktu, który nie może ci zapłacić, nie zostawia cię w punkcie wyjścia: stare jednostki poszły na adres, którego nigdy nie napisano tak, by je oddał, a nowych nie masz. Najpierw przeczytaj rezerwę, a jeśli jest pusta, nie wysyłaj.
Migracje, które platforma przeprowadziła za ciebie
Niektóre migracje w ogóle nie dotknęły twojego portfela. Jeśli w czasie wymiany trzymałeś stary token na scentralizowanej platformie, platforma przewalutowała własne saldo zbiorcze i przepisała wpis na twoim koncie, więc migracja wyglądała u ciebie jak zmiana tickera i nic więcej.
Ta droga ma własny zegar i jest polityką, a nie regułą łańcucha. Platforma ogłasza okno konwersji, zapisuje salda, które trafiły do niego w terminie, i w pewnym momencie przestaje. Kształt znany jest z delistingu tokena: zawiadomienie, okno, a potem zamknięty dostęp, przy czym późniejsze ratowanie zależy od tego, czy ta firma nadal prowadzi ręczny proces dla spóźnionych.
Są tu więc dwa pytania, nie jedno, i mają różne odpowiedzi. Czy platforma zaksięguje spóźnioną wpłatę starych tokenów, to pytanie do wsparcia. Czy kontrakt wymiany w łańcuchu jeszcze zapłaci, to pytanie do kodu. Odpowiadaj na nie osobno, bo odmowa w jednym nic nie mówi o drugim.
Co zostaje, gdy droga w łańcuchu jest zamknięta na dobre
Załóżmy, że kod jest zamknięty, rezerwa wymieciona, a żadna obsługa nie rozpatrzy spóźnionego roszczenia. Stary token nie przestał istnieć. To saldo w kontrakcie, który wciąż działa, wciąż da się je przenosić, a więc i sprzedać każdemu, kto zechce kupić, po cenie, jaką da rynek porzuconego rejestru.
Nie szukaj obejścia, wysyłając stare jednostki w miejsce, które wygląda obiecująco. Wysłanie ich do nowego kontraktu tokena albo do samego starego kontraktu to błąd tej samej klasy co wysłanie krypto na zły adres: kontrakt nie ma klucza prywatnego i jeśli nikt nie napisał funkcji wyprowadzającej zabłąkane tokeny, nikt ich nie wyjmie. Standard ERC-223 powstał właśnie wokół tej awarii i odnotowuje, że tokeny wysłane do kontraktu zwykłym przelewem przychodzą jako saldo, o którym kontrakt nigdy się nie dowiaduje.
Uczciwe podsumowanie tego przypadku brzmi tak: rozmiar straty jest już ustalony, a każda kolejna transakcja może go tylko powiększyć. Trzymanie pozycji nic nie kosztuje. Zgadywanie ratunku może kosztować resztę.
Termin migracji jest przynętą dla podszywających się
Wygasające okno tworzy presję czasu, dopływ zdezorientowanych posiadaczy i uzasadniony powód, by projekt prosił ludzi o podłączenie portfela. Atakujący nie muszą niczego z tego wymyślać. Potrzebują tylko łudząco podobnej strony. Taki jest kształt podszywania się i dlatego wynik wyszukiwania to zły sposób na dotarcie do portalu migracji.
Mechanizm, o który chodzi fałszywemu portalowi, jest ten sam, którego używa prawdziwa wymiana. Prawdziwa migracja prosi o zezwolenie, żeby kontrakt mógł pobrać twoje stare tokeny, a zatwierdzenia tokenów przyznane atakującemu robią dokładnie to, co mówią: pozwalają temu adresowi zabrać saldo, które zatwierdziłeś. Przyznawaj zezwolenie ograniczone, a nie nieograniczone, sprawdź adres kontraktu z własnym opublikowanym ogłoszeniem projektu i wchodź na stronę przez własną zakładkę.
Jedna zasada przecina całą tę kategorię. Każdy fakt potrzebny w spóźnionej migracji da się przeczytać w publicznym eksploratorze za darmo: kod źródłowy kontraktu, sprawdzenie znacznika czasu, saldo rezerwy. Kto pobiera opłatę za ponowne otwarcie zamkniętej migracji albo prosi o frazę odzyskiwania, sprzedaje ci drugą stratę, a nie naprawę pierwszej.
Podsumowanie
Stare tokeny nie wygasają. Wygasają kontrahenci. Ogłoszona data nie wiąże w łańcuchu nikogo; sprawdzenie znacznika czasu w kontrakcie wymiany wiąże wszystkich, łącznie z projektem; a wymieciona rezerwa zamyka drzwi równie skutecznie, zostawiając klamkę na miejscu. Te trzy przypadki wyglądają identycznie na ekranie portfela, a pod spodem są zupełnie inne.
Kolejność pracy jest ustalona. Przeczytaj kontrakt wymiany w eksploratorze, poszukaj sprawdzenia znacznika czasu, potem odczytaj saldo rezerwy pod tym adresem, a jeśli w grę wchodziła platforma, zapytaj ją osobno. Jeśli wszystko to wraca jako zamknięte, stare saldo nadal jest twoje i nadal przenoszalne, a żadna presja czasu nie powinna cię skłonić do wysłania go tam, skąd nic nie wróci. Aby dalej poznawać podstawy, śledź kolejne materiały Bitbase Academy.
Powiązane artykuły
Inne artykuły Bitbase na ten temat:
- Jak cofnąć delegację w zarządzaniu
- Dlaczego migracja tokena prosi o zatwierdzenie w portfelu
- Migracja tokenów zakończona, ale nowych tokenów nie ma w portfelu
- Jak obliczyć zapas finansowy skarbca projektu tokenowego
- Futures coin-margined vs USDT-margined: którym kontraktem handlować
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, metody approve i transferFrom (status: Final) eips.ethereum.org
[2] Ethereum Improvement Proposals, ERC-223: Token with transaction handling model, sekcja Motivation (status: Final) eips.ethereum.org






