Fireblocks policy rules for DALP vaults in each signing mode

A Fireblocks workspace decides whether each DALP signing request runs, waits for approvers, or stops. It decides with its policy, the ordered list of rules Fireblocks calls the Transaction Authorisation Policy. This page lists the rules each DALP vault needs and what a Fireblocks rule cannot see once account abstraction is on.

A wrong policy stops DALP in one of two ways. A missing allow rule blocks every request from a vault. An approval rule on a vault that must sign without a person fails every sponsored operation, for every user, until someone changes the rule. Both appear on the first transaction after the policy changes, so set the policy before you onboard investors and test it with one transfer per mode.

DALP signs in one of two modes. With account abstraction off, each wallet is a Fireblocks vault, and the vault sends its own transactions. With account abstraction on, each wallet is a Smart Wallet, a contract account under ERC-4337. The Fireblocks vault then holds only the wallet's owner key and signs user operations, the signed instructions that the Smart Wallet executes. Two shared vaults sign for every user: the paymaster vault signs the ticket that lets DALP pay gas for an operation, and the bundler vault submits user operations to the chain.

DALP signs as one Fireblocks API user, whose API key and private key it holds, as Prerequisites lists. Whatever your approval rules do not catch, the allow rule for that API user passes without a person, so your approval rules are the only check between DALP and a signature.

What a Fireblocks policy can read in each DALP signing mode.

Rules per vault

Mode	Vault	Fireblocks rule type	Settings
Account abstraction off	Each vault that holds investor tokens	Contract Call	Source: the vault. Asset: the DALP token. Amount: the range that needs approval. Destination type: one-time address. Action: require approval from an approver group with a threshold.
Account abstraction off	The same vaults	Transfer	Covers native coin transfers, which have no call data. Use the same source and approval settings.
Account abstraction on	Owner vault of each Smart Wallet	Typed Message	Source: the vault. Asset: the chain's base asset. Set the designated signers, the approver group, and its threshold.
Account abstraction on	Bundler vault	Contract Call	Source: the vault. Destination type: one-time address. Action: allow without approval.
Account abstraction on	Paymaster vault	Typed Message	Source: the vault. Action: allow without approval.
Both	Every vault DALP signs from	Rule order	Allow rules for Typed Message and Contract Call for the API user DALP signs as, matched by the DALP vault tag, above the catch-all block rule.

Each request DALP files reaches the approver with a note that names the operation: the action, the asset or contract, the amount, and the counterparty. Approvers read that note on the request in Fireblocks before they decide. The note starts with the name and symbol of the contract the call reaches, such as Acme Bond (ACME): mint(...), which DALP reads from the contract. DALP writes the note and Fireblocks does not check it, and the contract name is whatever the contract reports, so an approver who must verify a request checks the contract address and the typed data. A request that calls more than one contract, or a contract that has no name, starts with the call. The note ends with the DALP request the signature belongs to, its kind and its id, so an approver can match a sponsorship ticket, a user operation and its bundle to one request.

A call that also sends the chain's coin ends with that amount, such as depositTo(account=0x…) with 0.04 native. A list of addresses, numbers or true/false values shows its first three entries and how many more follow. A list of roles shows the role names, and any other list shows its count, such as [2 items]. A list that holds a number of more than 32 digits, such as a list of claim topic ids, shows its count. A country code passed as a number in its own argument shows as its two letters and its number, such as SA (682). A country code inside a structure does not read this way: a token created from an instrument template passes its settings as one structure, so its note shows the name, symbol, type and decimals of the token and not its country. DALP cuts the note at 255 characters from the end of the call, so a call that lists addresses can lose its last arguments, such as the country list of a batch registration.

Rule order decides the outcome

Fireblocks checks a request against the rules from the top of the policy down, and the first rule that matches decides. A request that matches no rule meets the catch-all block rule at the bottom of every policy, and Fireblocks blocks it.

