nestonexStart a project What makes a product non-custodial, and what does that remove from your risk?
A product is non-custodial when it cannot move a user's funds without that user's key, and cannot reconstruct the key on its own. It removes the ability to be compromised into moving funds, and removes you from a category of financial regulation. It does not remove your obligations around recovery, phishing or the interface.
Can your system, acting alone, move a user's funds? If the answer is yes under any circumstance — an admin function, a recovery flow, a backup of the key material, a signing service — the product is custodial, whatever the marketing says.
This matters because custody is the question regulators, insurers and attackers all ask. It determines which licences may apply, what an incident looks like, and whether a breach of your infrastructure is embarrassing or catastrophic.
The intermediate cases are where the honest answer takes work. Key shares split between the user and a service, recovery through a third party, hardware-backed enclaves: each has a specific answer to 'who can move funds alone', and that answer belongs in the architecture document rather than in the pitch.
The useful framing during discovery is not 'are we non-custodial' but 'list every path by which funds can move, and say who has to participate in each'. That list is short, checkable, and ends most arguments.
It removes the single most attractive target in the system. A backend that cannot move funds is not worth compromising for funds, which changes the threat model substantially.
It removes a class of insider risk. No employee can be coerced or bribed into a transfer that the architecture does not permit.
It does not remove phishing. Users are still persuaded to sign transactions they did not understand, and that is now the primary attack — which makes the clarity of your signing interface a security control, not a design preference.
It does not remove recovery obligations. A user who loses their key has lost the funds, and 'not our problem' is a product decision with real consequences for support, reputation and who is willing to use the thing.
And it does not remove all regulation. Depending on jurisdiction, providing the interface, the routing or the fiat on-ramp can carry obligations regardless of custody. That is a question for a lawyer in the relevant market, not for an architecture diagram.
An embedded wallet is created and held for the user inside the application rather than in a separate browser extension, which removes the seed-phrase step that loses most new users before they start.
Whether it is non-custodial depends entirely on the key handling underneath. If the key material is derived and held such that the service cannot reconstruct it alone, the product is non-custodial with a much better onboarding story. If the service can reconstruct it, it is custody with a friendlier interface.
The feature that distinguishes them in practice is export. A wallet the user can export and walk away with is genuinely theirs. One they cannot leave is an account, and should be described as one.
Gating export behind two-factor is the right compromise: it is the highest-risk action in the product, and making it deliberate is not the same as making it impossible.
Every state change needs the user. No background rebalancing, no administrative correction, no 'we will fix it on our side'. Flows that assume a server can act unilaterally have to be redesigned around a signature.
Automation needs a different shape. An agent or a scheduled strategy cannot simply be given the key; it gets a bounded set of validated actions the user has authorised, with the same checks as a manual request.
And the interface carries more weight than in a custodial product, because the user is the last line of defence. What does this transaction do, what does it cost, what is it approving, and what happens if it fails — all of that is now safety-critical copy.
Wen runs on embedded wallets, so the backend never holds a private key at any point. The in-app AI agent cannot move funds directly either — it calls typed, validated tools that pass the same checks as a tap in the interface. Key export exists, gated behind two-factor.
Gaya Wallet applies the same model across sixteen chains, quoting six aggregators in parallel for a best route and executing through a per-user sequencer inside a database transaction. The user holds the keys; the backend holds the routing, the sequencing and the correctness.
It depends on the key handling, not on the label. If the service cannot reconstruct the key on its own and the user can export it and leave, it is non-custodial with better onboarding. If the service can reconstruct it, it is custody with a friendlier interface, and should be described that way.
No. It removes one significant category of obligation in many jurisdictions, and others can still attach to providing the interface, the routing or a fiat on-ramp. It is a question for a lawyer in each market you operate in, not one an architecture decision settles.
Yes, if it proposes rather than decides. The model turns a request into a typed intent, and that intent passes schema validation, policy limits and whatever authorisation a manual request would need. The agent chooses among actions the user authorised; it never holds the key.
The funds are unrecoverable, which is the trade for the guarantees. Products soften this with social or multi-party recovery, each of which reintroduces a party who can participate in moving funds — so the recovery design is where the custody question has to be asked again.