Overview
This page provides comprehensive examples and implementations for EVM-based policy configurations. These policies control EVM transaction signing, sending, message signing, and smart account operations. For general policy concepts and setup instructions, see the Policies Overview.Supported EVM Operations
EVM policies support the following operations:signEvmTransaction
: To identify incoming signing transactions on the EVM networksendEvmTransaction
: To identify incoming signing transactions that are then sent to a supported networksignEvmTypedData
: To identify incoming typed data to be signed by an accountsignEvmMessage
: To identify incoming messages to be signed by an accountsignEvmHash
: To identify incoming hash to be signed by an accountprepareUserOperation
: For preparing user operations on a smart accountsendUserOperation
: For sending user operations using a smart account
Supported Criteria Types
The following criteria types are available for EVM policies:evmAddress
: Criterion for recipient addresses of EVM transactionsethValue
: Criterion for ETH value in wei of native transfersevmNetwork
: Criterion for restricting transactions to specific EVM networksevmMessage
: Criterion for validating message content using regex patternsevmData
: Criterion for transaction data validation using contract ABIevmTypedDataVerifyingContract
: Criterion for EIP-712 verifying contract addressesevmTypedDataField
: Criterion for validating specific fields within EIP-712 typed datanetUSDChange
: Criterion for USD-denominated limits on asset transfers and approvals
Example policies
Allowlist
The following example demonstrates a policy that allows signing transactions only to specific EVM addresses. Transactions to any address outside of this list will automatically be deleted by the policy engine.allow-list-policy.json
addresses
as an allowlist, only accepting sign transaction requests to an EVM address that is in
the set.
Denylist
The following example demonstrates a policy that rejects signing transactions to specific EVM addresses. Transactions withto
field set to any address outside of this list will be accepted.
deny-list-policy.json
addresses
as a denylist, rejecting any sign transaction to an address that is not in
the set.
Transaction limits
The following example demonstrates a policy that only permits signing transactions with a value of 2000000000000000000 wei (2 ETH) or less.transaction-limit-policy.json
USD Limits
The following example demonstrates a policy that only allows transactions to transfer, or expose the sender to, less than $100.00 worth of assets at a time for both EOA accounts and Smart Accounts. This USD denominated amount includes native assets,ERC20
, ERC721
, and ERC1155
tokens calculated using current market prices.
The
netUSDChange
criterion can only be applied to mainnet transactions; it will be ignored for testnet transactions.How is change calculated?
How is change calculated?
The total change represents the dollar value of assets that the user either sends directly, or allows a spender to access from their wallet, in a single transaction. This includes:
- Native asset transfers
- Non-native token transfers
- Token approvals from
approve
,setApprovalForAll
, andpermit
functions
- Approving unlimited tokens
(type(uint256).max)
to an unknown contract - Giving approval to addresses with known malicious history
setApprovalForAll
for valuable NFT collections
- Limited approvals to well-known DEXs like Uniswap
- Approvals to verified, reputable protocols
- Time-limited permit signatures
usd-change-policy.json
Network restrictions
The following example demonstrates a policy that only permits sending transactions on the Base Sepolia network.restricted-network-policy.json
Multi-rule policies
Learn more on combining multiple rules in a single policy.- Allowlist first: A policy that checks the allowlist first, then the transaction limit.
- Allowlist second: A policy that checks the transaction value first, then uses a combined rule to check both the transaction value and the allowlist.
Allowlist first
The following example demonstrates a policy that contains both an allowlist and a transaction limit.combined-policy-1.json
- The transaction will be rejected against the first rule, as the address is not in the allowlist. However, the criteria still is not met and the engine will evaluate the transaction against the second rule.
- The transaction will be rejected against the second rule, as the value is greater than 2000000000000000000 wei (2 ETH).
Allowlist second
Let’s take a look at another combined policy example where we define the allowlist as the second rule instead of the first.combined-policy-2.json
- The transaction will be rejected against the first rule, as the value is greater than 1000000000000000000 wei. However, the criteria still is not met and the engine will continue evaluating the transaction against the second rule.
- The transaction matches against the second rule, as the value is less than or equal to 2000000000000000000 wei AND the address is in the allowlist. The transaction will be accepted.
What's the difference?
What's the difference?
The primary differences between these two examples are the rule order in which a transaction is evaluated.
-
The first example checks the allowlist first, and then the transaction limit
- This option is more restrictive, as it requires all transactions go to allowlisted addresses first, regardless of their value.
-
The second example checks the transaction value first, then uses a combined rule to check both the transaction value and the allowlist
- This option offers more granular control by allowing small transactions to be signed to any address, but restricts larger transactions to allowlisted addresses only.
Message signing restrictions
The following example demonstrates how to guarantee any attempt to sign a message will conform to a specific template. When composing a regular expression in thematch
field, any valid re2 regular expression syntax will be accepted.
accept-sign-message-policy.json
Limiting USDC Spend
This policy restricts USDC transactions on the Base network to transfers of 10,000 tokens or less. It applies to both signing and sending transactions to the USDC contract address, using the ERC20 ABI to validate that onlytransfer
function calls with a value
parameter under the specified limit are permitted.
limit-usdc-spend-policy.json
Transaction data restrictions with custom ABI
When working with smart contracts that aren’t covered by standard token interfaces (ERC20, ERC721, ERC1155), you need to provide a custom ABI to enable the policy engine to decode and validate transaction data. This is essential for:- Custom smart contracts: Protocols with unique function signatures and parameters
- Complex DeFi interactions: Multi-step operations, custom swaps, or governance functions
- Proprietary contracts: Internal business logic that requires specific validation rules
- Non-standard token implementations: Tokens with additional features beyond basic standards
custom-abi-policy.json
stakeTokens
function to:
- Maximum stake amount of 1000 tokens (assuming 18 decimals)
- Minimum duration of 1 day (86400 seconds)
- Only allow staking for pre-approved beneficiary addresses
Disable signing arbitrary hashes
The example below demonstrates a policy to prevent fraud by rejecting any attempt to sign a hash (i.e., undefined or arbitrary input data) on behalf of an account.reject-sign-hash-policy.json
EIP-712 verifying contract allowlist
The following example demonstrates a policy that prevents signing typed data for the zero address. This ensures that typed data signatures cannot be created for invalid or burn addresses.sign-typed-data-verifying-contract-policy.json
"in"
operator with trusted contract addresses, or a denylist by using "not in"
with untrusted addresses.
EIP-712 field restrictions
The following example demonstrates a more advanced policy that validates specific fields within typed data. This policy restricts an arbitrary Payment data type to a specific address, message content, and amount:sign-typed-data-field-policy.json
evmTypedDataField
criterion to inspect the actual data being signed. The evmTypedDataField
criterion supports conditions on numerical values, addresses and strings.
Difference between evmTypedDataVerifyingContract and evmTypedDataField
Difference between evmTypedDataVerifyingContract and evmTypedDataField
evmTypedDataVerifyingContract
: Checks only the verifying contract address in the EIP-712 domain. This is simpler and useful for allowlisting/denylisting contracts.evmTypedDataField
: Allows inspection of the entire typed data structure including types and field values. This enables more complex validations like checking specific field values, ranges, or data types.
Smart Account Operations
The following policy restricts Smart Account operations to USDC transactions on the Base network, with transfers of 10,000 tokens or less. It applies to both prepare and send operations to the USDC contract address, using the ERC20 ABI to validate that onlytransfer
function calls with a value
parameter under the specified limit are permitted.
smart-account-operations-policy.json
Complete implementation example
The following example shows how to create and manage multiple EVM policies programmatically:What to read next
- Policies Overview: Learn about general policy concepts and setup
- Solana Policies: Learn about Solana-specific policy examples
- v2 Server Wallet Security: Learn more about the security features of the CDP v2 Server Wallet
- v2 API Reference: Explore the API reference for CDP Policies