Skip to main content
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 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

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

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 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.