Author | @0xOptimus

Compiled by Odaily Planet Daily ( @OdailyChina )

Translator | Dingdang ( @XiaMiPP )

Prop AMMs have quickly captured 40% of all Solana transaction volume. Why aren’t they on the EVM yet?

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

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, Prop AMMs are still rare in the EVM ecosystem. Why haven't they taken root on the EVM?

This article explores three main questions: what are Prop AMMs, what technical and economic hurdles do they face on the EVM chain, and the promising new architectures that could eventually bring them to the forefront of EVM DeFi.

What is Prop AMM?

Prop AMM is an automated market maker in which liquidity and pricing are actively managed by a single professional market maker, rather than passively funded by the public like traditional AMMs.

Traditional AMMs (such as Uniswap v2) typically use the formula x * y = k to determine prices, where x and y represent the quantities of the two assets in the pool, respectively, and k is a constant. In Prop AMMs, however, the pricing formula is not fixed but is updated frequently (typically multiple times per second) . Because the internal mechanisms of most Prop AMMs are "black boxes," the exact algorithms they use are unknown. However, the code for Obric's Prop AMM smart contract on the Sui chain is public (thanks to @markoggwp for his discovery), and its invariant k depends on the internal variables mult_x, mult_y, and concentration. The figure below illustrates how the market maker continuously updates these variables.

One thing that needs to be clarified is that the formula on the left side of the Obric pricing curve is more complicated than a simple x*y, but the key to understanding Prop AMM is that it is always equal to a mutable invariant k, and the market maker will constantly update this k to adjust the price curve.

Review: How does AMM determine price?

Throughout this article, we'll be referring to the concept of the "price curve" several times. The price curve determines the price users pay when trading with an AMM and is the component that market makers constantly update in Prop AMMs. To better understand this, let's first review how traditional AMMs are priced.

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. Assuming there are 100 WETH and 400,000 USDC in the pool, the curve points are x = 100 and y = 400,000, corresponding to an initial price of 400,000 / 100 = 4,000 USDC/WETH. From this, we get 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 amount of WETH in the pool to 99. To maintain a constant product k, the new point (x, y) must still fall on the curve, so y must become 40,000,000 / 99 ≈ 404,040.40. In other words, the trader paid approximately 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 the "price curve": any tradable price must fall on this curve.

Why would market makers choose AMM design over a centralized order book (CLOB)?

Let's explain why market makers would want to use an AMM design for market making. Imagine you're a market maker quoting prices on an on-chain centralized limit order book (CLOB). To update your quote, you 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.

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

To visualize how a "price curve" corresponds to different effective price ranges, we can refer to SolFi, a Solana-based Prop AMM created by Ellipsis Labs. While its specific price curve is unknown and hidden, Ghostlabs has created a graph showing the effective price of exchanging different amounts of SOL for USDC within a specific Solana slot (block time period). Each line represents a different WSOL/USDC pool, demonstrating that multiple price tiers can coexist. This effective price chart changes between slots as market makers update the price curve.

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 greater capital and computational efficiency.

Why is Solana's architecture well suited 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 go hand in hand: low-cost updates often mean updates get priority for execution.

Why do market makers need these two features? First, they constantly update price curves at the speed of the blockchain based on inventory changes or fluctuations in asset index prices (such as those on centralized exchanges). On high-frequency chains like Solana, high-frequency adjustments would be difficult to achieve if the update cost was too high.

Secondly, if market makers cannot queue their updates to the top of the block, their old quotes will be copied by arbitrageurs, resulting in inevitable losses. Without these two features, market makers cannot operate efficiently, and users will receive worse transaction prices.

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

Coming from the EVM, one might ask: “Solana’s slots are around 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 EVM’s discrete block model.

• EVM: Transactions are usually executed sequentially after a full block is proposed and finalized. This means that updates sent midway will not take effect until the next block.
• Solana: Leader validators don't wait for full blocks. Instead, they split transactions into small packets (called "shreds") and broadcast them continuously to the network. Multiple swaps can occur within a single slot, but a price update for shred #1 affects swap #1, and a price update for shred #2 affects swap #2.

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

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

First, while the Prop AMM implementation on Solana is black-box, libraries like Pinocchio exist that allow Solana programs to be written in a CU-optimized manner. Helius's blog provides a fascinating overview of this, demonstrating that using this library can reduce the CU consumption of Solana programs from approximately 4,000 to approximately 100 CU.

Image source: github

Let’s look at the second part. At a high level, Solana prioritizes transactions by selecting the transactions with the highest Fee/Compute Units ratio (Compute Units are similar to Gas in EVM), similar to the EVM.

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

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

Prop AMM Updates : Simple Curve Updates are Extremely Cheap. Wintermute updates are 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

Because of this huge difference, market makers only need to pay a very small fee for update transactions to achieve a Fee/CU ratio much higher than 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?

Assume that updating a Prop AMM involves writing to the variables that determine the price curve for a trading pair. While the Prop AMM code on Solana is a “black box” and market makers prefer to keep their strategies confidential, we can use this assumption to understand Obric’s implementation of the Prop AMM on Sui: the variables that determine the quotes for a trading pair are written to the smart contract via the update function.

