The TAP rule parameters are described in greater detail below. The range of configurations for each parameter gives you flexibility and strong controls for your transaction workflows.

Initiator

Defines users who can initiate the type of transaction to which the rule applies. Only users with the below workspace roles can be Initiators:

• Owner
• Admin
• Non-Signing Admin (requires a Designated Signer)
• Signer
• Editor (requires a Designated Signer)

You can configure Initiator in different ways for a rule, such as:

• Individual or multiple users: one or more individual users listed by name
• User groups: a specific user group or multiple groups. When you specify a user group, all of its users must have the same role type. For example, Editors can't be in a user group with Signers.
• Any: applies to all users in your workspace.

Type

Defines the type of transaction to which the rule applies. Select one of the following types:

• Transfer: transfers funds from one account to another.
• Mint: mints new tokens. Typically used with ERC-20 smart contracts.
• Burn: burns tokens. Typically used with ERC-20 smart contracts.
• Contract Call: calls a smart contract, mainly for DeFi operations.
• Raw: off-chain messages with no predefined format. Use it to sign any message with your private key. It is exclusively initiated by API.
• Typed message: off-chain message type that follows a predefined format. Used to sign specific messages that are not actual transactions. It is mainly used for certain web3 dApps that require you to sign off-chain messages.
• Approve: allows a smart contract to withdraw from a designated wallet. Learn more.
• Stake: allows you to allocate and lock certain assets for earning staking rewards. Learn more.
  

  Note

  Raw signing, Mint, and Burn are premium features and require additional purchase. Contact your  Customer Success Manager or complete this form before creating rules for these options.

Source

Defines the type of venue or wallet the rule allows transfers to originate from. The options are:

• Any
• Vault Account: specific vault account (must already be created in your workspace)
• Any Vault Account: any vault account
• Any End User Wallet: any end user wallet
• Exchange: specific exchange account (must already be linked to your workspace)
• Any Exchange: any exchange account
• Fiat Account: specific BCB account (must already be connected)
• Any Fiat Account: any BCB fiat account

When selecting multiple sources, there is no shortcut to select sub-groups of similar types of vaults. You must either choose “All Vaults” or individually select all vaults you wish the rule to apply for.

Source Name

Defines the specific account that the transaction's source must be. To choose a specific vault account, enter its name. Make sure it's already created or connected to your workspace before you make rules for it. If you select an Any... source, this doesn't apply.

Destination

Defines the type of venue or wallet the rule allows transfers to:

• Any
• Any Vault Account: any of your Fireblocks vault accounts
• Vault Account: specific vault account (must already be created in your workspace)
• Any End User Wallet: any end user wallet
• Any Exchange: any exchange account linked to your workspace
• Exchange: specific exchange account (must already be linked to your workspace)
• Any Network: any of your Fireblocks Network connections
• Network: a specific Fireblocks Network connection (must already be connected)
• Any Internal Wallet: any whitelisted internal wallet in your workspace
• Internal Wallet: specific whitelisted internal wallet in your workspace (must already be created and whitelisted in your workspace)
• Any External Wallet: any whitelisted external wallet in your workspace
• External Wallet: specific whitelisted external wallet in your workspace (must already be whitelisted in your workspace)
• All Contract Wallets: any whitelisted smart contract address
• Contract: a specific whitelisted smart contract address
• Any Fiat Account: any BCB account
• Fiat Account: specific BCB account (must already be connected)
• All Staking destinations: any of the staking destinations (only available when creating a Stake rule)
• Staking destination: a specific staking destination, such as a validator address (only available when creating a Stake rule)

When selecting multiple destinations, there is no shortcut to select sub-groups of similar types of vaults. You must either choose “All Vaults” or individually select vaults you wish the rule to apply for.

Destination Name

Defines the specific account the transaction's destination must be. To choose a specific vault account, enter its name. Make sure it's already created or connected to your workspace before you make rules for it. If you select an Any... destination, this won’t apply.

Whitelisted / OTA

Defines whether the destination to which you are sending funds must be whitelisted, to allow one-time transfers to non-whitelisted external addresses, or both. By default, you can only transfer to an external address after it’s whitelisted. To allow transfers to a non-whitelisted external address, enable the one-time address feature and create a rule for that external address.

• Whitelisted only: can only be sent to whitelisted addresses
• One-time address only: can only be sent to non-whitelisted external addresses
  

  Important

  Selecting one-time address only blocks transactions to whitelisted addresses. If you want the flexibility to also transfer to whitelisted addresses, select Whitelisted+OTA which is the better choice to avoid unintended blocked transactions.

• Any (Whitelisted+OTA): can be sent to whitelisted addresses or non-whitelisted external addresses on a one-time basis. Mostly used related to DeFi operations.

By default, if your TAP contains rules for external addresses but doesn't allow one-time transfers, then transfers matching those rules will be automatically blocked.

Minimum

Defines the value a transaction must exceed for the rule to apply to it. You can enter it two ways:

