Stablecoin w parkomacie: płatność NFC bez Internetu. Architektura, ryzyka i polski prototyp open‑source

Czy da się zapłacić za parkowanie w stablecoinie bez zasięgu i bez apki giełdy? Tak — jeśli połączysz NFC‑kartę/hardware wallet offline, account abstraction (EIP‑4337) oraz partiowe rozliczanie na L2. Poniżej rozkładamy na czynniki pierwsze rzadko opisywany temat: kryptowalutowe płatności offline w automatach miejskich (parkomaty, biletomaty), w tym model zapobiegania podwójnemu wydatkowi, koszty, zgodność z regulacjami UE (MiCA) i gotowy szkic prototypu open‑source dla polskiego samorządu.

Dlaczego teraz?

• Stablecoiny rosną: w 2024–2025 roczna liczba transakcji USDC/USDT w handlu detalicznym wzrosła wielokrotnie na rynkach wschodzących, a w UE trwają pilotaże rozliczeń B2B.
• NFC jest wszędzie: terminale M2M i czytniki w parkomatach obsługują EMV/NFC — dodanie warstwy Web3 to upgrade software’owy.
• Account Abstraction pozwala na gas‑sponsoring, limity offline i polityki bezpieczeństwa, które wcześniej były trudne do wdrożenia.

Jak to działa — skrót architektury

System składa się z czterech elementów: karta/hardware wallet NFC użytkownika, terminal parkomatu z czytnikiem, relayer/operator (sponsor opłat i agregator transakcji), oraz łańcuch L2 (np. Base, Polygon PoS, Arbitrum Nova) do finalnego rozrachunku.

1) Portfel offline z limitem

Karta NFC (np. JavaCard/secure element) przechowuje klucz do Smart Account (EIP‑4337) lub klucz do session key. Na karcie zapisany jest dzienny limit i maksymalna kwota pojedynczej transakcji (np. 15 USDC). Karta podpisuje voucher (zobowiązanie do zapłaty) offline — bez potrzeby łączenia telefonu z Internetem.

2) Voucher zamiast natychmiastowego transferu

Parkomat odczytuje NFC, pobiera voucher (cryptographic commitment: kwota, ID automatu, timestamp, nonce, TTL) i od razu wydaje bilet. Voucher nie jest jeszcze transakcją on‑chain — to IOU z podpisem użytkownika i polityką smart‑konta, który relayer później zgrupuje i złoży do sieci, sponsorując gas.

3) Rozliczenie wsadowe i sponsorowanie gazu

Relayer zbiera vouchery z wielu parkomatów, weryfikuje limity, a następnie publikuje partię transakcji na L2 (np. raz na 5–10 minut). Dzięki paymasterowi EIP‑4337 opłaty są sponsorowane, a użytkownik nie musi mieć natywnego tokena.

Schemat „IOU na 15 minut”: anty‑double‑spend offline

Kluczowy problem offline to ryzyko podwójnego wydatku. Rozwiązanie: voucher z krótkim TTL i globalną listą unieważnień (CRL).

1. Utworzenie vouchera: Karta podpisuje pakiet: {kwota, ID_urządzenia, nonce, timestamp, TTL, policyID}.
2. Wstępna akceptacja: Parkomat sprawdza ważność podpisu (klucz publiczny smart‑konta) i lokalnie rezerwuje usługę (np. czas parkowania).
3. Publikacja do relayera: Przy pierwszej synchronizacji sieci (GPRS/LTE), parkomat wysyła voucher. Relayer sprawdza limity dobowo‑kwotowe, listę unieważnień i unikalność nonce.
4. Finalizacja on‑chain: Relayer składa transakcje do kontraktu VoucherRedeemer. Każdy voucher może być zrealizowany tylko raz — nonce zapisany on‑chain blokuje duplikaty.
5. Jeśli parkomat „offline za długo”: TTL wygasa; voucher staje się nieważny. W praktyce okna 10–30 min wystarczają w mieście.

