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
Delegated access lets your server perform wallet operations (signing messages) on behalf of users with their permission. This is useful for automating workflows while maintaining security through user-approved delegation. This guide covers the server-side implementation using the Rust SDK. For conceptual background, see Delegated Access Overview.Prerequisites
- A Dynamic environment with embedded wallets (MPC) enabled
- An RSA private key registered with Dynamic for webhook decryption (PEM-encoded PKCS#8)
- Access to delegated shares, wallet API etc. via Delegated Access
How Delegation Works
- User approves delegation request in your application (client-side).
- Dynamic sends an encrypted webhook to your server containing:
walletId— the user’s wallet IDencryptedWalletApiKey— wallet-scoped API key for outbound signing requests, RSA-OAEP-wrapped + AES-GCM encryptedencryptedShare— the customer-side MPC share, encrypted with the same envelope
- Your server decrypts both fields with your RSA private key.
- Your server stores the credentials securely (vault).
- Your server uses these credentials to sign on behalf of the user via
DelegatedEvmWalletClient.
Decrypting the Webhook Payload
DecryptedWebhookData has a custom Debug impl that redacts both fields — safe to include in tracing spans.
The envelope is RSA-OAEP-SHA256-wrapped AES-256-GCM (alg = "HYBRID-RSA-AES-256"). The SDK also accepts legacy "RSA-OAEP" for backward compatibility.
Creating the Delegated Client
Configuration Options
Signing Messages
The delegated client takes the same arguments as the org-token EVM client. Build aWalletProperties using identity from the webhook payload and the decrypted share:
Revoking Delegation
When a user revokes consent (or your server detects misuse), callrevoke_delegation on the base delegated client:
sign_message calls will fail with Error::Auth.
Security Considerations
Credential Storage
- Never log or expose delegation credentials (wallet API key, key share). The SDK redacts them in
Debugoutput; mirror that in your own code. - Store credentials encrypted at rest in your database (envelope encryption via cloud KMS recommended — see Storage Best Practices).
- Use secure environment variables for the RSA private key. Load it from AWS Secrets Manager / GCP Secret Manager / Vault, not
.env. - Implement credential rotation policies — revoke wallet API keys when no longer needed.
Defense-in-Depth Skeleton
Related
- Delegated Access Overview — conceptual background and flow diagram
- Solana Delegated Access