@wowok/agent-mcp 3.4.4 → 3.4.5

package/dist/schemas/onchain_operations_allocation.schema.json

@@ -1 +1 @@
-{"$schema":"http://json-schema.org/draft-07/schema#","$id":"https://wowok.net/schemas/onchain_operations_allocation.json","title":"Allocation Operation","description":"📤 Allocation Object: Create distribution plans to auto-distribute funds to multiple recipients.","type":"object","properties":{"operation_type":{"type":"string","const":"allocation"},"data":{"anyOf":[{"type":"object","properties":{"object":{"type":"object","properties":{"name":{"description":"The name of the object","type":"string"},"tags":{"description":"The tags of the object","type":"array","items":{"type":"string"}},"onChain":{"description":"CRITICAL: Whether to sync the name to the blockchain. DEFAULT (undefined/false): The name is stored LOCALLY ONLY on your device (PRIVATE). If set to true: The name is published ON-CHAIN and becomes PUBLICLY VISIBLE to everyone. Only set to true for displaying the relationships you are willing to make public on the chain.","type":"boolean"},"replaceExistName":{"description":"FORCE CLAIM: Set to true ONLY when the user explicitly expresses a STRONG INTENTION to forcefully take over an existing name (e.g., 'I must use this name', 'force rename', 'replace the existing one'). WARNING: This will UNBIND the name from its original object and rebind it to the new one, potentially breaking existing references. If not specified or false: the operation will FAIL with an error when the name is already in use (safe default behavior).","type":"boolean"},"type_parameter":{"default":"0x2::wow::WOW","description":"Payment token type for this object (format: {address}::{module}::{struct}). e.g. ALWAYS the FULL type string `{address}::{module}::{struct}` e.g. '0x2::wow::WOW'. ⚠️ The bare names 'WOW' / 'USDT' / 'ETH' are REJECTED (the validator requires all three parts) — write '0x2::wow::WOW', not 'WOW'. The field may be OMITTED entirely: it then defaults to WOW ('0x2::wow::WOW'). This token is what the object accepts for payments and is fixed at creation. To discover other available tokens, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here. NOTE: testnet/localnet carry WOW only — USDT/ETH are a mainnet capability.","type":"string"}},"required":["type_parameter"],"additionalProperties":false,"description":"REQUIRED for creating new object. Provide {name: 'yourName', type: 'Allocation'} to create and name the new Allocation object."},"allocators":{"type":"object","properties":{"description":{"type":"string","description":"Description of fund allocator list"},"threshold":{"default":0,"description":"Minimum balance required for allocation to fire. When the Allocation object's balance < threshold, allocation aborts with EINSUFFICIENT_BALANCE=7. Also: when an Allocator has only Amount items (no Rate, no Surplus), the sum of Amount items must be >= threshold (EAMOUNT_BELOW_THRESHOLD=12). Set to 0 (default) to allow any balance.","anyOf":[{"type":"number"},{"type":"string"}]},"allocators":{"type":"array","items":{"type":"object","properties":{"guard":{"type":"string","description":"Guard object ID or name. A distribution call submits ONE guard; EVERY Allocator bound to that guard fires — in vector order, each against the balance left by the previous (the distribution loop matches the submitted guard address, it does NOT evaluate guards competitively). NOT first-match-wins: Allocators with different guards are alternative distribution paths selected by the caller's choice of guard (e.g., a refund guard vs a damage guard), and mutual exclusion must be expressed inside the Guard conditions themselves, never assumed from ordering."},"sharing":{"type":"array","items":{"type":"object","properties":{"who":{"anyOf":[{"type":"object","properties":{"GuardIdentifier":{"type":"integer","minimum":0,"maximum":255,"description":"Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails whose payee is NOT the order itself, such as settlement releases and incentive/bounty claims). NEVER arm 254 on a refund rail: a refund pays the submitted Order through user slot 0, and a refund leg re-entered in a later renewal period would abort E_ONCE_TRIGGERED (16) forever — refund once-ness comes from the terminal-node topology, never from a once slot. SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."}},"required":["GuardIdentifier"],"additionalProperties":false,"description":"Guard verified recipient ID. Get recipient ID from specified data index in Guard table. The ID must be of address type. ALLOCATION rails only — the REWARD claim rail requires recipient == the transaction sender (abort 14), so a GuardIdentifier recipient on reward.guard_add resolves to the submitted Order and is structurally unpayable; the tool gate rejects it (crs-mn-261015 F-12)."},{"type":"object","properties":{"Entity":{"anyOf":[{"description":"Account name, address (0x...), or mark name. When using string format, local marks are searched first. EXAMPLE: 'alice' - searches local marks first, then global; EXAMPLE: '0x2...' (64 hex chars) - uses address directly; EXAMPLE: '' - uses the default local account"},{"type":"object","properties":{"name_or_address":{"type":"string","description":"Account/Object name or ID. If specifying an account, use empty string '' for the default account. If it starts with '0x', it will be treated as an ID. Otherwise, it will be treated as a name (max 64 bcs characters)."},"local_mark_first":{"description":"Whether to prioritize local marks, if true, prioritize local marks, otherwise prioritize global marks","type":"boolean"}},"additionalProperties":false,"description":"Account or address lookup object. Use this to specify which account to use for an operation. EXAMPLE: { name_or_address: 'testor2' } - looks up account by name; EXAMPLE: { name_or_address: '0x1234...' } - uses address directly; If name_or_address is empty string '', uses the default local account. name_or_address is REQUIRED — {} resolves to nothing useful and is rejected."}],"description":"Account or address lookup. Can be a simple string (recommended for AI) or full object with explicit local_mark_first control. String form auto-converts to { name_or_address: <string>, local_mark_first: true }."}},"required":["Entity"],"additionalProperties":false,"description":"Static address resolved via LocalMark. Format: {Entity: 'mark_name'} (string shorthand) or {Entity: {name_or_address: 'mark_name'}} (full object).F-RQ-11 (rq2 promotion): string shorthand accepted — the FIX-005 transform resolves local marks first."},{"type":"object","properties":{"Signer":{"type":"string","const":"signer"}},"required":["Signer"],"additionalProperties":false,"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. On the REWARD claim rail this is the CANONICAL recipient (the claim entry requires recipient == the tx sender)."}],"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":[{"type":"number"},{"type":"string"}],"description":"Allocation value. SEMANTICS DEPEND ON `mode`:\n• mode='Amount': absolute amount in smallest unit (e.g., '750000000' for 0.75 WOW, '250000000' for 0.25 WOW). Allocated first; sum of Amount items cached as `fix`.\n• mode='Rate' (NET): basis-points rate off the post-fix base (balance - fix, or max - fix), 10000 = 100% (e.g., '7500' for 75%, '2500' for 25%). When no Surplus in same Allocator, sum MUST == 10000; when Surplus present, sum MUST <= 10000.\n• mode='RateGross': basis-points rate off the FULL pool (balance) or the `max` cap — the fixed Amount total is NOT subtracted, 10000 = 100%. sum MUST <= 10000 (and, with `max` set, fix×10000 + sum×max <= max×10000). Cannot be mixed with mode='Rate' in the same Allocator while a fixed Amount total is present.\n• mode='Surplus': IGNORED (contract forces to 0). Set to '0' for clarity. Receives remaining balance after Amount + Rate/RateGross allocations.\n• mode='Formula': basis-points COEFFICIENT (MUST be <= 10000) of a RUNTIME repository scalar — payout = clamp(coefficient × scalar / 10000, 0, headroom). Does NOT join any rate sum (its base is the queried scalar, not the pool) and skips the Amount>=threshold declaration check. Bind the slot's data source via allocation formula_spec_set, else the scalar reads 0.\n⚠️ T1 LOSSY POINT (B-2): Amount/Rate/RateGross/Surplus values are PRE-CONFIGURED and STATIC — a free-form continuous amount still cannot be expressed with them. Formula mode covers the bounded case: a coefficient (<= 10000 bps) of an attested repository aggregate (record count / value sum) — use it for runtime-proportional payouts; for anything richer, model (a) a fixed-tier Allocator list guarded by distinct Guards, or (b) an Amount with a `max` cap — both are finite configurations."},"mode":{"anyOf":[{"type":"string","enum":["Amount","Rate","Surplus","RateGross","Formula"]},{}],"description":"Allocation mode — determines how the `sharing` field is interpreted. Modes can be used individually OR combined within a single Allocator; when combined, allocation order is strictly: Amount first, then Rate/RateGross, then Formula scalar legs, then Surplus. Understanding these modes allows modeling almost any fund distribution pattern.\n• Amount (0): `sharing` is a FIXED amount in smallest unit (e.g., '750000000' = 0.75 WOW). Allocated FIRST; sum of all Amount items is cached as `fix` by the contract. Validation: when no Rate and no Surplus items exist, sum of Amount items must be >= allocators.threshold (EAMOUNT_BELOW_THRESHOLD=12); when `max` is set, sum of Amount items must be <= max (EAMOUNT_EXCEEDS_MAX=13).\n• Rate (1): `sharing` is a NET basis-points rate (10000 = 100%). Allocated AFTER Amount; formula: allocated = (sharing × total_rates) / 10000, where total_rates = balance - fix (or max - fix if `max` is set) — the cached fixed Amount total IS subtracted. Validation: when no Surplus items exist, sum of all Rate items must be EXACTLY 10000 (ERATE_NOT_10000=4); when Surplus items exist, sum of all Rate items must be <= 10000 (ERATE_EXCEEDS_10000=6).\n• RateGross (3): `sharing` is a GROSS basis-points rate (10000 = 100%). Allocated AFTER Amount; formula: allocated = (sharing × total_rates) / 10000, where total_rates = balance (the full pool) or the `max` cap when set — the fixed Amount total is NOT subtracted, so fixed Amount entries and percentage-of-total rates coexist exactly. Validation: sum of all RateGross items must be <= 10000 (ERATE_EXCEEDS_10000=6); when `max` is set, fix×10000 + sum(rate)×max <= max×10000 must hold (6); with no `max` and a fixed total > 0, sum of RateGross items must be < 10000 (6). RateGross cannot be mixed with NET Rate entries in the same Allocator while a fixed Amount total is present (EMIXED_RATE_BASES=17).\n• Surplus (2): `sharing` is IGNORED (contract forces it to 0). Allocated LAST; receives the remaining balance after Amount + Rate allocations. Validation: MAX ONE Surplus item per Allocator (EMULTIPLE_SURPLUS=5). When Surplus exists, Rate sum constraint relaxes from == 10000 to <= 10000.\n• Formula (4): `sharing` is a basis-points COEFFICIENT (<= 10000, ERATE_EXCEEDS_10000=6) applied to a RUNTIME scalar queried from a Repository at alloc() time — amount = clamp(coefficient × scalar / 10000, 0, headroom). The scalar comes from the slot's bound FormulaSpec (record-count or value-sum over a repository policy key, predicate wire identical to the 1173/1174 count/sum-where guard queries; explicit candidate ids, max 100, empty list = zero hits = scalar 0). A Formula leg does NOT join total_rate (its base is the queried scalar, not the pool) and its presence SKIPS the Amount-sum >= threshold declaration check (payout is runtime-defined). Requires a spec bound via allocation formula_spec_set — an unbound Formula slot prices its scalar as 0. binding a malformed spec aborts (EFORMULA_SPEC_INVALID=24).\nALLOCATION ORDER (strict): Amount items (fixed, cached as fix) → Rate/RateGross items → Formula scalar legs → Surplus item (remaining).\nRECOMMENDATION: Use Amount mode for known fixed amounts (clearer, no sum constraint). Use Rate mode for proportional splits off the post-fix remainder (requires sum == 10000 unless Surplus present). Use RateGross mode for a percentage of the FULL pool/`max` that must coexist with fixed Amount entries. Use Surplus to capture remainder (e.g., platform fee + host gets rest). Use Formula for payouts proportional to an attested on-chain aggregate (e.g. N records served, total value logged in a Repository) that cannot be known at configuration time. Accepts string ('Amount'/'Rate'/'Surplus'/'RateGross'/'Formula', recommended) or number (0/1/2/3/4)."}},"required":["who","sharing","mode"],"additionalProperties":false,"description":"Fund allocation item — one recipient's share of the Allocation balance. The `sharing` value's meaning depends on `mode` (see AllocationModeSchema). Multiple items in the same Allocator are evaluated together: Amount items first, Rate/RateGross items second, Surplus last."},"description":"Fund allocation item list. Each item specifies a recipient (who), a value (sharing), and a mode. Items can mix modes (Amount + Rate/RateGross + Formula + 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; RateGross proportional to the full pool) → Formula legs (coefficient of the runtime repository scalar) → Surplus item (remaining). CONSTRAINTS: max ONE Surplus item per Allocator; NET Rate sum must == 10000 (no Surplus) or <= 10000 (with Surplus); RateGross sum must <= 10000 (never mixed with NET Rate while a fixed total is present); each Formula leg's coefficient must <= 10000 but does NOT count into any rate sum; Amount sum must >= threshold (no Rate, no RateGross and no Formula present — a Formula leg skips this floor since its payout is runtime-defined) 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 when the allocator is added — DO NOT set this field at creation. Used internally to compute `total_rates = balance - fix` for NET Rate allocation (RateGross ignores fix and uses the full pool/`max`).","anyOf":[{"type":"number"},{"type":"string"}]},"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> 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: NET Rate total_rates = max - fix; RateGross total_rates = max (fix NOT subtracted)\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":[{"type":"number"},{"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 prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."},{"type":"null"}]}},"required":["guard","sharing"],"additionalProperties":false,"description":"Fund allocator — a complete allocation strategy triggered by a Guard. Contains a sharing[] array where items can mix Amount/Rate/RateGross/Surplus modes. When the Guard passes, the contract allocates funds in strict order: Amount → Rate/RateGross → Surplus."},"description":"Fund allocator list. NOT first-match-wins: a distribution call submits ONE guard and EVERY allocator bound to that guard fires, in vector order, each against the shrinking pool left by the previous (this is how a waterfall like Amount fee + net Rate split is built). Alternative paths (e.g., refund / damage-deduct / arbitrate) are expressed as allocators bound to DIFFERENT guards; the caller's submitted guard selects the path."}},"required":["description","threshold","allocators"],"additionalProperties":false,"description":"Fund allocator list — the top-level allocation configuration attached to an Order. Contains a threshold and a list of Allocators. A distribution call submits ONE guard; every Allocator bound to that guard executes its sharing[] in strict order (Amount → Rate/RateGross → Surplus) against the shrinking pool. MULTI-TIER ALLOCATION (DOC-04): Each Order binds ONE Allocators template (set on Service.order_allocators before publish). For multi-tier distribution (e.g., customer→agency→suppliers), use a two-phase approach: (1) Tier-1 Allocators on the customer's Order (allocates to agency + refund fund); (2) Tier-2 Allocators on a NEW Order created by the agency (allocates agency's received funds to suppliers). Each tier's NET Rate-mode sharing[] must independently sum to 10000 (or <= 10000 with Surplus); RateGross-mode sharing[] must sum to <= 10000."},"coin":{"anyOf":[{"type":"object","properties":{"balance":{"anyOf":[{"type":"number"},{"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 prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."}},"required":["balance"],"additionalProperties":false,"description":"Specify an amount value."},{"type":"object","properties":{"coin":{"type":"string","description":"Coin object ID or name(local mark). WHOLE-COIN TRANSFER: the ENTIRE Coin object is moved to the recipient — the 'amount' is NOT taken from it (testnet lesson: passing your main gas coin transfers its full balance, leaving you unable to pay for anything). Use only for coins whose whole balance is exactly what you intend to send; prefer {balance: <smallest-unit number>} for partial amounts."}},"required":["coin"],"additionalProperties":false}],"description":"Specify the amount to pay from the transaction account, or the Coin ID owned by the transaction account. Used for payment."},"payment_info":{"type":"object","properties":{"for_object":{"description":"Binding anchor for this distribution. On an Allocation a SET for_object is ENFORCED at alloc(): every GuardIdentifier recipient submission must equal this address or the whole tx aborts (ERECIPIENT_NOT_FOR_OBJECT, code 15) — verify the anchor matches the intended recipient flow BEFORE create; payment_info is immutable afterwards. NULL/omitted = no anchor: nothing is enforced on-chain, recipient routing is entirely the creator's design. Also recorded at creation for auditors to query the distribution's business context.","anyOf":[{"type":"string"},{"type":"null"}]},"for_guard":{"description":"Payment to satisfy verification of a Guard object","anyOf":[{"type":"string"},{"type":"null"}]},"remark":{"type":"string","description":"Payment record remark"},"index":{"type":"integer","minimum":0,"maximum":9007199254740991,"description":"Payment record index (non-negative integer)"}},"required":["remark","index"],"additionalProperties":false,"description":"Payment information"},"allow_unanchored":{"description":"docs#11 escape hatch: explicitly allow creating an Allocation whose payment_info has NO for_object anchor while any sharing row uses a GuardIdentifier recipient. Unanchored + GuardIdentifier lets any guard-passing caller redirect the submitted payout address to an arbitrary address — anchor it with payment_info.for_object instead. Set true ONLY after the user explicitly accepts that risk. Default: blocked.","type":"boolean"}},"required":["object","allocators","coin","payment_info"],"additionalProperties":false,"description":"Create a new Allocation object. Set 'object' field with {name: 'yourName', type: 'Allocation'} to name the new object. Notice:'name' goes INSIDE 'object', NOT at the data root level."},{"type":"object","properties":{"object":{"type":"string","description":"REQUIRED for operating existing object. Provide the Allocation object ID or existing name to reference the target object."},"received_coins":{"description":"Unwrap the CoinWrapper objects received by the Allocation object and deposit them into the pending allocation balance.\n\nACCEPTED FORMATS (F-06 unified receive operation block):\n• 'recently' (string literal) — auto-query and receive ALL recently received balance.\n  Use this for the common case: \"deposit all recently received coins into pending balance.\"\n  Example: receive: 'recently'\n  REWARD-OBJECT TRAP (F55 gf32-mn-261103): on a REWARD object, 'recently' resolves through\n  the Payment-derived ReceivedBalance primitive — a Reward that holds plain CoinWrapper\n  sweeps (query_received answers ReceivedNormal[]) aborts with 'received is ReceivedNormal[]\n  (expected ReceivedBalance)'. For a plain coin sweep on a Reward use owner_receive:'recently'\n  (same call — it unwraps received objects to the Permission owner) instead of receive.\n• ReceivedBalance ({token_type, balance, received: [{id, balance, payment}]}) —\n  receive a specific balance record from a Payment/payer.\n  Use this when targeting a specific received balance (advanced).\n  Example: receive: {token_type: '0x2::wow::WOW', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.","anyOf":[{"type":"object","properties":{"balance":{"anyOf":[{"type":"number"},{"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 prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."},"token_type":{"type":"string","description":"Asset type of Coin objects. Supports CoinWrapper<...> format for order receive operations."},"received":{"type":"array","items":{"type":"object","properties":{"id":{"type":"string","description":"Received CoinWrapper object ID"},"balance":{"anyOf":[{"type":"number"},{"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 prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."},"payment":{"type":"string","description":"Payment object ID"},"type":{"description":"Type of the received object (or inner coin type); used for token_type detection","type":"string"},"version":{"description":"Object version, required to build a Receiving<T> argument for owner_receive","type":"string"},"digest":{"description":"Object digest, required to build a Receiving<T> argument for owner_receive","type":"string"}},"required":["id","balance","payment"],"additionalProperties":false,"description":"Received CoinWrapper object record"},"description":"Received records of Coin objects"}},"required":["balance","token_type","received"],"additionalProperties":false,"description":"Received record of Coin objects"},{"type":"string","const":"recently"}]},"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 (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"},"alloc_batch":{"description":"Q8-F01 AGGREGATE RELEASE — sweep SEVERAL pools in ONE transaction (a single on-chain batch release). Provide the COMPLETE pool list INCLUDING 'object': the anchor Allocation addressed by this operation must appear in the list, and the SDK refuses a list that omits it. REQUIRES alloc_by_guard — that one Guard defines the release and is applied to every pool. WHY THIS EXISTS: a crowdfunding settlement holds each backer's escrow in its own Allocation under the SAME release/refund Guard; with single-pool calls a keeper needs N ordered transactions, and any keeper that stops at the first failure strands the remaining pools while the release reports done. ALL-OR-NOTHING: one pool aborting reverts the whole batch. PRE-FILTER drained pools before building the call — a zero-balance pool aborts the ENTIRE batch with EZERO_DISTRIBUTION (14) and nothing is released; an empty candidate set means there is genuinely nothing to release (an empty list is refused with EEMPTY_POOL_BATCH 26 instead of a fake success). EVERY pool must carry an allocator BOUND to alloc_by_guard: an unbound pool completes the sweep having distributed NOTHING, so the SDK verifies membership pool-by-pool and REFUSES the call before any gas is spent. Each recipient still receives a CoinWrapper and claims it through the normal POST-DISTRIBUTION CLAIM step — batching changes the release atomicity, not the claim path.","minItems":1,"type":"array","items":{"type":"string","description":"Account/Object name or ID. If specifying an account, use empty string '' for the default account. If it starts with '0x', it will be treated as an ID. Otherwise, it will be treated as a name (max 64 bcs characters)."}},"acknowledge_dual_payout":{"description":"A-1 (amz9-ln-261023; keeper posture 拍板⑧ dm-mtw-261027) explicit opt-in for a KNOWN double payout: when a submitted order already received arbitration compensation (order.claimed_by set) and this call would ALSO release its escrow (refund track), the call is REFUSED unless this flag is true. The two payout tracks are independent by design — the chain will not net or stop the second payout (the escrow receive path has no claimed_by gate), BUT a rail paired on order.claimed_by (refund none / recover some) may guard-reject the second payout on-chain; that rejection is the designed mutual exclusion, and the escrow exits via the paired rail. Buyer NET view: total received = compensation + escrow refund. Leave unset for normal refunds of un-awarded orders. AUTOMATION RULE: this flag is the HUMAN operator's netting decision — an automated keeper that receives dual_payout_unconfirmed must STOP retrying and escalate (never set the flag itself); a retry loop wastes gas and a silent stop strands the payout. D-1 (ksr 5R-08): the flag is additionally honored ONLY when the executing store carries a human-recorded preauthorization (config_operation store_dual_payout_set {account, confirm:true}, then store_dual_payout_get shows preauthorized=true); without it the gate answers dual_payout_preauthorization_required — record the standing decision first, then re-send.","type":"boolean"},"formula_spec_set":{"description":"Bind (or replace) the runtime pricing spec of ONE Formula sharing slot of this Allocation — no re-declaration of the allocator plan, no fund movement. Only the DATA SOURCE (which repository aggregate prices the slot) is set here; the slot itself must already be declared as a Formula leg (mode 4). An unbound Formula slot prices its scalar as 0.","type":"object","properties":{"allocator_index":{"type":"integer","minimum":0,"maximum":9007199254740991,"description":"Index of the allocator within allocators.allocators (0-based). Must address an EXISTING allocator, else refused on-chain (EFORMULA_SPEC_INVALID=24)."},"slot_index":{"type":"integer","minimum":0,"maximum":9007199254740991,"description":"Index of the sharing row within that allocator's sharing[] (0-based). Must address a slot whose mode is Formula, else refused on-chain (EFORMULA_SPEC_INVALID=24)."},"spec":{"type":"object","properties":{"repo":{"type":"string","description":"Repository object (ID or LocalMark name) whose policy-key data table is scanned at alloc() time to produce the scalar. Resolved to an address before the call."},"key":{"type":"string","description":"Policy key (String) inside that Repository whose data rows are the candidate set. Max 64 bytes."},"selector":{"anyOf":[{"type":"number","const":0},{"type":"number","const":1},{"type":"number","const":2}],"description":"Which aggregate produces the scalar: 0 = RECORD COUNT (u64 — how many candidate rows match the predicate), 1 = VALUE SUM (u256 — sum of the matching rows' numeric payloads, overflow-safe), 2 = ESCROW-BOUND VALUE SUM (u256 — like 1, but every row is first clamped to the escrow it points to: min(row_value, Order.amount of the Order that row's id names); a row whose id is not a real framework Order contributes 0, fail-closed). PREFER 2 whenever anyone other than the payer can write the candidate rows: an unbound SUM (1) lets a writer inflate the scalar simply by writing a large row, while 2 caps each row at the real order amount behind it (ksc-tn-261024 F-01 root cure). Any other value is refused on-chain (EFORMULA_SPEC_INVALID=24)."},"predicate":{"oneOf":[{"type":"object","properties":{"kind":{"type":"string","const":"range"},"valueMin":{"description":"Optional lower bound (inclusive unless minInclusive=false). Plain number string (U256 semantics).","type":"string"},"valueMax":{"description":"Optional upper bound (inclusive unless maxInclusive=false). Plain number string (U256 semantics).","type":"string"},"minInclusive":{"description":"Default true. false makes the lower bound exclusive.","type":"boolean"},"maxInclusive":{"description":"Default true. false makes the upper bound exclusive.","type":"boolean"}},"required":["kind"],"additionalProperties":false,"description":"Numeric closed/open range. min=max inclusive is an equality match. At least one bound required."},{"type":"object","properties":{"kind":{"type":"string","const":"numEq"},"value":{"type":"string","description":"Exact numeric match. Plain number string (U256 semantics)."}},"required":["kind","value"],"additionalProperties":false},{"type":"object","properties":{"kind":{"type":"string","const":"gt"},"value":{"type":"string","description":"Greater than. Plain number string (U256 semantics)."}},"required":["kind","value"],"additionalProperties":false},{"type":"object","properties":{"kind":{"type":"string","const":"gte"},"value":{"type":"string","description":"Greater than or equal. Plain number string (U256 semantics)."}},"required":["kind","value"],"additionalProperties":false},{"type":"object","properties":{"kind":{"type":"string","const":"lt"},"value":{"type":"string","description":"Less than. Plain number string (U256 semantics)."}},"required":["kind","value"],"additionalProperties":false},{"type":"object","properties":{"kind":{"type":"string","const":"lte"},"value":{"type":"string","description":"Less than or equal. Plain number string (U256 semantics)."}},"required":["kind","value"],"additionalProperties":false},{"type":"object","properties":{"kind":{"type":"string","const":"addressEq"},"identifier":{"type":"integer","minimum":0,"maximum":255,"description":"Identifier of the Address-type table entry to compare against."}},"required":["kind","identifier"],"additionalProperties":false},{"type":"object","properties":{"kind":{"type":"string","const":"stringEq"},"value":{"type":"string","description":"Exact string match (byte equality, UTF-8)."}},"required":["kind","value"],"additionalProperties":false},{"type":"object","properties":{"kind":{"type":"string","const":"stringContains"},"value":{"type":"string","description":"Substring match, case-sensitive."}},"required":["kind","value"],"additionalProperties":false},{"type":"object","properties":{"kind":{"type":"string","const":"stringNoCaseContains"},"value":{"type":"string","description":"Substring match, case-insensitive."}},"required":["kind","value"],"additionalProperties":false},{"type":"object","properties":{"kind":{"type":"string","const":"boolEq"},"value":{"type":"boolean","description":"Boolean equality."}},"required":["kind","value"],"additionalProperties":false}],"description":"Predicate filter applied to each candidate's stored value — SAME wire format as the repository count/sum-where guard queries (1173/1174). kind must match the policy value type; mismatching entries are skipped honestly (never an error)."},"ids":{"type":"array","items":{"type":"string"},"description":"EXPLICIT candidate object IDs (vector<address>) to scan. Duplicates are deduped; max 100 candidates; an EMPTY list matches no records (scalar 0) — there is no 'all objects' wildcard. S12-③ witness boundary (v140): the 100-cap applies to THIS guard-table vector; the guard's inline WITNESS is separately capped at 4096 BCS bytes total (passport MAX_SUBMISSION_SIZE — a 100-address roster fits), so keep roster-style attestation here in the vector and reserve the witness for per-call attestation."}},"required":["repo","key","selector","predicate","ids"],"additionalProperties":false,"description":"Runtime pricing spec for one Formula sharing slot (FormulaSpec). Payout for that leg = clamp(sharing_coefficient_bps × scalar / 10000, 0, headroom), where scalar = the selected aggregate over the Repository rows. Binding REPLACES any previous spec for the slot; the plan shape itself (which slots are Formula, coefficients) is immutable and was fixed when the allocator was declared."}},"required":["allocator_index","slot_index","spec"],"additionalProperties":false}},"required":["object"],"additionalProperties":false,"description":"Operate on an existing Allocation object. Set 'object' field with the object ID or existing name to specify the target."}],"description":"On-chain Allocation operations. USAGE: (1) CREATE NEW: Use CallAllocation_CreateSchema by setting 'object' with OBJECT format {name, type_parameter, ...}. (2) OPERATE EXISTING: Use CallAllocation_OperateSchema by setting 'object' with STRING format (object ID or name). The 'object' field is CRITICAL and REQUIRED in both cases. "},"idempotency_key":{"type":"string","minLength":8,"maxLength":128,"pattern":"^[A-Za-z0-9._:-]+$","description":"F-RQ-13A (prescription ⑨): idempotency key for this business attempt. REPLAY GUARD: if a previous call with the SAME key is still open (dispatched but outcome unresolved, or already committed), this call is HELD — you get a structured state_conflict envelope with the prior attempt's verification data instead of a second on-chain submission (the ghost-order guard: two live mainnet orders, two escrows). Lifecycle: a deterministic failure (nothing submitted / provably reverted) clears the key — fix the cause and retry with the SAME key; an unknown-outcome failure (submission may have landed) keeps the key HELD — verify on-chain state first (result.submission_verification tells you where to look), and only retry with a NEW key once the outcome is resolved. Keep one key per business attempt (e.g. 'ord-20261030-042-buy'); do not reuse across attempts."},"env":{"type":"object","properties":{"account":{"default":"","type":"string","description":"Account/Object name or ID. If specifying an account, use empty string '' for the default account. If it starts with '0x', it will be treated as an ID. Otherwise, it will be treated as a name (max 64 bcs characters)."},"permission_guard":{"description":"List of permission guard IDs. Used to extend additional operation permissions (requires verification and configuration in the Permission object).","type":"array","items":{"type":"string"}},"no_cache":{"description":"Whether to disable caching.","type":"boolean"},"network":{"description":"Omit in chat-client contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.","type":"string","enum":["localnet","testnet","mainnet"]},"referrer":{"description":"Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).","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 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":{"description":"Phase 2 ConfirmGate: set to true to proceed after a 'pending_confirmation' result. The operation is NOT executed until you re-call with confirmed=true after user consent.","type":"boolean"},"user_intent_phrases":{"description":"Phase 2 ConfirmGate: explicit user intent phrases collected from conversation context (e.g. 'use default account', 'force publish'). Used to bypass confirmation rules whose bypass_on_explicit_intent matches.","type":"array","items":{"type":"string"}},"plan_approval":{"description":"K3 24 PlanApproval: id of a goal whose plan was approved via goal_operation action='approve'. When set: 1) the ConfirmGate treats fail-open rules (standard/none levels) as pre-approved for operations under this goal's plan; 2) after successful CREATION operations, the created objects are auto-registered into the goal (GoalRecord.objects + its TaskProcess manifest — ACT station 'execution registers'). Fail-closed levels (irreversible/publish/amount) still require per-operation confirmation with env.confirmed=true.","type":"string"},"client_schema_version":{"description":"Client-side schema version (semver, e.g. '1.0.0'). When provided, the server checks compatibility and attaches warnings if mismatched.","type":"string"},"schema_strict_mode":{"default":false,"description":"When true, schema incompatibility returns an error instead of a warning. Default: false (warn mode).","type":"boolean"},"dry_run":{"description":"Phase 1 dry_run: when true, SIMULATE the transaction without signing or submitting. Returns effects + events showing what WOULD happen — no on-chain state is modified, no gas is charged. Use this to verify that an operation will succeed before committing. The returned digest will be 'dry_run:<timestamp>' and objectChanges will be empty (simulation only).","type":"boolean"},"window_profile":{"description":"Time-window profile for trial runs (N8 ktt6 F-14 re-carving of the 'business windows are never test-compressed' ruling, 2026-11-04). 'production' (default): compressed time-window violations BLOCK publish exactly as before. 'test': compressed windows are ADMITTED so a disposable trial store can run its full lifecycle fast — R-TIME-PROFILE violations degrade to loud named disclosures, and the publish itself is BLOCKED on a real network (testnet/mainnet); point the trial at a local/dev chain (env.network='localnet'). Trial discipline: test-profile stores are throwaway — a production store must re-issue WITHOUT this flag (guards freeze at publish, so compressed windows are unrepairable except by rebuilding the store).","type":"string","enum":["production","test"]},"response_level":{"description":"Write-success response size. 'compact' (default) trims the structured result to key fields (digest + created object references); 'full' includes the complete raw result. Default: compact.","type":"string","enum":["compact","full"]},"confirm_mode":{"description":"Confirmation frequency for this call. 'full': confirm every matched gate rule. 'streamlined' (client default): skip fail-open 'standard' level prompts — fail-closed levels (irreversible/publish/amount) ALWAYS still confirm. 'quiet': same hard floor as streamlined, for clients that batch/suppress repeat low-risk prompts in their own UI. This field NEVER downgrades fail-closed levels.","type":"string","enum":["full","streamlined","quiet"]}},"required":["account","schema_strict_mode"],"additionalProperties":false,"description":"IMPORTANT: Execution environment includes: account for signing operations, network selection (testnet | localnet | mainnet), additional Guard permissions, and more. Used to specify context information during the call. If account is not specified, the default account (\"\") will be used. NOTE: by default the SDK auto-registers the sender in the global Entity table when absent (first business transaction; the account receives an owned Resource object). Set no_auto_register=true only on explicit user request."},"submission":{"type":"object","properties":{"type":{"type":"string","const":"submission","description":"Discriminator for this result variant. Constraint: always 'submission'. Example: 'submission'"},"guard":{"maxItems":20,"type":"array","items":{"type":"object","properties":{"object":{"type":"string","description":"Guard object name or ID to verify against. Example: 'my-delivery-guard' or '0x123...'"},"impack":{"type":"boolean","description":"Whether this Guard's verification result participates in the final logic. Constraint: if false, the Guard is checked but does not block the operation. Example: true"}},"required":["object","impack"],"additionalProperties":false},"description":"Array of Guard objects to verify. Constraint: at most 20 entries (MAX_GUARD_COUNT_PASSPORT). Relation: each entry corresponds to a Guard bound to the operation."},"submission":{"type":"array","items":{"type":"object","properties":{"guard":{"type":"string","description":"Guard object name or ID that requires submission data. Example: 'my-delivery-guard'"},"submission":{"type":"array","items":{"type":"object","properties":{"identifier":{"type":"integer","minimum":0,"maximum":255,"description":"Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails whose payee is NOT the order itself, such as settlement releases and incentive/bounty claims). NEVER arm 254 on a refund rail: a refund pays the submitted Order through user slot 0, and a refund leg re-entered in a later renewal period would abort E_ONCE_TRIGGERED (16) forever — refund once-ness comes from the terminal-node topology, never from a once slot. SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."},"b_submission":{"type":"boolean","description":"Whether this table item's value is submitted dynamically at Guard trigger time (alloc_by_guard call). \n\ntrue = value is submitted by the caller when triggering the Guard. Use for runtime-context-dependent values like order address, user address. The 'value' field is ignored when b_submission=true; the caller must provide it via submissions[]. \n\nfalse = value is static, set at Guard creation time. Use for values known when the Guard is created: expected node names, expected merchant address, expected service address. The 'value' field must be populated and will be stored on-chain permanently. \n\nRule of thumb: if the value is the SAME for all future Guard triggers, use false. If the value DIFFERS per trigger (e.g., which order to release funds for), use true."},"value_type":{"description":"Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details.","anyOf":[{"type":"number","const":0,"description":"Bool (0)"},{"type":"number","const":1,"description":"Address (1)"},{"type":"number","const":2,"description":"String (2)"},{"type":"number","const":3,"description":"U8 (3)"},{"type":"number","const":4,"description":"U16 (4)"},{"type":"number","const":5,"description":"U32 (5)"},{"type":"number","const":6,"description":"U64 (6)"},{"type":"number","const":7,"description":"U128 (7)"},{"type":"number","const":8,"description":"U256 (8)"},{"type":"number","const":9,"description":"VecBool (9)"},{"type":"number","const":10,"description":"VecAddress (10)"},{"type":"number","const":11,"description":"VecString (11)"},{"type":"number","const":12,"description":"VecU8 (12)"},{"type":"number","const":13,"description":"VecU16 (13)"},{"type":"number","const":14,"description":"VecU32 (14)"},{"type":"number","const":15,"description":"VecU64 (15)"},{"type":"number","const":16,"description":"VecU128 (16)"},{"type":"number","const":17,"description":"VecU256 (17)"},{"type":"number","const":18,"description":"VecVecU8 (18)"},{"type":"string","const":"Bool","description":"Bool"},{"type":"string","const":"Address","description":"Address"},{"type":"string","const":"String","description":"String"},{"type":"string","const":"U8","description":"U8"},{"type":"string","const":"U16","description":"U16"},{"type":"string","const":"U32","description":"U32"},{"type":"string","const":"U64","description":"U64"},{"type":"string","const":"U128","description":"U128"},{"type":"string","const":"U256","description":"U256"},{"type":"string","const":"VecBool","description":"VecBool"},{"type":"string","const":"VecAddress","description":"VecAddress"},{"type":"string","const":"VecString","description":"VecString"},{"type":"string","const":"VecU8","description":"VecU8"},{"type":"string","const":"VecU16","description":"VecU16"},{"type":"string","const":"VecU32","description":"VecU32"},{"type":"string","const":"VecU64","description":"VecU64"},{"type":"string","const":"VecU128","description":"VecU128"},{"type":"string","const":"VecU256","description":"VecU256"},{"type":"string","const":"VecVecU8","description":"VecVecU8"},{"type":"string","const":"bool","description":"bool"},{"type":"string","const":"address","description":"address"},{"type":"string","const":"string","description":"string"},{"type":"string","const":"u8","description":"u8"},{"type":"string","const":"u16","description":"u16"},{"type":"string","const":"u32","description":"u32"},{"type":"string","const":"u64","description":"u64"},{"type":"string","const":"u128","description":"u128"},{"type":"string","const":"u256","description":"u256"},{"type":"string","const":"vecbool","description":"vecbool"},{"type":"string","const":"vecaddress","description":"vecaddress"},{"type":"string","const":"vecstring","description":"vecstring"},{"type":"string","const":"vecu8","description":"vecu8"},{"type":"string","const":"vecu16","description":"vecu16"},{"type":"string","const":"vecu32","description":"vecu32"},{"type":"string","const":"vecu64","description":"vecu64"},{"type":"string","const":"vecu128","description":"vecu128"},{"type":"string","const":"vecu256","description":"vecu256"},{"type":"string","const":"vecvecu8","description":"vecvecu8"}]},"value":{"description":"The actual value data. Format depends on `value_type`:\nTYPE-CLASS SPLIT (F03): scalar value_types (Bool/Address/String/U8..U256) take ONE scalar value (boolean/address string/name/string/number); Vec* value_types (VecBool/VecAddress/VecString/VecU8..VecU256) take a REAL JSON ARRAY of elements — a string (even a Python-repr-looking \"[a, b]\") fails serialization with 'value_type=10 (array) requires a array value'. The historical 'static values must be strings' rule applied to SCALARS only.\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nPROTOCOL SLOT 254 (once, b_submission Address): the submitted value MUST be the ORDER address bound to the operation (payment_info.for_object) — NEVER the Progress/Machine/Arb object the call is advancing. The chain asserts submission(254) == the order address; a Progress address fails the task binding and the forward aborts.\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).","anyOf":[{"type":"boolean"},{"anyOf":[{"type":"object","properties":{"name_or_address":{"type":"string","description":"Account/Object name or ID. If specifying an account, use empty string '' for the default account. If it starts with '0x', it will be treated as an ID. Otherwise, it will be treated as a name (max 64 bcs characters)."},"local_mark_first":{"description":"Whether to prioritize local marks, if true, prioritize local marks, otherwise prioritize global marks","type":"boolean"}},"additionalProperties":false,"description":"Account or address lookup object. Use this to specify which account to use for an operation. EXAMPLE: { name_or_address: 'testor2' } - looks up account by name; EXAMPLE: { name_or_address: '0x1234...' } - uses address directly; If name_or_address is empty string '', uses the default local account. name_or_address is REQUIRED — {} resolves to nothing useful and is rejected."},{"type":"string"}]},{"type":"string"},{"type":"number"},{"type":"array","items":{"type":"boolean"}},{"anyOf":[{"type":"object","properties":{"entities":{"minItems":1,"type":"array","items":{"type":"object","properties":{"name_or_address":{"type":"string","description":"Account/Object name or ID. If specifying an account, use empty string '' for the default account. If it starts with '0x', it will be treated as an ID. Otherwise, it will be treated as a name (max 64 bcs characters)."},"local_mark_first":{"description":"Whether to prioritize local marks, if true, prioritize local marks, otherwise prioritize global marks","type":"boolean"}},"additionalProperties":false,"description":"Account or address lookup object. Use this to specify which account to use for an operation. EXAMPLE: { name_or_address: 'testor2' } - looks up account by name; EXAMPLE: { name_or_address: '0x1234...' } - uses address directly; If name_or_address is empty string '', uses the default local account. name_or_address is REQUIRED — {} resolves to nothing useful and is rejected."}},"check_all_founded":{"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","check_all_founded"],"additionalProperties":false,"description":"Used to batch find account or object IDs by name"},{"type":"array","items":{"type":"string"}}]},{"type":"array","items":{"type":"string"}},{"type":"array","items":{"type":"number"}},{"type":"array","items":{"type":"array","items":{"type":"number"}}}]},"name":{"default":"","description":"Data name identifier. MAX 64 BCS characters (Chinese chars count as 3-4 BCS bytes each). Use short identifiers like 'order_id', 'delivery_node'. Put longer descriptions in the Guard's 'description' field, NOT here.","type":"string"},"object_type":{"description":"OUTPUT-ONLY (query side): Object type when value_type is Address and represents a specific object. Auto-derived by the system — DO NOT set this field at Guard creation.","type":"string","enum":["Permission","Repository","Arb","Arbitration","Service","Machine","Order","Progress","Payment","Treasury","Guard","Demand","Passport","Allocation","Resource","Reward","Discount","EntityRegistrar","EntityLinker","Proof","WReceivedObject","Contact","TableItem_ProgressHistory","TableItem_PermissionPerm","TableItem_DemandPresenter","TableItem_MachineNode","TableItem_TreasuryHistory","TableItem_RepositoryData","TableItem_RewardRecord","TableItem_EntityLinker","TableItem_AddressMark","TableItem_EntityRegistrar"]}},"required":["identifier","b_submission","value_type","name"],"additionalProperties":false,"description":"Guard table item (QUERY/OUTPUT form — includes auto-derived object_type field)"},"description":"User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}] PROTOCOL SLOT 254: when the Guard table has identifier 254, submit the ORDER address bound to the operation (payment_info.for_object) — never the Progress/Machine object being advanced."}},"required":["guard","submission"],"additionalProperties":false,"description":"One Guard's submission data: the Guard to verify plus the user-provided data that satisfies its requirements."},"description":"User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. SLOT COMPLETENESS (T8 az3-mn-261013): the submission array must cover EVERY b_submission slot in the Guard's table, not just one — a Guard whose table has multiple b_submission entries (e.g. slot 0 + slot 254) aborts on-chain with 'Submission ID not found' (abort 11) when any b_submission slot has no matching entry. Check the Guard's table (each entry with b_submission needs its identifier filled) and include ALL of them. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"}},"required":["type","guard","submission"],"additionalProperties":false,"description":"Guard verification required. The operation was blocked because one or more Guards require user-submitted data. Fill the submission array and resubmit. Semantic status is 'pending_input'."}},"required":["operation_type","data"],"additionalProperties":false}
+{"$schema":"http://json-schema.org/draft-07/schema#","$id":"https://wowok.net/schemas/onchain_operations_allocation.json","title":"Allocation Operation","description":"📤 Allocation Object: Create distribution plans to auto-distribute funds to multiple recipients.","type":"object","properties":{"operation_type":{"type":"string","const":"allocation"},"data":{"anyOf":[{"type":"object","properties":{"object":{"type":"object","properties":{"name":{"description":"The name of the object","type":"string"},"tags":{"description":"The tags of the object","type":"array","items":{"type":"string"}},"onChain":{"description":"CRITICAL: Whether to sync the name to the blockchain. DEFAULT (undefined/false): The name is stored LOCALLY ONLY on your device (PRIVATE). If set to true: The name is published ON-CHAIN and becomes PUBLICLY VISIBLE to everyone. Only set to true for displaying the relationships you are willing to make public on the chain.","type":"boolean"},"replaceExistName":{"description":"FORCE CLAIM: Set to true ONLY when the user explicitly expresses a STRONG INTENTION to forcefully take over an existing name (e.g., 'I must use this name', 'force rename', 'replace the existing one'). WARNING: This will UNBIND the name from its original object and rebind it to the new one, potentially breaking existing references. If not specified or false: the operation will FAIL with an error when the name is already in use (safe default behavior).","type":"boolean"},"type_parameter":{"default":"0x2::wow::WOW","description":"Payment token type for this object (format: {address}::{module}::{struct}). e.g. ALWAYS the FULL type string `{address}::{module}::{struct}` e.g. '0x2::wow::WOW'. ⚠️ The bare names 'WOW' / 'USDT' / 'ETH' are REJECTED (the validator requires all three parts) — write '0x2::wow::WOW', not 'WOW'. The field may be OMITTED entirely: it then defaults to WOW ('0x2::wow::WOW'). This token is what the object accepts for payments and is fixed at creation. To discover other available tokens, call wowok_buildin_info with info 'mainnet bridge tokens' and use the returned `wowTypeTag` value here. NOTE: testnet/localnet carry WOW only — USDT/ETH are a mainnet capability.","type":"string"}},"required":["type_parameter"],"additionalProperties":false,"description":"REQUIRED for creating new object. Provide {name: 'yourName', type: 'Allocation'} to create and name the new Allocation object."},"allocators":{"type":"object","properties":{"description":{"type":"string","description":"Description of fund allocator list"},"threshold":{"default":0,"description":"Minimum balance required for allocation to fire. When the Allocation object's balance < threshold, allocation aborts with EINSUFFICIENT_BALANCE=7. Also: when an Allocator has only Amount items (no Rate, no Surplus), the sum of Amount items must be >= threshold (EAMOUNT_BELOW_THRESHOLD=12). Set to 0 (default) to allow any balance.","anyOf":[{"type":"number"},{"type":"string"}]},"allocators":{"type":"array","items":{"type":"object","properties":{"guard":{"type":"string","description":"Guard object ID or name. A distribution call submits ONE guard; EVERY Allocator bound to that guard fires — in vector order, each against the balance left by the previous (the distribution loop matches the submitted guard address, it does NOT evaluate guards competitively). NOT first-match-wins: Allocators with different guards are alternative distribution paths selected by the caller's choice of guard (e.g., a refund guard vs a damage guard), and mutual exclusion must be expressed inside the Guard conditions themselves, never assumed from ordering."},"sharing":{"type":"array","items":{"type":"object","properties":{"who":{"anyOf":[{"type":"object","properties":{"GuardIdentifier":{"type":"integer","minimum":0,"maximum":255,"description":"Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails whose payee is NOT the order itself, such as settlement releases and incentive/bounty claims). NEVER arm 254 on a refund rail: a refund pays the submitted Order through user slot 0, and a refund leg re-entered in a later renewal period would abort E_ONCE_TRIGGERED (16) forever — refund once-ness comes from the terminal-node topology, never from a once slot. SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."}},"required":["GuardIdentifier"],"additionalProperties":false,"description":"Guard verified recipient ID. Get recipient ID from specified data index in Guard table. The ID must be of address type. ALLOCATION rails only — the REWARD claim rail requires recipient == the transaction sender (abort 14), so a GuardIdentifier recipient on reward.guard_add resolves to the submitted Order and is structurally unpayable; the tool gate rejects it (crs-mn-261015 F-12)."},{"type":"object","properties":{"Entity":{"anyOf":[{"description":"Account name, address (0x...), or mark name. When using string format, local marks are searched first. EXAMPLE: 'alice' - searches local marks first, then global; EXAMPLE: '0x2...' (64 hex chars) - uses address directly; EXAMPLE: '' - uses the default local account"},{"type":"object","properties":{"name_or_address":{"type":"string","description":"Account/Object name or ID. If specifying an account, use empty string '' for the default account. If it starts with '0x', it will be treated as an ID. Otherwise, it will be treated as a name (max 64 bcs characters)."},"local_mark_first":{"description":"Whether to prioritize local marks, if true, prioritize local marks, otherwise prioritize global marks","type":"boolean"}},"additionalProperties":false,"description":"Account or address lookup object. Use this to specify which account to use for an operation. EXAMPLE: { name_or_address: 'testor2' } - looks up account by name; EXAMPLE: { name_or_address: '0x1234...' } - uses address directly; If name_or_address is empty string '', uses the default local account. name_or_address is REQUIRED — {} resolves to nothing useful and is rejected."}],"description":"Account or address lookup. Can be a simple string (recommended for AI) or full object with explicit local_mark_first control. String form auto-converts to { name_or_address: <string>, local_mark_first: true }."}},"required":["Entity"],"additionalProperties":false,"description":"Static address resolved via LocalMark. Format: {Entity: 'mark_name'} (string shorthand) or {Entity: {name_or_address: 'mark_name'}} (full object).F-RQ-11 (rq2 promotion): string shorthand accepted — the FIX-005 transform resolves local marks first."},{"type":"object","properties":{"Signer":{"type":"string","const":"signer"}},"required":["Signer"],"additionalProperties":false,"description":"Current transaction signer (tx_context::sender) at the time of the alloc() call. On refund rails the recipient resolution does NOT check who fires the transaction: with {Signer} the FUNDS GO TO whoever sends the tx (klk3-mn D1: a non-owner successfully fired a refund alloc_by_guard on mainnet). So for a buyer self-refund the BUYER must be the sender — an operator firing it would pay itself. With an order-anchored recipient (GuardIdentifier/Entity) anyone may fire alloc_by_guard; the refund CoinWrapper is owned by the ORDER object and the ORDER OWNER unwraps it via order receive. On the REWARD claim rail this is the CANONICAL recipient (the claim entry REQUIRES recipient == the tx sender — abort 14 otherwise)."}],"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. CORRECTION (klk3-mn D1, mainnet-verified): on REFUND rails the contract does NOT enforce that the sender be the Order owner — whoever fires alloc_by_guard with a {Signer} recipient BECOMES the recipient. For a customer self-refund the CUSTOMER must therefore be the tx sender (an operator/keeper firing it pays itself). With an order-anchored recipient the CoinWrapper is owned by the ORDER and the order owner unwraps via order receive regardless of who fired the alloc. The recipient == sender HARD constraint exists only on the REWARD claim rail (abort 14). Use when the recipient is whoever submits the allocation transaction (e.g., customer receives refund)."},"sharing":{"anyOf":[{"type":"number"},{"type":"string"}],"description":"Allocation value. SEMANTICS DEPEND ON `mode`:\n• mode='Amount': absolute amount in smallest unit (e.g., '750000000' for 0.75 WOW, '250000000' for 0.25 WOW). Allocated first; sum of Amount items cached as `fix`.\n• mode='Rate' (NET): basis-points rate off the post-fix base (balance - fix, or max - fix), 10000 = 100% (e.g., '7500' for 75%, '2500' for 25%). When no Surplus in same Allocator, sum MUST == 10000; when Surplus present, sum MUST <= 10000.\n• mode='RateGross': basis-points rate off the FULL pool (balance) or the `max` cap — the fixed Amount total is NOT subtracted, 10000 = 100%. sum MUST <= 10000 (and, with `max` set, fix×10000 + sum×max <= max×10000). Cannot be mixed with mode='Rate' in the same Allocator while a fixed Amount total is present.\n• mode='Surplus': IGNORED (contract forces to 0). Set to '0' for clarity. Receives remaining balance after Amount + Rate/RateGross allocations.\n• mode='Formula': basis-points COEFFICIENT (MUST be <= 10000) of a RUNTIME repository scalar — payout = clamp(coefficient × scalar / 10000, 0, headroom). Does NOT join any rate sum (its base is the queried scalar, not the pool) and skips the Amount>=threshold declaration check. Bind the slot's data source via allocation formula_spec_set, else the scalar reads 0.\n⚠️ T1 LOSSY POINT (B-2): Amount/Rate/RateGross/Surplus values are PRE-CONFIGURED and STATIC — a free-form continuous amount still cannot be expressed with them. Formula mode covers the bounded case: a coefficient (<= 10000 bps) of an attested repository aggregate (record count / value sum) — use it for runtime-proportional payouts; for anything richer, model (a) a fixed-tier Allocator list guarded by distinct Guards, or (b) an Amount with a `max` cap — both are finite configurations."},"mode":{"anyOf":[{"type":"string","enum":["Amount","Rate","Surplus","RateGross","Formula"]},{}],"description":"Allocation mode — determines how the `sharing` field is interpreted. Modes can be used individually OR combined within a single Allocator; when combined, allocation order is strictly: Amount first, then Rate/RateGross, then Formula scalar legs, then Surplus. Understanding these modes allows modeling almost any fund distribution pattern.\n• Amount (0): `sharing` is a FIXED amount in smallest unit (e.g., '750000000' = 0.75 WOW). Allocated FIRST; sum of all Amount items is cached as `fix` by the contract. Validation: when no Rate and no Surplus items exist, sum of Amount items must be >= allocators.threshold (EAMOUNT_BELOW_THRESHOLD=12); when `max` is set, sum of Amount items must be <= max (EAMOUNT_EXCEEDS_MAX=13).\n• Rate (1): `sharing` is a NET basis-points rate (10000 = 100%). Allocated AFTER Amount; formula: allocated = (sharing × total_rates) / 10000, where total_rates = balance - fix (or max - fix if `max` is set) — the cached fixed Amount total IS subtracted. Validation: when no Surplus items exist, sum of all Rate items must be EXACTLY 10000 (ERATE_NOT_10000=4); when Surplus items exist, sum of all Rate items must be <= 10000 (ERATE_EXCEEDS_10000=6).\n• RateGross (3): `sharing` is a GROSS basis-points rate (10000 = 100%). Allocated AFTER Amount; formula: allocated = (sharing × total_rates) / 10000, where total_rates = balance (the full pool) or the `max` cap when set — the fixed Amount total is NOT subtracted, so fixed Amount entries and percentage-of-total rates coexist exactly. Validation: sum of all RateGross items must be <= 10000 (ERATE_EXCEEDS_10000=6); when `max` is set, fix×10000 + sum(rate)×max <= max×10000 must hold (6); with no `max` and a fixed total > 0, sum of RateGross items must be < 10000 (6). RateGross cannot be mixed with NET Rate entries in the same Allocator while a fixed Amount total is present (EMIXED_RATE_BASES=17).\n• Surplus (2): `sharing` is IGNORED (contract forces it to 0). Allocated LAST; receives the remaining balance after Amount + Rate allocations. Validation: MAX ONE Surplus item per Allocator (EMULTIPLE_SURPLUS=5). When Surplus exists, Rate sum constraint relaxes from == 10000 to <= 10000.\n• Formula (4): `sharing` is a basis-points COEFFICIENT (<= 10000, ERATE_EXCEEDS_10000=6) applied to a RUNTIME scalar queried from a Repository at alloc() time — amount = clamp(coefficient × scalar / 10000, 0, headroom). The scalar comes from the slot's bound FormulaSpec (record-count or value-sum over a repository policy key, predicate wire identical to the 1173/1174 count/sum-where guard queries; explicit candidate ids, max 100, empty list = zero hits = scalar 0). A Formula leg does NOT join total_rate (its base is the queried scalar, not the pool) and its presence SKIPS the Amount-sum >= threshold declaration check (payout is runtime-defined). Requires a spec bound via allocation formula_spec_set — an unbound Formula slot prices its scalar as 0. binding a malformed spec aborts (EFORMULA_SPEC_INVALID=24).\nALLOCATION ORDER (strict): Amount items (fixed, cached as fix) → Rate/RateGross items → Formula scalar legs → Surplus item (remaining).\nRECOMMENDATION: Use Amount mode for known fixed amounts (clearer, no sum constraint). Use Rate mode for proportional splits off the post-fix remainder (requires sum == 10000 unless Surplus present). Use RateGross mode for a percentage of the FULL pool/`max` that must coexist with fixed Amount entries. Use Surplus to capture remainder (e.g., platform fee + host gets rest). Use Formula for payouts proportional to an attested on-chain aggregate (e.g. N records served, total value logged in a Repository) that cannot be known at configuration time. Accepts string ('Amount'/'Rate'/'Surplus'/'RateGross'/'Formula', recommended) or number (0/1/2/3/4)."}},"required":["who","sharing","mode"],"additionalProperties":false,"description":"Fund allocation item — one recipient's share of the Allocation balance. The `sharing` value's meaning depends on `mode` (see AllocationModeSchema). Multiple items in the same Allocator are evaluated together: Amount items first, Rate/RateGross items second, Surplus last."},"description":"Fund allocation item list. Each item specifies a recipient (who), a value (sharing), and a mode. Items can mix modes (Amount + Rate/RateGross + Formula + 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; RateGross proportional to the full pool) → Formula legs (coefficient of the runtime repository scalar) → Surplus item (remaining). CONSTRAINTS: max ONE Surplus item per Allocator; NET Rate sum must == 10000 (no Surplus) or <= 10000 (with Surplus); RateGross sum must <= 10000 (never mixed with NET Rate while a fixed total is present); each Formula leg's coefficient must <= 10000 but does NOT count into any rate sum; Amount sum must >= threshold (no Rate, no RateGross and no Formula present — a Formula leg skips this floor since its payout is runtime-defined) 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 when the allocator is added — DO NOT set this field at creation. Used internally to compute `total_rates = balance - fix` for NET Rate allocation (RateGross ignores fix and uses the full pool/`max`).","anyOf":[{"type":"number"},{"type":"string"}]},"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> 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: NET Rate total_rates = max - fix; RateGross total_rates = max (fix NOT subtracted)\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":[{"type":"number"},{"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 prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."},{"type":"null"}]}},"required":["guard","sharing"],"additionalProperties":false,"description":"Fund allocator — a complete allocation strategy triggered by a Guard. Contains a sharing[] array where items can mix Amount/Rate/RateGross/Surplus modes. When the Guard passes, the contract allocates funds in strict order: Amount → Rate/RateGross → Surplus."},"description":"Fund allocator list. NOT first-match-wins: a distribution call submits ONE guard and EVERY allocator bound to that guard fires, in vector order, each against the shrinking pool left by the previous (this is how a waterfall like Amount fee + net Rate split is built). Alternative paths (e.g., refund / damage-deduct / arbitrate) are expressed as allocators bound to DIFFERENT guards; the caller's submitted guard selects the path."}},"required":["description","threshold","allocators"],"additionalProperties":false,"description":"Fund allocator list — the top-level allocation configuration attached to an Order. Contains a threshold and a list of Allocators. A distribution call submits ONE guard; every Allocator bound to that guard executes its sharing[] in strict order (Amount → Rate/RateGross → Surplus) against the shrinking pool. MULTI-TIER ALLOCATION (DOC-04): Each Order binds ONE Allocators template (set on Service.order_allocators before publish). For multi-tier distribution (e.g., customer→agency→suppliers), use a two-phase approach: (1) Tier-1 Allocators on the customer's Order (allocates to agency + refund fund); (2) Tier-2 Allocators on a NEW Order created by the agency (allocates agency's received funds to suppliers). Each tier's NET Rate-mode sharing[] must independently sum to 10000 (or <= 10000 with Surplus); RateGross-mode sharing[] must sum to <= 10000."},"coin":{"anyOf":[{"type":"object","properties":{"balance":{"anyOf":[{"type":"number"},{"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 prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."}},"required":["balance"],"additionalProperties":false,"description":"Specify an amount value."},{"type":"object","properties":{"coin":{"type":"string","description":"Coin object ID or name(local mark). WHOLE-COIN TRANSFER: the ENTIRE Coin object is moved to the recipient — the 'amount' is NOT taken from it (testnet lesson: passing your main gas coin transfers its full balance, leaving you unable to pay for anything). Use only for coins whose whole balance is exactly what you intend to send; prefer {balance: <smallest-unit number>} for partial amounts."}},"required":["coin"],"additionalProperties":false}],"description":"Specify the amount to pay from the transaction account, or the Coin ID owned by the transaction account. Used for payment."},"payment_info":{"type":"object","properties":{"for_object":{"description":"Binding anchor for this distribution. On an Allocation a SET for_object is ENFORCED at alloc(): every GuardIdentifier recipient submission must equal this address or the whole tx aborts (ERECIPIENT_NOT_FOR_OBJECT, code 15) — verify the anchor matches the intended recipient flow BEFORE create; payment_info is immutable afterwards. NULL/omitted = no anchor: nothing is enforced on-chain, recipient routing is entirely the creator's design. Also recorded at creation for auditors to query the distribution's business context.","anyOf":[{"type":"string"},{"type":"null"}]},"for_guard":{"description":"Payment to satisfy verification of a Guard object","anyOf":[{"type":"string"},{"type":"null"}]},"remark":{"type":"string","description":"Payment record remark"},"index":{"type":"integer","minimum":0,"maximum":9007199254740991,"description":"Payment record index (non-negative integer)"}},"required":["remark","index"],"additionalProperties":false,"description":"Payment information"},"allow_unanchored":{"description":"docs#11 escape hatch: explicitly allow creating an Allocation whose payment_info has NO for_object anchor while any sharing row uses a GuardIdentifier recipient. Unanchored + GuardIdentifier lets any guard-passing caller redirect the submitted payout address to an arbitrary address — anchor it with payment_info.for_object instead. Set true ONLY after the user explicitly accepts that risk. Default: blocked.","type":"boolean"}},"required":["object","allocators","coin","payment_info"],"additionalProperties":false,"description":"Create a new Allocation object. Set 'object' field with {name: 'yourName', type: 'Allocation'} to name the new object. Notice:'name' goes INSIDE 'object', NOT at the data root level."},{"type":"object","properties":{"object":{"type":"string","description":"REQUIRED for operating existing object. Provide the Allocation object ID or existing name to reference the target object."},"received_coins":{"description":"Unwrap the CoinWrapper objects received by the Allocation object and deposit them into the pending allocation balance.\n\nACCEPTED FORMATS (F-06 unified receive operation block):\n• 'recently' (string literal) — auto-query and receive ALL recently received balance.\n  Use this for the common case: \"deposit all recently received coins into pending balance.\"\n  Example: receive: 'recently'\n  REWARD-OBJECT TRAP (F55 gf32-mn-261103): on a REWARD object, 'recently' resolves through\n  the Payment-derived ReceivedBalance primitive — a Reward that holds plain CoinWrapper\n  sweeps (query_received answers ReceivedNormal[]) aborts with 'received is ReceivedNormal[]\n  (expected ReceivedBalance)'. For a plain coin sweep on a Reward use owner_receive:'recently'\n  (same call — it unwraps received objects to the Permission owner) instead of receive.\n• ReceivedBalance ({token_type, balance, received: [{id, balance, payment}]}) —\n  receive a specific balance record from a Payment/payer.\n  Use this when targeting a specific received balance (advanced).\n  Example: receive: {token_type: '0x2::wow::WOW', balance: 1000000, received: [{id: '0xrec1', balance: 1000000, payment: '0xpay1'}]}\nANTI-PATTERN: do NOT wrap in {result: ...} — pass the value directly.","anyOf":[{"type":"object","properties":{"balance":{"anyOf":[{"type":"number"},{"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 prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."},"token_type":{"type":"string","description":"Asset type of Coin objects. Supports CoinWrapper<...> format for order receive operations."},"received":{"type":"array","items":{"type":"object","properties":{"id":{"type":"string","description":"Received CoinWrapper object ID"},"balance":{"anyOf":[{"type":"number"},{"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 prices, compensation fund balances, Treasury deposits, arbitration fees, reward amounts, stock quantities."},"payment":{"type":"string","description":"Payment object ID"},"type":{"description":"Type of the received object (or inner coin type); used for token_type detection","type":"string"},"version":{"description":"Object version, required to build a Receiving<T> argument for owner_receive","type":"string"},"digest":{"description":"Object digest, required to build a Receiving<T> argument for owner_receive","type":"string"}},"required":["id","balance","payment"],"additionalProperties":false,"description":"Received CoinWrapper object record"},"description":"Received records of Coin objects"}},"required":["balance","token_type","received"],"additionalProperties":false,"description":"Received record of Coin objects"},{"type":"string","const":"recently"}]},"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 (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"},"alloc_batch":{"description":"Q8-F01 AGGREGATE RELEASE — sweep SEVERAL pools in ONE transaction (a single on-chain batch release). Provide the COMPLETE pool list INCLUDING 'object': the anchor Allocation addressed by this operation must appear in the list, and the SDK refuses a list that omits it. REQUIRES alloc_by_guard — that one Guard defines the release and is applied to every pool. WHY THIS EXISTS: a crowdfunding settlement holds each backer's escrow in its own Allocation under the SAME release/refund Guard; with single-pool calls a keeper needs N ordered transactions, and any keeper that stops at the first failure strands the remaining pools while the release reports done. ALL-OR-NOTHING: one pool aborting reverts the whole batch. PRE-FILTER drained pools before building the call — a zero-balance pool aborts the ENTIRE batch with EZERO_DISTRIBUTION (14) and nothing is released; an empty candidate set means there is genuinely nothing to release (an empty list is refused with EEMPTY_POOL_BATCH 26 instead of a fake success). EVERY pool must carry an allocator BOUND to alloc_by_guard: an unbound pool completes the sweep having distributed NOTHING, so the SDK verifies membership pool-by-pool and REFUSES the call before any gas is spent. Each recipient still receives a CoinWrapper and claims it through the normal POST-DISTRIBUTION CLAIM step — batching changes the release atomicity, not the claim path.","minItems":1,"type":"array","items":{"type":"string","description":"Account/Object name or ID. If specifying an account, use empty string '' for the default account. If it starts with '0x', it will be treated as an ID. Otherwise, it will be treated as a name (max 64 bcs characters)."}},"acknowledge_dual_payout":{"description":"A-1 (amz9-ln-261023; keeper posture 拍板⑧ dm-mtw-261027) explicit opt-in for a KNOWN double payout: when a submitted order already received arbitration compensation (order.claimed_by set) and this call would ALSO release its escrow (refund track), the call is REFUSED unless this flag is true. The two payout tracks are independent by design — the chain will not net or stop the second payout (the escrow receive path has no claimed_by gate), BUT a rail paired on order.claimed_by (refund none / recover some) may guard-reject the second payout on-chain; that rejection is the designed mutual exclusion, and the escrow exits via the paired rail. Buyer NET view: total received = compensation + escrow refund. Leave unset for normal refunds of un-awarded orders. AUTOMATION RULE: this flag is the HUMAN operator's netting decision — an automated keeper that receives dual_payout_unconfirmed must STOP retrying and escalate (never set the flag itself); a retry loop wastes gas and a silent stop strands the payout. D-1 (ksr 5R-08): the flag is additionally honored ONLY when the executing store carries a human-recorded preauthorization (config_operation store_dual_payout_set {account, confirm:true}, then store_dual_payout_get shows preauthorized=true); without it the gate answers dual_payout_preauthorization_required — record the standing decision first, then re-send.","type":"boolean"},"formula_spec_set":{"description":"Bind (or replace) the runtime pricing spec of ONE Formula sharing slot of this Allocation — no re-declaration of the allocator plan, no fund movement. Only the DATA SOURCE (which repository aggregate prices the slot) is set here; the slot itself must already be declared as a Formula leg (mode 4). An unbound Formula slot prices its scalar as 0.","type":"object","properties":{"allocator_index":{"type":"integer","minimum":0,"maximum":9007199254740991,"description":"Index of the allocator within allocators.allocators (0-based). Must address an EXISTING allocator, else refused on-chain (EFORMULA_SPEC_INVALID=24)."},"slot_index":{"type":"integer","minimum":0,"maximum":9007199254740991,"description":"Index of the sharing row within that allocator's sharing[] (0-based). Must address a slot whose mode is Formula, else refused on-chain (EFORMULA_SPEC_INVALID=24)."},"spec":{"type":"object","properties":{"repo":{"type":"string","description":"Repository object (ID or LocalMark name) whose policy-key data table is scanned at alloc() time to produce the scalar. Resolved to an address before the call."},"key":{"type":"string","description":"Policy key (String) inside that Repository whose data rows are the candidate set. Max 64 bytes."},"selector":{"anyOf":[{"type":"number","const":0},{"type":"number","const":1},{"type":"number","const":2}],"description":"Which aggregate produces the scalar: 0 = RECORD COUNT (u64 — how many candidate rows match the predicate), 1 = VALUE SUM (u256 — sum of the matching rows' numeric payloads, overflow-safe), 2 = ESCROW-BOUND VALUE SUM (u256 — like 1, but every row is first clamped to the escrow it points to: min(row_value, Order.amount of the Order that row's id names); a row whose id is not a real framework Order contributes 0, fail-closed). PREFER 2 whenever anyone other than the payer can write the candidate rows: an unbound SUM (1) lets a writer inflate the scalar simply by writing a large row, while 2 caps each row at the real order amount behind it (ksc-tn-261024 F-01 root cure). Any other value is refused on-chain (EFORMULA_SPEC_INVALID=24)."},"predicate":{"oneOf":[{"type":"object","properties":{"kind":{"type":"string","const":"range"},"valueMin":{"description":"Optional lower bound (inclusive unless minInclusive=false). Plain number string (U256 semantics).","type":"string"},"valueMax":{"description":"Optional upper bound (inclusive unless maxInclusive=false). Plain number string (U256 semantics).","type":"string"},"minInclusive":{"description":"Default true. false makes the lower bound exclusive.","type":"boolean"},"maxInclusive":{"description":"Default true. false makes the upper bound exclusive.","type":"boolean"}},"required":["kind"],"additionalProperties":false,"description":"Numeric closed/open range. min=max inclusive is an equality match. At least one bound required."},{"type":"object","properties":{"kind":{"type":"string","const":"numEq"},"value":{"type":"string","description":"Exact numeric match. Plain number string (U256 semantics)."}},"required":["kind","value"],"additionalProperties":false},{"type":"object","properties":{"kind":{"type":"string","const":"gt"},"value":{"type":"string","description":"Greater than. Plain number string (U256 semantics)."}},"required":["kind","value"],"additionalProperties":false},{"type":"object","properties":{"kind":{"type":"string","const":"gte"},"value":{"type":"string","description":"Greater than or equal. Plain number string (U256 semantics)."}},"required":["kind","value"],"additionalProperties":false},{"type":"object","properties":{"kind":{"type":"string","const":"lt"},"value":{"type":"string","description":"Less than. Plain number string (U256 semantics)."}},"required":["kind","value"],"additionalProperties":false},{"type":"object","properties":{"kind":{"type":"string","const":"lte"},"value":{"type":"string","description":"Less than or equal. Plain number string (U256 semantics)."}},"required":["kind","value"],"additionalProperties":false},{"type":"object","properties":{"kind":{"type":"string","const":"addressEq"},"identifier":{"type":"integer","minimum":0,"maximum":255,"description":"Identifier of the Address-type table entry to compare against."}},"required":["kind","identifier"],"additionalProperties":false},{"type":"object","properties":{"kind":{"type":"string","const":"stringEq"},"value":{"type":"string","description":"Exact string match (byte equality, UTF-8)."}},"required":["kind","value"],"additionalProperties":false},{"type":"object","properties":{"kind":{"type":"string","const":"stringContains"},"value":{"type":"string","description":"Substring match, case-sensitive."}},"required":["kind","value"],"additionalProperties":false},{"type":"object","properties":{"kind":{"type":"string","const":"stringNoCaseContains"},"value":{"type":"string","description":"Substring match, case-insensitive."}},"required":["kind","value"],"additionalProperties":false},{"type":"object","properties":{"kind":{"type":"string","const":"boolEq"},"value":{"type":"boolean","description":"Boolean equality."}},"required":["kind","value"],"additionalProperties":false}],"description":"Predicate filter applied to each candidate's stored value — SAME wire format as the repository count/sum-where guard queries (1173/1174). kind must match the policy value type; mismatching entries are skipped honestly (never an error)."},"ids":{"type":"array","items":{"type":"string"},"description":"EXPLICIT candidate object IDs (vector<address>) to scan. Duplicates are deduped; max 100 candidates; an EMPTY list matches no records (scalar 0) — there is no 'all objects' wildcard. S12-③ witness boundary (v140): the 100-cap applies to THIS guard-table vector; the guard's inline WITNESS is separately capped at 4096 BCS bytes total (passport MAX_SUBMISSION_SIZE — a 100-address roster fits), so keep roster-style attestation here in the vector and reserve the witness for per-call attestation."}},"required":["repo","key","selector","predicate","ids"],"additionalProperties":false,"description":"Runtime pricing spec for one Formula sharing slot (FormulaSpec). Payout for that leg = clamp(sharing_coefficient_bps × scalar / 10000, 0, headroom), where scalar = the selected aggregate over the Repository rows. Binding REPLACES any previous spec for the slot; the plan shape itself (which slots are Formula, coefficients) is immutable and was fixed when the allocator was declared."}},"required":["allocator_index","slot_index","spec"],"additionalProperties":false}},"required":["object"],"additionalProperties":false,"description":"Operate on an existing Allocation object. Set 'object' field with the object ID or existing name to specify the target."}],"description":"On-chain Allocation operations. USAGE: (1) CREATE NEW: Use CallAllocation_CreateSchema by setting 'object' with OBJECT format {name, type_parameter, ...}. (2) OPERATE EXISTING: Use CallAllocation_OperateSchema by setting 'object' with STRING format (object ID or name). The 'object' field is CRITICAL and REQUIRED in both cases. "},"idempotency_key":{"type":"string","minLength":8,"maxLength":128,"pattern":"^[A-Za-z0-9._:-]+$","description":"F-RQ-13A (prescription ⑨): idempotency key for this business attempt. REPLAY GUARD: if a previous call with the SAME key is still open (dispatched but outcome unresolved, or already committed), this call is HELD — you get a structured state_conflict envelope with the prior attempt's verification data instead of a second on-chain submission (the ghost-order guard: two live mainnet orders, two escrows). Lifecycle: a deterministic failure (nothing submitted / provably reverted) clears the key — fix the cause and retry with the SAME key; an unknown-outcome failure (submission may have landed) keeps the key HELD — verify on-chain state first (result.submission_verification tells you where to look), and only retry with a NEW key once the outcome is resolved. Keep one key per business attempt (e.g. 'ord-20261030-042-buy'); do not reuse across attempts."},"env":{"type":"object","properties":{"account":{"default":"","type":"string","description":"Account/Object name or ID. If specifying an account, use empty string '' for the default account. If it starts with '0x', it will be treated as an ID. Otherwise, it will be treated as a name (max 64 bcs characters)."},"permission_guard":{"description":"List of permission guard IDs. Used to extend additional operation permissions (requires verification and configuration in the Permission object).","type":"array","items":{"type":"string"}},"no_cache":{"description":"Whether to disable caching.","type":"boolean"},"network":{"description":"Omit in chat-client contexts — the runtime stamps the user's CURRENT network (the client's UI selection). Standalone MCP/CLI: omit to use the current network; set ONLY when the user explicitly names a different network (a mismatch pauses for user confirmation). Never guess or hardcode a network.","type":"string","enum":["localnet","testnet","mainnet"]},"referrer":{"description":"Referrer ID. If the user is using the network for the first time, the referrer ID will be recorded (also applied when the SDK auto-registers the sender in the global Entity table).","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 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":{"description":"Phase 2 ConfirmGate: set to true to proceed after a 'pending_confirmation' result. The operation is NOT executed until you re-call with confirmed=true after user consent.","type":"boolean"},"user_intent_phrases":{"description":"Phase 2 ConfirmGate: explicit user intent phrases collected from conversation context (e.g. 'use default account', 'force publish'). Used to bypass confirmation rules whose bypass_on_explicit_intent matches.","type":"array","items":{"type":"string"}},"plan_approval":{"description":"K3 24 PlanApproval: id of a goal whose plan was approved via goal_operation action='approve'. When set: 1) the ConfirmGate treats fail-open rules (standard/none levels) as pre-approved for operations under this goal's plan; 2) after successful CREATION operations, the created objects are auto-registered into the goal (GoalRecord.objects + its TaskProcess manifest — ACT station 'execution registers'). Fail-closed levels (irreversible/publish/amount) still require per-operation confirmation with env.confirmed=true.","type":"string"},"client_schema_version":{"description":"Client-side schema version (semver, e.g. '1.0.0'). When provided, the server checks compatibility and attaches warnings if mismatched.","type":"string"},"schema_strict_mode":{"default":false,"description":"When true, schema incompatibility returns an error instead of a warning. Default: false (warn mode).","type":"boolean"},"dry_run":{"description":"Phase 1 dry_run: when true, SIMULATE the transaction without signing or submitting. Returns effects + events showing what WOULD happen — no on-chain state is modified, no gas is charged. Use this to verify that an operation will succeed before committing. The returned digest will be 'dry_run:<timestamp>' and objectChanges will be empty (simulation only).","type":"boolean"},"window_profile":{"description":"Time-window profile for trial runs (N8 ktt6 F-14 re-carving of the 'business windows are never test-compressed' ruling, 2026-11-04). 'production' (default): compressed time-window violations BLOCK publish exactly as before. 'test': compressed windows are ADMITTED so a disposable trial store can run its full lifecycle fast — R-TIME-PROFILE violations degrade to loud named disclosures, and the publish itself is BLOCKED on a real network (testnet/mainnet); point the trial at a local/dev chain (env.network='localnet'). Trial discipline: test-profile stores are throwaway — a production store must re-issue WITHOUT this flag (guards freeze at publish, so compressed windows are unrepairable except by rebuilding the store).","type":"string","enum":["production","test"]},"response_level":{"description":"Write-success response size. 'compact' (default) trims the structured result to key fields (digest + created object references); 'full' includes the complete raw result. Default: compact.","type":"string","enum":["compact","full"]},"confirm_mode":{"description":"Confirmation frequency for this call. 'full': confirm every matched gate rule. 'streamlined' (client default): skip fail-open 'standard' level prompts — fail-closed levels (irreversible/publish/amount) ALWAYS still confirm. 'quiet': same hard floor as streamlined, for clients that batch/suppress repeat low-risk prompts in their own UI. This field NEVER downgrades fail-closed levels.","type":"string","enum":["full","streamlined","quiet"]}},"required":["account","schema_strict_mode"],"additionalProperties":false,"description":"IMPORTANT: Execution environment includes: account for signing operations, network selection (testnet | localnet | mainnet), additional Guard permissions, and more. Used to specify context information during the call. If account is not specified, the default account (\"\") will be used. NOTE: by default the SDK auto-registers the sender in the global Entity table when absent (first business transaction; the account receives an owned Resource object). Set no_auto_register=true only on explicit user request."},"submission":{"type":"object","properties":{"type":{"type":"string","const":"submission","description":"Discriminator for this result variant. Constraint: always 'submission'. Example: 'submission'"},"guard":{"maxItems":20,"type":"array","items":{"type":"object","properties":{"object":{"type":"string","description":"Guard object name or ID to verify against. Example: 'my-delivery-guard' or '0x123...'"},"impack":{"type":"boolean","description":"Whether this Guard's verification result participates in the final logic. Constraint: if false, the Guard is checked but does not block the operation. Example: true"}},"required":["object","impack"],"additionalProperties":false},"description":"Array of Guard objects to verify. Constraint: at most 20 entries (MAX_GUARD_COUNT_PASSPORT); each entry is an OBJECT {object, impack} — NOT a bare address string. An EMPTY array is rejected at dispatch unless the forward genuinely carries no guards — prefer omitting submission entirely for guard-less edges (kq4x-mn MCP-1: an empty guard list produced no transaction and burned 6 retries on a misleading 'no result'). Relation: each entry corresponds to a Guard bound to the operation."},"submission":{"type":"array","items":{"type":"object","properties":{"guard":{"type":"string","description":"Guard object name or ID that requires submission data. Example: 'my-delivery-guard'"},"submission":{"type":"array","items":{"type":"object","properties":{"identifier":{"type":"integer","minimum":0,"maximum":255,"description":"Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails whose payee is NOT the order itself, such as settlement releases and incentive/bounty claims). NEVER arm 254 on a refund rail: a refund pays the submitted Order through user slot 0, and a refund leg re-entered in a later renewal period would abort E_ONCE_TRIGGERED (16) forever — refund once-ness comes from the terminal-node topology, never from a once slot. SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."},"b_submission":{"type":"boolean","description":"Whether this table item's value is submitted dynamically at Guard trigger time (alloc_by_guard call). \n\ntrue = value is submitted by the caller when triggering the Guard. Use for runtime-context-dependent values like order address, user address. The 'value' field is ignored when b_submission=true; the caller must provide it via submissions[]. \n\nfalse = value is static, set at Guard creation time. Use for values known when the Guard is created: expected node names, expected merchant address, expected service address. The 'value' field must be populated and will be stored on-chain permanently. \n\nRule of thumb: if the value is the SAME for all future Guard triggers, use false. If the value DIFFERS per trigger (e.g., which order to release funds for), use true."},"value_type":{"description":"Type of the value stored in `value`. One of: Bool(0), Address(1), String(2), U8(3), U16(4), U32(5), U64(6), U128(7), U256(8), VecBool(9), VecAddress(10), VecString(11), VecU8(12), VecU16(13), VecU32(14), VecU64(15), VecU128(16), VecU256(17), VecVecU8(18). When value_type=Address (1), the `value` field accepts a hex address string, a LocalMark name, or an AccountOrMark_Address object — see `value` field description for details.","anyOf":[{"type":"number","const":0,"description":"Bool (0)"},{"type":"number","const":1,"description":"Address (1)"},{"type":"number","const":2,"description":"String (2)"},{"type":"number","const":3,"description":"U8 (3)"},{"type":"number","const":4,"description":"U16 (4)"},{"type":"number","const":5,"description":"U32 (5)"},{"type":"number","const":6,"description":"U64 (6)"},{"type":"number","const":7,"description":"U128 (7)"},{"type":"number","const":8,"description":"U256 (8)"},{"type":"number","const":9,"description":"VecBool (9)"},{"type":"number","const":10,"description":"VecAddress (10)"},{"type":"number","const":11,"description":"VecString (11)"},{"type":"number","const":12,"description":"VecU8 (12)"},{"type":"number","const":13,"description":"VecU16 (13)"},{"type":"number","const":14,"description":"VecU32 (14)"},{"type":"number","const":15,"description":"VecU64 (15)"},{"type":"number","const":16,"description":"VecU128 (16)"},{"type":"number","const":17,"description":"VecU256 (17)"},{"type":"number","const":18,"description":"VecVecU8 (18)"},{"type":"string","const":"Bool","description":"Bool"},{"type":"string","const":"Address","description":"Address"},{"type":"string","const":"String","description":"String"},{"type":"string","const":"U8","description":"U8"},{"type":"string","const":"U16","description":"U16"},{"type":"string","const":"U32","description":"U32"},{"type":"string","const":"U64","description":"U64"},{"type":"string","const":"U128","description":"U128"},{"type":"string","const":"U256","description":"U256"},{"type":"string","const":"VecBool","description":"VecBool"},{"type":"string","const":"VecAddress","description":"VecAddress"},{"type":"string","const":"VecString","description":"VecString"},{"type":"string","const":"VecU8","description":"VecU8"},{"type":"string","const":"VecU16","description":"VecU16"},{"type":"string","const":"VecU32","description":"VecU32"},{"type":"string","const":"VecU64","description":"VecU64"},{"type":"string","const":"VecU128","description":"VecU128"},{"type":"string","const":"VecU256","description":"VecU256"},{"type":"string","const":"VecVecU8","description":"VecVecU8"},{"type":"string","const":"bool","description":"bool"},{"type":"string","const":"address","description":"address"},{"type":"string","const":"string","description":"string"},{"type":"string","const":"u8","description":"u8"},{"type":"string","const":"u16","description":"u16"},{"type":"string","const":"u32","description":"u32"},{"type":"string","const":"u64","description":"u64"},{"type":"string","const":"u128","description":"u128"},{"type":"string","const":"u256","description":"u256"},{"type":"string","const":"vecbool","description":"vecbool"},{"type":"string","const":"vecaddress","description":"vecaddress"},{"type":"string","const":"vecstring","description":"vecstring"},{"type":"string","const":"vecu8","description":"vecu8"},{"type":"string","const":"vecu16","description":"vecu16"},{"type":"string","const":"vecu32","description":"vecu32"},{"type":"string","const":"vecu64","description":"vecu64"},{"type":"string","const":"vecu128","description":"vecu128"},{"type":"string","const":"vecu256","description":"vecu256"},{"type":"string","const":"vecvecu8","description":"vecvecu8"}]},"value":{"description":"The actual value data. Format depends on `value_type`:\nTYPE-CLASS SPLIT (F03): scalar value_types (Bool/Address/String/U8..U256) take ONE scalar value (boolean/address string/name/string/number); Vec* value_types (VecBool/VecAddress/VecString/VecU8..VecU256) take a REAL JSON ARRAY of elements — a string (even a Python-repr-looking \"[a, b]\") fails serialization with 'value_type=10 (array) requires a array value'. The historical 'static values must be strings' rule applied to SCALARS only.\n• Bool: true/false (boolean)\n• Address (CRITICAL — string 'Address' is NOT a placeholder): a hex address (e.g. '0x1234...'), a LocalMark name (e.g. 'my-service' — resolved to address at evaluation time), an AccountOrMark_Address object (e.g. {name_or_address:'my-service'}), or system shorthand ('0xaaa' = EntityLinker, '0xaab' = EntityRegistrar). The literal string 'Address' itself is INVALID — it would be treated as a non-existent LocalMark name and fail. Example: value='0x2::wow::WOW<address>' or value='my-permission'.\n• String: any string\n• U8/U16/U32/U64/U128/U256: number or numeric string (e.g. 42 or '42')\n• Vec* types: arrays of the corresponding element type\nPROTOCOL SLOT 254 (once, b_submission Address): the submitted value MUST be the ORDER address bound to the operation (payment_info.for_object) — NEVER the Progress/Machine/Arb object the call is advancing. The chain asserts submission(254) == the order address; a Progress address fails the task binding and the forward aborts.\nREQUIRED when b_submission=false. OPTIONAL when b_submission=true (value is supplied at evaluation time by user submission).","anyOf":[{"type":"boolean"},{"anyOf":[{"type":"object","properties":{"name_or_address":{"type":"string","description":"Account/Object name or ID. If specifying an account, use empty string '' for the default account. If it starts with '0x', it will be treated as an ID. Otherwise, it will be treated as a name (max 64 bcs characters)."},"local_mark_first":{"description":"Whether to prioritize local marks, if true, prioritize local marks, otherwise prioritize global marks","type":"boolean"}},"additionalProperties":false,"description":"Account or address lookup object. Use this to specify which account to use for an operation. EXAMPLE: { name_or_address: 'testor2' } - looks up account by name; EXAMPLE: { name_or_address: '0x1234...' } - uses address directly; If name_or_address is empty string '', uses the default local account. name_or_address is REQUIRED — {} resolves to nothing useful and is rejected."},{"type":"string"}]},{"type":"string"},{"type":"number"},{"type":"array","items":{"type":"boolean"}},{"anyOf":[{"type":"object","properties":{"entities":{"minItems":1,"type":"array","items":{"type":"object","properties":{"name_or_address":{"type":"string","description":"Account/Object name or ID. If specifying an account, use empty string '' for the default account. If it starts with '0x', it will be treated as an ID. Otherwise, it will be treated as a name (max 64 bcs characters)."},"local_mark_first":{"description":"Whether to prioritize local marks, if true, prioritize local marks, otherwise prioritize global marks","type":"boolean"}},"additionalProperties":false,"description":"Account or address lookup object. Use this to specify which account to use for an operation. EXAMPLE: { name_or_address: 'testor2' } - looks up account by name; EXAMPLE: { name_or_address: '0x1234...' } - uses address directly; If name_or_address is empty string '', uses the default local account. name_or_address is REQUIRED — {} resolves to nothing useful and is rejected."}},"check_all_founded":{"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","check_all_founded"],"additionalProperties":false,"description":"Used to batch find account or object IDs by name"},{"type":"array","items":{"type":"string"}}]},{"type":"array","items":{"type":"string"}},{"type":"array","items":{"type":"number"}},{"type":"array","items":{"type":"array","items":{"type":"number"}}}]},"name":{"default":"","description":"Data name identifier. MAX 64 BCS characters (Chinese chars count as 3-4 BCS bytes each). Use short identifiers like 'order_id', 'delivery_node'. Put longer descriptions in the Guard's 'description' field, NOT here.","type":"string"},"object_type":{"description":"OUTPUT-ONLY (query side): Object type when value_type is Address and represents a specific object. Auto-derived by the system — DO NOT set this field at Guard creation.","type":"string","enum":["Permission","Repository","Arb","Arbitration","Service","Machine","Order","Progress","Payment","Treasury","Guard","Demand","Passport","Allocation","Resource","Reward","Discount","EntityRegistrar","EntityLinker","Proof","WReceivedObject","Contact","TableItem_ProgressHistory","TableItem_PermissionPerm","TableItem_DemandPresenter","TableItem_MachineNode","TableItem_TreasuryHistory","TableItem_RepositoryData","TableItem_RewardRecord","TableItem_EntityLinker","TableItem_AddressMark","TableItem_EntityRegistrar"]}},"required":["identifier","b_submission","value_type","name"],"additionalProperties":false,"description":"Guard table item (QUERY/OUTPUT form — includes auto-derived object_type field)"},"description":"User-submitted data matching the Guard's required fields. Relation: structure must match the Guard table's column definitions. Example: [{field:'delivery_proof', value:'Qm...'}] PROTOCOL SLOT 254: when the Guard table has identifier 254, submit the ORDER address bound to the operation (payment_info.for_object) — never the Progress/Machine object being advanced."}},"required":["guard","submission"],"additionalProperties":false,"description":"One Guard's submission data: the Guard to verify plus the user-provided data that satisfies its requirements."},"description":"User-submitted data for each Guard. Relation: one entry per Guard in the guard array; fill submission fields and resubmit via call_with_submission. SLOT COMPLETENESS (T8 az3-mn-261013): the submission array must cover EVERY b_submission slot in the Guard's table, not just one — a Guard whose table has multiple b_submission entries (e.g. slot 0 + slot 254) aborts on-chain with 'Submission ID not found' (abort 11) when any b_submission slot has no matching entry. Check the Guard's table (each entry with b_submission needs its identifier filled) and include ALL of them. PLACEMENT: this `submission` field is at the SAME level as `data` and `env` in the operation input — NOT inside `data.data`. Example structure: {tool:'onchain_operations', data:{operation_type:'order', data:{object:'my_order', progress:{...}}}, submission:{type:'submission', guard:[...], submission:[...]}}"}},"required":["type","guard","submission"],"additionalProperties":false,"description":"Guard verification required. The operation was blocked because one or more Guards require user-submitted data. Fill the submission array and resubmit. Semantic status is 'pending_input'."}},"required":["operation_type","data"],"additionalProperties":false}