Overview

Your company's unique activities, security, and regulatory needs may cause you to build your Policies differently than other Fireblocks customers. Below is a range of basic operational and approval flows for common use cases that you can benchmark or use as a template.

Trading and treasury management examples

Example 1

There are three Policy roles users can be assigned to in transaction flows: Initiator, Approver, and Signer. In this example, a company only wants specific users to have these operational roles. Their Policy could look like this:

The Policy uses one basic rule to assign these functions.

1. Only members of a user group called Traders can initiate transactions.
2. Only users from a group called Management can approve the Trading group’s transactions. Only one member of that group needs to approve the transactions before they can be signed.
3. Only the Head of Trading can sign the transaction to the blockchain after approval.

The second rule is the block-all rule, the mandatory rule at the bottom of every Policy that blocks any transaction that does not explicitly match a rule above it.

Creating this Policy example using the Policy Editor

This is how you would create rule one above in the Policy Editor.

Your Policy will use more rules and parameters based on transaction values, Initiator types, and more. Example 2 below shows a more complete Policy for a trading business.

Example 2

Below are best practices to structure your workspace for trading and treasury management needs. To be competitive, you can set rules that enable your management team and traders to settle trades or rebalance quickly within limitations to manage risk.

In this example, the business needs both the Management and Trader user groups to transfer without approvals up to a certain value, requires custom approval flows for higher value transfers, and rejects all transfers if a pre-set aggregate limit exceeds an 8-hour window or per transaction.

Management group users also need less strict value thresholds and more flexibility than Traders group users regarding which types of accounts they can initiate transfers from.

Below are generic examples of Policy rules that meet these needs. Each rule is briefly explained beneath the image.

• Rules 1-3 are ordered by the highest Amount threshold to the lowest for transfers initiated by a Management group user. The most restrictive rules are listed first to ensure they're enforced based on the main principle called the first-match principle. Rules 4-5 do the same for Traders.
  • For Rule 1, selecting Per initiator when defining the $10 million within an 8-hour threshold ensures the rule will match only if the same user tries to transfer more than $10 million within 8 hours. If they do, approval from two members of the Management user group is required.
• Rules 4-5 apply different amount thresholds for the Traders group, and only per transaction instead of over a fixed period. Rule 4 ensures that one Management group user must approve if they request a transfer worth over $500,000. Rule 4 ensures that one Management group user must approve if they request a transfer worth over $500,000. For Rules 4-5, you must create the Withdrawal vault account listed under Source and Source Name before you create this Policy.
• Finally, Rule 6 is the block-all rule, blocking any transfer not explicitly allowed by this Policy. 

Submitting this Policy example using the Policy Editor

This is how you would submit Rule 1 above in the Policy Editor.

Web3 example

This example shows the basic best practices for structuring your workspace's Policy for decentralized finance (DeFi) and Web3 operations. If you use the Fireblocks WalletConnect integration or the Fireblocks Chrome Extension, you can create specific rules for contract call transactions with different restrictions and approval flows than with other transfer types.

Use contract call rules to implement custom policies for DeFi operations in case you have different risk and compliance needs for DeFi. Below are generic examples of rules.

Option A

Option B

1. Rule 1 in Option A approves contract calls to enable DeFi operations in your workspace.
   • Only Traders group users can initiate contract calls.
   • Only the DeFi Trading vault account can be the Source.
   • They can send contract calls to any contract address (Destination is set to Any, both Whitelisted+OTA). This allows maximum flexibility using Web3 protocols and liquidity pools, but is less secure. For maximum security, select Whitelisted Only to only allow contract calls with pre-whitelisted contracts.
   • Amount is blank because you cannot set amount limits for contract calls in your Policy. Instead, you use the separate Approve transactions - amount cap setting.
   • All contract call transactions to one-time addresses must be approved by one Management group user.
2. Alternatively, Rules 1-2* in Option B approve contract calls differently for Traders group users.
   • Rule 1 in Option B is the same as Rule 1 in Option A, except Destination is set to Whitelisted Only, and Action is set to Allow. This allows Traders group users to send contract calls to whitelisted addresses without requiring approval.
   • Rule 3 in Option B sets Destination to One-Time-Address Only. This allows Traders group users to send contract calls to one-time addresses with one Management group approval.
   • Rules 2 and 4 in Option B relate to Typed messaging signing for smart contract transactions for Fireblocks Console users.
