Portfel jako silnik polityk: praktyczne AA (ERC-4337) dla startupów Web3, z guardianami, limitami i ZK-atestami

Dlaczego o tym mało w polskim internecie? Większość poradników o kryptowalutach zatrzymuje się na poziomie seed phrase i multisig. Tymczasem nowe pokolenie portfeli opartych o Abstrakcję Kont (ERC-4337) pozwala wdrożyć reguły bezpieczeństwa jak w bankowości korporacyjnej: limity dzienne, sesyjne klucze, guardianów M-of-N, geofencing, a nawet zgodność z regulacjami bez ujawniania danych dzięki zero-knowledge attestation. Ten artykuł to techniczno-biznesowy przewodnik, jak zbudować taki portfel lub wdrożyć go w startupie Web3.

Szybkie wprowadzenie: o co chodzi w ERC-4337 i dlaczego teraz?

ERC-4337 przenosi logikę kont użytkownika do smart kontraktów, umożliwiając niestandardowe reguły podpisu i płatności gasem. Operacje użytkownika trafiają do bundlerów, a rozlicza je EntryPoint. Efekt: portfel staje się programowalny i może egzekwować polityki jak system finansowy.

• Kluczowa różnica EOA vs. Smart Account: EOA = jeden klucz prywatny. Smart Account = kod + moduły polityk (plugins), podpis weryfikowany np. przez EIP-1271.
• Gas sponsorship: Paymaster pokrywa opłaty, co otwiera onboarding bez ETH, ale wymaga kontroli ryzyka.
• Nowe propozycje: EIP-3074 i EIP-7702 mogą przybliżyć funkcje AA do klasycznych portfeli – warto planować kompatybilność.

Architektura: portfel jako policy engine

Traktujemy portfel jak silnik reguł, który przed wykonaniem transakcji przechodzi przez pipeline decyzji.

• Warstwa weryfikacji podpisu: klucze główne, session keys z zakresem i TTL, sprzętowe FIDO2.
• Moduły polityk: limity kwotowe, velocity (częstotliwość), whitelisty/blacklisty, time-lock, geofencing, wymuszony quorum guardianów.
• Warstwa płatnika gasu (Paymaster): reguły sponsorowania, budżety, antynadużycia.
• Telemetria i alerty: sygnały ryzyka on-chain i off-chain, tryb awaryjny (circuit breaker).

Najważniejsze reguły polityk – co naprawdę podnosi bezpieczeństwo

Reguła	Opis	Kiedy używać
Limit dzienny	Maksymalna suma transferów per 24 h.	Hot wallet startupu, konta operacyjne.
Time-lock > X h	Opóźnia wypłaty powyżej progu.	Ochrona przed drainerami i paniką.
Session key	Tymczasowy klucz na 1 dApp, z limitem metod i kwot.	Gaming, DeFi-trading bots, NFT minty.
Whitelist kontraktów	Dozwolone adresy i metody ABI.	DAO Treasury, fundusze.
Guardian M-of-N	Wymaga współautoryzacji lub odzysku.	Klucze główne, krytyczne transfery.
Geofencing	Blokada z regionów ryzyka lub TOR.	Paymaster, masowe wypłaty.
Velocity	Limit liczby transakcji na godzinę/dzień.	Airdropy, kampanie growth.

Guardiani i odzyskiwanie: jak zrobić to dobrze

Klasyczne „social recovery” bywa podatne na social engineering. Lepsze wzorce:

• M-of-N heterogeniczne: 1 hardware key + 1 custody partner + 1 DAO multisig; różne domeny ryzyka.
• Opóźnione przejęcie (time-delay): po spełnieniu quorum zmiana klucza wchodzi w życie np. po 48 h, z alertami.
• Tryb lodówki (freeze): jedna szybka sygnatura z hardware key zamraża konto na 24–72 h.
• MPC lub Shamir SSS na poziomie klucza głównego, ale polityki nadal w kontrakcie (przez EIP-1271).

Paymaster: sponsorowanie gasu bez otwierania furtki dla fraudu

Paymasterzy ułatwiają onboarding, ale są wektorem nadużyć. Wbuduj:

• Budżety per użytkownik i per dApp (np. 5 USD dziennie).
• Filtry metod: sponsoruj tylko określone funkcje (np. deposit, approve z limitem).
• Anty-farm: sygnatury czasu, device fingerprint, minimalny staż konta.
• Blokada weekendowa dla ryzykownych aktywów, kiedy płynność jest płytsza.

Zgodność bez masowego KYC: ZK-atesty w praktyce

Zamiast gromadzić dane, wymagaj atestów zero-knowledge (np. „powyżej 18 lat”, „nie z listy sankcyjnej”). Portfel wymusza posiadanie ważnego atestu, ale nie widzi surowych danych użytkownika.

• Use case 1: IDO tylko dla użytkowników z atestem jurysdykcji dozwolonej.
• Use case 2: Limity większe dla posiadaczy atestu weryfikacji dochodów bez ujawniania kwoty.
• Use case 3: DAO głosuje, a portfel weryfikuje „jeden człowiek = jeden głos” przez atesty sybil-resistance.

