Important
Implementing the correct Policies is critical to protecting your assets. Policies are your primary security control in your workspace. You must read these guidelines carefully to understand how Policies work before implementing your own.
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 P2P Network connections, or whitelisted addresses. Policies do not govern certain transactions within specific third-party accounts.
Policy types
You can create distinct Policies for each of the following transaction types (also known as categories) shown in the collapsible table below:
Transaction Types
Transaction Type |
Description |
| Approve | Allows a third party to withdraw from a designated wallet. Learn more here. |
| Burn | Burns tokens. Typically used with ERC-20 smart contracts. |
| Contract Call | Calls a smart contract, mainly for DeFi operations. |
| 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. |
| dApp connection | Connects your Fireblocks vault or wallet to a decentralized application (dApp) to interact with it. Learn more here. |
| Deployment | Allows a smart contract to be deployed from your workspace to the blockchain for interaction. |
| Mint | Mints new tokens. Typically used with ERC-20 smart contracts. |
| Order | Controls who can buy, sell, and settle assets between external bank accounts, provider accounts, and your workspace. Learn more here. |
| Program Call | Calls a Solana Program, mainly for DeFi operations. |
| Raw | For workspaces with Raw Signing enabled, you can sign any message using your private key. |
| Stake | Allocates and locks certain assets for earning staking rewards. Learn more about Staking on Fireblocks. |
| Transfer | Transfers funds from one account to another. |
| Typed message | Controls signing of off-chain messages (for example, EIP-712) and on-chain transactions that are not executed through Contract Calls (EVM) or Program Calls (Solana). |
| Vault account upgrade | Enables a vault to send transactions without paying gas fees by allowing a designated relayer to cover those costs. Learn more here. |
Note
Raw Signing, Mint, and Burn are premium features that require an additional purchase. Contact your Customer Success Manager or complete this form before creating rules for these options.
Configurable fields by operation type
When creating policy rules in Fireblocks, different operation types support different configurable fields. Use the field descriptions and tables below to understand which fields are available for each transaction type.
Field Descriptions
| Field Name | Description |
|---|---|
| Rule Name |
A descriptive name for the policy rule that helps identify
its purpose. Applies to: All operation types Required: Yes |
| Initiator |
Specifies which user or user group can initiate the transaction.
Controls who has permission to start this type of operation. Applies to: All operation types except Vault account upgrade Required: Yes |
| Source |
The origin account or vault from which funds or the transaction
will be initiated. Applies to: All operation types Required: Yes |
| Destination |
The target account, address, or contract where funds will
be sent or where the transaction will be executed. Applies to: Transfer, Approve, Contract Call, Stake, Mint, Order, Convert Not applicable to: Burn, Deployment, Program Call, Raw, Typed message, dApp connection, Vault account upgrade Address Type Filter (*): Available for Transfer, Approve, Contract Call, Stake, and Mint. Options include: • All addresses: Any destination address is allowed • Whitelisted addresses: Only pre-approved addresses on your whitelist • One-time addresses only: Addresses used only once |
| Asset |
The cryptocurrency or token type that the rule applies to
(e.g., BTC, ETH, USDC). Applies to: Transfer, Approve, Burn, Contract Call, Deployment, Mint, Raw, Stake, Typed message Not applicable to: Convert, dApp connection, Order, Program Call, Vault account upgrade Note: For Order and Convert operations, asset control is handled through Base asset and Quote asset fields instead. |
| Amount |
Sets the minimum transaction amount value that this rule
applies to. Includes both a numeric value and currency denomination. Applies to (*): Transfer, Approve, Burn, Contract Call, Deployment, Mint, Stake Not applicable to: Convert, dApp connection, Order, Program Call, Raw, Typed message, Vault account upgrade Components: Minimum amount field + Currency selector (USD, EUR, etc.) |
| Limitation |
Adds an extra layer of security by limiting the rule's applicability
based on transaction frequency or time constraints. Applies to: Transfer, Approve, Burn, Mint, Stake Not applicable to: Contract Call, Convert, dApp connection, Deployment, Order, Program Call, Raw, Typed message, Vault account upgrade Options: • Limit to single transaction: Rule applies only once per transaction • Limit to specific time: Rule is active only during a defined time period |
| Action Options |
Defines what happens when a transaction matches all the criteria
specified in the rule. Applies to: All operation types Available actions: • Block: Automatically reject the transaction • Allow: Automatically approve the transaction • Request approval: Require manual approval from designated approvers (available for most operation types) Note: dApp connection, Order, and Vault account upgrade only support Block/Allow actions. |
| Connected Account |
Specifies which connected exchange account or fiat account
the rule applies to. Applies to: Order, Convert only |
| Base Asset & Quote Asset |
Controls which trading pair the rule applies to, with minimum
and maximum thresholds for each asset. Applies to: Order, Convert only Components: • Base asset: The asset being bought or sold (with Min/Max fields) • Quote asset: The asset used for pricing (with Min/Max fields) • Buy/Sell/Any tabs: Specify whether the rule applies to buy orders, sell orders, or both |
| Contract Call Method |
Specifies which smart contract function or method the rule
applies to when calling a contract. Applies to: Contract Call only Purpose: Allows you to create granular rules for specific contract interactions |
| Program Calls Filter |
Controls which Solana programs can be called through this
policy rule. Applies to: Program Call only Options: • Any: Allows calls to any Solana program • Whitelisted only: Restricts calls to pre-approved programs on your whitelist |
| dApp Selector |
Specifies which decentralized application (dApp) the connection
rule applies to. Applies to: dApp connection only Purpose: Controls which dApps users can connect to from specific source accounts |
| Fungible Tokens vs NFTs |
Transfer rules can distinguish between fungible token transfers
and non-fungible token (NFT) transfers. Applies to: Transfer only Options: • Fungible tokens or coins: Standard cryptocurrency and token transfers • Non-fungible tokens (NFTs): Transfers of unique digital assets |
Field applicability by operation type
The following tables show which fields apply to each policy operation type:
Legend: ✓ = Applies | ✗ = Does not apply | * = Conditional/Special options
Scope Fields
| Operation Type | Rule Name | Initiator | Source | Destination |
|---|---|---|---|---|
| Approve | ✓ | ✓ | ✓ | * |
| Burn | ✓ | ✓ | ✓ | ✗ |
| Contract Call | ✓ | ✓ | ✓ | * |
| Convert | ✓ | ✓ | ✓ | ✓ |
| dApp connection | ✓ | ✓ | ✓ | ✗ |
| Deployment | ✓ | ✓ | ✓ | ✗ |
| Mint | ✓ | ✓ | ✓ | * |
| Order | ✓ | ✓ | ✓ | ✓ |
| Program Call | ✓ | ✓ | ✓ | ✗ |
| Raw | ✓ | ✓ | ✓ | ✗ |
| Stake | ✓ | ✓ | ✓ | * |
| Transfer | ✓ | ✓ | ✓ | * |
| Typed message | ✓ | ✓ | ✓ | ✗ |
| Vault account upgrade | ✓ | ✗ | ✓ | ✗ |
Funds Fields
| Operation Type | Asset | Amount | Limitation |
|---|---|---|---|
| Approve | ✓ | * | ✓ |
| Burn | ✓ | * | ✓ |
| Contract Call | ✓ | * | ✗ |
| Convert | ✗ | ✗ | ✗ |
| dApp connection | ✗ | ✗ | ✗ |
| Deployment | ✓ | * | ✗ |
| Mint | ✓ | * | ✓ |
| Order | ✗ | ✗ | ✗ |
| Program Call | ✗ | ✗ | ✗ |
| Raw | ✓ | ✗ | ✗ |
| Stake | ✓ | * | ✓ |
| Transfer | ✓ | * | ✓ |
| Typed message | ✓ | ✗ | ✗ |
| Vault account upgrade | ✗ | ✗ | ✗ |
Action & Special Fields
| Operation Type | Action Options | Special Fields |
|---|---|---|
| Approve | Block / Allow / Request approval | Address type filter |
| Burn | Block / Allow / Request approval | None |
| Contract Call | Block / Allow / Request approval | Contract call method, Address type filter |
| Convert | Block / Allow / Request approval | Connected account, Buy/Sell/Any tabs, Base asset, Quote asset (with Min/Max) |
| dApp connection | Block / Allow | dApp selector |
| Deployment | Block / Allow / Request approval | None |
| Mint | Block / Allow / Request approval | Address type filter |
| Order | Block / Allow | Connected account, Buy/Sell/Any tabs, Base asset, Quote asset (with Min/Max) |
| Program Call | Block / Allow / Request approval | Program calls filter (Any / Whitelisted only) |
| Raw | Block / Allow / Request approval | None |
| Stake | Block / Allow / Request approval | Address type filter |
| Transfer | Block / Allow / Request approval | Address type filter, Fungible tokens vs NFTs tabs |
| Typed message | Block / Allow / Request approval | None |
| Vault account upgrade | Block / Allow | Simplified rule (only 2 fields) |
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.
Policy rules
Policy rules have two components: Parameters define which characteristics a transaction must match for the rule to apply (such as who can initiate it, where it goes, and which assets), and Actions define what happens next (allow, block, or require approval). Learn more about How Policies Work.
How the Policy Engine works
The Policy Engine applies rules using the first-match principle by scanning your Policy from top to bottom and applying the first rule that matches the transaction. Because of this, rule order matters; place more restrictive rules before less restrictive ones. Learn more about How Policies Work.
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.
Important
Since default Policy rules only apply to whitelisted addresses, default rules are only effective when at least one address is whitelisted.
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.
Note
If your operational needs require more functionality from day one, we recommend creating your own Policies before making any transfers. Customizing your Policies immediately deletes the default rules. Deleting your custom Policies reinstates the default rules and their Policies.
Using user groups in Policy rules
User groups enable you to apply rules to sets of multiple users, simplifying your Policies and reducing the need to revise them as your team changes. Learn more about User group management and best practices.
Next steps
- How Policies Work - Learn about the first-match principle and rule ordering
- Create a Policy Rule - Start building your first Policy rule
- Policy Best Practices - Follow recommendations for effective Policy management
- Policy Rule Parameters - Reference guide for all available parameters
- Policy Rule Examples - Review some common use cases