Non-Custodial Is a Deployment Property
“Non-custodial” is less of a feature you can buy. And more of a property of how a wallet system is deployed, and the same product can satisfy people’s definition of non-custodial in one configuration and violate it in another. Vendors who don’t acknowledge this are selling a label that may describe a technical system that relieves them of liability (allows them to claim non-custodial), but promote an integration mode that allows for unilateral signing.
The regulatory definitions all use one axis. FinCEN, FATF, and MiCA each define a wallet as non-custodial when the user holds their own private keys and no third party can move funds without the user. That definition was written before MPC, before TEE-resident keys, before sharded credentials, and before the server-side signing market existed. It assumes a binary: either you hold a key, or someone else does. It has no language for systems where a key is split into shares, encrypted at rest in someone else’s database, or held inside an attested enclave behind a credential check.
Modern wallet products don’t fit the binary, the space in-between is where the marketing lives.
What the test should be
“Who holds the key?” is the wrong axis. It catches one of three ways custody manifests and lets the other two through.
Custody has two faces. Safety: can someone else move the asset? Liveness: can someone else stop the user from moving it? A definition that ignores liveness lets any vendor with a kill-switch self-certify as non-custodial. A definition that ignores the dependency graph - the services whose disappearance would strand the user - misses the same problem from a different angle.
A wallet is non-custodial only if all three hold:
- No third party can cause a transfer. This includes parties who can replace the signer entirely - proxy admins, upgrade keys, social-recovery quorums acting outside the user’s intent. Replacement attacks pass any test that asks only about credentials, because replacement is not production.
- No third party can prevent a transfer indefinitely. MPC co-signers who refuse, paymasters who gate, contracts with pause roles, RPC monopolies. They are custodians by way of liveness. They never need to touch the asset.
- No third party’s disappearance can strand the user. If the vendor going dark makes funds unspendable, the vendor was always a custodian. They just wore service-provider clothing.
The one-line version: non-custodial means the user is the only single point of failure. Any other party whose action or inaction can move, freeze, or strand the asset is a custodian, regardless of which side of the cryptographic boundary the bytes sit.
This collapses MPC, smart-contract wallets, social recovery, and EOAs into one framework. The three questions are the same. The cryptographic primitives change which parties have which powers. They do not change the test.
Five questions to ask before integrating a wallet vendor
If you are picking wallet infrastructure, the cryptographic protocol is the least important thing to evaluate. The questions that determine your actual custody posture are:
- Who can authorize a transfer, or replace the user’s signer, beyond the user themselves? Signers count. So does anyone who can replace them - upgrade keys, admin roles, recovery quorums, co-signer shares. “User share encrypted in our database” is not a credential held by the user. It is a credential held by you, in a wrapper.
- Can your application server unilaterally initiate signing, and can the vendor unilaterally refuse it? If yes to either - even if the cryptographic ceremony involves the vendor’s infrastructure - you are custodial. Initiation breaks safety. Refusal breaks liveness. The ceremony does not save you from either.
- If your application environment is fully compromised, what can the attacker sign? Everything? Nothing? Something bounded by a policy enforced outside the compromised environment? The answer is your actual security posture, not your aspirational one.
- Where does the custody liability sit, and does the vendor’s marketing match your legal reality? The vendor’s “non-custodial” claim describes the vendor. It may not describe you. Read the contract, then read your AML obligations.
- Can the end user exit the system? If the wallet cannot be exported back to standard self-custody without exposing a platform-wide credential, your users are structurally locked into your custody.
If the answers describe a custodial system, you are running a custodial system - regardless of which cryptographic primitives the vendor sells you on.
The longer argument
The Custody Illusion works through the case in detail, using one MPC vendor (Para) and one TEE vendor (Turnkey) as worked examples. Both market non-custodial guarantees. Both ship documented patterns where, once adopted by integrators building for server-side signing, those guarantees do not hold.
The pattern is not vendor-specific. Any wallet infrastructure with a server-side mode for AI agents, automated workflows, or batch operations will face the same configuration question, and most will answer it the same way: externalise custody to the integrator while preserving the vendor’s non-custodial claim. If you are evaluating one of these products, the cryptography is the wrong place to look.