Typed Message Policy lets you govern off-chain signing requests at the field level, controlling not just whether a transaction can be signed, but what values are permitted inside the message itself. This gives you precise oversight of DeFi operations on supported platforms directly from your workspace Policies.

What's new

You can now govern more of what's inside a typed message. In addition to the platform, operation, destination, and amount, you can set conditions on other details in the message, such as a recipient, a time limit, or a network name.

This gives you finer control over what your team can sign, including on platforms that don't have a Fireblocks preset.

What's included:

• More message parameters: Choose any supported field in the message and set the condition it must meet.
• Message type list: Search for the type of message you want to govern. Its available parameters appear automatically.
• Rules for any platform: Create a rule for a specific message type, even when there's no platform preset for it.

Your existing Typed Message policy rules continue to work as before. You don't need to recreate them.

What are typed messages?

Many DeFi platforms use EVM off-chain messages to authorize operations such as withdrawals, deposits, and transfers. These messages are signed off-chain, meaning they are not recorded on the blockchain and no gas is required. Because they don't go through the standard transaction flow, they previously couldn't be governed with the same granularity as on-chain transactions.

This feature closes this gap by letting you define exactly which operations are allowed, from which sources, to which destinations, and up to what amounts, for each supported platform.

Governance levels

Typed Message Policy supports three levels of governance, from simple platform-specific presets to fully custom field-level control.

Platform presets

For supported platforms such as Hyperliquid, Fireblocks provides a predefined set of governable fields: operation, verifying contract, and amount, plus a destination address for operations that carry one. You select a platform when creating a rule, and the relevant fields appear automatically. No knowledge of the underlying message structure is required.

Custom field parameters

When you need to govern fields beyond the predefined set, you can define your own parameters. Selecting Add message parameters (advanced) opens the message parameters modal, where you can choose a specific parameter from the message type and set the value it must match.

Message types

When there's no preset for the platform you use, you can still govern its messages. Set Blockchain type to Any, select Add message type & parameters (advanced), then search for the message type in the Message type list. Choose the parameters you want to govern and set their values.

A rule created this way applies only to the message type you selected. Other message types don't match this rule, even when they look similar.

Supported platforms and presets

Setting policy rules for platforms supports Hyperliquid, OpenSea, Safe, and Blur on mainnet and testnet with predefined field governance. For other platforms, you can select a supported message type from the Message type list. The Message type list includes hundreds of message types from common protocols.

Rule parameters

When creating a Typed Message Policy rule, you configure the following:

Scope

• Rule name: A label which identifies the rule in your policy.
• Initiator: The users or user groups this rule applies to.
• Source: The vault account this rule applies to.
• Blockchain type: EVM, Non-EVM, or Any (default). Selecting EVM shows the Platform field and filters the available assets to EVM-compatible assets. Selecting Any hides the Platform field and lets you choose a message type instead. Non-EVM doesn't support message parameters.
• Platform: The DeFi platform on which you want to govern signing requests (for example, Hyperliquid). Selecting a platform surfaces the relevant operation fields, and the destination field for operations that have one.
• Operation: The type of action being authorized (e.g., withdraw, staking deposit, or transfer).
• Destination: The destination address the rule applies to, for operations whose message contains one (for example, Withdraw and Transfer).

  Note: Some operations, such as a Hyperliquid staking Deposit (CDeposit), have no destination in the signed message, because the funds move within your own account. A rule with a Destination condition can never match these messages, so they are blocked by default. For these operations, create a separate rule with no Destination and scope it by initiator, source, and asset.

• Message parameters (advanced): If Blockchain type is EVM, select Add message parameters (advanced) to choose from the selected platform's parameters. If Blockchain type is Any, select Add message type & parameters (advanced), choose a message type, then choose its parameters. Set the values for each parameter you choose.

Funds

• Asset: The asset this rule applies to.
• Amount: The minimum and maximum transaction values this rule applies to.

Action

• Action: Whether to allow or block matching transactions.

How message parameters work

When you add message parameters to a rule, Fireblocks checks each one before the message can be signed:

• Every parameter you add must match. If a parameter is missing from the message, or its value doesn't match, the rule doesn't apply and Fireblocks checks the next rule.
• Parameters you don't add aren't checked. Only the parameters you choose affect the rule.
• When the message contains several values for a parameter, such as a list of destinations, every value must match.
• When you set several allowed values for a parameter, the message matches if its value is any one of them.

