Overview

By default, only contract call transactions to whitelisted contract addresses are allowed in your workspace. To allow contract calls to non-whitelisted contract addresses or to add rules and approval flows for other parameters, implement specific Policy rules for contract calls. You need Contract Call Policy rules to use the Reown integration in your workspace and to programmatically call decentralized applications (dApps) using the Fireblocks DeFi SDK.

Below, we discuss limiting transaction amounts, contract call whitelisting, Approve transactions, Typed messages, and deploying smart contracts. The unique characteristics of these operations will impact how you construct Policy rules. Please finish the sections below before looking at the Policy example for Web3 operations.

Limiting transaction amounts

In your Contract Call Policy, you can define rules based on amounts to limit how much of an asset can be included in a transaction. You can also set amount thresholds separately from your Policy that limits how much a smart contract can withdraw. Learn about amount caps for Approve transactions.

Contract call whitelisting

As a best practice, Fireblocks recommends that require smart contracts be whitelisted in the workspace before users can interact with them. Note that the assigned approval group must approve each contract address individually.

Important

To whitelist a contract's address, you must whitelist it as a contract of the network’s base asset. For example, a contract on Ethereum would be whitelisted as ETH, a contract on BNB Chain would be whitelisted as BNB_BSC, and so on.

Depending on your security risk appetite, you can allow users to interact with smart contracts at will using the one-time address feature. This method can pose security risks. If using this method, we recommend setting up a strict Policy before enabling the feature. You can set a variety of such Policy protective limitations, such as:

Restricting one-time address transfers only to certain preselected users or groups
Requiring approval for one-time address transfers above a certain threshold

Policy rules for Approve transactions and Typed Messages

When using dApps, you may be required to perform certain actions that create different types of smart contract transactions. You can create different rules for these actions. The primary Web3 operations are contract calls. Two other operations you may use are:

Approve transactions: When interacting with a smart contract or decentralized application (dApp), you must first sign an Approve transaction. This allows the third party to move funds on your behalf so you can complete the actual operation. You can create Approve Policy rules to govern these transactions. Learn more about Approve transactions.
Typed Messages: You can use Typed Message Signing to securely sign off-chain messages. You can create Typed Message Policy rules to govern these messages. Below, we explain specific use cases that may require Typed Messages and how to enable Typed Message Signing. Learn more about Typed Message Signing here.

Enabling Typed Message Signing for Web3

You can use Typed Message Signing for three types of operations:

Bitcoin personal message: A standard primarily used for Proof-of-Address ownership.
EIP-712 messages: A standard format of off-chain messages, used by some ERC-20 contracts to verify withdrawals for you instead of the gas-consuming Approve transaction.
ETH personal messages: A standard format to sign any string of data that is not a valid transaction.

When using a dApp that requires signing one of these formats, you must create a Typed Message Policy rule that enables Typed Messages for that smart contract.

Note

To improve your experience and operational clarity, we have deprecated the Applies for Typed messages toggle for Contract Call Policy rules. As of June 16th, 2024, new rules no longer have the Applies for Typed Message toggle. Existing Policy rules with this toggle on will continue to match both Contract Call and Typed Message transactions, but they will not match the Typed Message transaction unless the destination is Any or Any one-time address.
If you had a Contract Call rule with Applies for Typed Message toggled on, with an Any whitelisted address destination and an Allow action, you will now have a separate Typed Message Policy rule for the transaction.

Fireblocks Console users

Enabling Raw Signing for Fireblocks Console users has less risk because you can only use Raw Signing through API. Therefore, riskier Raw Signing use cases are not accessible to Fireblocks Console users. As an added layer of security, Raw Signing can also only be activated manually through Fireblocks Support, not internally using the Policy Editor.

Smart contract deployment

Smart contracts are foundational to a variety of blockchains. For example, Ethereum’s standards, such as ERC-20 (fungible tokens) and ERC-721 (non-fungible tokens), are implemented using smart contracts. In order to leverage these standards for your use case, you must first deploy a smart contract.

In Fireblocks, you can create Contract Call Policy rules that allow you to deploy smart contracts via the Fireblocks Console and the Fireblocks API. These rules are also helpful for restricting when smart contracts can be deployed from your workspace.