Skip to main content
constructPartialSDK is the tree-shaken entry point. You pick which per-method construct* factories you care about, and the resulting SDK has only those methods on it. TypeScript infers the return type from your selection, so calls into unused modules don’t compile, and the bundler drops the unused code.

When to pick this

  • You’re shipping a browser bundle and every kilobyte counts.
  • You only use a small slice of the SDK, e.g. just getRate + approveToken, or just the Delta signing flow.
  • You want compile-time guarantees that your build doesn’t accidentally call a method you didn’t intend to ship.
If you use most of the SDK or run server-side, prefer Simple SDK or Full SDK.

Example: rates and approvals only

The smallest useful Partial SDK: read rates from the API, approve tokens for swaps.

Example: Delta signing only

A front-end that signs Delta orders but does no other reads or writes. The Delta constructors are exported bare from the package root:
Bundlers tree-shake whichever members you don’t reference, so this example pulls in only the constructors above.

Available constructors

Pass any combination of these. Methods on the resulting SDK match the names listed in Simple SDK → Available methods. All constructors are exported bare from the package root. The full list lives in src/index.ts.
Several constructors come in pairs. For example, constructBuildDeltaOrder + constructSignDeltaOrder + constructPostDeltaOrder, or constructSubmitDeltaOrder (which orchestrates all three). Use the orchestrator when you want one call; use the individual constructors when you need custom signing (hardware wallet, multisig, deferred submission).

Choose a variant

Side-by-side comparison of Simple, Full, and Partial.

Configure providers

Construct the fetcher and contract caller you’ll pass in.

Swaps → Delta

Delta order lifecycle, including the split build/sign/post flow.

Swaps → Market

Market-Swap walkthrough using individual constructors.
Last modified on June 14, 2026