Why is Prop AMM flourishing on Solana but still absent on EVM?

Original Title: Must-Watch dApps After Monad Mainnet Launch

Author: Optimus, Founder of Waterloo Blockchain

Translated by: Dingdang, Odaily

Prop AMMs have rapidly captured 40% of all trading volume on Solana. Why haven’t they appeared on EVM yet?

Proprietary Automated Market Makers (Prop AMMs) are quickly becoming the dominant force in the Solana DeFi ecosystem, now accounting for over 40% of trading volume in major pairs. These specialized liquidity venues, operated by professional market makers, can provide deep liquidity and more competitive pricing, mainly because they significantly reduce the risk of market makers being front-run by arbitrageurs exploiting “stale quotes.”

Image source: dune.com

However, their success is almost entirely limited to Solana. Even on fast and low-cost Layer 2 networks like Base or Optimism, Prop AMMs are rarely seen in the EVM ecosystem. Why haven’t they taken root on EVM?

This article mainly explores three questions: What is a Prop AMM, what technical and economic barriers do they face on EVM chains, and what promising new architectures might eventually bring them to the forefront of EVM DeFi.

What is a Prop AMM?

A Prop AMM is an automated market maker where liquidity and pricing are actively managed by a single professional market maker, rather than passively provided by the public as in traditional AMMs.

Traditional AMMs (like Uniswap v2) typically use the formula x * y = k to determine prices, where x and y represent the quantities of two assets in the pool, and k is a constant. In Prop AMMs, the pricing formula is not fixed but is updated at high frequency (often multiple times per second). Since the internal mechanisms of most Prop AMMs are “black boxes,” outsiders do not know the exact algorithms used. However, the Prop AMM smart contract code of Obric on Sui is open source (thanks to @markoggwp’s discovery), and its invariant k depends on internal variables mult_x, mult_y, and concentration. The diagram below shows how market makers continuously update these variables.

One point to clarify: the formula on the left side of Obric’s pricing curve is more complex than simple x*y, but the key to understanding Prop AMMs is that—it always equals a variable invariant k, and the market maker continuously updates this k to adjust the price curve.

Review: How do AMMs determine price?

In this article, we will mention the concept of “price curve” multiple times. The price curve determines the price users pay when trading with an AMM, and it is the part that market makers continuously update in Prop AMMs. To better understand this, let’s review how traditional AMMs set prices.

Take the WETH-USDC pool on Uniswap v2 as an example (assuming no fees). The price is passively determined by the formula x * y = k. Suppose the pool has 100 WETH and 400,000 USDC, the curve point is x = 100, y = 400,000, corresponding to an initial price of 400,000 / 100 = 4,000 USDC/WETH. Thus, the constant k = 100 * 400,000 = 40,000,000.

If a trader wants to buy 1 WETH, they need to add USDC to the pool, reducing WETH to 99. To maintain the constant product k, the new point (x, y) must still lie on the curve, so y must become 40,000,000 / 99 ≈ 404,040.40. That is, the trader pays about 4,040.40 USDC for 1 WETH, slightly higher than the initial price. This phenomenon is called “slippage.” This is why x*y=k is called a “price curve”: any tradable price must lie on this curve.

Why do market makers choose AMM design over Centralized Limit Order Books (CLOB)?

Let’s explain why market makers want to use AMM design for market making. Imagine you are a market maker quoting on an on-chain CLOB. To update your quotes, you need to cancel and replace thousands of limit orders. If you have N orders, updating them is an O(N) operation, which is slow and expensive on-chain.

But what if you could represent all your quotes with a single mathematical curve? You would only need to update a few parameters defining this curve, turning an O(N) operation into an O(1) constant complexity.

To visually demonstrate how “price curves” correspond to different effective price ranges, we can refer to SolFi, created by Ellipsis Labs—a Prop AMM based on Solana. Although its specific price curve is unknown and hidden, Ghostlabs drew a chart showing the effective price for exchanging different amounts of SOL for USDC within a certain Solana slot (block time period). Each line represents a different WSOL/USDC pool, indicating that multiple price levels can coexist. As market makers update the price curve, this effective price chart also changes between different slots.

Image source: github

The key point here is that, by updating only a few price curve parameters, market makers can change the effective price distribution at any time without having to modify N orders one by one. This is the core value proposition of Prop AMMs—it allows market makers to provide dynamic and deep liquidity with higher capital and computational efficiency.

Why is Solana’s architecture so suitable for Prop AMMs?

Prop AMMs are “actively managed” systems, which means they require two key conditions:

1. Cheap updates

2. Priority execution

