@wowok/agent-mcp 3.1.0 → 3.1.2

package/dist/schemas/onchain_operations_service.schema.json

@@ -149,7 +149,7 @@
                               "type": "string"
                             }
                           ],
-                          "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                          "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                         }
                       },
                       "required": [
@@ -1013,7 +1013,7 @@
                                 "type": "string"
                               }
                             ],
-                            "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                            "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                           },
                           {
                             "type": "null"
@@ -1071,7 +1071,7 @@
                       "type": "string"
                     }
                   ],
-                  "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                  "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                 }
               },
               "required": [
@@ -1118,7 +1118,7 @@
               "type": "object",
               "properties": {
                 "for_object": {
-                  "description": "Object this distribution belongs to (e.g. the order for a per-order allocation, recorded at creation). Auditors can query it to see the distribution's business context.",
+                  "description": "Binding anchor for this distribution. On an Allocation a SET for_object is ENFORCED at alloc(): every GuardIdentifier recipient submission must equal this address or the whole tx aborts (ERECIPIENT_NOT_FOR_OBJECT, code 15) — verify the anchor matches the intended recipient flow BEFORE create; payment_info is immutable afterwards. NULL/omitted = no anchor: nothing is enforced on-chain, recipient routing is entirely the creator's design. Also recorded at creation for auditors to query the distribution's business context.",
                   "anyOf": [
                     {
                       "type": "string"
@@ -1188,7 +1188,7 @@
                       "type": "string"
                     }
                   ],
-                  "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                  "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                 },
                 "token_type": {
                   "type": "string",
@@ -1212,7 +1212,7 @@
                             "type": "string"
                           }
                         ],
-                        "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                        "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                       },
                       "payment": {
                         "type": "string",
@@ -1306,7 +1306,7 @@
                       "type": "string"
                     }
                   ],
-                  "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                  "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                 },
                 "token_type": {
                   "type": "string",
@@ -1330,7 +1330,7 @@
                             "type": "string"
                           }
                         ],
-                        "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                        "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                       },
                       "payment": {
                         "type": "string",

package/dist/schemas/onchain_operations_treasury.schema.json

@@ -113,7 +113,7 @@
                       "type": "string"
                     }
                   ],
-                  "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                  "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                 },
                 "token_type": {
                   "type": "string",
@@ -137,7 +137,7 @@
                             "type": "string"
                           }
                         ],
-                        "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                        "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                       },
                       "payment": {
                         "type": "string",
@@ -199,7 +199,7 @@
                           "type": "string"
                         }
                       ],
