The Rise of Prop AMMs on Solana

Early Iterations of DEX Design

A long-standing thesis of mine since the early days of Uniswap V1/V2 was that DEXs would inevitably overtake CEXs. At the time, this was purely from the perspective of simplicity in UX and on-chain feasibility. However, the DEX landscape has come a long way since the early iterations of the x*y=k model.

The original constant product AMM (CPMM) introduced by Uniswap in 2018 was breakthrough in that it removed the need for active market makers, matching engines, and off-chain order management. Liquidity provision was democratized: anyone could deploy a pool and passively earn fees. This formula ensured continuous liquidity at every price point, but it came with trade-offs – most notably, significant price impact on large trades and impermanent loss for LPs.

Source: Constant Product AMM Math | DeFi

In the years to follow, DEX design would evolve to address these shortcomings. Uniswap V3 would introduce concentrated liquidity, allowing LPs to allocate capital within specific price ranges. Meanwhile, Curve optimized for stable asset swaps with custom bonding curves, and Balancer introduced programmable weights and multi-token pools.

Yet even as these innovations matured, most DEXs continued to follow the “public execution” paradigm – where all orders, swaps, and liquidity positions were visible and ordered deterministically onchain. Now, while this model was composable and permissionless, it exposed users to many adverse dynamics, including MEV, frontrunning, and toxic flow against passive LPs.

The emergence of performance-focused L1s like Solana unlocked a new design space for more granular, more competitive execution models, including onchain orderbooks and eventually, private liquidity venues. Today, we’re witnessing the rise of a new generation of DEX architectures built on Solana that go beyond public AMMs and into the domain of oracle-based, flow-protected venues.

In this report, we’ll focus specifically on this new cohort of proprietary AMMs – SolFi, Obric, and ZeroFi, and the directional thesis of where we believe the DEX landscape is heading.

Market Making Onchain

Before we dive into the current limitation of today’s DEX designs, it’s worth understanding how market making has evolved onchain. Unlike centralized exchanges, where market makers operate in low-latency environments and interact with real-time orderbooks, market making in DeFi is constrained by block time, transaction costs, and public visibility. This inherently reshapes how liquidity is provisioned and maintained.

The earliest attempts at onchain market making came in the form of constant product automated market makers (AMMs), which abstracted away the orderbook model entirely. Instead of relying on active market participants to provide two-sided quotes, AMMs use deterministic pricing curves to quote both sides of the market algorithmically. This meant that anyone could become a liquidity provider by depositing tokens into a pool, and the system would automatically facilitate trades using the x*y=k formula.

Orca Pools allow custom position ranges for LPs

This model, however, came with its own structural inefficiencies – the main one being capital inefficiency. Since liquidity is distributed across the entire price curve, only a small fraction of it is actually used in most trades. This problem has been partially addressed through concentrated liquidity designs (Uniswap V3, Orca Whirlpools), which allow LPs to allocate capital within tighter ranges. However, concentrated liquidity shifts the burden of price discovery and active management onto LPs. This consequently makes passive LPing less profitable and less incentivizing.

Additionally, all AMMs (even those that offer improved capital efficiency) have one shared vulnerability: they expose orderflow to the public, creating opportunities for frontrunning and MEV extraction. 

And while some protocols have tried to reintroduce more traditional market making via onchain orderbooks, the inherent nature of being completely onchain still carries over its own set of challenges. Every quote, update, or cancellation requires a transaction, making it both costly and slow compared to off-chain execution – a reason why I don’t view CLOBs to be viably efficient, even on today’s current high-throughput chains. 

Of course, it’s still a hot take. Many are in the camp that CLOBs are the winning design. And I don’t fully dismiss the idea of CLOBs, but the market is signaling