Klasyczny model DEX opiera się na zleceniach: użytkownik składa transakcję, która trafia do mempoolu, a walidator lub searcher decyduje, w jakiej kolejności ją wykonać. Ta kolejność to pole do nadużyć — frontrunning, backrunning, sandwich. Intenty odwracają logikę: zamiast mówić „wykonaj tę transakcję", mówisz „chcę osiągnąć ten efekt". Reszta należy do solverów.<br>
<br>
<br>
<br>
Najczęstsze błędy to pomijanie entropii przy generowaniu kluczy, brak ochrony przed atakami replay oraz zaufanie wyłącznie danym z jednego źródła. Drugi typowy problem to nullifier powiązany z adresem IP zamiast z kluczem urządzenia — wtedy zmiana sieci pozwala odebrać airdrop dwa razy. Trzeci błąd to brak testów na urządzeniach ze zmanipulowanym systemem; jeśli użytkownik może wstrzyknąć fałszywe współrzędne, cały mechanizm traci sens.<br>
<br>
<br>
<br>
Mechanika jest prostsza, niż brzmi. Telefon zbiera próbki z odbiornika GNSS, ewentualnie wspiera się siecią Wi-Fi i Bluetooth, i zapisuje je lokalnie. Z tych próbek powstaje świadek (witness) dla obwodu, który sprawdza trzy rzeczy: odległość od zadeklarowanego punktu, czas przebywania w promieniu oraz spójność danych w oknie czasowym. Jeśli warunki są spełnione, obwód generuje dowód. Dowód trafia do kontraktu razem z hashem nullifiera, który blokuje drugie odebranie z tego samego urządzenia.<br>
<br>
<br>
<br>
Oto co warto zrobić przed pierwszym użyciem. Po pierwsze, sprawdź, czy portfel obsługuje konta abstrakcyjne lub podobny mechanizm — bez tego paymaster nie zadziała. Po drugie, przetestuj na małej transakcji, zanim powierzysz większe środki. Po trzecie, zapisz, jakie uprawnienia przyznałeś, i w razie potrzeby je odwołaj. Po czwarte, nie zakładaj, że sponsor jest anonimowy i bezpieczny — sprawdź, czy projekt ma publiczny kontrakt i czy ktokolwiek go weryfikował.<br>
<br>
<br>
<br>
Utrzymuj spójny model zagrożeń. Rozdziel role: jeden zestaw kluczy na łańcuchy UTXO, drugi na EVM, trzeci na konta wymagające codziennego dostępu. Trzymaj osobne urządzenia podpisujące dla dużych i małych kwot. Testuj procedurę na małych transakcjach przed każdą zmianą firmware’u czy oprogramowania. Sprawdzaj, czy odbiorca na urządzeniu online nie zamienia bajtów w adresie — porównuj co najmniej początek i koniec adresu na dwóch ekranach. Typowe pułapki: współdzielenie seeda między sieciami, brak weryfikacji domeny EIP-712, aktualizacje przez sieć, kopiowanie PSBT przez schowek i brak kontroli sum kontrolnych.<br>
<br>
<br>
<br>
Typowe błędy, które psują cały mechanizm: brak zdarzenia zwrotu, brak możliwości korekty stawki po zmianie przepisów, zapisanie adresu depozytu na sztywno w tokenie oraz pominięcie kursu wymiany, gdy stablecoin nie jest w złotych. Kurs trzeba zamrażać w momencie transakcji i przechowywać w zdarzeniu, inaczej po miesiącu kwota podatku przestaje się zgadzać z deklaracją. Kolejna pułapka to brak audytu — urząd skarbowy może zażądać pełnej historii escrow dla każdej faktury, więc zdarzenia muszą być indeksowane i możliwe do wyeksportowania.<br>
<br>
<br>
<br>
Ochrona przed MEV bierze się stąd, że nie ma publicznego mempoolu z twoją intencją w formie gotowej do wykorzystania. Searcher nie widzi twojego zlecenia, widzi jedynie warunek wyniku. Nie może cię wyprzedzić, bo nie ma czego wyprzedzać — nie ma transakcji, którą mógłby przestawić w kolejności. To nie znaczy, że MEV znika całkowicie: solverzy nadal konkurują o kolejność własnych transakcji, ale rywalizacja przenosi się na poziom rozliczenia, a nie na poziom twojej straty.<br>
<br>
<br>
<br>
Jak to wdrożyć bez wycieku danych i bez fałszywek Zacznij od ustalenia promienia i minimalnego czasu obecności. Zbyt duży promień zaprasza osoby z okolicy, zbyt mały — wyklucza uczciwych uczestników stojących przy ścianie budynku. Przyjmij, że w mieście typowy błąd pozycjonowania to kilkanaście metrów, więc promień mniejszy niż pięćdziesiąt metrów bez wsparcia zewnętrznego jest ryzykowny. Okno czasowe ustaw na kilka minut, nie na kilka sekund, bo pojedynczy odczyt łatwo podrobić.<br>
<br>
<br>
<br>
Jak zbudować poprawny escrow bez wchodzenia w konflikt z prawem Zacznij od rozdzielenia ról. Token powinien mieć trzy adresy: odbiorcy, sprzedawcy i depozytu VAT. Kwota netto i kwota podatku są wyliczane poza łańcuchem, a do kontraktu trafiają już jako osobne pola. Warto dodać warunek, że escrow można zwolnić tylko po potwierdzeniu dostawy — inaczej przy zwrotach pieniądze wracają razem z VAT-em, a to wymaga korekty faktury. Drugi warunek: jeśli nabywca jest podatnikiem z innego kraju UE, stawka może być zerowa, więc kontrakt musi obsłużyć wiele stawek, a nie jedną sztywną.<br>
<br>
<br>
<br>
Pierwszy typowy błąd to zbyt sztywne warunki. Jeśli ustawisz minimalną kwotę wyjściową zbyt wysoko, solverzy odpuszczą, a intent przepadnie — mimo że rynek oferował cenę tylko minimalnie gorszą. Drugi błąd to brak limitu czasu. Intent bez deadline'u może zostać wypełniony w momencie, gdy warunki rynkowe całkowicie się zmieniły, i skończysz z aktywem, którego wcale nie chciałeś trzymać. Trzeci błąd to ślepe zaufanie do jednego solvera. Konkurencja między solverami to cały mechanizm ochronny — jeśli twoje intenty trafiają tylko do jednego podmiotu, wracasz do punktu wyjścia.
