Relayable writes

The transparent gasless execution mode: existing write actions relay through the GaslessQ service with zero signature or behavior change. When active, the SDK signs the write’s own calldata as an InstantLayer operation, relays it, waits for the relayer’s broadcast, and returns the transaction hash — so receipt-waiting and every hook’s invalidation pipeline run unchanged.

// Per call…
await initiateWithdraw(config, { account, parts, gasless: true });
 
// …or globally, in the chain's gasless block:
gasless: { url, protocolInstance, gaslessLayerAddress, execution: { mode: "gasless", fallback: "wallet" } }

Which writes relay

Relayability is a compile-time truth: only these actions accept the gasless parameter. All selectors derive from the shipped v0.8.6 ABIs at module load.

Writes that are not in this table (approveCollateral, requestToRegisterAffiliate, cancelRegistration, …) never relay — under the config mode they silently keep the wallet path (that is the no-behavior-change promise), and they do not accept gasless at all.

The dispatch, in order

1. Resolve the mode: per-call gasless overrides execution.mode; the default is "wallet" (zero overhead).
2. Cross-check the config once per chain: the GaslessLayer’s instantLayer() must equal the chain’s instantLayerAddress, or the relay refuses with GASLESS_CONFIG_INCOHERENT — a mismatched pairing would produce signatures the gateway rejects.
3. Read the nonce and build the operations, serialized per nonce stream so concurrent relays cannot collide.
4. Quote the batch (getGaslessFeeQuote, every operation on wallet 0) before any signature prompt (preflightFee, default on). The quote carries placeholder signatures, so it needs no prompt of its own:
   • an exhausted daily free quota stops with GASLESS_FREE_QUOTA_EXHAUSTED, or takes the wallet path under fallback: "wallet", since nothing was signed;
   • a quote the contract rejects stops with GASLESS_FEE_QUOTE_REVERTED, and a GaslessLayer without the multi-wallet interface with GASLESS_LAYER_INTERFACE_UNSUPPORTED. Neither falls back, because the relay would fail the same way;
   • a quote read that fails for transport reasons does not block. Signing proceeds, and the relayer’s simulation decides.
5. Sign. A user’s signature rejection propagates — there is no wallet fallback for “the user said no”.
6. Submit, then wait for broadcast (bounded by broadcastTimeoutMs) and return the hash. Pre-acceptance failures follow the fallback policy; post-202 there is no fallback — see Errors & fallback.

Lifecycle observers get every accepted request through execution.onEvent (accepted / broadcast / terminal) — persist it there so in-flight relays survive reloads. The accepted event is a GaslessAcceptedRequest, and carries everything needed to resume the workflow, not just the id:

execution: {
  mode: "gasless",
  onEvent: (event) => {
    if (event.type !== "accepted") return;
    // { requestId, service, chainId, protocolInstance, idempotencyKey, operationType, owner, walletIds }
    persist(event);
  },
}

owner is the billing sub-account’s owner, which is also the userAddress the request is tracked under — not the signing key, since a session key owns nothing. walletIds is one id per operation, always 0n here: transparent writes are ordinary InstantLayer operations. Store the row under (environment, protocolInstance, service, requestId); a bare request id is not enough context to reconcile it later.

Batch calls

Every write in the table above can also join a gasless batch, several of them in one atomic request, by name — the SDK already holds each one’s ABI, so { functionName: "editAccountName", args: [account, name] } is a complete call. GASLESS_RELAYABLE_FUNCTIONS maps each name to its ABI item, which is also the list to offer in a UI:

import { GASLESS_RELAYABLE_FUNCTIONS } from "@symmio/trading-core";
import { formatAbiItem } from "viem/utils";
 
for (const item of GASLESS_RELAYABLE_FUNCTIONS.values()) {
  console.log(formatAbiItem(item, { includeName: true })); // "allocate(uint256 amount)", …
}

A batch names the contract functions, not the SDK actions that wrap them — forceCloseAuto relays forceClosePosition, for example — and the batch’s account is each call’s billing account: the virtual account’s parent for addMargin and removeMargin.

Session keys

Two lists, deliberately not the same one.

GASLESS_RELAYABLE_SELECTORS is what the relayer will carry — this whole table, including grantDelegation, which is why onboarding a session key needs no gas either. isGaslessRelayableSelector(selector) answers for one selector.

getSessionKeySelectors is what you grant a key. Prefer it over the raw constants: it unions gasless account management with the instant-trade lifecycle and resolves the chain’s contracts generation, so a key comes out able to both trade and manage the account. GASLESS_SESSION_KEY_SELECTORS is the account-management half on its own, enumerated by hand rather than derived from the table above: the cancel, withdraw-completion, margin and operational-fee writes. There is no trading write among them — trading is delegated through the instant-trade selectors, which the relayer does not carry at all.

Relayability and delegability are different questions — the first asks whether the relayer will carry a write, the second whether a browser-held key may sign it unattended — so a write becoming relayable never widens a session key on its own.

GASLESS_SESSION_KEY_WITHDRAW_SELECTORS holds initiateWithdraw alone, and is not in the default set. Request it with getSessionKeySelectors(config, { withdraw: true }) only for a key that must run withdrawals unattended: it takes a caller-supplied receiver, and delegation is selector-and-expiry only — no argument scope exists — so a key holding it can move the sub-account’s collateral anywhere. finalizeWithdrawRequest and requestCancelWithdraw stay in the default set precisely because neither takes a receiver: both only complete or cancel a withdrawal the owner already addressed.

Deliberately excluded, though relayable: createSubAccounts, deleteSubAccount, editAccountName, depositForAccount, depositAndAllocateForAccount and forceClosePosition. The two deposits pull the owner’s ERC-20 collateral, which a session key has no allowance for, and createSubAccounts carries no onlyAccountOwner guard, so the Instant Layer’s scope never confines it. The rest relay without gas but stay owner-signed as a product decision — grant them explicitly if you want them.

Grant them with grantDelegation and gasless: true; the grant relays like any other write.

Per-call options