Overview

The Fireblocks Policies is a set of rules that you define to govern outgoing transactions from your workspace and your connected external accounts. Your Policies allows you to control which workspace users can create, sign, or approve transactions 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 broadcasted to the blockchain
• Automatically block the transaction. It will not go to the blockchain
• Forward the transaction for approval to a specific designated approver or group of approvers

The 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. The Policies do not govern certain transactions within specific third-party accounts.

Who can manage your Policies?

Only your workspace Owner or other Admin users can manage your Policies. They use the Fireblocks Console’s Policy Editor to create and make ongoing changes to your Policies. Your Owner and Admin Quorum must approve any proposed Policy changes.

Default Policies

All newly created workspaces have five default Policy rules already in place. These rules allow you to securely complete certain transactions from day one. The first four default Policy rules:

• Allow contract call transactions of any asset to any whitelisted smart contract.
• Allow Web3 Approve transactions, enabling contract calls to withdraw your funds.
• Allow transfers of NFTs to any whitelisted address.
• Allow transfers of any USD amount of any asset to any whitelisted address.

The fifth default Policy rule is called the block-all rule. It is always the last rule at the bottom of your Policies. Unlike the first four rules above, you can’t remove this rule when you create your own Policy:

• Block any transaction that is not explicitly allowed by another Policy rule.

How Policies works

Your Policies are set up as a list of ordered rules that your workspace Admins must logically 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.

In the sections that follow, we describe:

• The two components of your Policy rules that tell your Policy Engine what to look for when scanning a transaction and what action to take next
• The first-match principle: a logical framework for how to order your Policy rules correctly so your policy is properly enforced

Policy rules

Policy rules have two components that you can define. Parameters determine how a transaction can match with the rule, then Actions tell the Policy Engine what to do next.

• Parameters: Define which characteristics a transaction must “match” for the rule to apply. Examples: 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 them must have user roles that are authorized to be approvers.
  • 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

Your Policies operate according to the first-match principle. For each submitted transaction, the Policy Engine scans your Policies from top to bottom and applies the first rule that it matches. It checks the top rule first. If it is a match, it performs that rule’s action. If not, it checks rule two, and so on.

For security, the default block-all rule is always the last rule at the bottom of your Policies. If no other rule matches a transaction, the block-all rule blocks it. Due to the first-match principle, setting rules up in the wrong order can cause unintended outcomes.

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 below workspace role and is part of the below workspace user group:

• Workspace user role: Signer. This role is authorized to sign transactions.
• Workspace user group: Traders. This is a custom group that John’s company created in their workspace. The group has all the traders, who all have 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 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, it sends a signing request 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 so they will be correctly applied based on 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 about both in creating rules using the Policy Editor.
  
• Put more restrictive rules first to ensure that they get correctly enforced.
  Example: You have two rules, both apply to the same transaction Initiator:
  • Rule one has a $1 million or above threshold and needs one approval.
  • Rule two has a $10 million or above threshold 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 for a transaction that big to need two approvers. If you list rule two first, you don’t have this issue.

Using user groups in Policy rules

User groups enable you to bundle multiple users together and apply rules to them, without needing to add new rules when you add or remove users. This allows you to simplify your Policies and use groups for key actions like initiating and approving transactions.

You can create groups based on either workspace or company roles to easily designate multiple users to initiate, approve or sign transactions based on their roles. Assigning groups for these parameters simplifies both creating rules and approval flows.

Your Admin Quorum and Owner must approve all new groups or changes to existing groups. 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.

See two more ways you can use user groups in rules below:

• 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.

Read user group management and best practices for detailed steps and guidelines.

Creating and managing user groups

Any workspace Admin can draft and submit new user groups or draft changes to existing user groups in your Fireblocks Console. Your Admin Quorum and Owner must approve all new groups or changes to existing groups.

You create and manage user groups in your Manage Groups page in your Fireblocks Console: 

Select Settings > Users > Manage Groups

Read user group management and best practices for a complete guide to creating and managing groups.