Geo‑fenced stablecoiny: pieniądz programowalny wydawany tylko „tu i teraz” — od proof‑of‑location po ERC‑4337

Czy stabilny krypto‑pieniądz, który działa wyłącznie w określonej strefie i czasie, może stać się brakującym ogniwem między Web3 a światem offline? W dobie account abstraction (ERC‑4337), tanich L2 i tanich czujników BLE/LoRaWAN, geo‑fenced stablecoiny nabierają realnych kształtów — z potencjałem do subwencji miejskich, biletów komunikacji, tokenów cateringowych na stadionach czy grantów dla lokalnych społeczności.

Co to są geo‑fenced stablecoiny?

To stablecoiny (np. USD‑pegged) z programowalnym ograniczeniem miejsca i/lub czasu użycia. Przelew „przechodzi” tylko wtedy, gdy portfel odbiorcy lub płatnika udowodni, że znajduje się wewnątrz wielokąta geograficznego (np. stadion, kampus, dzielnica) oraz opcjonalnie spełnia okno czasowe (np. 18:00–22:00). Ograniczenie jest egzekwowane przez logikę w smart‑kontrakcie, która przyjmuje kryptograficzny dowód położenia.

Po co geofencing pieniądza?

• Airdropy lokalne: nagrody tylko dla uczestników wydarzenia IRL (walka z sybilem i botami).
• Bilety i katering: token‑vouchery ważne wyłącznie w obrębie stadionu/konferencji.
• Wsparcie socjalne: kupony na żywność i transport w obrębie gminy (przejrzystość i rozliczalność on‑chain).
• DeFi dla miast: community notes z odsetkami wypłacanymi tylko rezydentom dzielnicy.
• Metaverse ↔ IRL: NFT‑przepustki, które „odblokowują” stablecoiny po fizycznym odwiedzeniu lokalizacji (POAP + cash‑back).

Architektura: jak dowieść, że jesteś tam, gdzie mówisz?

Geo‑fenced stablecoin to warstwy: czujniki → dowód lokalizacji → portfel → smart‑kontrakt → polityka/DAO.

1) Warstwa dowodu lokalizacji

• Fuzja sensorów: GPS + Wi‑Fi RTT + BTS (cell‑tower) + beacony BLE. Minimalizuje spoofing jednego źródła.
• Attestacja sprzętowa: podpis z TEE (np. Android StrongBox) lub zewnętrzny klucz w HSM/Secure Element; łączy odczyty z tożsamością urządzenia.
• Dowód bez ujawniania: zk‑proof (np. circuit w Circom), który potwierdza, że H3‑index pozycji należy do zadanego wielokąta, bez zdradzania dokładnej koordynaty.

2) Warstwa portfela (ERC‑4337)

• Account Abstraction: portfel to smart‑konto; akceptuje userOperation tylko z ważnym dowodem lokalizacji.
• Klucze sesyjne: krótkotrwałe session keys przypięte do geostrefy i limitów (np. 3 płatności/30 min).
• Rate‑limiting i spending policy trzymane on‑chain, aktualizowane decyzją DAO/emitenta.

3) Warstwa smart‑kontraktu

• Token: rozszerzony ERC‑20 z hookiem w transfer sprawdzającym politykę geofencingu (albo standardy restrykcyjne typu ERC‑1404/3643).
• Weryfikator ZK: kontrakt odbiera skrót dowodu i weryfikuje go względem roota polityki (Merkle‑root polygonów).
• Tryb awaryjny: „panic button” do zdjęcia ograniczeń w klęskach żywiołowych (z multisign/DAO).

4) Polityka i orakle

• Zarządzanie strefami: wielokąty w standardzie GeoJSON → zhashowane do drzewa Merkle → opublikowane on‑chain.
• Okna czasowe: zegar on‑chain (L2 sequencer) + cross‑check ntp oracle, aby ograniczyć manipulację czasem.
• Audyt legalny: polityki zgodne z AML/KYC, minimalizacja danych wg GDPR.

Bezpieczeństwo: wektory ataku i obrony

Najczęstsze ataki

• GPS spoofing (aplikacje, anteny SDR).
• Relay sygnału BLE/Wi‑Fi (przedłużanie zasięgu).
• Emulacja urządzenia (root/jailbreak, fałszywe TEE).
• Ataki czasu (zmiana zegara systemowego, delay tranzakcji).

Mitigacje

• Fuzja i spójność: wymagaj >= 2 zgodnych źródeł; wykrywaj anomalie (RSSI, RTT, jitter).
• Hardware attestation: podpisy sprzętowe + listy zaufanych modeli urządzeń.
• Challenge‑response z lokalnych beaconów o zmiennym kluczu (czasowo‑jednorazowe tokeny).
• Limity i ryzyko: mikropłatności domyślnie, wyższe kwoty wymagają silniejszego dowodu (MFA, dodatkowe beacony).
• Tryb offline‑optimistic: NFC‑paragony z podpisem merchanta, późniejsza finalizacja z oknem sporów.

