The balance shown in a crypto app is not the authority that moves funds. The relevant boundary is who holds the signing key and who processes a withdrawal.
Custodial flow: account request, platform processing
A cryptocurrency exchange is primarily a place to buy, sell, and trade digital assets. Centralized crypto exchanges also let customers leave purchased assets in their accounts, so an exchange can gradually become a place where people keep cryptocurrency between trades.
In this custody model, the service controls the private keys. A customer signs in, sees an account balance, and can request a withdrawal, but the platform processes that request through its own systems. Access to an account and control of the keys are not the same thing.
The distinction becomes concrete when you withdraw crypto. If BTC or USDT is held on a centralized exchange, you submit a withdrawal request and the platform handles the operation under its procedures. You control the account, but the private key used to sign the on-chain transaction is not in your possession.
That does not make crypto exchanges inherently bad tools. Their central purpose is to let people buy, sell, and exchange assets. The separate question is whether cryptocurrency that you are not currently trading needs to remain there.
Non-custodial flow: owner-controlled signing
A non-custodial crypto wallet uses a different model. The wallet owner controls the private key, which is used to sign transactions. A seed phrase can restore access to the wallet.
With your own crypto wallet, sending cryptocurrency does not require you to hand a withdrawal request to a separate custodian. The transaction is signed with the owner's key. This is what people mean by self-custody: control over the keys stays with the user rather than with an exchange or wallet company.
When choosing a crypto wallet, this is one of the first things worth checking. You can compare supported coins, interface, fees, and features, but first find out who controls the private keys. An app may look like an ordinary online crypto wallet while the company actually holds the keys. Conversely, a familiar interface does not by itself prevent a wallet from being non-custodial.
Consider what happens when you send Bitcoin to another person. With an exchange account, the platform processes your withdrawal. With a non-custodial wallet, the wallet signs a transaction using a key controlled by its owner. Both may show a similar balance, but responsibility for authorizing the transfer is different.
The trade-off is control versus recovery responsibility
The key difference is not simply where crypto appears on a screen. It is who can authorize movement of the assets and who is responsible for access recovery.
An exchange account can be convenient for buying, selling, and trading. The customer relies on the platform to maintain account access and process withdrawals. That convenience comes with dependence on the service and its procedures. This description is about the custody model, not a claim that every exchange behaves identically or that a particular outcome is guaranteed.
A non-custodial wallet gives the owner direct control of the keys. It also puts more responsibility on that owner. A seed phrase must be protected, and the user needs to understand how to restore access if a device is lost or replaced. If the recovery information is lost, the wallet provider cannot simply retrieve the owner's private key on their behalf.
“Cold wallet” is another term people encounter when comparing storage options. It generally refers to keeping key material offline, rather than to a different kind of cryptocurrency. Whether a wallet is custodial or non-custodial is a separate question from whether its keys are kept online or offline. Do not infer who controls the assets from the label or appearance of a device or app.
These are different trust and responsibility models, not a universal ranking. An exchange processes account withdrawals under its procedures. A non-custodial wallet leaves signing authority with the owner, who must also protect recovery information.
How DARCA approached self-custody and recovery
When we built the DARCA crypto wallet, we chose a non-custodial model and separately considered the problem of restoring access. We did not want the experience to begin by requiring users to write down a seed phrase at first launch and then figure out on their own where to keep it.
In DARCA, keys are created and opened on the owner's device. By default, the seed phrase is not shown to the user. It is encrypted on the device, and the server receives an encrypted backup. DARCA's server does not receive the seed phrase in plaintext, the private keys, or a ready-made decryption key.
The owner can still access the standard BIP-39 seed phrase and use it to restore the wallet in another compatible solution. This matters for a non-custodial crypto wallet because access to assets should not depend solely on one particular app continuing to exist.
This design does not turn a self-custody wallet into a cryptocurrency exchange, and it does not remove the owner's responsibility to protect recovery access. The aim was narrower: keep control of the keys with the owner while reducing some of the friction that can make independently storing cryptocurrency difficult for people who do not want to manage every technical detail themselves.
Questions to ask about the signing boundary
Buying and trading are distinct from deciding how to hold assets. The same BTC or USDT can appear in two apps even though one relies on platform-processed withdrawals and the other on owner-controlled signing.
For a wallet design, inspect who can authorize a transaction, what recovery data reaches the server, and whether the owner can restore the wallet in another compatible solution. In DARCA, keys are created and opened on the owner's device; the server receives an encrypted backup, not the plaintext seed phrase or private keys. The owner can still retrieve the standard BIP-39 phrase. This does not remove the need to protect the device and recovery information.
Which part of a wallet's trust boundary would you inspect first: signing, recovery, or server-side data?
Top comments (0)