# Set Policy Rules for Message Signatures

The policy allows you to control the approval process for signing messages, but not all conditions apply to messages. Moreover, the behavior differs between different types of messages on different chains.

## Personal messages and messages on non-EVM chains

Personal messages on EVM chains and any messages on non-EVM chains do not have an associated recipient. Therefore, to apply a policy rule to such message signatures, the recipient matcher in the rule must be left as "Any".  The rationale is that such messages do not explicitly specify their recipient in a standard way, and we therefore cannot reliably match them to a recipient in the policy.

Personal messages on EVM chains and any messages on non-EVM chains are treated as if their amount is 0. Therefore, they will match any transaction amount condition.

## Permit and Permit2 messages

These important security-sensitive messages, used for token allowances, are supported as "first-class objects". These include [EIP-2612](https://eips.ethereum.org/EIPS/eip-2612) Permit messages and messages using Uniswap's [Permit2](https://docs.uniswap.org/contracts/permit2/overview) standard. Such messages are classified as "Allowance" transactions and are subject to the same handling as token allowances. Specifically, the recipient of the message is the spender contract that is granted the allowance, the amount is the dollar value of the amount of the token that is being approved, and the asset condition can be used to specify the token that is being approved.

## Typed data messages

The recipient of Typed Data messages on EVM chains is the contract address that is specified in the `verifyingContract` field of the Typed Data message. Therefore, to apply a policy rule to such message signatures, the recipient matcher in the rule must be set to the address of the contract that is being called.

Typed Data messages have no amount associated with them. However, since those messages are often used for transferring funds, the amount is treated as unknown, rather than 0. This means that a rule with an amount condition will not match Typed Data messages.

The *EVM Typed Message* condition lets admins create policies that restrict or allow specific actions on EVM typed messages transactions. This condition allows specifying the domain name and matching object type.

The following are examples of using the *EVM Typed Message* condition to match specific EVM typed messages.

1inch Order
A 1inch Order message can be matched by a rule with the domain name `1inch Aggregation Router` and the matching object type `Order`. Additionally, it can be matched more tightly by specifying the recipient of the rule to be the `verifyingContract` address.


```
{
  "primaryType": "Order", // [!code highlight]
  "domain": {
    "name": "1inch Aggregation Router", // [!code highlight]
    "version": "6",
    "chainId": 1337,
    "verifyingContract": "0x111111125421ca6dc452d289314280a0f8842a65" // [!code highlight]
  },
  "message": {
    "maker": "0x1788124e29feb72eecae5c08b5ac16932a607063",
    "makerAsset": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
    "takerAsset": "0xc4441c2be5d8fa8126822b9929ca0b81ea0de38e",
    "makerTraits": "62419173104490761595518734106350460423624858895588428857840128814335647547392",
    "salt": "102412815612101317841011027302898044182118311605090620840156673102513625049742",
    "makingAmount": "2000000000000000",
    "takingAmount": "15273044570528616665",
    "receiver": "0x8bfcf9e2764bc84de4bbd0a0f5aaf19f47027a73"
  }
}
```

Hyperliquid
Hyperliquid
Hyperliquid transactions (such as `Withdraw` and `SendAsset`) are submitted as EIP-712 message signatures rather than contract calls. Because these messages move real funds, the Fordefi policy engine can instead treat them as **Transfers** — allowing you to apply the same security controls you would use for any other asset movement.

**Recommended approach: match as a Transfer**

The most secure way to set a policy rule for Hyperliquid messages that move assets is to:

1. Set the transaction type condition to **Transfer**.
2. Set the **recipient** to the address where funds are actually going.


This ensures your rule controls *where the funds end up*, which is what matters for security.

- For a `Withdraw` message, the recipient should be the Fordefi vault signing the withdraw message.
- For a `SendAsset` message (used to move tokens between Hyperliquid Perps and Spot markets), the recipient is typically the vault signing the message, but can also be a third-party address on Hyperliquid.


**Legacy approach: match as an EVM Typed Message**

For backward compatibility, Hyperliquid messages can also be matched as EVM Typed Messages by setting the domain name to `HyperliquidSignTransaction` and the matching object type to the relevant primary type (e.g., `HyperliquidTransaction:SendAsset`). However, this approach is less secure: the recipient is derived from the `verifyingContract` field, which is the zero address (`0x000...000`) for all Hyperliquid messages. This means a rule using EVM Typed Message matching **cannot** verify the actual funds destination.

**Example: `SendAsset` message**

The following is a `SendAsset` message moving USDC from Perps to Spot on Hyperliquid. Note the `destination` field — this is the address a Transfer-type policy rule should use as the recipient.


```
{
  "domain": {
    "name": "HyperliquidSignTransaction", // [!code highlight]
    "version": "1",
    "chainId": 1,
    "verifyingContract": "0x0000000000000000000000000000000000000000" // [!code highlight]
  },
  "message": {
    "type": "sendAsset",
    "destination": "0x8BFCF9e2764BC84DE4BBd0a0f5AAF19F47027A73", // [!code highlight]
    "sourceDex": "",
    "destinationDex": "spot", // [!code highlight]
    "token": "USDC:0x6d1e7cde53ba9467b783cb7c530ce054",
    "amount": "7",
    "fromSubAccount": "",
    "nonce": 1773429058027,
    "signatureChainId": "0x1",
    "hyperliquidChain": "Mainnet"
  },
  "primaryType": "HyperliquidTransaction:SendAsset", // [!code highlight]
}
```

## Summary

The following table summarizes the behavior of message signatures for different types of messages on different chains.

| Message Type | Amount | Recipient |
|  --- | --- | --- |
| Personal Message | 0 | N/A (must be Any) |
| Typed Data Message | Unknown (must be Any) | `verifyingContract` field |
| Non-EVM Message | 0 | N/A (must be Any) |
| Permit and Permit2 Messages | Amount of the token being approved | Recipient of the message (spender contract) |