Why is Solana full of Prop AMM while there is still a blank space on EVM?

Compiled by | Odaily Planet Daily (@OdailyChina)

Translator | Dingdang (@XiaMiPP)

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

Proprietary Automated Market Makers (Prop AMMs) are rapidly becoming a dominant force in the Solana DeFi ecosystem, currently contributing over 40% of the trading volume in major trading pairs. These specialized liquidity venues operated by professional market makers can provide deep liquidity and more competitive pricing, primarily because they significantly reduce the risk of market makers being exploited by "stale quotes" for front-running arbitrage.

Image source: dune.com

However, their success is almost entirely confined 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 actively managed by a single professional market maker for liquidity and pricing, rather than relying on the public to provide funds passively 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 a Prop AMM, the pricing formula is not fixed but is updated frequently (often multiple times per second). Since the internal mechanisms of most Prop AMMs are "black boxes," the exact algorithms they use are unknown to outsiders. However, the smart contract code for Obric's Prop AMM on the Sui chain is public (thanks to @markoggwp), and its invariant k depends on internal variables multx, multy, and concentration. The following diagram shows how market makers continuously update these variables.

It should be clarified that the formula on the left side of the Obric pricing curve is more complex than a simple x*y, but the key to understanding Prop AMM is that it always equals a variable invariant k, which the market maker continuously updates to adjust the price curve.

Review: How do AMMs determine prices?

In this article, we will frequently refer to the concept of "price curve." The price curve determines the price users must pay when trading with an AMM and is also the part that market makers continuously update in a Prop AMM. To better understand this, we can first review how traditional AMMs determine prices.

Taking 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 there are 100 WETH and 400,000 USDC in the pool; 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 the WETH in the pool to 99. To maintain the constant product k, the new point (x, y) must still lie on the curve, so y must change to 40,000,000 / 99 ≈ 404,040.40. This means the trader pays about 4,040.40 USDC for 1 WETH, slightly higher than the initial price. This phenomenon is known as "price slippage." This is why x*y=k is referred to as the "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 centralized limit order book (CLOB). If you want to update your quote, you need to cancel and replace thousands of limit orders. If you have N orders, the update cost is O(N), which is slow and expensive on-chain.

But what if you could represent all quotes with a mathematical curve? You only need to update a few parameters that define this curve, transforming the O(N) operation into O(1) constant complexity.

To visually demonstrate how the "price curve" corresponds 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 created a chart showing the effective prices when different amounts of SOL are exchanged 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 simultaneously. As market makers update the price curve, this effective price chart will also change 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 AMM—it allows market makers to provide dynamic and deep liquidity with higher capital and computational efficiency.

Why is Solana's architecture very suitable for Prop AMMs?

Prop AMMs are a type of "actively managed" system, which means they require two key conditions:

Cheap updates
Priority execution

On Solana, these two are complementary: low-cost updates often mean that updates can gain execution priority.

Why do market makers need these two points? First, they continuously update the price curve based on inventory changes or fluctuations in asset index prices (such as centralized exchange prices) at the speed of blockchain operation. On high-frequency chains like Solana, if the update cost is too high, it will be difficult to achieve high-frequency adjustments.

Second, if market makers cannot prioritize their updates at the top of the block, their old quotes will be "sniped" by arbitrageurs, resulting in inevitable losses. Without these two features, market makers cannot operate efficiently, and users will receive worse trading prices.

Taking the Prop AMM HumidiFi on Solana as an example, according to data from @SliceAnalytics, this market maker updates quotes up to 74 times per second.

Players from EVM may ask: "With Solana's slot (approximately 400ms), how can Prop AMMs update prices multiple times within a single slot?"

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

EVM: Transactions are typically executed sequentially after a complete block is proposed and finalized. This means that updates sent in between will only take effect in the next block.
Solana: Leader validator nodes do not wait for a complete block but continuously broadcast transactions as small data packets (called "shreds") to the network. There may be multiple swaps within a single slot, but the price update from shred #1 affects swap #1, while the price update from shred #2 affects swap #2.

Note: Flashblocks are similar to Solana's shreds. According to @Ashwinningg from Anza Labs' presentation 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 remains an open question compared to Solana's continuous architecture.

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

First, although the implementation of Prop AMMs on Solana is a black box, there are libraries like Pinocchio that can optimize the way Compute Units (CU) are written in Solana programs. Helius' blog provides an excellent introduction to this, showing that the CU consumption of Solana programs can be reduced from about 4000 CU to around 100 CU.

Image source: github

Now, let's look at 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 Gas in EVM), similar to EVM.

