About This Blog

We talk a lot about what Jupiter ships. Ultra, Mobile, new integrations - there's always something launching. But we almost never talk about how we build any of it.

That's been on my mind for a while. Some of the most interesting engineering work I've seen happens inside this team, and almost none of it gets told. The routing breakthroughs, the 3 AM debugging sessions, the arguments that turn into better architecture - these stories deserve to exist somewhere outside our internal channels.

So this is that place. Not a marketing page. Not a company announcement. An engineering blog, written by the people who write the code. Here's who we are and why we think the way we do.

The team

I'm Aaron. I've been an engineer most of my life - whether that means architecting a distributed system or figuring out how to organise a team so it doesn't slow itself down. What I care about most is building something that works under real pressure, with people who care as much as I do.

And we got fortunate with this team. It's a genuine hybrid, and honestly I think that's the most important thing about us.

We have engineers from Big Tech - Google, Meta - people who've built systems that handle billions of requests and know exactly what happens when they fail. They bring rigour. And we have crypto natives - Triton, Ironforge, Binance, OKX - who live inside the mempool, squeeze milliseconds out of RPCs, and understand DeFi mechanics in their bones. They bring velocity.

Having both in the same room is rare, and the tension between "move fast" and "don't break things" is where our best work comes from.

Here's what that looks like in practice. When we were redesigning our quoting engine, the Big Tech engineers said: "We need to cache this for stability." The crypto engineers said: "We can't cache this - the price moves every 400 milliseconds." Neither side was wrong. The answer wasn't caching or not caching. It was redesigning the routing algorithm entirely to reduce latency by over 150x, so caching wasn't necessary in the first place.

That argument - and the architecture it produced - is exactly the kind of thing we want to write about here.

We work in small, autonomous squads, each with full ownership of their domain. When the market shifts, we don't need a month of meetings to respond. We ship in days. And when things go wrong (they do), there's no "we'll look at it in the morning." It's engineers up at 3 AM doing whatever it takes. That pressure over the past year isn't something we survived - it's what forged the team we have now.

What you'll find here

Every post on this blog is written by the engineer who built the thing being explained. The person writing about split routing is the one who researched and implemented it. The person writing about token tradability is the one who built the market quality system from scratch.

You'll read about how things work under the hood - routing engines, transaction pipelines, pricing algorithms. The real mechanics, not the abstraction. You'll read about architecture decisions - what we tried, what failed, what we shipped, and why. And you'll find practical guides with working code for developers building on our APIs.

We're not going to explain things we don't fully understand ourselves. If we write about it, it's because we built it, debugged it, or argued about it at 2 AM until someone had a better idea.

---

This is a blog for people who care about how things really work. If that's you, welcome. We're glad you're here.