ZK‑KYC w DeFi: pułapka pozornego spełnienia eIDAS 2.0

Kolejna pułapka to UX. Jeśli weryfikacja wymaga instalacji dodatkowego oprogramowania, ręcznego kopiowania dowodów i czekania na potwierdzenia, użytkownicy odpłyną. Rozwiązanie: weryfikacja powinna być jednorazowa i trwała dla danej sesji lub adresu, z możliwością odświeżenia. Nie zmuszaj do ponownego przechodzenia procesu przy każdej transakcji. Zamiast tego wystawiaj token dostępu o ograniczonym czasie życia, powiązany z kontekstem.

Przewagę zdobędzie ten, kto usunie tarcie, ale nie odda kontroli nad kosztami. Abstrakcja konta działa najlepiej, gdy portfel i giełda traktują ją jak warstwę infrastruktury, a nie pojedynczą funkcję. Wtedy transakcja bez gazu staje się normalnym elementem obsługi, a nie eksperymentem, który kończy się pustym saldem sponsora.

Mechanika jest prosta tylko na pierwszy rzut oka. Użytkownik buduje UserOperation, podpisuje ją kluczem konta, a bundler pakuje kilka takich operacji i wysyła do EntryPoint. Paymaster najpierw weryfikuje, czy pokryje koszt, potem opłaca gaz, a rozliczenie następuje po wykonaniu. Portfel musi więc obsłużyć symulację, szacowanie i podpisywanie dodatkowych danych. Typowy błąd to założenie, że wystarczy dodać obsługę paymastera do wysyłki. Bez poprawnej walidacji podpisu i nonce’a operacja przepada, a użytkownik widzi tylko zawieszone „oczekiwanie".

Praktyczna implementacja wygląda tak: użytkownik generuje dowód ZK, że posiada ważne poświadczenie od zaufanego wystawcy. Twój kontrakt weryfikuje dowód on‑chain lub w warstwie off‑chain, a następnie zapisuje wyłącznie znacznik „zweryfikowany". Nie zapisujesz daty urodzenia, numeru dokumentu ani adresu. Uważaj na typowy błąd: przechowywanie surowych danych w logach lub w bazie po stronie backendu. To nie tylko psuje prywatność, ale też zwiększa ryzyko wycieku i zakres audytu.

Mechanizm jest prosty do wyobrażenia. Formułujesz intencję: chcę wymienić token A na token B, nie mniej niż X, w ciągu Y sekund, maksymalny poślizg Z procent. Ta intencja trafia do aukcji, a solverzy proponują realizację. Najlepsza oferta wygrywa, ale nie jest to oferta „dla Ciebie" w sensie charytatywnym — to oferta, która pozostawia solverowi jak najwięcej. Kluczowe jest to, że konkurują między sobą, więc w teorii spread jest mniejszy. W praktyce zależy to od tego, jak dobrze Twoje ograniczenia są dobrane.

Giełdy mają tu inny problem niż portfele. Wypłata na adres konta inteligentnego wymaga sprawdzenia, czy kontrakt jest już wdrożony, czy trzeba użyć initCode i czy podpis przejdzie w EntryPoint. Częsty błąd to wysyłanie środków na adres bez wdrożonego konta i bez danych inicjalizujących. Drugi to brak obsługi wycofania operacji, gdy paymaster odmówi. Operacje trzeba kolejkować, śledzić i mieć plan B: awaryjną ścieżkę z klasyczną transakcją, gdy sponsorowanie zawiedzie.

Nie ma tu darmowego obiadu. Intenty i RFQ przenoszą koszty z jawnych opłat na ukryty spread i ryzyko egzekucji. Gdy to zrozumiesz, przestaniesz patrzeć tylko na cenę wyświetlaną na ekranie, a zaczniesz pilnować warunków, które sam narzucasz. To one decydują, czy solver zarobi na Tobie, czy dla Ciebie.

Praktycznie: przed każdą większą wymianą porównaj kilka kanałów realizacji, w tym klasyczny swap w puli i aukcję intencji. Sprawdź, jaka jest różnica w kwocie wyjściowej przy tych samych ograniczeniach. Ustawiaj poślizg na podstawie obserwacji, nie przyzwyczajenia. Jeśli transakcja jest duża, rozbij ją na mniejsze części, bo pojedyncza intencja przyciąga uwagę solverów nastawionych na maksymalny zysk. I czytaj, kto jest kontrahentem — w aukcji nie widzisz drugiej strony, więc polegasz na reputacji i zabezpieczeniach protokołu.

Gdzie realnie tracisz: poślizg, MEV i ukryty spread Poślizg cenowy w DEX-ie to nie tylko efekt głębokości puli. W modelu intencji to raczej parametr akceptacji, który sam ustawiasz. Zbyt luźny poślizg to zaproszenie do wysysania wartości — solver może zrealizować transakcję tuż za progiem Twojej tolerancji, a różnicę zatrzymać. Zbyt ciasny poślizg sprawia, że oferty są gorsze albo ich brak, bo solver nie chce ryzykować. Typowy błąd to kopiowanie ustawień z poradników bez sprawdzenia, jak zachowuje się płynność w Twojej parze w danych godzinach.

Praktyczne wdrożenie warto zacząć od jednego scenariusza, na przykład pierwszej transakcji nowego użytkownika. Zbieraj metryki: ile operacji kończy się sukcesem, ile odrzuca paymaster, ile wpada w błąd walidacji. Ustaw limity per adres i per operacja. Testuj na sieci testowej z tym samym bundlerem, którego użyjesz na produkcji. Pamiętaj, że paymaster to zobowiązanie finansowe. Jeśli nie potrafisz szybko wyłączyć sponsorowania, lepiej go nie włączaj.

ERC-4337 zmienia sposób, w jaki portfel podpisuje i wysyła transakcje, bo wprowadza warstwę abstrakcji konta bez modyfikacji samego protokołu. Zamiast klasycznego adresu z kluczem prywatnym działa kontrakt konta (smart account), a użytkownik podpisuje intencję, którą do sieci wnosi bundler. W tym modelu płatność za gaz może przejąć paymaster, czyli kontrakt sponsorujący. Dla portfeli i giełd na L2 to nie ciekawostka techniczna, tylko sposób na usunięcie największego tarcia przy pierwszym wejściu.