@vedatech/svm-sdk

@vedatech/svm-sdk

TypeScript SDK for integrating deposits, withdrawals, and account data for Veda vaults on Solana. The SDK supports browser and Node.js applications, uses @solana/kit, accepts deployment-specific program addresses at runtime, and does not manage private keys.

Requirements

• Node.js 24 or newer
• @solana/kit 7
• An RPC endpoint for the target cluster
• Program and vault addresses supplied by Veda
• A compatible transaction signer for methods that submit transactions

Installation

pnpm add @vedatech/svm-sdk @solana/kit

Create a client

Create one client for each deployment and cluster. Program addresses are always explicit; the SDK does not include default addresses or infer one program from another.

import { createVedaClient } from "@vedatech/svm-sdk";

const client = createVedaClient({
  rpc,
  rpcSubscriptions,
  deployment: {
    vaultProgramAddress,
    queueProgramAddress, // Optional for deployments without withdrawal queues.
    hookProgramAddress,
    label: "customer-devnet", // Optional identifier used in reports and logs.
  },
  signer, // Optional default TransactionSigner.
  commitment: "confirmed",
});

const vault = client.vault(vaultAddress);

The SDK derives each vault, queue, hook, and request PDA with the program address configured for that deployment. This allows integrations to support multiple customer-specific deployments without hard-coded program IDs.

Validate a deployment

Validate a deployment before enabling user transactions:

const deploymentReport = await client.validateDeployment();
const vaultReport = await vault.validateCompatibility();

validateDeployment() checks that every configured program exists, is executable, and uses the expected Solana upgradeable loader.

validateCompatibility() additionally verifies:

• Vault ownership and PDA derivation
• Share-mint derivation and transfer-hook configuration
• Hook configuration and extra-account-metadata PDAs
• Queue ownership and its relationship to the vault program, vault ID, and share mint
• The queue's immutable Token-2022 share account
• Required queue permissions for supported vault configurations

Pass { requireQueue: true } when queue support is required. Otherwise, a deployment without a queue is reported as a supported capability state.

Compatibility reports include the deployment label, configured programs, program loaders, vault ID, share mint, optional queue state, and available deposit and withdrawal capabilities. Package releases are generated from a pinned Veda SVM ABI recorded in programs.lock.json.

Read vault and account data

const state = await vault.getState();
const assets = await vault.listAssets();
const sharePrice = await vault.getSharePrice();
const position = await vault.getUserPosition(userAddress);
const options = await vault.getWithdrawalOptions();

const queue = await vault.getQueueState();
const queueAsset = await vault.getQueueWithdrawalAsset(usdcMint);
const requests = await vault.listOpenWithdrawalRequests(userAddress);
const request = await vault.getWithdrawalRequest(requestAddress);

Instant and queued withdrawals are reported independently because both may be available for the same vault. The SDK does not automatically choose a withdrawal route.

Withdrawal request status is reported as:

• pending
• fulfillable
• expiredCancelable
• closedOrUnknown when the request account no longer exists

Fulfillment and cancellation close the request account. Historical fulfilled or cancelled status requires transaction indexing outside the SDK.

Preview transactions

Preview methods apply the vault's current accounting, fees, limits, and oracle configuration without submitting a transaction:

const depositQuote = await vault.previewDeposit({
  asset: { kind: "mint", address: usdcMint },
  amount: 1_000_000n,
});

const instantQuote = await vault.previewWithdraw({
  asset: usdcMint,
  shares: 1_000_000n,
});

const queuedQuote = await vault.previewRequestWithdrawal({
  asset: usdcMint,
  shares: 1_000_000n,
  discountBps: 50,
  deadlineSeconds: 86_400,
});

Token quantities use atomic bigint values. Use parseTokenAmount() and formatTokenAmount() at application boundaries. Quotes include the RPC slot, block time, and commitment used for the calculation.

Build, prepare, or execute transactions

Each supported action provides three integration modes:

• buildX returns the ordered instructions.
• prepareX returns an unsigned serialized transaction, blockhash lifetime, required signer addresses, and simulation result.
• The direct action signs, submits, and confirms when a signer is available. Without a signer, it returns a prepared transaction.

const input = {
  owner: userAddress,
  asset: { kind: "mint", address: usdcMint },
  amount: 1_000_000n,
  protection: { slippageBps: 25 },
};

const plan = await vault.buildDeposit(input);
const prepared = await vault.prepareDeposit(input);

console.log(prepared.requiredSignerAddresses);
console.log(prepared.blockhash, prepared.lastValidBlockHeight);
console.log(prepared.simulation);

const receipt = await vault.deposit({ ...input, signer });

The same modes are available for:

• buildDeposit, prepareDeposit, deposit
• buildWithdraw, prepareWithdraw, withdraw
• buildRequestWithdrawal, prepareRequestWithdrawal, requestWithdrawal
• buildCancelWithdrawal, prepareCancelWithdrawal, cancelWithdrawal

Deposit and instant-withdraw inputs require either minAmountOut or slippageBps; the SDK does not apply an implicit slippage tolerance. Required user token accounts and queue user state are initialized when needed. Deployment-owned queue accounts must already be configured.

Compliance approvals

When a vault requires a compliance approval, obtain it from the configured compliance service and pass it to the deposit:

const approval = {
  authority: complianceAuthority,
  user: userAddress,
  vault: vaultAddress,
  expiration: 1_800_000_000n,
  signature: signatureBytes,
};

const plan = await vault.buildDeposit({
  signer,
  asset: { kind: "native" },
  amount: 1_000_000_000n,
  protection: { minAmountOut: 990_000n },
  complianceApproval: approval,
});

The SDK validates the approval's user, vault, authority, expiration, and signature length. The Ed25519 verification instruction is placed immediately before the deposit instruction. extendInstructionPlan() preserves that required ordering when an application adds instructions.

Errors and simulation results

Local validation failures throw typed VedaSdkError subclasses with stable SDK error codes and structured details.

Simulation results decode configured vault, queue, and hook program errors into simulation.programError. Other RPC or runtime failures remain available through simulation.error and the simulation logs.

Supported assets and networks

The SDK supports:

• Native SOL
• SPL tokens
• Token-2022 assets with zero current and scheduled transfer fees
• Solana devnet and mainnet deployments supplied by Veda

Share accounts use Token-2022's immutable-owner extension. Assets requiring custom CPI-digest execution are not supported by the public API. Validation and previews account for pause state, compliance requirements, asset enablement, deposit caps, share locks, queue limits, fee liabilities, fee remainders, and exact integer rounding.

Oracle addresses are read from vault asset configuration. The SDK validates Pyth feed addresses and receiver ownership, as well as Switchboard feed ownership. Stale, mismatched, or invalid oracle data produces an error.

Integration responsibilities

Applications integrating the SDK are responsible for:

• Supplying deployment addresses approved for the target environment
• Providing RPC connectivity
• Managing authentication and transaction signers
• Obtaining compliance approvals when required
• Applying application-level idempotency and transaction tracking
• Indexing historical withdrawal outcomes when needed

The public API does not include share transfers, queue solver fulfillment, vault discovery, privileged authority or strategist operations, custom CPI-digest assets, React bindings, custody, or hosted infrastructure.