Overview
Policies are rules-based controls that govern account and project operations in the CDP SDK. They allow you to accept or reject specific blockchain operations based on customizable criteria, providing security, compliance, and operational controls for your application.What are Policies?
A policy is a collection of rules that are evaluated when operations like transactions or signatures are requested. Each rule specifies:- Operation type - What operation the rule applies to (e.g.,
sendEvmTransaction,signSolMessage) - Action - Whether to
acceptorrejectmatching operations - Criteria - Conditions that must be met for the rule to match
Policy Scope
Policies can be applied at two levels:Project-Level Policies
Apply to all accounts in your project. Only one project-level policy can exist at a time. Use cases:- Organization-wide security controls
- Compliance requirements
- Default restrictions for all operations
- Network restrictions (e.g., only allow mainnet)
Account-Level Policies
Apply to specific accounts. Multiple account-level policies can exist, each attached to different accounts. Use cases:- Per-user spending limits
- Role-based access controls
- Account-specific restrictions
- Feature flags per account
When an account has both a project-level and an account-level policy, both policies are evaluated. If either policy rejects an operation, it will be blocked.
Policy Types
EVM Transaction Policies
Control EVM transaction operations with various criteria:ETH Value Limits
ETH Value Limits
Restrict transactions based on ETH value:Operators:
>, >=, <, <=, ==Address Restrictions
Address Restrictions
Allow or block specific recipient addresses:Operators:
in, not inNetwork Controls
Network Controls
Restrict operations to specific networks:Supported networks:
base, base-sepolia, ethereum, ethereum-sepolia, optimism, arbitrum, polygon, avalanche, bnb, zoraSmart Contract Data
Smart Contract Data
Control contract interactions based on function calls and parameters:Known ABIs:
erc20, erc721, erc1155 or provide custom ABIUSD Value Controls
USD Value Controls
Limit transactions based on USD value:Note: USD values are calculated based on real-time price feeds
Message Signing Policies
Control message and typed data signing:Smart Account Policies
Control user operations for Account Abstraction:Solana Policies
Control Solana transactions and signatures:SOL Value Limits
SOL Value Limits
Address Controls
Address Controls
Program ID Restrictions
Program ID Restrictions
Supported Operations
| Operation | Description | Account Type |
|---|---|---|
signEvmTransaction | Sign EVM transactions | Server Account |
sendEvmTransaction | Send EVM transactions | Server Account |
signEvmMessage | Sign EIP-191 messages | Server Account |
signEvmTypedData | Sign EIP-712 typed data | Server Account |
signEvmHash | Sign arbitrary message hashes | Server Account |
prepareUserOperation | Prepare ERC-4337 user ops | Smart Account |
sendUserOperation | Send ERC-4337 user ops | Smart Account |
signSolTransaction | Sign Solana transactions | Solana Account |
sendSolTransaction | Send Solana transactions | Solana Account |
signSolMessage | Sign Solana messages | Solana Account |
Managing Policies
List Policies
Update Policies
Delete Policies
Use Cases
Spending Limits
Spending Limits
Implement per-account or project-wide spending limits:
- Limit ETH/token transfers per transaction
- Cap USD value of transactions
- Control gas spending for smart accounts
Address Allowlisting
Address Allowlisting
Only allow transactions to approved addresses:
- Treasury management (only send to known wallets)
- Vendor payments (approved recipient list)
- Internal transfers (company wallet allowlist)
Contract Interaction Controls
Contract Interaction Controls
Govern smart contract interactions:
- Block dangerous functions (e.g.,
delegatecall) - Limit token approvals to specific spenders
- Control NFT minting and transfers
Compliance and Security
Compliance and Security
Meet regulatory and security requirements:
- Restrict testnet usage in production
- Block sanctioned addresses
- Enforce network restrictions
- Prevent phishing via message signing controls
Policy Evaluation
When an operation is requested:- All applicable policies are checked (project + account level)
- Rules are evaluated in order within each policy
- First matching rule determines the outcome
- If no rules match, the operation is allowed by default
- If any policy rejects, the entire operation is rejected
Best Practices
Start Conservative
Start Conservative
- Begin with restrictive policies in development
- Gradually relax restrictions as you understand your needs
- Test thoroughly on testnet before applying to mainnet accounts
Layer Your Controls
Layer Your Controls
- Use project-level policies for organization-wide rules
- Use account-level policies for user-specific restrictions
- Combine multiple criteria for fine-grained control
Monitor and Iterate
Monitor and Iterate
- Log rejected operations to understand policy effectiveness
- Review and update policies regularly
- Respond to security incidents by adjusting policies
Document Your Policies
Document Your Policies
- Use descriptive policy descriptions
- Maintain internal documentation of policy purposes
- Communicate policy changes to affected teams
Limitations
- Maximum 10 rules per policy
- Maximum 300 addresses per address criterion
- Project scope allows only one policy per project
- Policy descriptions limited to 50 characters
- Policies are evaluated synchronously and may add slight latency
Next Steps
Accounts
Learn about account types and policies
Transactions
Understand transaction lifecycle
Policy Management Guide
Step-by-step policy implementation
API Reference
Full API documentation for policies