What is a non-custodial wallet?
A non-custodial wallet is an arrangement in which a service provider does not hold the user’s signing keys or equivalent unilateral authority to authorize account activity on the user’s behalf. The user controls the key, combination of keys or account policy required for authorization. Self-custody and self-hosted wallet are often used for closely related arrangements, but the labels should not replace an examination of ordinary signing, policy changes and recovery powers.
Non-custodial describes an authority relationship, not a screen layout or device category. A browser extension, mobile app, hardware device, multisignature setup or smart account can all be non-custodial if the actual authorization and recovery powers support that description.
Authorization can be a key, several keys or contract logic
In a conventional key-controlled wallet, software prepares a transaction and the user’s signer produces a signature. The provider may supply an interface, network endpoint or transaction relay, but cannot produce the required signature by itself.
That one-key model is not universal:
- a multisignature account may require a threshold of several keys;
- a smart-contract account may enforce spending limits, session keys or recovery conditions;
- a distributed signing design may split authorization across devices or participants; and
- a managed recovery design may give another party limited powers without giving it ordinary spending authority.
Ethereum illustrates the distinction between externally owned accounts, which are controlled by private keys, and contract accounts, which are controlled by code. ERC-4337 account abstraction also allows an account to define how an operation is validated rather than requiring every account to use the same single-key rule. A non-custodial smart account therefore may not map to “one user, one private key,” provided no provider retains unilateral transaction or takeover authority. Ethereum accounts and ERC-4337
How to assess control instead of relying on the label
The useful questions are operational:
- Who can create the signatures or approvals required for an ordinary transaction?
- Can a provider block, replace or independently authorize an action?
- Who can change signers, upgrade account logic or alter a policy?
- Which parties can recover the account after a key is lost?
- Is there an emergency, guardian or administrative path with broader authority?
Control is not always all-or-nothing. A provider may be unable to spend in normal operation but hold one key in a recovery threshold. A smart contract may use a user-controlled signer policy yet remain upgradeable by an administrator. If that administrator can unilaterally replace the user’s authority or redirect assets, the non-custodial label may not describe the effective control model. These details should be disclosed and evaluated separately rather than compressed into the label.
NIST distinguishes self-hosted wallets, in which users retain control of private keys, from custodial wallets, in which an external entity stores keys and manages transactions. It also describes hybrid models, reinforcing that the actual key-management and transaction process matters. NISTIR 8301
Third-party infrastructure does not automatically mean custody
A non-custodial wallet may depend on third parties for:
- blockchain RPC access and balance indexing;
- fee estimation and transaction simulation;
- application interfaces and software distribution;
- transaction broadcasting or relaying;
- token lists, contract metadata and risk warnings; or
- optional recovery participants.
These dependencies can affect availability, privacy and the information shown to a signer. They do not necessarily give the provider authorization power. Conversely, a service can look like an ordinary app while retaining the keys and signing for users; a familiar interface does not make it non-custodial.
Ethereum’s wallet documentation defines wallets as applications that provide control over accounts and emphasizes that a wallet is not the account itself. This helps separate the user interface from the underlying authorization model. Ethereum wallets
Recovery is part of the custody analysis
Some non-custodial wallets use a recovery phrase. Others rely on several devices, trusted participants, hardware-backed credentials or smart-contract rules. Each design creates different powers and failure modes.
If a provider cannot reconstruct or replace the user’s authorization, a conventional “forgot password” process cannot recreate a missing private key. An app password may only unlock local encrypted storage. However, a wallet with contract recovery or a multi-party recovery policy may restore access without reproducing the original key. That does not automatically make it custodial; the answer depends on whether another party can act alone and what authority the recovery mechanism grants.
The recovery phrase, passphrase, signer set, policy configuration and account metadata can be separate pieces of the recovery state. Backing up only one item may not restore the intended account.
Non-custodial control does not make each action safe
Keeping authorization under user control removes one provider-held signing path, but it does not validate software or transaction intent. Relevant risks include:
- phishing and fake wallet applications;
- malware or a compromised browser extension;
- malicious contract approvals or unreadable signing data;
- wrong addresses, networks or fee settings;
- exposed or incomplete recovery material; and
- loss or compromise of another signer, guardian or upgrade authority.
A provider’s inability to sign does not, by itself, give that provider power to reverse an already confirmed blockchain transaction. Account-specific recovery or upgrade rules may change future authority, but they do not turn a support password reset into a universal transaction-reversal mechanism. Recovery secrets should not be disclosed merely because someone claims to provide support. Ethereum’s security guidance treats phishing, recovery-secret exposure and malicious transaction requests as separate threats. Ethereum security
FAQ
Does non-custodial mean no third parties are involved?
No. Software distribution, network access, relayers and recovery participants may still be provided by third parties. The term concerns authorization control; it does not promise that every dependency is operated by the user.
Is every non-custodial wallet hot or cold?
Neither. Non-custodial describes who controls authorization, while hot and cold describe connectivity. The signer can be online, offline or split across components.
Can a wallet be non-custodial if another party helps recovery?
Possibly. The answer depends on the recovery policy. Assistance that cannot unilaterally authorize or take over an account differs from a provider-held reset key that can independently replace the user’s authority.
Learn more
For broader background, see The Rise of Non-Custodial Wallets. It is supplementary reading; the authority and recovery distinctions in this glossary entry are based on standards and official technical documentation.
Related concepts
Explore crypto wallets, hardware wallets, hot wallets and private keys, or return to the Crypto Glossary.
Sources
- NISTIR 8301: Blockchain Networks — Token Design and Management Overview — self-hosted, custodial and hybrid wallet models.
- Ethereum: wallets — wallets as account interfaces and wallet format distinctions.
- Ethereum: accounts — key-controlled externally owned accounts and code-controlled contract accounts.
- ERC-4337: Account Abstraction Using Alt Mempool — account-defined operation validation and smart-account execution.
- Ethereum: security — recovery-secret, phishing and malicious-transaction risks.
- Bitcoin Developer Guide: wallets — separable transaction, network, key-storage and signing functions.
© 2025 OKX. Este artigo pode ser reproduzido ou distribuído na sua totalidade, ou podem ser utilizados excertos de 100 palavras ou menos deste artigo, desde que essa utilização não seja comercial. Qualquer reprodução ou distribuição do artigo na sua totalidade deve indicar de forma clara: “Este artigo é © 2025 OKX e é utilizado com permissão.” Os excertos permitidos devem citar o nome do artigo e incluir a atribuição, por exemplo, "Nome do artigo, [o nome do autor, caso aplicável], © 2025 OKX." Alguns conteúdos podem ser gerados ou ajudados por ferramentas de inteligência artificial (IA). Não são permitidas obras derivadas ou outros usos deste artigo.








