Trade SODA on Kraken.
Trade SODA on Kraken.
Canonical explanations of SODAX concepts and system components. Human-readable and always up to date.
The liquidity the SODAX system can reach beyond its own inventory: local DEX, aggregator and AMM liquidity on each network, the last mile where an asset actually lives. Together with the liquidity inventory it forms SODAX liquidity.
Software systems that independently evaluate conditions, form intents, and execute financial actions across networks without continuous human direction, using programmatic interfaces like MCP servers and SDKs to interact with execution infrastructure.
The SODAX AMM is SODAX’s internal decentralized exchange on the Sonic network, used to create tradeable markets for SODAX-native assets, primarily paired against bnUSD.
The Asset Manager is the bridge and permission layer that authorizes and moves assets into and out of the SODAX system.
The condition in which actions across multiple systems resolve independently over time rather than completing simultaneously.
The removal of network-specific complexity from user and developer experience, so that actions resolve across systems without requiring awareness of where execution happens.
A Coordinator is an execution planning and monitoring function that structures cross-network actions into concrete, ordered steps as they move toward settlement. The Coordinator is an internal function of a solver, not a SODAX-owned component: solvers own the act of solving.
Cross-network execution is the coordinated process of completing a financial action that spans multiple independent blockchain networks as a single, coherent operation.
The ability to lend, borrow, and reuse capital across network boundaries without requiring users to manually bridge, wrap, or reposition assets.
The DApp Kit (@sodax/dapp-kit) is SODAX's UI component layer, providing pre-built React components that give applications a ready-made cross-network experience with minimal integration effort.
Deterministic execution wallets are system-generated smart wallets that provide each user with a consistent identity and execution account across all supported networks.
The portion of total available capital that can actually be accessed and used under real execution and coordination constraints.
The process of coordinated actions that turns an intended outcome into a real, settled state across one or more systems.
The alignment of multiple actions across systems so they collectively achieve an intended outcome under real conditions.
The Hub is the central coordination network of SODAX where cross-network actions are registered and where their final settlement state is recorded as the system’s single source of truth.
Hub Wallet Abstraction is the deterministic smart wallet system on the Hub that provides each user with a stable execution identity for cross-network actions.
Hub-and-spoke architecture is the system design pattern where a central coordinator (the Hub) manages state and coordination while local endpoints (Spokes) handle network-specific execution.
The specific end state a user or system aims to reach, independent of the individual transactions required to achieve it.
The Intent Filler is the spoke-side contract that enables local fulfillment of cross-network intents by locking solver funds and relaying fill confirmations back to the Hub.
Intent-based execution is the design pattern where users define desired outcomes and constraints, and the system determines the optimal path to fulfillment.
An Intent is the structured user request that defines the desired cross-network outcome and the constraints under which it may be executed.
The ability of a system to reach and use capital where it already exists across networks or venues under real execution conditions.
The condition in which capital is distributed across multiple systems or venues, limiting its effective usability despite sufficient aggregate depth.
System-level execution liquidity held as one inventory rather than isolated pools per network, owned and managed by the SODAX DAO, that admitted solvers draw on to fill intents. Funded by 60% of the protocol fee.
Making a token liquid and available across many networks and applications at once: distribution across every network and Venue Partner surface, liquidity created through the system's own mechanics, and active quoting performed by admitted solvers.
Money that exists in programmable, multi-network systems, where its usefulness depends on coordinated execution, timing, and context, not just ownership.
A cross-network money market that lets builders and users lend, borrow, and reuse capital across all integrated networks.
The Multi-Bridge Architecture is SODAX's layered approach to cross-network message delivery, combining proprietary relays with third-party protocols to maximize reliability and coverage.
The architectural ability to integrate with multiple bridge infrastructures, using each where appropriate rather than relying on a single cross-network mechanism.
The path that a financial action takes from intent to settlement, including every routing decision, venue selection, and execution step along the way.
The point at which an intended outcome has been fully reached and is usable, independent of intermediate confirmations or partial steps.
The Partner Dashboard is the interface where builders who integrate SODAX connect their fee wallet and manage the fees generated by their SODAX-powered application.
The governance-approved, automated buy-back and burn funded by 20% of the protocol fee. It buys SODA on the open market and permanently removes it from supply: volume-driven, code-enforced, with no manual timing and no discretion.
The fee carried by activity routed through the SODAX System. Fees collect in the Fee Treasury, where code splits them three ways: 60% liquidity inventory, 20% programmatic buy-back and burn, 20% staking pool.
The Rate Limiter is the contract-level mechanism that controls asset throughput across the bridge layer, managing risk by capping transfer volumes within defined time windows.
The ability of a system to move from partial or divergent execution states back to a coherent and usable outcome.
The Relayer is the distributed signing and transaction submission layer that delivers verified cross-network messages within SODAX.
Self-custody is the principle that users retain direct control of their assets throughout all system interactions, without delegating ownership to intermediaries.
The SODA Exchange is the asset management environment on
sodaVariants are how SODAX extends assets into networks where they do not exist natively, making them usable through system-level liquidity.
The SODAX API (
The SODAX SDK (@sodax/sdk) is the TypeScript interface for integrating SODAX's cross-network execution and liquidity capabilities, and one of two integration paths alongside the SODAX API.
SODAX is a non-custodial cross-network execution and liquidity system that coordinates financial actions across networks through a solver-based model, multi-bridge architecture, and integrated money market. Execution is the surface apps and Venue Partners tap into; liquidity is what admitted solvers draw on to fill.
A solver is an independent trading firm admitted to the SODAX marketplace that decides, prices and executes how a cross-network action is carried out, drawing on SODAX liquidity wherever it operates. SODAX coordinates routing and settlement and does not itself act as a solver or take custody.
The surface where admitted solvers access SODAX liquidity to fill intents, inside the SODAX System or on external venues where they operate. Admission is gated on liquidity, reliability, risk and screening requirements. SODAX provides the marketplace and settlement rails.
A Spoke is the local execution endpoint on a supported network, responsible for receiving user actions, locking assets, and relaying messages to the Hub for cross-network coordination.
The movement of a system from one defined condition to another, especially across distributed or multi-network environments.
