Overview
Two related pieces of wallet lifecycle live on the base DynamicWalletClient:
updatePassword — Rotate the password protecting the wallet’s backup. Local re-encrypt only, no MPC ceremony.
- State predicates —
isPasswordEncrypted, requiresPasswordForOperation, requiresRestoreBackupSharesForOperation. Pure-local static helpers that tell you what inputs the next operation will need.
Use the predicates in UI code to decide whether to prompt the user for a password or trigger a backup-shares recovery before the underlying signing / export call. Use updatePassword to rotate the AES-256-GCM password that wraps the backup shares Dynamic stores on your behalf.
State Predicates
All three predicates are pure-local — no MPC, no network. They inspect the WalletProperties.externalServerKeySharesBackupInfo field and return a boolean.
WalletOperation enum
The operation argument is one of:
SIGN_MESSAGE / SIGN_TYPED_DATA / SIGN_TRANSACTION / SEND_TRANSACTION
EXPORT_PRIVATE_KEY
REFRESH / RESHARE
UPDATE_PASSWORD
The predicates encode the minimum input the SDK will demand for that operation given the wallet’s current state — feed them into your UI gating so users only see the password prompt when it’s actually required.
Use in UI Gating
Rotate the Backup Password
updatePassword is a local re-encrypt only (no MPC ceremony). It decrypts the existing backup shares with existingPassword, re-encrypts with newPassword, and POSTs the new ciphertext. The MPC secret-share material inside the shares is unchanged — only the AES key wrapping it.
Skipping the recovery round-trip
When the caller already has plaintext externalServerKeyShares cached client-side, existingPassword can be omitted — the SDK skips the recovery round-trip entirely:
This is the common case for active wallets that have cached shares — pay the recovery round-trip only when shares have been evicted.
Why Both Predicates and updatePassword Are Local
Both fall in the same conceptual bucket: the SDK already has everything it needs to answer / perform them client-side, so there’s no MPC ceremony involved. This matters for:
- Throughput — no Dynamic backend round-trip on the hot path (predicates)
- Recovery —
updatePassword works the same in disaster scenarios as it does in steady state
- Cost — no MPC compute consumed for a password rotation
The trade-off is that you must hold the existing password (or plaintext shares) to call updatePassword. If both are lost, the wallet’s MPC shares are recoverable only through the standard refresh / reshare flows (not yet exposed in v0.1.0).
Next Steps
Last modified on May 25, 2026