建立原則

原則是一組可以封鎖簽署要求的規則。簽署要求包括區塊鏈交易和簽署資料的要求，例如 EIP-712 類型資料。每個儲存的規則都有範圍、條件和 BLOCK 回應。啟用的規則會累計套用：如果有任何適用的規則相符項目，要求就會被拒絕。

如果原則評估順利完成且沒有適用的規則傳回 BLOCK 回應，則 UWaaS 公事包管理程式 (UWM) 會認證呼叫程式、授權公事包和金鑰，以及驗證簽署要求之後，便可繼續進行要求。

如需有關 UWaaS 公事包管理程式的資訊，請參閱通用公事包即服務 (UWaaS) 。如需 API 要求欄位和作業的相關資訊，請參閱通用公事包管理程式 API ，包括：

定義規則條件

規則會結合條件與 all、any 及 not。您可以巢狀化這些群組以定義限制：

每個子項條件都相符時，all 就會相符。
至少有一個子項條件相符時，any 就會相符。
當其子項條件不相符時，not 就會相符。

以內嵌方式定義條件群組。UWM 簽署規則不支援具名條件參照。

條件分葉指定事實、運算子以及值。使用 path 從事實中選取巢狀特性。較高的 priority 值會先評估。

{
  "fact": "to_address",
  "operator": "in",
  "value": ["<blocked-address>"]
}

當事實等於其中一個列出的值時，in 運算子就會相符。使用 all 將此條件與 operation 條件結合。當數個條件之一可以觸發限制時，請使用 any。

運算子

運算子	使用時機的條件
`equal`, `notEqual`	定量事實必須等於或不同於相同類型的值。
`in`, `notIn`	純量事實必須出現在值清單中或不顯示。
`contains`, `doesNotContain`	陣列事實必須包含或不包含值。
`lessThan`, `lessThanEquals` (`lessThanInclusive`)	數值事實必須小於或等於數值。
`greaterThan`, `greaterThanEquals` (`greaterThanInclusive`)	數值事實必須大於或等於數值。

amount、amount_atomic 和 native_value_atomic 上的排序比較使用 /evaluate 和 /internal/v1/authorize 上完全相同的小數算術。

針對單元數量和大型臨界值使用小數字串。舉例而言：

{ "fact": "amount_atomic", "operator": "greaterThanEquals", "value": "1000000000000000000" }

UWM 以基準單位提供 amount_atomic，且不會將其轉換為變數替代字小數位數。/evaluate 的呼叫者提供時，支援 amount 事實；UWM 不會將它新增至簽署事實。

接受安全數字範圍內的小數 JSON 數字。以字串形式傳送較大的數值；拒絕較大的數值文字。仍然支援 greaterThanInclusive 和 lessThanInclusive 運算子名稱。equal 與 notEqual 運算子會依類型比較值。其他事實則保留其現有的比較行為。

陣列裝飾器

在運算子前面加上一個修飾符號和一個冒號，例如 someFact:equal。裝飾器可變更運算子處理陣列或其結果的方式。

修飾器	使用時機的條件
`someFact`	陣列事實中至少有一個項目相符。
`everyFact`	陣列事實中的每個項目都相符。
`someValue`	事實至少符合陣列值中的一個項目。
`everyValue`	事實與陣列值中的每個項目相符。
`swap`	比較會使用這個值作為事實，而事實是它的值。
`not`	基礎運算子結果必須為否定。

例如，someFact:equal 可以比對為解碼的 ERC-1155 批次呼叫所提供之 token_ids 陣列中的一個記號 ID：

{
  "fact": "token_ids",
  "operator": "someFact:equal",
  "value": "42"
}

使用布林邏輯的 not 條件群組和 not: 修飾條件來否定個別運算子。條件與規則優先順序集評估順序。它們不允許一個規則置換另一個相符的 BLOCK。

設定規則範圍

設定 scopelevels 和 targets，以指定規則涵蓋的簽署要求。每個選取的範圍都必須相符。一個範圍內的目標為替代項目。

範圍	必要目標	使用它
`global`	無；指定 `scopelevels: ["global"]` 本身。	適用於每個簽署要求的限制。
`org`	`targets.orgIds`	一或多個組織的限制。
`wallet`	`targets.walletIds`	一或多個公事包的限制。
`instance`	`targets.instanceIds`	一或多個網路執行處理的限制。
`asset`	`targets.assetIds`	現有的資產作用領域規則；保留以保持相容性。

當規則相依於一個以上的維度時合併範圍。例如，

scopelevels: ["org",
        "wallet"]

必須同時比對組織和公事包目標。僅限公事包規則沒有隱含的組織界限。使用 UWM 傳回的 ID，而非顯示名稱。

若要限制合約方法，請在條件中比對 contract_address 與 function_selector。如果相同方法需要不同網路的不同限制，請新增 instance 範圍。asset 範圍會保留在現有的規則中；這些條件不需要。

對於 targets.instanceIds，請使用 UWM 公事包或網路 API 顯示的公用 instanceId。這是已登錄的 infra_instance_id，不是數值資料庫金鑰或鏈 ID。更新使用資料庫金鑰的舊版執行處理作用領域規則；UWM 現在只會傳送公用執行處理 ID。

