Choose a Velora SDK variant

The SDK ships three constructors that wrap the same per-method construct* primitives. They differ in how much of the SDK comes pre-wired and what the resulting API surface looks like.

At a glance

	Simple	Full	Partial
Constructor	`constructSimpleSDK`	`constructFullSDK`	`constructPartialSDK`
API shape	Namespaced: `sdk.swap.getRate(...)`, `sdk.delta.submitDeltaOrder(...)`, `sdk.quote.getQuote(...)`	Same namespaces, typed against your transaction-response generic (`sdk.swap.`, `sdk.delta.`)	Flat: `sdk.getRate(...)`, `sdk.approveToken(...)`. Whatever you import is what you get.
Bundle size	Includes every module	Includes every module	Tree-shaken to the constructors you import
Provider wiring	Pass `{ axios }` or `{ fetch }` and (optionally) `providerOptions`; SDK builds the fetcher and contract caller for you	You build `fetcher` and `contractCaller` and pass them in	You build `fetcher` and `contractCaller` and pass them in
`<TxResponse>` generic	Returns `TxHash` (string) for write calls	You choose: viem `Hex`, `ethers.ContractTransaction`, etc.	Inherits from the `contractCaller` you pass
Best for	Quickstarts, server-side scripts, integrators who want one import	Apps that use most modules and want typed transaction responses	Bundle-size-sensitive front-ends

Pick by use case

“I just want a quote and a swap.” Use the Simple SDK: one constructor, ready to call.
“I have a Node service that does Delta orders, Market Swaps, and price polling.” Use the Full SDK. You get namespaced access plus a typed <TxResponse> so your code knows what approveToken returns.
“I’m shipping a front-end and only sign Delta orders.” Use the Partial SDK: import constructBuildDeltaOrder, constructSignDeltaOrder, constructPostDeltaOrder and tree-shake the rest.
“I want a custom HTTP client (got, undici, superagent…).” All three variants accept a custom fetcher. See Configure providers.

What stays the same

Every variant ultimately calls the same construct* factories under @velora-dex/sdk src/methods/. That means:

Same method signatures across variants: getRate, buildDeltaOrder, submitDeltaOrder, etc. behave identically.
Same partner-fee handling. See Monetize.
Same retries, errors, and FetcherError semantics regardless of constructor.

Simple SDK

constructSimpleSDK: one constructor, sensible defaults.

Full SDK

constructFullSDK. Namespaced, with typed transaction responses.

Partial SDK

constructPartialSDK: cherry-pick constructors, tree-shake the rest.

​At a glance

​Pick by use case

​What stays the same

​Related pages