When using delegated wallets, your end users control their own signing credentials. If they lose access to their device, they need a way to recover their wallet. This guide covers how to implement recovery flows.Documentation Index
Fetch the complete documentation index at: https://docs.dfns.co/llms.txt
Use this file to discover all available pages before exploring further.
Recovery credentials are encrypted private keys that Dfns stores as an opaque blob. The encryption happens in your frontend. Dfns never sees the decryption password. This means you own the full recovery experience: you decide the encryption scheme, the password format, and the recovery UX. The Dfns dashboard recovery flow at app.dfns.io/recover only works for users who registered their recovery credential through the dashboard.
Recovery strategies
| Strategy | How it works | Best for |
|---|---|---|
| Secondary credentials | User registers credentials on multiple devices | Users with multiple devices |
| Recovery credential | User stores a recovery password securely | Self-service recovery |
How recovery credentials work
ARecoveryKey credential uses an encryptedPrivateKey field - an opaque string that Dfns stores and returns to you. You implement the encryption, and the user keeps the decryption password.
Dfns stores the encrypted blob but never has access to the decryption password. Only the user can decrypt and use the recovery key.
Implementing user-held recovery
If implementing recovery in a browser without Node.js, use the @dfns/sdk-browser package for signing operations. If you must implement manually, see Base64Url encoding for correct encoding functions.
Generate a recovery keypair during registration
When a user registers, generate a recovery keypair and encrypt the private key with a password. This must happen on the client side - the password should never be sent to your server.
Frontend - Recovery credential generation
Display the recovery password to the user
Show the recovery password to the user with clear instructions:The user must store this password themselves. You should not store it.
Register the recovery credential with Dfns
Bundle the recovery credential into the same See Credentials Data for the exact To add a recovery credential after registration instead, use the Create Credential flow. The challenge then comes from
Complete User Registration (or Complete End User Registration with Wallets) call as the first passkey. The public key and encryptedPrivateKey are sent to Dfns. The password stays with the user.Which challenge to use. The RecoveryKey credential signs the same challenge returned by the registration init endpoint (Create Delegated Registration Challenge, Create Registration Challenge, or Create Social Registration Challenge). All credentials in the same registration call share that one challenge.Build the clientData for the recovery credential manually, since it is a key-style credential and not a Fido2 passkey:Frontend - Build clientData for the RecoveryKey
clientData and attestationData formatting rules. Incorrect stringification causes Unable to verify signature errors.Frontend - Include in registration request
Create Credential Challenge (or Create Credential Challenge With Code); the rest of the construction is identical.Implement the recovery flow
When a user needs to recover, all decryption happens on the client side:
Frontend - Recovery flow
Generate new recovery credentials
After recovery, all previous credentials (including recovery credentials) are invalidated. Always generate a new recovery credential and display the new recovery password to the user. Do not let the user leave the recovery flow without a fresh recovery credential in place.
Security considerations
- Password strength - Generate strong random passwords. Consider using word-based formats (like BIP39) for easier transcription.
- Clear user instructions - Users must understand the importance of storing their recovery password securely.
- Rate limiting - Prevent brute-force attempts on recovery flows.
Related
Account Recovery
Overview of recovery mechanisms for users.
Credentials Data
How to build Client Data and Attestation Data objects.
Create Delegated Recovery Challenge
API endpoint to initiate recovery for an end user.
Recover User
API endpoint to complete user recovery.