Mapa komponentów

Komponent	Opis	Przykład
Portfel	ERC‑4337 z kluczami sesyjnymi	Smart‑wallet na L2 (Base/Arbitrum)
Dowód lokalizacji	zk‑proof z H3‑index i attestation	Circom, snarkJS, keystore StrongBox
Beacony	BLE z rotacją kluczy	iBeacon/Eddystone z trybem E2E
Orakle	GeoJSON → Merkle root on‑chain	Chainlink Functions / własny oracle
Token	ERC‑20 z hookiem polityk	ERC‑1404/3643 kompatybilny

Studium przypadku (hipotetyczne): Miasto 250k — „bilet miejski” jako stablecoin

• Zakres: Strefy geograficzne obejmują przystanki, perony, pętle tramwajowe i kioski.
• Polityka: Płatność działa w promieniu 50 m od węzłów komunikacyjnych, ważna przez 90 min od pierwszej walidacji.
• Technika: Walidator w autobusie wystawia wyzwanie BLE; portfel zwraca podpisany zk‑dowód; kasownik zapisuje hash na L2.
• Efekt: 34% mniej oszustw „na screeny”, 22% szybsza walidacja, transparentne rozliczenia operatorów w czasie rzeczywistym.

DIY dla deweloperów: minimalny MVP w 7 krokach

1. Wybierz łańcuch L2 z tanim gazem i wsparciem ERC‑4337.
2. Zdefiniuj strefę w GeoJSON, podziel na siatkę H3 (np. resol. 9), wylicz Merkle‑root.
3. Zbuduj circuit w Circom: wejście prywatne = H3 komórki + attestacja urządzenia; publiczne = root, czas, nonce.
4. Napisz weryfikator w kontrakcie i rozszerz transfer w tokenie o wymóg ważnego dowodu.
5. Portfel: dodaj klucze sesyjne i politykę płatności (limity/TTL) w module AA.
6. Walidacja offline: merchanci z NFC publikują podpisane paragony; batch finalizacja on‑chain.
7. Monitoring: dashboard anomalii (udział odrzuconych dowodów, heatmapa nadużyć).

Pro / Contra

Aspekt	Plus	Minus
Użyteczność	Środki trafiają tam, gdzie powinny; szybkie IRL‑płatności	Wymaga kompatybilnego portfela i beaconów
Bezpieczeństwo	Silna kontrola wydatkowania, mniejszy fraud	Ryzyko spoofingu przy słabym wdrożeniu
Prywatność	zk‑proof ukrywa dokładne położenie	Attestacja sprzętu bywa kontrowersyjna (modele zaufania)
Regulacje	Łatwa segmentacja do AML/benefitów	Kompleksowość zgodności z GDPR/KYC
Koszty	Tanie L2, batch finalizacja	Utrzymanie infrastruktury beaconów

Regulacje & Podatki: na co uważać

• AML/KYC: geofencing to nie tożsamość — rozważ verifiable credentials z selektywnym ujawnianiem.
• GDPR: trzymaj minimum danych — publikuj tylko zk‑dowody i skróty; unikaj logów geo off‑chain.
• Podatki: vouchery i bony mogą mieć inne traktowanie podatkowe niż gotówka; mapuj scenariusze z doradcą.

Narzędzia & Kalkulatory (starter pack)

• Kalkulator pokrycia beaconów: liczba nadajników vs. powierzchnia i gęstość ludzi.
• Estimator gazu: koszt weryfikacji zk‑proof vs. batch (N transakcji/blok).
• Generator Merkle: z GeoJSON do root + dowód członkostwa (H3).
• Test spoofingu: skrypty do symulacji GPS/Wi‑Fi RTT i metryk anomalii.

FAQ & Support

• Czy to działa bez internetu? Tak, w trybie offline‑optimistic z NFC i późniejszą finalizacją.
• Czy potrzebuję specjalnego telefonu? Urządzenie z Android StrongBox/TEE i BLE — zalecane, ale można wdrożyć tryb „soft” z niższymi limitami.
• Co, jeśli strefa się zmieni? Nowy Merkle‑root polityki jest publikowany on‑chain; portfele pobierają aktualizację.

Wnioski i następne kroki

Geo‑fenced stablecoiny łączą finanse programowalne z konkretnym miejscem i czasem. To szansa na precyzyjne airdropy, transparentne subwencje i płynne płatności IRL bez rezygnacji z prywatności dzięki zk‑proof. Jeśli jesteś miastem, organizatorem eventu lub twórcą portfela, zacznij od PoC na jednej strefie i polityce czasowej, a następnie rozbuduj o klucze sesyjne i beacon‑challenge.

CTA: Chcesz wdrożyć pilota? Przygotujemy referencyjny kontrakt, circuit i specyfikację beaconów dla Twojej strefy — odezwij się do redakcji, aby otrzymać repo i checklistę audytu.