Skip to main content
This feature is available for all Dynamic v3 embedded wallets (TSS-MPC). Upgrade is required if you are on v2 or earlier.
Wallet and signer policy layers are in early access. Talk to us if you’d like to participate.

Overview

Policies gives developers fine-grained control over how wallets interact. Policies are enforced before a transaction is signed, ensuring there is validation before execution. This allows you to:
  • Block malicious or unauthorized counterparties
  • Create custom workflows around wallet interactions
  • Ensure transactions are simulated and verified before execution
Policies are chain-agnostic, working seamlessly across EVM (including Account Abstraction wallets), Solana, Stellar, and Bitcoin.

Security Model

Dynamic’s policy system is designed with security and transparency at its core:
  • Tamper Resistance: Policies are created and enforced in a trusted execution environment, ensuring they cannot be bypassed at the client level. Only administrators and those with permissions can update and modify rules
  • Auditability: Every policy update is logged and traceable.
  • Transaction Simulation: Before a transaction is signed, it is simulated against your rules. Non-compliant requests are automatically rejected.
  • Malicious Transaction Detection: Before a transaction is signed, all transactions will be validated to ensure they are not being sent to a malicious address.
  • Pre-Signing Enforcement: Rules apply at signing time, not just after execution. This means developers can trust that no transaction leaves the wallet unless it passes policy checks.

Policy types

You can apply three types of policy rules to control how wallets interact:

Allowlist Mode

When you configure an allowlist, only addresses included in your allow rules are permitted. Everything not on the list is blocked.

Address Evaluation

Policies evaluate all participant addresses involved in a transaction’s execution path. If a transaction calls contract A that then calls contract B, every touched address (A and B) is considered a participant for evaluation. When using an allowlist (only listed addresses are permitted), ensure you include all relevant contract addresses, including proxies and their underlying implementations, to avoid unintended rejections.

Value Limits

You can add a value limit to any rule to restrict the maximum amount that can be transferred in a single transaction. When a value limit is set, the policy will evaluate the transaction amount and automatically block any transaction that exceeds the specified limit. Value limits work for EVM, Solana (SVM), Stellar, and Bitcoin chains, and can be applied to native tokens (like ETH, SOL, XLM, or BTC) as well as custom tokens (such as ERC-20, SPL, or Stellar assets). To set a value limit for the native token of the chain, leave the address field for the value limit blank.

Rule fields

A WaasPolicyRule has the following fields: For more details on modifiableBySigner, see Policy Layers.

Additional Notes

  • The list of available chains in the dashboard depends on your configuration settings. Some networks may not be available for policy validation.
  • Policies and rules are currently supported for most EVM, Solana, Stellar, and Bitcoin chains, including their respective testnets.
  • Sui embedded wallets are not supported at this time.

Next steps

Policy Layers

Understand how environment, account, wallet, and signer rules combine.

Creating & Managing Rules

Create and update environment-wide rules in the dashboard or through the API.

Managing layers

Create and update account, wallet, and signer layers through the API.
Last modified on August 13, 2026