svm venue: spl-token-swap-forks - Eco Docs

Solana venue integration spl-token-swap-forks under svm/venues/spl-token-swap-forks.

Generated from the type declarations shipped in @eco-incorp/sauce 0.99.4. Each entry shows the package authors’ JSDoc and declaration for this SDK version. For runtime compatibility and deployed addresses, see architecture and deployments.

`TOKEN_SWAP_V1_PROGRAM_ID`

Variable · sdk/dist/svm/venues/spl-token-swap-forks/index.d.ts Token Swap - the original solana-labs/solana-program-library deployment.

TOKEN_SWAP_V1_PROGRAM_ID: Address

`tokenSwapV1`

Variable · sdk/dist/svm/venues/spl-token-swap-forks/index.d.ts

tokenSwapV1: SplTokenSwapForkAdapter

`DEXLAB_PROGRAM_ID`

Variable · sdk/dist/svm/venues/spl-token-swap-forks/index.d.ts DexLab - GATED (see unresolvedGate above): a real-CPI probe against the live mainnet binary (a real SOL/USDC pool, 4KizLX56YSbTtc8NJQWDBz3iiwSTpJRHFUXAvB4v6MM3, dumped 2026-07-31) shows the deployed Swap instruction reads MORE than the standard spl-token-swap 10 (or 11, with the optional host-fee account) accounts - it still fails NotEnoughAccountKeys with 10 or 11 provided, and only clears that check at 14 (10 + 4 arbitrary dummy reads), at which point it fails a DIFFERENT (custom code 24) check - meaning DexLab’s fork genuinely extends the account list with something this repo hasn’t identified (no public source was available to cross-reference). Gated rather than guessed at: a wrong account list here would revert every dexlab cook in production, and DexLab is otherwise the single deepest-liquidity fork of the six (2,097 live constant-product pools).

DEXLAB_PROGRAM_ID: Address

`dexlab`

Variable · sdk/dist/svm/venues/spl-token-swap-forks/index.d.ts

dexlab: SplTokenSwapForkAdapter

`SAROS_PROGRAM_ID`

Variable · sdk/dist/svm/venues/spl-token-swap-forks/index.d.ts Saros - UN-GATED (2026-08-03; was gated, see git history for the original unresolvedGate text). The original real-CPI probe against the live mainnet binary (a real WSOL/USDC pool, Djxfn7zWFxFqYgwesXfq8BeAirfXwfhQmNcCousXh7G7, dumped 2026-07-31) found the same fee-MODEL divergence this comment used to describe: REALIZED output across 14 independently-sampled real trades (27,995 to 6,089,579 raw units) implies an effective swap fee of a clean, reproducible ~4 bps - NOT the 30 bps the pool’s own on-chain owner_trade_fee field states (trade_fee reads 0 bps). The account layout is confirmed correct up through pool_fee_account (the swap only succeeds because that key check passes) - this is a genuine fee-MODEL divergence, not a decode bug: Saros’s deployed program evidently does not compute the swap fee the vanilla spl-token-swap way from the fields at these offsets, and no public source was available to determine the real rule (the likely explanation, not confirmed: the stored owner_trade_fee sizes how many LP tokens this fork mints to pool_fee_account - confirmed growing consistent with invariant growth on every sampled trade - while the amount actually deducted from the trader’s output is governed by a separate, unrecovered constant). Rather than continue gating on an unresolved exact rule, this adapter deliberately keeps the generic makeSplTokenSwapForkAdapter formula (the STORED, higher trade+owner fee rates as the netIn deduction) as a MEASURED, DELIBERATE safety margin: across all 14 sampled trades this model’s predicted output was strictly <= the real realized output every time (margins of ~0.05%-0.26% of the trade) - never an over-promise, so quoting it is safe for election (a worse model never wins a share it doesn’t deserve), the same closed-source-fork trade-off gamma’s dynamic-fee ceiling already makes. Proven end-to-end against the real deployed binary in LiteSVM at 2 and 4 rungs plus three additional sizes (predicted <= realized at every sampled size, never ===, unlike the orca-legacy-token-swap/token-swap-v1/etc. siblings this fork’s math was cloned from) - see the consuming app realcpi e2e test’s saros describeWith block in sauce-recipes.

SAROS_PROGRAM_ID: Address

`saros`

Variable · sdk/dist/svm/venues/spl-token-swap-forks/index.d.ts

