Zellic to firma zajmująca się bezpieczeństwem blockchainów – audytuje smart kontrakty, protokoły DeFi, mosty między sieciami, portfele i implementacje kryptografii. Jej zespół wywodzi się ze środowiska konkursów CTF (Capture The Flag), a raporty z audytów są publikowane i często linkowane w dokumentacji projektów. Dla inwestora nazwa Zellic zwykle pojawia się w jednym kontekście: projekt chwali się, że „przeszedł audyt Zellic”. Warto wiedzieć, co to naprawdę oznacza.
Czym jest audyt smart kontraktów
Audyt to przegląd kodu przez zewnętrznych specjalistów w poszukiwaniu błędów, które mogą doprowadzić do utraty środków: błędów logiki, złego zarządzania uprawnieniami, podatności na manipulację wyrocznią cenową, ataków typu reentrancy czy problemów z matematyką. Audytor sprawdza konkretną wersję kodu w określonym czasie i opisuje znalezione problemy w raporcie. Nie gwarantuje, że błędów nie ma – stwierdza, co znalazł w tym zakresie i w tym czasie.
W 2024 r. Zellic przejął platformę audytów konkursowych Code4rena, w których wielu niezależnych badaczy przegląda ten sam kod. W maju 2026 r. ogłoszono stopniowe wygaszanie Code4rena, a jej program nagród i społeczność badaczy przejmuje Immunefi. Sam Zellic nadal prowadzi klasyczne audyty.
Jak czytać raport z audytu
| Element raportu | Na co zwrócić uwagę |
|---|---|
| Zakres (scope) | które kontrakty i repozytoria sprawdzono – kod poza zakresem nie był audytowany |
| Commit / wersja | czy wdrożony kontrakt odpowiada audytowanej wersji |
| Czas trwania | kilka dni na duży protokół to mało |
| Znaleziska wg wagi | critical, high, medium, low, informational |
| Status poprawek | fixed (naprawione), acknowledged (przyjęte do wiadomości, ale nie naprawione), disputed |
| Założenia | np. zaufanie do administratora, wyroczni czy multisigu |
Przykład
Załóżmy, że nowy protokół pożyczkowy publikuje raport Zellic: 1 błąd krytyczny, 3 wysokie i 7 średnich – razem 11 znalezisk. W tabeli statusów widzisz, że 9 zostało naprawionych (ok. 82%), a 2 średnie oznaczono jako „acknowledged”. Czytasz opis i okazuje się, że oba dotyczą uprawnień administratora, który może zmienić parametry likwidacji bez opóźnienia czasowego (timelock).
Drugi krok: porównujesz commit z raportu z kodem wdrożonym w sieci. Raport dotyczy wersji sprzed trzech miesięcy, a od tego czasu dodano nowy moduł nagród, którego w zakresie nie było. Wniosek: „audyt Zellic” dotyczy tylko części kodu, a ryzyko administratora zostało świadomie pozostawione. To nie musi dyskwalifikować projektu, ale zmienia ocenę ryzyka i to, ile kapitału jesteś gotów tam wpłacić.
Czego audyt nie załatwia
- Ryzyka ekonomicznego – protokół może działać zgodnie z kodem i nadal tracić pieniądze przy ekstremalnych ruchach cen.
- Ryzyka kluczy administracyjnych i multisigu – kradzież kluczy omija nawet idealny kod.
- Zmian po audycie – każda aktualizacja kontraktu to nowy, nieaudytowany kod.
- Ryzyka integracji – błędy mogą leżeć w zewnętrznych protokołach, z których projekt korzysta.
- Oszustwa zespołu – audyt ocenia kod, nie intencje ludzi.
Najczęstsze błędy
- Traktowanie logo audytora na stronie projektu jako gwarancji bezpieczeństwa.
- Nieczytanie raportu, a zwłaszcza znalezisk oznaczonych jako „acknowledged”.
- Brak sprawdzenia, czy audytowana wersja to ta, która działa w sieci.
- Uznawanie jednego audytu za wystarczający przy dużej, często aktualizowanej bazie kodu.
- Wiara w raport, którego nie ma na stronie audytora ani w jego oficjalnym repozytorium.
Perspektywa tradera
Dla tradera korzystającego z DeFi audyt to jeden z elementów oceny ryzyka kontrahenta, a nie przepustka. Rozsądna praktyka: czytasz podsumowanie raportu i listę nienaprawionych znalezisk, sprawdzasz, kto kontroluje klucze administracyjne i czy działa timelock, a wielkość depozytu dopasowujesz do tego ryzyka. Nowy protokół z jednym świeżym audytem to inna kategoria niż kod działający od lat z kilkoma audytami i programem bug bounty. Rozkładanie kapitału między protokoły ogranicza skutki pojedynczego exploitu.
Najczęstsze pytania
Czy projekt po audycie Zellic jest bezpieczny?
Nie ma takiej gwarancji. Audyt zmniejsza ryzyko błędów w sprawdzonym kodzie, ale nie obejmuje zmian po audycie, ryzyka administratora ani ryzyka ekonomicznego.
Gdzie znaleźć raport z audytu?
Najpewniej w oficjalnym repozytorium lub na stronie audytora oraz w dokumentacji projektu. Raport dostępny wyłącznie jako plik na stronie projektu warto porównać ze źródłem.
Co oznacza status „acknowledged”?
Zespół przyjął znalezisko do wiadomości, ale go nie naprawił – zwykle uznając ryzyko za akceptowalne lub wynikające z założeń projektu. Takie punkty warto przeczytać najdokładniej.
Czym audyt różni się od bug bounty?
Audyt to jednorazowy przegląd w określonym czasie. Bug bounty to stały program nagród dla badaczy, którzy zgłaszają błędy w działającym kodzie. Najlepiej, gdy projekt ma jedno i drugie.
Czy więcej audytów oznacza większe bezpieczeństwo?
Zwykle tak, jeśli dotyczą aktualnego kodu i różnych zespołów. Kilka audytów starej wersji nie mówi wiele o kodzie, który działa dziś.
Tekst ma charakter edukacyjny i nie stanowi rekomendacji inwestycyjnej.
