Installation#

The launch surface is intentionally one SDK family per language.

These commands run from the repository root in an authorized checkout. Source availability and package registry publication are separate: this checkout's release metadata does not establish a published package you can install from a registry. See source availability and licenses.

TypeScript#

pnpm --filter @seesaw/core build
pnpm --filter @seesaw/reclaim test

@seesaw/core depends on modular @solana/* packages and exports generated instructions, PDA helpers, account readers, API clients, and streams. @seesaw/reclaim contains Reclaim proof-wire and external-market canonicalization helpers.

The exact versions are pinned by the workspace lockfile; the core package does not declare a dependency on the monolithic @solana/kit package.

For a repository checkout:

pnpm install --frozen-lockfile
pnpm --filter @seesaw/client-gen generate:check
pnpm --filter @seesaw/core test
pnpm --filter @seesaw/reclaim test

Do not add @solana/web3.js or a second Seesaw SDK family. Wallet and RPC libraries are application choices; builders return Kit instructions and never sign or submit transactions.

Python#

python -m venv .venv
source .venv/bin/activate
pip install -e packages/sdk-python

The Python SDK follows the same generated instruction, PDA, account-layout, and test-vector contract as the TypeScript and Rust clients.

Rust#

[dependencies]
seesaw-sdk = { path = "packages/sdk-rust" }

Use the pinned workspace toolchain and run cargo test --locked before shipping. The Rust SDK's account decoders and instruction vectors are checked against the canonical program source.

Release checks#

The release inventory is authoritative in scripts/sdk-release-packages.json and scripts/sdk-release-docs.json. Run:

pnpm test:sdk-release

The gate verifies Changesets RC coherence, package versions, registry provenance, clean-install evidence, and the canonical package list.

Reclaim service#

Use Reclaim integration when the source market originated elsewhere. The service resolves through the registered resolver; it is not a second native instruction family or a second SDK surface.