Przelew, który trafił nie tam, gdzie miał, to nie jeden problem z jedną odpowiedzią. To pięć różnych problemów, a różni je warstwa, na której pojawił się błąd: odbiorca, sieć, wewnętrzna księgowość platformy, smart contract albo adres, do którego nikt nie ma klucza. Ten artykuł przechodzi przez te pięć warstw, mówi, od czego naprawdę zależy każda z nich, i zaznacza te, które są nieodwracalne. Nazywa też oszustwo, które czeka na szukających wyjścia.
Zacznij od zapisu w łańcuchu, a nie od wyszukiwarki
Zanim zrobisz cokolwiek innego, ustal, co się faktycznie stało, i weź to z łańcucha, a nie z pamięci. Eksplorator sieci, której użyłeś, pokaże transakcję, jej potwierdzenie, adres nadawcy i odbiorcy oraz to, jaki aktyw się przesunął. Wszystkie oceny poniżej opierają się na poprawnym odczytaniu tego zapisu.
Potwierdzenie oznacza, że sieć przyjęła transakcję i ją zapisała. Nie oznacza, że przelew poszedł tam, gdzie chciałeś. Ważność dotyczy podpisów i sald, o zamiarze nie mówi nic, więc transakcja może być jednocześnie całkowicie ważna i całkowicie błędna.
Nieodwracalny jest sam wpis w rejestrze. Nikt nie odpisze potwierdzonej transakcji, a publiczny łańcuch nie ma infolinii z przyciskiem cofnij. Wszystko, co wygląda na cofnięcie, jest w istocie drugim przelewem, odesłanym przez tego, kto teraz dysponuje monetami.
Dlatego użyteczne pytanie nigdy nie brzmi, czy da się to cofnąć. Brzmi ono: kto lub co kontroluje teraz adres docelowy i czy ta strona ma zarówno możliwość, jak i powód, by odesłać środki. Możliwość to klucz albo linijka kodu, powód to człowiek albo regulamin. Czytaj każdy przypadek poniżej przez te dwa słowa.
Dobra sieć, zły odbiorca
Najprostsza wersja błędu: adres poprawnie zbudowany, sieć właściwa, a środki leżą teraz u kogoś innego w tym samym łańcuchu. Nic się nie zepsuło. Łańcuch zrobił dokładnie to, co podpisałeś.
Odzyskanie zależy tu od strony na drugim końcu i od niczego więcej. Jeśli adres należy do kogoś, kogo potrafisz zidentyfikować, kontrahenta, sprzedawcy, znajomego, to jest to zwyczajna rozmowa o zwyczajnym wyniku, który może być zgodą i może być odmową. Jeśli adresu zidentyfikować nie potrafisz, nie masz żadnej dźwigni: eksplorator pokaże ci jego aktywność, ale nie da ci nazwiska, a żadne śledzenie nie zmieni tego, kto ma klucz.
Większość literówek nigdy nie zachodzi tak daleko, bo formaty adresów niosą sumy kontrolne. ERC-55 koduje około 15 bitów kontrolnych w wielkość liter adresu Ethereum, więc portfele odrzucają literówkę przed wysłaniem; według szacunku samego standardu błędnie wpisany adres i tak przechodzi w około 0,02% przypadków. Adresy Bitcoina w formacie bech32 idą dalej: ich kod z gwarancją wykrywa każdy błąd dotyczący najwyżej 4 znaków.
Wynikają z tego dwa nawyki. Adresy wklejaj, a nie przepisuj, a po wklejeniu porównaj pierwsze i ostatnie znaki ze źródłem, bo złośliwe oprogramowanie podmieniające schowek podstawia adres poprawny, który każda suma kontrolna chętnie przyjmie. Zwróć też uwagę, czego BIP-173 wymaga od twórców oprogramowania: nie poprawiać adresów automatycznie, bo poprawiony, ale niewłaściwy adres jest w pełni ważnym celem i środki pójdą właśnie tam.
Dobry adres, zła sieć
Wszystkie łańcuchy EVM używają tego samego formatu adresu, a powód łatwo przeoczyć. Adres Ethereum to ostatnie 20 bajtów skrótu twojego klucza publicznego, a to wyprowadzenie nie ma nic wspólnego z tym, w jakim jesteś łańcuchu. Ten sam klucz kontroluje więc ten sam adres w Ethereum, w rollupach i w każdym innym istniejącym łańcuchu EVM.
To wygodne i dokładnie dlatego ten błąd jest tak łatwy do popełnienia. Portfel przyjmie ten adres w każdym z tych łańcuchów bez zastrzeżeń, bo we wszystkich jest on adresem prawidłowym.
W łańcuchu nic nigdzie nie przeszło. EIP-155 wkłada identyfikator łańcucha w dane, które podpisujesz, więc przelew w jednym łańcuchu po prostu nie jest przelewem w drugim. Twoje tokeny nie są w drodze ani nie utknęły między sieciami: są saldem w rejestrze łańcucha, którego faktycznie użyłeś, pod adresem, który faktycznie wpisałeś.
O tym, czy je odzyskasz, decyduje jedno pytanie: czy masz klucz do tego adresu. Jeśli wysłałeś z portfela samodzielnego na własny adres, to zwykle wystarczy dodać sieć docelową w tym portfelu i opłacić jej prowizję, a saldo się pokaże. Do poruszenia czegokolwiek potrzebna będzie natywna moneta tego łańcucha, co jest osobnym drobnym problemem jajka i kury. Jeśli wysłałeś na adres depozytowy wydany przez platformę, tego klucza nie masz i to zupełnie inny przypadek.
Jedno nie przechodzi razem z adresem: sam aktyw. Kontrola nad adresem nie zależy od łańcucha, a token zależy. To, co wysłałeś, istnieje tylko w rejestrze łańcucha, w którym to wysłałeś, więc dotrzeć do tego można wyłącznie tam: jego ustawieniami sieci, jego monetą na prowizje, jego eksploratorem. Nic, co zrobisz w łańcuchu, który miałeś na myśli, tego aktywu nie wytworzy.
Wpłata na platformę: nieobsługiwana sieć albo brak memo
Adres depozytowy wystawiony przez platformę scentralizowaną jest kontrolowany przez tę platformę, a nie przez ciebie. Ten jeden fakt zmienia kształt problemu: niczego nie rozstrzyga tu kryptografia, a wszystko rozstrzyga proces wewnętrzny, więc nie ma odpowiedzi ogólnej ani żadnej uczciwej odpowiedzi zaczynającej się od tak.
W wersji z nieobsługiwaną siecią wysłałeś aktyw łańcuchem, z którego ten adres depozytowy nigdy nie miał księgować wpłat. W łańcuchu z przelewem wszystko jest w porządku. W księgach platformy nie stało się nic, bo oprogramowanie pilnujące wpłat tego łańcucha nie pilnowało. Liczy się dalej to, czy platforma kontroluje ten adres w tym łańcuchu i czy w ogóle prowadzi ręczną procedurę odzyskiwania. Jedne prowadzą, inne nie, jeszcze inne dopiero powyżej pewnego progu kwotowego i za opłatą. To kwestia regulaminu, nie fizyki.
W wersji z brakującym memo sieć prowadzi wielu klientów przez jeden wspólny adres i rozróżnia ich dodatkowym polem. Tagi docelowe w XRP Ledger są najczystszym przykładem, a specyfikacja mówi wprost, czym one są: tagi nie pełnią w rejestrze żadnej bezpośredniej funkcji, istnieją wyłącznie po to, by powiedzieć systemom poza łańcuchem, jak przetworzyć płatność. Wyślij bez taga, a pieniądze dotrą pod właściwy adres, nie niosąc ze sobą niczego, co mówiłoby, czyje są.
Wynikają z tego dwie rzeczy. Po pierwsze, dlatego adres odbiorczy może włączyć ustawienie wymagające taga docelowego, przez co rejestr wprost odrzuca płatność bez taga, zamiast przyjmować taką, której nikt nie umie zaksięgować. Po drugie, gdy to ustawienie jest wyłączone, wracasz do procesu ludzkiego: kolejka wsparcia, zestaw logów, zestaw reguł. Użyteczne, co możesz dostarczyć, to hash transakcji z eksploratora. Pewności w ofercie nie ma.
Adresy kontraktów i adresy, do których nikt nie ma klucza
Wysłanie tokenów na smart contract to znów inna awaria i akurat ta najczęściej wydaje się naprawialna, bo przecież kontrakt może je po prostu odesłać. Czasem może. Zwykle nie może.
Konta kontraktowe nie mają klucza prywatnego. Rządzi nimi ich kod, a kod robi wyłącznie to, co ktoś w nim napisał. Jeśli kontrakt nie zawiera funkcji wyprowadzającej dowolny token, to nikt tego tokena nie ruszy: ani wdrażający, ani audytorzy, ani sąd.
Problem się nawarstwia, bo funkcja transfer w ERC-20 nie powiadamia odbiorcy. Właśnie ta luka jest deklarowaną motywacją ERC-223: przy zwykłym przelewie ERC-20 tokeny trafiają na kontrakt jako saldo, o którym kontrakt nigdy się nie dowie, a jeśli nie został napisany pod ich obsługę, mogą tam zostać na stałe. Najczęstszy przypadek ze wszystkich to wysłanie tokena pod adres jego własnego kontraktu.
Wyjątki istnieją i są zamierzone. Na przykład kontrakt jednego z największych stablecoinów zawiera komponent ratunkowy: wyznaczona rola rescuer może wywołać funkcję wyprowadzającą dowolny token ERC-20 wysłany na kontrakt przez pomyłkę. Ktoś to celowo zbudował. Czy dany kontrakt ma odpowiednik, da się sprawdzić z góry, czytając jego zweryfikowany kod źródłowy w eksploratorze, i to jedyne, co rozstrzyga ten przypadek.
Na drugim krańcu są adresy, do których nikt nie ma klucza. Adres Ethereum to 20 bajtów danych i nic więcej; nie ma reguły mówiącej, że pasujący klucz istnieje albo kiedykolwiek istniał. Adresy spalania są używane właśnie dlatego, że nikt nie ma z nich wydawać środków. Wyślij tam albo pod adres wygenerowany z klucza, którego nigdy nie zapisano, a nie ma kogo przekonywać, nie ma jakiego procesu otwierać i nie ma czego kupować. To koniec, a powiedzenie tego wprost jest bardziej użyteczne niż nadzieja.
Usługa odzyskiwania to druga strata
Na każdego, kto rusza szukać wyjścia z pierwszej straty, czeka druga, i jest to dobrze udokumentowane. Centrum Zgłaszania Przestępstw Internetowych FBI wielokrotnie ostrzegało przed firmami, które reklamują śledzenie kryptowalut i obiecują odzyskanie utraconych środków: pobierają opłatę z góry, a potem albo przestają odpisywać, albo produkują cienki raport i proszą o więcej pieniędzy.
Sygnały strukturalne są proste. IC3 stwierdza, że prywatne firmy odzyskujące nie mogą wydawać nakazów zajęcia, a organy ścigania nie pobierają od poszkodowanych opłat za prowadzenie śledztwa. Każdy więc, kto powołuje się na urząd, żeby sprzedać ci usługę, już powiedział ci, kim jest, a każdy, kto chce zapłaty przed rozpoczęciem pracy, dopowiedział resztę.
Jest jeszcze sama prośba. Seed phrase albo klucz prywatny to jest właśnie władza nad środkami: kto je ma, ten porusza pieniędzmi, i na tym cały system jest zbudowany. Żaden prawdziwy proces odzyskiwania nie potrzebuje twoich, w żadnych okolicznościach i z żadnego powodu. Prośba o seed phrase nie jest krokiem do odzyskania. Jest kradzieżą.
Zwróć uwagę, co łączy pięć omówionych przypadków. Każdy z nich opiera się na faktach, które sprawdzisz sam i za darmo w publicznym eksploratorze: który adres trzyma teraz środki, czy jest kontraktem, czy kontrakt ma funkcję ratunkową, czy sieć była w ogóle tą, o którą ci chodziło. Żeby przeczytać publiczny rejestr, nikomu nie trzeba płacić z góry.
Podsumowanie
W potwierdzonym przelewie nie da się cofnąć niczego, więc żywe pozostaje jedno pytanie: kto kontroluje odbiorcę i czy może oraz chce odesłać środki. Zły odbiorca we właściwej sieci zależy od człowieka, którego możesz nie umieć zidentyfikować. Ten sam adres w złym łańcuchu EVM zależy od tego, czy masz tam klucz i czy opłacisz prowizję tego łańcucha. Wpłata na platformę nieobsługiwaną siecią lub bez wymaganego memo zależy od wewnętrznego procesu tej platformy, a to regulamin, nie twoje prawo. Adres kontraktu zależy od tego, czy ktoś wpisał do kodu funkcję ratunkową, a większość nie wpisała. Adres, do którego nikt nie ma klucza, jest ostateczny. Przeczytaj transakcję w eksploratorze, ustal, w którym z pięciu przypadków jesteś, i potraktuj każdego, kto sprzedaje nadzieję za opłatę z góry albo za seed phrase, jako drugi atak, a nie jako wyjście.
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 sierpniu 2026 r.; sprawdzaj aktualne oficjalne informacje.
Źródła
[1] Ethereum Improvement Proposals, ERC-55: Mixed-case checksum address encoding eips.ethereum.org
[2] Bitcoin Improvement Proposals, BIP-173: Base32 address format for native v0-16 witness outputs github.com
[3] ethereum.org, Developer documentation, Ethereum accounts ethereum.org
[4] Ethereum Improvement Proposals, EIP-155: Simple replay attack protection eips.ethereum.org
[5] Ethereum Improvement Proposals, ERC-223: Token with transaction handling model eips.ethereum.org
[6] XRP Ledger, official documentation, Source and Destination Tags xrpl.org
[7] Circle, stablecoin-evm repository, Rescuable.sol github.com
[8] FBI Internet Crime Complaint Center, Alert I-081123-PSA, Increase in Companies Falsely Claiming an Ability to Recover Funds Lost in Cryptocurrency Investment Scams ic3.gov
