Softech Blog
Digital Assets & Financial Infrastructure

Custodial vs Non-custodial vs Embedded Wallets: Jak wybrać model

Jak wybrać wallet control architecture na podstawie ownership, transaction approval, automation, recovery, UX i odpowiedzialności operacyjnej.

2 min czytania
Custodial vs Non-custodial vs Embedded Wallets: Jak wybrać model
Podsumowanie

Najważniejsze informacje z artykułu

Jak wybrać wallet control architecture na podstawie ownership, transaction approval, automation, recovery, UX i odpowiedzialności operacyjnej. Kluczową decyzją jest to, kto kontroluje przepływ wartości, kto autoryzuje signing i który stan należy do blockchaina, a który do product ledgera.

Najważniejsze wnioski
  • Wybierz control model przed wyborem vendora walletów.
  • Oddziel business authorization od cryptographic signing.
  • Mapuj każdy wallet/adres do kanonicznej encji produktu.
  • Oddziel stan depozytu klienta od stanu treasury sweep.
  • Zaprojektuj recovery i reconciliation przed startem produkcji.
Kluczowe obserwacje

Kluczowe obserwacje i tezy

Najważniejsze obserwacje podsumowujące doświadczenia, decyzje i rezultaty opisane w materiale.

Wallet SDK nie powinien przypadkiem definiować modelu custody.
Signing authority i business authorization to osobne kontrole.
Saldo blockchain jest dowodem aktywów, nie kompletnym product ledgerem.
Treasury movement nie powinien zmieniać faktu, czy depozyt klienta był poprawny.

Krótka odpowiedź

Custodial, non-custodial i embedded nie są zamiennymi etykietami. Opisują różne granice economic control, odpowiedzialności za keys/signing i UX. „Embedded” opisuje głównie miejsce doświadczenia walleta; sam wallet może być user-controlled albo application-controlled.

Decyzja 1: kto kontroluje przepływ wartości?

Jeśli użytkownik ma zatwierdzać każdy transfer, wybierz user-controlled/non-custodial. Jeśli platforma potrzebuje automated payouts, deposit collection albo server-side settlement, developer-controlled może pasować lepiej. Jeśli treasury firmy wymaga institutional controls, dodaj vault/policy/approval architecture.

Custodial / developer-controlled

Aplikacja lub firma kontroluje transaction execution. Umożliwia to automatyzację i prostszy UX, ale zwiększa znaczenie licensing analysis, authorization policy, segregation of duties, recovery i security. Circle wprost zaznacza, że przy trzymaniu aktywów użytkowników mogą pojawić się wymagania licencyjne zależne od jurysdykcji.

User-controlled / non-custodial

Użytkownik autoryzuje signing. Circle dokumentuje user-controlled wallets, w których użytkownik loguje się znaną metodą i zatwierdza transakcję na swoim urządzeniu. Produkt orkiestruje flow, ale nie powinien ukrycie zamieniać user-owned signing w backend authorization.

Embedded wallet

Embedded wallet to wzorzec UX: onboarding, balance i actions są wewnątrz aplikacji zamiast zewnętrznego extension. Coinbase CDP i Circle dokumentują application-integrated wallet experiences. Kluczowe pytanie nadal brzmi: kto kontroluje signing.

Porównanie

ModelNajlepszy dlaGłówne ryzyko do zaprojektowania
User-controlled embeddedConsumer fintech, rewards, user-owned assetsRecovery, signing UX, user intent
Developer-controlledPayouty, depozyty, automation, marketplaceAuthorization, custody responsibility, policy
Treasury/institutionalRezerwy i środki operacyjne firmyApproval, limity, segregation of duties, incident response

Pytania na architecture discovery

  • Kto ekonomicznie posiada aktywa na każdym etapie?
  • Kto inicjuje transakcję?
  • Kto ją zatwierdza?
  • Czy backend może wykonać ją bez aktywnego usera?
  • Jak wygląda recovery?
  • Co robimy podczas provider outage?
  • Co jest source of truth dla product balance?
  • Jakie ograniczenia custody/jurisdiction musi potwierdzić legal?

Rekomendacja

Nie wybieraj providera na podstawie najlepszego demo onboarding. Najpierw zapisz control matrix. Dopiero później porównuj providerów.

Model rozwiązania

Kluczowe elementy i zależności

Wallet Control Architecture

Pięć warstw rozdzielających ownership, authorization, signing, execution i accounting.

Warstwa 1
Control model

Kto ekonomicznie kontroluje aktywa i kto może inicjować ruch wartości.

Warstwa 2
Authorization

Polityka produktu dla ról, limitów, destination i transaction intent.

Warstwa 3
Signing

MPC, passkey, key lub smart-account mechanism autoryzujący wykonanie blockchain.

Warstwa 4
Execution

Submission transakcji, obserwacja i finality w sieci.

Warstwa 5
Ledger & operations

Stan produktu, treasury, recovery, monitoring i reconciliation.

Źródła i kontekst

Informacje wspierające analizę

Circle documents developer-controlled wallets for backend-controlled automation, user-controlled wallets for user-approved transactions, and modular wallets for custom wallet experiences.

Circle documents developer-controlled wallets as API-driven wallets where the application controls creation, transaction execution and signing.

Circle documents user-controlled wallets as user-owned wallets where users authenticate and approve transactions from their device.

Fireblocks documents vault, policy and wallet infrastructure for controlling digital-asset operations and treasury workflows.

Coinbase CDP documents non-custodial wallet infrastructure and programmatic wallet APIs for application-integrated wallets.

Czytaj dalej

Powiązane artykuły

Materiały, które rozwijają temat i uzupełniają go o dodatkowy kontekst praktyczny.

Autor

Matt Dudzicz · Softech.app

Founder

Founder Softech.app, skoncentrowany na product engineeringu, infrastrukturze digital assets, custom software i systemach biznesowych AI-native.

LinkedIn
Następny krok
Projektujesz embedded wallet, MPC albo treasury?
Zmapujemy control model, signing policy, recovery, ledger i operacje zanim wybierzemy providera oraz SDK.