策略

在你的工作区中设置可编程的防护规则，自动放行、拦截敏感操作，或将其转入常规审批流程。策略会根据你定义的规则评估每一笔提现和智能合约调用，让高风险活动在到达区块链之前就被拦截。

概述

策略是一组规则，每当有人发起受保护的操作（例如申请提现或调用智能合约）时都会自动运行。每条规则都描述一个条件（例如 "向非白名单地址提现，金额超过 $10,000"）和一个效果：

Deny：直接拦截该操作
Allow：让该操作跳过审批队列，直接执行

策略是一道始终在线的防线，与签名人审批相互补充。你无需依赖每位审批人记住资金管理规则，只需将这些规则编码一次，Fystack 就会在每笔交易上强制执行。

策略如何评估

当受保护的操作运行时，Fystack 会将其与所有作用于相关钱包的活跃策略进行比对，并采用符合托管安全要求的决策模型：

Deny 始终优先：只要有任何效果为 Deny 的规则匹配，该操作就会被拦截，即使另一条规则会放行它。
Allow 跳过审批：如果有效果为 Allow 的规则匹配且没有规则拒绝，该操作会跳过审批队列直接执行。
无匹配：如果没有任何规则匹配，该操作将继续走常规审批流程。

策略评估采用 失败即关闭（fail-closed） 机制。如果策略因任何原因无法评估，该操作会被拒绝而不是放行。这可以确保配置错误或系统问题永远不会在不知不觉中削弱你的管控。

触发操作

每条规则都作用于一种触发操作，即它所保护的操作类型：

触发器	保护对象
Withdrawal	在申请提现时进行评估。规则可以引用金额、美元价值、资产、目标地址、白名单状态、地址存在时长，以及钱包、工作区和网络的近期活动。
Contract Call	在调用智能合约方法时进行评估。规则可以引用网络、合约地址、方法选择器、方法名称、原生币金额、gas limit 以及解码后的调用参数。
Web3 Transfer	在通过 Web3 原始交易 API 发送原生币或 ERC-20 转账时进行评估。规则使用与提现相同的字段（金额、美元价值、资产、目标地址、地址簿条目、内部钱包），因此同一个条件在两种触发器上含义一致。ERC-20 转账同时也会作为 Contract Call 进行评估。
Web3 Message Signing	在请求钱包对消息签名（`personal_sign`、`eth_sign`、`eth_signTypedData_v4`）时进行评估。规则可以识别代币授权许可（EIP-2612、DAI、Permit2）及其 spender、代币、金额和截止时间。仅支持 Deny：签名消息始终需要审批。

如何创建策略

第 1 步：打开策略页面

在左侧边栏中打开 Policies，然后点击 Create Policy。

第 2 步：为策略命名并选择审批组

为策略设置一个清晰的 Name，描述它所保护的内容（例如 "Large withdrawal guard"）。然后选择负责审核该策略变更的审批组。

每个策略都与一个审批组绑定。这意味着策略不能被悄悄创建或编辑，任何变更都必须像提现一样经过审核和批准。

审批组默认预选为工作区的默认审批组。你可以将其更改为任何应负责审核该策略规则的审批组。

第 3 步：指定目标钱包（可选）

默认情况下，策略适用于工作区中的所有钱包。如需将其限定在部分钱包，请在 Wallets 字段中选择一个或多个钱包。策略规则将只针对这些钱包上的操作进行评估。

第 4 步：添加规则

为策略添加一条或多条规则。对于每条规则，选择 Trigger（Withdrawal、Contract Call、Web3 Transfer 或 Web3 Message Signing），构建 Condition，并选择 Effect（Allow 或 Deny）。

条件构建器会显示所选触发器可用的字段，你无需记住字段名称即可构建表达式。如果不想从零编写规则，可以从下方的某个策略模板开始。

策略也可以通过 JSON 构建器进行编程，适合希望复制粘贴规则或使用比 UI 支持的更复杂逻辑的高级用户。

