Control wallet interactions with fine-grained, tamper-resistant rules across EVM, Solana, and Stellar.
Recommended: JavaScript SDK with React Hooks
For new React apps, we recommend the JavaScript SDK with React Hooks (@dynamic-labs-sdk/react-hooks) instead of the legacy React SDK documented here. The JS SDK comes with many benefits such as a much smaller bundle size and other optimizations. Use the React quickstart (JavaScript SDK) to get started.
This feature is available for all Dynamic v3 embedded wallets (TSS-MPC). Upgrade is required if you are on v2 or earlier.
Policy and Rules 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, and Stellar.
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.
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.
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), and Stellar chains, and can be applied to native tokens (like ETH, SOL, or XLM) 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, simply leave the address field for the value limit blank.
Click on Save Rule to create a rule by clicking on Add Rule in Basic Settings once you have configured the rule.
You can also send an API request with your authorized token to create/update a rule. The payload can be found in the JSON tab of the Rule creation page.
Below is an example of creating a rule via curl:
curl -X POST \"https://app.dynamicauth.com/api/v0/environments/<environment_id>/waas/policies" \-H "Content-Type: application/json" \-H "Authorization: Bearer <your_token>" \-d '{ "rulesToAdd": [ { "chain": "EVM", "chainIds": [1], "name": "Allow only transaction with WETH contract on ETH mainnet", "ruleType": "allow", "addresses": ["0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2"] } ]}'
To confirm that your policy rule is enforced, attempt to send a transaction that matches or violates the rule you configured. We recommend performing these tests on a testnet within a sandbox environment.Expected Behavior:
If the transaction complies with the policy, it will be processed as normal.
If the transaction violates the policy, the SDK or wallet connector will return an error indicating that the operation is not permitted.
Below is an example of a policy violation error displayed when a transaction does not meet the configured rule criteria:
You can programmatically create or update multiple policy rules at once using the API. To do this, provide an array of rules in the rulesToAdd, rulesToUpdate, or ruleIdsToDelete fields of your request payload.Here is an example of how to create multiple rules using a POST request (SDKs or HTTP clients):
curl -X POST \"https://app.dynamicauth.com/api/v0/environments/<environment_id>/waas/policies" \-H "Content-Type: application/json" \-H "Authorization: Bearer <your_token>" \-d '{ "rulesToAdd": [ { "chain": "EVM", "chainIds": [1], "name": "Allow only transaction with the WETH contract on ETH mainnet", "ruleType": "allow", "addresses": ["0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2"] }, { "chain": "EVM", "chainIds": [8453], "name": "Allow only transaction with USDC contract on Base mainnet", "ruleType": "allow", "addresses": ["0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"] } ]}'
Here is an example of how to update multiple rules using curl:
curl -X PUT \"https://app.dynamicauth.com/api/v0/environments/<environment_id>/waas/policies" \-H "Content-Type: application/json" \-H "Authorization: Bearer <your_token>" \-d '{ "rulesToUpdate": [ { "id": <existing_rule_id>, "chain": "EVM", "chainIds": [1], "name": "Allow only transaction with the WETH contract on ETH mainnet", "ruleType": "allow", "addresses": ["0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2"] }, { "id": <existing_rule_id>, "chain": "EVM", "chainIds": [8453], "name": "Allow only transaction with USDC contract on Base mainnet", "ruleType": "allow", "addresses": ["0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"] } ]}'
Here is an example of how to delete multiple rules using curl:
USDC allowlist example (Ethereum mainnet, proxy + implementation) to a single address:
USDC on Ethereum mainnet uses a proxy pattern. To allow interactions, add both the proxy and the current implementation addresses to your allowlist, on this example we are allowing interactions to a single address (0x5f09B2caaafD345EaE7B711A32CcBdf59befB4bB):
Dynamic emits a waas.policy.violation webhook event whenever a transaction is blocked by your configured policy rules. This event provides detailed information about what was blocked and why, making it invaluable for monitoring security, debugging rules, and discovering which addresses your users need to interact with.
Building Allow-Only Rules: The webhook includes all counterparties involved in a transaction, helping you identify which addresses to add to your allowlist
Security Monitoring: Track blocked transactions and identify potential threats or unusual activity
Rule Debugging: Understand why legitimate transactions are being blocked and adjust rules accordingly
Audit Trail: Maintain a complete log of all policy violations for compliance and security review
The reasonCode field indicates the type of policy violation. The webhook payload structure varies based on the violation type, but always includes the core fields needed to understand what was blocked and why.
To receive policy violation events, configure a webhook endpoint in your Developer Dashboard and subscribe to the waas.policy.violation event. For more information on webhook setup and signature validation, see the webhooks documentation.
