Wypłaty z Zondacrypto – co naprawdę mówi support giełdy?

Wypłaty z Zondacrypto – co naprawdę mówi support giełdy?

2026-04-10

W wczorajszej publikacji przedstawiliśmy kompleksową analizę sytuacji klientów zondacrypto — od historycznego wzorca kryzysów płynnościowych, przez praktyczny przewodnik dochodzenia roszczeń, po szczegółowy przegląd klauzul abuzywnych w regulaminie giełdy. Artykuł kończył się obserwacją, że klient zondacrypto nie potrzebuje wiedzieć, jak giełda przetwarza wypłaty — potrzebuje wiedzieć, czy giełda ma czym wypłacać.

Od tego momentu minęło dwadzieścia cztery godziny. W tym czasie jeden z naszych klientów otrzymał od supportu zondacrypto odpowiedź, która — czytana przez pryzmat wiedzy o architekturze giełd kryptowalutowych — mówi znacznie więcej, niż jej autorzy zamierzali.

Publicznie prezes Przemysław Kral prezentuje spójną narrację: wypłaty z Zondacrypto są opóźnione z powodu planowego „wdrażania nowych, zaawansowanych systemów bezpieczeństwa i monitoringu transakcji„, rezerwy wynoszą ponad 4 500 BTC, sytuacja jest pod kontrolą. Prywatnie — w emailu do konkretnego klienta czekającego na wypłatę — support zondacrypto opowiada inną historię: o awarii systemu automatycznego zasilania hot walleta, o transakcjach wpadających w status „rejected”, o ręcznym dobieraniu środków „z adresów depozytowych” pod każdą pojedynczą wypłatę.

To nie są dwie wersje tego samego zdarzenia. To dwa opisy dwóch różnych rzeczywistości — i tylko jedna z nich może być prawdziwa.

Poniżej przedstawiamy pełną analizę techniczną: co oznaczają użyte przez support terminy, kim jest „operator” generujący statusy „confirming” i „rejected”, dlaczego sformułowanie o „ręcznym dobieraniu z adresów depozytowych” jest technicznie najbardziej alarmującym elementem całej korespondencji — i co to wszystko oznacza dla klientów, których środki wciąż widnieją na koncie ze statusem „pending”.

 

Co support Zondacrypto napisał klientowi

Przytaczamy pełną treść odpowiedzi supportu zondacrypto, otrzymaną przez naszego klienta w dniu 9 kwietnia 2026 r.:

„Wstrzymanie realizacji wypłaty wynika z ogólnego problemu technicznego związanego z funkcjonowaniem systemu obsługującego wypłaty, w szczególności w obszarze automatycznego zasilania portfela operacyjnego (HOT wallet). Problem dotyczy automatycznego dobierania wartości z portfela HOT per dany asset — otrzymujemy błędną odpowiedź przy wypłatach. Wpadają one u operatora w status «confirming» lub «rejected» ze względu na błędnie dobrane środki, na koncie za to widnieje jako «pending».

Środki dobierane są ręcznie przez nasz Dział Techniczny z adresów depozytowych na hot pod konkretną wypłatę środków. W związku z tym część transakcji, w tym Pana wypłata, wymaga obecnie ręcznego procesowania.

Wypłata nie została anulowana i pozostaje aktywna w systemie, a Pana środki są bezpieczne i pozostają pod pełną kontrolą. Poinformujemy Pana w osobnej wiadomości, kiedy wypłata zostanie zrealizowana.”

Na pierwszy rzut oka — techniczna, spokojna odpowiedź działu wsparcia. Ale każde zdanie w tej wiadomości, dekodowane w kontekście tego, jak faktycznie działają giełdy kryptowalutowe, opowiada historię zasadniczo odmienną od tej, którą prezes Kral przedstawił publicznie.

 

Dwie narracje jednej giełdy – support kontra oświadczenie publiczne

Przyczyna opóźnień wypłat z Zondacrypto — planowy upgrade czy awaria systemu?

Publicznie zondacrypto komunikuje: „Wdrażanie nowych systemów bezpieczeństwa wymusiło wprowadzenie procedury manualnej weryfikacji części wypłat.” Narracja brzmi: wdrażamy upgrade, to planowa niedogodność.

Support prywatnie opisuje coś zupełnie innego: „Ogólny problem techniczny związany z funkcjonowaniem systemu obsługującego wypłaty, w szczególności w obszarze automatycznego zasilania portfela operacyjnego (HOT wallet). Otrzymujemy błędną odpowiedź przy wypłatach. Wpadają one u operatora w status «confirming» lub «rejected» ze względu na błędnie dobrane środki.”