第 5 步：提交审批

点击 Create。由于每个策略都需要经过审批，新策略此时尚未生效，它会连同所有规则一起，作为 Pending Approval 请求提交给对应的审批组。

第 6 步：批准策略

所分配审批组的成员打开待处理请求，审核拟议的策略及其规则，然后批准。只有这样，策略才会变为 Active 并开始保护交易。

后续的策略和规则变更也适用相同的审批流程：编辑规则、添加规则或删除策略都会创建新的审批请求。在审批组签署同意之前，任何变更都不会生效。

策略模板

从模板开始，而不是从空白策略开始。下面每个模板都是针对一种常见钱包配置的完整策略：包括它保护的内容、用通俗语言描述的规则，以及可直接粘贴到策略编辑器中的 JSON。

每个模板中的数值只是起点，而不是针对你业务量的建议值。一个不错的默认做法是将每个 Deny 上限设置为你最繁忙的正常一天的 2 到 3 倍左右，然后在经过一周真实流量后再进行调整。

使用模板

进入 Policies，点击 Create Policy，并将编辑器切换到 JSON 标签页。
粘贴模板中的 Policy JSON。
切换回 Form。选择 Approval Group 以及策略应覆盖的 Wallets。模板有意将两者留空，钱包列表为空表示覆盖工作区中的所有钱包。
打开每条规则，替换所有尖括号中的占位符，例如 <payout_api_key_id>。引用成员、API key、钱包或地址簿条目的规则会在构建器中显示选择器，你可以按名称选择，而无需查找其 ID。
根据你自己的业务量调整限额，然后点击 Create 并完成策略审批。

你也可以将同样的 JSON 发送到策略 API。

选择模板

模板	适用于	自动批准	主要限制
资金储备库	托管钱包和资金储备钱包	无	仅限地址簿地址，24 小时冷静期，每个钱包每天 250,000 USD
热钱包出款	团队使用的运营钱包	向可信地址的小额出款	向未知地址最多 2,000 USD，每天 50,000 USD，每小时 60 笔
API 出款机器人	自动化 API key 用于出款的钱包	单个 key 发起的 500 USD 以内出款	仅限稳定币，每笔出款 2,000 USD，该 key 每天 20,000 USD
充值归集	客户充值钱包	归集到资金储备钱包	资金只能转入资金储备钱包
DeFi 操作	使用 Web3 和 dApp 的钱包	无	仅限已批准的合约，禁止未知代币，禁止高风险签名
工作区兜底	所有钱包	无	整个工作区每天 500,000 USD，周末冻结大额提现

策略可以叠加。将工作区兜底应用于所有钱包，然后为每组钱包添加一个模板。由于 Deny 始终优先，兜底策略同样会为范围更窄的策略所自动批准的操作设定上限。

资金储备库

适用场景：持有储备金、每周只转账几次的钱包。没有任何操作会被自动批准，因此每笔转账仍需由审批人处理，而这些规则会拦截那些根本不应提交给审批人签署的转账。

钱包：选择你的托管钱包和资金储备钱包。

效果	规则	原因
Deny	拦截向任何不在地址簿中的外部地址的提现。	输入错误或被篡改的剪贴板地址永远不会被误批。
Deny	拦截向加入地址簿不足 24 小时的地址的提现。	能够编辑地址簿的人无法在同一天添加地址并将资金转走。
Deny	拦截会使钱包 24 小时内流出超过 250,000 USD 的提现（包含待处理的提现）。	在审批人被攻破或被欺骗时限制损失。
Deny	将地址簿规则同样应用于通过 Web3 API 发送的原生币和 ERC-20 转账。	堵住绕过提现规则的途径。

Policy JSON

