Crate solana_central

Expand description

§Solana Central Rust Library

Provides utilities, types, and DEX protocol-specific implementations

Currently supported DEXs: Meteora Dammv2, Dbc, Ammv1 (Old), Raydium Cpmm, AmmV4, Launchpad, Pumpswap, Pumpfun Bonding Curve

This library also provides:

A shared context (CentralContext) for managing DEX liquidity pools for trading pairs, RPC clients, blockchain state, etc.
Protocol-specific pool parsing and raw on-chain account data decoding utilities. Every protocol type has an accessible from_account_info method that can be used from raw on chain account data.
Common types and traits for abstractions with liquidity pool fees, liquidity, etc.

Environment variables required:

RPC_NODE_URL: URL of the Solana JSON RPC node to use for on-chain data fetching

Modules§

constants
protocol_idls: Protocol IDL structures. This module contains Borsh-deserializable structs copied from various on-chain Solana protocol IDLs. These structs represent the exact account layouts used by protocols like Meteora, Raydium, Pumpfun, and Pumpswap.

Structs§

CentralContext: Central context for managing DEX liquidity pools, markets, and RPC clients
Instruction: A general independent Solana instruction type agnostic of inner or top level instructions. Designed to conveniently work with the format used in Solana SDKs and yellowstone grpc. Does not own any of the data just lifetimes to it.
Link: Struct used to track a “link” between two accounts. For there to be a link, both accounts must be on curve. We return link as a 64 byte array with first 32 bytes being “smaller” account and last 32 bytes being “larger” account. Accounts are compared from most to least significant bit. In addition to storing the 2 wallets, we also store the earliest tx where they were first observed linking, and we order by block_time, slot, index, and atomic_instruction_index.
MarketUpdate: Used to deliver high frequency market price updates without having to do read locks on the pool struct that holds the current market state. It’s going to be more meant to be used for “pushing” market updates throughout the system.
MeteoraAmmPool: Struct to hold data and PoolTrait implementation for Meteora Ammv1 pools. This struct contains the data that is UNIQUE to a specific AMM Pool on Meteora. For shared data, such as vaults for tokens, because they are shared across all AMM pools in the Meteora protocol, they will be stored in shared MeteoraVault objects. References to those shared objects will be stored in these pool info objects.
MeteoraDammV2Pool: Struct to hold data and PoolTrait implementation for Meteora Ammv2/Dammv2 pools.
MeteoraDbc: Struct to hold data and PoolTrait implementation for Meteora Dynamic Bonding Curve pools.
MeteoraVault: Struct to hold data for Meteora vaults, which are used in Meteora AMMv1 and potentially Meteora DLMM pools.
PfBondingCurve: Struct to hold data and PoolTrait implementation for Pumpfun Bonding Curve pools/markets.
Pool: Base pool information shared by all pool types. Contains the essential addresses and identifiers that every pool implementation requires. Protocol-specific pool structs will embed this as an info field.
PumpswapPool: Struct to hold data and PoolTrait implementation for Pumpswap pools.
RaydiumAmmV4Pool: Struct to hold data and PoolTrait implementation for Raydium AmmV4 pools. The only things you actually need to trade on a Raydium AmmV4 at least are these things: the liquidity pool program address, baseVault, quoteVault. The rest of the fields can be constant blasted as random values and the program will not care because Serum and Openbook are no longer in use for these AMMs.
RaydiumCpmmPool: Struct to hold data and PoolTrait implementation for Raydium Cpmm pools.
RaydiumLaunchpad: Struct to hold data and PoolTrait implementation for Raydium AmmV4 pools. As of July 2025, the only global config account for Raydium Launchlab uses the constant product pool. We use do token a is base and token b is quote here.
SwapTx: Standardized swap transaction type that is used to store all swap transactions on the blockchain regardless of the protocol. This schema is used in solana_car historical ingestion and by strategies and data analytics tools working in polars queries that we made.
TokenCreation: Standardized token creation event structure. Contains information about newly created tokens/pools extracted from transaction data. Used for tracking new token launches (e.g., Pumpfun bonding curve creation).

Enums§

Pools: Enumeration of all supported DEX pool types
SwapDirection: Direction of a swap operation. If on a liquidity pool/market,token A is USDC and token B is WSOL: AToB: Swap from USDC to WSOL (buying SOL), BToA: Swap from WSOL to USDC (selling SOL)

Traits§

PoolTrait: Trait for all pool types, providing a unified interface for DEX pools. All pools implement this trait to provide common functionality like price queries, fee calculations, and reserve lookups.

Functions§

derive_bonding_curve: Derive the Pumpfun bonding curve PDA for a given token address
get_cpmm_fee_amount_from_config_account: Get the fee amount for a Raydium CPMM pool based on its config account
get_meteora_vault_from_token_address: Get or create a Meteora vault for a given token address
is_legit_token: Check if a token is legitimate based on its Metaplex metadata
load_pools: Load pools from multiple protocols using async getProgramAccounts JSON RPC calls. Fetches and processes pool accounts for the specified protocols in parallel using multiple threads. Processed pools are inserted into the central context for later access.
process_get_program_accounts_pool: Process raw account data from getProgramAccounts into pool instances. Identifies pools by their program owner and account size, then parses them into the appropriate pool type (Meteora, Raydium, Pumpswap, etc.). Designed to be called from multiple threads with different slice ranges.