Fireblocks policy for DALP vaults

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 Authorization Policy. This page lists the rules each DALP vault needs and shows where DALP enforces the limits that a Fireblocks rule cannot see.

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 WalletA Smart Wallet lets a tenant require several signers to agree before an instruction moves assets, with the rule enforced on chain, not by one private key.Read the concept, 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.

Rules per vaultCopy Anchor Link

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.

Rule order decides the outcomeCopy Anchor Link

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.

Two consequences follow for DALP. 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 allow rules for the paymaster and bundler vaults, then the general allow rules.

With account abstraction on, DALP enforces the limitsCopy Anchor Link

With account abstraction on, the tokens move from the Smart Wallet, and the Smart Wallet is a contract, not a Fireblocks vault. 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 therefore enforces amount and destination limits. The token's compliance policyA Compliance Policy lets a compliance team write eligibility and holding rules once, while a platform floor reaches every current-factory token.Read the concept checks each transfer on chain against its eligibility, jurisdiction, holding, and approval rules, whichever wallet sends it. 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 rulesCopy Anchor Link

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 walletAn operator wallet lets your users transact without holding native gas: the platform pays the network fee, and you fund and monitor the wallet that covers it.Read the concept 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 catch a policy change before users report failed operations.

Rules for vaults that send their own transactionsCopy Anchor Link

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.

TroubleshootingCopy Anchor Link

Fireblocks sourcesCopy Anchor Link

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