Introduction

The Policy Engine is your platform's source of truth for access control. Declare rules once; the engine enforces them everywhere - across transactions, key operations, and any action your platform exposes.

Capabilities

Capability	Stateless Policy	Stateful Policy	Notes
Multi-chain support	✅	✅	One policy language across supported chains.
Offchain operations	✅	✅	Can gate key export, key refresh, quorum change, and similar off-chain operations.
Per-transaction transfer limits	✅	✅	Example: amount <= 100 for a single request.
Address controls: whitelisting (per-account)	✅	✅	Restrict allowed destination/source addresses via policy conditions.
Address controls: source account/wallet restrictions	✅	✅	Restrict signing requests to specific source wallets/accounts.
Cumulative transfer limits (daily/weekly/monthly)	❌	✅	Requires historical aggregation. See Stateful Policy Onboarding: Duo, Trio, Silent Network.
Transaction rate limiting	❌	✅	Requires counting events inside a time window. See Stateful Policy Onboarding: Duo, Trio, Silent Network.
Time-window aware rules	❌	✅	Requires rolling/fixed window logic. See Stateful Policy Onboarding: Duo, Trio, Silent Network.
Fine-grained access control	✅	✅	Supports issuer-based and condition-based controls.
MPC-focused architecture	✅	✅	Designed for transactions signed by MPC nodes.
Key-bound policies	✅	✅	Policies are bound to a specific key_id.
Auditable evaluation	✅	✅	Evaluation outcomes are logged per action.

Concepts

A Policy is a JSON document that defines the complete set of constraints for a key. Policy contains multiple Rule. A Rule contains multiple Condition or ConditionGroup.

• Rule: A composite statement about if the transaction/request satisfies all the condition groups or conditions to execute the action.
• Condition: A boolean statement that evaluates a specific attribute of the transaction (e.g., checking if amount is less than 100).
• ConditionGroup: A combination of boolean statements about the transaction/request.

Validation: Policies are integrity-checked using a Message Authentication Code (MAC).

Policy Structure

A Policy object follows this structure:

FieldTypeDescription

versionstringMust be "1.0".

descriptionstringOptional description (max 512 chars).

management_approvalApprovalGroupOptional quorum required to update or delete the policy.

rulesRule[]List of rules to evaluate.

Approval Group

Both management_approval and Rule.approval use the same structure, but they authorize different actions:

• management_approval defines the quorum for policy management. Its members approve updates to or deletion of the policy currently attached to the key; this group does not approve signing requests.
• Rule.approval defines the quorum for signing requests that match that rule.

The two groups are configured and evaluated independently. A credential can be a member of both, but it receives authority for each action only from the group in which it appears.

FieldTypeDescription

membersCredentialIdentity[]EOA, passkey, or JWT credentials that can approve the action.

thresholdnumberNumber of distinct member approvals required; from 2 through the number of members.

Each member contains its authentication method and credential id.

Rule Structure

FieldTypeDescription

descriptionstringOptional description (max 512 chars).

issuerIssuer[]Entities authorized to issue the request that will be evaluated by the engine.

approvalApprovalGroupOptional quorum required to authorize a signing request that matches this rule.

actionstring"allow", "deny".

logicstring"or", "and" (combining conditions). Defaults to "and" if omitted.

chain_typestring"off", "ethereum", "solana".

conditionsConditionOrGroup[]List of conditions or condition groups.

external_checksExternalCheckGroupOptional external provider checks that must pass before this rule applies.

Issuer

Defines who is making the request which is usually defined by the authentication payload in the request.

• type: "UserId", "SessionKeyId", or "*" (any).
• id: The specific ID of the user or session.

External Checks

Rule.external_checks configures one or more decisions from external providers:

{
  "external_checks": {
    "logic": "and",
    "checks": [
      {
        "check_id": "550e8400-e29b-41d4-a716-446655440000",
        "integration_id": "transaction-screening",
        "operation": "screen-destination-address",
        "duration_ms": 3000
      }
    ]
  }
}

FieldTypeDescription

logicstring"and" requires every check to pass; "or" requires at least one check to pass.

checksExternalCheck[]Non-empty list of external checks required by the rule.

Each external check contains:

FieldTypeDescription

check_idstringUnique identifier for the check within the policy.

integration_idstringSelects a configured external provider integration.

