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 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)

    📘

    Note

    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.

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

📘

Notes

  • 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 you 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 as "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 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.

📘

Note

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

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.

Periodic Amounts

The Periodic Amounts condition limits the spending volume of a transaction for 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.

  • Use the > or symbols to define the amount. To indicate a maximum amount, use .
  • Set a timeframe:
    • 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..

📘

Notes

  • Accelerated transactions do not effect your quota.
  • Cancelled transactions are not marked completed, so Fordefi does not reset the cumulative counter.
  • Aborted transaction are deducted from the quota within the timeframe.
  • Allowance transactions will always count as 0 towards the daily limit. Meaning, it will not add the allowance amount and be counted against the limit.
  • When the cumulation set in the velocity control reaches the specified amount within the specified time window, whether by one or many transactions, then the rule will match and will be determined based on the action selected: if blocked, they will be blocked; if they require approval, they will require approval.
  • Amounts are always counted as "net" and not outgoing towards the quota.

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:

  • Allow a transaction.
  • Block a transaction.
  • Require approval for a transaction.

📘

Note

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