What Is a Non-Custodial Wallet, and How Does It Differ From a Custodial Wallet?

A non-custodial wallet and a custodial wallet differ mainly in who controls the credentials used to access and authorize transactions involving crypto assets. In the self-custody model described by SEC staff, the user controls and is responsible for the private keys and recovery material needed to access the user’s crypto assets. In a third-party custody arrangement, a provider manages access to private keys on the customer’s behalf. The distinction determines where key-management responsibility sits, but it does not by itself establish how secure, recoverable, or reliable a particular implementation is.

The labels describe custody arrangements, not a single technical design. A useful comparison begins with the control boundary: who controls the transaction-authorizing credentials, who manages them, and what documented processes govern access and recovery?

What is a non-custodial wallet?

A non-custodial wallet is an arrangement in which the user retains control of the credentials used to authorize transactions. The self-custody model described by SEC staff places control and responsibility for the relevant private keys and recovery material with the user. This wording matters: a system’s mere designation by a user does not establish that the arrangement is non-custodial. The relevant question is whether the user retains control of the transaction-authorizing credentials.

A wallet generally manages private keys or passcodes used to access and authorize crypto assets rather than storing the assets themselves. This distinction helps clarify what a wallet service may manage: credentials or the means of using them, rather than the assets in the ordinary sense. The precise design can vary, so a wallet label alone does not explain how signing works or who controls it.

Self-custody designs can use seed phrases, hardware devices, multisignature arrangements, threshold signing, or other recovery models. These are examples of possible approaches, not a claim that every wallet uses them or that they work identically. To understand a particular implementation, documentation should identify the credentials used to authorize transactions, who controls them, and how recovery is handled.

Calling a wallet “non-custodial” does not resolve every operational question. The label does not specify who within an organization can initiate or approve a transaction, what recovery material exists, or how the system handles key-management events. Those details depend on the implementation and its operating procedures.

What is a custodial wallet?

A custodial wallet involves a third party managing access to private keys on behalf of customers. Crypto exchanges can be among the possible third-party custodians. Instead of the customer directly managing the relevant private keys, the provider’s arrangement governs credential management and the customer’s access to the service.

The relationship between a customer account, provider-managed credentials, and transaction authorization depends on the specific arrangement. A provider may have systems and processes involved in processing or authorizing transactions, but the label “custodial” alone does not describe those steps. Account access and asset-control processes depend on the provider’s arrangement and terms. To assess a particular service, verify its documented custody structure and authorization workflow rather than inferring them from a product name or account interface.

Custody should also be distinguished from the wallet interface. An interface is how a person or system interacts with a service; the custody arrangement identifies who manages access to transaction-authorizing credentials. The provider’s account-access process is part of its arrangement and should not be assumed from the general meaning of “custodial.”

The scope of a provider’s arrangement matters. Custody structure, customer rights, segregation, insurance, regulation, and insolvency treatment vary by provider and jurisdiction. These matters cannot be determined from the general definition of a custodial wallet. This comparison does not establish the legal treatment or protections applicable to a specific arrangement.

Non-custodial vs. custodial wallets: the core differences

DimensionNon-custodial arrangementCustodial arrangement
Credential controlThe user retains control of the relevant transaction-authorizing credentials.A third-party custodian manages access to private keys on the customer’s behalf.
Key-management responsibilityIn the self-custody model described by SEC staff, the user is responsible for the private keys and recovery material needed to access the user’s crypto assets.The provider manages credential access within the scope of its arrangement; customer access and control depend on that arrangement and its terms.
Transaction authorizationThe specific wallet and signing design determine how credentials are used to authorize a transaction.The provider’s technical systems and documented processes determine how its custody arrangement processes or authorizes transactions.
What the label establishesIt indicates user control of relevant credentials, but not a uniform technical or recovery design.It indicates third-party management of access to private keys, but not uniform customer rights or provider processes.

The main operational difference is where responsibility for credential management sits. In self-custody, the user controls and is responsible for the relevant keys and recovery material. In third-party custody, the provider manages access to private keys on the customer’s behalf, while the customer’s access and control depend on the provider’s arrangement and terms. Neither description is a complete assessment of a specific system’s safeguards or performance.

