Velora SDK v10 moves Delta order building to the server

Three construction modes, and the smallest one is 10KB gzipped

The SDK offers a range of ways to instantiate itself, from a single call to a fully composable arrangement where you import only the functions you use. The headline properties are named in the README: versatility, because it works with web3 or ethers without a direct dependency on either and also with viem, which it uses internally for its own utilities; canonical, described as bringing only the functions you actually need; and lightweight, at 10KB gzipped for the minimal variant. The package metadata backs that up with a size-limit configuration capping dist/sdk.cjs.production.min.js and dist/sdk.esm.js at 25 KB each, with viem excluded from the measurement because it is treated as an external dependency. The package is published as @velora-dex/sdk, and its files field ships dist, src and docs/DELTA.md, so the source is in the tarball and the Delta documentation travels with it. The install command is:

pnpm add @velora-dex/sdk

The simple SDK is a chainId, a fetcher and an optional API version

The quickest way in is constructSimpleSDK, which takes a chainId and either axios or window.fetch, or any alternative fetch implementation, plus an optional version parameter of '5' or '6.2' that selects which API version the SDK talks to. With only a fetcher, the resulting object can use every method that queries the API. The README's own example shows the minimal construction first and the versioned variant second:

import { constructSimpleSDK } from '@velora-dex/sdk';
import axios from 'axios';

// construct minimal SDK with fetcher only
const minSDK = constructSimpleSDK({ chainId: 1, axios });
// or
const minSDK = constructSimpleSDK({
  chainId: 1,
  fetch: window.fetch,
  version: '5',
});

The optional second parameter is providerOptions, and supplying it is what upgrades the object from a read-only client into one that can approve tokens, sign orders and submit transactions. That split is the single most important structural decision in the SDK, because it separates the read path from the write path at construction time rather than at call time, and it means a server-side integration that only quotes prices never has to load a signer or a contract caller at all.

providerOptions is where the library differences get absorbed

Because there is no direct dependency on web3, ethers or viem, the SDK takes the objects it needs from you and adapts them. The README shows four shapes for providerOptions. Ethers version 5 uses ethersProviderOrSigner plus EthersContract and an account, while ethers version 6 uses the separate keys ethersV6ProviderOrSigner and EthersV6Contract, so the two major versions of ethers are not interchangeable without renaming the keys. The viem form passes a viemClient, the kind made with createWalletClient(), and the web3 form passes a web3 instance. The README shows the ethers v5 and v6 variants side by side, and then approves a token through the SDK and waits for the transaction:

// with ethers@5
const providerOptionsEtherV5 = {
  ethersProviderOrSigner: provider, // JsonRpcProvider
  EthersContract: ethers.Contract,
  account: senderAddress,
};

// with ethers@6
const providerOptionsEtherV6 = {
  ethersV6ProviderOrSigner: provider, // JsonRpcProvider
  EthersV6Contract: ethers.Contract,
  account: senderAddress,
};

Because the SDK never imports these libraries, the version skew between your ethers and the SDK is your problem to manage. The keys are explicit about which major version they expect, which is helpful, but it also means a project on ethers v5 cannot move to v6 by upgrading the SDK alone.

The full SDK wires a fetcher to a contract caller, the partial SDK does not

constructFullSDK is the middle setting, and the shape of it explains the naming. You build a contract caller with constructEthersContractCaller, passing the provider or signer and the contract class along with the account, and the README notes that constructViemContractCaller and constructWeb3ContractCaller are the alternatives. You build a fetcher with constructAxiosFetcher, with constructFetchFetcher as the other option, and pass both into the SDK along with a chainId:

const contractCaller = constructEthersContractCaller(
  {
    ethersProviderOrSigner: signer,
    EthersContract: ethers.Contract,
  },
  account
); // alternatively constructViemContractCaller or constructWeb3ContractCaller
const fetcher = constructAxiosFetcher(axios); // alternatively constructFetchFetcher

const sdk = constructFullSDK({
  chainId: 1,
  fetcher,
  contractCaller,
});

The partial SDK is the bundle-size option and works differently. Instead of assembling a full object, you pass the functions themselves, so constructPartialSDK with constructGetRate and constructGetBalances gives you an sdk with only getRate and getAllowances on it, and the read paths are called directly on the result. The trade is that the partial SDK is for reads, since the contract-calling machinery that write operations need is exactly what you have left out.

v10 rebuilt Delta around server-built orders and one signer

The v10 line is a breaking release over v9.x, and the Delta changes are the reason to read it. The first is that you no longer build the order locally. You pass the quoted route and side, coming from getDeltaPrice or quote.delta, to buildDeltaOrder or submitDeltaOrder, and the server returns the typed data to sign. You no longer pass local amounts. The second is one signer for every family: signDeltaOrder now signs Standard, External, TWAP Sell and TWAP Buy orders, and the per-family signExternalDeltaOrder and signTWAPDeltaOrder have been removed. The third is a type change, with getDeltaPrice returning a route-based DeltaPrice carrying a route and alternatives, while the old BridgePrice type is gone because cross-chain handling moved into the route through destChainId. All Delta endpoints now sit under the /v2/delta/... prefix.

Legacy limit orders are gone, and the OTC methods were renamed

The removals are the part of v10 that breaks running code, and there are two separate cuts. The deprecated legacy, non-Delta limit-order methods are gone, and the OTC functionality that sat alongside them survives under a new name: sdk.limitOrders.* becomes sdk.otcOrders.*, and the constructors are renamed accordingly to constructBuildOTCOrder, constructSignOTCOrder, constructPostOTCOrder, constructCancelOTCOrder, constructGetOTCOrders, constructApproveTokenForOTCOrder, constructFillOTCOrder and constructSubmitOTCOrder. Separately, the deprecated NFT-orders feature has been removed outright, so sdk.nftOrders.* and every construct*NFTOrder* export no longer exist. The renaming pattern is the one to watch in a diff, because a limitOrders call site that happened to be doing OTC work still needs renaming even though the name did not mention OTC before.

The repository is a pnpm monorepo with typedoc, size-limit and hardhat

The tooling in the repository explains how the SDK is built and checked. The package name is @velora-dex/sdk at version 11.0.1, the entry points are dist/index.js for CommonJS and dist/sdk.esm.js for modules with typings at dist/index.d.ts, and the engines field requires node 22 or newer. The scripts section is built around dts-cli: build and prepare run dts build, lint runs dts lint, test runs dts test, and start runs dts watch. There is a size-limit script and an analyze script that runs size-limit with the --why flag to explain the bundle composition. Documentation is generated by typedoc through the docs scripts, which produce both HTML and Markdown output, and a husky pre-commit hook runs dts lint --fix. A pnpm-lock.yaml and a pnpm-workspace.yaml are present, and hardhat.config.ts, jest.config.js and the apiary.apib file at the root indicate the contract and test side of the project.

Editorial conclusion

Velora SDK v10 suits a team building a DEX aggregator integration on the Velora API that wants a small, tree-shakeable client and a single Delta signing path, and the v10 upgrade suits a team that has to follow the API rather than stay on the older line. It does not suit a codebase still calling sdk.limitOrders or sdk.nftOrders, since those methods were removed rather than deprecated, and it does not suit a project that needs to build Delta orders locally, because that capability is gone. Before adopting, read the Delta migration notes shipped as docs/DELTA.md, check the Node requirement of 22 or newer, and confirm which v9 call sites you are replacing, given that the last push to the repository was on 2026-10-06.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. VeloraDEX/sdk on GitHub