To nie jest ten sam opis. Publiczne oświadczenie sugeruje proaktywne wdrożenie nowego systemu bezpieczeństwa – decyzję biznesową, kontrolowaną i zamierzoną. Email supportu opisuje awarię istniejącego systemu — błędne odpowiedzi, transakcje wpadające w status „rejected”, konieczność ręcznego dobierania środków „pod konkretną wypłatę.”

Jedno brzmi jak remont kuchni, drugie – jak pęknięta rura.

 

Hot wallet zondacrypto – zamierzona architektura czy pustka?

Publicznie problem jest przedstawiany jako kwestia percepcji – media badały tylko hot wallety, a większość środków jest w cold walletach. Implikacja: hot wallet jest celowo utrzymywany na niskim poziomie, bo tak deklaruje sama giełda na stronie o bezpieczeństwie środków.

Support prywatnie: hot wallet nie jest zasilany automatycznie, środki są dobierane ręcznie „z adresów depozytowych na hot pod konkretną wypłatę.” To opis systemu, w którym hot wallet jest de facto pusty i zasilany ad hoc – nie z wyboru architektonicznego, lecz dlatego, że mechanizm automatyczny nie działa.

Te dwa opisy są wzajemnie sprzeczne. Jeśli niski stan hot walleta to zamierzony element architektury bezpieczeństwa (wersja publiczna), to nie powinien generować błędów systemowych (wersja support). Jeśli generuje błędy, to nie jest zamierzony — jest awaryjny.

Dane analizy Recoveris, opublikowanej przez money.pl i Wirtualną Polskę, potwierdzają skalę problemu: średni miesięczny stan BTC na hot walletach zondacrypto spadł z ok. 55,7 BTC w sierpniu 2024 r. do zaledwie 0,18 BTC w marcu 2026 r. — spadek o 99,7%. Na dzień 1 kwietnia 2026 r. saldo wynosiło 0,086 BTC, czyli równowartość ok. 21 000 PLN. W marcu saldo ani razu nie przekroczyło jednego bitcoina. Dane te potwierdziły niezależnie Polskie Radio, Bankier.pl i Business Insider Polska.

 

Transfer 76 mln PLN – wyjaśnienie dla mediów, cisza dla klienta

Publicznie: „Odnotowane transfery to standardowe operacje związane z zarządzaniem płynnością oraz realizacją zleceń klientów instytucjonalnych.” Jak ustalili analitycy Recoveris, w ciągu niespełna czterech miesięcy — od 18 grudnia 2025 r. do 2 kwietnia 2026 r. — za pomocą 511 przelewów wytransferowano z zondacrypto aktywa o wartości ponad 21 mln USD (ok. 76 mln PLN) na pojedynczy adres depozytowy giełdy Kraken. Fakt ten potwierdziła Rzeczpospolita.

Support: cisza. Ani słowa. Klient indywidualny nie dostaje żadnego wyjaśnienia, dlaczego 76 mln PLN opuściło platformę, podczas gdy jego wypłata czeka na ręczne procesowanie.

To pominięcie jest samo w sobie informacją. „Zarządzanie płynnością” w kontekście giełdy, która nie może automatycznie zasilić własnego hot walleta, brzmi jak eufemizm, którego support wolał nie powtarzać w korespondencji jeden-na-jeden.

 

Rezerwy 4 500 BTC – dlaczego support nie powołuje się na deklarację prezesa?

Publicznie prezes Kral — w oświadczeniu przesłanym mediom — deklaruje ponad 4 500 BTC i „ponad 100-procentowe pokrycie wszystkich zobowiązań wobec użytkowników.” Szerzej komentując sytuację, zapewnił, że „środki nigdy nie były zablokowane z powodu ich fizycznego braku.”

Support: „Pana środki są bezpieczne i pozostają pod pełną kontrolą” — ale bez jednej liczby, bez odniesienia do rezerw, bez powołania się na deklarację prezesa. Support powtarza zapewnienie, ale nie powołuje się na jego podstawę faktyczną.

To sugeruje jedno z dwóch: albo support nie został wyposażony w materiały pozwalające powoływać się na konkretne dane (co wskazuje na słabą koordynację kryzysową), albo — co bardziej niepokojące — osoby na pierwszej linii kontaktu z klientem nie mają pewności co do danych, które prezes podaje publicznie.

