Transfers policy allows you to define limits for your v2 wallet transactions. It is a policy in Liminal Firewall, where you can configure multiple rules including setting up the amount limit for a single transaction. A transaction that is evaluated by this policy is either accepted, rejected, or requires approvals from the designated team, as per the configured rules. The policy applies exclusively to the send (outgoing transactions) flow of the hot and warm/cold MPC wallets. It does not require any third-party involvement for execution or transaction screening.

📘

Note:

• Existing spending limits and transaction limits on policies will still work parallelly to this policy, if configured.
• Currently, the transaction amount in the policy is configured in USD. Native denominations are not supported.

Policy rules

A policy contains a set of rules defined in an order to evaluate a transaction. A rule applied on a transaction results in an outcome, as configured for the rule. For example, if a transaction contains an amount greater than the min amount configured in the rule, it will either be rejected or will require approvals from the designated team, as configured in the rule. These rules are set in the priority order of their execution, meaning that a transaction is evaluated first by the rule with priority order 1, and if it doesn’t match the criteria in the rule, it moves on to the next rule in order, and so on.

Rule parameters

The parameters in a rule are used to define criteria or settings that the rule uses to define conditions and execute actions. Each rule in the Transfers policy is governed by the following parameters:

• Source - The wallet from where the transaction is initiated. This parameter can include any of the following values:
  • Any - Includes any wallet from the organisation.
  • A specific wallet identified by its name.
  • A group of hot or warm/cold MPC wallets. Hot wallets include both withdrawal and deposit wallets.
• Destination - The target wallet to which the transaction is sent. This parameter can include any of the following values:
  • Any - Includes any wallet including whitelisted and non-whitelisted addresses. This applies to a particular hot wallet, cold wallet, or a group of hot wallets.
  • A whitelisted wallet address associated with the source wallet. This applies only to the warm/cold wallets.
• Protocol - The type of protocol of the wallet to which the rule applies. This parameter can include any of the following values:
  • Any - Applicable to all types of protocols.
  • A single specified protocol only.
• Asset - The types of assets the rule applies to. This parameter can include any of the following values:
  • Any - Applicable to all types of assets.
  • One or more specified assets.
• Min Amount - The upper limit for transactions under the rule. This parameter can include any of the following values:
  • A maximum amount allowed in a single transaction. Any transaction exceeding this limit will either be rejected or require approvals from the designated team.
  • A cumulative amount that can be transacted in X number of hour(s). Transactions exceeding this limit will be rejected.
  • A cumulative amount that can be transacted in X number of day(s). Transactions exceeding this limit will be rejected.
• Outcome - The action taken when a transaction meets the rule criteria. This parameter can include any of the following values:
  • Reject - Prevents the transaction from proceeding.
  • Accept - Permits the transaction to go through.
  • N of Team X - Mandates obtaining approvals for the transaction from the designated team specifying the minimum number of approvals needed from the team. For example, “2 of team X”.

Examples

Your organisation’s security and regulatory needs may require a customised Transfers policy for transactions. This policy sets specific approval requirements for high-value transactions to ensure security. The following are a few examples of Transfer policy rules which you can use as templates. You can also submit a set of rules for your organisation by submitting a support ticket to share your intent.

Example 1

The following image illustrates the types of rules, which are explained as follows.

1. A transaction from a warm/cold MPC wallet into a whitelisted address with any protocol and asset type, with the amount above $100,000, will require two final approvals from team A. If the amount is lower than this amount, the transaction will move to the next rule that matches it.
2. A transaction from a hot wallet into any address with any protocol and asset type, with the amount above $50,000, will require a single final approval from team A. If the amount is lower than this amount, the transaction will move to the next rule that matches it.
3. A transaction from any wallet into any address with any protocol and asset type, with any amount above $0 (but lower than $50,000 as per the previous rule), will be accepted by Liminal Firewall without requiring any final approvals from the team.

Example 2

The following image illustrates the types of rules, which are explained as follows.

