Documentation Index
Fetch the complete documentation index at: https://www.dynamic.xyz/docs/llms.txt
Use this file to discover all available pages before exploring further.
Overview
This guide walks you through creating EVM wallets using Dynamic’s Rust SDK. You’ll learn how to set up different threshold signature schemes and understand the security implications of each choice.Prerequisites
Before you begin, make sure you have:Step 1: Choose Your Security Model
Dynamic supports two threshold signature schemes, each offering different security and availability trade-offs:TwoOfTwo (Recommended for most use cases)
- Security: Highest — requires both your server and Dynamic’s infrastructure
- Availability: Lower — both parties must be online
- Use case: High-value transactions, maximum security
TwoOfThree
- Security: High — requires 2 out of 3 shares
- Availability: Medium — can tolerate one party being offline
- Use case: Balanced security and availability
Step 2: Choose Your Backup Mode
Every call tocreate_wallet_account returns a Vec<ServerKeyShare> — the customer-side half of the MPC key. You always vault this share in your own infrastructure for day-to-day signing; the chain clients in 0.0.3 require it as an explicit argument on every sign / export call.
The back_up_to_dynamic flag controls whether Dynamic also keeps an encrypted copy for disaster recovery:
back_up_to_dynamic: true (recommended)
The SDK encrypts your share with password (AES-256-GCM) and uploads the encrypted blob to Dynamic’s key share service. You still receive the share locally in the return value and still vault it yourself. If you ever lose your vaulted copy, you can recover it from Dynamic’s backup using run_recover_key_shares with the same password.
password is required when back_up_to_dynamic: true. The SDK rejects the call with Error::InvalidArgument if you pass None. The password never leaves your server — it’s used locally to derive an AES-256-GCM key that wraps the share before upload, and the same password is needed later to unwrap the recovered blob.back_up_to_dynamic: false
Dynamic does not store any copy of the share. You are the only holder. password is optional in this mode. Losing the share means permanently losing access to the wallet.
| Mode | Local vault | Dynamic backup | password at create | Disaster recovery |
|---|---|---|---|---|
back_up_to_dynamic: true | Required | Encrypted copy stored | Required | run_recover_key_shares + password |
back_up_to_dynamic: false | Required | None | Optional | None — share loss = wallet loss |
Step 3: Create Your First Wallet
Here’s a complete example of creating an EVM wallet:Step 4: Handle Errors
The SDK returnsdynamic_waas_sdk::Error. Match on the variants you care about:
Step 5: Persist WalletProperties and Vec<ServerKeyShare>
create_wallet_account() returns two pieces of state — each belongs in a different storage tier:
WalletProperties to every subsequent sign / export operation. See Storage Best Practices for the full pattern.
Best Practices
- Password Security — use strong, unique passwords per wallet; never log them
- Error Handling — match on
dynamic_waas_sdk::Errorvariants rather than string-matching - Tracing — the SDK uses
tracing::instrumentandskips sensitive args; mirror that in your code - Backup Strategy — if
back_up_to_dynamic: false, persist shares to a vault before returning success to the caller