Jest jeszcze trzecia rozbieżność dotycząca terminów. Publicznie prezes Kral zapowiedział powrót do normalnych wypłat do 12 kwietnia i przywrócenie standardowego czasu realizacji do 48 godzin „w ciągu najbliższych sześciu dni”. Support napisał klientowi: „Poinformujemy Pana w osobnej wiadomości, kiedy wypłata zostanie zrealizowana.” Brak terminu. Brak odniesienia do deklaracji prezesa. Klient dostaje obietnicę przyszłej wiadomości — nie datę. Facebook zondacrypto z 8 kwietnia informował o codziennych aktualizacjach realizowanych wypłat, przepraszając za ręczne przetwarzanie — ale również nie podając daty przywrócenia automatycznych wypłat. Fintek.pl odnotował, że „początkowo deklarowano termin 12 kwietnia, jednak go nie podtrzymano.”

Jeśli support nie powołuje się na termin podany przez CEO, to albo nie wierzy w jego realność, albo nie został o nim poinformowany. Oba warianty są niepokojące.

 

Kim jest „operator” -i dlaczego to pytanie zmienia wszystko

Zondacrypto jest giełdą, ale współczesne giełdy kryptowalutowe z reguły nie zarządzają infrastrukturą portfelową samodzielnie. Korzystają z zewnętrznych dostawców infrastruktury custodialnej — platform takich jak Fireblocks, BitGo, Copper.co czy Anchorage. Te platformy świadczą usługę MPC wallet management: generują adresy, zarządzają kluczami prywatnymi w architekturze multi-party computation, konstruują transakcje, podpisują je i broadcastują do sieci blockchain.

Statusy „confirming” i „rejected” nie są statusami sieci Bitcoin ani Ethereum. Sieć Bitcoin nie zwraca statusu „rejected” — transakcja albo trafia do mempoola i zostaje potwierdzona, albo jest odrzucona przez node i nigdy nie istnieje. „Confirming” i „rejected” to statusy wewnętrznego lifecycle’u transakcji w platformie custodialnej. Fireblocks na przykład operuje cyklem: SUBMITTED → QUEUED → PENDING_AUTHORIZATION → BROADCASTING → CONFIRMING → COMPLETED/FAILED/REJECTED. Status REJECTED w Fireblocks może wynikać m.in. z polityk AML lub niewystarczających środków. BitGo ma analogiczny pipeline.

To znaczy, że „operator” w emailu supportu to niemal na pewno zewnętrzny dostawca infrastruktury portfelowej. Zondacrypto nie mówi o sieci blockchain — mówi o swoim custody providerze.

Zastrzeżenie metodologiczne: Zondacrypto nigdy nie ujawniła publicznie, jakiego dostawcy infrastruktury custodialnej używa. Identyfikacja „operatora” jako zewnętrznego custody providera jest interpretacją technicznie uzasadnioną — statusy „confirming” i „rejected” odpowiadają terminologii platform custodialnych, nie sieci blockchain — ale pozostaje hipotezą. Słowo „operator” w korespondencji supportu mogłoby teoretycznie odnosić się również do wewnętrznego systemu giełdy. Spójność tej hipotezy z dostępnymi danymi jest jednak wysoka.

 

Co technicznie oznacza „błędnie dobrane środki”

W przypadku Bitcoina kluczowe jest zrozumienie modelu UTXO (Unspent Transaction Output). Bitcoin nie operuje „saldem” — operuje zestawem niespożytkowanych wyjść transakcyjnych. Żeby wysłać 1 BTC, system musi wybrać jeden lub więcej UTXO, których suma pokrywa kwotę transakcji plus opłatę sieciową. To jest właśnie „dobieranie środków” — UTXO selection.

„Błędna odpowiedź przy wypłatach” i „błędnie dobrane środki” oznaczają, że custody provider próbuje skonstruować transakcję, ale UTXO selection kończy się niepowodzeniem. Dzieje się tak w trzech przypadkach: UTXO są niewystarczające (hot wallet nie ma czym zapłacić), UTXO są już zarezerwowane pod inną transakcję w toku (race condition przy wielu równoległych wypłatach z prawie pustego portfela), albo UTXO są dust — tak małe, że opłata sieciowa za ich spożytkowanie przewyższa ich wartość.

Przy hot wallecie na poziomie 0,086 BTC — jak wykazała analiza Recoveris — wszystkie trzy scenariusze występują jednocześnie. Portfel z ułamkiem BTC, z którego obsługuje się setki lub tysiące żądań wypłat, będzie generował dokładnie te błędy: custody provider próbuje dobrać UTXO, nie znajduje wystarczających, transakcja wpada w „rejected.” Przy ledwie wystarczających — wpada w „confirming” i wisi, bo opłata sieciowa jest za niska przy tak małych UTXO.

