@wowok/agent-mcp 3.1.3 → 3.1.4

package/dist/schemas/onchain_operations_machine.schema.json

@@ -218,12 +218,14 @@
                       }
                     },
                     "check_all_founded": {
-                      "description": "Whether to check all entities are found, if true, all entities must be found (abort and throw exception if any ID not found); if false, only return found IDs",
+                      "default": true,
+                      "description": "Whether to check all entities are found. Defaults to true: abort and throw if ANY entity cannot be resolved. Set false only when partial resolution is explicitly intended (only found IDs are returned)",
                       "type": "boolean"
                     }
                   },
                   "required": [
-                    "entities"
+                    "entities",
+                    "check_all_founded"
                   ],
                   "additionalProperties": false,
                   "description": "Used to batch find account or object IDs by name"
@@ -371,7 +373,7 @@
                                 },
                                 "threshold": {
                                   "default": 0,
-                                  "description": "Threshold to trigger node advancement. If total Forward weight is greater than or equal to threshold, node advancement is triggered. ⚠️ SINGLE-OPERATOR LOCK: each forward contributes its weight AT MOST ONCE (locked by its first operator — progress.move session_accomplish_imp; re-execution by others aborts E_NOT_THE_HOLDER). The maximum achievable weight of this Pair is the sum of its DISTINCT forward weights — if that sum < threshold the transition can NEVER migrate. Multi-operator cooperation (threshold > 1) needs one DISTINCT forward per contributing operator (e.g. threshold 2 → begin_a + begin_b, each weight 1), never one forward reused by several people.",
+                                  "description": "Threshold to trigger node advancement. If total Forward weight is greater than or equal to threshold, node advancement is triggered. ⚠️ SINGLE-OPERATOR LOCK: each forward contributes its weight AT MOST ONCE (locked by its first operator; re-execution by others aborts E_NOT_THE_HOLDER). The maximum achievable weight of this Pair is the sum of its DISTINCT forward weights — if that sum < threshold the transition can NEVER migrate. Multi-operator cooperation (threshold > 1) needs one DISTINCT forward per contributing operator (e.g. threshold 2 → begin_a + begin_b, each weight 1), never one forward reused by several people.",
                                   "anyOf": [
                                     {
                                       "type": "number"
@@ -402,7 +404,7 @@
                                         ]
                                       },
                                       "permissionIndex": {
-                                        "description": "Forward operation permission 2: Permission index (one of the two must be specified); recommended if all Progress object operators are the same (e.g., same reward reviewers for all orders).",
+                                        "description": "Forward operation permission 2: Permission index (one of the two must be specified); recommended if all Progress object operators are the same (e.g., same reward reviewers for all orders). RANGE: use a USER_DEFINED index ≥1000 (0–999 are builtin/reserved) — a USER_DEFINED index works for the Permission's admin immediately without any grant; a builtin index (<1000) aborts with MoveAbort 7 unless it was explicitly granted to the operators first.",
                                         "anyOf": [
                                           {
                                             "type": "number"
@@ -424,7 +426,7 @@
                                             "type": "string"
                                           }
                                         ],
-                                        "description": "Forward weight — the contribution this forward makes toward its Pair's threshold. ⚠️ SINGLE-OPERATOR LOCK: a forward contributes its weight AT MOST ONCE. It is locked by the first operator that accomplishes it (progress.move session_accomplish_imp); a second operator re-executing the same accomplished forward aborts E_NOT_THE_HOLDER. Therefore multi-operator cooperation (threshold > 1) needs one DISTINCT forward per contributing operator (e.g. threshold 2 → begin_a + begin_b, each weight 1) — never reuse one forward."
+                                        "description": "Forward weight — the contribution this forward makes toward its Pair's threshold. ⚠️ SINGLE-OPERATOR LOCK: a forward contributes its weight AT MOST ONCE. It is locked by the first operator that accomplishes it; a second operator re-executing the same accomplished forward aborts E_NOT_THE_HOLDER. Therefore multi-operator cooperation (threshold > 1) needs one DISTINCT forward per contributing operator (e.g. threshold 2 → begin_a + begin_b, each weight 1) — never reuse one forward."
                                       },
                                       "guard": {
                                         "description": "Guard reference for this forward. Accepts TWO formats:\n• STRING (preferred): \"my_guard_name\" — the Guard's name or address as a plain string.\n• OBJECT (only when retained_submission is needed): {guard: \"my_guard_name\", retained_submission: [1,2,3]}.\nFOLLOW THE SCHEMA FIELD STRUCTURE: A Guard reference is fundamentally a STRING (the Guard object's name or address). Provide a string when you only need to reference a Guard — do NOT wrap a bare string in an object structure. The OBJECT form {guard: \"...\", retained_submission: [...]} exists ONLY to carry additional `retained_submission` data alongside the string reference; inside the object, the `guard` field is STILL a string. In short: string-in for a string reference, object-in only when you need to pass extra data.\nCOGNITIVE PRINCIPLE: Guard validation ALWAYS occurs BEFORE the forward operation. A Guard that queries state of the SAME Progress object this forward operates on (e.g. progress.current) will see the PRE-transition value (source node), NOT the target node. If the Guard checks progress.current == target_node, it will ALWAYS FAIL. Querying a DIFFERENT Progress object (cross-machine) is safe and reasonable — that progress is not modified by this forward. For target-node verification after transition, bind the Guard to the Allocator instead (allocation.alloc runs AFTER the state transition completes).\n⚠️ T1 LOSSY POINT (B-3): WoWok has NO on-chain cron. A business phrase like 'after N days, auto-X' is NOT an automatic trigger — it decomposes into (1) a time_guard that checks elapsed time, and (2) an OFF-CHAIN keeper that must submit the forward when the guard passes. Configuring a time_guard WITHOUT a keeper means nothing ever fires.\nRETAINED_SUBMISSION: a non-empty retained_submission does NOT relax Guard verification — the forward's Guard is always validated first. The list only selects which of the caller's already-verified submissions are persisted into the Progress history (see the guard field above).",
@@ -439,7 +441,7 @@
                                                     "description": "Guard object name or address (string). Example: 'my_attendance_guard' or '0x1234...'"
                                                   },
                                                   "retained_submission": {
-                                                    "description": "Guard table identifiers whose verified values are persisted into the Progress history when the forward is accomplished. The Guard is ALWAYS fully verified first (regardless of this list): the forward cannot complete unless the Passport carries a passing result for it. After verification, exactly the caller's submissions for the listed identifiers are copied into history (passport::submissions_get) as Guard-verified facts; empty array (default) records nothing. Use it for audit and downstream queries, never as a way to relax Guard conditions.",
+                                                    "description": "Guard table identifiers whose verified values are persisted into the Progress history when the forward is accomplished. The Guard is ALWAYS fully verified first (regardless of this list): the forward cannot complete unless the Passport carries a passing result for it. After verification, exactly the caller's submissions for the listed identifiers are copied into history (from the passport's submission records) as Guard-verified facts; empty array (default) records nothing. Use it for audit and downstream queries, never as a way to relax Guard conditions.",
                                                     "anyOf": [
                                                       {
                                                         "type": "array",
@@ -547,7 +549,7 @@
                                 },
                                 "threshold": {
                                   "default": 0,
-                                  "description": "Threshold to trigger node advancement. If total Forward weight is greater than or equal to threshold, node advancement is triggered. ⚠️ SINGLE-OPERATOR LOCK: each forward contributes its weight AT MOST ONCE (locked by its first operator — progress.move session_accomplish_imp; re-execution by others aborts E_NOT_THE_HOLDER). The maximum achievable weight of this Pair is the sum of its DISTINCT forward weights — if that sum < threshold the transition can NEVER migrate. Multi-operator cooperation (threshold > 1) needs one DISTINCT forward per contributing operator (e.g. threshold 2 → begin_a + begin_b, each weight 1), never one forward reused by several people.",
+                                  "description": "Threshold to trigger node advancement. If total Forward weight is greater than or equal to threshold, node advancement is triggered. ⚠️ SINGLE-OPERATOR LOCK: each forward contributes its weight AT MOST ONCE (locked by its first operator; re-execution by others aborts E_NOT_THE_HOLDER). The maximum achievable weight of this Pair is the sum of its DISTINCT forward weights — if that sum < threshold the transition can NEVER migrate. Multi-operator cooperation (threshold > 1) needs one DISTINCT forward per contributing operator (e.g. threshold 2 → begin_a + begin_b, each weight 1), never one forward reused by several people.",
                                   "anyOf": [
                                     {
                                       "type": "number"
@@ -578,7 +580,7 @@
                                         ]
                                       },
                                       "permissionIndex": {
-                                        "description": "Forward operation permission 2: Permission index (one of the two must be specified); recommended if all Progress object operators are the same (e.g., same reward reviewers for all orders).",
+                                        "description": "Forward operation permission 2: Permission index (one of the two must be specified); recommended if all Progress object operators are the same (e.g., same reward reviewers for all orders). RANGE: use a USER_DEFINED index ≥1000 (0–999 are builtin/reserved) — a USER_DEFINED index works for the Permission's admin immediately without any grant; a builtin index (<1000) aborts with MoveAbort 7 unless it was explicitly granted to the operators first.",
                                         "anyOf": [
                                           {
                                             "type": "number"
@@ -600,7 +602,7 @@
                                             "type": "string"
                                           }
                                         ],
-                                        "description": "Forward weight — the contribution this forward makes toward its Pair's threshold. ⚠️ SINGLE-OPERATOR LOCK: a forward contributes its weight AT MOST ONCE. It is locked by the first operator that accomplishes it (progress.move session_accomplish_imp); a second operator re-executing the same accomplished forward aborts E_NOT_THE_HOLDER. Therefore multi-operator cooperation (threshold > 1) needs one DISTINCT forward per contributing operator (e.g. threshold 2 → begin_a + begin_b, each weight 1) — never reuse one forward."
+                                        "description": "Forward weight — the contribution this forward makes toward its Pair's threshold. ⚠️ SINGLE-OPERATOR LOCK: a forward contributes its weight AT MOST ONCE. It is locked by the first operator that accomplishes it; a second operator re-executing the same accomplished forward aborts E_NOT_THE_HOLDER. Therefore multi-operator cooperation (threshold > 1) needs one DISTINCT forward per contributing operator (e.g. threshold 2 → begin_a + begin_b, each weight 1) — never reuse one forward."
                                       },
                                       "guard": {
                                         "description": "Guard reference for this forward. Accepts TWO formats:\n• STRING (preferred): \"my_guard_name\" — the Guard's name or address as a plain string.\n• OBJECT (only when retained_submission is needed): {guard: \"my_guard_name\", retained_submission: [1,2,3]}.\nFOLLOW THE SCHEMA FIELD STRUCTURE: A Guard reference is fundamentally a STRING (the Guard object's name or address). Provide a string when you only need to reference a Guard — do NOT wrap a bare string in an object structure. The OBJECT form {guard: \"...\", retained_submission: [...]} exists ONLY to carry additional `retained_submission` data alongside the string reference; inside the object, the `guard` field is STILL a string. In short: string-in for a string reference, object-in only when you need to pass extra data.\nCOGNITIVE PRINCIPLE: Guard validation ALWAYS occurs BEFORE the forward operation. A Guard that queries state of the SAME Progress object this forward operates on (e.g. progress.current) will see the PRE-transition value (source node), NOT the target node. If the Guard checks progress.current == target_node, it will ALWAYS FAIL. Querying a DIFFERENT Progress object (cross-machine) is safe and reasonable — that progress is not modified by this forward. For target-node verification after transition, bind the Guard to the Allocator instead (allocation.alloc runs AFTER the state transition completes).\n⚠️ T1 LOSSY POINT (B-3): WoWok has NO on-chain cron. A business phrase like 'after N days, auto-X' is NOT an automatic trigger — it decomposes into (1) a time_guard that checks elapsed time, and (2) an OFF-CHAIN keeper that must submit the forward when the guard passes. Configuring a time_guard WITHOUT a keeper means nothing ever fires.\nRETAINED_SUBMISSION: a non-empty retained_submission does NOT relax Guard verification — the forward's Guard is always validated first. The list only selects which of the caller's already-verified submissions are persisted into the Progress history (see the guard field above).",
@@ -615,7 +617,7 @@
                                                     "description": "Guard object name or address (string). Example: 'my_attendance_guard' or '0x1234...'"
                                                   },
                                                   "retained_submission": {
-                                                    "description": "Guard table identifiers whose verified values are persisted into the Progress history when the forward is accomplished. The Guard is ALWAYS fully verified first (regardless of this list): the forward cannot complete unless the Passport carries a passing result for it. After verification, exactly the caller's submissions for the listed identifiers are copied into history (passport::submissions_get) as Guard-verified facts; empty array (default) records nothing. Use it for audit and downstream queries, never as a way to relax Guard conditions.",
+                                                    "description": "Guard table identifiers whose verified values are persisted into the Progress history when the forward is accomplished. The Guard is ALWAYS fully verified first (regardless of this list): the forward cannot complete unless the Passport carries a passing result for it. After verification, exactly the caller's submissions for the listed identifiers are copied into history (from the passport's submission records) as Guard-verified facts; empty array (default) records nothing. Use it for audit and downstream queries, never as a way to relax Guard conditions.",
                                                     "anyOf": [
                                                       {
                                                         "type": "array",
@@ -861,7 +863,7 @@
                                   ]
                                 },
                                 "permissionIndex": {
-                                  "description": "Forward operation permission 2: Permission index (one of the two must be specified); recommended if all Progress object operators are the same (e.g., same reward reviewers for all orders).",
+                                  "description": "Forward operation permission 2: Permission index (one of the two must be specified); recommended if all Progress object operators are the same (e.g., same reward reviewers for all orders). RANGE: use a USER_DEFINED index ≥1000 (0–999 are builtin/reserved) — a USER_DEFINED index works for the Permission's admin immediately without any grant; a builtin index (<1000) aborts with MoveAbort 7 unless it was explicitly granted to the operators first.",
                                   "anyOf": [
                                     {
                                       "type": "number"
@@ -883,7 +885,7 @@
                                       "type": "string"
                                     }
                                   ],
-                                  "description": "Forward weight — the contribution this forward makes toward its Pair's threshold. ⚠️ SINGLE-OPERATOR LOCK: a forward contributes its weight AT MOST ONCE. It is locked by the first operator that accomplishes it (progress.move session_accomplish_imp); a second operator re-executing the same accomplished forward aborts E_NOT_THE_HOLDER. Therefore multi-operator cooperation (threshold > 1) needs one DISTINCT forward per contributing operator (e.g. threshold 2 → begin_a + begin_b, each weight 1) — never reuse one forward."
+                                  "description": "Forward weight — the contribution this forward makes toward its Pair's threshold. ⚠️ SINGLE-OPERATOR LOCK: a forward contributes its weight AT MOST ONCE. It is locked by the first operator that accomplishes it; a second operator re-executing the same accomplished forward aborts E_NOT_THE_HOLDER. Therefore multi-operator cooperation (threshold > 1) needs one DISTINCT forward per contributing operator (e.g. threshold 2 → begin_a + begin_b, each weight 1) — never reuse one forward."
                                 },
                                 "guard": {
                                   "description": "Guard reference for this forward. Accepts TWO formats:\n• STRING (preferred): \"my_guard_name\" — the Guard's name or address as a plain string.\n• OBJECT (only when retained_submission is needed): {guard: \"my_guard_name\", retained_submission: [1,2,3]}.\nFOLLOW THE SCHEMA FIELD STRUCTURE: A Guard reference is fundamentally a STRING (the Guard object's name or address). Provide a string when you only need to reference a Guard — do NOT wrap a bare string in an object structure. The OBJECT form {guard: \"...\", retained_submission: [...]} exists ONLY to carry additional `retained_submission` data alongside the string reference; inside the object, the `guard` field is STILL a string. In short: string-in for a string reference, object-in only when you need to pass extra data.\nCOGNITIVE PRINCIPLE: Guard validation ALWAYS occurs BEFORE the forward operation. A Guard that queries state of the SAME Progress object this forward operates on (e.g. progress.current) will see the PRE-transition value (source node), NOT the target node. If the Guard checks progress.current == target_node, it will ALWAYS FAIL. Querying a DIFFERENT Progress object (cross-machine) is safe and reasonable — that progress is not modified by this forward. For target-node verification after transition, bind the Guard to the Allocator instead (allocation.alloc runs AFTER the state transition completes).\n⚠️ T1 LOSSY POINT (B-3): WoWok has NO on-chain cron. A business phrase like 'after N days, auto-X' is NOT an automatic trigger — it decomposes into (1) a time_guard that checks elapsed time, and (2) an OFF-CHAIN keeper that must submit the forward when the guard passes. Configuring a time_guard WITHOUT a keeper means nothing ever fires.\nRETAINED_SUBMISSION: a non-empty retained_submission does NOT relax Guard verification — the forward's Guard is always validated first. The list only selects which of the caller's already-verified submissions are persisted into the Progress history (see the guard field above).",
@@ -898,7 +900,7 @@
                                               "description": "Guard object name or address (string). Example: 'my_attendance_guard' or '0x1234...'"
                                             },
                                             "retained_submission": {
-                                              "description": "Guard table identifiers whose verified values are persisted into the Progress history when the forward is accomplished. The Guard is ALWAYS fully verified first (regardless of this list): the forward cannot complete unless the Passport carries a passing result for it. After verification, exactly the caller's submissions for the listed identifiers are copied into history (passport::submissions_get) as Guard-verified facts; empty array (default) records nothing. Use it for audit and downstream queries, never as a way to relax Guard conditions.",
+                                              "description": "Guard table identifiers whose verified values are persisted into the Progress history when the forward is accomplished. The Guard is ALWAYS fully verified first (regardless of this list): the forward cannot complete unless the Passport carries a passing result for it. After verification, exactly the caller's submissions for the listed identifiers are copied into history (from the passport's submission records) as Guard-verified facts; empty array (default) records nothing. Use it for audit and downstream queries, never as a way to relax Guard conditions.",
                                               "anyOf": [
                                                 {
                                                   "type": "array",
@@ -1097,7 +1099,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. 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."
+                  "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 prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."
                 },
                 "token_type": {
                   "type": "string",
@@ -1121,7 +1123,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. 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."
+                        "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 prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."
                       },
                       "payment": {
                         "type": "string",
@@ -1217,7 +1219,7 @@
           "type": "string"
         },
         "no_auto_register": {
-          "description": "Opt-out of SDK-level Entity auto-registration. By default, a business transaction whose sender has no entry in the global Entity table automatically appends entity_register: the sender gets registered and receives an owned Resource object (their on-chain mark book) in the wallet. Set true ONLY when the user explicitly cancelled their entity registration (entity_cancel) or demands that the transaction not touch the Entity table.",
+          "description": "Opt-out of SDK-level Entity auto-registration. By default, a business transaction whose sender has no entry in the global Entity table automatically appends an entity registration: the sender gets registered and receives an owned Resource object (their on-chain mark book) in the wallet. Set true ONLY when the user explicitly cancelled their entity registration or demands that the transaction not touch the Entity table.",
           "type": "boolean"
         },
         "confirmed": {
@@ -1674,12 +1676,14 @@
                                   }
                                 },
                                 "check_all_founded": {
-                                  "description": "Whether to check all entities are found, if true, all entities must be found (abort and throw exception if any ID not found); if false, only return found IDs",
+                                  "default": true,
+                                  "description": "Whether to check all entities are found. Defaults to true: abort and throw if ANY entity cannot be resolved. Set false only when partial resolution is explicitly intended (only found IDs are returned)",
                                   "type": "boolean"
                                 }
                               },
                               "required": [
-                                "entities"
+                                "entities",
+                                "check_all_founded"
                               ],
                               "additionalProperties": false,
                               "description": "Used to batch find account or object IDs by name"

package/dist/schemas/onchain_operations_order.schema.json

@@ -39,12 +39,14 @@
               }
             },
             "check_all_founded": {
-              "description": "Whether to check all entities are found, if true, all entities must be found (abort and throw exception if any ID not found); if false, only return found IDs",
+              "default": true,
+              "description": "Whether to check all entities are found. Defaults to true: abort and throw if ANY entity cannot be resolved. Set false only when partial resolution is explicitly intended (only found IDs are returned)",
               "type": "boolean"
             }
           },
           "required": [
-            "entities"
+            "entities",
+            "check_all_founded"
           ],
           "additionalProperties": false
         },
@@ -218,7 +220,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. 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."
+                  "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 prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."
                 },
                 "token_type": {
                   "type": "string",
@@ -242,7 +244,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. 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."
+                        "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 prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."
                       },
                       "payment": {
                         "type": "string",
@@ -341,7 +343,7 @@
           "type": "string"
         },
         "no_auto_register": {
-          "description": "Opt-out of SDK-level Entity auto-registration. By default, a business transaction whose sender has no entry in the global Entity table automatically appends entity_register: the sender gets registered and receives an owned Resource object (their on-chain mark book) in the wallet. Set true ONLY when the user explicitly cancelled their entity registration (entity_cancel) or demands that the transaction not touch the Entity table.",
+          "description": "Opt-out of SDK-level Entity auto-registration. By default, a business transaction whose sender has no entry in the global Entity table automatically appends an entity registration: the sender gets registered and receives an owned Resource object (their on-chain mark book) in the wallet. Set true ONLY when the user explicitly cancelled their entity registration or demands that the transaction not touch the Entity table.",
           "type": "boolean"
         },
         "confirmed": {
@@ -798,12 +800,14 @@
                                   }
                                 },
                                 "check_all_founded": {
-                                  "description": "Whether to check all entities are found, if true, all entities must be found (abort and throw exception if any ID not found); if false, only return found IDs",
+                                  "default": true,
+                                  "description": "Whether to check all entities are found. Defaults to true: abort and throw if ANY entity cannot be resolved. Set false only when partial resolution is explicitly intended (only found IDs are returned)",
                                   "type": "boolean"
                                 }
                               },
                               "required": [
-                                "entities"
+                                "entities",
+                                "check_all_founded"
                               ],
                               "additionalProperties": false,
                               "description": "Used to batch find account or object IDs by name"

