Skip to main content

Overview

Delegated access allows your server to perform Solana wallet operations on behalf of users with their permission. Dynamic sends delegation credentials to your webhook, and your server uses them to sign without the user being online. This guide covers the server-side implementation using the Python SDK. For conceptual background on the delegation workflow, see Delegated Access Overview.

Prerequisites

How Delegation Works

  1. User approves delegation in your application (client-side)
  2. Dynamic sends delegation credentials to your webhook:
    • walletId — the user’s wallet ID
    • encryptedWalletApiKey — temporary API key, encrypted with your RSA public key
    • encryptedDelegatedShare — the server key share, encrypted with your RSA public key
  3. Your server decrypts the credentials and stores them securely
  4. Your server uses the credentials to sign on the user’s behalf

Step 1: Decrypt the Webhook Payload

Dynamic encrypts delegation credentials with your RSA public key. The decrypt helper is chain-agnostic — the same function used for EVM works for SVM:
Store wallet_api_key and key_share encrypted in your database alongside the walletId.

Step 2: Create a Delegated Client

The returned client is an authenticated DynamicSvmWalletClient.

Step 3: Sign a Message

For SVM, delegated_sign_message returns the raw 64-byte Ed25519 signature as bytes — not a string. Convert it to your preferred encoding:
is_formatted:
  • Truemessage is already a hash (typical Solana flow: pass the hashed transaction message)
  • Falsemessage is a plain string; the SDK formats and hashes it for you

Complete Webhook Handler Example

Security Considerations

  • Never log delegation credentials (wallet API key, key share)
  • Store credentials encrypted at rest — treat them like passwords
  • Use secure environment variables for your RSA private key and server API key
  • The RSA private key used for decryption should never leave your server

Next Steps

Last modified on August 3, 2026