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).

rulesRule[]List of rules to evaluate.

Rule Structure

FieldTypeDescription

descriptionstringOptional description (max 512 chars).

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

actionstring"allow", "deny".

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

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

conditionsCondition[]List of conditions or condition groups.

Issuer

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

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

Conditions

Conditions are the building blocks of rules. They compare transaction attributes against expected values.

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.

Stateful Policy Onboarding

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

Incoming

• External State: Create webhook policy rules to reference external business logic for approving or denying transactions.