Softech Blog
Digital Assets & Financial Infrastructure

Custodial vs Non-custodial vs Embedded Wallets: Architecture Decision Guide

How to choose wallet control architecture based on ownership, transaction approval, automation, recovery, UX and operational responsibility.

2 min read
Custodial vs Non-custodial vs Embedded Wallets: Architecture Decision Guide
Executive summary

The most important points from this article

How to choose wallet control architecture based on ownership, transaction approval, automation, recovery, UX and operational responsibility. The core design decision is who controls value movement, who authorizes signing, and which state belongs to the blockchain versus the product ledger.

Key takeaways
  • Choose the control model before choosing the wallet vendor.
  • Separate business authorization from cryptographic signing.
  • Map every wallet/address to a canonical product entity.
  • Keep customer deposit state separate from treasury sweep state.
  • Design recovery and reconciliation before production launch.
Key insights

Key observations and insights

The key observations summarizing the experience, decisions and outcomes described in the article.

The wallet SDK should not define the custody model by accident.
Signing authority and business authorization are separate controls.
A blockchain balance is evidence of assets, not the complete product ledger.
Treasury movement should not change whether a customer deposit was valid.

Short answer

Custodial, non-custodial and embedded are not interchangeable labels. They describe different boundaries of economic control, key/signing responsibility and user experience. “Embedded” mainly describes where the wallet experience lives; the wallet can still be user-controlled or application-controlled depending on the architecture.

Decision 1: who controls value movement?

If the user must approve each transfer, use a user-controlled/non-custodial model. If the platform needs automated payouts, deposit collection or server-side settlement, a developer-controlled model may fit. If business treasury requires institutional controls, add explicit vault/policy/approval architecture.

Custodial / developer-controlled

The application or business controls transaction execution. This enables automation and simplifies UX, but it increases the importance of licensing analysis, authorization policy, segregation of duties, recovery and operational security. Circle explicitly notes that regulatory licensing may apply when a platform holds assets for users.

User-controlled / non-custodial

The user authorizes the signing operation. Circle documents user-controlled wallets where users authenticate with familiar methods and approve transactions from their device. The application orchestrates the flow but should not silently convert user-owned signing into backend authorization.

Embedded wallet

Embedded wallet is a product-experience pattern: onboarding, balance and transaction actions live inside your application rather than forcing the user into an external wallet extension. Coinbase CDP and Circle both document application-integrated wallet experiences. The key question remains who ultimately controls signing.

Architecture comparison

ModelBest forPrimary risk to design
User-controlled embeddedConsumer fintech, rewards, user-owned assetsRecovery, session/signing UX, user intent
Developer-controlledPayouts, deposits, automation, marketplacesAuthorization, custody responsibility, key-operation policy
Treasury/institutionalCompany reserves and operational fundsApprovals, limits, segregation of duties, incident response

Questions we answer during architecture discovery

  • Who economically owns the assets at each stage?
  • Who may initiate a transaction?
  • Who must approve it?
  • Can the backend execute while the user is offline?
  • What recovery path exists?
  • What happens during provider outage?
  • Which state is authoritative for the product balance?
  • Which jurisdictional or custody constraints must the legal team confirm?

Recommendation

Do not select a wallet provider based only on the prettiest onboarding demo. Write the control matrix first. Then compare providers against that matrix.

Solution framework

Key elements and relationships

Wallet Control Architecture

Five layers separating ownership, authorization, signing, execution and accounting.

Layer 1
Control model

Who economically controls the assets and who is allowed to initiate movement.

Layer 2
Authorization

Product policy for roles, limits, destination and transaction intent.

Layer 3
Signing

MPC, passkey, key or smart-account mechanism that authorizes blockchain execution.

Layer 4
Execution

Network transaction submission, observation and finality.

Layer 5
Ledger & operations

Product state, treasury, recovery, monitoring and reconciliation.

Evidence and context

Information supporting the analysis

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.

Continue reading

Related articles

Articles that expand the topic and add further practical context.

Author

Matt Dudzicz · Softech.app

Founder

Founder of Softech.app, focused on product engineering, digital asset infrastructure, custom software and AI-native business systems.

LinkedIn
Next step
Designing embedded wallets, MPC or treasury infrastructure?
We map the control model, signing policy, recovery, ledger and operations before selecting the provider and SDK.