-                      "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                      "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                     }
                   },
                   "required": [
@@ -232,7 +232,7 @@
               "type": "object",
               "properties": {
                 "for_object": {
-                  "description": "Object this distribution belongs to (e.g. the order for a per-order allocation, recorded at creation). Auditors can query it to see the distribution's business context.",
+                  "description": "Binding anchor for this distribution. On an Allocation a SET for_object is ENFORCED at alloc(): every GuardIdentifier recipient submission must equal this address or the whole tx aborts (ERECIPIENT_NOT_FOR_OBJECT, code 15) — verify the anchor matches the intended recipient flow BEFORE create; payment_info is immutable afterwards. NULL/omitted = no anchor: nothing is enforced on-chain, recipient routing is entirely the creator's design. Also recorded at creation for auditors to query the distribution's business context.",
                   "anyOf": [
                     {
                       "type": "string"
@@ -327,7 +327,7 @@
                           "type": "string"
                         }
                       ],
-                      "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                      "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                     }
                   },
                   "required": [
@@ -371,7 +371,7 @@
               "type": "object",
               "properties": {
                 "for_object": {
-                  "description": "Object this distribution belongs to (e.g. the order for a per-order allocation, recorded at creation). Auditors can query it to see the distribution's business context.",
+                  "description": "Binding anchor for this distribution. On an Allocation a SET for_object is ENFORCED at alloc(): every GuardIdentifier recipient submission must equal this address or the whole tx aborts (ERECIPIENT_NOT_FOR_OBJECT, code 15) — verify the anchor matches the intended recipient flow BEFORE create; payment_info is immutable afterwards. NULL/omitted = no anchor: nothing is enforced on-chain, recipient routing is entirely the creator's design. Also recorded at creation for auditors to query the distribution's business context.",
                   "anyOf": [
                     {
                       "type": "string"
@@ -797,7 +797,7 @@
                       "type": "string"
                     }
                   ],
-                  "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                  "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                 },
                 "token_type": {
                   "type": "string",
@@ -821,7 +821,7 @@
                             "type": "string"
                           }
                         ],
-                        "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
+                        "description": "A coin/balance amount. Accepts three formats: (1) DISPLAY FORMAT with token symbol: \"2.5WOW\", \"10USDC\", \"0.05WOW\" — auto-converted to smallest units via the Fund Processing Layer (token precision resolved from official registry → cache → on-chain). The symbol MUST match the token's type_parameter. (2) SMALLEST UNIT (numeric string): \"10000000000\" — used as-is, no conversion. (3) SMALLEST UNIT (number): 10000000000 — used as-is only within the safe integer range (±2^53); numbers outside it are REJECTED, use a numeric string instead. PRECISION RULE: for values exceeding 2^53 (9007199254740991), ALWAYS use format (1) or (2) — JS numbers lose integer precision silently and such inputs are blocked. Raw amounts must be plain non-negative integers; a decimal value without a token symbol (e.g. \"2.5\") is rejected — append the symbol (\"2.5WOW\") so the Fund Processing Layer converts it. WARNING — BARE INTEGER MEANS SMALLEST UNIT, NOT TOKENS: formats (2)/(3) are NEVER interpreted as display tokens. For example amount=\"5\" or 5 means 5 raw units = 0.000000005 WOW (9 decimals) — NOT 5 WOW. When the user asks for a token amount, you MUST use display format (\"5WOW\", \"2USDC\"); a bare integer is only correct for unitless counts (e.g. stock quantity) or when you computed exact raw units yourself. Default token: WOW (9 decimals, 1 WOW = 10^9 MIST). For custom tokens: use display format with the token's symbol, or pass smallest units directly. MONEY CONFIRMATION: all monetary fields trigger user confirmation via the Fund Processing Layer, where the token's FULL type, decimals and raw amount are always visible. MULTIPLE ISSUERS: several on-chain tokens may legally share the same symbol (e.g. multiple \"USDT\" coins). When a bare symbol matches more than one token, the operation is BLOCKED and every candidate is listed with full details (type, name, decimals, verified tag) — present the list to the USER and let them choose (they may answer by number), then re-issue with the chosen token's FULL type string in type_parameter; never guess an issuer from the bare symbol. MISSING TOKEN INFO: when a token's precision cannot be resolved, the operation is REFUSED (raw u64 included — amount magnitude could not be verified). Recovery: provide the token's FULL type in package::module::Name form in type_parameter (a bare symbol like \"USDT\" cannot be resolved), and verify the WOW network is correct. Examples: \"2.5WOW\" (display → 2500000000), 10000000000 (number, smallest unit), \"50000000000\" (string, smallest unit). Used for: Service.sale.price, Service.compensation_fund_add balance, Treasury.deposit, Arbitration.fee, Reward.amount, stock quantities."
                       },
                       "payment": {
                         "type": "string",

package/dist/schemas/onchain_table_data.output.json

@@ -2066,7 +2066,7 @@
                             "type": "boolean"
                           },
                           "favor": {
-                            "description": "Whether favorited (收藏)",
+                            "description": "Whether favorited",
                             "type": "boolean"
                           },
                           "time": {
@@ -4662,7 +4662,7 @@
                                 "type": "boolean"
                               },
                               "favor": {
-                                "description": "Whether favorited (收藏)",
+                                "description": "Whether favorited",
                                 "type": "boolean"
                               },
                               "time": {
@@ -9160,6 +9160,10 @@
               "description": "On-chain object address (0x followed by 32-64 hex chars) for object_panorama. Also accepts a LocalMark NAME (resolved automatically). H-06 fix: invalid formats are rejected at the handler level with a descriptive error.",
               "type": "string"
             },
+            "filter": {
+              "description": "DEPRECATED alias of object_address (accepted for call compatibility; must be a plain address or LocalMark NAME string, not an object). Prefer object_address. Example: {\"query_type\": \"object_panorama\", \"object_address\": \"0xabc...\"}.",
+              "type": "string"
+            },
             "context_network": {
               "type": "string",
               "enum": [
@@ -9420,7 +9424,7 @@
             "query_type"
           ],
           "additionalProperties": false,
-          "description": "Business Relationship Graph (K3/19): derive ONE account's full relationship web from on-chain power carriers (Permission memberships, Machine forwards, Orders, Demand presenters, Allocation sharing, Arbitration bindings, Contact ims). Each edge carries the three dimensions — 权属 power (what each side CAN do, and where that power lives on-chain), 利益 interest (gains/exposures, with registry-declared goal tensions like principal-agent divergence), and 价值交互 value flows (escrow → allocation → payment chains). Read-only; roles are DERIVED from chain data, never asserted."
+          "description": "Business Relationship Graph (K3/19): derive ONE account's full relationship web from on-chain power carriers (Permission memberships, Machine forwards, Orders, Demand presenters, Allocation sharing, Arbitration bindings, Contact ims). Each edge carries the three dimensions — power (what each side CAN do, and where that power lives on-chain), interest (gains/exposures, with registry-declared goal tensions like principal-agent divergence), and value flows (escrow → allocation → payment chains). Read-only; roles are DERIVED from chain data, never asserted."
         },
         {
           "type": "object",
@@ -9609,7 +9613,7 @@
               "type": "string"
             },
             "interest_role": {
-              "description": "G2 role interest view — project THIS CommercialRole's complete interest view (利益评估 stakes + 可行操作路径 node-game actions + 博弈对手分析 + 风险提醒) for context_account (or the seed when it is an EOA) over the same expanded graph. The view is returned as result.role_interest and as one IR:<role> finding carrying the same structured payload. Scoring comes exclusively from the evaluation game modules; when omitted, defaults to the persona 'role' lens if provided.",
+              "description": "G2 role interest view — project THIS CommercialRole's complete interest view (interest-assessment stakes + node-game actions + counterparties + risk reminders) for context_account (or the seed when it is an EOA) over the same expanded graph. The view is returned as result.role_interest and as one IR:<role> finding carrying the same structured payload. Scoring comes exclusively from the evaluation game modules; when omitted, defaults to the persona 'role' lens if provided.",
               "type": "string",
               "enum": [
                 "merchant",
@@ -10618,14 +10622,14 @@
                     "description": "Business meaning of advancing to this node. Example: 'Guide starts the day service'"
                   },
                   "gains": {
-                    "description": "Gains for the caller if this option is chosen (K3 Game G1 收益分离). Example: ['Settlement triggered — funds released to provider']",
+                    "description": "Gains for the caller if this option is chosen (K3 Game G1 gain separation). Example: ['Settlement triggered — funds released to provider']",
                     "type": "array",
                     "items": {
                       "type": "string"
                     }
                   },
                   "risks": {
-                    "description": "Risks for the caller if this option is chosen (K3 Game G1 风险分离). Example: ['Refund leverage lost after confirmation']",
+                    "description": "Risks for the caller if this option is chosen (K3 Game G1 risk separation). Example: ['Refund leverage lost after confirmation']",
                     "type": "array",
                     "items": {
                       "type": "string"
@@ -10655,7 +10659,7 @@
               "description": "ALL reachable next-node directions (every operator/permission/guard disclosed)."
             },
             "recommendation": {
-              "description": "Recommended option with rationale (K3 Game 意图/博弈/利益).",
+              "description": "Recommended option with rationale (K3 Game intent/game/interests).",
               "type": "object",
               "properties": {
                 "best": {
@@ -10667,7 +10671,7 @@
                   "type": "string"
                 },
                 "caveat": {
-                  "description": "Disclosed trade-off / opportunity cost of NOT taking another path (K3 Game G3 机会成本). Example: 'Choosing cancelled forfeits this order's settlement'",
+                  "description": "Disclosed trade-off / opportunity cost of NOT taking another path (K3 Game G3 opportunity cost). Example: 'Choosing cancelled forfeits this order's settlement'",
                   "type": "string"
                 }
               },
@@ -10787,7 +10791,7 @@
                   "operator"
                 ],
                 "additionalProperties": false,
-                "description": "A forward still pending — who must act next (threshold cooperation, K3 Game G4 阈值配合)."
+                "description": "A forward still pending — who must act next (threshold cooperation, K3 Game G4)."
               }
             },
             "next_guidance": {
@@ -10865,14 +10869,14 @@
                         "description": "Business meaning of advancing to this node. Example: 'Guide starts the day service'"
                       },
                       "gains": {
-                        "description": "Gains for the caller if this option is chosen (K3 Game G1 收益分离). Example: ['Settlement triggered — funds released to provider']",
+                        "description": "Gains for the caller if this option is chosen (K3 Game G1 gain separation). Example: ['Settlement triggered — funds released to provider']",
                         "type": "array",
                         "items": {
                           "type": "string"
                         }
                       },
                       "risks": {
-                        "description": "Risks for the caller if this option is chosen (K3 Game G1 风险分离). Example: ['Refund leverage lost after confirmation']",
+                        "description": "Risks for the caller if this option is chosen (K3 Game G1 risk separation). Example: ['Refund leverage lost after confirmation']",
                         "type": "array",
                         "items": {
                           "type": "string"
@@ -10902,7 +10906,7 @@
                   "description": "ALL reachable next-node directions (every operator/permission/guard disclosed)."
                 },
                 "recommendation": {
-                  "description": "Recommended option with rationale (K3 Game 意图/博弈/利益).",
+                  "description": "Recommended option with rationale (K3 Game intent/game/interests).",
                   "type": "object",
                   "properties": {
                     "best": {
@@ -10914,7 +10918,7 @@
                       "type": "string"
                     },
                     "caveat": {
-                      "description": "Disclosed trade-off / opportunity cost of NOT taking another path (K3 Game G3 机会成本). Example: 'Choosing cancelled forfeits this order's settlement'",
+                      "description": "Disclosed trade-off / opportunity cost of NOT taking another path (K3 Game G3 opportunity cost). Example: 'Choosing cancelled forfeits this order's settlement'",
                       "type": "string"
                     }
                   },