Custodial vs Non-Custodial Wallets, Including for AI Agents
A custodial wallet is an account where a provider holds the keys and moves funds on your instruction. A non-custodial wallet keeps the signing keys with you or a device you control. Custodial trades key-management risk for provider risk: freezes, outages, insolvency. Non-custodial removes the provider and makes every signature your responsibility.
The one difference that decides everything else
Onchain funds move when a valid signature authorises a transfer. A custodial wallet means a company controls that signature. You hold a balance in its ledger and ask it to send; it decides whether and when. Exchanges, many payment apps, and most wallet-as-a-service APIs work this way.
A non-custodial wallet means the key lives with you: in a seed phrase, a hardware device, a passkey, or a protected store on a machine you control. The software builds and signs transactions, but no third party can move funds without that key.
Every other difference in the table below follows from this. Recovery is possible in custodial systems because the provider has the key. Freezes are possible for the same reason. Non-custodial wallets have neither property, because nobody else holds anything that can act.
Hybrids need a closer read
Threshold signing, keys split across a user device and a provider, and smart contract accounts with guardians all sit between the poles. The test is the same: can any single provider move funds, or block you from moving them, without your participation? If yes, treat it as custodial for risk purposes, whatever the marketing says.
How each one fails
Custodial failure modes are institutional. The provider can be hacked, go insolvent, freeze an account for compliance review, suspend withdrawals during stress, or simply be down when you need it. Your claim is against the company, not the chain. In exchange, a forgotten password is a support ticket, and an internal transfer sent to the wrong account inside the same platform can sometimes be reversed.
Non-custodial failure modes are personal. A lost seed phrase with no backup is permanent loss. A phished signature or a leaked key gives the attacker the same authority you have. Malware on the signing machine is the main threat. There is no support line that can reverse an onchain transfer, because settlement is final by design.
Neither is safe by default. They move risk to different places, and the right choice depends on which failures you can survive and which you can control.
What changes when an agent holds the wallet
An agent signs without a person reviewing each payment, reads untrusted input, and can repeat an action many times quickly. That reshapes both options.
Custodial for agents usually means an API: the agent calls an endpoint, and the provider signs. The agent never touches a private key, which sounds safer. But the API credential is now the key. Anything that can read the agent's environment can call that API exactly as the agent would. Provider-side spending controls help only if the same credential cannot change them.
Non-custodial for agents fails badly when done naively: a raw private key in an environment variable is one leaked log line away from a drained account. Done properly, the agent never holds the owner key. It holds a session key registered on a smart account, limited by a spending cap, allowed assets and recipients, and an expiry, all enforced by the account contract. A leak or a manipulated agent can lose only what the key's scope allows, and the owner can revoke it onchain.
CryptoCadet takes the second path: a non-custodial USDC rail on Base where the agent spends from a session-key-bounded float, and the session key sits in the OS keychain rather than in a config file.
| Dimension | Custodial | Non-custodial |
|---|---|---|
| Who signs transfers | The provider | You, or a device or account you control |
| Account recovery | Usually possible through the provider | Only through your own backups or recovery setup |
| Freezes and withdrawal limits | Possible at the provider's discretion | No third party can freeze the keys |
| Provider insolvency or outage | Funds at risk or inaccessible | Funds remain onchain under your key |
| Main attack target | The provider, and your login | Your key, seed phrase, or signing machine |
| Reversing a mistake | Sometimes, for internal transfers | Onchain transfers are final |
| Agent integration | API credential that acts as a bearer key | Scoped session key enforced by a smart account |
| Worst case if the agent is compromised | Whatever the API credential permits | Whatever the session key's limits permit |
Frequently asked questions
- What is the difference between a custodial and non-custodial wallet?
- In a custodial wallet a provider holds the keys and moves funds when you ask. In a non-custodial wallet you hold the keys and nobody else can sign. Custodial gives you recovery and support but exposes you to freezes, outages, and insolvency. Non-custodial removes the provider and makes key security entirely your job.
- Is a non-custodial wallet safer than a custodial one?
- It is safer against provider failure and less forgiving of your own mistakes. If you can protect a key or seed phrase well, non-custodial removes a whole category of institutional risk. If you are likely to lose backups or approve phishing signatures, a reputable custodian may lose you less. The answer depends on which failures you can control.
- Should an AI agent use a custodial or non-custodial wallet?
- Either can work, but each needs bounds. A custodial API makes the credential the key, so protect it and ensure the agent cannot change its own limits. A non-custodial setup should never hand the agent the owner key; give it a scoped session key with caps, allowed recipients, and expiry enforced by a smart account.
- Is an exchange account a custodial wallet?
- Yes. When you hold crypto on an exchange, the exchange controls the keys and your balance is an entry in its records. Withdrawing to an address you control moves the funds into non-custodial storage. That is why exchange withdrawals require choosing a network: the exchange is signing an onchain transfer on your behalf.