package/dist/schemas/onchain_operations_payment.schema.json

@@ -82,7 +82,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. 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."
+                            "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 prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."
                           }
                         },
                         "required": [
@@ -184,7 +184,7 @@
             "receive": {
               "type": "boolean",
               "const": true,
-              "description": "Set to true to activate receive mode. CoinWrapper objects ARE transferred to recipients via transfer::public_transfer (they arrive as owned objects), but they are NOT spendable coins. This mode unwraps a CoinWrapper into actual coins in your wallet via payment::unwrap_to_myself. The caller must be the CoinWrapper's owner (the recipient specified in the Allocation's revenue split). When 'object' is omitted, every CoinWrapper owned by the caller is unwrapped at once."
+              "description": "Set to true to activate receive mode. CoinWrapper objects ARE transferred to recipients via transfer::public_transfer (they arrive as owned objects), but they are NOT spendable coins. This mode unwraps a CoinWrapper into actual coins in your wallet. The caller must be the CoinWrapper's owner (the recipient specified in the Allocation's revenue split). When 'object' is omitted, every CoinWrapper owned by the caller is unwrapped at once."
             },
             "type_parameter": {
               "description": "Coin type of the CoinWrapper, e.g. '0x2::wow::WOW'. OPTIONAL: when omitted it is auto-derived from the CoinWrapper's own on-chain type (the inner T of `CoinWrapper<T>`), so {object, receive:true} alone unwraps to spendable coins. Only provide it explicitly when auto-derivation fails. In AUTO-RECEIVE mode (no object) the type is always derived per-wrapper.",
@@ -233,7 +233,7 @@
           "type": "string"
         },
         "no_auto_register": {
-          "description": "Opt-out of SDK-level Entity auto-registration. By default, a business transaction whose sender has no entry in the global Entity table automatically appends entity_register: the sender gets registered and receives an owned Resource object (their on-chain mark book) in the wallet. Set true ONLY when the user explicitly cancelled their entity registration (entity_cancel) or demands that the transaction not touch the Entity table.",
+          "description": "Opt-out of SDK-level Entity auto-registration. By default, a business transaction whose sender has no entry in the global Entity table automatically appends an entity registration: the sender gets registered and receives an owned Resource object (their on-chain mark book) in the wallet. Set true ONLY when the user explicitly cancelled their entity registration or demands that the transaction not touch the Entity table.",
           "type": "boolean"
         },
         "confirmed": {

package/dist/schemas/onchain_operations_permission.schema.json

@@ -155,12 +155,14 @@
                       }
                     },
                     "check_all_founded": {
-                      "description": "Whether to check all entities are found, if true, all entities must be found (abort and throw exception if any ID not found); if false, only return found IDs",
+                      "default": true,
+                      "description": "Whether to check all entities are found. Defaults to true: abort and throw if ANY entity cannot be resolved. Set false only when partial resolution is explicitly intended (only found IDs are returned)",
                       "type": "boolean"
                     }
                   },
                   "required": [
-                    "entities"
+                    "entities",
+                    "check_all_founded"
                   ],
                   "additionalProperties": false,
                   "description": "Used to batch find account or object IDs by name"
