Why is Prop AMM everywhere on Solana, but still blank on EVM?

Original Title: Must-Watch dApps After Monad Mainnet Launch

Original Author: Optimus

Source:

Reprint: Mars Finance

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

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

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

This article mainly discusses three issues: what is Prop AMM, what technical and economic barriers they face on EVM chains, and the promising new architectures that may eventually bring them to the forefront of EVM DeFi.

What is Prop AMM?

Prop AMM is an automated market maker actively managed by a single professional market maker for liquidity and pricing, rather than being funded passively by the public like 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 value. In Prop AMMs, however, the pricing formula is not fixed and 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 the outside world. However, the smart contract code of Obric's Prop AMM on the Sui chain is public (thanks to @markoggwp's discovery), and its invariant k depends on the internal variables mult_x, mult_y, and concentration. The diagram below shows how market makers continuously update these variables.

One point that needs clarification is that the formula on the left side of the Obric pricing curve is more complex than the simple x*y, but the key to understanding Prop AMM is that it is always equal to a variable invariant k, and the market makers continuously update this k to adjust the pricing curve.

Review: How does AMM determine prices?

In this article, we will refer to the concept of “price curve” multiple times. The price curve determines the price that users need to pay when trading using AMM, and it is also the part that market makers continuously update in Prop AMM. To better understand this, we can first review the pricing method of traditional AMM.

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. Assuming there are 100 WETH and 400,000 USDC in the pool, the curve point at this time is x = 100, y = 400,000, corresponding to an initial price of 400,000 / 100 = 4,000 USDC/WETH. Therefore, the constant k = 100 * 400,000 = 40,000,000.

If a trader wants to buy 1 WETH, he needs 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 paid about 4,040.40 USDC for 1 WETH, which is slightly higher than the initial price. This phenomenon is called “price slippage.” This is exactly 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 instead of centralized 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 Central Limit Order Book (CLOB). To update your quote, you need to cancel and replace thousands of limit orders. If you have N orders, then the update cost is O(N) level operations, which are slow and expensive on-chain.

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

To intuitively 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 has drawn a chart showing the effective prices when 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 exist simultaneously. As market makers update the price curves, this effective price chart will also change between different slots.

The key point here is that by updating only a small number of 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 particularly suitable for Prop AMM?

Prop AMM is an “actively managed” system, which means it requires two key conditions:

1. Cheap updates

2. Priority Execution

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

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

Secondly, if market makers cannot ensure that their updates are at the top of the block, their old quotes will be “arbitraged” by traders, leading to inevitable losses. Without these two characteristics, 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 its quotes up to 74 times per second.

Players from EVM might ask, “Solana's slot is about 400ms, how can Prop AMM 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 in order after a complete block is proposed and finalized. This means that updates sent in the meantime will take effect only in the next block.

· Solana: Leader validation nodes do not wait for a complete block, but instead break transactions into small data packets (called “shred”) and broadcast them continuously to the network. There may be multiple exchanges within a slot, but shred #1 的价格更新影响 swap #1, shred #2 的价格更新影响 swap #2.

Note: Flashblocks are similar to Solana's shreds. According to Anza Labs' @Ashwinningg's presentation at the CBER conference, the limit for each 400ms slot is 32,000 shreds, which is equivalent to 80 shreds per millisecond. Whether 200ms Flashblocks are fast enough to meet the needs of market makers 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 of all, although the implementation of Prop AMM on Solana is a black box, there are libraries like Pinocchio that can optimize the way to write Solana programs for CU. Helius's blog provides a wonderful introduction to this; through this library, the CU consumption of Solana programs can be reduced from about 4000 CU to around 100 CU.

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

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

Comparing the Compute Units of Prop AMM updates with Jupiter Swap, it can be seen that the updates are extremely cheap, with a ratio of 1:1000.

Prop AMM Update: Simple curve update is extremely cheap. Wintermute's update is as low as 109 CU, with a total cost of only 0.000007506 SOL.

Jupiter Swap: The swap through the Jupiter router can reach ~100,000 CU, with a total fee of 0.000005 SOL.

Due to this huge disparity, market makers only need to pay a minimal fee for updating trades, allowing them to achieve a Fee/CU ratio far exceeding that of exchanges, thereby ensuring that updates are executed at the top of the block and protecting themselves from arbitrage attacks.

Why hasn't Prop AMM been implemented on EVM yet?

Assuming the update of Prop AMM involves writing variables that determine the price curve of trading pairs. Although the Prop AMM code on Solana is a “black box,” and market makers wish to keep their strategies confidential, we can use this assumption to understand how Obric implements Prop AMM on Sui: the determining variables of trading pair quotes are written into the smart contract through the update function.

