Airdropy 2.0: zkKYC i Proof‑of‑Personhood bez KYC – jak zrobić zgodny z AML, odporny na Sybil airdrop na L2

Kategorie: Airdropy & Giveaway’e, Bezpieczeństwo, Regulacje & Prawo, Web3 & DAO, Portfele (Wallets)

Wstęp: czy da się rozdawać tokeny bez wycieku danych?

Gwałtowny wzrost liczby Sybil-farm, rosnące wymogi AML/CFT i presja na ochronę prywatności stawiają projekty Web3 pod ścianą. Czy można przeprowadzić airdrop, który jest jednocześnie zgodny z regulacjami i nie zbiera danych osobowych? Odpowiedź brzmi: tak — dzięki zkKYC, anonimowym poświadczeniom i proof‑of‑personhood opartym o zero‑knowledge proofs na L2.

Dlaczego „stare” airdropy są dziś nie do utrzymania

Tradycyjne airdropy (snapshot → lista → claim) cierpią na trzy kluczowe problemy:

• Sybil: jedna osoba może kontrolować setki adresów, zawyżając alokację.
• Ryzyko prawne: rosną oczekiwania w zakresie weryfikacji użytkownika i sankcji geograficznych.
• Prywatność: KYC zrywa z ethos Web3 i odstrasza technicznych użytkowników.

Zamiast pełnego KYC, projekty wykorzystują dowody wiedzy zerowej do potwierdzenia spełnienia warunków — bez ujawniania danych źródłowych.

Co to jest zkKYC i jak działa w airdropach

zkKYC to parasolowy termin dla rozwiązań, w których użytkownik uzyskuje poświadczenie (credential) od wydawcy (issuer), a następnie generuje dowód ZK potwierdzający, że spełnia politykę (np. „nie jest z kraju X”, „jest pełnoletni”, „unikalny człowiek”) bez ujawniania tożsamości.

Minimalny model architektury

• Issuer: zaufany wydawca credentiali (np. dostawca eID, uczelnia, weryfikator zgodności).
• Holder: użytkownik przechowujący credential w portfelu (np. smart wallet z ERC‑4337).
• Verifier: kontrakt airdropu, który akceptuje dowód ZK i zapobiega podwójnym roszczeniom (nullifiers).

Dowód ZK często zawiera nullifier — kryptograficzny „odcisk palca” instancji credentialu pozwalający odrzucić drugi claim tej samej osoby, bez ujawnienia jej klucza czy tożsamości.

Wzorce wdrożenia: od „badges” do anonimowych credentiali

Wzorzec	Jak działa	Prywatność	Koszt (L1/L2)	Ryzyka / Uwaga
Sismo‑style Badges	Użytkownik posiada dowód przynależności lub historii on‑chain; generuje ZK‑proof bez ujawniania adresu źródłowego.	Wysoka (ukrywa adres źródłowy)	Niskie na L2	Wymaga ostrożnego doboru grup i limitu na „list leakage”.
Polygon ID / anon. credentials	Wydawca wystawia credential (np. „18+”, „non‑US”). Użytkownik prezentuje selektywnie atrybuty w ZK.	Bardzo wysoka (selektywne ujawnianie)	Niskie/średnie na L2	Wymaga kanału dystrybucji credentiali i polityki odwołań.
Semaphore / RLN (Rate‑Limit Nullifier)	Dowód unikalności i ograniczenie liczby roszczeń w czasie (1 osoba → 1 claim/okres).	Wysoka	Niskie	Dobór okna czasowego i parametrów anty‑farmowych kluczowy.
zkEmail / zkPass‑style	Dowód posiadania konta e‑mail lub statusu (np. staż konta) bez ujawniania adresu.	Średnia–wysoka	Niskie	Zależność od dostawcy e‑mail; ryzyko automatyzacji farm na jednorazowych skrzynkach.
World‑ID‑style PoP	Proof‑of‑Personhood dostarczany przez zewnętrzny system; kontrakt akceptuje ZK‑dowody unikalności.	Wysoka (on‑chain)	Niskie na L2	Kontrowersje dot. źródła PoP; sprawdź warunki użycia i jurysdykcję.

