Control begins with the signer
A non-custodial application asks your wallet to sign messages or transactions. The application does not receive the wallet’s private key.
An embedded email wallet can also be non-custodial when signing occurs in secure wallet infrastructure and the user can export the key.
Delegated trading keys
A delegated key can authorize a narrower set of actions, such as placing orders on one venue, without exposing the wallet’s master key for every trade.
The exact permissions and revocation process are defined by the venue. A delegated key should not be treated as harmless simply because it is not the main wallet key.
What non-custodial does not eliminate
Self-custody does not remove market losses, liquidations, contract bugs, oracle failures, frontend compromise, malicious approvals, or execution-provider insolvency and operational risk.
It changes who can authorize asset movement; it does not make every authorized action safe.
A signing checklist
Pause when a prompt does not match the action you intended.
- Confirm the network and contract or venue.
- Read the asset and allowance being approved.
- Be cautious with unlimited token approvals.
- Reject unexpected prompts and reconnect from a trusted URL.
- Protect recovery methods and never share a seed phrase.
Self-custody changes authorization, not every dependency
A user-controlled signer can prevent an interface from unilaterally moving assets, but a valid signature can still authorize an unsafe contract call, broad token allowance, delegated trading key, or malicious message. The Ethereum Foundation’s clear-signing work focuses on making the consequences of approvals human-readable because blind confirmation remains a major failure point.1
Smart contracts may also be upgradeable or controlled by governance, multisignature accounts, or timelocks. Those controls can improve incident response but create additional trust assumptions. Review upgrade authority, withdrawal paths, and provider status separately from wallet custody.24