Skip to main content
Declarative rules are in early access and are not enabled by default. Talk to us if you’d like to participate.
Each example below is one rule, ready to copy and adjust. For what each field means, see Rule anatomy, and for how rules combine, read Declarative rules. The JSON is what the rule templates in the Dynamic demo produce. Before you save one:
  • Replace the ruleId with your own UUID. The ones here are placeholders.
  • Amounts are strings in the token’s smallest unit. USDC has 6 decimals, so 100 USDC is "100000000". ETH has 18 decimals, so 5 ETH is "5000000000000000000".
  • Token addresses are per network. The examples use Ethereum mainnet: USDC is 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 and USDT is 0xdAC17F958D2ee523a2206206994597C13D831ec7.

Limit per transaction

Deny any transaction on an EVM chain that moves more than 5 ETH. The comparison is gt, so exactly 5 ETH still goes through.

Spend limit over time

Deny a transaction on an EVM chain once the wallet has moved more than 5,000 USDC in the last day. The window’s total already includes the transaction being checked. Durations are written like 1.day, 2.hours, 90.seconds, or 1.month, and a month is 30 days.

Control where money can go

Block one address. This reads counterparties, which is every address the transaction touches, so it also catches the address when it is the contract being called or a spender being approved.
Only pay approved vendors. nin means “is not one of”, so this denies a transaction that touches any address outside the list. It reads effectiveCounterparties, which leaves out gas infrastructure you did not choose, such as a bundler or paymaster.
A token transfer also touches the token contract. To let USDC reach a vendor through this rule, add the USDC contract and its implementation to the list too. See Destinations and tokens.

Control which tokens move

Deny a transaction on an EVM chain that moves anything other than USDC, USDT, or ETH. The asset.isNative comparison keeps the network’s own coin permitted.

Restrict by chain or network

Require one admin’s approval for every transaction on Ethereum mainnet. Approval fields are described in Rule anatomy.
On all chains, require one admin’s approval for every transaction. A condition of { "always": true } matches everything, so, like the fallback, this rule must be last in the list, and it cannot share a layer with a DENY fallback. To allow or deny every transaction instead, use the fallback.

Wallet actions

Require one admin’s approval before the private key is exported.
Protect delegated access from being revoked.
Stop signing from the client.

Require approval for large transfers

Hold any transaction that moves more than 10,000 USDC on an EVM chain until two people with the admin or cfo role approve it within 24 hours.

A whole layer in deny style

Block one address and cap transactions at 5 ETH. There is no fallback, so everything else goes through.

A whole layer in allow style

Allow transactions on an EVM chain that move at most 100 USDC, and refuse everything else with the DENY fallback.
This allow rule matches when any one asset in the transaction is 100 USDC or less, and it says nothing about destinations. To require that every asset qualifies, use the not exists pattern in Matching every item.

Next steps

Advanced conditions

Operators, lists, matching every item, and combined flows.

Rule anatomy

Rule fields, the fallback rule, and approval requirements.

Declarative rules

How rules, the fallback, and the allow and deny styles work.
Last modified on October 23, 2026