Introduction

Policy engine is not available in Duo and Trio yet. Here is the overview of the implementation in Silent Network which is coming to Duo and Trio soon.

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.