people have asked: “why do we need one deep liquidity pool on sushi as the core dex app on katana when dex aggregators can already route across multiple pools?” it’s a good question, but here’s why deep native liquidity still matters.👇 dex aggregators do a great job of finding best execution across fragmented liquidity. but they don’t solve the core problems caused by that fragmentation: – worse pricing due to slippage – poor UX from unpredictable routing – increased MEV risk – more gas costs when you concentrate liquidity into one deep pool, you dramatically reduce slippage—even for large trades. That’s critical for both traders and apps that rely on reliable execution. with fragmented pools, every hop adds cost and risk. aggregators route after price impact has occurred in each pool. they’re reactive. asingle deep pool is proactive—you get better quotes from the start. liquidity depth drives price efficiency. on katana, sushi as the core dex apps is designed to have natively integrated liquidity that’s deep by design. this means: – better execution without needing to aggregate – more predictable pricing – stronger UX for end-users – a foundation composable with everything else built on top it also simplifies design for other apps. instead of worrying about how to route or optimize for various liquidity sources, protocols can just tap into one deep source they trust. in short: DEX aggregators play an important role, especially cross-chain—but they can’t replace the benefits of deep native liquidity in a single pool. katana’s design with sushi as the core dex app focuses on building this foundation natively into the ecosystem. one deep pool = – better capital efficiency – sower slippage – easier integrations – less MEV – better UX fragmented liquidity will always be suboptimal. Aggregators patch, but deep pools solve. this is why i believe in the core app thesis. it’s not just a technical preference—it’s a strategic one. Let’s build the base layer right. This way, users win.