Skip to main content
POST
Simulate policies

Authorizations

Authorization
string
header
required

A JWT signed using your CDP API Key Secret, encoded in base64. Refer to the Generate Bearer Token section of our Authentication docs for information on how to generate your Bearer Token.

Body

application/json

Inputs for one operation, without signing credentials. operation is the policy rule operation name (for example signSolTransaction), not the HTTP operation ID (signSolanaTransaction).

operation
enum<string>
required

Rule operation to simulate.

Available options:
signEvmTransaction
address
string
required

The 0x-prefixed address of the EVM account.

Pattern: ^0x[0-9a-fA-F]{40}$
transaction
string
required

The RLP-encoded transaction to evaluate, as a 0x-prefixed hex string.

Example:

"0x02f082210580843b9aca00847735940082520894123456789012345678901234567890123456789087038d7ea4c6800080c0"

Response

Policy simulation result.

The action the real operation would take and why. matchedRule is present exactly when reason is rule_accepted or rule_rejected.

action
enum<string>
required

Whether the real operation would be accepted or rejected.

Available options:
accept,
reject
Example:

"reject"

reason
enum<string>
required

Why the operation got its action. Each value implies exactly one action. Within a policy, a matching reject rule overrides any matching accept rule, regardless of rule order. With accept: rule_accepted means matchedRule matched all of its criteria, its action is accept, and no reject rule in the same policy matched. no_rule_for_operation means no rule targeted the operation, so it was accepted by default. With reject: rule_rejected means matchedRule matched all of its criteria and its action is reject, so the rejection is caused by the entire rule. no_rule_matched means at least one rule targeted the operation but none matched, so it was rejected by default; unmatchedRules shows the criterion that disqualified each one.

Available options:
rule_accepted,
rule_rejected,
no_rule_matched,
no_rule_for_operation
Example:

"no_rule_matched"

unmatchedRules
object[]
required

Rules targeting the operation that were evaluated and did not match. Within a policy, reject rules are evaluated before accept rules, and evaluation stops at matchedRule. Rules that were not evaluated are omitted. When there is no matchedRule, every rule that targeted the operation appears here. Among matching rules with the same action, the first in policy order is matchedRule.

evaluatedPolicies
object[]
required

Policies iterated, in order: the project policy, then the account policy. Evaluation stops at the policy containing matchedRule. End-user operations consult only the project policy.

matchedRule
object

The rule whose action decided the evaluation.

Example:
evaluatedUnit
EvaluatedUnit · object

The unit this result describes. Present only when the operation was evaluated as more than one unit: one unit per call for user operations, and one unit per signing account for Solana transactions. Each unit is evaluated against the policies separately, and matchedRule, unmatchedRules, evaluatedPolicies, and every observed value describe this unit only. When action is reject, this is the first unit that was rejected. When action is accept, every unit was accepted and this is the last one.

Example: