A conversation with Ross about his journey from law to smart contract development, creating the Uniswap v4 Swap Router with Sauce, the easiest, flexible, and optimized Uniswap v4 swap router for developers.
How did you get started in crypto?
I was working at a law firm. I saw that I could spend 8 years there, or just learn about smart contracts - it seemed like a simple choice. I'm grateful I decided to join crypto, especially seeing how AI is disrupting the legal profession.
I started at ConsenSys on OpenLaw, putting documents on the blockchain. Then I joined SushiSwap working on AMMs, pivoted to legal technology with KALI and on-chain DAOs, and now I'm back to DeFi - never a dull moment.
How did the v4 router project come about?
My previous work on natural language processing for Uniswap v3 caught the Uniswap Foundation's attention. It was an English language router on top of v3, a contract where you could throw in sentences and it would resolve the swaps based on the sentence.
Sauce reached out and said, 'if you're doing something that complex on v3, you can probably simplify v4.’Together, our goal became to create the simplest way to route on v4, inspired by UniswapV2Router02.
Why is the router beneficial to v4 hook developers?
For end users, the v4 router provides the most gas-optimized path. As more apps are built as hook extensions, it will offer a more competitive way to swap and get better rates.
For developers, this is about starting to build on Uniswap v4, which is state of the art.
We’re essentially saying, don’t begin with v2 or v3 - look at v4 contracts and use our router that's custom built for you. Smart contracts have size limitations, and while the original Universal Router does a good job, having a dedicated router for v4 makes sense when you're trying to unlock dynamic fees and optimize for LPs through design around the size limitation.
What makes the Community Router special?
As a builder, I’m always trying to make things cheap, simple, and readable. v4 is a complex equation for many DeFi developers, and our API simplifies calling those contracts significantly.
The v4 router is intuitive - it uses v2 functions as a wrapper on v4 contracts. Developers have mentioned it helps with testing, which shows we're addressing that critical learning curve for new protocols.
We included native calldata compression in the fallback, making it extremely cost competitive on L2s where calldata costs dominate. No other router I've seen has this compression technique, and our design specifically anticipates L2 as a major volume source.
We also solved the multi-chain address problem by using create3, which gives us the same exact address on every chain despite different constructor settings. The address is also gas-optimized with leading zeros to make calls cheaper.
It's familiar too - we use the v2 ABI that developers know well. While v4 has complex methods like 'take' that might not be intuitive, our wrapper provides familiar functions like swapExactIn and swapExactOut that everyone understands. It's essentially a semantic translator for v4's powerful but complex interface.
What are you excited to work on next?
I'm exploring what it would look like to have a single contract that holds all tokens on Ethereum, with a DeFi program built within that idea. With ZAMM for example, I'm trying to distill DeFi use cases around token launches and liquidity into a minimal primitive combining v2 with a new token standard, ERC-6909.
If Ethereum is a commons, it needs to be clean. I believe we can coordinate by deploying code that embodies better patterns. My ideal is making Ethereum work better - blockchains are too expensive and complicated right now. I'd like to see Ethereum become less expensive than alternatives like Solana and establish a single pattern for tokenization that makes crypto less confusing for everyone.
Note: The views expressed herein may not reflect the views of the Uniswap Foundation. This interview is provided for informational purposes only and does not constitute legal, financial, or professional advice.