{
  "name": "Treasury vault guard",
  "description": "Hard limits for custody and treasury wallets",
  "approval_group_id": "",
  "wallet_ids": [],
  "rules": [
    {
      "trigger_action": "withdrawal.create",
      "condition": "!withdrawal.destination_is_internal && !withdrawal.is_whitelisted",
      "effect": "DENY",
      "description": "Only send to address book entries or workspace wallets"
    },
    {
      "trigger_action": "withdrawal.create",
      "condition": "withdrawal.is_whitelisted && withdrawal.address_age_sec < 86400",
      "effect": "DENY",
      "description": "New address book addresses wait 24 hours"
    },
    {
      "trigger_action": "withdrawal.create",
      "condition": "wallet.projected_outflow_24h > 250000",
      "effect": "DENY",
      "description": "Cap each wallet at 250000 USD per 24 hours"
    },
    {
      "trigger_action": "web3.transfer",
      "condition": "!withdrawal.destination_is_internal && !withdrawal.is_whitelisted",
      "effect": "DENY",
      "description": "Apply the address book rule to Web3 transfers"
    }
  ]
}

调整建议

需要更严格的冷静期？将 86400（24 小时）改为 172800（48 小时）。
如需将托管资金限制在工作区内，使其只能转入你自己的热钱包，请添加一条 Deny 规则：wallet.purpose == 'custody' && !withdrawal.destination_is_internal。
如需以资产自身单位为单个资产设定上限，请添加 withdrawal.asset_symbol == 'BTC' && wallet.asset_projected_outflow_24h > 5。

热钱包出款

适用场景：团队每天用于出款的运营钱包。向已知收款方的小额常规出款可跳过审批，其他所有操作要么经过审核，要么被拦截。

钱包：选择你的热钱包或支付钱包。

效果	规则	原因
Deny	拦截向不在地址簿中的地址提现超过 2,000 USD 的请求。	较大金额必须转入经过审核的地址。
Deny	拦截会使钱包 24 小时内流出超过 50,000 USD 的提现。	为最坏情况设定上限，包括自动批准的出款。
Deny	当钱包在过去一小时内已发出 60 笔提现时，拦截后续提现。	识别发送大量小额提现的脚本或被攻破的会话。
Allow	向已在地址簿中至少 24 小时的地址提现不超过 1,000 USD 时，跳过审批。	审批人不必再在常规出款上花费时间。

提现会如何处理

提现	结果
向上周添加的地址簿条目转账 500 USD	被 Allow 规则自动批准
向一小时前添加的地址转账 500 USD	提交给审批人，因为该地址太新，不满足 Allow 规则
向未知地址转账 1,500 USD	提交给审批人
向未知地址转账 5,000 USD	被拦截
钱包今天已发出 49,500 USD 时，向可信地址转账 800 USD	被拦截，因为 Deny 始终优先于 Allow

Policy JSON

{
  "name": "Hot wallet payouts",
  "description": "Auto approve routine payouts and cap the worst case",
  "approval_group_id": "",
  "wallet_ids": [],
  "rules": [
    {
      "trigger_action": "withdrawal.create",
      "condition": "!withdrawal.destination_is_internal && !withdrawal.is_whitelisted && withdrawal.value_usd > 2000",
      "effect": "DENY",
      "description": "Unknown recipients are limited to 2000 USD"
    },
    {
      "trigger_action": "withdrawal.create",
      "condition": "wallet.projected_outflow_24h > 50000",
      "effect": "DENY",
      "description": "Cap each wallet at 50000 USD per 24 hours"
    },
    {
      "trigger_action": "withdrawal.create",
      "condition": "wallet.withdrawal_count_1h > 60",
      "effect": "DENY",
      "description": "Stop bursts of more than 60 withdrawals per hour"
    },
    {
      "trigger_action": "withdrawal.create",
      "condition": "withdrawal.is_whitelisted && withdrawal.address_age_sec >= 86400 && withdrawal.value_usd <= 1000",
      "effect": "ALLOW",
      "description": "Auto approve small payouts to trusted addresses"
    }
  ]
}

