> ## Documentation Index > Fetch the complete documentation index at: https://docs.kuru.io/llms.txt > Use this file to discover all available pages before exploring further. # Operational methods > Opt-in, simulation-first Relay methods for maintenance, FOK, and stored instructions. Relay's nine operational methods are **slow, opt-in routes**, not the low-latency batch or packed-slot trading path. A method's presence in this reference does not mean it is enabled on every deployment or market. Check the selected deployment's capabilities before integrating. Wallet methods that specify a market require that market to enable the method; AccountCore methods have no market scope. A code merge or testnet smoke test does not establish mainnet availability. Before signer FIFO insertion, Relay validates the typed payload and signature where applicable, then calls `eth_estimateGas` against `latest` using the actual sponsor as `from`, the canonical wallet or AccountCore target, exact calldata, zero value, and an empty access list. It supplies `estimate + ceil(estimate / 5)` gas (at least 20% headroom) and rejects estimates above the configured method cap. It never silently truncates gas or substitutes a guessed estimate. These methods do not use FastLane, exchange-state enrichment, access-list generation, or heuristic gas models. The existing fast batch/packed paths are unchanged; latency-sensitive FOK can use `wallet.execute_batch`. Simulation adds RPC latency and can become stale before inclusion. On a WebSocket, an operational request also occupies a public worker and its ordered nonce handoff can delay later trading requests on that same connection. Use REST or a separate WebSocket connection for operational work. A `BROADCAST` response only means Relay scheduled asynchronous broadcast, not RPC acceptance or execution. REST callers must inspect the receipt and events/state; WebSocket callers receive automatic terminal outcomes but must still reconcile the intended action. Operational routes require a pre-existing trading-wallet delegation. They accept neither an atomic `authorization7702` tuple nor a `makerSlotsPrimed` hint. Complete [onboarding](/sdk/relay-onboarding) first. Do not rely on every incorrect delegation state being rejected before broadcast; verify delegation and the expected on-chain events/state yourself. ## Wallet methods | Method | Scope | Effect | | - | - | - | | [Cancel orders by ID](/api/relay/reference/execute-cancel-orders-by-id) | Signed account and market | Cancel 1–62 explicit order IDs | | [Cancel all](/api/relay/reference/execute-cancel-all) | Signed account and market | Cancel resting orders in that market | | [FOK swap](/api/relay/reference/execute-fok-swap) | Signed account and market | Execute full base quantity or revert | | [Store FOK trigger](/api/relay/reference/create-fok-swap-trigger) | Signed account and market | Persist the condition hash and FOK instruction only | | [Store TWAP](/api/relay/reference/create-twap) | Signed account and market | Persist a schedule only; no slices run | | [Cancel TWAP](/api/relay/reference/cancel-twap) | Signed account and stored TWAP | Cancel a signed stored instruction | | [Finalize TWAP](/api/relay/reference/finalize-twap) | Authenticated wallet and stored TWAP | Mark expired instruction finished; no execution | FOK trigger and TWAP creation are **storage only**. Relay does not monitor conditions, schedule slices, or run a keeper for these methods. It checks the FOK condition schema/hash and discards the supplied condition bytes, so retain them yourself. `finalize_twap` only persists expiry/skipped/finished state; it does not execute slices, cancel orders, or transfer funds. Automated triggers, including take-profit/stop-loss (TP/SL), and TWAP execution are **not implemented** as live features; they remain work in progress. These opt-in endpoints can store instructions where enabled, but storing one will not trigger an order or execute TWAP slices. Wallet signatures use EIP-712 domain `KuruTradingWallet`, version `2`, with the delegated EOA as verifying contract. The wallet header's `authNonce` is the AccountCore authorization epoch; its immediate or one-shot `nonce` is separate. Read the method page for the exact type string and nonce namespace. For cancellation, builder and builder fee must both be zero. ## AccountCore methods | Method | Signed authority | Effect | | - | - | - | | [Revoke signer](/api/relay/reference/revoke-account-signer) | Root owner or live ADMIN | Revoke signer and advance the root authorization epoch | | [Create subaccount](/api/relay/reference/create-subaccount) | Root owner or live ADMIN/TRADE | Create the next child sequence; epoch unchanged | The frontend trading wallet supplies the Relay JWT, but **the JWT identity does not need to equal the AccountCore `authorizer`, owner/root owner, or signer being revoked**. JWT identity controls service admission and sponsorship only. A separate owner or authorized EOA signs the AccountCore EIP-712 request using domain `KuruAccountCore`, version `1`, and the configured AccountCore proxy as verifying contract. These two methods accept canonical 65-byte or ERC-2098 64-byte EOA signatures; they do not add ERC-1271 support. The older signer-grant onboarding route keeps its distinct JWT-to-new-signer binding. Read `nonce` or `authNonce` from AccountCore: these are uint256 root authorization epochs, **not** millisecond trading nonces. For subaccount creation, use the next nonzero uint16 `subaccountSeq`, wait for inclusion, then read again before creating another child. A pending creation is not assumed to have changed `latest` state for the next simulation. ## Immediate errors and recovery * `OPERATIONAL_SIMULATION_REVERTED` (HTTP 400) means the exact simulation explicitly reverted. No transaction was signed or broadcast; correct the state or request before retrying. * `POLICY_DECLINED` (HTTP 403) can mean the buffered estimate exceeded the method's gas cap. No gas amount is silently clipped. * `GAS_POLICY_UNAVAILABLE` (HTTP 503, retryable) covers estimator saturation, timeouts, malformed estimates, and transient provider failures. A generic RPC failure is not a proven contract revert. * `INTERNAL_DEADLINE_EXCEEDED` (HTTP 504) can mean the caller's deadline elapsed during estimation. Reconcile any ambiguous submission before retrying. After a successful `BROADCAST`, use the usual [Relay outcomes and recovery](/api/relay/errors) rules. A simulation is not an execution guarantee: balances, orders, permissions, and nonce state may change before inclusion. Do not blindly resubmit a FOK or account-administration operation after a lost reply. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.