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.
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):
| Transaction type | Description |
|---|---|
| Approve | Allows a third party to withdraw from a designated wallet. |
| 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 the Payments feature. |
| dApp connection | Connects your Fireblocks vault or wallet to a decentralized application (dApp) to interact with it. |
| 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. Commonly used with the Payments feature. |
| 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. |
| 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. |
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. The tables below show which fields apply to each operation 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. |
| 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. |
| Source | The origin account or vault from which funds or the transaction will be initiated. Applies to all operation types. Required. |
| 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. |
| 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. 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. 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. |
| 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. |
| Action Options | Defines what happens when a transaction matches all the criteria specified in the rule. Applies to all 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. |
| Contract Call Method | Specifies which smart contract function or method the rule applies to. Applies to: Contract Call only. |
| Program Calls Filter | Controls which Solana programs can be called through this policy rule. Applies to: Program Call only. |
| dApp Selector | Specifies which decentralized application (dApp) the connection rule applies to. Applies to: dApp connection only. |
| Fungible Tokens vs NFTs | Transfer rules can distinguish between fungible token transfers and non-fungible token (NFT) transfers. Applies to: Transfer only. |
Scope fields by operation type
| Operation type | Rule Name | Initiator | Source | Destination |
|---|---|---|---|---|
| Approve | ✓ | ✓ | ✓ | * (address type filter) |
| Burn | ✓ | ✓ | ✓ | ✗ |
| Contract Call | ✓ | ✓ | ✓ | * (address type filter) |
| Convert | ✓ | ✓ | ✓ | ✓ |
| dApp connection | ✓ | ✓ | ✓ | ✗ |
| Deployment | ✓ | ✓ | ✓ | ✗ |
| Mint | ✓ | ✓ | ✓ | * (address type filter) |
| Order | ✓ | ✓ | ✓ | ✓ |
| Program Call | ✓ | ✓ | ✓ | ✗ |
| Raw | ✓ | ✓ | ✓ | ✗ |
| Stake | ✓ | ✓ | ✓ | * (address type filter) |
| Transfer | ✓ | ✓ | ✓ | * (address type filter + fungible/NFT) |
| Typed message | ✓ | ✓ | ✓ | ✗ |
| Vault account upgrade | ✓ | ✗ | ✓ | ✗ |
Funds fields by operation type
| 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 and special fields by operation type
| 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.
The five default rules are:
- Transfer Policy: Allow transfers of NFTs to any whitelisted address, which includes vault accounts.
- Transfer Policy: 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 always the last rule at the bottom of each Policy and cannot be removed 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, edit, and publish a Policy — 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 examples — Review common use cases