调整建议

优先调高或调低自动批准限额（1000）。请确保它远低于每个钱包的每日上限。
如果只想自动批准部分收款方（例如你的交易所账户），请将 Allow 规则中的 withdrawal.is_whitelisted 替换为 Destination · Address book entry is any of 你信任的条目。
如果你的团队有固定工作时间，请添加下方规则示例中的工作时间规则。

API 出款机器人

适用场景：通过 API key 向客户出款的后端服务。小额出款无需等待审批人即可发出，中等金额需经过审核，并且该 key 有严格的每日额度。

钱包：选择出款服务用于发款的钱包。

效果	规则	原因
Deny	禁止出款 key 发送 USDT 和 USDC 以外的任何资产。	泄露的 key 无法转移你的其他资产。
Deny	拦截该 key 发起的任何超过 2,000 USD 的单笔出款。	较大金额的出款必须由人工创建。
Deny	当该 key 在所有钱包上 24 小时内的出款将超过 20,000 USD 时，拦截该 key。	无论使用哪个钱包，该 key 都有每日额度。
Allow	该 key 发起的不超过 500 USD 的出款跳过审批。	客户可以立即收到小额出款。500 到 2,000 USD 之间的出款提交给审批人。

Policy JSON

{
  "name": "API payout bot",
  "description": "Budget and auto approval for the payout API key",
  "approval_group_id": "",
  "wallet_ids": [],
  "rules": [
    {
      "trigger_action": "withdrawal.create",
      "condition": "principal.api_key_id in ['<payout_api_key_id>'] && !(withdrawal.asset_symbol in ['USDT', 'USDC'])",
      "effect": "DENY",
      "description": "Payout key sends stablecoins only"
    },
    {
      "trigger_action": "withdrawal.create",
      "condition": "principal.api_key_id in ['<payout_api_key_id>'] && withdrawal.value_usd > 2000",
      "effect": "DENY",
      "description": "Payout key cannot send more than 2000 USD at once"
    },
    {
      "trigger_action": "withdrawal.create",
      "condition": "principal.api_key_id in ['<payout_api_key_id>'] && workspace.initiator_projected_outflow_24h > 20000",
      "effect": "DENY",
      "description": "Payout key is capped at 20000 USD per 24 hours"
    },
    {
      "trigger_action": "withdrawal.create",
      "condition": "principal.api_key_id in ['<payout_api_key_id>'] && withdrawal.value_usd <= 500",
      "effect": "ALLOW",
      "description": "Auto approve payouts up to 500 USD"
    }
  ]
}

调整建议

在每条规则中替换 <payout_api_key_id>，或使用 Initiator · API key 选择器选择该 key。四条规则中请使用同一个 key。
客户的收款地址通常不在你的地址簿中，因此该模板不要求地址簿。风险改由单笔上限和每日上限来控制。
如果你使用其他稳定币出款，请将更多符号（例如 'DAI'）添加到列表中。

充值归集

适用场景：为每位客户分配的充值钱包，其资金只应转入你的资金储备钱包。由于目标地址固定，这是最适合完全自动化的安全流程。

钱包：选择你的客户充值钱包，或将列表留空，依靠钱包用途检查来限定范围。

效果	规则	原因
Deny	拦截从充值钱包向资金储备钱包以外任何地址的提现。	充值资金永远无法直接离开工作区。
Allow	从充值钱包转入资金储备钱包的转账跳过审批。	归集无需等待任何人即可运行。

Policy JSON

{
  "name": "Deposit sweep",
  "description": "Deposit wallets sweep to treasury only",
  "approval_group_id": "",
  "wallet_ids": [],
  "rules": [
    {
      "trigger_action": "withdrawal.create",
      "condition": "wallet.purpose == 'user' && !(withdrawal.destination_wallet_id in ['<treasury_wallet_id>'])",
      "effect": "DENY",
      "description": "Deposit wallets can only send to the treasury"
    },
    {
      "trigger_action": "withdrawal.create",
      "condition": "wallet.purpose == 'user' && withdrawal.destination_wallet_id in ['<treasury_wallet_id>']",
      "effect": "ALLOW",
      "description": "Auto approve sweeps to the treasury"
    }
  ]
}

