Ataki sandwich na Solanie osiągnęły rozmiary epidemii — w ciągu trzech lat odnotowano 28 milionów takich przypadków. Jednak traderzy korzystający z Jupiter Ultra wydają się padać ich ofiarą znacznie rzadziej, według pierwszego wieloletniego badania akademickiego ataków na chroniony przepływ zleceń w największych łańcuchach bloków.

Badanie pt. „No Place to Hide: An Analysis on Protected Order Flow Sandwich Attacks” zostało opublikowane na arXiv 23 września 2026 r. Zostało przeprowadzone przez badaczy z Category Labs, ETH Zurych, Flashbots oraz Uniwersytetu Lizbońskiego i objęło analizę aktywności ataków sandwich na Ethereum, Solanie, Tron, Base, Arbitrum i Monad. Wyniki wskazują, że decyzje projektowe na poziomie aplikacji mają ogromne znaczenie dla tego, jak często użytkownicy są wykorzystywani. „Chroniony przepływ zleceń” w tytule odnosi się do ruchu swapowego przesyłanego kanałami prywatnymi, a nie widocznego publicznie — tej samej zasady projektowej, która utrzymuje szczegóły transakcji w ukryciu momentu jej wykonania.

Jak działają ataki sandwich

W ataku sandwich bot wykrywa oczekującą transakcję swap, składa zamówienie kupna bezpośrednio przed nią, aby podnieść cenę, a następnie sprzedaje zaraz po wykonaniu transakcji ofiary po zawyżonej cenie. Trader otrzymuje gorsze warunki wykonania, a bot zatrzymuje różnicę. Ponieważ koszt ujawnia się jako gorsza cena, a nie jawna opłata, łatwo go przeoczyć przy pojedynczym swapie, mimo że sumuje się on na przestrzeni milionów ataków odnotowanych w okresie badania.

Architektura Solany czyni sieć szczególnie żyznym gruntem dla tego typu wykorzystania. Niskie opłaty transakcyjne pozwalają botom tanio i na masową skalę podejmować próby ataków sandwich, a widoczność mempool dostarcza im informacji potrzebnych do wyprzedzania transakcji.

Wyniki Jupiter Ultra na tle konkurencji

Badanie wykorzystało wskaźnik zwany „excess ratio”, aby zmierzyć, jak często użytkownicy poszczególnych aplikacji padali ofiarą ataków sandwich względem wartości bazowej. Jupiter Ultra odnotował ogółem wskaźnik 0,7, co oznacza, że jego użytkownicy byli faktycznie atakowani rzadziej, niż przewidywałyby oczekiwania statystyczne. W scenariuszach z pojedynczą ofiarą wskaźnik wzrósł do 2,0 — nadal znacznie poniżej konkurencji.

Kontrast z innymi terminalami handlowymi na Solanie jest ewidentny. Axiom uzyskał wskaźnik 18,9, Photon 11,1, a zarówno BullX, jak i GMGN również przekroczyły poziom 10 — wartości wskazujące na częstotliwość ataków znacznie wyższą niż oczekiwana dla użytkowników.

Jupiter przypisuje tę przewagę wersji Ultra V3, uruchomionej 17 października 2025 r., która wprowadziła szereg funkcji ochronnych. Prywatny routing ukrywa szczegóły transakcji do momentu jej wykonania, odcinając przewagę informacyjną, na której opierają się boty sandwich. Dynamiczne szacowanie poślizgu dostosowuje poziomy tolerancji w czasie rzeczywistym, zamiast polegać na statycznych parametrach ustawianych przez użytkownika. Platforma włączyła także tzw. „Iris meta-aggregation” oraz „Ultra Signaling”, aby dalej poprawić prywatność transakcji i jakość ich wykonania.

Deklarowane wyniki są ambitne: ochrona przed atakami sandwich 34 razy skuteczniejsza niż u konkurentów, średni dodatni poślizg +0,6 punktu bazowego oraz opłaty za wykonanie 8–10 razy niższe niż na konkurencyjnych platformach.

Architektura ma większe znaczenie niż łańcuch

Do bardziej godnych uwagi wniosków badania należy teza, że sam łańcuch bazowy nie jest jedyną zmienną. Decyzje na poziomie aplikacji — jak platforma handlowa kieruje zlecenia, co ujawnia w publicznym mempool i jak obsługuje poślizg — odgrywają decydującą rolę w określaniu tego, którzy użytkownicy są atakowani i jak często. Dla traderów oznacza to, że terminal, przez który kierują swap, jest sam w sobie mierzalnym czynnikiem ryzyka wykonania.

Badacze podkreślili jednak, że ataki sandwich na Solanie nie zostały wyeliminowane. Walidatorzy wciąż stanowią wektor ekspozycji, a Jupiter Ultra ogranicza problem, choć go nie rozwiązuje. Wskaźniki excess ratio dają teraz branży wspólną miarę do porównywania ochrony na poziomie platform — punkt odniesienia pokazujący, jak szeroka jest obecna luka między aplikacjami i jaka część powierzchni ataku pozostaje poza kontrolą jakiejkolwiek pojedynczej platformy.