@wowok/agent-mcp 3.1.3 → 3.1.5

package/dist/schemas/onchain_operations_allocation.schema.json

@@ -139,7 +139,7 @@
                                   "description": "Current transaction signer (tx_context::sender) at the time of the alloc() call. For refunds, the Order owner must call alloc_by_guard themselves to receive the funds."
                                 }
                               ],
-                              "description": "Recipient of this allocation. Three forms — each resolves the address at a DIFFERENT time:\n• { GuardIdentifier: u8 } — DYNAMIC address resolved from Passport at alloc() time (contract calls passport::submission_get). Use 0 for Order owner in Service-integrated mode (Customer who created the Order). The identifier must match a Guard table entry with b_submission=true. If Passport has no matching submission, contract aborts with E_VERIFY_FAILED. Use when the recipient address is not known at config time and must be supplied via Guard submission data.\n• { Entity: { name_or_address: '...' } } — FIXED address resolved via LocalMark at SDK build time (passed to contract as a literal address). Use for known recipients (e.g., 'turo_host', or a Treasury object address). Use when the recipient is a stable, known address (e.g., operator receives rent, platform fee to treasury).\n• 'Signer' — the transaction sender at the time of the alloc() call (tx_context::sender). RESOLVED AT EXECUTION TIME, not at config time. For refunds: the customer (Order owner) must call alloc_by_guard THEMSELVES so that tx_context::sender resolves to THEIR address — if the operator calls alloc_by_guard, the operator becomes the recipient (Signer = operator), NOT the customer. Use when the recipient is whoever submits the allocation transaction (e.g., customer receives refund)."
+                              "description": "Recipient of this allocation. Three forms — each resolves the address at a DIFFERENT time:\n• { GuardIdentifier: u8 } — DYNAMIC address resolved from Passport at alloc() time (from the passport's submission record). Use 0 for Order owner in Service-integrated mode (Customer who created the Order). The identifier must match a Guard table entry with b_submission=true. If Passport has no matching submission, contract aborts with E_VERIFY_FAILED. Use when the recipient address is not known at config time and must be supplied via Guard submission data.\n• { Entity: { name_or_address: '...' } } — FIXED address resolved via LocalMark at SDK build time (passed to contract as a literal address). Use for known recipients (e.g., 'turo_host', or a Treasury object address). Use when the recipient is a stable, known address (e.g., operator receives rent, platform fee to treasury).\n• 'Signer' — the transaction sender at the time of the alloc() call (tx_context::sender). RESOLVED AT EXECUTION TIME, not at config time. For refunds: the customer (Order owner) must call alloc_by_guard THEMSELVES so that tx_context::sender resolves to THEIR address — if the operator calls alloc_by_guard, the operator becomes the recipient (Signer = operator), NOT the customer. Use when the recipient is whoever submits the allocation transaction (e.g., customer receives refund)."
                             },
                             "sharing": {
                               "anyOf": [
@@ -178,7 +178,7 @@
                         "description": "Fund allocation item list. Each item specifies a recipient (who), a value (sharing), and a mode. Items can mix modes (Amount + Rate + Surplus) within the same Allocator. RECIPIENT SEMANTICS: the Guard constrains what each submission slot may be; a recipient's safety follows from the sufficiency of those constraints (run the recipient constraint audit). Canonical order pattern: recipient = the single submitted Order — funds land at that object and are receivable only by its owner. ALLOCATION ORDER: Amount items first (cached as fix) → Rate items (proportional to balance - fix) → Surplus item (remaining). CONSTRAINTS: max ONE Surplus item per Allocator; Rate sum must == 10000 (no Surplus) or <= 10000 (with Surplus); Amount sum must >= threshold (no Rate and no Surplus) and <= max (if max set)."
                       },
                       "fix": {
-                        "description": "OUTPUT-ONLY (query result). Cached sum of all Amount-mode `sharing` values in this Allocator. Computed by the contract during `allocator_add` — DO NOT set this field at creation. Used internally to compute `total_rates = balance - fix` for Rate allocation.",
+                        "description": "OUTPUT-ONLY (query result). Cached sum of all Amount-mode `sharing` values in this Allocator. Computed by the contract when the allocator is added — DO NOT set this field at creation. Used internally to compute `total_rates = balance - fix` for Rate allocation.",
                         "anyOf": [
                           {
                             "type": "number"
@@ -189,7 +189,7 @@
                         ]
                       },
                       "max": {
-                        "description": "Maximum allocation cap (OPTIONAL — omit the field or set to null to disable the cap; do NOT set to 0 as that means a cap of zero). Passed through to the contract as Option<u64> via allocator_add(): when null/omitted the contract treats it as `none` (no cap); when set, the contract enforces it. Has THREE effects when set:\n1. Construction: sum of Amount items must be <= max (EAMOUNT_EXCEEDS_MAX=13)\n2. Rate execution: total_rates = max - fix (instead of balance - fix)\n3. Surplus execution: surplus_amount = max - alloced_amount (instead of balance - alloced_amount)\nUse when you want to cap total allocation regardless of Order balance (e.g., cap payout to declared amount). SDK pre-validates Amount sum <= max at build time to give actionable error messages before on-chain abort.",
+                        "description": "Maximum allocation cap (OPTIONAL — omit the field or set to null to disable the cap; do NOT set to 0 as that means a cap of zero). Passed through to the contract as Option<u64> when the allocator is added: when null/omitted the contract treats it as `none` (no cap); when set, the contract enforces it. Has THREE effects when set:\n1. Construction: sum of Amount items must be <= max (EAMOUNT_EXCEEDS_MAX=13)\n2. Rate execution: total_rates = max - fix (instead of balance - fix)\n3. Surplus execution: surplus_amount = max - alloced_amount (instead of balance - alloced_amount)\nUse when you want to cap total allocation regardless of Order balance (e.g., cap payout to declared amount). SDK pre-validates Amount sum <= max at build time to give actionable error messages before on-chain abort.",
                         "anyOf": [
                           {
                             "anyOf": [
@@ -200,7 +200,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."
                           },
                           {
                             "type": "null"
@@ -240,7 +240,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": [
@@ -345,7 +345,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",
@@ -369,7 +369,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",
@@ -414,7 +414,7 @@
               ]
             },
             "alloc_by_guard": {
-              "description": "Verify the specified Guard and execute the corresponding fund distribution. GENERIC SEMANTICS: an Allocation distributes whatever balance it holds — order funds, payroll, dividends, bounties. It defines no scenario-specific rule: eligibility (including issuer identity for standalone use, e.g. an org admin) and differentiation inputs are expressed as Guard constraints, all public and auditable. RECIPIENT RESOLUTION (allocation.move Recipient enum): Entity → fixed address; Signer → transaction sender; GuardIdentifier n → the address submitted for identifier n (passport::submission_get). ORDER PATTERN (canonical): the Guard table needs ONE submitted Order, constrained by the Guard (e.g. order.service == host service, progress at a qualifying node, signer == order.owner); that order submission IS the recipient slot. Whoever calls alloc, funds necessarily land at an Order OBJECT; delivered CoinWrappers are owned by the order and can be extracted only via order::owner_receive (&mut Order input, Sui ownership) — the coins then go to the order's current owner. Object receipt = owner receipt. POST-DISTRIBUTION CLAIM (required step): each recipient gets a CoinWrapper (not spendable coins) — EOA wallet → operation_type='payment' RECEIVE mode {object:'<coinwrapper_id>', receive:true}; Order object → operation_type='order' {object:'<order_id>', receive:'recently'}; Treasury object → treasury receive. Find pending CoinWrappers via query_toolkit query_type='onchain_received'; verify via the immutable Payment object (allocation.payment array). RISK: safety follows from the sufficiency of the Guard constraints, not the recipient form — analyze the recipient constraint audit before publish; structural residuals (unavoidable): permissionless alloc allows forced settlement timing, the submitted order is not bound to the settled allocation, and allocators/guards are immutable after publish.",
+              "description": "Verify the specified Guard and execute the corresponding fund distribution. GENERIC SEMANTICS: an Allocation distributes whatever balance it holds — order funds, payroll, dividends, bounties. It defines no scenario-specific rule: eligibility (including issuer identity for standalone use, e.g. an org admin) and differentiation inputs are expressed as Guard constraints, all public and auditable. RECIPIENT RESOLUTION (Recipient enum): Entity → fixed address; Signer → transaction sender; GuardIdentifier n → the address submitted for identifier n (resolved from the passport's submission record). ORDER PATTERN (canonical): the Guard table needs ONE submitted Order, constrained by the Guard (e.g. order.service == host service, progress at a qualifying node, signer == order.owner); that order submission IS the recipient slot. Whoever triggers the distribution, funds necessarily land at an Order OBJECT; delivered CoinWrappers are owned by the order and can be extracted only by the Order object itself (Wow ownership) — the coins then go to the order's current owner. Object receipt = owner receipt. POST-DISTRIBUTION CLAIM (required step): each recipient gets a CoinWrapper (not spendable coins) — EOA wallet → operation_type='payment' RECEIVE mode {object:'<coinwrapper_id>', receive:true}; Order object → operation_type='order' {object:'<order_id>', receive:'recently'}; Treasury object → treasury receive. Find pending CoinWrappers via query_toolkit query_type='onchain_received'; verify via the immutable Payment object (allocation.payment array). RISK: safety follows from the sufficiency of the Guard constraints, not the recipient form — analyze the recipient constraint audit before publish; structural residuals (unavoidable): permissionless alloc allows forced settlement timing, the submitted order is not bound to the settled allocation, and allocators/guards are immutable after publish.",
               "type": "string"
             }
           },
@@ -460,7 +460,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": {
@@ -917,12 +917,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_arbitration.schema.json

@@ -127,7 +127,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": [
@@ -282,7 +282,7 @@
               "description": "Proposition INDICES (0-based, u8) the voter agrees with — e.g. [0] votes for the first proposition. Re-voting REPLACES the voter's previous vote (old weight removed, new applied). Out-of-range index aborts with E_PROPOSITION_NOT_FOUND."
             },
             "voting_guard": {
-              "description": "Optional Voting Guard for weighted voting. THREE PATHS are supported by the SDK and Move contract: (1) voting_guard PROVIDED → vote_with_voting_guard (Guard verifies voter + determines vote weight via VoteWeight config); (2) voting_guard OMITTED but other guards trigger passport creation (e.g. env.permission_guard or usage_guard) → vote_with_passport (permission-only via passport); (3) voting_guard OMITTED and no passport context → vote (plain permission-only vote, no Guard). The Guard (when provided) must be in the Arbitration's voting_guard list.",
+              "description": "Optional Voting Guard for weighted voting. THREE PATHS are supported by the SDK and Move contract: (1) voting_guard PROVIDED → Guard-weighted vote (Guard verifies voter + determines vote weight via VoteWeight config); (2) voting_guard OMITTED but other guards trigger passport creation (e.g. env.permission_guard or usage_guard) → permission-only vote via passport; (3) voting_guard OMITTED and no passport context → vote (plain permission-only vote, no Guard). The Guard (when provided) must be in the Arbitration's voting_guard list.",
               "type": "string"
             }
           },
@@ -621,7 +621,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",
@@ -645,7 +645,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",
@@ -706,7 +706,7 @@
         "object"
       ],
       "additionalProperties": false,
-      "description": "On-chain Arbitration operations. USAGE: (1) CREATE NEW: Set 'object' field with OBJECT format {name, type_parameter, permission, ...} to create an Arbitration. NOTE:'name' goes INSIDE 'object', NOT at the data root level. 'permission' can be a new Permission object or reference an existing one - check 'object' field description for details. ⚠️ PERMISSION RULE (contract-enforced, service.move arbitration_add_imp): the Arbitration's permission MUST be DIFFERENT from the permission of any Service it will be bound to — binding an Arbitration that SHARES the Service's Permission aborts with E_ARBITRATION_PERMISSION_CONFLICT (error 33). Always create a DEDICATED Permission object for each Arbitration. (2) OPERATE EXISTING: Set 'object' field with STRING format (object ID or name). The 'object' field is CRITICAL and REQUIRED in both cases. STRING for existing, OBJECT for new creation."
+      "description": "On-chain Arbitration operations. USAGE: (1) CREATE NEW: Set 'object' field with OBJECT format {name, type_parameter, permission, ...} to create an Arbitration. NOTE:'name' goes INSIDE 'object', NOT at the data root level. 'permission' can be a new Permission object or reference an existing one - check 'object' field description for details. ⚠️ PERMISSION RULE (contract-enforced): the Arbitration's permission MUST be DIFFERENT from the permission of any Service it will be bound to — binding an Arbitration that SHARES the Service's Permission aborts with E_ARBITRATION_PERMISSION_CONFLICT (error 33). Always create a DEDICATED Permission object for each Arbitration. (2) OPERATE EXISTING: Set 'object' field with STRING format (object ID or name). The 'object' field is CRITICAL and REQUIRED in both cases. STRING for existing, OBJECT for new creation."
     },
     "env": {
       "type": "object",
@@ -741,7 +741,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": {
@@ -1198,12 +1198,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_contact.schema.json

@@ -268,7 +268,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",
@@ -292,7 +292,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",
@@ -376,7 +376,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": {
@@ -833,12 +833,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_demand.schema.json

@@ -406,7 +406,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",
@@ -430,7 +430,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",
@@ -526,7 +526,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": {
@@ -983,12 +983,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_gen_passport.schema.json

@@ -433,12 +433,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"
@@ -580,7 +582,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_gen_proof.schema.json

@@ -99,7 +99,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_guard.schema.json

@@ -412,12 +412,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"
@@ -2402,7 +2404,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": {