Skip to main content
If the user loses their password, they will lose access to their wallet. There is no way to recover the password or the wallet without it.
Password encryption adds an extra layer of security to embedded wallets by requiring a password to decrypt the user’s key share. This ensures that even if an attacker gains access to the stored key share, they cannot use it without the password.

How it works

When password encryption is enabled, it specifically protects the client-side key share:
  1. The user’s client key share is encrypted with their password.
  2. This encrypted share is sent through an encryption proxy which adds a second layer of encryption before storing it on Dynamic’s servers. This ensures the share is double-encrypted and accessible from any device.
  3. Operations like signing transactions require the password to decrypt this share once per session; after unlocking, the user is not prompted again until the next session.
  4. The password is never sent to Dynamic; decryption happens entirely client-side.
  5. No single party (Dynamic, encryption provider) can access the key share alone.

Requiring password for wallets

You can require all wallets to have a password in the Dynamic Dashboard:
  1. Navigate to Embedded Wallets.
  2. Toggle Require Password to enforce that all wallets must be created with a password.
When Require Password is enabled, a password must be provided when creating a wallet. Attempting to create a wallet without a password will return an error. Once the wallet is created and unlocked, it remains unlocked for the rest of the session—the password is not required for every operation.

Creating a password-protected wallet

Use the createWaasWalletAccounts method with a password parameter:

Creating a wallet with a developer-provided salt

You can supply the password yourself instead of collecting it from the user. This is useful when you want to encrypt a wallet with a password derived from a user or wallet specific salt that you control. Derive the password on your backend using a key derivation function such as PBKDF2, scrypt, or Argon2id, then pass the result to the SDK. The salt and the secret used for derivation must be the same every time you unlock the wallet.
For this pattern to add security, gate the endpoint that returns the derived password with your own authentication using Bring Your Own Auth. If you rely on Dynamic authentication instead, a Dynamic JWT alone is enough to fetch the password and decrypt the key share, which removes the extra layer that the password is meant to add.
The example below is illustrative. In production, derive the password inside a KMS or HSM (for example AWS KMS, Google Cloud KMS, or HashiCorp Vault transit) so no single service or environment variable holds a secret that can regenerate every wallet password. Store only the per-user or per-wallet salt in your database, never expose the derivation material to the browser, and remember that losing the salt or the key means the wallet cannot be unlocked.

Backend derivation example

Use the same derived password when you call unlockWallet later in the session.

Password management

  • Users set their own password during wallet creation
  • They must enter the password to unlock the wallet
  • Important: If the user forgets their password, wallet recovery is not possible without a backup.

Unlocking a wallet

Before performing operations with a password-protected wallet, unlock it using the unlockWallet method.
Once unlocked, the wallet remains unlocked for the rest of the user session (until logout). The user is only asked for the password once per session. Unlocking one wallet unlocks all wallets associated with the user account. As a result, all wallets for a user must share the same password.

Operations requiring password

Any operation that changes the underlying key shares requires the password to be provided again, even if the wallet is currently unlocked. These operations include:
  • Refreshing shares
  • Resharing (Cloud backup)
  • Delegation
This is because the new shares generated during these processes must be encrypted with the password before they are stored.
Dynamic’s UI does not prompt for the password during these operations. You must implement refresh, reshare (e.g. cloud backup), and delegation headlessly: obtain the password in your own flow and pass it programmatically into the SDK when triggering these operations. Do not rely on Dynamic to show a password field for share-changing operations.

Setting a password on an existing account

If a wallet was created without a password, you can add password protection later using setWaasWalletAccountPassword. This is useful when you want to enable password encryption for users who initially created their wallet without one.

Migrating existing wallets

Enabling Require Password in the dashboard only enforces password protection for new wallets. Existing wallets created before this setting was enabled remain unprotected. To migrate an existing wallet to password protection:
  1. Check if the wallet is already password-protected using getWalletRecoveryState.
  2. If isPasswordEncrypted is false, prompt the user for a password and set it using setWaasWalletAccountPassword.

Updating the password

Change an existing password using updateWaasPassword. This will update the password for all wallets associated with the user account.

Checking wallet lock state

You can check if a wallet is currently locked or ready to use with getWalletRecoveryState. This is more accurate than just checking if a password exists, as it tells you if the wallet is currently unlocked for the session.

Complete example

This example demonstrates how to check the wallet state, unlock it if necessary, and then sign a message.

Security considerations

Password-protected wallets are only as secure as the password itself. Enforce strong password requirements and educate users about password security.
  • Password strength: Require minimum length and complexity
  • No password recovery: If using user-provided passwords, there’s no way to recover a forgotten password without a backup.
  • Session-based unlock: Wallets remain unlocked for the session, reducing friction while maintaining security
Last modified on August 21, 2026