Fireblocks: Blocked by Policy

Fireblocks and TAP RulesPermalink

A core feature of Fireblocks is to route transactions through an approval process before signing them and submitting them on-chain (see an earlier post to learn more about Fireblocks fundamentals). The approval process is controlled by the Fireblocks Transaction Authorisation Policy (TAP) rules that you configure.

TAP rules don’t have great debugging tools, and if you’re tasked with configuring TAP rules, you will definitely become familiar with the “blocked by policy” message. It is issued by Fireblocks when no TAP rule is present that lets the desired transaction through.

The Fireblocks Sandbox has some sample TAP rules. These are not super-helpful for a demo here, because they are read-only and the second rule, shown in green below, allows any sort of transaction from and to any address. But your rules will look different, for example the to address might be a specific contract that has been whitelisted in Fireblocks. What we can see in the below, is that each rule has an initiator, a from and to address, details about assets and an action (approve, deny, or send for X-of-Y approval).

Workflow for TAP Rule DebuggingPermalink

1. What TAP Rule do you expect to match?Permalink

The first step is to identify what TAP rule you expect to be matching. Remember TAP rules are processed from the top down, and as soon as a rule matches, then it is executed. If the rule does not specify that the transaction should proceed, but doesn’t explicitly deny it, then Fireblocks will try to match against the next rule down, and so on. The key point here is that, at most, only one single rule is executed for any given transaction. Once a match is made, that single matching rule must either explicitly deny, explicitly allow, or forward the transaction on for an X-of-Y approval process.

Let’s imagine you’ve identified the rule you expect to match. You then need to collect information about that rule: pick out the initiator, the from and to addresses and any other criteria like whether it requires whitelist addresses or only particular assets.

2. Gather InformationPermalink

Think of the TAP rule identified above as the expected form of the transaction. The actual form is what the transaction really was, and comparing the two will tell us why we have an issue.

Since the transaction was not processed by Fireblocks, it didn’t end up on chain, so to collect information about it we must look elsewhere. Here are some places to look:

1. First of course, is whatever process sent the transaction. You want to collect information about the initiator, the from and to address, the same information we collected about the TAP rule in the previous step. If the sender process was some app, then it might be an API call that tried to send the transaction, then the initiator will be an API user.

2. The Fireblocks Console shows some fields about failed transactions.

3. Making a Fireblocks API call can give more fields than you see in the Fireblocks Console. There is an API endpoint to get transaction details by Fireblocks transaction id. To use this endpoint you need the Fireblocks transaction id, which you’ll get from the Fireblocks console in the previous step. There is also a Fireblocks SDK if you prefer, which has the same endpoint available as a function getTransactionById.

3. Identify FaultPermalink

Now we try to identify what the underlying fault was. So we can have one of two situations:

1. We matched against a rule that we didn’t expect, one that is above our desired rule in the list, and that rule explicitly denied the transaction.
2. We failed to match against any rule, and once all rules are exhausted, then Fireblocks says “blocked by policy”.

Case 2 above should be revealed by comparing the fields collected above.

An important point to note, is that time is also a factor. Let’s say you have a TAP rule that says “accept any transactions sent to whitelisted contracts”. However, adding a new contract address to a whitelist entry (which is a Fireblocks Console process, not something on-chain) might itself have an approval process, depending on your setup. Say that approval process needs X-of-Y approvers, perhaps 2 of 5. If you tried to send a transaction after the whitelist entry was created and had one approval, then the TAP rule would not regard that whitelist entry as valid, and would give “blocked by policy”. If the second approval then arrives, it could make this hard to debug, because everything is in fact configured correctly, just the timing of sending the transaction is wrong.

AttributionsPermalink

The “blocked by policy” rubber stamp image is courtesy of TextStudio.