Jak czytać transakcję w eksploratorze: Solscan, Basescan i BscScan krok po kroku

Po co czytać transakcję w eksploratorze[11]

Wallet i aplikacja pokazują Ci swoją interpretację transakcji. Eksplorator pokazuje to, co faktycznie zapisano na łańcuchu. Na Solanie najczęściej używa się Solscan, na Base Basescan, a na BNB Chain BscScan. Etherscan w dokumentacji swojego API wymienia Base (chain ID 8453) i BNB Smart Chain (chain ID 56) wśród obsługiwanych sieci, a układ stron Basescan i BscScan jest bardzo podobny do Etherscan.

Zawsze zaczynaj od właściwej sieci. Ten sam hash albo contract address wklejony w eksplorator innej sieci nic nie znajdzie albo pokaże coś zupełnie innego.

Solscan: pola na stronie transakcji Solany[1][4]

Dokumentacja Solscan opisuje nagłówek transakcji tak: Signature to identyfikator (hash) transakcji, Block to numer slotu, w którym ją zapisano, Result pokazuje Success albo Failure oraz to, czy transakcja jest Finalized. Signer to adres nadawcy, a Fee to opłata za transakcję.

Niżej są Main Actions, czyli rozbicie na transfery, oraz Instruction Details. Według dokumentacji Solany transakcja zawiera jedną lub więcej instructions i wykonuje się atomowo: wszystkie się udają albo wszystkie są cofane. Każda instruction wskazuje program, dane i konta, które czyta lub zapisuje. Inner instructions to wywołania innych programów w trakcie wykonania, a Program log to zapis zdarzeń z programów.

Jeśli w transakcji pojawia się Create Associated Account, program utworzył nowy token account. Solscan pokazuje wtedy Authority (wallet właściciela), Associated Account (nowe konto) i Token Address (mint).

Opłaty na Solanie: base fee i priority fee[1][2]

Według dokumentacji Solany opłata bazowa to 5000 lamportów za każdy podpis: 50% jest spalane, 50% trafia do walidatora. Priority fee liczy się jako ceil(compute unit price × compute unit limit / 1 000 000) lamportów, bo cena podawana jest w mikrolamportach za compute unit. Priority fee trafia w całości do walidatora.

Pole Fee w eksploratorze to suma opłat. Nie zawiera depozytu za nowe konta: ten widać jako osobny spadek salda SOL. Recent blockhash transakcji jest ważny przez 150 slotów, więc stara, niewysłana transakcja wygasa sama.

Basescan i BscScan: pola transakcji EVM[10][8][6]

Dokumentacja Etherscan opisuje dane strony transakcji jako szczegóły po hashu (from, to, value i gas), status sukcesu lub błędu, internal transactions oraz event logs. Status pochodzi z receipt: według EIP-658 wartość 1 oznacza sukces, a 0 błąd, czyli revert transakcji lub wywołania najwyższego poziomu.

Pole To przy swapie to zwykle kontrakt routera DEX, a nie odbiorca tokenów. Value to natywna waluta (ETH na Base, BNB na BNB Chain) wysłana razem z wywołaniem. Tokeny ERC-20 widać w sekcji transferów tokenów, którą eksplorator buduje z eventów Transfer: standard ERC-20 wymaga emitowania tego eventu przy każdym transferze, także zerowym.

Gas na sieciach EVM: co znaczą liczby[7][8]

Po EIP-1559 nadawca ustala max fee per gas i max priority fee per gas. Protokół liczy priority fee jako mniejszą z wartości: max priority fee albo max fee minus base fee bloku. Effective gas price to base fee plus ta priority fee. Base fee jest spalany, priority fee dostaje producent bloku, a niewykorzystany gas (gas limit minus gas used) wraca do nadawcy.

Opłata transakcji w eksploratorze to więc gas used × effective gas price. Wysoki gas limit sam w sobie nie oznacza wysokiej opłaty. Transakcja ze statusem 0 nie wykonała swapu, ale za zużyty gas zapłaciłeś.

Jak zweryfikować swap[3][6]

Swap sprawdzasz po skutkach, nie po opisie. Na Solanie porównaj salda przed i po transakcji: odpowiedź RPC getTransaction zawiera preBalances i postBalances oraz preTokenBalances i postTokenBalances. Na sieciach EVM spójrz na transfery tokenów: ile wyszło z Twojego adresu, ile do niego wróciło i z jakiego kontraktu.

Wynik porównaj z kwotą, którą aplikacja pokazała przed podpisem. Różnica powyżej ustawionego slippage nie powinna się zdarzyć, bo wtedy transakcja powinna się nie wykonać. Upewnij się też, że otrzymany token ma właściwy contract address, a nie tylko właściwy ticker.

• Status Success na Solanie albo 1 na EVM
• Signer albo From to Twój wallet
• Wydana kwota zgadza się z tym, co zatwierdziłeś
• Otrzymany token ma właściwy contract address
• Fee jest zbliżone do tego, co pokazał wallet

Jak rozpoznać approve dla wallet drainera[6][9][5]

Standard ERC-20 definiuje approve jako zgodę dla spendera na wielokrotne pobieranie tokenów z Twojego konta do ustalonego limitu. Nowe approve nadpisuje poprzednie. Spender wykonuje potem transferFrom i przenosi tokeny bez kolejnego podpisu właściciela. Każde udane approve emituje event Approval, który widać w logach transakcji.

EIP-2612 dodaje permit: zmianę allowance na podstawie podpisanej wiadomości zamiast transakcji. Wywołać permit może dowolny adres, więc sam podpis w wallecie, bez wysyłania transakcji, wystarczy, żeby ktoś inny ustawił allowance. Na Solanie odpowiednikiem jest delegate: approve pozwala innemu adresowi przenieść lub spalić tokeny do limitu.

Czerwone flagi to approve albo permit dla adresu, którego nie znasz i który nie jest routerem DEX, bardzo duży limit, Approval w transakcji, która miała być „claimem” airdropu, oraz kolejne transferFrom z Twojego adresu, których nie inicjowałeś. W takiej sytuacji odwołaj zgodę: na EVM nowym approve z limitem 0, na Solanie instrukcją revoke.

Przykład: liczby z dokumentacji i hipotetyczny swap

Pierwszy przykład pochodzi z przykładowej odpowiedzi getTransaction w dokumentacji Solany. Drugi jest hipotetyczny i pokazuje tylko rachunek.