Wielosieciowość: jedna polityka, wiele łańcuchów

Polityki należy modelować cross-chain. Dobre praktyki:

• Limity w USD liczone z wyroczni (medianizer, time-weighted) z zapasowym feedem.
• Listy dozwolonych mostów i minimalne opóźnienia przy bridge out.
• Synchronizacja stanów polityk przez komunikację uXCM/IBC lub komunikaty potwierdzane przez guardianów.

Mini-case study: gorący portfel marketplace NFT

• Problem: drenaże przez złośliwe setApprovalForAll oraz boty gazowe podczas mintów.
• Rozwiązanie AA:
  • Session keys tylko do metod safeTransferFrom, limit 3 NFT na godzinę.
  • Time-lock 2 h dla wypłat > 5 000 USD, guardian 2-of-3 do skrócenia opóźnienia.
  • Whitelist kontraktów kolekcji zweryfikowanych przez ryzyka.
  • Paymaster sponsoruje wyłącznie minty z KYC-ZK lub allowlistą.
• Wynik: redukcja fraudu o 72% i 38% mniej zgłoszeń wsparcia przy zimnym starcie kolekcji.

Szablon polityk: przykład w pseudo-konfiguracji

{
  policy_version: 1,
  limits: {
    daily_usd: 2000,
    per_tx_usd: 800
  },
  timelocks: [
    { threshold_usd: 1000, delay_hours: 6 }
  ],
  session_keys: [
    { dapp: "app.example", methods: ["swapExactTokens"], ttl_min: 60, max_usd: 200 }
  ],
  allowlists: { contracts: ["0xABC...", "0xDEF..."] },
  guardians: { quorum: 2, members: ["hardware:ledger#A1", "safe:0xGUA...", "custody:partnerX"] },
  paymaster: { daily_budget_usd: 5, allowed_methods: ["deposit", "mint"] },
  zk_requirements: ["age_over_18", "not_sanctioned"],
  emergency: { freeze_hours: 48 }
}

Checklist wdrożenia w startupie Web3

• Model zagrożeń: malware na urządzeniu, phishing transakcji, SIM swap, ataki na mosty.
• Dobór SDK: Safe{Core}, Pimlico, Biconomy, Stackup, Rhinestone plugins (sprawdź licencje i audyty).
• Obsługa EIP-1271: podpisy z różnych źródeł (MPC, hardware, sesyjne).
• Testy chaosowe: symulacje w shadow-forku, property-based testing polityk.
• Monitoring: alerty na wzrost odrzuceń, nieudane walidacje, anomalie gazu, nowe uprawnienia.
• UX: tłumaczenie polityk na język użytkownika: „Możesz dziś wydać 2 000 USD”.

Kalkulator limitów: prosta heurystyka

Ustal limit dzienny tak, by maksymalna strata przy pojedynczym incydencie była akceptowalna.

• Limit_dzienny = 0,5 × średnie dzienne przepływy (ostatnie 30 dni), zaokrąglone do najbliższych 100 USD.
• Limit_transakcyjny = min(0,4 × Limit_dzienny, 0,2 × saldo).
• Jeśli zmienność 7D aktywa > 80%, obniż limity o 25% na weekend.

Regulacje & Prawo: praktyka bez nadmiernej inwazyjności

• Travel Rule w B2B: portfel może wymagać ZK-atestu „VASP-to-VASP ok” zamiast pełnych danych.
• Listy sankcyjne: sprawdzane przez orakle zgodności; logika w kontrakcie blokuje transfer bez poprawnego atestu.
• Rejestrowalność: export podpisanych logów polityk dla audytu, bez danych osobowych.

Roadmapa techniczna: ERC-4337, EIP-3074 i EIP-7702

• ERC-4337: dojrzały ekosystem bundlerów i paymasterów; standard dla smart accountów.
• EIP-3074: autoryzacja EOA przez kontrakt – może ułatwić migracje do polityk AA.
• EIP-7702: propozycja łączenia zalet EOA i smart accountów; planuj kompatybilność modułów.

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

• Brak opóźnień dla wysokich kwot – dodaj co najmniej 2–6 h.
• Session key bez ograniczeń – zawsze ogranicz metody i TTL.
• Jeden guardian w tej samej domenie ryzyka – różnicuj dostawców i urządzenia.
• Paymaster bez budżetów – prowadzi do drenowania sponsorowanych środków.

Podsumowanie z akcją do wykonania

Portfel jako silnik polityk to przewaga konkurencyjna: mniej fraudu, lepsza zgodność, lepszy UX. Zacznij od małego: wdroż limit dzienny, time-lock i session keys w jednym krytycznym przepływie, a następnie dodaj guardianów oraz Paymaster z budżetami. Jeśli prowadzisz startup Web3, wyznacz „właściciela polityk”, który będzie iterował reguły w oparciu o dane.

CTA: Przygotowaliśmy szablon polityk i scenariusze testów dla AA – zaimplementuj je w tygodniu sprintowym i zmierz spadek incydentów. Gdy będziesz gotów, rozszerz o ZK-atesty i wielosieciowe limity USD.