Innymi słowy: „problem techniczny z automatycznym zasilaniem” to technicznie poprawny opis sytuacji, w której hot wallet jest pusty. To jak powiedzieć, że samochód ma „problem z systemem paliwowym” – technicznie prawdziwe, gdy w baku nie ma benzyny.

A jeśli hot wallet jest pusty, dlaczego transakcja nie jest po prostu odrzucana z komunikatem „insufficient funds”? Bo custody providerzy — Fireblocks, BitGo — operują z buforem retry i kolejkowaniem. Transakcja jest submitted, system próbuje skonstruować ją z dostępnych UTXO, nie może, wpada w „pending” lub „confirming” z niskim priority fee, czeka na dostępność środków. W międzyczasie na dashboardzie klienta giełdy widnieje „pending.”

To nie jest bug — to feature custody platformy zaprojektowany na sytuacje, w których hot wallet jest chwilowo niedofinansowany i zostanie zasilony w ciągu minut.

Problem pojawia się, gdy „chwilowo” trwa tygodniami.

 

„Z adresów depozytowych na hot” — najważniejsze zdanie w całym emailu

Sformułowanie „środki dobierane są ręcznie przez nasz Dział Techniczny z adresów depozytowych na hot pod konkretną wypłatę” jest technicznie najbardziej alarmującym elementem całej korespondencji.

W standardowej architekturze giełdy przepływ wygląda tak: klient deponuje BTC na indywidualny adres depozytowy → giełda periodycznie sweepuje depozyty do skonsolidowanego cold walleta → cold wallet zasila hot wallet automatycznie, gdy saldo hot walleta spada poniżej progu → hot wallet realizuje wypłaty. To trzy odrębne warstwy, zaprojektowane tak, by żadna pojedyncza awaria nie zatrzymała całego pipeline’u.

Email supportu opisuje architekturę, w której środkowa warstwa — skonsolidowany cold wallet — albo nie istnieje, albo jest pusta. Zamiast przelewać z cold walleta na hot, dział techniczny ręcznie zbiera środki z indywidualnych adresów depozytowych klientów. To jakby bank, zamiast wypłacać z kasy, chodził do sejfów innych klientów i przekładał ich banknoty do okienka.

Tymczasem oficjalna strona zondacrypto o bezpieczeństwie środków deklaruje, że „wszystkie środki w kryptowalutach są przetrzymywane na tak zwanych zimnych portfelach (cold wallets).” Opis supportu jest z tą deklaracją sprzeczny.

To ma trzy implikacje.

Po pierwsze, cold wallet — ten, w którym prezes Kral deklaruje 4 500 BTC — albo nie istnieje jako skonsolidowany portfel, albo nie może być użyty do zasilenia hot walleta. Przyczyn może być kilka: jest obciążony zobowiązaniami, zamrożony, klucze są niedostępne — lub po prostu nie zawiera deklarowanej kwoty. Niezależnie od przyczyny: gdyby cold wallet z 4 500 BTC był operacyjnie dostępny, żaden dział techniczny nie zbierałby ręcznie okruchów z adresów depozytowych.

Po drugie, giełda operuje w trybie peer-to-peer wewnętrznie: wypłata klienta A jest finansowana bezpośrednio z depozytu klienta B. To nie jest „zarządzanie płynnością” — to opis systemu, w którym rezerwa zagregowana nie istnieje.

Po trzecie, ręczne procesowanie „pod konkretną wypłatę” oznacza, że każda wypłata wymaga indywidualnej decyzji — kto dostaje środki, z czyjego depozytu, w jakiej kolejności. To jest triage, nie operacja techniczna.

 

Proof of Reserves – jedno kliknięcie, które kończy kryzys

Istnieją dwa scenariusze wyjaśniające opisaną sytuację.

Scenariusz A — łagodny: rzeczywisty problem z oprogramowaniem obsługującym hot wallet. Cold wallety istnieją i są zasilone. Ręczne procesowanie jest tymczasowym obejściem. W tym scenariuszu wyjaśnienie supportu jest prawdziwe, ale rodzi pytanie: dlaczego po tygodniach problemu nie ma nawet przybliżonego terminu naprawy?

Scenariusz B — poważny: hot wallet jest pusty, bo cold wallety są niewystarczająco zasilone lub obciążone zobowiązaniami, których giełda nie ujawnia. „Ręczne procesowanie” oznacza w praktyce selekcję — kto dostaje wypłatę, a kto czeka. To klasyczny triage płynnościowy, znany z każdego kryzysu opisanego w naszej wczorajszej analizie — od Voyager Digital po FTX.