调整建议

替换 <treasury_wallet_id>，或使用 Destination · Workspace wallet 选择器进行选择。
如需允许多个归集目标，请将它们的 ID 添加到两个列表中。

DeFi 操作

适用场景：通过 Web3 API 与 dApp 交互的钱包。每次调用仍需经过审批人，而这些规则会拦截审批人通常无法仅凭原始数据判断的调用和签名。

钱包：选择你连接到 dApp 的钱包。

效果	规则	原因
Deny	拦截对任何不在你列表中的合约的调用。	钓鱼 dApp 无法将对未知合约的调用提交到审批人面前。
Deny	拦截对你的代币列表以外任何合约的代币授权（`approve`，选择器 `0x095ea7b3`）。	授权额度是日后盗空钱包的常见手段。
Deny	拦截不在 Fystack 资产目录中的代币转账。	未知代币没有美元价值，因此金额限制无法对其生效。
Deny	拦截签署无限额度的代币授权许可（permit）。	已签署的 permit 允许 spender 日后转移代币，而无需你再发起任何交易。
Deny	拦截为任何不在你列表中的 spender 签署 permit。	Permit 钓鱼通常会诱导你为攻击者控制的 spender 签名。
Deny	拦截 `eth_sign` 请求。	`eth_sign` 可以签署隐藏的交易，而现代 dApp 并不需要它。

Policy JSON

{
  "name": "DeFi operations guard",
  "description": "Approved contracts and safe signatures for dApp wallets",
  "approval_group_id": "",
  "wallet_ids": [],
  "rules": [
    {
      "trigger_action": "web3.contract_call",
      "condition": "!(resource.contract_address in ['<router_address>', '<vault_address>', '<token_address>'])",
      "effect": "DENY",
      "description": "Only call approved contracts"
    },
    {
      "trigger_action": "web3.contract_call",
      "condition": "resource.method_selector == '0x095ea7b3' && !(resource.contract_address in ['<token_address>'])",
      "effect": "DENY",
      "description": "Only approve allowances on known tokens"
    },
    {
      "trigger_action": "web3.transfer",
      "condition": "!withdrawal.asset_is_known",
      "effect": "DENY",
      "description": "Block transfers of unknown tokens"
    },
    {
      "trigger_action": "web3.sign_message",
      "condition": "resource.is_permit && resource.permit_amount_is_unlimited",
      "effect": "DENY",
      "description": "Block unlimited token permits"
    },
    {
      "trigger_action": "web3.sign_message",
      "condition": "resource.is_permit && !(resource.permit_spender in ['<trusted_spender_address>'])",
      "effect": "DENY",
      "description": "Block permits to untrusted spenders"
    },
    {
      "trigger_action": "web3.sign_message",
      "condition": "resource.method == 'eth_sign'",
      "effect": "DENY",
      "description": "Block raw eth_sign"
    }
  ]
}

调整建议

合约和代币地址必须为小写。
在启用策略之前，请添加你的策略所用到的每个合约（例如路由、金库和代币合约），否则合法调用也会被拦截。
消息签名规则仅支持 Deny。通过这些规则的签名仍需提交给审批人。

工作区兜底

适用场景：覆盖所有钱包的安全网。它可以识别分散在多个钱包、key 或成员之间的资金流失，而这是单个钱包限额无法发现的。

钱包：将列表留空，使策略覆盖所有钱包。

