What is a delegated wallet?
A delegated wallet is a wallet where your end user has full control, not your company. Think of it like giving someone the only key to a safe deposit box - you provide the box, but only they can open it. When you delegate a wallet:- Only your user can move funds or sign transactions
- Your company cannot access the wallet’s assets
- Your user proves ownership using biometrics (Face ID, fingerprint) or a security key
Why delegate wallets?
Clear signing authority
With delegated wallets, only the end user holds the credentials (passkey) required to sign transactions. Your organization cannot authorize transactions on their behalf, giving users verifiable proof that they alone control their wallet.User trust
Users have cryptographic proof that only they can use their wallet. Your company physically cannot move their assets without the user’s explicit approval via their passkey.Reduced liability
Since you cannot authorize transactions from delegated wallets, you reduce your exposure to internal threats targeting user assets.How it works
Architecture
Dfns uses distributed key generation and threshold signatures to secure wallets. Private key shares are encrypted and stored across a decentralized signer network spread across multiple data centers and geographic regions. The wallet private keys never leave Dfns infrastructure — they are not stored on the user’s device. The key insight is that the signing credential determines who can use the wallet. Authorizing a transaction requires both an access token and a signing credential (passkey). In a delegated configuration, the signing credential lives on your user’s device — meaning only they can authorize transactions.Dfns is a technical infrastructure provider. Regardless of the wallet model, Dfns secures the cryptographic key material in its MPC network. The difference between org-managed and delegated wallets is who holds the signing authority — your organization’s credentials or your end user’s passkey. “Custody” is a legal term with jurisdiction-specific meaning; consult legal counsel for your specific regulatory situation.
- Users authenticate with familiar biometrics instead of seed phrases
- If a credential is compromised, it can be revoked
- If a credential is lost, it can be recovered
Transaction flow
- User signs up - They register with your app and set up a passkey (biometric or security key)
- Wallet is created - Your system creates a wallet and delegates it to the user
- User transacts - When they want to send funds, they approve with their biometric
- You can’t intervene - Your company has no ability to approve or block their transactions
User experience
From your user’s perspective, delegated wallets feel like any modern app:- Sign up with email or social login
- Approve transactions with Face ID or fingerprint
- No seed phrases to write down or remember
- Can recover access if they lose their device
Recovery
Unlike seed-phrase-based wallets where loss means permanent loss of funds, delegated wallets support recovery:| Seed phrase (traditional) | API credential (Dfns) | |
|---|---|---|
| If lost | Funds lost forever | Can be re-established |
| If stolen | Funds stolen | Can be revoked |
| Backup method | Write down 24 words | Register multiple devices |
Recovery strategies
Your application should implement ways for end users to register additional credentials:- Same device - Users can add another passkey (e.g., a hardware security key) using their existing credential to sign the request. See how this works in the dashboard: Registering a new passkey credential.
- New device - Users can register a passkey on a different device using a time-limited registration code. See how this works in the dashboard: Onboarding a new device.
- Recovery credentials - Users store a recovery password securely offline, which can be used to register a new passkey if all other credentials are lost.
Trade-offs
| Delegated wallets | Organization-managed wallets |
|---|---|
| End user holds signing authority | Your organization holds signing authority |
| No spending limits or approval workflows | Policies can restrict transactions |
| User responsible for recovery | You can help users recover access |
| Only the user can authorize transactions | Your team authorizes transactions |
When to use delegated wallets
Good fit:- Consumer apps where users expect to control their assets
- Regulatory environments where signing authority matters
- Products where user trust and transparency matter
- Treasury or operational wallets
- Scenarios requiring spending limits or multi-approval
- When users expect you to help if something goes wrong
White-labeling
Delegation allows you to provide Dfns wallet infrastructure without exposing Dfns to your users. Your backend registers and logs in users to Dfns on their behalf. Users only interact with your app and your brand - no Dfns emails, no Dfns branding. When users need to sign transactions, your app prompts them for their passkey directly.End users are first-class citizens in Dfns. Once registered, they could use the Dfns APIs directly if they access their auth token. Carefully review your policies and controls.
Learn more
- End-user wallets solution - Implementation overview
- Implementing delegated wallets - Step-by-step developer guide
- End-user recovery - Implementing recovery