Rule anatomy

Declarative rules are in early access and are not enabled by default. Talk to us if you’d like to participate.

This page describes the parts of a declarative rule. For how rules, the fallback, and the allow and deny styles work, read Declarative rules first.

Rule fields

{
  "ruleId": "00000000-0000-4000-8000-000000000001",
  "name": "Cap at 5 ETH",
  "phase": "transaction",
  "then": "DENY",
  "when": {
    "all": [
      { "field": "operation.chain", "op": "eq", "value": "EVM" },
      {
        "exists": {
          "in": "outgoingAssets",
          "where": {
            "all": [
              { "field": "asset.isNative", "op": "eq", "value": true },
              { "field": "totalRawValue", "op": "gt", "value": "5000000000000000000" }
            ]
          }
        }
      }
    ]
  }
}

Field	What it holds
`ruleId`	The rule’s identity, a UUID. It is how you update or remove the rule later. If a new rule arrives without one, Dynamic generates it.
`name`	Optional label for people.
`phase`	`transaction` for money moving on a chain, or `operation` for a wallet action.
`then`	`ALLOW`, `DENY`, or `REQUIRE_APPROVAL`. Operation rules accept only `DENY` and `REQUIRE_APPROVAL`.
`when`	The condition. See Advanced conditions.
`approvalRequirements`	Only on `REQUIRE_APPROVAL` rules: who must approve, how many, and by when. See Approval requirements.

The fallback rule

A deny fallback is this rule, placed last in the layer’s list. A rule placed after it is refused when you save the layer. Leave it out for an allow fallback.

{
  "ruleId": "00000000-0000-4000-8000-000000000099",
  "phase": "transaction",
  "then": "DENY",
  "when": { "always": true }
}

Fields a rule reads

These fields are read at the top level of when. Assets, amounts, destinations, and spending arrive as lists, which Advanced conditions covers.

Field	Values
`operation.chain`	`EVM`, `SVM`, `BTC`, and the other supported chain families
`chain.id`	The network, as a number
`operation.type`	In operation rules: `exportPrivateKey`, `revocation`, or `clientSigning`. In transaction rules, the kind of request, such as `evmTransaction`.

The chain.id values for common networks:

Chain family	Networks (`chain.id`)
`EVM`	Ethereum `1`, Polygon `137`, Base `8453`, Arbitrum `42161`, Optimism `10`
`SVM`	Mainnet `101`, Devnet `103`
`BTC`	Mainnet `0`, Testnet `1`

Approval requirements

The approvalRequirements list on a REQUIRE_APPROVAL rule takes these fields. Only a business-account owner or admin, or an environment admin, can write approval rules.

Field	Meaning
`id`	Your identifier for this requirement within the rule.
`v`	Schema version. Always `1`.
`requiredApprovals`	How many approvals are needed in total. The person who made the request does not count.
`eligibleApproverRoles`	Roles whose holders may approve: `owner`, `admin`, `viewer`, or any role your business account defines, such as `cfo`. Names are matched without regard to case, and a custom role also counts as the built-in role it inherits.
`completeWithinSeconds`	Optional deadline. When you leave it out, the request can be approved for 30 days, which is also the maximum.

Next steps

Rule examples

A ready-made rule for each common case, and two whole layers.

Advanced conditions

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

Declarative rules

How rules, the fallback, and the allow and deny styles work.

Managing layers

Read and update account, wallet, and signer layers through the API.

Learn

Implement

Rule fields

The fallback rule

Fields a rule reads

Approval requirements

Next steps

Rule examples

Advanced conditions

Declarative rules

Managing layers

​Rule fields

​The fallback rule

​Fields a rule reads

​Approval requirements

​Next steps

Rule examples

Advanced conditions

Declarative rules

Managing layers

Rule fields

The fallback rule

Fields a rule reads

Approval requirements

Next steps