Skip to Content
Symmio Trading-SDK — the SDK surface for builders on Arbitrum
CoreABI fragments

ABI fragments

Raw viem-style Abi arrays for the SYMMIO contracts, for consumers who call viem directly (bypassing the SDK’s typed actions). Use these as an escape hatch — the typed actions are recommended for everything the SDK already covers.

Import

import { accountLayerAbi, gaslessLayerAbi, gaslessWalletAbi, instantLayerAbi, symmioAbi } from "@symmio/trading-core";

Each is a readonly Abi array exported straight from the versioned src/symmio-contracts/abi/v0.8.6/ files.

Available fragments

The shipped ABIs target v0.8.6, sourced from perps-core at revision 3e25e6e. symmioAbi and accountLayerAbi contain the complete source arrays. instantLayerAbi contains the three delegation methods used by the SDK: delegations, grantDelegation, and isDelegationActive; these entries also match that revision.

Compatibility changes

Direct ABI consumers should account for these changes from the previous SDK snapshot:

ContractChange
SYMMIOstartRestatement now requires symbolId and expectedLiquidationStartNonce. Use this two-argument signature in place of the old one-argument call.
SYMMIORestatementPreparationCompleted adds a phase (uint8) event argument.
SYMMIOgetSymbolAdjustment adds pendingQuoteIdCutoff and fundingSettlementRequired to its returned tuple.
SYMMIOUse pausePartyBOpenPositionsFor(partyB) or unpausePartyBOpenPositionsFor(partyB) in place of setPartyBOpenPositionsPaused(partyB, status).
AccountLayerThe ABI includes timelock setup, approval, scheduling, execution, and read methods, plus their events and errors.

For contract behavior, see the matching symbol-adjustment documentation , admin-role changes , and AccountLayer timelocks . A raw ABI entry does not imply an SDK action or React hook exists for that method.

Every array is the complete source ABI (constructor, errors, events and functions), never a subset trimmed to what the SDK wraps, so viem can decode any revert or event these contracts emit.

GaslessLayer and GaslessWallet provenance

The gasless ABIs changed within the version_0.8.6 branch, so they are pinned to perps-core commit b63ee55e instead of the moving branch. That commit is the multi-wallet generation: wallets are identified by (owner, walletId), the old single-wallet overloads are gone, and the fee quote is previewFeeQuote.

Use these ABIs only against a GaslessLayer that runs the multi-wallet interface. They were verified by read-only calls against the staging proxy 0x386EF97D913acf02B3C9452da4Cd4aaEc82eFBca. The production proxy 0x8347953D80037b8d82827246f37EC7442AD188B4 has not been upgraded yet: every multi-wallet signature reverts there with empty data, so it is unsupported until the vendor upgrades it.

Decode gasless settlement events with gaslessLayerAbi. gaslessWalletAbi holds no gateway events.

import { parseEventLogs } from "viem"; import { gaslessLayerAbi } from "@symmio/trading-core"; const events = parseEventLogs({ abi: gaslessLayerAbi, logs: receipt.logs });

Usage — viem readContract

import { createPublicClient, http } from "viem"; import { arbitrum } from "viem/chains"; import { accountLayerAbi } from "@symmio/trading-core"; const client = createPublicClient({ chain: arbitrum, transport: http() }); const result = await client.readContract({ address: "0x…", abi: accountLayerAbi, functionName: "getSubAccountsCountOfUser", args: [user], });

Usage — viem writeContract

import { walletClient } from "./client"; import { symmioAbi } from "@symmio/trading-core"; const hash = await walletClient.writeContract({ address: "0x…", abi: symmioAbi, functionName: "allocate", args: [amount], });

Pair with Config.getChainConfig(chainId).addresses (see Addresses) for the deployment-specific address.

When to reach for the ABI vs typed actions

Prefer the typed action when one exists:

  • Typed actions run through Config.getClient / getWalletClient, so chain switching and wallet routing already work.
  • They wrap responses in typed shapes (Quote, Market, LockedValues) with 18-decimal-wei bigint.
  • They surface SDK errors (SymmError / SymmApiError) instead of raw viem errors when the failure is config-level.

Reach for the ABI directly when:

  • The function isn’t wrapped by the SDK yet.
  • You want raw viem semantics (e.g. multicall batches, custom overrides).
  • You’re building diagnostics that need untouched ABI-level output.
Last updated on