3. Using Rules 2-4 in Option A (Rules 5-7 in Option B), the Management user group controls the funds in the DeFi Trading vault account. The most restrictive rules are first to ensure their restrictions are applied according to the first-match principle. They go from the highest to the lowest sum for the same users.
4. Rule 5 in Option A (Rule 6 in Option B) blocks any transfer not allowed by this Policy.
   
   *Rules 2 and 4 in Option B enable Typed messaging signing, which is the Fireblocks operation for signing standard off-chain messages (ETH Personal Sign and EIP-712). Signing an off-chain message that’s not a transaction is often required by Web3 applications.

Submitting this Web3 Policy example using Policy Editor

This is how you would submit Rule 1 from Option A above using Policy Editor.

Retail Policy example

Here we show basic best practices for structuring your Policy for retail operations. Retail businesses can use Fireblocks API to automate transfers to numerous retail users. With Policy, you can set limits and approval flows for API Signer user activity.

We recommend only giving certain users access to your omnibus treasury vault. You can apply Policy rules to an omnibus vault structure to streamline operations for your retail app by allowing instant transfers for API Signers. To tailor policies for high retail volumes, you can allow API Signers to sweep funds from your end client (intermediate) vault accounts to your Omnibus Deposits vault account and to withdraw from your Omnibus Withdrawals vault account.

You can also manage risk by setting custom approvals based on amount or time-based thresholds. An example of this structure is below, with custom rules for three user roles. Each rule is explained below. Note that if you use a two-withdrawal vault flow or a different vault structure than in this example, you should consider this when building your Policy.

1. Rule 1 blocks API Signer users from withdrawing from the Any vault account. Only Management and FinOps groups users can access it. 
2. The most restrictive rules are listed first to ensure they are enforced based on the first-match principle.
   • Rule 2 requires any transfer between vault accounts by API Signers above $50,000 to be approved by one FinOps group user. This rule, however, will get blocked by Rule 1 due to the first-match principle and because the parameters are the same.
   • Rule 3 allows API Signers to transfer any amount from $0-$50,000 between vault accounts without approval. This rule, however, will get blocked by Rule 1 due to the first-match principle and because the parameters are the same.
   • Rule 4 allows the API to transfer to the Fireblocks Gas Station without approval.
   • Rules 5-6 are similar to Rules 2-3, but more restrictive due to the Withdrawals Omnibus vault account being the source and external wallets the destination. Your user withdrawal wallets are often external wallets. It is up to you whether to whitelist them. In this example, some are not, but transfers are allowed because Destination is set to Whitelisted+OTA.
   • Rules 7-8 allow Management group users to transfer any amount between the Treasury and Withdrawals vault accounts with one other Management group user’s approval. This allows them to rebalance their vault accounts.
   • Rule 9 blocks the FinOps group from collectively transferring over $1 million within 24 hours by selecting Accumulate all under Accumulation.
   • Rules 10-12 allow FinOps group users to transfer certain amounts from any source to any destination with custom approval flows based on amount.
     1. In Rule 10, transferring over $100,000 requires approval from two FinOps users and one Management group user.
     2. In Rule 11, transferring $50,000 up -$100,000 requires the approval of two FinOps group users or one Management group user.
     3. In Rule 12, transferring $0-$50,000 requires one FinOps group user’s approval.
   • Rule 13 allows Juniors group users to transfer between vault accounts. Since Juniors group users have Editor roles, which cannot sign transactions, a Designated Signer is required.
   • Finally, Rule 14 blocks any transfer that is not explicitly allowed by this Policy.

Submitting this Retail Policy example using Policy Editor

Below shows you how to submit Rule 1 from above using the Policy Editor.

Embedded Wallets example

Within the Embedded Wallets (EW) realm, you may build a Policy that meets your criteria. There is no best practice, as one example that fits one business may not meet the expectations of another.

You may limit volumes per end-user wallet, set a limit on which dApps the end-user can interact with, or block them from interacting with certain assets.

To apply any wanted logic, you may use the End User wallet venue, which can be used both as source and destination.

Here is an example Policy that uses the End User Wallet venue:

Although the above example is simple, it introduces different possibilities within the Policy for end-user wallets.

1. Rule 1 limits an end user to trade Solana no more than $1,000 per day, regardless of the destination.
2. Rule 2 limits an end user to trade Ethereum (Sepolia) no more than $2,000 per day, regardless of the destination.
3. Rule 3 allows end users to trade BTC, with no limits.
4. Rule 4 allows end users to trade with a special token only between themselves within the app ecosystem.
5. Rule 5 allows connecting to only a specific dApp, using Contract Whitelisting.