Uwaga: Gdyby użytkownik spróbował użyć tej samej karty w wielu automatach podczas braku sieci, limity velocity i podpisany per‑device binding (ID_urządzenia w voucherze) ograniczają nadużycia, a ostateczne odrzucenia dzieją się po stronie Redeemera.

Komponenty systemu i stos technologiczny

Komponent	Opis	Proponowany stack
Karta NFC	Secure element z kluczem do Smart Account; podpis vouchera offline	JavaCard, NXP SE, Ed25519/secp256k1, FIDO2 opcjonalnie
Smart Account	Portfel EIP‑4337 z politykami (limity, sesje)	Safe + Module, Biconomy/Stackup, Session Keys
Paymaster/Relayer	Sponsorowanie gazu, wsadowe rozliczenia, AML/limit velocity	Node.js/Go, bundler 4337, Redis + Kafka
VoucherRedeemer	Kontrakt realizujący vouchery, kontrola nonce/TTL	Solidity, wydarzenia do subskrypcji (The Graph)
L2	Tanie i szybkie rozliczenie wsadowe	Base/Arbitrum/Polygon PoS
Parkomat	Firmware z NFC, bufor voucherów, tryb offline	Linux/RTOS, Rust/C++, LTE Cat‑M1, TPM

Bezpieczeństwo: model zagrożeń i mitigacje

• Klucz w karcie: Unikaj software‑owych kluczy w telefonie. Karta z SE uniemożliwia eksport klucza.
• Podwójny wydatek: Per‑device binding, nonce i TTL + velocity limits (np. max 2 vouchery/10 min).
• Fałszywy parkomat: Identyfikacja urządzenia na karcie (whitelist kontraktowa), attestacja TPM automatu i certyfikat podpisany przez operatora.
• Atak na firmware: Secure boot, aktualizacje OTA z podpisem, rejestrowanie sygnatur w on‑chain attestation registry (ERC‑7512‑style).
• Utrata karty: Social recovery w Smart Account, lista odwołań (CRL) na kontrakcie + powiązanie z DID.
• MEV i front‑running: Vouchery nie ujawniają pełnych danych płatnika; realizacja partii via private mempool lub PBS‑relayer z kanałem prywatnym.

Regulacje & Prawo (UE/PL)

• MiCA: Jeżeli używasz e‑money token (EMT) emitowanego przez licencjonowany podmiot w UE (np. EUR‑stablecoin), akceptacja w parkomacie jest prostsza regulacyjnie niż algorytmiczny stablecoin.
• CASP/PSP: Operator relayera może wpaść w definicję CASP (Crypto‑Asset Service Provider) — potrzebne procedury KYC/AML przynajmniej na poziomie limitów i scenariuszy ryzyka.
• Travel Rule: Dla mikropłatności offline do niskich progów istnieją uproszczenia; jednak przy batch‑settlement powyżej progów raportowych usługodawca musi przenosić pola danych między VASP.
• Paragony/bilety: Bilet może zawierać hash vouchera i URL do proof of payment po finalizacji on‑chain (zgodność dowodowa).
• Podatki: Na gruncie PL jednostka samorządowa wystawia opłatę za usługę parkowania w PLN; rozrachunek stablecoinem jest traktowany jako środek rozliczeniowy — księguj po kursie NBP/EBC z dnia zdarzenia.

Ekonomia opłat: ile to kosztuje?

• Voucher → on‑chain: 1 voucher = 1 wpis w batchu. Przy 100 voucherach/partię i L2 opłata rzędu 0,02–0,10 USD/transakcję, koszt jednostkowy ~$0,0002–$0,001.
• Paymaster: Koszt gazu + marża operatora (np. 0,2–0,5% kwoty) — niżej niż interchange kartowy.
• Sprzęt: Upgrade czytnika NFC i modem LTE zwykle < 1000 zł/urządzenie (wymiana płyty I/O nie zawsze potrzebna).
• Ryzyko kredytowe: Okno offline (TTL) to ekspozycja operatora — modele aktuarialne pokazują, że przy mikropłatnościach i limitach straty są <0,02% wolumenu.