效果	规则	原因
Deny	拦截会使整个工作区 24 小时内流出超过 500,000 USD 的提现。	无论其他策略如何放行，这都是绝对上限。
Deny	当工作区在过去一小时内已发出 300 笔提现时，拦截后续提现。	识别分散在多个钱包上的自动化滥用。
Deny	在周六和周日（UTC）拦截超过 25,000 USD 的提现。	大额转账会等到团队在岗时再处理。

Policy JSON

{
  "name": "Workspace backstop",
  "description": "Workspace wide ceilings for all wallets",
  "approval_group_id": "",
  "wallet_ids": [],
  "rules": [
    {
      "trigger_action": "withdrawal.create",
      "condition": "workspace.projected_outflow_24h > 500000",
      "effect": "DENY",
      "description": "Cap the workspace at 500000 USD per 24 hours"
    },
    {
      "trigger_action": "withdrawal.create",
      "condition": "workspace.withdrawal_count_1h > 300",
      "effect": "DENY",
      "description": "Stop bursts of more than 300 withdrawals per hour"
    },
    {
      "trigger_action": "withdrawal.create",
      "condition": "context.day_of_week in ['Saturday', 'Sunday'] && withdrawal.value_usd > 25000",
      "effect": "DENY",
      "description": "No withdrawals over 25000 USD on weekends"
    }
  ]
}

调整建议

日期和小时均为 UTC 时间。
将工作区上限设置在所有钱包正常最繁忙日之和以上，使兜底策略只在真正出现异常时触发。

规则示例

以下是可添加到任何策略中的单条规则。将条件粘贴到规则的 Expression 标签页中，或在 Fields 中构建。

目标	触发器	效果	条件
拦截一组地址，例如受制裁地址或诈骗地址	Withdrawal	Deny	`withdrawal.address_book_id in ['<blocklist_entry_id>']`。将这些地址保存在同一个地址簿条目中，这样更新条目即可同步更新规则。
只有所有者和管理员可以发送超过 50,000 USD	Withdrawal	Deny	`!(principal.role in ['owner', 'admin']) && withdrawal.value_usd > 50000`
仅允许在工作时间（UTC 09:00 至 18:00）进行大额提现	Withdrawal	Deny	`withdrawal.value_usd > 25000 && (context.hour < 9 \|\| context.hour >= 18)`。由于使用了括号，请在 Expression 标签页中编写。
将单个钱包限制为每天 5 BTC	Withdrawal	Deny	`withdrawal.asset_symbol == 'BTC' && wallet.asset_projected_outflow_24h > 5`
将单个网络限制为每天 100,000 USD	Withdrawal	Deny	`withdrawal.network_code == '<network_code>' && workspace.network_projected_outflow_24h > 100000`
自动批准你自己钱包之间的转账	Withdrawal	Allow	`withdrawal.destination_is_internal && withdrawal.value_usd <= 10000`
自动批准向可信交易所账户的充值	Withdrawal	Allow	`withdrawal.address_book_id in ['<exchange_entry_id>'] && withdrawal.address_age_sec >= 172800 && withdrawal.value_usd <= 25000`
防止审批队列中的请求堆积	Withdrawal	Deny	`wallet.pending_outflow > 100000`。当已有 100,000 USD 在等待处理时，拦截新的请求。
拦截费用异常高的合约调用	Contract Call	Deny	`resource.gas_limit > 1000000`

逐步推行策略

Allow 规则会改变哪些人需要查看交易，因此应最后引入。

第一周，仅使用 Deny 规则：创建只包含 Deny 规则的策略。此时没有任何操作会被自动批准，规则只拦截绝不应发生的操作。
检查审批队列：找出审批人每次都原样批准的提现，例如相同的收款方、资产和金额范围。
添加范围较窄的 Allow 规则：为这类流量精确编写一条 Allow 规则，并将限额设得比预期需要的更低。
逐步提高限额：只有在 Allow 规则平稳运行一段时间后才扩大其范围。每次变更都需要经过审批，并会显示在策略的变更历史中。

