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.

3 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.

Architektura

Referencyjny przepływ wykonania

Kolejność warstw pokazuje, gdzie probabilistyczne AI łączy się z deterministycznym stanem, policy i operacjami produktu.

  1. 01
    control model
  2. 02
    wallet lifecycle
  3. 03
    signing policy
  4. 04
    treasury and reconciliation
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

Źródła zewnętrzne i twierdzenia weryfikowalne

Zewnętrzne twierdzenia faktograficzne są powiązane ze źródłami pierwotnymi lub dokumentacją techniczną; nie są mieszane z first-party evidence Softech.

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, systemach mobile i web, digital infrastructure oraz oprogramowaniu biznesowym AI-native.

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