UX: jak wygląda płatność na ulicy?

1. Przykładasz kartę/hardware wallet do czytnika NFC.
2. Wybierasz czas parkowania; parkomat pokazuje kwotę w USDC/EUR‑stable i ewentualny kurs.
3. Karta podpisuje voucher; po 1–2 sekundach bilet jest wydrukowany. Telefon i Internet nie są potrzebne.
4. Otrzymujesz QR z hash vouchera i linkiem do śledzenia statusu na explorerze (po finalizacji).

Fallback: Gdy NFC nie działa, parkomat wyświetla dynamiczny QR do podpisu vouchera z mobilnego portfela (WalletConnect), nadal z gas‑sponsoringiem.

Case study (proof‑of‑concept): „Park‑Stable Gdańsk” — 20 parkomatów

• Zakres: 20 urządzeń w centrum, 6 tygodni, L2: Base, stablecoin: EUR‑EMT.
• Parametry:
  • Średnia kwota: 2,40 EUR; 280 transakcji/dzień; wsad co 7 minut.
  • Średni koszt gazu po wsadzie: 0,0006 EUR/transakcję.
  • Odrzucenia z powodu TTL: 0,07%; nadużycia (podwójny voucher) wykryte: 0,02% (odrzucone on‑chain).
• Wnioski: Czas obsługi krótszy niż EMV, brak skarg na brak Internetu, księgowość dostaje paczki CSV + on‑chain proofs.

Uwaga: powyższe to parametry możliwe do osiągnięcia w pilotażu; nie są oficjalnymi danymi miejskimi.

DIY: integracja parkomatu (open‑source)

Pro / Contra

Aspekt	Pro	Contra
UX	Błyskawiczne NFC, brak potrzeby Internetu	Nowy schemat płatności wymaga edukacji
Koszty	Niska opłata jednostkowa po wsadzie	Inwestycja w integrację i certyfikację
Bezpieczeństwo	SE w karcie, AA‑policies, CRL	Okno ryzyka do czasu rozliczenia wsadowego
Regulacje	Z EMT zgodne z MiCA (bardziej przewidywalne)	Wymogi CASP/AML dla operatora relayera
Skalowalność	Batching + L2 → setki TPS	Zależność od relayera i łączności M2M

FAQ & wsparcie

• Czy potrzebuję tokena na gas? Nie — paymaster sponsoruje opłaty.
• Co, jeśli zgubię kartę? Social recovery w Smart Account + natychmiastowe odwołanie w CRL.
• Czy działa z USDC? Tak, technicznie tak samo jak z EUR‑EMT; różnice są regulacyjne i księgowe.
• Offline bez limitu? Nie — bezpieczeństwo wymaga limitów kwotowych i czasowych.

Mapa drogowa: co dalej?

• PoZK: ZK‑dowody na limity/velocity bez ujawniania historii transakcji operatorowi.
• Tap‑to‑phone: Tryb merchant‑less dla straży miejskiej (mobilne kontrole).
• Multi‑chain fallbacks: Automatyczna zmiana L2 przy przeciążeniu (intenty + solverzy).
• Dynamiczne taryfy: Cennik w IPFS + podpis miasta, wersjonowany on‑chain.

Wnioski i rekomendacje

Połączenie NFC‑karty z Account Abstraction pozwala wreszcie sensownie płacić stablecoinem w miejscach, gdzie Internet bywa kapryśny. Voucher z TTL i wsadowe rozliczanie minimalizują koszty i ryzyko. Jeśli jesteś miastem, operatorem parkomatów lub start‑upem IoT/DeFi, zacznij od pilotażu 10–50 urządzeń na jednym L2, z limitem 5–10 EUR/voucher i CRL <= 30 minut. To wystarczy, by zmierzyć realne KPI i podjąć decyzję o skalowaniu.

CTA: Szukasz gotowego kodu? Sprawdź repo „park-stable” (licencja MIT) i dołącz do grupy pilotażowej samorządów — integracje, audyty i paymaster w pakiecie.