Skip to main content

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

  • Multi-chain support: Allow for setting rules to secure digital assets held across multiple chains using a single, unified policy language model.
  • Offchain operations: Enforces policies for key export, key refresh, quorum change and other off-chain operations.
  • Transfer Limits: Cap the amount of value that can be transferred in a single transaction.
  • Fine-grained Access Control: Enables distributed authority across organizational boundaries where signature authority is split among multiple parties/levels.
  • Specific Architecture: Designed for transactions signed by Multi-Party Computation (MPC) nodes.
  • Key-Bound: Policies are bound to a specific Key ID.
  • Stateless & Deterministic: Evaluation is based solely on the request payload and the policy itself.
  • Auditable: Policy evaluation results are logged for every 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.

Limitations

  • Stateless: No access to historical data (e.g., "Daily Limit" is not supported).
  • No External State: Cannot reference external price feeds or databases.
  • No Time Awareness: Cannot restrict based on time of day.