添加 Allow 规则时，请确认有 Deny 上限覆盖相同的钱包，例如按钱包或按 key 的预计流出限额。由于 Deny 始终优先，该上限对自动批准的提现同样适用。

编写规则条件

条件是一个求值结果为 true 或 false 的表达式。当结果为 true 时，规则的效果生效。可以使用 and、or 和 not 组合字段，并使用 >、>=、== 和 != 等运算符比较值。

你可以在保存前校验条件。构建器会根据触发器的可用字段检查表达式并标出所有错误，确保你不会提交无法运行的规则。

条件字段

构建器中可用的字段取决于规则的触发器。决定在规则中使用哪个字段时，请参考以下标签。

所有触发器均可用

字段	用途
Initiator type	操作来自 Web 会话（`user`）还是 API key（`api_key`）。
Member	针对特定工作区成员的规则。从成员列表中选择。
API key	针对特定 API key 的规则，例如自动化出款 key。Web 会话没有 API key，因此请将 `is none of` 检查与 Initiator type 结合使用。
User role	基于工作区角色的规则：owner、admin、signer、proposer 或 viewer。
Hour	按一天中的时间进行控制，使用 0 到 23 的 UTC 小时。
Day of week	工作时间、周末或仅限工作日的规则。
Source wallet	在同一策略内针对特定钱包的规则。
Source wallet purpose	按钱包用途划分的规则：general、custody、payment、user、one-time use、gas tank 或 deployment。
Source wallet type	对 MPC 钱包和标准钱包实施不同的管控。
User email (legacy)	对现有规则仍会进行评估。新规则请使用 Member，因为邮箱可能会变更。

提现字段

字段	用途
Amount	以资产计价的限额，例如超过 10 ETH 或 1 BTC。
Value USD	跨资产的美元计价限额。
Asset symbol	针对 USDT、ETH、BTC 或 SOL 等特定资产符号的规则。
Native asset	对网络原生资产和代币实施不同的管控。
Destination address	拦截或放行特定的收款地址。
Network code	针对特定网络的限额，例如在某条链上采用更严格的规则。
In address book	针对是否存在于任何地址簿条目中的收款方进行管控。
Address book entry	针对特定地址簿条目进行管控。一个条目涵盖其中的所有地址，因此条目可以作为一个命名列表使用。
Address age	冷静期规则：目标地址被加入其地址簿条目以来经过的秒数。
Internal wallet	针对同一工作区内钱包之间的转账进行管控。
Workspace wallet	针对转入同一工作区内特定钱包的转账进行管控。

引用成员、API key、地址簿条目或钱包的字段在条件构建器中使用选择器。Fystack 会存储其 ID，在规则出现的所有位置（包括审批请求）显示名称，并在保存时检查每个 ID 是否属于你的工作区。如果某个实体之后被删除或吊销，规则会将其显示为未知引用，此时规则只会匹配得更少，而不会更多。

提现活动字段

字段	用途
Wallet outflow	单个钱包在过去 1、6 或 24 小时内的美元流出量。
Wallet withdrawal count	针对单个钱包在过去一小时内大量提现的突发控制。
Workspace outflow	整个工作区在过去 1、6 或 24 小时内的美元流出量。
Workspace withdrawal count	整个工作区在过去一小时内的提现笔数。
Network outflow	工作区在所选网络上过去 1、6 或 24 小时内的美元流出量。
Network withdrawal count	工作区在所选网络上过去一小时内的提现笔数。

待处理与预计活动字段

字段	用途
Pending outflow	尚未执行的提现（等待审批、排队中或正在补充 gas）的美元价值，无论其已等待多久。可按钱包、工作区和网络使用。
Projected 24h outflow	过去 24 小时内的已实现流出量，加上待处理流出量，再加上当前正在检查的提现。可用于设置限额：`projected 24h outflow over $100,000` 表示这笔提现会超出限额。可按钱包、工作区和网络使用。
Projected 24h asset outflow	针对来源钱包的相同预计值，以所提现资产为单位，例如每天最多 5 BTC。
Initiator projected 24h outflow	针对同一成员或 API key 在整个工作区内创建的提现的相同预计值。

