ZK‑KYC pod MiCA: jak DEX-y w UE mogą spełnić wymogi bez utraty prywatności

Czy zdecentralizowane giełdy (DEX) w Europie muszą wprowadzić KYC? Po wejściu w życie MiCA dla stablecoinów (2024) i pozostałych usług krypto (2024/2025) oraz unijnego Transfer of Funds Regulation (TFR), napięcie między wymogami AML a anonimowością on-chain rośnie. Rozwiązaniem, o którym w polskim internecie mówi się wciąż za mało, jest ZK‑KYC – weryfikacja użytkownika z wykorzystaniem zerowej wiedzy (zero‑knowledge), która pozwala udowodnić zgodność bez ujawniania danych.

Dlaczego ZK‑KYC teraz?

• MiCA porządkuje rynek CASP (Crypto‑Asset Service Providers), a DEX-y i interfejsy front‑end w UE będą pod presją, by filtrować dostęp zgodnie z AML.
• TFR rozszerza zasady Travel Rule na krypto – przekazy informacji o nadawcy/odbiorcy przy transferach obsługiwanych przez pośredników.
• Prywatność to przewaga konkurencyjna: projekty, które wdrożą zgodność bez masowego gromadzenia danych, zyskają zaufanie użytkowników i regulatorów.

Czym jest ZK‑KYC i co faktycznie trzeba udowodnić

ZK‑KYC to zestaw praktyk, w których użytkownik przechodzi standardowy KYC/AML u zaufanego wydawcy poświadczeń (issuer), otrzymuje verifiable credential (VC), a następnie tworzy dowód ZK spełnienia polityki dostępu (np. „mam 18+ i nie jestem na liście sankcyjnej”), nie ujawniając przy tym danych źródłowych (imię, PESEL itp.).

Minimalny zakres zgodności (przykładowo)

• Wiek/kwalifikacja (np. 18+, kwalifikowany inwestor – jeśli dotyczy produktu).
• Jurysdykcja (np. rezydencja w EOG vs wykluczone kraje sankcyjne).
• Brak listy sankcyjnej (EU/OFAC – weryfikowane off‑chain, dowodzone on‑chain jako przynależność do zbioru „dozwolonych”).
• Świeżość weryfikacji (np. credential ważny 30 dni, z możliwością unieważnienia).

Trzy architektury ZK‑KYC dla DeFi/DEX

A) VC + ZK‑proof przy logowaniu (iden3 / Polygon ID, ogólny wzorzec)

• Wydanie: dostawca KYC tworzy W3C VC z atrybutami (wiek, kraj, status sankcyjny).
• Dowód: w portfelu generowany jest zk‑SNARK potwierdzający reguły polityki bez ujawnienia atrybutów.
• Weryfikacja: smart‑kontrakt lub bramka na L2 sprawdza dowód oraz merkle root aktywnych issuerów.
• Zalety: dobre UX (dowód w kilka sekund), brak przechowywania PII w dApp.

B) Prywatne listy dostępu z nullifierem (Semaphore / Sismo)

• Wydanie: po pozytywnym KYC użytkownik zostaje członkiem grupy „Dozwoleni”.
• Dowód: użytkownik udowadnia członkostwo w grupie i generuje nullifier zapobiegający nadużyciom (unikalne, nieodwracalne ID sesji).
• Weryfikacja: kontrakt sprawdza proof i czy nullifier nie był użyty (anty‑sybil, anty‑replay).
• Zalety: minimalne ujawnienie informacji; łatwe geofencing via zestawy członkowskie.

C) Konfidentialne bramki na warstwie wykonania (TEE EVM + ZK potwierdzenie)

• Wydanie: KYC do TEE‑oracle (zaufane środowisko), które wystawia skrót atrybutów.
• Dowód: TEE generuje dowód ZK, że atrybuty spełniają politykę; tylko proof trafia on‑chain.
• Zalety: wysoka przepustowość; dobre dla on‑rampów i mostów.

Jak to poskładać: referencyjny przepływ wdrożenia

1. Konfiguracja polityki (policy.json): wiek ≥ 18, rezydencja ∈ EOG, brak sankcji, ważność VC ≤ 30 dni.
2. Wybór issuerów (min. 2 dla redundancji) i publikacja ich kluczy/merkle root on‑chain.
3. Wydanie VC do portfela użytkownika (mobile SDK/desktop plugin).
4. Generacja ZK‑proof po stronie klienta i weryfikacja przez bramkę dostępu do DEX (router/aggregator).
5. Mint ephemeral pass: nietransferowalny ERC‑1155 z wygaśnięciem (np. 30 dni), by nie liczyć proofu przy każdym swapie.
6. Revocation: on‑chain lista unieważnień (CRL) aktualizowana przez issuerów; kontrakt odrzuca wygasłe/unieważnione passy.

Integracja z Account Abstraction (ERC‑4337)

• Session keys: po pozytywnym ZK‑KYC dApp wystawia klucz sesyjny o ograniczonych uprawnieniach (wybrane routery, limity wolumenu, TTL).
• Paymasters „KYC‑aware”: sponsorują gaz tylko dla adresów z ważnym pass‑tokenem.
• Multi‑chain: publikacja stanu (root, CRL) przez zk‑bridge lub relayer na L2/L3, by uniknąć niespójności.

AML w modelu ZK: co da się dowodzić bez ujawniania danych

