Cover photo

PropAMMs: The Rise of Programmable Market Makers

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.

post image

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.

Based L3 Appchains, Synchronous Composability and Programmable Market Makers

Baibai approaches this problem differently to other PropAMMs. We use a based L3 appchain architecture. In practice, this means the market-making logic and price updates run in a dedicated execution environment, while users continue to interact from the L2.

Users remain on Base.

Market makers operate on the L3 appchain.

This separation matters because execution on the appchain is cheap enough that market makers can continuously update pricing logic without pushing meaningful additional costs onto traders.

The important detail is that the swap itself still happens on the L2, but the pricing logic is composed with state from the appchain at execution time. The AMM curve becomes less important than the ability to retrieve a fresh executable price.

In practice, the L2 queries the L3 for pricing data. Before the swap executes, the market maker submits an updated pricing state to the appchain. The sequencer then observes both the state update and the swap within the same sequencing window, allowing the transaction to execute against pricing that was refreshed immediately before inclusion. Rather than relying on stale liquidity positions or periodically refreshed curves, execution composes directly with continuously updated market state.

Conceptually, it starts to resemble synchronous composability across execution domains. Instead of treating the appchain as an isolated environment, the L2 swap effectively composes with market-making logic executing elsewhere, but still within the same sequencing window. This design fits naturally alongside emerging preconfirmation systems such as ETHGas or more direct integrations with sequencers and block builders. The later a market maker can observe the state before committing a quote, the more accurately it can price risk and the tighter spreads it can theoretically offer. Today, this is a best-efforts predictive model in which price updates are inserted alongside the swap and calculated at the point of submission to the sequencer. But we think tighter sequencer integration could push this much closer to real-time state updates.

post image

In many ways, this shifts the AMM's role entirely. Liquidity increasingly stops being the mechanism for price discovery and instead becomes infrastructure for executing against externally generated prices.

Ethereum trading primitives have steadily evolved from simple peer-to-peer swaps to passive liquidity curves, to increasingly programmable and adaptive systems. PropAMMs push that trajectory even further. They blur the boundary between market maker, execution engine and settlement layer, while forcing DeFi to confront deeper questions about composability, latency, openness, centralisation and where intelligence should live (and who ultimately controls it) within the stack. Some of these designs may ultimately fail or drift too far toward opaque off-chain systems, but that tension is precisely what makes them important.

DeFi has always progressed by pulling more financial logic onchain, then discovering the limits of what onchain systems can support. PropAMMs feel like the latest attempt to push that boundary again.

Our view is that the next step is not simply building faster market makers. DeFi will never compete with high-frequency trading firms operating at sub-microsecond latencies inside highly optimised private infrastructure. Instead, the opportunity lies in extending Ethereum to make it even more composable. Fully customisable execution environments where complex programmable liquidity can evolve without sacrificing the composability that made DeFi powerful in the first place.

We think synchronously composable based appchains are one of the best ways to keep pushing Ethereum forward without giving up the things that made this whole experiment exciting to begin with.