流出量和笔数字段基于已实现的提现计算：它们只统计已执行或已确认的提现资金。待处理和预计字段还会统计尚未执行的提现。当活跃规则使用待处理或预计字段时，Fystack 会逐一检查工作区的提现，因此同时发送的两个请求不可能都通过限额。等待处理超过 5 秒的请求会被以 HTTP 429 拒绝，可以重试。

合约调用字段

字段	用途
Network code	针对特定链的合约调用规则。
Contract address	拦截未知合约或放行已知合约。
Method selector	底层函数检查，例如 ERC-20 transfer 选择器 `0xa9059cbb`。
Method name	在有元数据时进行易读的方法检查。
Value wei	随合约调用发送的原生币金额。
Gas limit	拦截费用异常高或有风险的调用。
Decoded arguments	当 Fystack 能够解码调用时，可编写参数级规则。ERC-20 转账会暴露收款方和代币金额。

只有在调用可以被解码时，才能使用解码后的参数。在 JSON 构建器中，读取值之前请先对解码参数检查进行保护判断。

Web3 转账字段

Web3 Transfer 规则使用提现字段以及下方的字段。由于这些转账不属于提现，因此无法使用活动字段。

字段	用途
Asset in catalog	当代币合约不在资产目录中时为 false。此时金额、美元价值和符号均为空，因此如有需要，请显式拒绝未知代币。
Token contract	针对特定代币合约的规则。原生币为空。

消息签名字段

字段	用途
Signing method	`personal_sign`、`eth_sign` 或 `eth_signTypedData_v4`。
Typed data type, domain name, verifying contract	针对特定类型化数据消息的规则，例如某个已知 dApp 的订单。
Is a token permit	对于 EIP-2612、DAI 和 Permit2 消息为 true，这类消息允许 spender 日后无需再次签名即可转移代币。
Permit spender	拒绝向你不信任的 spender 授予 permit。
Permit tokens	permit 所涵盖的代币合约。在表达式编辑器中使用，例如 `'0x…' in resource.permit_tokens`。
Permit unlimited amount	对于最大值授权（2¹⁵⁹ 或以上，或设置了 allowed 的 DAI permit）为 true。
Permit deadline	permit 或其签名过期的 Unix 时间。消息中没有该值时为 0。

策略状态

状态	含义
Pending	该策略或其变更正在等待审批组签署同意，尚未生效。
Active	该策略已获批准并生效。其规则会针对目标钱包上的每个受保护操作进行评估。
Inactive	该策略已被禁用，不会进行评估。
Rejected	待处理的变更被审批人拒绝，未生效。

变更历史

策略的每次变更都会被记录。策略的 History 会显示每个修订版本的提出人、具体变更内容（逐字段）以及是否被批准或拒绝。这为你提供了防护规则随时间演变的完整审计记录。

最佳实践

在添加便利性的 Allow 规则之前，先为风险最高的场景（大额转账、未知目标地址）设置 Deny 规则
请记住 Deny 始终优先，可借此设置任何 Allow 规则都无法覆盖的硬性限制
当不同钱包的风险特征不同时，将策略限定到特定钱包，而不是到处套用一个宽泛的策略
谨慎使用 Allow 规则，它们会绕过审批队列，因此仅用于低金额、明确可信的场景
当 Allow 规则信任地址簿条目时，请保留构建器添加的地址存在时长条件。任何能编辑地址簿的人都可以向可信条目中添加地址，而时长检查可确保新地址在被自动批准前需要等待一段时间
提交前校验每个条件，并在审批环节检查变更，确认其行为符合预期
像对待提现一样谨慎对待策略变更，审批关卡的存在就是为了确保任何人都无法在不被察觉的情况下削弱你的管控