How to Assess Web3 Project Risks: A Practical User Checklist

In Web3, users often hold their own keys and sign transactions directly. A useful review therefore starts not with “How much can I earn?” but with: What am I signing, which code will gain access to my assets, and who can change the rules?

Żadna lista kontrolna nie może dowieść, że projekt jest bezpieczny. Jej celem jest ujawnienie niewiadomych, porównanie deklaracji ze sprawdzalnymi dowodami i ograniczenie potencjalnych szkód.

Ten artykuł ma wyłącznie charakter edukacyjny i nie stanowi porady finansowej, inwestycyjnej ani prawnej. Transakcje Web3 mogą prowadzić do całkowitej utraty przesłanych aktywów.

1. Zweryfikuj źródło

• Użyj zapisanej zakładki lub adresu URL z potwierdzonego oficjalnego kanału.
• Sprawdź każdy znak w domenie.
• Nie podłączaj portfela przez reklamy, niezamówione wiadomości ani przypadkowe wyniki wyszukiwania.
• Porównaj adresy kontraktów w oficjalnych materiałach projektu.
• Nigdy nie ujawniaj frazy seed ani klucza prywatnego.

Stop signal: a site asks you to “synchronize,” “validate,” or “restore” a wallet by entering secret words.

2. Potwierdź sieć i aktywo

Przed przesłaniem czegokolwiek zapisz:

• sieć;
• adres smart kontraktu tokena;
• adres odbiorcy lub wywoływanego smart kontraktu;
• kwota;
• aktywo używane do opłaty;
• zamierzoną operację.

A name such as USDT does not uniquely identify a token. Verify the full token contract address. The same 0x… address format can be used on different EVM networks, but assets and state remain network-specific.

Stop signal: the project gives a ticker but does not publish the network and token address.

3. Sprawdź wdrożony kod

W eksploratorze blockchaina:

• znajdź smart kontrakt za pomocą oficjalnego adresu;
• sprawdź weryfikację kodu źródłowego;
• ustal, czy jest to proxy;
• otwórz bieżącą implementację;
• porównaj wszystkie adresy z dokumentacją projektu.

On BscScan, Exact Match means published source and constructor parameters were matched to deployed bytecode. This improves transparency but is not a security assessment.

Stop signal: no address is published, source is unverified, and the project still claims “full transparency” without explanation.

4. Poznaj uprawnienia administracyjne

Szukaj ról i funkcji takich jak:

• owner, admin, operator i upgrader;
• wstrzymywać i wznawiać działanie;
• zmiany opłat lub limitów;
• zmiany powiązanych adresów;
• emisja tokenów;
• wypłacanie aktywów;
• aktualizacje implementacji;
• blokowanie adresów.

Ustal, kto kontroluje te klucze, czy używany jest multisig, czy zmiany są objęte timelockiem i w jaki sposób powiadamia się użytkowników. Scentralizowana kontrola nie oznacza automatycznie oszustwa, ale tworzy zależność od konkretnych osób kontrolujących system.

Stop signal: one address holds critical powers while the project claims that nobody can change anything.

5. Prawidłowo interpretuj audyt

Sprawdź, czy:

• raport został opublikowany przez audytora;
• wskazano repozytorium i hash commita;
• aktywny smart kontrakt jest objęty zakresem;
• raport obejmuje aktualną implementację;
• pozostały nierozwiązane ustalenia;
• poprawki zostały ponownie przetestowane;
• ważne komponenty zostały wyłączone z zakresu.

Audyt jest dodatkowym niezależnym przeglądem. Nie może wykryć każdej wady i nie obejmuje automatycznie witryny, zarządzania kluczami, modelu biznesowego ani przyszłych aktualizacji.

Stop signal: there is an “Audited” badge but no report or reviewed code version.

6. Porównaj Claims z działaniem on-chain

Sprawdź kilka transakcji pod kątem:

• status;
• From and To / Interacted With;
• przepływy BEP-20;
• wywołania wewnętrzne;
• logi;
• opłaty;
• zmiany sald i stanu smart kontraktu.

Compare the actual path of funds with the published architecture. Do not draw a system-wide conclusion from one demonstration transaction. Success means the code executed without reverting; it does not mean the operation was safe or beneficial.

Stop signal: observable fund flows differ from the stated process and no clear explanation is provided.

7. Oddziel aktywa od zobowiązań

Widoczne saldo adresu jest tylko jednym faktem. Zapytaj:

• czy ujawniono wszystkie istotne adresy;
• kto kontroluje aktywa;
• czy można je wypłacić;
• jakie zobowiązania istnieją wobec innych użytkowników;
• jak ustalana jest cena zewnętrzna;
• czy dostęp zależy od mostu, DEX, wyroczni lub kontrahenta.

Duże saldo tokena nie dowodzi płynności. Duża liczba jednostek może mieć niewielką wartość możliwą do zrealizowania.

Stop signal: one address balance is presented as proof of solvency without disclosing obligations or control rights.