@@ -209,12 +211,14 @@
                       }
                     },
                     "check_all_founded": {
-                      "description": "Whether to check all entities are found, if true, all entities must be found (abort and throw exception if any ID not found); if false, only return found IDs",
+                      "default": true,
+                      "description": "Whether to check all entities are found. Defaults to true: abort and throw if ANY entity cannot be resolved. Set false only when partial resolution is explicitly intended (only found IDs are returned)",
                       "type": "boolean"
                     }
                   },
                   "required": [
-                    "entities"
+                    "entities",
+                    "check_all_founded"
                   ],
                   "additionalProperties": false,
                   "description": "Used to batch find account or object IDs by name"
@@ -263,12 +267,14 @@
                       }
                     },
                     "check_all_founded": {
-                      "description": "Whether to check all entities are found, if true, all entities must be found (abort and throw exception if any ID not found); if false, only return found IDs",
+                      "default": true,
+                      "description": "Whether to check all entities are found. Defaults to true: abort and throw if ANY entity cannot be resolved. Set false only when partial resolution is explicitly intended (only found IDs are returned)",
                       "type": "boolean"
                     }
                   },
                   "required": [
-                    "entities"
+                    "entities",
+                    "check_all_founded"
                   ],
                   "additionalProperties": false,
                   "description": "Used to batch find account or object IDs by name"
@@ -612,12 +618,14 @@
                   }
                 },
                 "check_all_founded": {
-                  "description": "Whether to check all entities are found, if true, all entities must be found (abort and throw exception if any ID not found); if false, only return found IDs",
+                  "default": true,
+                  "description": "Whether to check all entities are found. Defaults to true: abort and throw if ANY entity cannot be resolved. Set false only when partial resolution is explicitly intended (only found IDs are returned)",
                   "type": "boolean"
                 }
               },
               "required": [
-                "entities"
+                "entities",
+                "check_all_founded"
               ],
               "additionalProperties": false,
               "description": "List of admin addresses."
@@ -702,7 +710,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. 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."
+                  "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 prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."
                 },
                 "token_type": {
                   "type": "string",
@@ -726,7 +734,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. 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."
+                        "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 prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."
                       },
                       "payment": {
                         "type": "string",
@@ -819,7 +827,7 @@
           "type": "string"
         },
         "no_auto_register": {
-          "description": "Opt-out of SDK-level Entity auto-registration. By default, a business transaction whose sender has no entry in the global Entity table automatically appends entity_register: the sender gets registered and receives an owned Resource object (their on-chain mark book) in the wallet. Set true ONLY when the user explicitly cancelled their entity registration (entity_cancel) or demands that the transaction not touch the Entity table.",
+          "description": "Opt-out of SDK-level Entity auto-registration. By default, a business transaction whose sender has no entry in the global Entity table automatically appends an entity registration: the sender gets registered and receives an owned Resource object (their on-chain mark book) in the wallet. Set true ONLY when the user explicitly cancelled their entity registration or demands that the transaction not touch the Entity table.",
           "type": "boolean"
         },
         "confirmed": {

package/dist/schemas/onchain_operations_personal.schema.json

@@ -435,12 +435,14 @@
                                         }
                                       },
                                       "check_all_founded": {
-                                        "description": "Whether to check all entities are found, if true, all entities must be found (abort and throw exception if any ID not found); if false, only return found IDs",
+                                        "default": true,
+                                        "description": "Whether to check all entities are found. Defaults to true: abort and throw if ANY entity cannot be resolved. Set false only when partial resolution is explicitly intended (only found IDs are returned)",
                                         "type": "boolean"
                                       }
                                     },
                                     "required": [
-                                      "entities"
+                                      "entities",
+                                      "check_all_founded"
                                     ],
                                     "additionalProperties": false,
                                     "description": "Used to batch find account or object IDs by name"
@@ -690,12 +692,14 @@
                           }
                         },
                         "check_all_founded": {
-                          "description": "Whether to check all entities are found, if true, all entities must be found (abort and throw exception if any ID not found); if false, only return found IDs",
+                          "default": true,
+                          "description": "Whether to check all entities are found. Defaults to true: abort and throw if ANY entity cannot be resolved. Set false only when partial resolution is explicitly intended (only found IDs are returned)",
                           "type": "boolean"
                         }
                       },
                       "required": [
-                        "entities"
+                        "entities",
+                        "check_all_founded"
                       ],
                       "additionalProperties": false,
                       "description": "Used to batch find account or object IDs by name"
@@ -747,7 +751,7 @@
                 "address"
               ],
               "additionalProperties": false,
-              "description": "PUBLIC REPUTATION VOTE: Like an address (0x...) or LocalMark name. Goes through registrar::like — toggles off if already liked, auto-flips an existing dislike, and increments the target's PUBLIC aggregate like count (queryable via query personal / Guard entity_voted_record). Do NOT emulate with mark.add tags:['like'] — manual tags stay private in your Resource and never affect the aggregate count."
+              "description": "PUBLIC REPUTATION VOTE: Like an address (0x...) or LocalMark name. An on-chain reputation vote — toggles off if already liked, auto-flips an existing dislike, and increments the target's PUBLIC aggregate like count (queryable via query personal / Guard entity_voted_record). Do NOT emulate with mark.add tags:['like'] — manual tags stay private in your Resource and never affect the aggregate count."
             },
             {
               "type": "object",
@@ -785,7 +789,7 @@
                 "address"
               ],
               "additionalProperties": false,
