Skip to main content

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

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