Depending on the parameter, you can set:

• Numbers: A range. The message value must be greater than the minimum and less than or equal to the maximum. Values are in the message's raw units, with no decimals applied. For example, 1 USDC is entered as 1000000.
• Addresses: Any address, your vault accounts, or whitelisted addresses, including whitelisted contracts.
• Text: Exact values. Matching is case-sensitive.
• On/off settings: True, False, or Any.
• Bytes: Hex values. The 0x prefix is optional and the letter case doesn't matter.

View your Typed Message policy rules

Your typed message policy rules appear in the policy table alongside all other rule types. Each row displays the rule's key parameters at a glance: rule number, name, initiator, source, destination, platform, message parameters count, asset, amount range, action (allow or block), and the approval groups required to authorize matching transactions. EVM rules that apply to any platform show Any platform in the Platform column. The Message parameters column shows how many parameters a rule has. Select it to see each parameter and its values.

Hovering over the message parameters count shows the parameters and their values. To edit or delete a rule, select the More actions menu (⋮) on the right side of the row.

Create a Typed Message policy rule

1. In the Fireblocks Console, go to Policies.
2. Select the policy you want to edit, then select Edit policy.
3. Select + Add rule and then select Typed message as the rule type.
4. Complete the Scope fields: rule name, initiator, source, blockchain type, asset, platform, operation, and destination.

5. To add message parameters:

   • If the Blockchain type is EVM, select Add message parameters (advanced).
   • If the Blockchain type is Any, select Add message type & parameters (advanced), then choose a message type from the Message type list.

   Select the parameters you want to govern, set their values, then select Update parameters.

6. Set the action (allow or block) and configure the amount range if needed.
7. Select Save to add the rule to your policy draft.
8. Publish the updated policy. The required approval quorum must approve the change before the rule takes effect.

How Typed Message policy works

When a user initiates a DeFi EIP-712 operation on a supported platform, Fireblocks decodes the EIP-712 message and extracts the relevant fields: platform, operation, destination address, verifying contract, amount, and other relevant fields. These values are then evaluated against your policy rules before Fireblocks approves the transaction for signing.

If the transaction matches an allow rule, it proceeds to signing. If it matches a block rule, or no matching rule is found, the transaction is rejected.

If your rule includes message parameters, the rule applies only when all of them match.

Typed Message policy example

The following setup for typed message policy rules is a possible Hyperliquid use case example, where:

• All of the workspace's wallets are allowed to use Hyperliquid (e.g., login operations)
• Withdraw operations are only allowed to specific wallet addresses
• Other messages (non-Hyperliquid related) are allowed

Typed message policy rules are evaluated in order, from top to bottom, and the first matching rule determines the outcome.

Rule 1: Allow withdrawals to an approved destination

Allow Hyperliquid Withdraw messages that withdraw to a specific vault account.

• Blockchain type: EVM
• Platform: Hyperliquid
• Operation: Withdraw
• Destination: The approved Whitelisted Wallet
• Action: Allow

Rule 2: Block all other Hyperliquid withdrawals

Block any Hyperliquid Withdraw message that does not match Rule 1.

• Blockchain type: EVM
• Platform: Hyperliquid
• Operation: Withdraw
• Destination: Any
• Action: Block

Rule 3: Allow all other typed messages

Allow any typed message that does not match Rule 1 or Rule 2.

• Blockchain type: Any
• Platform: Any
• Operation: Any
• Destination: Any
• Action: Allow

Why does the order matter?

Rules are evaluated top to bottom and the first match wins. The sequence above is what makes the policy work:

• Rule 1 is evaluated first, so approved withdrawals are allowed before any block rule is reached.
• Rule 2 blocks every other Hyperliquid withdrawal before it can reach the final catch-all allow rule.
• Rule 3 permits everything else: other Hyperliquid operations such as ApproveAgent, and typed messages on any other platform or blockchain.

Limitations

• Some complex messages include nested fields. These fields can't be governed yet and don't appear in the parameter list.
• Message parameters are available only for EIP-712 typed messages, so they aren't available for Non-EVM rules or other message formats.
• Very large messages (more than 1,024 parameter values, or more than 256 values for a single field) don't match rules that use message parameters.