Why is Solana filled with Prop AMMs, but still blank on EVM?

Original Article Title: Must-Watch dApps After Monad Mainnet Launch

Original Article Author: @0xOptimus

Original Article Translation: Dingdang, Odaily Planet Daily

Proprietary AMMs have rapidly captured 40% of Solana's total trading volume. Why haven't they appeared on the EVM yet?

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

Image Source: dune.com

However, their success has been almost entirely limited to Solana. Even on fast and low-cost Layer 2 networks like Base or Optimism, the presence of Prop AMMs in the EVM ecosystem is rare. Why have they not taken root on the EVM?

This article mainly explores three issues: what Prop AMMs are, the technical and economic barriers they face on the EVM chain, and the promising new architectures that may eventually bring them to the forefront of EVM DeFi.

What Are Prop AMMs?

Proprietary AMMs are a type of automated market maker where a single professional market maker actively manages liquidity and pricing, rather than having funds passively provided by the public as in traditional AMMs.

Traditional AMMs (such as Uniswap v2) usually use the formula x * y = k to determine the price, where x and y represent the quantities of the two assets in the pool, and k is a constant. In Prop AMMs, the pricing formula is not fixed but is frequently updated (often multiple times per second). Since the internal mechanics of most Prop AMMs are considered a "black box," the outside world does not know the exact algorithm they use. However, the Prop AMM smart contract code on the Sui chain from Obric is public (thanks to @markoggwp's discovery), where the invariant k depends on the internal variables mult_x, mult_y, and concentration. The image below shows how the market maker continuously updates these variables.

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

Review: How Does AMM Determine Prices?

In this article, we will mention the concept of a "price curve" multiple times. The price curve determines the price users need to pay when trading using an AMM and is the part that liquidity providers continuously update in the Prop AMM. To better understand this, we can first review the pricing mechanism of a traditional AMM.

Taking the example of the WETH-USDC pool on Uniswap v2 (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 current curve point is x = 100, y = 400,000, corresponding to an initial price of 400,000 / 100 = 4,000 USDC/WETH. This gives a constant k = 100 * 400,000 = 40,000,000.

If a trader wishes 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 become 40,000,000 / 99 ≈ 404,040.40. This means the trader paid around 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 called a "price curve": any tradable price must fall on this curve.

Why Do Liquidity Providers Choose AMM Design Over Centralized Order Book (CLOB)?

Let's explain why liquidity providers would want to use AMM design for providing liquidity. Imagine you are a market maker quoting on a on-chain Central Limit Order Book (CLOB). If you want to update your quote, you would need to cancel and replace thousands of limit orders. If you have N orders, the update cost is an O(N) operation, which is slow and expensive on-chain.

But what if you could represent all quotes with a mathematical curve? By simply updating a few key parameters defining this curve, you can transform an O(N) operation into a constant O(1) complexity.

To visually demonstrate how the "Price Curve" corresponds to different effective price ranges, we can refer to SolFi created by Ellipsis Labs—a Solana-based Prop AMM. Although its specific price curve is unknown and hidden, Ghostlabs has created a graph showing the effective price when exchanging varying amounts of SOL for USDC within a certain Solana slot (block time period). Each line represents a different WSOL/USDC pool, illustrating that multiple price tiers can coexist. As the liquidity provider updates the price curve, this effective price graph will also change between different slots.

Image Source: GitHub

The key here is that by updating only a few price curve parameters, liquidity providers can dynamically alter the effective price distribution at any time without having to modify each of the N orders individually. This is precisely the core value proposition of Prop AMM—it enables liquidity providers to offer dynamic and deep liquidity with higher capital and computational efficiency.

Why is Solana's Architecture Ideal for Prop AMM?

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

1. Low Update Costs

2. Priority Execution

In Solana, these two aspects are intertwined: Low-cost updates often mean that updates can have priority execution.

But why do liquidity providers need these two points? First, they will continuously update the price curve based on inventory changes or fluctuations in asset index prices (e.g., centralized exchange prices) at the speed of blockchain. On a high-frequency chain like Solana, if the update costs are too high, achieving high-frequency adjustments would be challenging.

Secondly, if a liquidity provider cannot get their update included at the top of a block, their old quote will be "front-run" by arbitrageurs, resulting in inevitable loss. Without these two features, liquidity providers cannot operate efficiently, and users would receive worse trade prices.

Using the example of the Prop AMM HumidiFi on Solana, according to @SliceAnalytics data, the liquidity provider updates its quote up to 74 times per second.

Players coming from the EVM may ask: "Solana's slot is approximately 400ms, how can Prop AMM update the price 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 typically execute sequentially after a full block is proposed and finally confirmed. This means that updates sent in the middle take effect in the next block.

· Solana: Leader Validator nodes do not wait for a full block; instead, they break transactions into small data packets (called "shreds") and continuously broadcast them to the network. Within a slot, there may be multiple exchanges, 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 Anza Labs' @Ashwinningg at the CBER conference, the slot's limit of 32,000 shreds every 400ms equates to 80 shreds per millisecond. Whether 200ms Flashblocks are fast enough to meet liquidity provider requirements remains an open question compared to Solana's continuous architecture.

So, why are updates on Solana so cheap? And what leads to their priority execution?

Firstly, although the implementation of Prop AMM on Solana is a black box, there is a library like Pinocchio that optimizes the way CUs are written in Solana programs. Helius' blog provides a wonderful explanation. With this library, the CU consumption of Solana programs can be reduced from around 4000 CUs to approximately 100 CUs.

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 EVM's Gas), similar to the EVM.

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

· Otherwise: Priority = (Tip + Base Fee) / (1 + CU Limit + Signature CU + Write Lock CU)

Comparing the Compute Units of a Prop AMM update to Jupiter Swap, it is evident that the update is extremely cheap, with a ratio of 1:1000.

Prop AMM Update: The simple curve update is very inexpensive. Wintermute's update is as low as 109 CU, with a total cost of only 0.000007506 SOL

Jupiter Swap: A swap through the Jupiter route can reach ~100,000 CU, with a total cost of 0.000005 SOL

Due to this significant difference, liquidity providers only need to pay a minimal fee for update transactions, achieving a much higher Fee/CU ratio than exchanges, ensuring that updates are executed at the top of the block, protecting themselves from arbitrage attacks.

Why Has Prop AMM Not Yet Landed on EVM?

Assuming that a Prop AMM update involves writing to a variable that determines the price curve of the asset pair. Although Prop AMM's code on Solana is a "black box," with liquidity providers wanting to keep their strategies confidential, we can use this assumption to understand how Obric implemented Prop AMM on Sui: the variable determining the asset pair's price is written to the smart contract through an update function.

Thanks to @markoggwp for the discovery!

With this assumption, we found a significant barrier in the architecture of the EVM that renders Solana's Prop AMM model unfeasible on the EVM.

Recall that on OP-Stack Layer 2 blockchains (such as Base and Unichain), transactions are prioritized based on per-Gas fees (similar to Solana's Fee/CU sorting).

On the EVM, the Gas cost of write operations is extremely high. Compared to Solana's updates, the cost of writing a value on the EVM via the SSTORE opcode is staggering:

· 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 the EVM is similar to Computational Units (CUs) on Solana. The SSTORE gas numbers above assume each transaction has only one write (cold write), which is reasonable as multiple updates are not typically sent within one transaction.

While updates are still cheaper than swaps, the gas efficiency is only about 10x (updates may involve multiple SSTOREs), whereas on Solana, this ratio is around 1000x.

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

1. High Gas costs make it difficult to ensure update priority: Lower gas fees cannot secure a high fee/Gas ratio. To ensure updates are not front-run and are placed at the top of a block, higher gas fees are needed, increasing costs.

2. Higher arbitrage risk on the EVM: The update Gas to swap Gas ratio on the EVM is only 1:10, while on Solana, it is 1:1000. This means arbitrageurs only need to increase fees by 10x to front-run a liquidity provider's update, compared to 1000x on Solana. In this lower ratio scenario, arbitrageurs are more likely to front-run price updates to capture stale quotes due to the low cost.

Some innovations (such as EIP-1153's TSTORE for temporary storage) provide a write cost of around 100 gas, but this storage is ephemeral, only valid within a single transaction and cannot be used to persist price updates for later use in derivative trading (e.g., across an entire block period).

How to Introduce Prop AMM to the EVM?

Before answering, let's address "why do it": Users always want better trade quotes, meaning more bang for their buck. Ethereum and Layer 2's Prop AMM can provide users with competitive quotes that previously were only available on Solana or centralized exchanges.

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

· Block-Top Update Protection: On Solana, Prop AMM updates are at the block top to shield liquidity providers from front-running. Top updates are possible because the computational unit cost is minimal, allowing even low fees to achieve a high fee/CU ratio, especially compared to derivative trades.

So, how can we introduce block-top Prop AMM updates to a Layer 2 EVM blockchain? There are two approaches: either reduce the write cost or create a priority channel for Prop AMM updates.

Due to the EVM's state growth issue, reducing the write cost approach is less viable, as cheap SSTOREs would lead to state bloat attacks.

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

Uniswap's @MarkToda has proposed a new approach, leveraging a Global Storage Smart Contract + Dedicated Block Builder Strategy:

Here's how it works:

· Global Storage Contract: Deploy a simple smart contract as a public key-value store. Liquidity providers write price curve parameters to 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 5–10% of the block's Gas to these update transactions, prioritizes them by fee, and sorts them to prevent spam transactions.

Please note: Transactions must be sent directly to the global storage address to guarantee placement at the top of the block.

Custom block building algorithm examples can be found in rblib.

Prop AMM Integration: The Prop AMM contract of liquidity providers reads price curve data from the global storage contract during swaps to provide quotes.

This architecture adeptly addresses two issues:

1. Protection: The builder strategy creates a "fast lane" to ensure all price updates in the block are executed before transactions, eliminating frontrunning risk.

2. Cost Efficiency: Liquidity providers no longer compete with all DeFi users for high Gas Prices to get into the top of the block; instead, they only need to compete for the top block reserved for update transactions in the local fee market, significantly reducing costs.

User transactions will execute based on the price curve set by the liquidity provider at the start of the same block, ensuring the freshness and security of quotes. This model replicates the low-cost, high-priority update environment on Solana in the EVM, paving the way for Prop AMM on the EVM.

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

Conclusion

The feasibility of Prop AMM depends on addressing a core economic issue: cheap and priority execution to prevent frontrunning.

While the standard EVM architecture makes such operations costly and risky, new designs offer different approaches to solve this problem. By combining on-chain global storage smart contracts and off-chain builder strategy in the new design, a dedicated "fast lane" can be created to ensure top-of-block execution of updates, while establishing a local, controlled fee market. This not only makes Prop AMM viable on the EVM but may also revolutionize all EVM DeFi relying on block top oracle updates.

Open Questions

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

· On Solana, most AMM traffic comes from a single aggregator called Jupiter, which provides an SDK for easy AMM integration. However, on Layer 2 EVM, traffic is dispersed across multiple aggregators with no public SDK. Does this pose a challenge to Prop AMM?

· On Solana, Prop AMM updates consume only about 100 CUs. What is the implementation mechanism behind this efficiency?

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

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

· How does Prop AMM compare to RFQ?

· How can we prevent liquidity providers from offering competitive quotes in Block N to entice users and then updating to uncompetitive quotes in Block N+1? How does Jupiter mitigate this risk?

· The Ultra Signaling feature of Jupiter Ultra V3 allows Prop AMM to differentiate between harmful and benign traffic, providing tighter quotes. How crucial are these aggregator features for Prop AMM on EVM?