1. A transaction from any source wallet into a whitelisted address with any protocol and asset type, with the cumulative amount above $1M triggered within 8 hours, will be rejected. For example, if you send $500,000 at 1 AM, $300,000 at 4 AM, and $200,000 at 6 AM, the total reaches $1M within 8 hours. As a result, the final transaction of $200,000 will be rejected. If the amount is lower than this amount, the transaction will move to the next rule that matches it.
2. A transaction from a reserve wallet into any address with any protocol and asset type, with the cumulative amount above $100,000 triggered within a day, will be rejected. For example, if you send $50,000 at 1 AM, $30,000 at 9 AM, and $20,000 at 5 PM, the total reaches $100,000 within a day. As a result, the final transaction of $20,000 will be rejected. If the amount is lower than this amount, the transaction will move to the next rule that matches it.
3. A transaction from a cold wallet called “ETH wallet” into a whitelisted address with ETH protocol and any asset type, with an amount above $500,000, will require one final approval from team B. If the amount is lower than this amount, the transaction will move to the next rule that matches it.
4. A transaction from any source wallet into any address with any protocol and asset type, with an amount above $750,000, will require two final approvals from team B. If the amount is lower than this amount, the transaction will move to the next rule that matches it.
5. A transaction from any source wallet into any address with any protocol and asset type, with amount above $50,000, will require a single final approval from team A. If the amount is lower than this amount, the transaction will move to the next rule that matches it.
6. A transaction from any source wallet into any address with any protocol and asset type, with any amount (lower than $50,000 as per the previous rule), will be accepted by Liminal Firewall without requiring any final approvals from the team.

Example 3

This example is ideal for organisations like exchanges and institutional investors including hedge funds. The following image illustrates the types of rules, which are explained as follows.

1. A transaction from any trade or reserve wallet of the organisation into any address with any protocol and BTC or ETH asset type, with the cumulative amount above $10M, triggered within a 1 day, will be rejected. For example, if you send $5M at 1 AM, $3M at 9 AM, and $2M at 5 PM, the total reaches $10M within a day. As a result, the final transaction of $2M will be rejected. If the amount is lower than this amount, the transaction will move to the next rule that matches it.
2. A transaction from any hot wallet into any address with any protocol and asset type, with an amount above $2M triggered within 6 hours, will be rejected. For example, if you send $1M at 1 AM, $500,000 at 3 AM, and $500,000 at 5 AM, the total reaches $2M within 6 hours. As a result, the final transaction of $500,000 will be rejected. If the amount is lower than this amount, the transaction will move to the next rule that matches the transaction.
3. A transaction from any reserve wallet into a whitelisted address with BTC protocol and BTC asset type, with an amount above $1M, will require three final approvals from team A. If the amount is lower than this amount, the transaction will move to the next rule that matches the transaction.
4. A transaction from any warm/cold MPC wallet into a whitelisted address with ETH protocol and ETH asset type, with an amount above $500,000, will require two final approvals from team B. If the amount is lower than this amount, the transaction will move to the next rule that matches the transaction.
5. A transaction from any treasury wallet into any address with any protocol and USDC or USDT asset type, with an amount above $250,000, will require a single final approval from team B. If the amount is lower than this amount, the transaction will move to the next rule that matches the transaction.
6. A transaction from any hot wallet into any address with any protocol and asset type, with an amount above $100,000, will require a single final approval from team A. If the amount is lower than this amount, the transaction will move to the next rule that matches the transaction.
7. A transaction from any warm/cold MPC wallet into a whitelisted address with BTC protocol and any asset type, with an amount above $5M, will require three final approvals from team B. If the amount is lower than this amount, the transaction will move to the next rule that matches the transaction.
8. A transaction from any treasury wallet into a whitelisted address with ETH protocol and USDC or DAI asset type, with an amount above $1M, will require a single final approval from team B. If the amount is lower than this amount, the transaction will move to the next rule that matches the transaction.
9. A transaction from any reserve wallet into any address with any protocol and asset type, with an amount above $500,000, will require two final approvals from team A. If the amount is lower than this amount, the transaction will move to the next rule that matches the transaction.
10. A transaction from any wallet into any address with any protocol and asset type, with any amount, will be accepted by Liminal Firewall without requiring any final approvals from the team.

Contact the Liminal Sales team at [email protected] to enable this policy for your Firewall transactions. Once enabled, you can check its activation in Vaults. Go to Settings > Firewall. Select View. If there’s a green dot under the Status column for Transfers policy, it means the policy is enabled for your organisation. Select the adjacent View icon to see all the configured rules for the policy.