• Native amount: Limits the amount of an asset a user can transfer when using a specific asset. Example: A rule for transactions for any amount greater than 5 BTC. Only select this value for rules limited to a single asset.
• Fiat amount: Limits the amount of any asset users can transfer based on the USD or EUR equivalent of the asset. Example: A rule for transactions that use any amount greater than $5,000 worth of any asset.

We recommend using rules with fiat amount values. This allows you to apply rules to all your assets simultaneously and to give better visibility into your operations. We use CoinMarketCap to determine an asset's USD and EUR equivalent.

Time Period

Defines over what length of time to accumulate transferred amounts in transactions that match the rule, until the total exceeds the value you specify under Minimum.

When the specified amount is reached within that period, whether by one or many transactions, further transactions in that period either fail or require more approvals. You can choose these options:

• Single Tx: applies the rule when a single transaction meets the rule's criteria
• 4hrs, 8hrs, 12hrs, 24hrs, 48hrs, 72hrs, 1wk, 2wk: applies the rule when accumulation reaches the specified amount during the specified period, whether by one or many transactions. You can select a period from the default values or enter an hour period (e.g., 1hr, 2hrs, 10hrs). The maximum period you can enter is 360 hours.

Accumulation

Defines the method by which the Policy Engine calculates accumulation. It uses the Initiator, Source, and Destination to calculate accumulation toward the value under Minimum, for the time under Time Period. You can set accumulation to count individually across each parameter (per + per + per), collectively for one or more parameters (per + per + accumulated), or collectively for all parameters.

The different options for how the Policy Engine calculates accumulation are detailed below:

• Initiator: Select Per Initiator to apply the limit to each listed Initiator. Select Accumulated initiators to apply the limit to the sum of all Initiators’ transactions.
• Source: Select Per source to apply the limit to each listed Source. Select Accumulated sources to apply the limit to the sum of all transactions from all listed Sources.
• Destination: Select Per destination to apply the limit to each listed Destination. Select Accumulated destinations to apply the limit to the sum of all transactions to all listed Destinations.

For example, let's say you have a rule in which three initiators can't transfer more than $1 million within four hours from any source to any destination.

• When you select a Per Initiator... value, each Initiator can transfer up to $1 million, for a collective total of $3 million, every four hours.
• When you select an Accumulated Initiators... value, the three Initiators can collectively transfer up to $1 million every four hours.

Asset

Defines the type of asset being transacted. Selecting NFT applies the rule to all non-fungible tokens (NFTs). If you select Asset, enter a specific asset or select Any to apply the rule to any asset (excluding NFTs) in your workspace used in a transaction matching the rule. If the asset you want is not supported, learn how to add EVM-based assets.

Action

Defines what occurs when a transaction meets the rule's criteria:

• Allow: The transaction goes through and can be signed without requiring additional approvals.
• Block: The transaction is automatically blocked.
• Approved by: Only these users or user groups can approve. If any of them reject the transaction before the required approval threshold is met, the transaction doesn't go through.

Approved By

Defines who can approve transactions that match the rule. Specify whether a single user can approve or if an approval threshold must be met, for example, 3 approvers from Group 1). You can list multiple users or user groups to create more approval layers. The only user roles that can be Approvers are Owner, Admin, Non-Signing Admin, Signer, or Approver.

By default, when a transaction initiator is also a listed approver (individually or as part of a group), they can't approve their own transaction and won't count toward the approval threshold. To enable their own approval to be counted, check the box Initiator Counts as Approver.

Initiator Counts as Approver

Defines whether the user who initiates a transaction can approve their own transaction and count toward the approval threshold for their transaction. Select either:

• No: Can’t approve their own transactions and don't count toward their transaction’s approval threshold when they’re part of a group listed under Approved By
• Yes: Can approve their own transactions and counts toward their transaction’s approval threshold when they’re part of a group listed under Approved By

Designated Signers

This parameter allows you to designate a specific user, multiple individual users, or user groups as a signer for transactions that match the rule. For example, you can create a semi-automated flow for API users that allows them to be Initiators but requires another user to sign the transaction.

Rules with multiple signers

When a transaction matches a rule with multiple designated signers, Fireblocks sends a signing request notification to each user specified as a designated signer. However, only one user needs to sign the transaction. Once the transaction is signed, Fireblocks automatically removes the notification from all other signers’ devices (or queues, for API users).

Designated Signers for Online Workspaces

In online workspaces, only users with the following workspace roles can be designated signers:

• Owner
• Admin
• Signer

You can use any combination of user types as designated signers in online workspaces. For example, you can have one Fireblocks mobile app user and one API user, user groups containing all mobile app users and all API users, or user groups containing a mixture of mobile app users and API users.

Designated Signers for Offline Workspaces

Like in an online workspace, you can assign multiple designated signers to TAP rules in an offline workspace. However, there are some restrictions in place to help with overall security:

• The Source parameter must be a vault account.
• Designated signers (whether an individual or as part of a group) can only be Fireblocks mobile app users with the Signer role who have completed their user setup for the offline workspace.