Delegated Access is currently in development and not yet available in production. This documentation describes the planned implementation and may change before release.
Delegated Access allows an application developer to act on behalf of a user, under strict user-approved permissions. When enabled, the developer receives a cryptographic share and a per-wallet API key that allows limited operations such as signing transactions. This gives developers the ability to automate flows (e.g. bots, agents, recurring jobs) while keeping the end-user in full control of what’s allowed.
Policies coming soon: In the future, you’ll be able to attach detailed rules and spending caps directly from the dashboard. For now, permissions are configured during delegation.

​
Overview

At a high level:
  1. Developer Setup: Developer configures a secure HTTPS endpoint (where Dynamic will send encrypted key shares) and provides an encryption key in the dashboard.
  2. User Approval: On next sign-in, the user is prompted to approve delegation with a clear list of permissions (e.g. spending cap, trusted contracts, whitelisted wallets).
  3. Reshare Ceremony: If approved, Dynamic triggers a reshare ceremony:
    • User gets a new share.
    • Dynamic generates a new server share.
    • The developer’s endpoint receives an encrypted external share along with a per-wallet API key.
  4. Secure Storage: The developer stores the share securely (encrypting again on their side is recommended).
  5. Delegated Operations: When acting on behalf of the user, the developer:
    • Authenticates with the per-wallet API key.
    • Uses their share with the SDK to perform allowed operations.
Delegated access does not allow exporting private keys, refreshing/resharing, or modifying policies. It is limited to user-approved signing operations.

​
Step 1: Configure Delegated Access Endpoint

The Delegated Access Endpoint is a verified HTTPS endpoint that receives encrypted key shares from Dynamic when users approve delegation. This endpoint acts as a secure bridge between Dynamic’s MPC system and your application. In the dashboard, provide:
  • Endpoint URL (HTTPS POST)
  • Encryption key (used by Dynamic to encrypt the share before sending)
Your Delegated Access Endpoint will receive:
  • externalServerKeyShare - The encrypted key share for delegated operations
  • accountAddress - The wallet address being delegated
  • rawPublicKey - The public key associated with the wallet
Delegation Setup Screenshot
Example Response: 
{
  "externalServerKeyShare": "encrypted_key_share_data",
  "accountAddress": "0x1234...",
  "rawPublicKey": "abcd..."
}

​
Step 2: User Grants Permission

On next login, the user is prompted to approve delegation for your application. The UI shows exactly what permissions are being requested.
User Permission Prompt
Permissions may include:
  • Spending caps (e.g. up to $10,000)
  • Trusted contracts or domains
  • Whitelisted recipient addresses
  • Transaction type restrictions

​
Step 3: Reshare Ceremony

Once the user approves:
  1. New Share Generation: We generate new shares for the user and the developer.
  2. Share Distribution: New shares are created and distributed:
    • User share (local)
    • Dynamic server share (TEE)
    • Delegated external share (sent to developer’s Delegated Access Endpoint)
  3. EAC Update: Dynamic updates its Encrypted Account Credentials (EAC) with a “delegated” flag.
  4. Developer Notification: Developer’s Delegated Access Endpoint receives the encrypted share and per-wallet API key.
Example Response: 
{
  "accountAddress": "0x1234...",
  "rawPublicKey": "abcd...",
  "externalServerKeyShare": "encrypted_key_share_data"
}

​
Step 4: Developer Triggers Actions

The developer can now use their stored share and wallet API key to perform allowed actions. Process:
  1. Transaction Request: Developer calls the server/transact endpoint with transaction details.
  2. Dynamic Verification: Dynamic verifies:
    • Delegated flag exists in the EAC
    • Wallet is valid
    • Transaction passes all user-defined rules
  3. Transaction Signing: Transaction is signed using the delegated share.

​
Step 5: Rules and Policies

At any point, users can optionally attach rules/policies to delegation, such as:
  • Transaction type restrictions
  • Domain/contract allowlists
  • Spending caps
  • Time-based limitations
Currently, rules can be added by either the user or developer, but the most secure UX is user-initiated. If a developer attaches a rule, it will require user approval on next login.

​
Revocation

Revocation is simply another reshare initiated by the user that removes the delegated server share. After revocation, the developer will no longer be able to act on the user’s behalf. Revocation Process:
  1. User initiates revocation from their wallet
  2. Dynamic performs a reshare ceremony
  3. Developer’s external share becomes invalid
  4. All delegated operations are immediately blocked

​
Security Considerations

  • Encryption: Dynamic encrypts shares before sending. Developers should re-encrypt before storage.
  • Per-wallet API keys: Each wallet has its own API key, scoped only to that wallet.
  • Limited operations: Developers cannot reshare, refresh, or export keys.
  • Audits & compliance: All delegated flows inherit Dynamic’s SOC2 and security posture.
  • Endpoint security: Ensure your delegated access endpoint uses HTTPS and proper authentication.

​
Learn More