Specifically, if using Jito, the formula is Jito Tip / Compute Units
If not using: Priority = (Priority Fee + Base Fee) / (1 + CU Limit + Signature CU + Write Lock CU) (https://solana.com/docs/core/fees)

Comparing the Compute Units for Prop AMM updates with those for Jupiter Swap, we can see that updates are extremely cheap, with a ratio of 1:1000.

Prop AMM Updates: Simple curve updates are very cheap. Wintermute's updates are as low as 109 CU, with a total cost of only 0.000007506 SOL.

Jupiter Swap: Swaps through Jupiter routing can reach ~100,000 CU, with a total cost 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 that updates are executed at the top of the block, protecting themselves from arbitrage attacks.

Why Haven't Prop AMMs Landed on EVM?

Assuming that the updates of Prop AMMs involve writing variables that determine the price curve of trading pairs. Although the 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 decision variables for trading pair quotes are written into the smart contract through an update function.

Thanks to @markoggwp for the discovery!

Using this assumption, we find that the architecture of EVM presents significant obstacles that make the Solana Prop AMM model unfeasible on EVM.

To recap, on OP-Stack Layer 2 blockchains (like Base and Unichain), transactions are prioritized based on the Gas priority fee (similar to how Solana sorts by Fee / CU).

On EVM, the Gas consumption for write operations is very high. The cost of writing a value using the SSTORE opcode on EVM is staggering compared to updates on Solana:

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 above SSTORE gas figures assume that each transaction has only one write (cold write), which is reasonable since multiple updates are typically not sent in a single transaction.

While updates are still cheaper than swaps, the gas usage ratio is only about 10 times (updates may involve multiple SSTORE), whereas on Solana, this ratio is about 1000 times.

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

High Gas consumption makes it difficult to guarantee priority fees for updates, and lower priority fees cannot achieve a high fee rate/Gas ratio. To ensure that updates are not executed ahead of time and are at the top of the block, higher priority fees are needed, increasing costs.
Higher arbitrage risk on EVM, with the Gas ratio for updates to swaps on EVM being only 1:10, while on Solana it is 1:1000. This means arbitrageurs only need to increase the priority fee by 10 times to front-run market makers' updates, whereas on Solana, they need to increase it by 1000 times. At this lower ratio, arbitrageurs are more likely to front-run price updates to obtain stale quotes due to the low cost.

Some innovations (like EIP-1153's TSTORE for temporary storage) offer writes at around 100 gas, but this storage is ephemeral, only valid within a single transaction, and cannot be used to persist price updates for subsequent swap transactions (e.g., throughout the entire block period).

How to Introduce Prop AMM to EVM?

Before answering, let's address "why do it": users always want better trading quotes, which means trading is more cost-effective. 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 revisit 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 front-running. Updates are at the top because the Compute Unit consumption is extremely low, allowing for a high fee/CU ratio even with low fees, especially compared to swap transactions.

So, how can we bring block top Prop AMM updates to Layer 2 EVM blockchains? There are two methods: either reduce write costs or create a priority channel for Prop AMM updates.

Due to the state growth issues in EVM, the method of reducing write costs is less feasible, as cheap SSTORE could lead to garbage state attacks.

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

The Uniswap team's @MarkToda proposed a new method to achieve this through global storage smart contracts + dedicated block builder strategies:

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 into this contract (e.g., set(ETH-USDC_CONCENTRATION, 4000)).
Builder Strategy: This is a key off-chain component. The block builder identifies transactions sent to the global storage contract, allocates the top 5–10% Gas of the block to these update transactions, and prioritizes them by fee to prevent garbage transactions.

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

An example of a custom block building algorithm can be referenced in 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 addresses two issues:

Protection: The builder strategy creates a "fast lane," ensuring that all price updates in the block are executed before transactions, eliminating front-running risks.
Cost Efficiency: Market makers no longer compete with all DeFi users for high Gas Price transactions at the top of the block; they only need to compete in the local fee market for the top block reserved for update transactions, significantly reducing costs.

User transactions will execute based on the price curve set by market makers in the initial updates of the same block, ensuring the freshness and security of quotes. This model replicates 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, and I will leave these issues for discussion at the end of this article.

Conclusion

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

While the standard EVM architecture makes such operations costly and risky, new designs offer different approaches to address this issue. The combination of on-chain global storage smart contracts and off-chain builder strategies can create dedicated "fast lanes" that ensure updates are executed at the top of the block while establishing a local, controlled fee market. This not only makes Prop AMMs feasible on EVM but could also revolutionize all EVM DeFi that relies on top-of-block oracle updates.

Open Questions

Is the 200ms Flashblock speed of Prop AMM on EVM sufficient to compete with Solana's continuous architecture?
Most AMM traffic on Solana comes from a single aggregator, Jupiter, which provides an SDK for easy AMM integration. However, on Layer 2 EVM, traffic is dispersed across multiple aggregators without a public SDK. Does this pose a challenge for Prop AMM?
Prop AMM updates on Solana consume only about 100 CU. What is the mechanism behind this implementation?
The fast lane model only guarantees updates at the top of the block. 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 scheme on Solana?
How does Prop AMM compare to RFQ?
How can we prevent market makers from providing attractive quotes to users in block N and then updating to poor quotes in block N+1? How does Jupiter safeguard against this?
The Ultra Signaling feature of Jupiter Ultra V3 allows Prop AMM to distinguish between harmful and harmless traffic and provide tighter quotes. How important are these aggregator characteristics for Prop AMM on EVM?

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。