An application balance is an interface state, not a complete description of control. A user can see Bitcoin or Ethereum, send it and exchange it while the platform operator controls the keys required to authorize the underlying operations.
The control boundary
Cryptocurrency transactions are recorded on a blockchain. A wallet does not contain the assets. It manages cryptographic keys that authorize changes to the state recorded by the network.
That gives us two different architectures:
- In a custodial model, the service controls the operational secrets and signs or coordinates transactions for the user.
- In a non-custodial model, the owner controls the keys and the service must not have sufficient data to sign operations independently.
The UI can look identical in both cases. The failure modes are different. Custodial users depend on account access and the operator's availability. Self-custody users retain the signing authority, but recovery, device security and transaction correctness become their responsibility.
What self-custody does and does not solve
Self-custody reduces dependence on an intermediary. It does not solve phishing, malware, a compromised endpoint, disclosed recovery material or an incorrect destination address. It also removes the assumption that support can reset every lost secret.
That trade-off should be explicit in the threat model. The question is not whether self-custody is "safe" in the abstract. It is which actor can obtain which data after a particular component fails, and what that data authorizes.
DARCA's boundary
DARCA uses a non-custodial model. Wallet keys are created and opened on the owner's device. DARCA should not receive the secrets required to sign the owner's operations independently.
The product constraint is to preserve that boundary without making every normal interaction a manual blockchain procedure. Users still need to protect their device and access data, verify the recipient and network before a transfer, and understand recovery before depositing a significant amount.
This is also why a backup must be evaluated carefully. A server can store an encrypted package without having every value required to open it independently. Authentication and access to wallet secrets are separate concerns; a successful account login should not automatically mean that the server can use the assets.
The practical evaluation
When comparing wallets, inspect the control boundary instead of counting features:
- Who creates and opens the keys?
- Can the provider sign without the owner?
- What exactly is stored on the server?
- What is the recovery path?
- Which operations are irreversible?
There is no defensible "most secure wallet" claim without a defined comparison. A useful wallet explanation states the mechanism, the threat model and the remaining limitations. Self-custody is a control model, not a guarantee that no component can be compromised.
Recovery is part of the threat model
Recovery is not merely a user-experience feature. It is part of the key-management architecture. The relevant question is not whether a backup exists, but what it contains, where decryption happens and which party holds the values needed to complete that process.
An encrypted package on a server can support availability without giving the server independent authority, but only if the separation remains true under the authentication flow. A successful login should not automatically mean that server-side code can open wallet secrets or sign transactions.
Operational failure modes
Evaluate more than a database breach. Consider a compromised phone, a malicious browser extension, a phishing page, a copied destination address, a forgotten password and an unavailable service. Each scenario exposes a different part of the system.
A sound interface should make the destination and network visible before an irreversible operation is authorized. The architecture should also state what remains outside its protection. These are engineering constraints that can be tested and documented, not marketing adjectives.
Keeping keys with the owner does not require turning every transaction into a cryptography lesson. The application can remove unnecessary details from routine flows while preserving the user's ability to inspect what is being authorized. That is a usability decision with a security consequence: fewer routine mistakes without moving signing authority back to the provider.
Separating availability from authority
An engineering design should distinguish the data needed to make the application available from the data needed to sign a transaction. A server may store an encrypted backup and account metadata. That does not automatically mean that server-side code can open the wallet or authorize a transfer.
The distinction has to survive real flows. Login verification, backup retrieval and local decryption should not collapse into one server-side permission. If a successful authentication session gives the backend everything required to use the assets, the system has a different custody boundary from the one described to the user.
User errors are also system inputs
The threat model should include ordinary behavior. Users copy addresses from chats, install software from search results and mistake a convincing support message for a legitimate one. A design can reduce exposure by keeping recovery material out of routine screens and by making the destination and network visible before authorization.
That does not eliminate the need for user judgment. It defines where the product can help and where it cannot. The owner still controls the device, the access data and the decision to sign.
What a technical explanation should promise
The strongest wallet explanation is testable. It says which secrets exist, where they are created, which components receive encrypted data, what an attacker gains from a server compromise and what happens when a device is replaced. It also names the limits.
For DARCA, the intended boundary is straightforward: the owner retains control of the keys, the service should not sign independently, and routine use should not require unnecessary exposure of technical secrets. That is a narrower claim than universal safety, but it is one an engineering team can reason about.
What should engineers verify before calling a crypto wallet non-custodial?
Top comments (1)
"the UI can look identical in both cases, the failure modes are different" is the bit most users only find out on recovery day. nice clear explainer