This post is a lightly adapted cross-post of research and design work originally written while building baibai.cx at spire.dev. Some sections have been expanded, simplified or reframed for a broader audience, but much of the historical background and underlying thesis remains the same. If you want the original version with more implementation-specific detail, you can find it here.

A biased history of Ethereum trading primitives

In Ethereum’s early years, trading onchain felt more like a digital bazaar than a modern exchange. Liquidity was thin, fragmented, and difficult to discover. If you wanted to trade one asset for another, you needed someone willing to take the opposite side at roughly the same time and price. Early systems relied on variants of peer-to-peer matching and onchain order books, but liquidity was sparse, and the user experience was often slow and inefficient.

The problem wasn’t that trading infrastructure didn’t exist; it was that Ethereum’s architecture imposed constraints. Maintaining a traditional onchain central limit order book (CLOB) meant continuously creating, updating, and cancelling orders. Execution was expensive and unpredictable. Markets could exist, but they struggled to attract enough liquidity and activity to feel efficient. At a time when online trading systems elsewhere could fill orders in milliseconds, Ethereum transactions could take minutes to settle. The future of finance it was not.

Automated Market Makers (AMMs) changed this model entirely.

Instead of requiring a direct counterparty for every trade, AMMs introduced pooled liquidity that anyone could trade against at any time. Liquidity providers could deposit otherwise idle assets and earn fees in return, while traders gained immediate access to liquidity without needing another participant on the other side.

The tradeoff was straightforward: users exchanged price precision for accessibility and composability. Prices were mathematically derived from liquidity curves rather than determined through competing bids and offers. Larger trades incurred slippage, and liquidity was not necessarily deep, but it was always available, 24/7. More importantly, liquidity itself became a permissionless building block that any application could integrate with. Early pioneers such as Bancor led the charge, with Uniswap later refining the model and pushing it into the centre of DeFi.

This was transformative. Rather than being a destination, liquidity became infrastructure. Money was becoming programmable. For the first time, financial functionality felt less like an application and more like a set of Lego bricks that anyone could assemble into something new. It was genuinely innovative and, at the time, incredibly exciting.

As the ecosystem matured and more sophisticated participants entered the market, new trading primitives emerged. Protocols such as AirSwap, 0x, and later CoW Protocol explored alternative designs built around RFQs, off-chain order relays, intents, and solver networks.

These systems sought to address some of AMMs’ weaknesses by enabling users to express trades through signed intents or limit orders, while market makers and competing solvers provided execution. This frequently resulted in tighter pricing and improved capital efficiency, particularly for larger trades.

But the tradeoffs simply shifted elsewhere. Quotes could become stale, orders might not fill immediately, if ever, and more of the coordination would move off-chain. While settlement remained on Ethereum, some of the magic of fully onchain composability was lost. From a programmable money perspective, this felt like a step backwards. Not because the execution quality was worse, often it was much better, but because some of the intelligence moved away from open and shared infrastructure into specialised and often more opaque intermediaries.

Meanwhile, AMMs themselves continued evolving. Concentrated liquidity allowed liquidity providers to allocate capital only where trading activity was expected, dramatically improving capital efficiency. More recently, hooks introduced the ability to attach custom logic directly to liquidity pools, enabling dynamic fees, custom execution behaviour and entirely new forms of market design. Trading primitives have gradually shifted from static, passive systems to increasingly adaptive and expressive ones.

Yet despite all these improvements, AMMs and DeFi more generally still react to market conditions rather than anticipate them. Liquidity positions update periodically while markets move continuously. For many major assets, price discovery still largely happens on centralised exchanges such as Binance, while DeFi often plays catch-up.

That gap between where prices are discovered and where liquidity actually lives may be one of the most interesting problems in DeFi today. PropAMMs are an attempt to close it.

What is a PropAMM

PropAMM has become something of a catch-all term for a new class of active market-making systems. Rather than relying purely on a static pricing curve, these systems continuously adjust prices using external signals, inventory models and proprietary strategies. At its simplest, a PropAMM is an AMM with a feedback loop attached. A pricing engine observes market conditions, estimates fair value and updates executable liquidity accordingly. In some implementations, this may be little more than publishing updated quotes every block and refusing to trade against stale prices. More sophisticated systems incorporate volatility, inventory exposure, order flow and broader market conditions into their pricing decisions.

Most designs share a common pattern: pricing happens off-chain while execution remains onchain. This creates an interesting shift in where competitive advantage lives. Traditional AMMs largely competed on liquidity depth and fee structures; active market makers increasingly compete on latency, pricing accuracy and execution quality. The ability to observe markets, react quickly, and land transactions efficiently is becoming a strategic edge.

Some firms are already forming closer relationships with block builders and sequencers to secure favourable execution and top-of-block placement. In many ways, this feels familiar. High-frequency trading firms spent years placing servers physically closer to exchanges because microseconds mattered. Crypto is beginning to develop similar behaviour. Instead of competing for physical proximity to exchanges, firms are competing for proximity to block production.

The problem with this model, at least in our view, is that it is still too slow. The programmability remains separated from the moment that actually matters: the swap itself. Ideally, you want pricing logic to execute at the point of trade execution, allowing liquidity to adapt in real time as transactions flow through the system. The challenge is cost. Complex logic executed during a swap increases gas consumption, and those costs ultimately fall on the user. More expensive execution leads to wider spreads, poorer execution quality, and a less competitive market. The ideal system would allow market makers to continuously adapt prices at the point of execution while making that additional complexity feel almost free to the trader.

A personal conclusion

What excites me most about PropAMMs is not necessarily the idea of “better AMMs” or even tighter spreads. It is the possibility that Ethereum’s execution model itself is starting to evolve. For years, DeFi has largely operated within the constraints of relatively static liquidity, periodically refreshed state and delayed reactions to rapidly moving markets. PropAMMs feel like one of the first serious attempts to collapse that gap between execution and intelligence.

At the same time, I think there is a real risk that DeFi accidentally rebuilds many of the same opaque structures it originally set out to escape. If all meaningful pricing logic, market making and coordination move into proprietary off-chain systems with privileged relationships to builders and sequencers, then we may end up with something that looks technologically impressive but philosophically hollow. Better execution alone is not enough if the cost is losing openness, neutrality and composability.

That tension is what makes this space interesting right now.

The challenge is no longer simply making markets onchain. It is figuring out how to preserve Ethereum’s core properties while enabling increasingly sophisticated forms of execution and programmability. In many ways, the next phase of DeFi may be less about inventing entirely new financial primitives and more about redesigning the execution layer those primitives run on top of.

Personally, I think synchronously composable based appchains are one promising direction. Not because they magically solve every problem, but because they allow experimentation with new execution environments without abandoning Ethereum’s broader settlement and composability guarantees. They create space for programmable liquidity to evolve closer to the point of execution while still remaining part of a larger shared financial system.

Ethereum trading primitives have steadily evolved from simple peer-to-peer swaps, to passive liquidity curves, to increasingly programmable and adaptive systems. PropAMMs feel like the next logical step in that progression. Whether they ultimately succeed or fail, they are asking the right question:

What should programmable markets actually look like when blockchains become fast enough for liquidity itself to think?