January 15, 2026
This article is part of an ongoing series where I attempt to scaffold out the core market structure primitives on Solana using a combination of domain knowledge and LLMs (but no manual coding). Check out my previous article about building a Prop AMM.
The router has a special place in the DeFi ecosystem. It manages the messy problem of integrating markets and efficiently routing trades between them. In the early days of Solana, there was only one router, Jupiter, and it had very little competition. Over the past few years, teams like DFlow, OKX, and Titan have entered the space and forced some meaningful product iteration. Almost every retail trade on Solana is routed through one of these platforms.
This past weekend I set out on an experiment to build my own router from scratch with Claude. You can try it out below, or visit the standalone swap page.
I started this project with a reasonably high-level understanding of how the existing routers work, from talking to teams that have built them and from spending years market making on Solana. I came away with a new appreciation for the thorny problems that the existing routers solve, as well as some refined ideas for how to use LLMs to write code that interacts with blockchains.
Part of my interest in writing these articles is to convey the level of abstraction that I find is optimal for interacting with the new tools like Claude Code. I have a theory that the determinism, robust testing, and simulation infrastructure available in DeFi make it a shockingly good environment for agentically building financial primitives.
To build a router, we need some representation of every available exchange and market on Solana. To properly model an exchange, the system has to load all the relevant accounts, build a local representation of the swap logic, and then build a function to generate swap instructions given different parameters. There are a few key inputs to this that make it much easier:
With this context, Claude can understand and integrate the major open-source DEXs. It struggled a bit with the bin derivation on the CLMM systems, but I was able to guide it through the debugging process.
Without much trouble, I was able to get up and running with a few different AMMs:
However, it failed to figure out closed-source DEXs like HumidiFi.
I gave Claude a series of additional tools and let it attempt to reverse engineer HumidiFi for about three hours. After it failed, I gave up and moved on. This is something I will try again with Opus 5 and the next series of frontier models.
The way routing works is that an off-chain system stores the state of every market and, at the time of quote, collapses the list into a small number of plausible routes. It then sends the most efficient route in the transaction and the contract routes the user's trade. As these systems have gotten more advanced, companies like DFlow have pioneered the concept of JIT routing where the transaction sends multiple possible routes and the contract simulates them on-chain and picks the best one at trade time, improving execution quality further (this is beyond the scope of my system).
This contract is relatively simple. It takes a series of markets and a trade size and then forks or chains the trades together to give the user the desired swap, reverting if the slippage tolerance is exceeded. Claude was able to write this, test it, and send me some example swaps on mainnet with minimal intervention.
Once the program is written, the system needs to find the correct route off-chain when the user requests a quote. This becomes a somewhat involved engineering problem when you have to track millions of tokens and keep the pool states synced at low latency. To simplify the problem, I restricted the router to a smaller number of liquid tokens.
Claude implemented a DFS pathfinding algorithm where tokens are nodes and liquidity pools are edges.
Paths ranked by expected output
The algorithm explores all paths up to a maximum hop limit, scores them by expected output, and sends the top candidates for detailed quote simulation against live pool state.
The initial implementation was a bit clunky and took over 2 seconds to simulate the route because of RPC calls. Once given latency requirements, it was able to come up with a batched query pattern that was much better optimized. This was the portion where I ended up with the most frustrating back and forth, which surprised me. Claude struggled to properly optimize this service and made a series of elementary numerical and configuration errors.
After working through the building blocks, all that is left is to have Claude design a simple swap UI in the style of my existing website and format swap instructions.
This is a side project I could not imagine undertaking 6-12 months ago that is now doable in a weekend. However, it is worth noting that this implementation does not come close to replacing the existing commercialized routers on a few dimensions:
Even with those caveats, I am increasingly optimistic about this development pattern. I can see a world in the not-so-distant future where the harnesses and models are so strong that the only remaining engineering work for DeFi systems is reasoning through the algorithms and mechanisms.