saros: SplTokenSwapForkAdapter

`ORCA_V1_PROGRAM_ID`

Variable · sdk/dist/svm/venues/spl-token-swap-forks/index.d.ts Orca V1 - the ORIGINAL Orca token-swap deployment, a DIFFERENT program from the already-wired orca-legacy-token-swap (“Orca V2”, 9W959DqEETiGZocYWCQPaJ6sBmUzgfxXfqGeTEdp3aQP). Confirmed distinct live (routePlan ammKey 6fTRDD7sYxCN7oyoSQaN1AWC3P2m8A6gVZzGrpej9DvL, owner DjVE6JNiYqPL2QXyCUUh8rNjHrbz9hXHNYt99MQ59qw1).

ORCA_V1_PROGRAM_ID: Address

`orcaV1`

Variable · sdk/dist/svm/venues/spl-token-swap-forks/index.d.ts

orcaV1: SplTokenSwapForkAdapter

`PENGUIN_PROGRAM_ID`

Variable · sdk/dist/svm/venues/spl-token-swap-forks/index.d.ts Penguin.

PENGUIN_PROGRAM_ID: Address

`penguin`

Variable · sdk/dist/svm/venues/spl-token-swap-forks/index.d.ts

penguin: SplTokenSwapForkAdapter

`STEPN_PROGRAM_ID`

Variable · sdk/dist/svm/venues/spl-token-swap-forks/index.d.ts StepN (Dooar).

STEPN_PROGRAM_ID: Address

`stepn`

Variable · sdk/dist/svm/venues/spl-token-swap-forks/index.d.ts

stepn: SplTokenSwapForkAdapter

`makeSplTokenSwapForkAdapter`

Function · sdk/dist/svm/venues/spl-token-swap-forks/index.d.ts One adapter per deployed spl-token-swap fork - SAME math/layout as orca-legacy-token-swap (see module header), parameterized only by the fork’s own program id (the CPI target AND the swap-authority PDA domain). unresolvedGate, when passed, makes fetchPoolConfig throw UNCONDITIONALLY for every pool of this family (naming the reason) - the SAME mechanism orca-legacy-token-swap uses to keep its stable-curve pools out of the electable universe (see that adapter’s curve_type check), just applied to the WHOLE family instead of a per-pool byte. resolveSvmPoolSpec catches any fetchPoolConfig throw and drops the candidate - one venue’s gate never breaks discovery or any other family, and (critically) it means the family is WIRED (program id, discovery filter, CU entry all present and exercised) while being STRUCTURALLY UNABLE to enter a cook until the gate is lifted, so there is zero production revert/mispricing risk from an unresolved integration question. See ./index.ts’s dexlab/saros instantiations below for the two currently gated forks and exactly what each is waiting on.

export declare function makeSplTokenSwapForkAdapter(slug: string, programId: Address, unresolvedGate?: string): SplTokenSwapForkAdapter;

`SplTokenSwapForkPoolConfig`

Interface · sdk/dist/svm/venues/spl-token-swap-forks/index.d.ts

export interface SplTokenSwapForkPoolConfig extends PoolConfig {
    swapAuthority: Address;
    tokenProgram: Address;
    vaultIn: Address;
    vaultOut: Address;
    poolMint: Address;
    poolFeeAccount: Address;
    inputMint: Address;
    outputMint: Address;
    tradeFeeNumerator: bigint;
    tradeFeeDenominator: bigint;
    ownerTradeFeeNumerator: bigint;
    ownerTradeFeeDenominator: bigint;
    bumpSeed: number;
}

`SplTokenSwapForkAdapter`

Interface · sdk/dist/svm/venues/spl-token-swap-forks/index.d.ts

export interface SplTokenSwapForkAdapter {
    slug: string;
    kind: "constant-product";
    programId: Address;
    fetchPoolConfig(load: AccountLoader, pool: Address): Promise<SplTokenSwapForkPoolConfig>;
    quoteAccounts(cfg: SplTokenSwapForkPoolConfig): VenueAccount[];
    emitQuote(cfg: SplTokenSwapForkPoolConfig, i: number, amountIn: bigint): string;
    buildSwap(cfg: SplTokenSwapForkPoolConfig, user: SwapUser, amountIn: bigint): VenueSwap;
    referenceQuote(cfg: SplTokenSwapForkPoolConfig, state: AccountBytesMap, amountIn: bigint, _now: bigint): bigint;
}