The API user that DALP signs as needs an allow rule for typed messages and one for contract calls on every vault it signs from. Without the typed message rule, every typed signature from that vault ends blocked by policy, while contract calls from the same vault still pass. A broad allow rule also hides any approval rule below it, because the allow rule matches first. Put the narrow rules at the top: the approval rule for a token first, then the general allow rules. The allow rules for the paymaster and bundler vaults can sit above the approval rules, because each one names its infrastructure vault as the source and so never hides the approval rule of an investor vault.

With account abstraction on, Fireblocks cannot see amounts

The tokens move from the Smart Wallet, a contract. Fireblocks sees only the owner vault's signature over an EIP-712 user operation, the typed data format that wallets use to show a structured message before signing. A Typed Message rule has no amount field and takes no destination limit, so it cannot tell a transfer of 10 tokens from a transfer of 10 million.

DALP does not replace an amount threshold or a destination rule. The token's compliance policy checks each transfer on chain against the compliance modules installed on that token, such as eligibility, jurisdiction, holding and per-transfer approval, whichever wallet sends it. DALP has no per-transfer amount cap. If your risk policy needs approval above an amount, install the transfer approval module on the token, or keep account abstraction off for those wallets. Fireblocks still decides who must approve: a Typed Message rule on the owner vault can name designated signers, an approver group, and a threshold.

One Typed Message rule covers every typed signature from its vault. The same rule gates user operations, token permits, trading venue orders, and governance ballots signed by that owner key, because Fireblocks sees each of them as a typed message. Scope the rule by source vault, and expect its approvers to see all four kinds of request.

Keep the paymaster and bundler vaults free of approval rules

Two vaults sign for every user, not for one investor. The paymaster vault signs a sponsorship ticket for each operation that DALP pays gas for. The vault behind the bundler wallet submits each batch of user operations to the entry-point contract, the shared ERC-4337 contract that validates and runs them. A person cannot approve at that rate, and a hold on either vault stops operations for every user at once. Give each vault an allow rule without approval, above any approval rule that would match it.

DALP stops a sponsored operation within seconds when the paymaster vault's policy holds its ticket. The operation fails with this message, which names the held Fireblocks transaction:

The paymaster vault's Fireblocks policy holds sponsorship ticket signing (Fireblocks transaction <id>). Infrastructure vaults must stay approval-free.

DALP does not retry that operation, because each attempt would put one more request in front of the approvers. It also logs one warning and adds one to the dalp_execution_infrastructure_vault_holds_total counter for each hold, with the vault role and the provider as labels. Alert on that counter to learn of a hold within seconds, before users report it.

Rules for vaults that send their own transactions

With account abstraction off, DALP files each token write as a Fireblocks contract call from the wallet's vault to a one-time address, the Fireblocks destination type for an address that is not on the workspace whitelist. A native coin transfer has no call data, so DALP files it as a Fireblocks transfer.

Here Fireblocks reads the call itself, so a Contract Call rule can hold large transfers for approval:

Source: each vault that holds investor tokens.
Asset: the DALP token. DALP adds each token it creates to the Fireblocks workspace as an asset, so the token appears in the rule editor.
Amount: the range that needs approval, for example every transfer above a threshold your risk team sets.
Destination type: one-time address. A rule that matches only whitelisted destinations does not match the calls DALP files.
Contract methods: leave the field open. Fireblocks matches contract methods only on a whitelisted contract with a verified ABI, and DALP's token roles decide which token functions each wallet can call.
Action: require approval from an approver group with a threshold.

Name contract destinations

FIREBLOCKS_NAMED_CONTRACT_DESTINATIONS, set through the chart value global.dalpApp.env.FIREBLOCKS_NAMED_CONTRACT_DESTINATIONS, is off by default. While it is off, every Fireblocks broadcast goes to a ONE_TIME_ADDRESS destination and DALP makes no contract wallet call to Fireblocks. The note on each request still names the contract. With it on, DALP adds the organisation's system contracts and each token it creates to the Fireblocks workspace as contract wallets. A broadcast then names the contract wallet as its CONTRACT destination only when Fireblocks has approved that contract's asset entry for the chain. A plain native transfer, an entry that Fireblocks has not approved, and any other address keep the ONE_TIME_ADDRESS destination, and so does every broadcast when DALP cannot read the contract wallets. A rule written for one-time addresses does not match a named contract. Before you turn the setting on, add Contract Call, Approve and Transfer rules that accept whitelisted contract destinations.