On Solana, these two are complementary: cheap updates often mean updates can get execution priority.

Why do market makers need these two points? First, they update the price curve at blockchain speed based on inventory changes or asset index price (e.g., centralized exchange price) fluctuations. On high-frequency chains like Solana, if update costs are too high, high-frequency adjustments become difficult.

Second, if market makers can’t get their updates to the top of the block, their old quotes will be “picked off” by arbitrageurs, resulting in inevitable losses. Without these two features, market makers can’t operate efficiently, and users will get worse trading prices.

Take HumidiFi, a Prop AMM on Solana, as an example. According to @SliceAnalytics, this market maker updates quotes up to 74 times per second.

Players from EVM might ask: “Solana’s slot is about 400ms, how can a Prop AMM update prices multiple times within a single slot?”

The answer lies in Solana’s continuous architecture, which is fundamentally different from EVM’s discrete block model.

· EVM: Transactions are usually executed in order after a full block is proposed and finalized. This means updates sent mid-block only take effect in the next block.

· Solana: Leader validator nodes don’t wait for a full block but break transactions into small packets (called “shreds”) and broadcast them continuously to the network. There may be multiple swaps within a slot, but the price update in shred #1 affects swap #1, and the price update in shred #2 affects swap #2.

Note: Flashblocks are similar to Solana’s shreds. According to @Ashwinningg from Anza Labs at the CBER conference, each 400ms slot has a limit of 32,000 shreds, equivalent to 80 shreds per millisecond. Whether 200ms Flashblocks are fast enough to meet market makers’ needs compared to Solana’s continuous architecture remains an open question.

So, why are updates so cheap on Solana? And how does this lead to priority execution?

First, although Prop AMM implementations on Solana are black boxes, there are libraries like Pinocchio that allow Solana programs to be written in a way that optimizes Compute Units (CU). Helius’s blog has a great introduction to this. With this library, CU consumption for Solana programs can drop from about 4000 CU to about 100 CU.

Image source: github

Now for the second part. At a higher level, Solana prioritizes transactions by selecting those with the highest Fee / Compute Units ratio (Compute Units are similar to EVM’s Gas), similar to EVM.

· Specifically, if using Jito, the formula is Jito Tip / Compute Units

· Not using: Priority = (priority fee + base fee) / (1 + CU limit + signature CU + write lock CU)

Comparing Prop AMM updates and Jupiter Swap’s Compute Units, it’s clear that updates are extremely cheap, with a ratio of 1:1000.

Prop AMM update: Simple curve updates are very cheap. Wintermute’s update is as low as 109 CU, with a total fee of only 0.000007506 SOL

Jupiter Swap: Swaps routed through Jupiter can reach ~100,000 CU, with a total fee of 0.000005 SOL

Due to this huge difference, market makers only need to pay a tiny fee for update transactions to achieve a much higher Fee/CU ratio than swaps, ensuring their updates are executed at the top of the block and protecting themselves from arbitrage attacks.

Why haven’t Prop AMMs been implemented on EVM?

Suppose a Prop AMM update involves writing variables that determine the price curve of a trading pair. Although Prop AMM code on Solana is a “black box” and market makers want to keep their strategies confidential, we can use this assumption to understand how Obric implements Prop AMMs on Sui: the variables determining the trading pair’s quote are written to the smart contract via the update function.

Thanks to @markoggwp for the discovery!

Using this assumption, we find that EVM’s architecture presents major obstacles, making Solana’s Prop AMM model unfeasible on EVM.

Recall that on OP-Stack Layer 2 blockchains (like Base and Unichain), transactions are prioritized by per-Gas priority fee (similar to Solana’s Fee / CU sorting).

On EVM, write operations consume a lot of Gas. Compared to Solana’s updates, writing a value on EVM via the SSTORE opcode is astonishingly expensive:

· SSTORE (0 → non-0): ~22,100 gas

· SSTORE (non-0 → non-0): ~5,000 gas

· Typical AMM swap: ~200,000–300,000 gas

Note: Gas on EVM is similar to Compute Units (CU) on Solana. The SSTORE gas numbers above assume each transaction only has one write (cold write), which is reasonable since multiple updates are rarely sent in a single transaction.

Although updates are still cheaper than swaps, gas usage is only about 10 times less (updates may involve multiple SSTOREs), while on Solana, the ratio is about 1000 times.

This leads to two conclusions that make the same Solana Prop AMM model riskier on EVM:

1. High gas consumption makes it hard for priority fees to guarantee update priority, and lower priority fees can’t achieve a high fee/Gas ratio. To ensure updates aren’t front-run and are at the top of the block, higher priority fees are needed, increasing costs.

