Executive summary
Crypto wallet infrastructure to warstwa produktu, która określa kto kontroluje aktywa, kto może autoryzować transfer, jak odbywa się signing, jak transakcja blockchain staje się stanem produktu i jak operacje odzyskują system po awarii. Wygenerowanie adresu jest najłatwiejszą częścią.
Współczesne platformy walletowe oferują kilka modeli kontroli. Circle rozdziela m.in. developer-controlled, user-controlled i modular wallets. Decyzja inżynieryjna nie brzmi więc „który SDK?”, tylko „jaka granica własności i autoryzacji ma istnieć w produkcie?”.
Najpierw wybierz control model. Dopiero później wybieraj wallet providera.
Trzy produkcyjne modele walletów
User-controlled i embedded wallets
Ten model ma sens, gdy użytkownik powinien posiadać środki i akceptować transakcje. Aplikacja może dostarczać Web2-like onboarding i branded wallet UX, ale approval pozostaje po stronie użytkownika.
Developer-controlled i programmatic wallets
Programmatic wallets mają sens, gdy backend tworzy konta, przyjmuje depozyty, automatyzuje payouty, porusza treasury albo wykonuje operacje server-side. Circle dokumentuje tę klasę właśnie jako backend-controlled creation i transaction execution.
Treasury i institutional operations
Rezerwy firmy wymagają innego control plane: ról, transaction policy, approval, allowlist, recovery, segregation of duties i audit evidence. Fireblocks pozycjonuje vault i policy infrastructure właśnie wokół takich wymagań operacyjnych.
Pięć warstw wallet infrastructure
- Identity i wallet registry — mapowanie użytkownika, konta lub encji firmy do kanonicznego wallet record.
- Authorization policy — decyzja czy operacja jest dozwolona zanim zostanie wywołany signer.
- Signing — MPC, passkeys, keys albo smart-account ownership wykonują kryptograficzną autoryzację.
- Blockchain execution — submission, observation i klasyfikacja finality.
- Ledger i operations — posting zdarzeń biznesowych, reconciliation, treasury i recovery evidence.
Signing to nie authorization
Backend credential, który potrafi poprosić o podpis, nie powinien automatycznie móc wysłać dowolnej kwoty na dowolny adres. Product policy powinno wcześniej sprawdzić actor, asset, network, amount, destination, transaction purpose, limity i approval.
Wallet balance to nie product balance
Stan on-chain odpowiada na pytanie „ile aktywów jest pod adresem?”. Nie mówi, dlaczego środki przyszły, czy są depozytem klienta, czy zostały zaakceptowane, czy powstała korekta i czy treasury już je przesunęło. Ta interpretacja należy do internal ledgera.
Dla płatności przejdź dalej do dedykowanych adresów depozytowych USDC i przewodnika po stablecoin ledgerze.
Recovery projektujemy na discovery
Recovery to nie tylko „odzyskaj key”. Obejmuje utratę user authentication, migrację urządzenia, niedostępność signera, outage providera, stuck transaction, błędną policy, kompromitację operatora i bezpieczne wznowienie działania.
Provider abstraction bez udawania, że providerzy są identyczni
Utrzymujemy product-owned wallet registry i transaction model wokół provider-specific IDs. Ogranicza to coupling, ale custody model, signing guarantees, chain support, recovery i policy capabilities nadal pozostają jawnymi decyzjami architektonicznymi.
Kiedy smart accounts mają sens
EOA są proste i szeroko kompatybilne. Smart accounts mogą dodać gas sponsorship, batching i programmable authorization na wspieranych EVM networks. Aktualna dokumentacja Circle rozdziela te możliwości i rekomenduje wybór account type po wyborze wallet product/control model.
Checklist produkcyjny
- Zdefiniuj economic ownership i control boundary.
- Zdefiniuj kto inicjuje, zatwierdza i podpisuje.
- Mapuj wallet IDs i adresy do encji biznesowych.
- Używaj idempotency przy tworzeniu walletów i transakcji.
- Oddziel transaction submission od business posting.
- Oddziel customer deposits od treasury sweeps.
- Zaprojektuj provider outage i recovery.
- Uzgadniaj provider/chain evidence z product ledgerem.
- Daj operatorom pełny transaction timeline.
Wniosek
Najlepsza architektura walletów nie zaczyna się od tabeli funkcji vendora. Zaczyna się od kontroli. Gdy ownership, authorization, signing i operacje są jawne, provider i chain stają się wyborem implementacyjnym zamiast przypadkową definicją modelu biznesowego.