Your company's unique activities, security, and regulatory needs may cause you to build your TAP differently than other Fireblocks customers. Below is a range of basic operational and approval flows for common use cases that you can benchmark or use as a template.

Trading and treasury management examples

Example 1

There are three roles you can users to in transaction flows: Initiator, Approver, and Signer. Below, a company only wants specific users to have these operational roles. Their TAP could look like this:

The TAP uses one basic rule to assign these functions.

Only members of a user group called Traders can initiate transactions.
Only users from a group called Management can approve the Trading group’s transactions and only one member of that group has to approve.
Only the Head of Trading can sign the transaction to the blockchain after approval.

The second rule is the block-all rule, the mandatory rule at the bottom of every TAP that blocks any transaction that does not explicitly match a rule above it.

Creating this TAP example using TAP Editor

This is how you would create rule one above in the TAP Editor.

Your TAP will use more rules and parameters based on transaction values, Initiator types, and more than this simple example. Example 2 below shows a more complete TAP for a trading business.

Example 2

Below, we show basic best practices to structure your workspace for trading and treasury management needs. To be competitive, you can set rules that enable both your management team and traders to quickly settle trades or rebalance, but within limitations to manage risk.

In this example, the business need is for both the Management and Trader user groups to transfer without approvals up to a certain value, require custom approval flows for higher value transfers, and reject all transfers if a pre-set aggregate limit is exceeded over an 8-hour window or per transaction.

Management group users also need less strict value thresholds and more flexibility than Traders group users around which types of accounts they can initiate transfers from.

Below are generic examples of TAP rules that meet these needs. Each rule is briefly explained beneath the image.

Rules 1-3 go from the highest Amount threshold to the lowest for transfers initiated by a Management group user. The most restrictive rules go first to ensure they're enforced based on the first-match principle. Rules 4-5 do the same for Traders.
- For rule 1, selecting Per initiator when defining the $10 million within 8 hours threshold ensures the rule will match only if the same= user tries to transfer more than $10 million within 8 hours. If they do, it will require approval from two members of the Management user group.
Rules 4-5 apply different amount thresholds for the Traders group, and they apply only per transaction instead of over a fixed time period. Rule 4 ensures one Management group user must approve if they request a transfer worth over $500k. Rule 4 ensures one Management group user must approve if they request a transfer worth over $500k. For rules 4-5, you must create the Withdrawals vault account listed under Source and Source Name before you create this TAP.
Finally, rule 6 is the block-all rule, blocking any transfer not explicitly allowed by this TAP.

Submitting this TAP example using TAP Editor

This is how you would create rule one above in the TAP Editor.

Web3 example

In these examples, we show basic best practices to structure your workspace's TAP for decentralized finance (DeFi) and Web3 operations. If you use the Fireblocks WalletConnect integration or the Fireblocks Chrome Extension, you can create specific rules for contract call transactions with different restrictions and approval flows than other transfer types.

Use contract call rules to implement custom policies for DeFi operations, in case you have different risk and compliance needs for DeFi. Below are generic examples of rules. Each rule is briefly explained beneath the images.

Option A

Option B

Rule 1 in Option A approves contract calls to enable DeFi operations in your workspace.
1. Only Traders group users can initiate contract calls.
2. Only the DeFi Trading vault account can be the Source.
3. They can send contract calls to any contract address (Destination is set to Any, both Whitelisted+OTA). This allows maximum flexibility using Web3 protocols and liquidity pools, but is less secure. For maximum security, select Whitelisted Only to only allow contract calls with pre-whitelisted contracts.
4. Amount is blank because you don't set amount limits for contract calls in your TAP. Instead, you use the separate Approve transactions - amount cap setting.
5. All contract call transactions to one-time addresses must be approved by one Management group user.
Alternatively, rules 1-4* in Option B approve contract calls differently for Traders group users.
1. Rule 1 in Option B is the same as rule 1 in Option A, except Destination is set to Whitelisted Only and Action is set to Allow. This allows Traders group users to send contract calls to whitelisted addresses without requiring approval.
2. Rule 3 in Option B sets Destination to One-Time-Address Only. This allows Traders group users to send contract calls to one-time addresses with one Management group approval.
3. Rules 2 and 4 in Option B relate to Typed messaging signing for smart contract transactions for Fireblocks Console users.
Using rules 2-4 in Option A (rules 5-7 in Option B), the Management user group controls the funds in the DeFi Trading vault account. The most restrictive rules are first to ensure their restrictions are applied according to the first-match principle. They go from the highest to the lowest sum for the same users.
Rule 5 in Option A (rule 6, Option B) blocks any transfer that is not allowed by this TAP.

