Rule Conditions and Actions

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 first set the rule's Action, which should be taken if all the conditions of the rule are fulfilled. There are three action options:

• Allow a transaction.
• Block a transaction.
• Require approval for a transaction. add conditions to any of the following:

Then, add any of the following conditions:

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 select which vaults or group of vaults 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)

Matchers and transaction types

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. The table below summarizes which options are applicable. See also the specifics of setting policy rules for message signatures.

Recipient

The Destination/Recipient condition lets admins set limits on the destination/recipient of the transaction. The recipient of a transfer is the address that receives the funds. For allowances, this is the address that receives the token allowance (that is, the spender). For contract calls, recipient is the destination address of the contract call.

A policy rule can specify the Destination/Recipient as 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

Cosmos message

A 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. Users can input the ABI in the 4-byte 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.

Amounts

The policy engine supports both transaction-level and periodic amounts.

Transaction amount

The Transaction Amount condition lets admins specify a maximal amount in USD for the transaction. For transfers, the amount is simply the amount of the transfer.

Determining the amount of a contract call is more subtle. First, since a contract call does not directly specify an amount, its value is simulation-based—derived from the transaction simulation results. Second, a single contract call can transfer multiple tokens both in and out of the vault. Fordefi aggregates the USD-value amounts of all the token transfers in the contract call in each direction: from the vault and into the vault. Token transfers that do not affect the vault are ignored. The transaction then has two associated amounts:

• The outgoing amount: the sum of the USD-value amounts of all the token transfers out of the vault.
• The net amount: the sum of the USD-value amounts of all the token transfers out of the vault, minus the sum of the USD-value amounts of all the token transfers into the vault.

For example, when 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. When setting up a rule, the user can choose whether to use the outgoing or net amount.

Periodic amount

The Periodic Amounts condition limits the total spending volume across all transactions within a specified period of time. For example, you can limit the maximum cumulative transaction volume for all users in your organization to $100,000 per day. Periodic amounts are based on the "net" (rather than "outgoing") amount of a transaction.

• Use the > or ≤ symbols to define the amount. To indicate a maximum amount, use ≤.
• Set a timeframe (sliding window from current time):
  • Hour
  • Day
  • Week
• Select one of the checkboxes for user scope:
  • Single user: The maximal settings will apply to a single, specified user only.
  • Cumulative: The maximal settings will apply to the organization as a whole.
• Select one of the checkboxes for vault scope:
  • Single vault: The maximal settings will apply to a single, specified vault only.
  • Cumulative: The maximal settings will apply to the organization as a whole..

Handling of various transaction states

• A transaction is counted towards the spending limit quota as soon as it is created. Until its completion, the amount is computed based on the transaction simulation. Once a transaction is completed, the amount is computed based on the actual amount as was executed on the blockchain.
• If a transaction is aborted, the amount of the aborted transaction is credited back to the quota.
• If a transaction is accelerated, only one instance of the transaction amount counts towards the quota, even though both the original and accelerated versions are pending.
• If a transaction is cancelled, the amount of the transaction is credited back to the quota as soon as the cancellation transaction is confirmed.

Handling of token allowances

Token allowances count both toward transaction-level and periodic spending limits. Unlimited allowances are handled specially: they require approval if they would exceed the periodic limit, but their value is not added to the running total to prevent a single unlimited allowance from consuming the entire limit and blocking all further transactions.

For example, with a policy allowing up to $1,000 daily spending without approval:

• Allowance of $400 → Auto-approved (total: $400)
• Give unlimited token allowance → Requires approval (because it represents potentially unlimited spending), but doesn't add to the running total
• Allowance $400 → Auto-approved (total: $800)
• Allowance $400 → Requires approval (total would be $1,200, exceeding the $1,000 limit)

Handling of missing amounts

In some cases, the amount of a transaction is not available. There are two main cases when this can happen. The first is when Fordefi does not have a USD price for a transferred token. (We generally take the prices from CoinGecko, so when a token is not listed on CoinGecko, we do not have a price. It often happens for more exotic tokens like LP Tokens.)

The second is when the transaction is a contract call, and we fail to estimate the amount of the transaction using transaction simulation. This can happen when the simulation is not supported for a specific chain, when the simulation fails, or when transaction reverts in simulation.

In both cases, the amount of the transaction is unknown, which makes it unclear how to evaluate a rule which conditions on the amount of a transaction. In this case, Fordefi evaluates the policy conservatively as follows:

• If a rule does not have an amount condition, the rule is matched as usual.
• If a rule has a ≤ ("less than or equal to") amount condition, the rule is not matched. The rationale is that the unknown amount might be above the limit in the rule.
• If a rule a > ("greater than") amount condition, the rule is matched out of an abundance of caution.