Rule Conditions and Actions

A policy rule is made up of conditions and actions. When all the conditions are met, the policy rule is applied to the transaction and the preassigned action is taken.

Suppose you wish to have Fordefi automatically process a transaction up to $1000 and block any transaction that exceeds that amount. The policy rule you set would check the amount of the transaction. If an attempt is made to perform a transaction exceeding $1000, the system establishes that the condition is met, the policy rule is applied, and the transaction is blocked.

Conditions

This section describes the conditions that you can set for any single rule you create while building a policy. When you create a rule, you add conditions to any of the following:

Initiator

The Initiator condition lets admins select which user or group of users will be part of the rule. A user can appear both as an individual and as part of a group.

Origin

The Origin condition lets admins to select which vaults or group of vaults the policy will be part of the rule.

Transaction Type

The Transaction Type condition lets admins limit the type of transaction for which the rule will be in effect. It can be one the following:

  • Transfer: Sending funds directly to another recipient using the platform either using the Transfer dialog in the Web console or the API.
  • Contract call: Interaction using a smart contract or a DApp
  • Allowance: A token approval on EVM chains only
  • Message signature: One of two types:
    • Personal message
    • Typed message
  • Black-box signature: Signing any arbitrary buffer (on black-box vaults only)

Caveat: Certain matchers apply only to specific types of transactions. When a rule specifies a matcher that is not applicable to a certain transaction type, such transactions can not be matched by this rule. See below for details.

Destination/Recipient

The Destination/Recipient condition lets admins set limits on the destination/recipient of the transaction. Specify the recipient as it is displayed in the Fordefi platform.

For transfers, this is the recipient of the transfer. For allowances, this is the address that receives the token allowance (that is, the spender). For contract calls, this is the destination address of the contract call.

Destination/Recipient can be one or more of the following:

  • Any
  • DApp on a specific chain: Aggregation of different contracts using Fordefi’s DApp directory.
  • Internal vault or vault group
  • Address book entry or address group

Caveats

  • If a simulation for a transaction is not available, Fordefi will not match the recipient of the transaction.
  • If a user interacts with a smart contract that transfers funds to a third-party address using a DApp, Fordefi will match the address of the contract (and its corresponding DApp) as the recipient of the transaction, rather than the final destination of the funds.
  • Transactions with multiple recipients: on certain chains (most notably Solana and Sui), a transaction can have multiple recipients, where we define the set of recipients as the set of programs in each of the instructions of the transaction. For the policy to match the transaction, all of the recipients should appear in the rule.
  • Messages: certain messages have a recipient that can be matched by the policy, while others cannot. When a message does not have a recipient, it cannot be matched by any rule that specifies an explicit recipient. Therefore, to apply a policy rule to such message signatures, the recipient matcher in the rule must be left "Any". Specifically:
    • EVM personal messages do not have a recipient.
    • EVM typed data messages often specify an explicit recipient in the verifyingContract field. If so, Fordefi is able to match it as the recipient. When this field is missing, Fordefi is unable to match the recipient.
    • Messages on Cosmos, Solana, Sui, Aptos, and Bitcoin have no recipient.

Max amount

The Max Amount condition lets admins specify an amount in USD for the transaction. In case there is no dollar amount for the asset, the rule will not be matched.

The user can set whether they want the amount of the transaction to be calculated as “net”, meaning subtracting the any incoming transfer effects within the transaction from the outgoing amount of the transaction, or only the total outgoing amount. For example, if a user swaps $100 of USDC for $99.99 USDT, the outgoing amount of the transaction is $100, whereas the net amount is $0.01.

Caveat

  • Personal Message signatures are treated as if their amount is 0.

Cosmos message

Cosmos message refers to the specific instruction or action that users want to execute on the Cosmos blockchain. Messages can represent various types of actions, such as transferring tokens, voting on proposals, or delegating staking tokens to validators.

ABI

ABI defines how to encode and decode data to and from the EVM, enabling the execution of functions within smart contracts. It includes details such as function names, their parameters, and their return types. User can input the ABI in the 4bytes hash format so that Fordefi can check if the transaction matches the hash.

Asset

The Asset condition lets admins specify the token or tokens that the transaction is sending. For a rule to match a transaction, each of the outgoing (that is, sent) tokens in the transaction must appear in the list of tokens in the rule. For example, when swapping MATIC for USDC (that is, send 1 MATIC, get back 1.5 USDC), a rule that specifies MATIC would match the transaction, whereas a rule that specifies USDC would not.

Actions

After you set up a rule's conditions, specify the action that should be taken if all the conditions of the rule are fulfilled.

There are three action options:

  • Approve a transaction.
  • Block a transaction.
  • Require a transaction be approved by the approvers.

📘

Note

If a policy has multiple rules, they are applied in the order in which they appear in the list of rules.