Thanks to @markoggwp for the discovery!

Using this assumption, we found significant obstacles in the architecture of the EVM that make Solana's Prop AMM model unfeasible on the EVM.

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

On EVM, the Gas consumption of write operations is very high. Compared to the updates on Solana, the cost of writing a value on EVM through the SSTORE opcode is astonishing:

· 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 Computation Units (CU) on Solana. The SSTORE gas number above assumes that each transaction has only one write (cold write), which is reasonable as multiple updates are typically not sent in a single transaction.

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

This leads to two conclusions, making the same Solana Prop AMM model riskier on EVM:

1. High gas consumption leads to difficulties in ensuring priority fees for timely updates. Lower priority fees cannot achieve a high ratio of fees/gas. To ensure that updates are not preemptively executed and are positioned at the top of the block, higher priority fees are required, thus increasing costs.

2. The arbitrage risk on EVM is higher, with the update Gas to swap Gas ratio being only 1:10 on EVM, compared to 1:1000 on Solana. This means arbitrageurs only need to increase the priority fee by 10 times to outpace the market makers' updates, whereas on Solana, they need to increase it by 1000 times. With this lower ratio, arbitrageurs are more likely to trade ahead of price updates to capture stale quotes, as the cost is lower.

Some innovations (such as TSTORE from EIP-1153 for temporary storage) provide about 100 gas for writing, but this storage is ephemeral, only valid for a single transaction, and cannot be used to persist price updates for subsequent swap transactions (for example, throughout an entire block period).

How to introduce Prop AMM into EVM?

Before answering, first address the “why do it”: Users always hope to obtain better trading quotes, which means trading is more cost-effective. The Prop AMM of Ethereum and Layer 2 can provide users with competitive quotes that were originally only available on Solana or centralized exchanges.

To make Prop AMM viable on EVM, let's review one of the reasons for its success on Solana:

· Block Top Update Protection: On Solana, Prop AMM updates are positioned at the block top, protecting market makers from front-running. The updates are at the top because the computational units consume very little, allowing for a high fee/CU ratio even at low costs, especially compared to swap trades.

So, how do we introduce the Prop AMM update at the top of the block into the Layer 2 EVM blockchain? There are two methods: either reduce the write costs or create a priority channel for the Prop AMM update.

Due to the state growth issue of EVM, reducing writing costs is not a feasible method, as cheap SSTORE can lead to garbage state attacks.

We propose to create a priority channel for updating Prop AMM. 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 + specialized block builder strategies:

Its working principle is as follows:

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

· Builder Strategy: This is a key component off-chain. The block builder identifies transactions sent to the global storage contract, allocates 5-10% of the block's Gas to these updating transactions, and prioritizes them by fees to prevent spam transactions.

Please 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 refer to rblib.

Prop AMM Integration: The Prop AMM contract of the market maker reads price curve data from the global storage contract during exchanges to provide quotes.

This architecture cleverly solves two problems:

1. Protection: The Builder strategy creates a “fast lane” to ensure that all price updates within the block are executed before the transaction, eliminating the risk of front-running.

2. Cost-effectiveness: Market makers no longer compete with all DeFi users for high Gas Price to reach top block transactions, but only need to compete for the top block of updated transaction reservations in the local fee market, significantly reducing costs.

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

However, this model also has some drawbacks, and I will leave these issues for discussion at the bottom of this article.

Conclusion

The feasibility of Prop AMM relies on solving core economic issues: low cost and priority execution to prevent front-running.

Although the standard EVM architecture makes such operations costly and risky, new designs offer different approaches to solve this problem. The new design, which combines on-chain global storage smart contracts with 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 AMM feasible on EVM but could also bring transformative changes to all EVM DeFi relying on updates from top-of-block oracles.

Open-ended question

· Is the 200ms Flashblock speed of Prop AMM on EVM enough to compete with the continuous architecture of Solana?

· Most of the AMM traffic on Solana comes from a single aggregator, Jupiter, which provides an SDK for easy AMM integration. However, on Layer 2 EVM, the traffic is scattered across multiple aggregators without a public SDK. Does this pose a challenge to Prop AMM?

· How does the implementation mechanism of Prop AMM on Solana, which only consumes about 100 CU, work?

· The fast track model only guarantees updates at the top of the block. If there are multiple exchanges within a Flashblock, how do market makers update prices between these exchanges?

· 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 to prevent market makers from providing high-quality quotes to lure 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 differentiate between harmful and harmless traffic, providing tighter quotes. What is the significance of such aggregator characteristics for Prop AMM on EVM?