Thanks to @markoggwp for spotting this!

Using this assumption, we find that there are significant obstacles in the EVM’s architecture that make Solana’s Prop AMM model infeasible on the EVM.

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

On the EVM, write operations are very expensive. Compared to Solana’s updates, writing a value on the EVM via the SSTORE opcode is surprisingly expensive:

• SSTORE (0 → non-0): ~22,100 gas
• SSTORE (non-zero → non-zero): ~5,000 gas
• Typical AMM swap: ~200,000–300,000 gas

Note: Gas on the EVM is similar to Compute Units (CUs) on Solana. The SSTORE gas numbers above assume only one write per transaction (cold writes), which is reasonable since you typically don’t send multiple updates in a single transaction.

While updates are still cheaper than swaps, gas usage is only about 10x (updates may involve multiple SSTOREs), while on Solana it is about 1000x.

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

1. High gas consumption makes it difficult for priority fees to guarantee updates are prioritized , and lower priority fees make it impossible to achieve a high fee/gas ratio. To ensure updates are not preempted and are at the top of the block, higher priority fees are required, which increases costs.
2. Arbitrage risk is higher on the EVM , where the ratio of update gas to swap gas is only 1:10, compared to 1:1000 on Solana. This means arbitrageurs only need to increase their priority fee by a factor of 10 to front-run market maker updates, while on Solana, they need to increase it by a factor of 1000. With this lower ratio, arbitrageurs are more likely to front-run trade price updates to obtain outdated quotes because the cost is low.

Some innovations (such as EIP-1153’s TSTORE for temporary storage) provide writes with around 100 gas, but this storage is ephemeral, valid only within a single transaction, and cannot be used to persist price updates for subsequent swaps (e.g., across a block).

How to introduce Prop AMM to EVM?

Before answering, let's first answer the question "Why do it?": Users always want to get better transaction quotes, which means more cost-effective transactions. Ethereum and Layer 2 Prop AMMs can provide users with competitive quotes that were previously only available on Solana or centralized exchanges.

To make Prop AMM viable on the EVM, let’s revisit one of the reasons why it was successful on Solana:

• Top-of-block update protection: On Solana, Prop AMM updates are placed at the top of the block, protecting market makers from front-running. This top-of-block update placement is due to the minimal computational unit (CU) consumption, enabling high fee/CU ratios even with low fees, especially compared to swaps.

So, how do you get Prop AMM updates on top of blocks into the Layer 2 EVM blockchain? There are two approaches: either reduce the cost of writing them, or create a priority channel for Prop AMM updates.

Due to the state growth problem of the EVM, this approach of reducing write costs is not feasible because cheap SSTOREs will 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 approach, implemented through a global storage smart contract + a 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 a key off-chain component. The block builder identifies transactions sent to the global storage contract, allocates the first 5–10% of the block’s gas to these update transactions, and prioritizes them by fee to prevent spam transactions.

Please note: transactions must be sent directly to the global storage address, otherwise they are not guaranteed to be at the top of the block.

For examples of custom block building algorithms, 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” that ensures all price updates within a block are executed before trading, eliminating the risk of front-running.
2. Cost-effectiveness : Market makers no longer have to compete with all DeFi users for high gas prices to reach top-of-block transactions. Instead, they only need to compete in the local fee market to update the top blocks reserved for transactions, significantly reducing costs.

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

However, there are some drawbacks to this model, which I leave for discussion at the bottom of this article.

in conclusion

The viability of Prop AMMs relies on solving core economic problems: cheap and prioritized execution to prevent front-running.

While the standard EVM architecture makes such operations costly and risky, a new design offers a different approach. Combining an on-chain global storage smart contract with an off-chain builder strategy, this new design creates a dedicated "fast lane" to guarantee updates are executed at the top of the block, while also establishing a local, controlled fee market. This not only makes Prop AMMs feasible on the EVM, but also has the potential to revolutionize all EVM DeFi projects that rely on top-of-block oracle updates.

Open questions

• Is Prop AMM’s 200ms Flashblock speed on the EVM fast enough to compete with Solana’s continuous architecture?
• Most of the AMM traffic on Solana comes from a single aggregator, Jupiter, which provides an SDK for easy AMM access. However, on the Layer 2 EVM, traffic is dispersed across multiple aggregators and there is no public SDK. Does this pose a challenge to Prop AMM?
• Prop AMM only consumes about 100 CU to update on Solana. What is its implementation mechanism?
• The fast channel model only guarantees updates at the top of the block. If there are multiple swaps within a Flashblock, how does the market maker update prices between these swaps?
• Is it possible to write optimized EVM programs in languages like Yul or Huff, similar to the Pinocchio optimization solution on Solana?
• How does Prop AMM compare to RFQ?
• How can we prevent market makers from misleading users by providing high-quality quotes in block N, and then updating them to poor quotes in block N+1? How does Jupiter prevent this?
• Jupiter Ultra V3’s Ultra Signaling feature allows Prop AMM to distinguish between harmful and harmless traffic and provide tighter quotes. How important are these aggregator features to Prop AMM on the EVM?