Projekt airdropu z zkKYC: plan działania 0 → 1

Krok 1: Polityka i granice ryzyka

• Zdefiniuj cele: wzrost aktywnych adresów vs. głęboka adopcja produktu.
• Określ kryteria zgodności (np. wykluczenia sankcyjne, minimalny wiek, regiony).
• Wybierz wzorzec ZK (Sismo/Polygon ID/Semaphore) oraz L2 (np. rollup EVM) dla niskich kosztów gas.

Krok 2: Model tożsamości i anty‑Sybil

• Połącz proof‑of‑uniqueness (Semaphore/RLN) z risk‑signals poza łańcuchem (powierzchnia aktywności, staż portfela) mapowanymi do score.
• Wymuś „1 osoba → 1 claim” przez nullifiers oraz rate‑limit na okno czasowe.
• Rozważ device‑binding w portfelach ERC‑4337 (passkeys, klucze sprzętowe) bez gromadzenia PII.

Krok 3: Kontrakt i logika dowodu

• Kontrakt przyjmuje zk‑proof + nullifier; zapisuje nullifier jako spent.
• Opcjonalnie uwzględnia reputację (próg punktowy → warstwowe pule, np. Base/Gold).
• Wersja cross‑chain: publikuj korzeń Merkle credentiali i weryfikuj na wielu L2 z mostem komunikatów.

Krok 4: UX i onboarding

• Portfele smart accounts (ERC‑4337) z session keys i paymasterem pokrywającym gas dla pierwszego claimu.
• QR‑flow dla credentiali (np. Polygon ID) i 1‑klik claim na mobile.
• Transparentny privacy notice: co jest przetwarzane lokalnie, co trafia on‑chain.

Krok 5: Observability i bezpieczeństwo

• Metryki: claim‑rate, unikalność (nullifiers), wskaźniki podejrzanych wzorców czasowych.
• Alarmy na anomalię gazu, klastry adresów, farm botów (np. identyczne ścieżki transakcyjne).
• Audyty obwodów ZK, kontraktów i logiki rate‑limit.

Regulacje: jak łączyć AML z prywatnością (bez porady prawnej)

Uwaga: poniższe ma charakter informacyjny, nie jest poradą prawną. W praktyce projekty muszą uwzględnić lokalne prawo (np. ramy unijne dotyczące krypto‑aktywów i przeciwdziałania praniu pieniędzy) i ewentualne obowiązki VASP.

• Risk‑based approach: zamiast pełnego KYC dla wszystkich, zastosuj progi ryzyka i warstwowe credentiale (np. „nieobjęty sankcjami”, „rezydent UE”).
• Selektywne ujawnianie: dowody typu „spełnia/nie spełnia” (age‑over, geo‑allowlist) ograniczają przetwarzanie PII.
• Revocation: mechanizm odwołania credentialu (lista odwołań podpisana przez issuerów) propagowany do weryfikatorów.
• Travel Rule kompatybilność w transferach z custodianami: w airdropie non‑custodial można stosować soft‑gating (credential przy odbiorze), a przy wypłatach do VASP — przekazywać wyłącznie wymagane atrybuty (ZK).

Tokenomika airdropu odporna na farmy

• Warstwowe pule: Base (PoP), Plus (PoP + aktywność on‑chain), Pro (PoP + aktywność + wkład off‑chain potwierdzony ZK).
• Dynamiczna alokacja: część puli rozdzielana ex‑post na podstawie aktywności w okresie prób (np. 30 dni), mierzonej na L2 z minimalnym kosztem gas.
• Anti‑dump: vesting z soulbound‑escrow możliwy do przeniesienia dopiero po spełnieniu ZK‑mission (np. udział w głosowaniu DAO).

Case study (hipotetyczne): Airdrop gry Web3 na L2

