Projekt przenosi się na nowy kontrakt, otwierasz stronę migracji i zanim ruszy się choć jeden token, portfel prosi o zatwierdzenie starego. Prośba wygląda na dodatkowy krok, który ktoś dołożył do procesu. Nie jest. W ERC-20 to jedyny sposób, by przekazać saldo komukolwiek poza tobą, a umiejętność przeczytania tej prośby dzieli migrację od opróżnionego portfela.
Co naprawdę daje zatwierdzenie
Zatwierdzenie to wpis do rejestru, który żyje wewnątrz kontraktu starego tokena. Zapisuje jedną liczbę dla jednej pary adresów: ile tego tokena wskazany wydający może wyprowadzić z twojego konta. Podpis niczego nie przenosi, niczego nie wysyła projektowi i do żadnej wymiany cię nie zobowiązuje.
W standardzie token ERC-20 do tego rejestru sięgają dwie funkcje. `approve` pozwala wydającemu wielokrotnie pobierać z twojego konta, do ustalonej kwoty, a `transferFrom` to wywołanie, które faktycznie przenosi tokeny z jednego adresu na drugi. Specyfikacja przedstawia tę parę jako procedurę wypłaty, dzięki której kontrakty mogą przenosić tokeny w twoim imieniu, a kontrakt migracji jest jednym z takich kontraktów, bez żadnego szczególnego statusu.
Gdzie leży ten wpis, znaczy więcej, niż brzmi. Limit zapisuje się w starym tokenie, a nie w kontrakcie migracji, więc przeżywa stronę migracji, samą wymianę i projekt. Zamknięcie karty go nie kasuje.
Dlaczego kontrakt wymiany musi zapytać
Wymiana musi najpierw przejąć stare jednostki, zanim zapisze ci nowe. Kontrakt nie sięgnie na twoje konto sam, a o twoim saldzie kontrakt tokena słucha wyłącznie konta, które to saldo trzyma.
Pozorną alternatywą jest samodzielne wysłanie starych tokenów do kontraktu zwykłym przelewem. Tokeny rzeczywiście odejdą, i to również zawiedzie: zwykły przelew przychodzi jako saldo bez towarzyszącego wywołania, więc kontrakt nigdy nie dowiaduje się o przelewie i nie ma czego zapisać. Standard ERC-223 powstał dokładnie wokół tej awarii. Pobranie przez `transferFrom` daje kontraktowi jedno wywołanie, w którym przyjmuje stare jednostki i wypłaca nowe, a to wywołanie potrzebuje wcześniej limitu.
Dwie transakcje, a wymienia dopiero druga
Zatwierdzenie i wymiana to osobne transakcje, każda z własnym gazem. ERC-2612 ujmuje ten kształt wprost: jeśli użytkownik musi wejść w interakcję ze smart kontraktem, to musi wykonać 2 transakcje, `approve` oraz wywołanie kontraktu, które wewnętrznie wywoła `transferFrom`.
Właśnie dlatego, że są osobne, pierwsza może się udać, a druga i tak upaść. Zamknięte okno wymiany, opróżniona rezerwa wypłat, wstrzymany kontrakt: nic z tego nie jest widoczne dla zatwierdzenia, które tylko zapisuje liczbę i wraca. Potwierdzone zatwierdzenie nie dowodzi, że migracja za nim działa.
Odwrotna pułapka czeka krok dalej. Wymiana po udanej symulacji wciąż może się wycofać w sieci, bo symulacja odpowiada na pytanie o stan w jednej chwili, a nie o stan, w który trafia twoja transakcja. Gdy wymiana się wycofuje, przyznany limit pozostaje nienaruszony i dalej obowiązuje.
Migracje, które nie mają po co pytać
Nie każda migracja działa na limicie. Kształt, o którym ci powiedziano, powinien zgadzać się z prośbą, którą dostałeś.
| Jak prowadzona jest migracja | Co wysyłasz ty | Czy zatwierdzenie tu pasuje |
|---|---|---|
| Kontrakt wymiany pobiera twoje stare jednostki | Zatwierdzenie, potem wywołanie wymiany | Tak |
| Przelewasz stare tokeny na opublikowany adres | Jeden zwykły przelew | Nie |
| Posiadacze z migawki dostają zapis z rejestru | Nic | Nie |
| Platforma przelicza własne saldo zbiorcze | Nic | Nie |
Zatrzymać cię powinien trzeci wiersz. Rozdanie ogłoszone jako automatyczne nie ma mechanizmu, któremu potrzebny jest twój limit, więc strona prosząca o niego prosi o coś, czego opisana migracja nie używa. Zauważenie tej niezgodności nic nie kosztuje i nie zależy od niczyjej oceny witryny.
Trzy pola w prośbie, które rozstrzygają wszystko
Każda prośba o zatwierdzenie niesie te same trzy pola, niezależnie od tego, jak nazywa je twój portfel.
| Pole | Co przyznaje | Z czym to zestawić |
|---|---|---|
| Token | Do rejestru którego kontraktu trafia wpis | Adres starego kontraktu z własnego ogłoszenia projektu |
| Wydający | Który adres może pobierać z twojego konta | Adres kontraktu migracji z tego samego ogłoszenia |
| Kwota | Pułap tego, co ten adres może zabrać | Transza, którą zamierzasz teraz wymienić |
Porównuj adresy w całości. Adres łudząco podobny może dzielić z prawdziwym pierwsze i ostatnie znaki, a różnica siedzi w środku.
To pole wydającego niesie stratę i dlatego drenaż portfela nie musi niczego łamać. Wstawia w to pole własny adres i pozwala ci podpisać zatwierdzenie ważne i poprawnie zbudowane. Transakcja udaje się dokładnie tak, jak ją zapisano, a saldo odchodzi później, w terminie atakującego, nie twoim.
Kiedy proszą o podpis zamiast transakcji
Limit nie zawsze przychodzi jako transakcja. ERC-2612 rozszerza standard ERC-20 o funkcję `permit`, która pozwala użytkownikom zmieniać mapowanie allowance podpisaną wiadomością, zamiast przez `msg.sender`; ważny permit ustawia limit dla wskazanego wydającego na podaną wartość, zwiększa nonce i emituje zdarzenie zatwierdzenia.
Wniosek jest taki, że ekran z samą wiadomością do podpisania, bez gazu i bez oczekującej transakcji, potrafi przyznać dokładnie to, co przyznaje transakcja zatwierdzenia. W chwili podpisu nie zostawia też niczego w twojej własnej historii transakcji, bo podpisaną wiadomość wysyła ktoś inny.
Prośbę o podpis czytaj więc przez te same trzy pola. Permit nazywa wydającego i wartość, którą ustawia, plus deadline, do którego specyfikacja wymaga zmieścić bieżący czas bloku. Jeśli strona podaje podpis jako logowanie albo potwierdzenie, a dane typowane nazywają wydającego i kwotę, wykonane zostaną dane typowane.
Dokładna kwota czy bez limitu, i limit, który zostaje
Weź przykład. Portfel trzyma 10 000 starych jednostek, a projekt otworzył wymianę. Zatwierdzenie 2 500, wymiana tej transzy i porównanie tego, co przyszło, z ogłoszonym przelicznikiem zamienia migrację w coś zaobserwowanego, a nie założonego. Pozostałe 7 500 potrzebuje potem drugiego zatwierdzenia, czyli jednej dodatkowej opłaty za gaz, i to cały koszt tej metody.
Zatwierdzenie bez limitu usuwa tę drugą opłatę i zastępuje ją stałym pozwoleniem na ten token, dopóki wpis istnieje. Kontrakt migracji zachowuje prawo pobrać każde stare jednostki, które trafią na twoje konto później, w tym saldo starych tokenów, które odzyskasz ze starego portfela po latach.
Na koniec wyczyść to, co zostało. Zatwierdzenie na dokładną kwotę zużywa wymiana, dla której je przyznano, a wszystko ponad to zostawia żywy wpis, zaś zatwierdzenie tokenów, które przeżyło swój cel, to pozwolenie, którego nikt już nie pilnuje. Wyzerowanie limitu samo jest transakcją z własnym gazem, więc zrób to świadomie, gdy migracja się skończy.
Podsumowanie
Migracja prosi o zatwierdzenie, bo ERC-20 nie daje jej innego sposobu na zabranie twoich starych tokenów. Samo zatwierdzenie to liczba wpisana w kontrakt starego tokena, wskazująca adres i pułap: niczego nie przenosi, niczego nie dowodzi o stojącej za nim migracji i nie wygasa, gdy zamkniesz stronę.
To sprowadza całą pracę do trzech sprawdzeń. Czy ten kształt migracji w ogóle potrzebuje limitu, czy wydający to adres opublikowany przez projekt i czy kwota to transza, którą chciałeś wymienić. Prośba o podpis odpowiada na te same trzy, a przyznany limit przeżywa wszystko dokoła, więc usuń go, gdy wymiana jest zrobiona. 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
- Jak obliczyć zapas finansowy skarbca projektu tokenowego
- Wstęgi Bollingera wyjaśnione
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-2612: Permit Extension for EIP-20 Signed Approvals, sekcje Abstract i Specification (status: Final) eips.ethereum.org
[3] Ethereum Improvement Proposals, ERC-223: Token with transaction handling model, sekcja Motivation (status: Final) eips.ethereum.org