operationstringSelects an operation offered by the integration.

duration_msnumberMaximum time allowed for the provider check, in milliseconds.

Conditions

Conditions are the building blocks of rules. They compare transaction attributes against expected values. A rule can contain individual conditions, condition groups, or both.

Condition Groups

A ConditionGroup combines a non-empty list of conditions using its own boolean logic. The rule's logic then combines the group's result with the other entries in Rule.conditions. Condition groups contain only conditions and cannot be nested.

{
  "logic": "and",
  "group": [
    {
      "transaction_type": "nativeTransfer",
      "transaction_attr": "receiver",
      "operator": "eq",
      "value": "0x538f44e...d35Cc"
    },
    {
      "transaction_type": "nativeTransfer",
      "transaction_attr": "nativeValue",
      "operator": "lte",
      "value": "1000000000000000000"
    }
  ]
}

FieldTypeDescription

logicstring"and" requires every condition to pass; "or" requires at least one condition to pass.

groupCondition[]Non-empty list of conditions evaluated within the group.

abiobjectOptional group-level ABI for decoding Ethereum calldata. A condition-level ABI takes precedence.

Condition Fields

FieldTypeDescription

transaction_typestringThe type of transaction (see below).

transaction_attrstringThe specific attribute to check (see below).

operatorstringComparison operator.

valueanyThe static value to compare against.

abiobject(Optional) ABI/IDL for decoding data.

Transaction Types

Used to deserialize the transaction payload correctly.

• eip712: Typed Data signing.
• eip191: Personal Sign.
• erc20: Fungible Token interaction.
• erc721: NFT interaction.
• nativeTransfer: Pure ETH/SOL transfer.
• solanaTransaction: General Solana transaction.

Transaction Attributes

The specific field within the transaction to evaluate.

NameDescriptionExample

senderTransaction sender. EIP-1559 "from" field in erc20, erc721 and ETH transfer transactions"0x742d35Cc...8f44e"

receiverTransaction destination. EIP-1559 "to" field in erc20, erc721 and ETH transfer transactions. Or, sender account key in SOL transfer transaction"0x538f44e...d35Cc"

nativeValueAmount of native token (ETH/SOL)."1000000000000000000" (1 ETH)

chainIdBlockchain Network ID.1

functionSelectorEthereum function signature (4 bytes)."0xa9059cbb"

messageEIP-191 message content."Sign this message"

verifyingContractEIP-712 contract address."0xCcCC...cccC"

primaryTypeEIP-712 primary type."Mail"

domainNameEIP-712 domain name."Ether Mail"

splTransferAmountSolana SPL token amount.1000000

splTokenMintSolana SPL token mint address."EPjFWdd5...TDt1v"

solanaAccountKeysList of accounts in a Solana transaction.["Account1...", "Account2..."]

If an attribute is not found in the list above, the engine will try to resolve it as a parameter from the provided ABI. To resolve naming collisions between built-in attributes and ABI parameters, you can use the abi: prefix (e.g. abi:sender). This forces the engine to look up the attribute in the ABI parameters instead of using the built-in value.

Operators

The operands to evaluate Transaction Attributes against the Policy's expected values.

• eq: Equal
• neq: Not Equal
• lt: Less Than
• lte: Less Than or Equal
• gt: Greater Than
• gte: Greater Than or Equal
• in: Value is in a list.
• all: All values match (for arrays).

Policy evaluation flow

Policy

A Policy evaluation is based on the results of Rule evaluations:

• Precedence: DENY rules take precedence over ALLOW rules.
• Default Behavior: If no rules match the request, the default action is DENY. Or, if there's no Policy attached to the key, policy evaluation will never happen.

Rule

A Rule defines an action (ALLOW or DENY) that is triggered when:

• The request Issuer and the Transaction Type matches the Policy configuration. If these 2 attributes aren't matched, the evaluation will be skipped for that Rule.
• Conditions (or Condition Groups) are satisfied.

External Decisions

A Rule with external_checks makes its match result conditional on decisions from the configured external providers. The rule contributes its ALLOW or DENY action only when the external check group passes.

See External Check Onboarding to learn how to setup external provider operations and references them in a Policy.

Stateful Policy Onboarding

• Start Here - Build your first stateful policy with controllers, entries, and end-to-end flow examples.