• Cel: 100k unikalnych graczy, bez farmy z botów.
• Stos: L2 EVM, portfele ERC‑4337 z passkeys, Semaphore (PoP) + Polygon ID (geo/18+).
• Reguły:
  • Warstwa 1: 1 claim/OSOBA/7 dni (RLN), 100 tokenów bazowych.
  • Warstwa 2: +150 tokenów za ukończenie 3 zadań on‑chain (misje w grze).
  • Warstwa 3: +250 tokenów za wkład w społeczność potwierdzony anonimowym credentialem moderatora.
• Bezpieczeństwo: Audyt obwodów ZK; testnet z fałszywą pulą i honeypotem wykrywającym farmy.
• Wynik (oczekiwany): wysoki wskaźnik retencji dzięki misjom i minimalne duplikaty dzięki nullifierom.

Najczęstsze błędy i jak ich uniknąć

• Za słabe kryteria PoP: Połącz co najmniej dwa sygnały (Semaphore + staż adresu lub reputacja).
• Brak odwołań: Projektuj revocation w dniu 0, nie po wycieku credentiali.
• On‑chain deanonimizacja: Nie publikuj list surowych adresów kwalifikowanych; używaj grup/korzeni Merkle + ZK.
• Zły UX: Bez paymastera i mobilnego QR‑flow konwersja dramatycznie spada.
• Hard‑geofencing bez komunikacji: Transparentnie wyjaśnij powody i alternatywy (np. testnet‑missions).

Warstwa portfela: ERC‑4337, passkeys i session keys

Account Abstraction pozwala na portfele z logowaniem passkeys, które:

• Redukują bariery wejścia (brak fraz seed),
• Umożliwiają session keys do mikropodpisów w trakcie claimu,
• Wspierają policy engine (podpisz tylko jeśli dowód ZK ważny → mniej błędów użytkownika).

Warstwa danych: prywatność domyślna

• Minimalizacja danych: przechowuj wyłącznie hash/nullifier i znacznik czasu.
• Odcinanie korelacji: stosuj ephemeral relayers lub privacy‑preserving RPC do składania roszczeń.
• Analiza ryzyka off‑chain w trybie ZK (np. „score >= 70” bez ujawniania składowych).

Roadmapa technologiczna (co warto śledzić)

• Szybsze ZK‑provery na urządzeniach mobilnych i przeglądarce (krótszy czas generowania dowodu).
• Intents i bundlery łączące claim z natychmiastowym użyciem tokenów (np. stake/lock w jednej operacji).
• Cross‑chain claims z bezpiecznym mostem komunikatów i jednolitym nullifier set na wielu L2.
• Reputation composability: agregacja credentiali z różnych źródeł bez utraty prywatności.

Checklist: gotowość do startu

• Masz zdefiniowane kryteria zgodności i politykę prywatności?
• Wybrałeś stack ZK i zaprojektowałeś nullifiers + rate‑limits?
• Portfele ERC‑4337 z paymasterem działają na docelowym L2?
• Przeprowadziłeś audyty kontraktów i obwodów?
• Masz telemetrię i plan reakcji na nadużycia (pause/upgrade)?

Wnioski i następne kroki

Nowa fala airdropów nie opiera się na listach i botach, ale na poświadczeniach ZK, unikalności i account abstraction. Dzięki temu można pogodzić zgodność z regulacjami i prywatność użytkowników, a przy tym realnie ograniczyć farmy. Jeśli planujesz airdrop w tym roku:

• Wybierz stack credentiali (np. Polygon ID + Semaphore) i docelowe L2.
• Zaprojektuj nullifiers i rate‑limits, zanim napiszesz tokenomikę.
• Przetestuj UX na ERC‑4337 z paymasterem i mobilnym QR‑flow.

CTA: Chcesz checklistę wdrożeniową i szablony polityk? Daj znać, przygotujemy wersję dopasowaną do Twojego projektu i jurysdykcji.