2. Higher arbitrage risk on EVM, as the update-to-swap gas ratio is only 1:10 on EVM, compared to 1:1000 on Solana. This means arbitrageurs only need to raise their priority fee 10 times to front-run a market maker’s update, while on Solana, it would need to be 1000 times. With this lower ratio, arbitrageurs are more likely to front-run price updates to exploit stale quotes, as the cost is low.

Some innovations (like EIP-1153’s TSTORE for transient storage) offer about 100 gas per write, but this storage is temporary and only valid within a single transaction, so it can’t be used to persist price updates for subsequent swaps (e.g., throughout a block).

How can Prop AMMs be brought to EVM?

Before answering, let’s address “why do it”: users always want better trading quotes, meaning more favorable trades. Prop AMMs on Ethereum and Layer 2 can provide users with competitive quotes that were previously only available on Solana or centralized exchanges.

To make Prop AMMs feasible on EVM, let’s recall one of the reasons for their success on Solana:

· Block-top update protection: On Solana, Prop AMM updates are at the top of the block, protecting market makers from being front-run. Updates are at the top because compute unit consumption is extremely low, so even with low fees, a high fee/CU ratio can be achieved, especially compared to swaps.

So, how can block-top Prop AMM updates be introduced to Layer 2 EVM blockchains? There are two ways: either lower write costs or create a priority channel for Prop AMM updates.

Due to EVM’s state growth problem, lowering write costs is not feasible, as cheap SSTORE would lead to state bloat attacks.

We propose creating a priority channel for Prop AMM updates. This is a feasible solution and the focus of this article.

@MarkToda from the Uniswap team proposed a new approach using a global storage smart contract + specialized block builder strategy:

Here’s how it works:

· Global storage contract: Deploy a simple smart contract as a public key-value store. Market makers write price curve parameters to this contract (e.g., set(ETH-USDC_CONCENTRATION, 4000)).

· Builder strategy: This is the key off-chain component. The block builder identifies transactions sent to the global storage contract, allocates the first 5–10% of block Gas to these update transactions, and sorts them by fee to prevent spam.

Note: Transactions must be sent directly to the global storage address, or they cannot be guaranteed to be at the top of the block.

For an example of a custom block building algorithm, see rblib.

Prop AMM integration: The market maker’s Prop AMM contract reads price curve data from the global storage contract during swaps to provide quotes.

This architecture cleverly solves two problems:

1. Protection: The builder strategy creates a “fast lane,” ensuring all price updates in the block are executed before trades, eliminating front-running risk.

2. Cost-effectiveness: Market makers no longer compete with all DeFi users for high Gas Price to get block-top transactions, but only compete in a local fee market for the reserved block-top update transactions, greatly reducing costs.

Users’ trades will be executed based on the price curve set by the market maker’s initial update in the same block, ensuring the freshness and security of quotes. This model recreates the low-cost, high-priority update environment of Solana on EVM, paving the way for Prop AMMs on EVM.

However, this model also has some drawbacks, which I leave for discussion at the end of this article.

Conclusion

The feasibility of Prop AMMs depends on solving a core economic problem: cheap and prioritized execution to prevent front-running.

While standard EVM architecture makes such operations costly and risky, new designs offer different ways to address this. Combining on-chain global storage smart contracts with off-chain builder strategies, a dedicated “fast lane” can be created to guarantee block-top updates while establishing a local, controlled fee market. This not only makes Prop AMMs feasible on EVM but could also transform all EVM DeFi that relies on block-top oracle updates.

Open Questions

· Is the 200ms Flashblock speed on EVM sufficient to compete with Solana’s continuous architecture for Prop AMMs?

· Most AMM traffic on Solana comes from a single aggregator, Jupiter, which provides an SDK for easy AMM integration. But on Layer 2 EVM, traffic is spread across multiple aggregators with no public SDK. Does this pose a challenge for Prop AMMs?

· Prop AMM updates on Solana consume only about 100 CU. How is this achieved?

· The fast lane model only guarantees block-top updates. If there are multiple swaps within a Flashblock, how can market makers update prices between these swaps?

· Is it possible to write optimized EVM programs using languages like Yul or Huff, similar to the Pinocchio optimization on Solana?

· How do Prop AMMs compare to RFQ?

· How can we prevent market makers from offering attractive quotes in block N to lure users, then updating to poor quotes in block N+1? How does Jupiter prevent this?

· Jupiter Ultra V3’s Ultra Signaling feature allows Prop AMMs to distinguish between toxic and non-toxic flow and provide tighter quotes. How important are such aggregator features for Prop AMMs on EVM?

Original Link