
For DEXs, DEX Aggregators and Solver Marketplaces that want to offer cross-network asset exposure without building bridges or managing per-network liquidity.

For DEXs on a single network that want to offer cross-network swaps and onboard capital from any chain, so users can bring assets in, trade, and move out without leaving the app.

For wallets that want to bring new asset classes like tokenized stocks and RWAs to their users, purchasable with the assets they already hold.

For derivatives DEXs that want to offer cross-network asset exposure without building bridges or managing per-network liquidity.

For non-custodial wallets that want to add cross-network trades and real-world spending without managing bridges, liquidity, or custom integrations.

For Hedera apps that want to offer tokenized stocks, paid in HBAR or USDC and delivered to the user's own account, with no inventory or order book to run.

For RWA platforms that want investors to buy real estate bonds from any asset on any integrated network, with deposits settled in USDC in a single flow.

For DEXs on Solana that want users from other chains to onboard in one flow, bridge their assets, and land ready to trade without any contract changes.

For lending protocols on non-EVM chains that want users to deposit from any supported network, with funds flowing cross-chain into a single market in one step.

For payment platforms that want users to pay with any crypto on any of the 22+ supported networks, with the best route picked for each transaction on speed, cost, and reliability.

For e-commerce marketplaces that want buyers to pay from any integrated network with assets they already hold, keeping bridging out of checkout and the infrastructure out of sight.

For Hedera-native protocols that want to take their liquidity cross-chain in one self-custody flow, with no bridges to build and no custody to hold.

For yield vaults that want depositors to fund from any chain, routing stablecoins into a single settlement contract without manual bridging.

For wallets that want to add cross-network swaps: quotes, user-signed swaps, and status handling across chains through a single API.

For RWA vaults and protocols that want depositors to fund with any asset from any integrated chain, routed to the asset of choice, and deposited in a single step.

For DEXs and aggregators that want to list assets whose liquidity sits on other networks, without building a bridge, bootstrapping a pool, or changing how their existing routing works.

For apps on non-EVM networks that want EVM users to onboard with the wallet they already have, controlling a native smart wallet without ever leaving MetaMask.

For privacy-first DeFi platforms that want to offer users cross-chain swaps and liquidity access across 20+ networks from a single interface, without building routing infrastructure.

For liquidity marketplaces and aggregators that want intent-based execution, cross-chain liquidity, all through a single integration.

For trading apps that want cross-network onboarding to feel invisible, letting users bring funds in from any integrated network, trade, and move funds back out without a complicated bridging flow.

For DeFi platforms that want to give users access to cross-network stablecoin liquidity without building bridges, routing logic, or new infrastructure.

For cross-chain DeFi apps that want to offer intent-based trades, native stablecoin integration, and the ability to lend and borrow across chains.

For Bitcoin-native applications that want to give BTC holders trading and money-market lending across 18+ networks, self-custodied from entry to settlement, with no wrapping and no centralized exchange in the middle.
DEX Aggregator on Stellar
For DEXs and aggregators that want to list assets whose liquidity sits on other networks, without building a bridge, bootstrapping a pool, or changing how their existing routing works.
For DEXs and aggregators that want to list assets whose liquidity sits on other networks, without building a bridge, bootstrapping a pool, or changing how their existing routing works.
Soroswap aggregates Stellar liquidity. SODA is live on Stellar as a classic asset, but its depth is not on Stellar.
SODA has no meaningful AMM pool depth on Stellar. Its liquidity sits with solvers on the SODAX hub, so an aggregator that only routes Stellar venues has nothing to quote against.
The listing had to happen inside the swap card users already use. A separate page, a second wallet connection or a transfer flow would have added a surface to learn, and surfaces that need learning do not get used.
Soroswap already owns its signing layer and pins its own version of the Stellar SDK. Any integration that brought a second wallet stack or a duplicate SDK into the bundle was not going to be mergeable.
Stellar classic assets carry 7 decimals and require a trustline on the receiving account. Cross-network pairs mix precisions and need a delivery-side check that EVM-only integrations never encounter.
The requirement was a new asset with off-network liquidity, quoted and settled inside an interface that could not change.
Soroswap integrated the SODAX Swaps API v2 over HTTP. No new interface, and no change to the routing that was already there.
@sodax/swaps-api is a typed fetch client for the Swaps API v2, with two dependencies, roughly 100 KB, and no wallet or network SDKs. Soroswap already owned a Stellar signing layer, so it took the HTTP client and let its existing wallet code sign the unsigned transactions the API hands back.
The swap controller checks the pair. SODA pairs route through SODAX, and every other pair follows the Soroswap aggregation path exactly as before. Three touch points, around 300 lines of contact with existing code.
Nine thin server routes keep the base URL server-side, and one state machine mirrors the step and error shape of the existing swap flow, so both paths behave the same way for users and maintainers. The care went into Stellar-side detail: check the destination trustline before creating the intent, read decimals off each token record because Stellar assets are 7 not 18, and fetch the deadline last so wallet prompts do not eat the 300 second window.
SODA appears only on a mainnet deployment, with a backend URL configured, and only when the live API lists it. Fail any one and the application behaves exactly as it did before, which turned the merge decision into whether to set one variable. No API key, and the value never reaches the browser.
From cold start to a filled trade on mainnet, using the Swaps API over HTTP.
Stellar users buy and sell SODA in the Soroswap swap card they already use, with no new page and no second wallet connection.
XLM to SODA, verified on mainnet with real funds and the intent confirmed solved.
Two dependencies, with no wallet or network SDKs and no second copy of the Stellar SDK in the bundle.
Every non-SODA pair follows the Soroswap aggregation path exactly as before.
The API hands back unsigned transactions. Soroswap's existing wallet layer signs and broadcasts them unchanged.
TBD Layer
TBD
TBD
Swaps API is live. 21 endpoints, one public base URL.