8. Wyjaśnij model ekonomiczny prostym językiem

Znajdź jednoznaczne odpowiedzi na pytania:

• skąd pochodzi każda wypłata;
• kto płaci opłaty;
• co się stanie, jeśli nie pojawią się nowi użytkownicy;
• warunki wyjścia i blokady;
• gdzie mogą wystąpić straty;
• które parametry mogą zmieniać administratorzy;
• co kształtuje cenę tokena.

Jeśli wynik zależy od rynków, nowych uczestników, płynności lub decyzji zespołu, zależności te powinny być jasno wskazane.

Stop signal: a fixed outcome is promised without a verifiable source of funds or loss scenario.

9. Kontroluj podpisy i uprawnienia do tokenów

Przed potwierdzeniem sprawdź, co pokazuje portfel:

• sieć;
• wywoływany adres;
• funkcję lub czytelną operację;
• wartość natywnego tokena;
• token i kwota allowance;
• oczekiwane zmiany aktywów.

An approve call does not immediately transfer a token. It may authorize a spender contract to call transferFrom up to an allowance. An unlimited allowance increases potential loss if the spender is compromised or flawed.

Odrzuć podpis, jeśli dane są niejasne lub adres różni się od sprawdzonego. Po użyciu przejrzyj zgody i cofnij te, które nie są już potrzebne, korzystając z zaufanego narzędzia.

Stop signal: you are pressured to sign unreadable data or told that a signature “does nothing.”

10. Uwzględnij ryzyka off-chain

Nawet dokładnie sprawdzony kod nie może zapobiec każdemu:

• przejęcie witryny lub DNS;
• złośliwe rozszerzenie przeglądarki;
• kradzież klucza;
• przejęte konto projektu;
• awarię backendu;
• atak socjotechniczny;
• ograniczenie prawne;
• awarię pomocy technicznej lub operacyjną.

Sprawdź dokumentację, procedury obsługi incydentów, kanały powiadomień i historię zmian. Oceniaj twierdzenia prawne na podstawie rzeczywistych dokumentów i przepisów właściwych dla swojej jurysdykcji.

11. Ogranicz potencjalne straty

Nawet po zakończeniu przeglądu:

• zacznij od najmniejszej praktycznej kwoty testowej;
• używaj osobnego portfela do nieznanych dApps;
• nie przechowuj wszystkich aktywów w podłączonym portfelu;
• nigdy nie podpisuj pod presją czasu;
• zapisuj hashe transakcji i adresy;
• regularnie sprawdzaj allowance tokenów;
• ustal maksymalną ekspozycję, której całkowita utrata byłaby możliwa do zaakceptowania.

Oficjalne zalecenia Solidity dotyczące bezpieczeństwa sugerują ograniczenie ilości aktywów przechowywanych w smart kontrakcie: jeśli w kodzie, kompilatorze lub platformie występuje błąd, ograniczenie ekspozycji może zmniejszyć straty.

Lista kontrolna przed transakcją

Answer yes, no, or unknown:

• Sprawdziłem domenę.
• Znam dokładną sieć.
• Sprawdziłem adres smart kontraktu tokena.
• Sprawdziłem adres wywoływanego smart kontraktu.
• Znam status weryfikacji kodu źródłowego.
• Sprawdziłem proxy i implementację.
• Rozumiem uprawnienia administratora.
• Audyt odpowiada aktywnej wersji.
• Sprawdziłem rzeczywiste transakcje.
• Rozumiem źródło wypłat i scenariusze strat.
• Rozumiem żądanie podpisu.
• Wysokość allowance jest rozsądnie ograniczona.
• Uwzględniłem ryzyka związane z frontendem, kluczami i kwestiami prawnymi.
• Kwota testowa nie może spowodować krytycznej szkody.

For a critical question, unknown is not a neutral answer—it is an unassessed risk. Pausing for verification is usually cheaper than an irreversible transaction.

Pytania, które powinien zadać ostrożny użytkownik

Is a project safe if its code is open and audited?
No. Those are useful signals, but unknown bugs and administrative, operational, economic, and external risks remain.

If assets are visible on-chain, can they definitely be returned?
No. Return depends on code, current state, control rights, and external dependencies.

Does a small successful test prove a larger transaction will work?
No. It tests one path at one moment. Limits, liquidity, state, and implementation may later differ.

What if I do not understand the signature?
Reject it. Identify the function, called address, asset changes, and permissions before trying again.

Źródła i dalsza lektura

1. Solidity Documentation — Kwestie bezpieczeństwa
2. Ethereum.org — Bezpieczeństwo smart kontraktów
3. Ethereum.org — Testowanie smart kontraktów
4. BscScan Information Center — Przeglądanie transakcji
5. BscScan Information Center — Rodzaje weryfikacji smart kontraktów
6. BscScan Information Center — Czym jest adres?
7. OpenZeppelin Docs — Wzorzec aktualizacji proxy