When a wallet integration is described as “non-custodial,” the useful engineering question is not whether the label applies. It is: who can move the assets, under what conditions, and who must cooperate to end that access?
That framing exposes distinctions hidden by a binary label. An app may never possess a user’s root key while still operating a delegated signer that the user cannot directly disable. Another system may split key material across several parties, none of which can act alone. Both may call themselves non-custodial, but their failure modes are different.
Here is a practical spectrum, ordered from stronger to weaker unilateral user control. Lower positions are weaker specifically in the user’s ability to exclude other parties without their cooperation. They may still offer better recovery, automation, or support.
1. A plain externally owned account
With a plain EOA, one private key controls the account.
Who can move assets? Anyone with that private key.
Who must cooperate for third-party access to end? No third party has access unless the key was shared or compromised. If it was compromised, access cannot be selectively revoked. The user must move assets to a new account.
This model is simple to reason about, but unforgiving. There is no native permission scoping, spending limit, signer expiry, or recovery process. Automation usually means exposing the key to software that must remain available, which undermines the reason for choosing the model.
An EOA provides strong independence from operators, not necessarily strong operational security.
2. A smart account with a user-revocable permission
A smart account can let an owner authorize another key to perform a restricted set of actions. The restriction might cover certain contracts, tokens, methods, time periods, or spending amounts.
Who can move assets? The owner and any signer accepted by the account’s current contract logic, each within whatever rules that logic enforces.
Who must cooperate for delegated access to end? If the owner can submit an on-chain transaction that disables the permission, no operator needs to cooperate. The owner does need the chain to include that transaction and must retain whatever authority the account recognizes as its owner.
This is a meaningful improvement for automation because revocation is independently verifiable and user-initiated. It also adds contract risk. A bug in permission checks, upgrade logic, or account recovery can be more consequential than a broken user interface.
The important evidence is not a settings toggle. It is the contract path that removes the permission and proof that the user can call it without an operator signature.
3. A delegated session signer removed by the operator
Some embedded wallets support a secondary signer controlled by an application or its execution service. A policy may restrict what that signer can request.
Who can move assets? The user’s root authority can move assets, while the delegated signer can perform actions accepted by the wallet or signing provider’s policy.
Who must cooperate for delegated access to end? If no user-callable revocation path exists, the operator must remove its signer. A user who controls or can export the underlying wallet can instead move to a fresh wallet to eliminate residual access.
This model is useful for unattended execution because the user does not need to approve every action. It is weaker than unilateral smart-account revocation because cancellation and signer removal are separate events. A successful cancellation request may stop the application’s executor immediately while signer removal remains an operator-side, best-effort operation.
Policy placement matters too. An API policy enforced by a signing provider is not an on-chain permission. An executor check is not a wallet-level restriction. These controls may be useful, but documentation should identify the enforcing component and explain what happens if that component is unavailable or faulty.
4. Threshold MPC custody
“MPC wallet” describes a family of designs, not one custody model. In a threshold setup, several key shares participate in signing. The threshold and share holders determine the actual control structure.
Who can move assets? Any coalition that satisfies the signing threshold. Depending on the design, that might be the user plus a provider, several provider systems, or the user acting through multiple devices.
Who must cooperate for provider access to end? That depends on whether the user can rotate or replace shares without the provider. If resharing needs provider participation, ending provider access requires cooperation. If the user independently controls enough shares to authorize rotation, the answer is different.
MPC can support recovery and hide key-management complexity. It can also make authority difficult to inspect because the relevant policy lives in protocols, infrastructure, and contractual procedures rather than a public account contract.
Ask for the threshold, the share holders, the recovery path, and the share-rotation procedure. “We never reconstruct the key” does not answer who can authorize a signature.
5. An exchange account
In a conventional exchange account, the exchange controls the blockchain keys and maintains an internal ledger for customers.
Who can move assets? The exchange, through its signing infrastructure.
Who must cooperate for the user to withdraw or terminate access? The exchange must process the withdrawal. The user cannot independently move blockchain assets represented by an account balance.
This model can offer account recovery, customer support, transaction screening, and familiar authentication. Its trade-off is direct: the operator controls asset movement.
What to ask instead of accepting the label
For any automated wallet product, request concrete answers to these questions:
- Which keys or shares can authorize movement?
- Where is each restriction enforced: account contract, signing provider, executor, or user interface?
- Can the user disable delegated access without operator cooperation?
- Does authorization expire automatically?
- What happens if cancellation succeeds but signer removal fails?
- Can the user export the wallet or migrate assets without permission?
- Are policy changes auditable?
- Which controls remain effective if the application server is compromised?
Disclosure: I build Tradevo, software for describing a crypto strategy in plain English, compiling it into deterministic rules, testing and paper-trading it, submitting it for human review, setting a creator price, publishing approved strategies, and subscribing with a chosen allocation; execution uses a scoped and revocable delegated session signer attached to the user’s embedded wallet, while the token allowlist, per-subscription allocation cap, and slippage limits are enforced by the signing provider’s policy and the executor, the authorization does not expire by itself, cancellation stops execution and triggers best-effort server-side signer removal, and users can export their wallet for zero residual access.
“Non-custodial” is useful only as the start of an architecture review. The real boundary is who can sign, who can change the signing rules, and whether the user can exclude every other actor without asking for help.
Top comments (0)