-              "description": "PUBLIC REPUTATION VOTE: Dislike an address (0x...) or LocalMark name. Goes through registrar::dislike — toggles off if already disliked, auto-flips an existing like, and increments the target's PUBLIC aggregate dislike count. Same manual-tag caveat as 'like'."
+              "description": "PUBLIC REPUTATION VOTE: Dislike an address (0x...) or LocalMark name. An on-chain reputation vote — toggles off if already disliked, auto-flips an existing like, and increments the target's PUBLIC aggregate dislike count. Same manual-tag caveat as 'like'."
             },
             {
               "type": "object",
@@ -823,7 +827,7 @@
                 "address"
               ],
               "additionalProperties": false,
-              "description": "PUBLIC REPUTATION VOTE: Favor (bookmark/star) an address (0x...) or LocalMark name. Goes through registrar::favor — toggles off if already favored, and increments the target's PUBLIC aggregate favor count (independent of like/dislike; queryable via query personal). Use for 'save this service/provider' style endorsements."
+              "description": "PUBLIC REPUTATION VOTE: Favor (bookmark/star) an address (0x...) or LocalMark name. An on-chain reputation vote — toggles off if already favored, and increments the target's PUBLIC aggregate favor count (independent of like/dislike; queryable via query personal). Use for 'save this service/provider' style endorsements."
             },
             {
               "type": "object",
@@ -934,7 +938,7 @@
           "type": "string"
         },
         "no_auto_register": {
-          "description": "Opt-out of SDK-level Entity auto-registration. By default, a business transaction whose sender has no entry in the global Entity table automatically appends entity_register: the sender gets registered and receives an owned Resource object (their on-chain mark book) in the wallet. Set true ONLY when the user explicitly cancelled their entity registration (entity_cancel) or demands that the transaction not touch the Entity table.",
+          "description": "Opt-out of SDK-level Entity auto-registration. By default, a business transaction whose sender has no entry in the global Entity table automatically appends an entity registration: the sender gets registered and receives an owned Resource object (their on-chain mark book) in the wallet. Set true ONLY when the user explicitly cancelled their entity registration or demands that the transaction not touch the Entity table.",
           "type": "boolean"
         },
         "confirmed": {
@@ -1366,12 +1370,14 @@
                           }
                         },
                         "check_all_founded": {
-                          "description": "Whether to check all entities are found, if true, all entities must be found (abort and throw exception if any ID not found); if false, only return found IDs",
+                          "default": true,
+                          "description": "Whether to check all entities are found. Defaults to true: abort and throw if ANY entity cannot be resolved. Set false only when partial resolution is explicitly intended (only found IDs are returned)",
                           "type": "boolean"
                         }
                       },
                       "required": [
-                        "entities"
+                        "entities",
+                        "check_all_founded"
                       ],
                       "additionalProperties": false,
                       "description": "Used to batch find account or object IDs by name"