The client had a working Ethereum-based DEX. The trader UX was fatal — a swap took 12-40 seconds between click and fill, and the fee curve during network congestion made small trades economically pointless.
The ask was a Solana equivalent. Same UX intent, sub-second execution, Jupiter Aggregator integration so users get the best route across the Solana DeFi landscape, not just liquidity from our own pools.
Why Solana for a DEX#
- Block time: ~400ms. Trader clicks, trader gets fill, no coffee break.
- Fees: fractions of a cent per swap, not $5-40 like Ethereum L1.
- Anchor: Solana's dev framework is much lower-friction than raw Rust + Solana Program Library.
- Jupiter Aggregator: the de-facto aggregator on Solana. If you build a DEX and do not integrate Jupiter, users just use another one.
The AMM design#
Raydium-style constant-product AMM. x * y = k, LP tokens for liquidity providers, fee tier configurable per pool.
Implementation in Anchor:
initialize_pool— creates a pool for a given token pair, mints LP tokens.add_liquidity— deposits both tokens, mints LP tokens proportional to the pool share.remove_liquidity— burns LP tokens, returns proportional amounts of both underlying tokens.swap— the interesting instruction. Computes output amount using constant-product math, deducts fee, transfers tokens.
The whole program is ~450 lines of Rust. Anchor's macros carry a lot of weight — most of the boilerplate is generated.
Jupiter integration#
Jupiter Aggregator routes swaps across all Solana DEXes to give users the best price. From a DEX's perspective, being routable through Jupiter is free traffic.
Registration is submitting the pool addresses to Jupiter's API registry. Jupiter's routing engine picks up our pools automatically and includes them in quotes when they offer better pricing than alternatives.
The frontend also uses Jupiter for routing when the user's swap benefits from splitting across multiple pools. The user's UX is: type an amount, see the best quote, click swap, done in under a second.
SPL token support#
SPL tokens are Solana's ERC-20 equivalent — but the structure is different. Each token has a mint account and each holder has an associated token account. Transfers go through those associated accounts, not the mint.
The DEX handles arbitrary SPL tokens: any tokenmint address can be paired with any other, no whitelist, no approval process. This is table stakes for a Raydium-style DEX and it works out of the box with Anchor's token program integration.
Testing#
Anchor's built-in testing framework (Mocha + Anchor's TypeScript SDK) runs against a local Solana test validator. The test suite:
- Initializes a fresh pool.
- Adds liquidity from three simulated LPs.
- Executes 100 swaps with varying sizes, verifies the constant-product invariant holds.
- Removes liquidity, verifies each LP gets proportional withdrawal.
- Attempts adversarial swaps (zero input, larger-than-pool input, wrong token) and verifies rejection.
Run time on a local validator: ~40 seconds for the full suite. That is fast enough to run on every commit.
Deployment#
Deployed first to Solana devnet, ran a 2-week user smoke test, then deployed to mainnet-beta. Program addresses are pinned in the frontend config.
The upgrade authority for the program is a multisig (Squads Protocol, the Solana equivalent of Gnosis Safe). No single key can push a new program version.
What shipped#
- AMM DEX live at dexspeed.com.br.
- Sub-second swap execution (Solana block time is ~400ms, our full flow is under 800ms end-to-end).
- Jupiter integration — the DEX shows up in Jupiter route quotes.
- SPL tokens supported natively — any user can create a pool.
- 99% wait time reduction vs the client's prior Ethereum-based DEX (12-40s → <1s).
The client owns the Anchor program source, the deployment authority (via multisig), the frontend, and the Jupiter registration.