Overview
Condition sets provide a flexible way to define reusable lists of values that can be referenced in policy conditions.
Instead of hardcoding values directly in policy rules, you can create a named condition set (e.g., “Approved Recipients”) and reference it using the in_condition_set operator.
Together, condition sets make it easy to express complex constraints cleanly and keep policies maintainable as your application grows.
This approach offers several benefits:
- Maintainability: Update the list of values in one place without modifying policy rules
- Reusability: Reference the same condition set across multiple policies and rules
- Scalability: Manage large lists of values efficiently
- Dynamic Updates: Add or remove values without redeploying policies
Concepts
Condition sets are defined by three core primitives: condition sets, condition set items, and policy conditions. At a high-level:
- Condition sets are lists of values that can be referenced in policy conditions.
- Condition set items are individual items that belong to a condition set, whose values are directly evaluated against.
- Policy conditions are boolean statements that the policy engine can evaluate RPC requests against (see Conditions section)
The in_condition_set Operator
The in_condition_set operator allows you to check if the value of a transaction field exists in a condition set.
This is particularly useful for maintaining allowlists or denylists of addresses, contracts, or other string values.
The in_condition_set operator can be configured with a variety of fields and field sources, including ethereum_transaction.to, solana_system_program_instruction.Transfer.to, etc.
Create condition sets and items
Refer to the API reference for creating condition sets and items.
- Creating a condition set requires an owner.
- Updating condition sets or condition set items with the following endpoints requires
authorization signature.
- Deleting a condition set will delete all condition set items that have the same condition set id.
Condition sets evaluation
When the rules that are associated with the requested RPC method is evaluated:
- The policy engine extracts the value of the corresponding field from the transaction.
- If a
ConditionSetItem item is found with conditionSetId and the value (the value from the previous step), the condition evaluates to true.
- If all conditions in the rule pass, the rule evaluates to
ALLOW action.
The policy engine evaluates the raw value from the transaction directly against values of
condition set items without any conversion, so each ConditionSetItem must be exactly the value
of the field. Case sensitivity depends on the condition’s field source, not on the chain.
ethereum_transaction.to, address fields on ethereum_typed_data_message,
address arguments on ethereum_calldata, ethereum_typed_data_domain.verifyingContract,
ethereum_7702_authorization.contract, and tempo_transaction.fee_token. For these, a checksummed
and a lowercase address are interchangeable, so each address needs only one item.
Every other comparison is exact. That includes action_request_body fields such as
destination.address on transfer rules, even though the value is an EVM address, as well as all
Solana, Sui, Tron, and XRPL values.
Because action_request_body comparisons are exact, a transfer denylist keyed on a checksummed
address does not match the same address sent in lowercase, and the rule silently fails to fire.
Normalize destination addresses to one form in the app before calling transfer, or store both
forms in the condition set.
If a condition set is deleted, all conditions that evaluate against that condition set will
evaluate to false.
Example: Allowlist of recipient addresses
This example demonstrates how to create a policy that only allows transactions to approved recipient addresses using a condition set.
Step 1: Create a condition set
Response:
Step 2: Add approved addresses to the condition set
Step 3: Create a policy rule using the condition set
The following transaction is allowed because 0x5B8b13e8f3E6Ec888e88C77cf039EB6281F21D93 is in the condition set.
The following transaction denied because 0x0000000000000000000000000000000000000000 is not in the condition set.
Example: Denylist of recipient addresses
The example Allowlist of recipient addresses functions as a denylist of recipient addresses if the action is set to to DENY at step 3.
