Airdropy z dowodem położenia (zk-PoL): geofencje bez GPS i bez KYC dla Web3, DePIN i eventów

Jak zrobić airdrop wyłącznie dla osób obecnych na stadionie, konferencji lub w konkretnej dzielnicy – bez śledzenia GPS i bez zbierania danych osobowych? Odpowiedzią jest Proof-of-Location (PoL)zero-knowledge oraz sieciami DePIN. Poniżej znajdziesz praktyczny, techniczny i prawny przewodnik, którego w polskim internecie wciąż brakuje.

Dlaczego geofencing airdropów jest trudny

Geolokalizacja w krypto nie jest trywialna, bo większość klasycznych rozwiązań łatwo oszukać lub narusza prywatność.

1) GPS i emulatory

• Spoofing: aplikacje i debug-tryby potrafią podszyć się pod dowolne współrzędne.
• Brak kryptografii: surowe koordynaty nie dowodzą, że faktycznie byłeś na miejscu.

2) Prywatność vs. fraud

• Prywatność: KYC i śledzenie GPS są sprzeczne z ethosami Web3.
• Fraud: organizatorzy muszą ograniczyć multi-konta i farmy nagród.

3) Sybil i boty

• Sybil: jedna osoba może mieć dziesiątki portfeli.
• MEV: nawet poprawnie pozyskany token może zostać „podebrany” w mempoolu.

Architektura zk-Proof-of-Location: jak to działa

Nowa fala rozwiązań łączy fizyczne punkty kotwiczące (beacony), podpisy kryptograficzne i dowody zerowej wiedzy, aby udowodnić obecność w obszarze bez ujawniania dokładnej lokalizacji, urządzenia czy tożsamości.

Kluczowe komponenty

• Anchory (beacony): urządzenia BLE/Wi‑Fi/LoRa emitujące krótkotrwałe, podpisane komunikaty (np. co 5–15 s).
• Mapowanie: lista ID/kluczy anchorów dla danego geofencu jest hashowana do Merkle root i publikowana on‑chain.
• Klient: telefon zbiera pakiety z otoczenia i buduje dowód (zk‑SNARK/PLONK), że widział wystarczającą liczbę ważnych beaconów w krótkim oknie czasu.
• Weryfikator (smart‑kontrakt): sprawdza dowód i wypłaca airdrop bez ujawniania surowych danych.

Jak wygląda przepływ

1. Deploy: organizator instaluje anchory w obszarze i publikuje Merkle root z ich publicznymi kluczami, czasem i parametrami.
2. Skanning: użytkownik w aplikacji mobilnej zbiera podpisane ramki (BLE/Wi‑Fi/LoRa).
3. Dowód: lokalnie generuje zk‑proof (np. set‑membership + range proof czasu), że widział ≥N poprawnych ramek w T sekund.
4. Claim: kontrakt EVM weryfikuje dowód i pozwala odebrać token/NFT.

Prywatność: żadnych surowych SSID, adresów MAC, koordynatów czy identyfikatorów urządzenia na łańcuchu. Oszustwa są ograniczane przez krótkie okna czasowe, rotację kluczy beaconów i limity na portfel.

Metody dowodu położenia: co wybrać?

Metoda	Zasada	Sprzęt	Typowe ataki	Prywatność	Koszt	Skalowalność
BLE z podpisem + zk set‑membership	Telefon widzi ≥N podpisanych ramek z listy beaconów	Beacon BLE (np. nRF52) z kluczem ECDSA/Ed25519	Relay, klonowanie beaconów	Wysoka (brak surowych danych)	Niski/średni	Wysoka (tanie beacony)
Wi‑Fi AP z podpisem	Podpisy w beaconach/ProtEAP, zestaw SSID	AP z firmwarem z podpisem	Relay, podszywanie SSID	Wysoka	Średni	Wysoka (istniejąca infrastruktura)
LoRaWAN/DePIN (np. Helium)	Triangulacja hotspotów + podpisy	Hotspoty DePIN, tag LoRa	Relay, ograniczona gęstość	Wysoka	Średni	Średnia (gęstość sieci)
GNSS + TEE	Położenie z GPS/RTK poświadczone w TEE	Telefon/urządzenie z TEE	Spoofing GNSS, ataki na TEE	Średnia (zaufanie do TEE)	Wyższy	Wysoka

Wniosek: dla eventów i airdropów BLE/Wi‑Fi + zk‑proof jest często najlepszym kompromisem koszt/bezpieczeństwo/prywatność.

Przykład (case study): festiwal 30 000 osób, geofenced NFT + kupony

• Lokalizacja: teren festiwalu (0,28 km²), 65 beaconów BLE zasilanych powerbankami, rotacja kluczy co 60 s.
• On‑chain: publikacja Merkle root listy beaconów na L2 (Optimism/Arbitrum) + kontrakt claim.
• UX: QR‑kody przy wejściach prowadzą do PWA. Aplikacja skanuje otoczenie 20 s, generuje dowód na urządzeniu, claim z meta‑tx (sponsorowany gas).
• Anty‑Sybil: 1 claim/wallet/epoka + opcjonalny Soulbound wydawany przy bramce po zeskanowaniu biletu (offline, bez danych osobowych).
• Wyniki (hipotetyczne): 61% konwersji, średni czas claimu 16 s, 0,9% odrzuceń (relay), brak wycieków danych.

Implementacja krok po kroku (dla devów)

Warstwa off‑chain

1. Beacony: nRF52/ESP32 z ECDSA/Ed25519; ramka = epoch_id || nonce || podpis. Epoch 30–90 s.
2. Listy: budujesz Merkle tree z publicznych kluczy + identyfikatorów stref.
3. Dowód: obwód zk (Circom/Halo2/gnark) weryfikuje podpisy i to, że ≥N ramek pochodzi z zestawu pod korzeniem Merkle i w oknie czasu T.
4. Prover mobilny: WASM/Metal/Neon; ogranicz rozmiar świadectw (Groth16 ~ 192 B) i czas generacji (<5 s na nowszych telefonach).

Warstwa on‑chain (EVM)

• Verifier: kontrakt dla Groth16/PLONK (np. via snarkjs, Hardhat/Foundry).
• Claim: funkcja verifyAndMint(proof, publicSignals) + rate‑limit na adres (i opcjonalny SBT).
• Gas i UX: ERC‑4337 i meta‑transakcje – sponsorujesz opłaty, żeby onboard był 1‑klikowy.
• MEV‑safe: commit‑reveal z krótkim oknem lub use private mempool (RPC z ochroną przed frontrunem).

Testy i monitorowanie

• Emulator beaconów do testów relay/clone.
• Rotacja kluczy i wykrywanie anomalii (nagłe korelacje ramek z odległych punktów).
• Bezpieczne przechowywanie kluczy anchorów (HSM lub co najmniej secure element).

Bezpieczeństwo: wektory ataku i mitigacje

• Relay atak: ktoś przesyła ramki poza strefę. Mitigacja: bardzo krótkie epochy, miks anchorów z różnymi zegarami, opóźnienia nieprzewidywalne, sygnatura z unikalnym salt dla strefy.
• Klonowanie beaconów: skradzione klucze. Mitigacja: secure element, fizyczne plombowanie, szybkie unieważnianie i aktualizacja Merkle root.
• Sybil: multi‑portfele. Mitigacja: per‑device rate limit (lokalne), SBT on‑site, integracja z BrightID/Gitcoin Passport (dobrowolna).
• MEV: kradzież claimu. Mitigacja: commit‑reveal, prywatny RPC, batched relayer.

Uwaga: distance‑bounding (pomiar czasu lotu) w BLE/Wi‑Fi jest wciąż tematem badań – traktuj je jako uzupełnienie, nie jedyną tarczę.

Regulacje & Prawo (PL/EU)

• Airdropy co do zasady nie są loterią, jeśli brak elementu losowości. Jeśli wprowadzisz losowanie nagród – sprawdź przepisy o loterii promocyjnej i wymogi zezwoleń.
• AML/KYC: przy czystej dystrybucji utility/NFT bez wymiany na fiat zwykle nie wchodzisz w obowiązki VASP, ale jeśli oferujesz wymianę/wykup – konsultacja prawna wskazana.
• RODO: zk‑PoL minimalizuje dane – nie zapisujesz koordynatów ani identyfikatorów urządzeń. Zadbaj o politykę prywatności i retencję logów.
• Podatki: po stronie odbiorcy airdrop może stanowić przychód (w PL – potencjalnie do opodatkowania przy zbyciu). Po stronie organizatora – koszt marketingowy. Skonsultuj księgowość.

Narzędzia & stack startowy

• Circom + snarkjs lub Halo2/gnark – budowa obwodów i weryfikatorów.
• ESP32/nRF52 – beacony BLE z Ed25519/ECDSA; biblioteki mbedTLS/tinycrypt.
• Helium/DePIN – gdy chcesz wykorzystać istniejący zasięg LoRaWAN.
• ERC‑4337 bundler i OpenZeppelin – meta‑tx, kontrola dostępu.
• BrightID / Gitcoin Passport – opcjonalna warstwa anty‑Sybil.

Strategie inwestycyjne i rynek (Makro & DePIN)

DePIN + zk‑PoL tworzy nową kategorię: geolokalne utility NFT, kupony i mikropłatności. Potencjał mają tokenomie, które realnie nagradzają fizyczną obecność (sklepy, muzea, transport, smart‑miasta), zamiast czystych farm tasków. Ryzyko: regulacje i dojrzałość narzędzi mobilnych ZK.

FAQ & Support

• Czy to działa offline? Dowód możesz wygenerować offline; do claimu potrzebny jest internet (lub lokalny relayer).
• Jaki telefon? iOS/Android z BLE 4.2+, lepiej z nowszym GPU/Neon do przyspieszenia ZK.
• Ile beaconów? Minimum 4–8 na małą strefę, 50+ na duże wydarzenia dla redundancji.

Checklist: od pomysłu do airdropu w 14 dni

• D1–3: projekt stref i instalacja beaconów, generacja kluczy, publikacja Merkle root.
• D4–7: PWA z mobilnym proverem, integracja z bundlerem ERC‑4337.
• D8–10: testy relay/clone, monitoring, polityka prywatności.
• D11–12: kampania edukacyjna, QR‑kody, onboarding.
• D13–14: event, wsparcie relayera, post‑mortem i spalanie/rotacja kluczy.

Wnioski i następne kroki

zk‑PoL przenosi airdropy z poziomu „farming i boty” do realnej, lokalnej użyteczności bez KYC i bez naruszania prywatności. Jeśli organizujesz wydarzenie lub prowadzisz markę retail:

• Zacznij od pilota na jednej strefie (BLE + Groth16).
• Wdróż meta‑tx i prosty limit 1 claim/osoba.
• Przygotuj politykę prywatności oraz krótkie T&C airdropu.

CTA: Szukasz gotowego zestawu beaconów i kontraktów? Skontaktuj się z naszym zespołem lub dołącz do kanału Społeczności – udostępnimy repozytorium referencyjne i checklisty wdrożeniowe.