比對簽署要求

條件只能使用提供給要求之 operation 的事實。operation 事實適用於每個簽署要求。

`operation`	其他事實
`native-transfer`	`amount_atomic`, `to_address`
`erc20-transfer`	`amount_atomic`, `to_address`, `contract_address`
`contract-deployment`	`amount_atomic`, `init_code_hash`
`contract-call`	`contract_address`, `native_value_atomic`, `function_selector`, `calldata_hash`
`eip712`	`primary_type`, `verifying_contract`, `typed_data`

UWM 可辨識不含記號註冊的原生值為零的正規 ERC-20 transfer(address,uint256) 呼叫。UWM 已不再讀取 capability.approved-token-contracts。

erc20-transfer 設定檔也提供 native_value_atomic ("0")、function_selector ("0xa9059cbb") 以及 calldata_hash。這些事實允許現有的 contract-call 規則保留其完整限制。

erc20-transfer 作業也是作業條件的 contract-call。這兩種規則類型都可以符合相同的要求，而且任何符合的 BLOCK 都會拒絕。此行為適用於兩個評估端點的 equal、notEqual、in、notIn 以及巢狀布林條件。其他事實則保留其正常平等語意。

erc20-transfer 作業會比對 transfer，而不是 transferFrom 或 ERC-1155 方法。一律在記號規則中包含預期的 contract_address。

正規 ERC-20 transferFrom、ERC-1155 safeTransferFrom 和 ERC-1155 safeBatchTransferFrom 呼叫提供額外的 contract-call 事實：

通話	其他事實
ERC-20 `transferFrom`	`owner_address`, `to_address`, `amount_atomic`
ERC-1155 `safeTransferFrom`	`owner_address`, `to_address`, `token_id`, `amount_atomic`
ERC-1155 `safeBatchTransferFrom`	`owner_address`、`to_address`、平行 `token_ids` 和 `amounts` 陣列

UWM 只會解碼具有支援之正規 ABI 版面配置的呼叫。其他呼叫則保留一般的 contract-call 事實。

owner_address 是呼叫資料中的來源位址，而非簽署公事包。選取器可識別呼叫資料版面配置，而非已部署合約的行為。ERC-20 與 ERC-721 共用 transferFrom 選取器，因此僅將金額條件套用至已知導入 ERC-20 的合約。地址與選取器已標準化為小寫；請使用小寫條件值。針對批次呼叫，請勿將不同變數替代字 ID 的金額總計。

amount_atomic 和 native_value_atomic 是以基本單位表示的十進位字串；原生值是以 Wei 表示。EIP-712 整數值也是十進位字串。對於 EIP-712，typed_data 包含已簽署的網域和訊息。path 相對於該事實：對訊息值使用 $.message.value，對已簽署的鏈結 ID 使用 $.domain.chainId。

公事包、組織及網路限制屬於 wallet、org 及 instance 範圍。簽字者、氣體和 nonce 描述資料不是條件事實。asset 範圍目標不會新增 asset 條件事實。

啟用簽署規則之前

只使用「比對簽署要求」底下所列的作業事實。當規則使用作業特定的事實時，包括 operation 條件。

儲存規則並不會確認 UWM 可在簽署期間評估規則。例如，UWM 不提供 tier 事實。檢查 tier 是否等於 gold 的規則可能會導致簽署因一般 500 錯誤而失敗。

如果在啟用規則之後簽署失敗，請複查其事實、條件和範圍。更正規則，或要求授權的管理員停用規則 (如果是非預期的預留位置)。停用必要的限制會移除其保護。

在生產環境啟用規則之前，請先針對測試相關資訊環境中的預期範圍啟用規則，並確認提交實際簽署要求時是否允許或封鎖。僅 /evaluate 端點在簽署期間不會驗證行為，因為它接受使用者提供的事實，這可能與在簽署期間提供的事實不同。

建立一個規則

此範例會封鎖一個組織的原生傳輸至一個地址。以環境的值取代範例 ID 和位址。規則已停用，除非您啟用，否則不會封鎖要求。請先複查範圍與條件，再啟用規則。

{
  "name": "block-restricted-native-recipient",
  "description": "Block native transfers to the restricted recipient",
  "category": "transaction-policy",
  "enabled": false,
  "scopelevels": ["org"],
  "targets": {
    "orgIds": ["<organization-id>"]
  },
  "conditions": {
    "all": [
      {
        "fact": "operation",
        "operator": "equal",
        "value": "native-transfer",
        "priority": 100
      },
      {
        "fact": "to_address",
        "operator": "equal",
        "value": "0x3333333333333333333333333333333333333333",
        "priority": 1
      }
    ]
  },
  "response": {
    "type": "BLOCK",
    "params": {
      "reason": "restricted-recipient"
    }
  }
}

將 operation 條件放在最前面，並將其指派比作業特定事實更高的優先順序。在簽署授權期間，如果評估讀取了遺漏的事實，評估就會失敗；要求不會靜默地被允許。

評估端點會根據您提交的事實檢查規則。即時簽署會使用 UWM 之已驗證要求和已解析公事包之範圍目標的事實。使用評估來檢查條件，然後透過預期的簽署流程確認結果。