• Set‑membership: adres/credential nie należy do listy sankcyjnej (dowód przynależności do zbioru „dozwolonych”).
• Range proofs: wiek ≥ 18 bez podawania daty urodzenia.
• Bounded activity: wolumen ≤ X w oknie T (dowód polityki limitów bez pokazywania historii transakcji).

Ryzyka, o których rzadko się mówi

• Re‑identyfikacja przez wzorce użycia: nawet z ZK‑KYC, korelacja czasu i kwot może deanonimizować – potrzebny rate‑limiting i mieszanie tras.
• Cross‑L2 replay: nullifier musi być przestrzenią nazw (domain‑separated) dla łańcucha i dApp.
• De‑facto centralizacja: jeden issuer = single point of failure. Wymagajcie multi‑issuer + mechanizmów łagodzenia sporów.
• UX tarcie: dowody na urządzeniu mobilnym muszą mieścić się w 1–3 s, inaczej porzucenie sesji skacze powyżej 20%.

Porównanie praktycznych narzędzi

Rozwiązanie	Typ dowodu	Unieważnienia	On‑chain SDK	UX / mobilnie	Licencja
Polygon ID (iden3)	zk‑SNARK, VC (W3C)	Tak (state/merkle root)	Tak (EVM)	2–5 s proof	OSS (Apache‑2.0)
Sismo Connect	Membership + nullifier	Przez aktualizację grup	Tak (EVM)	~1–2 s	OSS (MIT)
Semaphore (DIY)	Anonimowe członkostwo	Własny CRL	Tak (EVM)	zależy od implementacji	OSS
TEE + ZK mostek	TEE attest + SNARK	Po stronie orakla	Różnie	~sub‑sekunda	Różnie

Mini‑case: DEX z geofencingiem w UE bez przechowywania PII

• Cel: odblokować swapy dla rezydentów EOG 18+ i niesankcjonowanych, z miesięcznym odświeżaniem statusu.
• Wdrożenie (4 tygodnie):
  • Tydz. 1: integracja bramki ZK‑KYC i publikacja listy issuerów (2 podmioty KYC).
  • Tydz. 2: mint ephemeral ERC‑1155 pass (TTL 30 dni) + moduł CRL.
  • Tydz. 3: session keys (ERC‑4337) i limity wolumenu per sesja.
  • Tydz. 4: audyt obwodów ZK i testy wydajności (cel: proof ≤ 2 s, on‑chain verify ≤ 300k gas).
• Wynik: brak przechowywania PII w dApp, zgodność z polityką dostępu, minimalny wpływ na UX.

Checklist: techniczne i prawne „must‑have”

• Polityka dowodzenia spisana w języku formalnym (zkPolicy), wersjonowana, publiczna.
• Multi‑issuer + governance: kto dodaje/usuwa issuerów? (DAO z kworum).
• Revocation żywy (CRL/SC): opóźnienie aktualizacji ≤ 10 min.
• Domain separation dla nullifierów (dApp, chainId, wersja polityki).
• Audyt obwodów ZK (to nie jest zwykły smart‑kontrakt – weryfikuj toksyczne wejścia, parametry krzywych).
• Privacy by design: brak logów IP sklejonych z hashami credentiali; retencja logów minimalna.

Najczęstsze pytania (FAQ)

• Czy ZK‑KYC to nadal „KYC”? Tak – weryfikacja tożsamości odbywa się u issuera, ale do dApp trafia tylko dowód spełnienia polityki, nie PII.
• Czy DEX podlega MiCA? To zależy od poziomu decentralizacji i roli podmiotu w UE. Nawet jeśli protokół jest permissionless, front‑end w UE może potrzebować warstwy zgodności.
• Co z Travel Rule? TFR przede wszystkim dotyczy transferów realizowanych przez pośredników (CASP). ZK‑KYC może pełnić rolę proof‑of‑eligibility dla interakcji z tymi podmiotami.

Metryki sukcesu wdrożenia

• UX: średni czas generacji proofu ≤ 2,5 s; porzucenia < 10%.
• Bezpieczeństwo: 0 udanych ataków replay; 100% zgodności domain separation.
• Operacje: CRL age median ≤ 5 min; ≥ 2 issuerów aktywnych.
• Koszty: weryfikacja on‑chain ≤ 350k gas; koszt VC ≤ 1 € / użytkownik / miesiąc (cel).

Mapa drogowa: co dalej dla DeFi w UE

• Portfele „privacy‑first” z natywnym ZK‑KYC i social recovery.
• Paymasters regulacyjne rozliczające opłaty w stablecoinach zgodnych z MiCA.
• ZK‑governance: głosowanie w DAO bez ujawniania jurysdykcji, z wymogiem „1 człowiek = 1 głos”.

Wnioski i następne kroki

Dojrzały, europejski DeFi nie musi wybierać między zgodnością a prywatnością. ZK‑KYC pozwala spełnić kluczowe wymogi MiCA/TFR i jednocześnie chronić użytkowników przed wyciekiem danych. Projekty, które dziś zbudują warstwę zgodności jako moduł – z multi‑issuer, CRL i AA – jutro będą skalować się bez bólu.

CTA: Jeśli prowadzisz DEX, most lub dApp z funkcją swapu – zacznij od pilota: wybierz dwóch issuerów, wdroż bramkę ZK i ephemeral pass, przetestuj proof‑times na mobile. 4 tygodnie wystarczą, by wejść na ścieżkę zgodności bez kompromisu prywatności.