Overview

Fireblocks Policies are sets of rules that you define to govern the transactions and other actions initiated within your workspace. Your Policies allow you to control which financial activities are allowed or restricted in your workspace by creating rules across a set of customizable parameters. 

The Fireblocks Policy Engine automatically applies your Policies to all transactions created from the Fireblocks Console or Fireblocks API. After a workspace user initiates a transaction, your Policy rules define which actions the Policy Engine will take:

• Automatically allow the transaction and forward it to be signed and broadcast to the blockchain.
• Automatically block the transaction and prevent it from being signed and broadcast to the blockchain.
• Forward the transaction for approval to a specific approver or approval group.

Your Policies govern transfers from your connected third-party main accounts to other destinations, including other exchange, fiat, or vault accounts, Fireblocks Network connections, or whitelisted addresses. Policies do not govern certain transactions within specific third-party accounts.

Types of Policies

You can create distinct Policies for each of the following transaction types:

• Transfer: Transfers funds from one account to another.
• Stake: Allocates and locks certain assets for earning staking rewards. Learn more about Staking on Fireblocks.
• Convert: Converts an asset into a different asset in a specific centralized exchange or fiat account. These transactions are commonly used with our Payments feature.
• Contract Call: Calls a smart contract, mainly for DeFi operations.
• Program Call: Calls a Solana Program, mainly for DeFi operations. 
• Typed message: Off-chain messages used to sign specific messages, primarily when connecting wallets to Web3 decentralized applications (dApps).
• Approve: Allows a third party to withdraw from a designated wallet. Learn more about approvals.
• Mint: Mints new tokens. Typically used with ERC-20 smart contracts.
• Burn: Burns tokens. Typically used with ERC-20 smart contracts.
• Raw: For workspaces with Raw Signing enabled, you can sign any message using your private key.

Who can manage Policies?

Only your workspace Owner or other Admin-level users can manage Policies. They use the Fireblocks Console to create and make ongoing changes to your Policies. Your assigned approval group must approve any proposed Policy changes.

How Policies work

Policies are a list of ordered rules that your workspace Admins must define and maintain. For any submitted transaction, the Fireblocks Policy Engine determines whether to automatically allow it, automatically block it, or which approval flow to trigger based on specific details you include in your Policy rules and how you order them.

Policy rules

Policy rules have two components that you can define: 

• Parameters: Define which characteristics a transaction must “match” for the rule to apply. 
  • Scope: Who can initiate it? Where can it go to or from? Which asset is the rule for?
• Actions: Define what will happen next out of the following options:
  • Allow: The Policy Engine automatically approves and forwards to a designated signer.
  • Approved by: Other users or user groups must approve or deny the allowed transaction. All of the associated user roles must be authorized approver user roles.
  • Block: The Policy Engine automatically blocks the transaction.

A sample rule is below. Your Policies include multiple ordered rules similar to this one. The Policy Engine compares transactions against your Policies before you can sign them to the blockchain.

The first-match principle

Policies operate according to the first-match principle. For each submitted transaction, the Policy Engine scans the appropriate Policy from top to bottom and applies the first rule that it matches. The scan stops after a successful match. The top rule is checked first. If it is a match, it performs the rule’s action. If not, rule two is checked, and so on.

Due to the first-match principle, the order of your rules is important for receiving the intended outcomes. For example, you may not want to place a rule that allows any transfer in any amount at the top of your Transfer Policy since most transactions would be allowed without needing to meet the stricter requirements in the other rules. Rules with overlapping parameters should be ordered so that higher priority rules are scanned first.

For security, the default block-all rule is always the last rule at the bottom of each Policy. If no other rule matches a transaction, the block-all rule blocks it. 

Example: Policy Engine applies the first-match principle to a transaction

John Smith, a trader at company XYZ, submits a transaction. In his company’s workspace, he is assigned the following workspace role and user group:

• Role: Signer, authorized to sign transactions.
• User group: Traders, a custom group that John’s company created in their workspace. The group has all traders with Signer roles.

John submits a transfer request for $500,000 of Bitcoin from his vault account to one of his whitelisted counterparties. His company’s Transfer Policy has the four rules shown below:

After John submits the transfer request, the Policy Engine:

1. Skips rule one, which only applies when a Management group user is Initiator.
2. Skips rule two, which only applies to transactions greater than $1 million.
3. Applies rule three because the transaction matches each of its parameters.
4. Sends the request to the approver that is defined under Action. Select Require approval of to see the name of the designated approver. For this rule, it is the Head of Trading.
5. After the Head of Trading approves the transaction, a signing request is sent to the Designated Signer.

Since rule three sets Initiator as Designated Signer, John can then sign the transaction himself. Read Policy examples to learn how to create tailored sets of rules for various common business use cases.

Ordering your rules

It’s important to put rules in order from the most restrictive rules to the least restrictive rules to correctly apply the first-match principle. The order of rules can affect whether or not the Policy Engine properly enforces your Policy rules.

For example:

• Put time period-based rules before single-transaction rules. Doing this ensures that time-based restrictions get enforced. Learn more about creating your Policy.

• Place more restrictive rules first to ensure proper enforcement.
  Example: You have two rules, both apply to the same transaction Initiator:
  • Rule one has an amount range with a $1 million minimum, no maximum, and needs one approval.
  • Rule two has an amount range with a $10 million minimum, no maximum, and needs two approvals.
    
    
    
• List the more restrictive rule (rule two) first so the Policy Engine enforces its stricter threshold and approval flow. If not, rule two won’t get enforced. A specific example:
  • If rule one is listed first, a $20 million transaction would match it and only need one approval. However, the intent of rule two is that a transaction that big needs two approvers. If you list rule two first, you don’t have this issue.

Default Policies

All newly created workspaces have five default Policy rules already in place. Four of the default rules apply to specific Policy types, while the fifth rule applies to all Policies. Together, these rules allow you to securely complete certain transactions from day one. Default Policies are grayed out and are active only when you don’t have any other Policy rules set.

Below are the descriptions of each default rule’s actions.

Transfer Policy

• Allow transfers of NFTs to any whitelisted address, which includes vault accounts.
• Allow transfers of any USD amount of any asset to any whitelisted address, which includes vault accounts.

Contract Call Policy

• Allow contract call transactions from any wallet on any blockchain to any whitelisted smart contract.

Approve Policy

• Allow Web3 Approve transactions, enabling contract calls to withdraw your funds.

All Policies

• Block any transaction that is not explicitly allowed by another Policy rule.
  • This rule is the last rule at the bottom of each Policy. Unlike the first four rules above, you can’t remove this rule when you create your own Policies.

Using user groups in Policy rules

User groups enable you to apply rules to sets of multiple users without needing to add new rules when the users change. This allows you to simplify your Policies and use groups for key actions like initiating and approving transactions.

You can create groups based on workspace user roles or internal company roles to easily designate multiple users to initiate, approve, or sign transactions based on those roles. Assigning groups for these parameters simplifies both creating rules and approval flows. As your company grows or changes, group-based rules help reduce how often you must revise your Policies.

You can also define approval quorums within a group as part of the Approved by action for a rule. For example, you can make a rule that requires any two members of a user group called Management to approve if a transaction matches that rule's parameters.

Two more ways you can use user groups in rules:

• The workspace Owner can initiate a certain type of transfer, but at least one other member of the Admins user group must approve.
• Any member of the Admins user group can initiate a certain type of transfer.

Learn more about User group management and best practices for detailed guidelines and steps to create and manage user groups.