This page 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 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.
These are the conditions you can define for the policy rule:
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.
The Origin condition lets admins select which vaults or group of vaults will be part of the rule.
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 three types:
- EVM Personal message
- EVM Typed data message
- Non-EVM message
- Black-box signature: Signing any arbitrary buffer (on black-box vaults only)
- Contract deployment: Deploy a smart contract to the blockchain.
- In-app swap: Swapping using in-app integrated DEX aggregators, encapsulates the required allowance transaction, as well.
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.
| Type | Subtype | Origin | Initiator | Recipient | Amount | Periodic amount | Asset | ABI | Cosmos Message | EVM Typed Message |
|---|---|---|---|---|---|---|---|---|---|---|
| Contract Call | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | x | |
| Transfer | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | x | x | x | |
| In-app swap | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | x | x | x | |
| Allowance | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | x | x | x | |
| Message | EVM Typed Data | ✓ | ✓ | ✓ | x | x | x | x | x | ✓ |
| EVM Personal Message | ✓ | ✓ | x | x | x | x | x | x | x | |
| Non-EVM | ✓ | ✓ | x | x | x | x | x | x | x | |
| Black box | ✓ | ✓ | x | x | x | x | x | x | x |
The 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.
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.
A policy rule can specify the Destination/Recipient as one or more of the following:
- Address book entry or address group
- Internal vault or vault group
- DApp on a specific chain: Aggregation of different contracts using Fordefi’s DApp directory.
- Custom address
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.
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.
The policy engine supports both transaction-level and periodic amounts.
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.
The Periodic Amount condition limits the total spending volume across all transactions within a specified period of time. It allows you to choose between the limit being applied to the cumulative amount of all users collectively, or for the amount of each user separately. 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):
- Hourly
- Daily
- Weekly
- Monthly (every 30 days)
- Select one of the user options:
- Per user: The maximal settings will apply to a single, specified user only.
- All users: The maximal settings will apply to the organization as a whole.
- 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.
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)
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.
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 name. Users can input the ABI in the 4-byte hash format so that Fordefi can check if the transaction matches the hash.
Quickly retrieve the hash for the smart contract by visiting Etherscan (or other block explorer) and clicking the corresponding Copy button.
See Set Policy Rules for Message Signatures to learn more.
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.
For example, suppose you wish to set a policy that requires different approval quorums for claiming staking rewards versus un-delegating your staked assets. This can be done by setting fine-grained policy rules on the MsgUndelegate message-level.