Co odróżnia scenariusz A od B? Jedno: Proof of Reserves. Kryptograficzny dowód posiadania deklarowanych aktywów, możliwy do opublikowania w ciągu godzin, weryfikowalny przez każdego uczestnika rynku. Gdyby scenariusz A był prawdziwy, publikacja PoR byłaby oczywistym ruchem — natychmiast zakończyłaby kryzys zaufania, uciszyła media i uspokoiła klientów. Koszt: zerowy. Zysk: nieograniczony.

Prezes Kral odmówił publikacji Proof of Reserves, argumentując zamiast tego, że „prawdziwym dowodem są audyty i compliance z regulatorami rynku kapitałowego.”

W branży kryptowalutowej odmowa PoR w momencie kryzysu zaufania ma status diagnostyczny porównywalny z odmową badania krwi u pacjenta, który zapewnia, że jest zdrowy. Może faktycznie jest zdrowy i po prostu nie lubi igieł. Ale lekarz — i rynek — wyciągają wnioski nie z tego, co pacjent mówi, lecz z tego, czego odmawia.

 

Kontekst instytucjonalny: prokuratura, UOKiK i luka regulacyjna

8 kwietnia 2026 r., z inicjatywy Prokuratora Generalnego Waldemara Żurka, Prokuratura Krajowa ogłosiła wszczęcie postępowania sprawdzającego dotyczącego nieprawidłowości w funkcjonowaniu zondacrypto. Postępowanie — prowadzone w ramach szerszego śledztwa dotyczącego zaginięcia Sylwestra Suszka, założyciela poprzedniczki giełdy — potwierdził RMF24, money.pl i Fakt.

UOKiK prowadzi własne postępowanie wyjaśniające wobec BB Trade Estonia OÜ od 31 stycznia 2025 r. Do dnia 6 kwietnia 2026 r. Urząd otrzymał dziewięć skarg na zondacrypto, z czego cztery wpłynęły w 2026 r.

Zondacrypto — formalnie estońska spółka BB Trade Estonia OÜ (nr rej. 14814864), kontrolowana przez szwajcarską Divisio Holding AG z Zug — działa na estońskiej licencji VASP (nr FVT000209), która wygasa 1 lipca 2026 r. KNF nie sprawuje i nie sprawowała bezpośredniego nadzoru nad giełdą. Jak szczegółowo analizuje Business Insider Polska, nawet dwukrotnie zawetowana przez Prezydenta Nawrockiego ustawa implementująca MiCA nie zmieniłaby tej sytuacji — zondacrypto nadal podlegałoby nadzorowi estońskiemu, a polscy klienci pozostają bez ochrony krajowego organu nadzoru finansowego.

 

Co to oznacza dla klientów zondacrypto

Email supportu, czytany przez osobę ze znajomością architektury custody, nie opisuje awarii oprogramowania. Opisuje giełdę, której hot wallet jest pusty, której zautomatyzowany pipeline cold→hot nie działa (lub nie ma czego przelewać), i która ręcznie zbiera BTC z rozproszonych adresów depozytowych klientów, żeby sfinansować poszczególne wypłaty — po jednej na raz — przez platformę custodialną, która odpowiada błędami UTXO selection na każdą próbę automatycznego przetworzenia.

Każdy element tego opisu jest spójny z danymi Recoveris (0,086 BTC na hot wallecie) i sprzeczny z narracją publiczną o 4 500 BTC w cold storage, które „zapewniają ponad 100-procentowe pokrycie.” Jeśli te 4 500 BTC istnieje — dlaczego dział techniczny zbiera okruchy z adresów depozytowych, zamiast przelać z cold walleta?

To pytanie, na które email supportu nie odpowiada. I to jest odpowiedź.

Klienci, których wypłaty z zondacrypto pozostają ze statusem „pending”, nie powinni czekać na kolejną wiadomość od supportu. Praktyczny przewodnik dochodzenia roszczeń — reklamacja, skarga do UOKiK, zawiadomienie do prokuratury, pozew z wnioskiem o zabezpieczenie — opisaliśmy szczegółowo wczoraj. Konsumenci mogą pozywać zondacrypto przed polskim sądem i pod polskim prawem, niezależnie od klauzuli jurysdykcyjnej wskazującej prawo estońskie. Każdy z tych kroków jest zasadny już teraz, dopóki istnieje podmiot, wobec którego można je egzekwować.

 

Robert Nogacki — radca prawny (WA-9026), założyciel Kancelarii Prawnej Skarbiec