Why is Solana full of Prop AMMs, but there is still a blank space on EVM?

Original Title: Must-Watch dApps After Monad Mainnet Launch

Original Author: Optimus, Founder of Waterloo Blockchain

Original Compilation: Dingdang, Odaily Planet Daily

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 are Prop AMMs, 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 are Prop AMMs?

Prop AMMs are automated market makers actively managed by a single professional market maker for liquidity and pricing, rather than relying on the public to provide funds passively as traditional AMMs do.

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 contrast, in Prop AMMs, 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's discovery), and its invariant k depends on internal variables multx, multy, and concentration. The following diagram illustrates how market makers continuously update these variables.

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

Review: How do AMMs Determine Prices?

In this article, we will frequently refer to the concept of "pricing curve." The pricing curve determines the price a user must pay when trading with an AMM and is also the part that market makers continuously update in Prop AMMs. 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 precisely why x*y=k is referred to as the "pricing 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 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 your quotes with a mathematical curve? You only need to update a few parameters that define this curve, turning the O(N) operation into a constant complexity of O(1).

To intuitively demonstrate how the "pricing 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 pricing 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 coexist simultaneously. As market makers update the pricing 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 pricing 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—they enable market makers to provide dynamic and deep liquidity with higher capital and computational efficiency.

Why is Solana's Architecture Well-Suited for Prop AMMs?

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

1. Cheap updates

2. Priority execution

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

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

Second, if market makers cannot get their updates to the top of the block, their old quotes will be "sniped" by arbitrageurs, resulting in 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 @SliceAnalytics data, this market maker updates its quotes up to 74 times per second.

Players from EVM might ask, "With Solana's slot being about 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 EVM's discrete block model.

· EVM: Transactions are typically executed in order 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, which is 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, while the implementation of Prop AMMs on Solana is a black box, there are libraries like Pinocchio that can optimize the way CU is consumed when writing Solana programs. Helius's blog provides an excellent 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 based on the Fee / Compute Units ratio, similar to how EVM works with Gas.

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

· If not using: Priority = (Priority Fee + Base Fee) / (1 + CU Cap + Signature CU + Write Lock CU)

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 cost as low as 109 CU, with a total fee of only 0.000007506 SOL.

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

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

Why Haven't Prop AMMs Been Implemented on EVM?

Assuming that the updates of Prop AMMs involve writing variables that determine the trading pair's pricing curve. 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 AMMs on Sui: the decision variables for trading pair quotes are written into the smart contract via an update function.

Thanks to @markoggwp for the discovery!

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

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

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

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

· SSTORE (non-zero → non-zero): ~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 numbers 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:

1. High Gas consumption makes it difficult to guarantee priority fees for updates, and lower priority fees cannot achieve a high fee/Gas ratio. To ensure that updates are not front-run and are at the top of the block, higher priority fees are needed, thus increasing costs.

2. The risk of arbitrage is higher on EVM, where the Gas ratio for updates to swaps is only 1:10, while on Solana it is 1:1000. This means that arbitrageurs only need to raise their priority fee by 10 times to front-run market makers' updates, while on Solana, they need to raise it by 1000 times. At this lower ratio, arbitrageurs are more likely to front-run price updates to obtain stale quotes because the costs are low.

Some innovations (like EIP-1153's TSTORE for temporary storage) offer writes at around 100 gas, but this storage is transient and only valid within a single transaction, making it unsuitable for persisting price updates for subsequent swap transactions (e.g., throughout an entire block).

How to Introduce Prop AMMs 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 updates 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 minimal, allowing for a high fee/CU ratio even with low fees, especially compared to swap transactions.

So, how can block-top Prop AMM updates be introduced 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 issue on EVM, the method of reducing write costs is less feasible, as cheap SSTORE would 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.

@MarkToda from the Uniswap team 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 pricing 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 fees to prevent garbage transactions.

Note: Transactions must be sent directly to the global storage address to ensure they are 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 pricing curve data from the global storage contract during swaps to provide quotes.

This architecture cleverly addresses two issues:

1. Protection: The builder strategy creates a "fast lane," ensuring that all price updates within the block are executed before transactions, eliminating front-running risks.

2. Cost-effectiveness: 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 for the top block reserved for update transactions in the local fee market, significantly reducing costs.

User transactions will execute based on the pricing curve set by the market maker's initial updates in the same block, ensuring the freshness and safety 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 standard EVM architecture makes such operations costly and risky, new designs provide 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 block-top oracle updates.

Open Questions

· Is the speed of 200ms Flashblocks for Prop AMMs 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 AMMs?

· Prop AMMs on Solana consume only about 100 CUs for updates. How is this implemented?

· 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?

· Can optimized EVM programs be written using languages like Yul or Huff, similar to the Pinocchio optimization scheme on Solana?

· How does Prop AMM compare with RFQ?

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

· Jupiter Ultra V3's Ultra Signaling feature allows Prop AMMs to distinguish between harmful and harmless traffic and provide tighter quotes. How important are such aggregator features for Prop AMMs on EVM?