The Policy Engine APIs evaluate policies (a set of rules) to govern the behavior of accounts or projects, such as enforce allowlists and denylists.
  • A policy is a collection of rules with defined criteria.
  • Each rule contains a specified action, operation, and criteria:
    • An 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.
    • An 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 network
  • A rule indicates how an operation should behave, specifying whether a request with defined criteria should be accepted or rejected. Only signEvmTransaction and signSolTransaction operations are currently supported.

​
Policy Scope

Policies can be applied at the project and/or account level:
  • Project-level policy: A 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: An 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: 
  "description": "Project-level policy",
  "scope": "account",
  ...

​
Policy Evaluation

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:
  1. If the rule’s 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.
  2. If after policy evaluation, no rule’s criteria are met, the engine moves to processing the next policy (i.e., an account-level policy).
  3. If no further policies exist, the request is rejected.
For example, the following policy is a project-level policy with two rules. The Policy Engine will:
  1. Evaluate the first rule: For a signEvmTransaction request, accept the request if the transaction is less than or equal to 1000000000000000000 wei OR
  2. Evaluate the second rule: If the request is a signEvmTransaction request, accept the request if the transaction is less than or equal to 2000000000000000000 wei AND the request is made to the address 0xEeeeeeEeeeEeEeeEeEeeEEEeeeeEeeeeeeeEEeE.
  3. If the request does not meet the criteria of either rule, the engine will move on to evaluate an account-level policy (if one exists).
  4. Otherwise, the request is rejected.
Rules are processed in the order they are defined. Once a rule applies to an operation, subsequent rules are ignored. 
{
  "description": "Project-level policy",
  "scope": "project",
  "rules": [
    {
      "action": "accept",
      "operation": "signEvmTransaction",
      "criteria": [
        {
          "type": "ethValue",
          "ethValue": "1000000000000000000",
          "operator": "<="
        }
      ]
    },
    {
      "action": "accept",
      "operation": "signEvmTransaction",
      "criteria": [
        {
          "type": "ethValue",
          "ethValue": "2000000000000000000",
          "operator": "<="
        },
        {
          "type": "evmAddress",
          "addresses": [
            "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE"
          ],
          "operator": "in"
        }
      ]
    }
  ]
}

​
Policy Application

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 policies field in the request body of the createEvmAccount and createSolAccount operations.
  • By specifying the policies field in the request body of the updateEvmAccount and updateSolanaAccount operations.

​
Criteria

The following criteria are supported:

​
SignEvmTransaction Criteria

ethValue 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. evmAddress 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.

​
SignSolTransaction Criteria

solAddress 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.