Order the rules in three bands

Order the rules for each type in three bands:

At the top, allow rules without approval: a Typed Message rule for the paymaster vault and a Contract Call rule for the bundler vault. Each names its vault as the source and the API user DALP signs as the initiator, so a customer approval rule below it cannot hold an infrastructure vault. To keep other users off these vaults, add a block rule for every other initiator on them.
Your approval rules, in your own order. The approver groups are your policy.
At the bottom, above the catch-all block rule, an allow rule for the API user on the DALP vaults for each type DALP uses. It sits below your approval rules, so it never hides one. Match the vaults by the DALP vault tag, so a wallet DALP creates later is covered without a rewrite.

A rule holds requests for approval when its verdict names at least one approver group or uses the 2-TIER action. An allow rule with approvers is an approval rule. A screening verdict such as SCREEN never counts as approval. After a hand edit in the Fireblocks Console, compare the policy with the rules on this page, because a broken policy shows no sign until the next request fails.

Tag the DALP vaults

DALP attaches one Fireblocks tag to every vault account it creates, and the bottom-band rule matches that tag. Create the tag in the Fireblocks Console and set its id in FIREBLOCKS_DALP_VAULT_TAG_ID (chart value global.dalpApp.env.FIREBLOCKS_DALP_VAULT_TAG_ID). Use an unprotected tag, or give the DALP API user the Admin or Non-Signing Admin role. Fireblocks refuses to attach a protected tag with a Signer key, and then every wallet creation fails. With the value empty, DALP attaches no tag, new vaults fall outside the bottom-band rule, and their requests reach the catch-all block rule.

Vaults that DALP created before you set the tag carry no tag, so the bottom-band rule does not cover them. Tag each of them once: in the Fireblocks Console, or with one call to POST /vault/accounts/attached_tags with tagIdsToAttach and vaultAccountIds. DALP also attaches the tag when it adopts an existing vault with the same name. Until a vault is tagged, its requests of every type DALP uses reach the catch-all block rule.

Troubleshooting

What you see	Cause	Fix
A sponsored operation fails with “The paymaster vault's Fireblocks policy holds sponsorship ticket signing”.	A rule that requires approval matches typed messages from the paymaster vault.	Add an allow rule without approval for typed messages from the paymaster vault above it. Reject the held request, then submit the operation again.
Typed signatures from a vault end blocked by policy, while contract calls from the same vault pass.	No allow rule matches typed messages from that vault, so the catch-all block rule does.	Add an allow rule for typed messages from that vault for the API user DALP signs as.
User operations stop reaching the chain while the bundler vault shows a request waiting for approval.	A rule that requires approval matches contract calls from the bundler vault.	Allow contract calls from the bundler vault without approval, then approve or reject the waiting request.
A large token transfer completes without the approval you configured.	A broader allow rule above the approval rule matches first.	Move the approval rule above the allow rule.

Fireblocks sources

About Policies: first-match evaluation from the top down, and the catch-all block rule at the bottom of each policy.
Configure Policies: rule fields, transaction types, destination types, designated signers, and approval groups. Typed Message, RAW, and Burn rules take no destination limit.
Set Policies: rules run in the order you define them, so put the most restrictive rules first.
Typed Message policy rules: the rule type that typed signatures need.
Policies for EVM DeFi operations: amount limits on contract calls and one-time addresses.
Policy rules for specific contract call methods: method rules need a whitelisted contract with a verified ABI.
Transactions blocked by policy: what the catch-all block rule looks like on a rejected transaction.