The frontend boundary between UI and SYMMIO.
An SDK-first workspace: the libraries that make SYMMIO buildable, and the apps that prove they are.
SYMMIO is a hybrid clearing house for permissionless derivatives. The product behind it is built by many vendors with different architectures: contracts, solvers, subgraphs, oracles, price feeds, and notification services. Building a UI directly against that raw surface means learning all of it.
This repo exists so you don't have to. It ships an SDK that hides the complexity behind an API that is simple, correct, and reliable — plus the apps we build on top of it, which are the proof that the SDK is good enough to build real products with.
Looking for how to use the SDK? Everything — install, config, and every action, hook, and type — lives on the documentation site.
Two SDK layers, and a strict rule about what goes where: trading-core never imports a framework, so a framework layer can be added without rewriting it.
| Package | Version | Description |
|---|---|---|
@symmio/trading-core |
 |
Framework-agnostic SDK. Contract reads/writes via viem, solver REST, subgraph GraphQL, Muon attestations, price and notification streams, and the calculations that turn raw protocol data into typed results. |
@symmio/trading-react |
 |
React adapter. A hook and a provider for everything in core, with caching and invalidation wired through TanStack Query and wagmi. |
@symmio/utils |
 |
Framework-agnostic helpers: amount formatting, address shortening, a Decimal.js bridge. |
@symmio/session-key |
 |
Local EVM session keys — generate, persist through an injected storage interface, and sign without a wallet prompt. |
Not part of the SDK surface — SDK consumers never need these:
| Package | Version | Description |
|---|---|---|
@symmio/ui |
private | Design system and primitives for our own apps. |
@symmio/eslint-config |
 |
Shared ESLint flat configs. |
@symmio/typescript-config |
 |
Shared TypeScript configs. |
Chain support: HyperEVM mainnet (999) is the only chain that ships today. The plumbing is chain-keyed throughout, so adding one is a registry entry rather than a refactor.
Requires Node ≥ 20 and pnpm (the version in packageManager; corepack enable picks it up). This repo is pnpm-only — npm install or yarn here will produce a broken tree.
pnpm install
pnpm dev # every app, via TurborepoAll commands run from the repo root and fan out through Turborepo:
| Command | What it does |
|---|---|
pnpm dev |
Run every app's dev server (and the packages' watch builds). |
pnpm build |
Build everything in dependency order. |
pnpm lint |
ESLint, zero-warnings. |
pnpm check-types |
tsc --noEmit across the workspace. |
pnpm test |
Unit tests (Vitest). Integration tests stay gated behind SYMM_RUN_INTEGRATION and a funded key. |
pnpm format |
Prettier. |
pnpm verify-packages |
Verify the published shape of the packages — see below. |
Scope any of them to one package with pnpm --filter @symmio/trading-core test, or run it from that package's directory.
Lefthook runs Prettier, ESLint, and type-checks pre-commit, and commitlint on the message — commits follow Conventional Commits.
pnpm lint and pnpm check-types only ever exercise workspace symlinks under bundler resolution, so they cannot catch a broken subpath export, an unresolvable .d.ts, or a file missing from the tarball. pnpm verify-packages packs each package, lints the tarball with publint and @arethetypeswrong/cli, then installs it into a consumer outside the workspace and type-checks it under strict nodenext before importing it at runtime. CI runs this on every PR.
Versioning is Changesets-driven. Add one with pnpm changeset in any PR that changes a published package; merging to main opens or refreshes the "Version Packages" PR, and merging that publishes to npm.
Read AGENTS.md first — it is the contract for this repo, for humans and AI coding agents alike, and it covers the hard rules (pnpm only, TypeScript only, core stays framework-agnostic), the file and naming conventions, and the Design Proposal Gate: non-trivial changes to trading-core or trading-react get a written design proposal and explicit approval before any implementation code is written. Several packages add their own AGENTS.md that applies on top of the root one.
Keep increments small and reviewable — one SDK slice per PR.
MIT © SYMMIO