For either model, distinguish the interface from the custody arrangement. A familiar interface does not, by itself, establish who controls credentials. Likewise, an account login or permission is not necessarily evidence of who controls the credentials used to authorize transactions. That control boundary must be established from the design and its documentation.

Transaction authorization also merits a precise reading. “Who can approve?” and “who controls the signing credentials?” are related but distinct questions. An organization may define approval roles around credentials, while a provider may manage credential access under its own arrangement. The specific approval roles and internal controls depend on the design. Technical decision-makers should identify both the credential controller and the documented authorization steps before describing a system’s custody model.

The supplied general definitions do not establish that either model is safer or more reliable. Security and recovery outcomes depend on the specific implementation and its processes, so a comparison should not draw conclusions from the custody label alone.

How to assess which custody model fits an operation

A neutral assessment starts with the operation’s requirements and checks them against implementation-specific details, without presuming that one custody model is preferable.

1. Map transaction approval and credential control. Identify who must approve transactions and who controls the credentials used to authorize them. These may be different roles. For a non-custodial arrangement, verify that the user retains control of the relevant signing credentials. For a custodial arrangement, establish which credentials the provider manages and what role the customer has under the documented arrangement. Do not treat a login or account permission as proof of who controls transaction-authorizing keys.

2. Define key-management responsibilities. For self-custody, document who is responsible for the keys and recovery material. For a provider-managed arrangement, determine what credential-management responsibilities the provider undertakes and what access processes remain with the customer. General key-management guidance covers protection and lifecycle functions such as generation, storage, distribution, use, recovery, revocation, and destruction. These categories can organize a review, but do not establish that a particular wallet performs each function in a specific way.

3. Examine access, continuity, and recovery requirements. State what the operation needs to know about access and recovery, then review implementation-specific documentation. A non-custodial label does not reveal the recovery design: possible approaches include seed phrases, hardware devices, multisignature arrangements, threshold signing, or other models. A custodial label likewise does not reveal the provider’s account-access process or the customer’s rights under its terms. Do not infer a recovery outcome from the model name.

4. Review technical documentation and terms. Where a third party manages credentials, consult primary documentation describing the custody structure and transaction-authorization process, along with the provider’s terms. The technical description can explain how credentials are managed; the terms can describe the stated customer relationship and access processes. If either source leaves a material point unclear, treat it as unresolved. For a non-custodial implementation, verify the actual signing and recovery design rather than relying on marketing terminology.

5. Keep conclusions proportional to evidence. Security, recovery, access continuity, and other performance outcomes require evidence specific to the implementation. General key-management guidance can help identify lifecycle topics for review, but blockchain-specific roles, custody models, and cryptographic modules require a separate risk assessment. A general definition is not enough to support a product-level comparison or a claim about a particular outcome.

Useful verification questions include:

  • Which party controls the private keys or other signing credentials?
  • What mechanism authorizes a transaction, and where is that mechanism documented?
  • Who is responsible for relevant key and recovery-material processes?
  • Which lifecycle functions—such as generation, storage, use, recovery, revocation, and destruction—are documented, and by whom?
  • If a provider manages credentials, what do its technical documentation and terms say about custody and customer access?
  • Which important details depend on the specific implementation rather than the wallet label?

These questions help distinguish a stated custody model from verified operational facts. They do not, on their own, determine legal rights, regulatory status, or a security outcome.

Key takeaways

  • The central distinction is who controls the credentials used to authorize transactions.
  • In the self-custody model described by SEC staff, the user controls and is responsible for the private keys and recovery material needed to access the user’s crypto assets.
  • A custodial arrangement involves a third party managing access to private keys on the customer’s behalf; processes and customer access depend on the specific arrangement and terms.
  • A wallet generally manages private keys or passcodes used to access and authorize crypto assets rather than storing the assets themselves.
  • Wallet labels do not establish a uniform signing, recovery, or access design. Verify technical documentation and, where applicable, provider terms.
  • The operational fit depends on requirements and implementation-specific evidence; the general definitions do not establish that one model is universally superior.

Sources and references