*Rules 2 and 4 in Option B enable Typed messaging signing, which is the Fireblocks operation for signing standard off-chain messages (ETH Personal Sign and EIP-712). Signing an off-chain message that’s not a transaction is often required by web3 applications.

Submitting this Web3 TAP example using TAP Editor

This is how you would submit Rule 1 from Option A above using TAP Editor.

Retail TAP example

Here we show basic best practices to structure your TAP for retail operations. Retail businesses can use Fireblocks API to automate transfers to numerous retail users. With TAP, you can set limits and approval flows for API Signer user activity.

We recommend only giving certain users access to your omnibus treasury vault. You can apply TAP rules to an omnibus vault structure to streamline operations for your retail app by allowing instant transfers for API Signers. To tailor policies for high retail volumes you can allow API Signers to sweep funds from your end client (intermediate) vault accounts to your Omnibus Deposits vault account and to withdraw from your Omnibus Withdrawals vault account.

You can also manage risk by setting custom approvals based on amount or time-based thresholds. An example of this structure is below, with custom rules for three user roles. Each rule is explained below the image. Note that if you use a two-withdrawal vault flow or a different vault structure than in this example, you should consider this when building your TAP.

Rule 1 blocks API Signer users from withdrawing from the Treasury vault account. Only Management and FinOps groups users can access it.
The most restrictive rules are listed first to ensure they're enforced based on the first-match principle.
1. Rule 2 requires any transfer between vault accounts by API Signers above $50,000 to be approved by one FinOps group user.
2. Rule 3 allows API Signers to transfer any amount from $0-$50,000 between vault accounts without approval.
3. Rule 4 allows the API to transfer to the Fireblocks Gas Station without approval.
4. Rules 5-6 are similar to rules 2-3, but more restrictive due to the Withdrawals Omnibus vault account being the source and external wallets the destination. Your user withdrawal wallets are often external wallets. It's up to you whether to whitelist them. In this example, some aren’t, but transfers are allowed because Destination is set to Whitelisted+OTA.
5. Rules 7-8 allow Management group users to transfer any amount between the Treasury and Withdrawals vault accounts with one other Management group user’s approval. This allows them to rebalance their vault accounts.
6. Rule 9 blocks the FinOps group from collectively transferring over $1 million within 24 hours by selecting Accumulate all under Accumulation.
7. Rules 10-12 allow FinOps group users to transfer certain amounts from any source to any destination with custom approval flows based on amount.
  1. In rule 10, transferring over $100,000 requires approval from two FinOps users and one Management group user.
  2. In rule 11, transferring $50,000-$100,000 requires the approval of two FinOps group users or one Management group user.
  3. In rule 12, transferring $0-$50,000 requires one FinOps group user’s approval.
8. Rule 13 allows Juniors group users to transfer between vault accounts. Since Juniors group users have Editor roles, which can't sign transactions, a Designated Signer is required.
9. Finally, rule 14 blocks any transfer that is not explicitly allowed by this TAP.

Submitting this Retail TAP example using TAP Editor

Below we show how you would submit rule 1 from above using the TAP Editor.

Embedded Wallets Example

Within the Embedded Wallets (EW) world, you may build a TAP that meets your criteria. There is no best practice, as one example that fits one business, might not meet the expectations of another.

With that said, you may limit volumes per end user wallet, set a limit to which Dapps the end-user can interact with or even block them from interacting with certain assets.

To apply any wanted logic, you may use the End User Wallet venue, which can be used both as source and destination:

When selecting the "Groups and accounts", you may "Any End User Wallet" to apply any logic you have at mind.

Here is an example TAP which uses the End User Wallet venue:

The above example is pretty simple and straightforward, but comes to introduce different possibilities within the TAP, for end user wallets.

Rule 1 limits an end user to trade Solana no more than $1,000 per day, regardless of the destination.
Rule 2 limits an end user to trade Ethereum (Sepolia) no more than $2,000 per day, regardless of the destination.
Rule 3 allows end users to trade BTC, with no limits.
Rule 4 allows end users to trade with a special token only between themselves, within the app ecosystem.
Rule 5 allows to connect to only a specific Dapp, using Contract Whitelisting.

Please Note - approval groups aren't supported for Embedded Wallets transactions.