The Policy Engine APIs evaluate policies (a set of rules) to govern the behavior of accounts or projects, such as enforce allowlists and denylists.
rules
with defined criteria.action
, operation
, and criteria
:
action
can either accept
or reject
a transaction if the criteria in the rule are met.criteria
is an array of logical expressions. All parameters must evaluate to true for the action to be applied.operation
corresponds to a CDP v2 API:
signEvmTransaction
or signSolTransaction
for signing transactions (to set a transaction limit)sendEvmTransaction
for signing a transaction, and sending it to a supported networksignEvmHash
for signing an arbitrary 32 byte hash.signEvmMessage
for signing an EIP-191 message.prepareUserOperation
for preparing user operations on a smart account.sendUserOperation
for sending user operations using a smart account.signEvmTransaction
and signSolTransaction
operations are currently supported.Policies can be applied at the project and/or account level:
project
-level policy applies to all accounts in a CDP Project. Only one project-level policy can be applied to accounts within a CDP Project at any given time.account
-level policy applies to one or more accounts. An account
can have at most one account-level policy at any given time.Thus, a single account can be assigned at most two policies at any given time: one project-level policy and one account-level policy.
Scope is specified in the scope
field of a policy:
Project-level policies are evaluated first, followed by account-level policies.
The Policy Engine will process the request against each rule in the order it is defined within the rules
array:
criteria
(processed as a logical AND operation applied to a list of independently evaluated boolean expressions) are met, accept
or reject
behavior is applied immediately and the engine stops further evaluation of the policy.criteria
are met, the engine moves to processing the next policy (i.e., an account
-level policy).For example, the following policy is a project-level policy with two rules. The Policy Engine will:
signEvmTransaction
request, accept the request if the transaction is less than or equal to 1000000000000000000 wei ORsignEvmTransaction
request, accept the request if the transaction is less than or equal to 2000000000000000000 wei AND the request is made to the address 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE
.account
-level policy (if one exists).Rules are processed in the order they are defined. Once a rule applies to an operation, subsequent rules are ignored.
Project-level policies are applied to all accounts in a CDP Project. They will apply retroactively even if the project-level policy is created after the account was created. To disable a project-level policy, you must remove the project-level policy from the CDP Project using the deletePolicy
operation.
Account-level policies can be applied in two ways:
By specifying the accountPolicy
field in the request body of the createEvmAccount
and
createSolAccount
operations.
By specifying the accountPolicy
field in the request body of the updateEvmAccount
and
updateSolanaAccount
operations.
The following criteria are supported:
A criterion based on the value of the transaction. The transaction’s value
field is compared to the criterion’s ethValue
field using the operator
field.
A criterion based on the recipient address of the transaction. The transaction’s to
field is compared to the criterion’s addresses
field using the operator
field.
A criterion based on encoded transaction data that evaluates the function being called, as well as any number of arguments accessed by either name or index. Currently this criterion only supports primitive types; string
, bool
, uint(8,16,32,64,256)
, int(8,16,32,64,256)
, address
, and both fixed and dynamic length bytes
.
A criterion based on the value of the transaction. The transaction’s value
field is compared to the criterion’s ethValue
field using the operator
field.
A criterion based on the recipient address of the transaction. The transaction’s to
field is compared to the criterion’s addresses
field using the operator
field.
A criterion based on the intended network of the transaction. The network
field in the sendEvmTransaction
request body is compared to the criterion’s networks
field using the operator
field.
A criterion based on encoded transaction data that evaluates the function being called, as well as any number of arguments accessed by either name or index. Currently this criterion only supports primitive types; string
, bool
, uint(8,16,32,64,256)
, int(8,16,32,64,256)
, address
, and both fixed and dynamic length bytes
.
A criterion based on the value of the user operation. The operation’s value
fields are compared to the criterion’s ethValue
field using the operator
field.
A criterion based on the recipient address of the operation. The operation’s to
fields are compared to the criterion’s addresses
field using the operator
field.
A criterion based on encoded transaction data that evaluates the function being called, as well as any number of arguments accessed by either name or index. Currently this criterion only supports primitive types; string
, bool
, uint(8,16,32,64,256)
, int(8,16,32,64,256)
, address
, and both fixed and dynamic length bytes
.
A criterion based on the value of the user operation. The operation’s value
fields are compared to the criterion’s ethValue
field using the operator
field.
A criterion based on the recipient address of the user operation. The operation’s to
fields are compared to the criterion’s addresses
field using the operator
field.
A criterion based on the intended network of the user operation. The network
field in the prepareUserOperation
request body is compared to the criterion’s networks
field using the operator
field.
A criterion based on encoded transaction data that evaluates the function being called, as well as any number of arguments accessed by either name or index. Currently this criterion only supports primitive types; string
, bool
, uint(8,16,32,64,256)
, int(8,16,32,64,256)
, address
, and both fixed and dynamic length bytes
.
The signEvmHash
operation does not accept any criteria. To prevent this operation from being executed by any account, specify a rule with signEvmHash
as the operation, and reject
as its action.
A criterion based on the intended message to be signed. The match
field in the criteria is a RE2 compliant regular expression that will be executed against the message in the API request.
A criterion based on the recipient addresses of the transaction. The criterion’s address
field is compared to the list of addresses in the transaction’s accountKeys
(for legacy transactions) or staticAccountKeys
(for V0 transactions) array using the operator
field.
Smart contract function restrictions serve as a critical security and governance mechanism in decentralized applications, allowing developers and organizations to implement fine-grained access controls over their protocol interactions. One of the primary use cases for function restrictions is protecting high-risk operations from unauthorized access such as:
evmData
criterion for the signEvmTransaction
, and sendEvmTransaction
operations.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 only transfer
function calls with a value
parameter under the specified limit are permitted.