From Solana to the EVM: A New Path for Proprietary AMMs

Prop AMMs have rapidly captured 40% of all trading volume on Solana. Why aren’t they on EVM?

Proprietary AMMs (Prop AMMs) have rapidly become a dominant force in Solana’s DeFi ecosystem, responsible for a growing 40%+ of trading volume on major pairs. These specialized venues, operated by professional market makers, offer deep liquidity and competitive pricing, primarily by reducing the vulnerability of market makers to front-running by arbitrageurs who exploit stale quotes.

https://dune.com/the_defi_report/prop-amms

However, their success has been almost entirely confined to Solana. Why haven’t they taken root in the EVM ecosystem, even on fast and cheap Layer 2s like Base or Optimism?

This article explores what Prop AMMs are, the technical and economic barriers they face on EVM chains, and a promising new architecture that could finally bring them to the forefront of EVM DeFi.

What are Prop AMMs?

A Prop AMM is an automated market maker where the liquidity and pricing for a pool are actively managed by a single, professional market maker, as opposed to being supplied passively and by the public.

Unlike a traditional AMMs that use the equation x * y = k for determining prices, where x and y are the quantities of the two assets in a pool, and k is a fixed constant, Prop AMMs use a different formula that is typically updated multiple times a second. As Prop AMMs are typically a black box, the formula each Prop AMM uses is unknown. However, the smart contract code for Obric’s Prop AMM on Sui is public (Thanks to @ markoggwp for spotting this!), where its invariant k is dependent on internal variables mult_x, mult_y, and concentration. The image below shows how the market maker is constantly updating these variables.

One small clarification to make is that the left-hand side of Obric’s price curve formula is more complex than x * y, but the key takeaway for understanding Prop AMMs is that it’s equal to an invariant k, which the market maker updates to adjust the price curve.

Refresher: How are prices determined on an AMM?

The word “price curve” will appear in this writeup many times, as it’s what determines the price a user pays for a trade when using an AMM and is what the market maker updates in their Prop AMM to update prices. Before diving deeper into Prop AMMs, it’s helpful to first build an understanding of how prices are determined in an AMM. Consider a Uniswap v2 pool for WETH-USDC with no fees. The price is passively determined by the formula x * y = k, where x and y are the quantities of the two assets in the pool, and k is a constant. Only the points on the curve are possible prices that a user can pay for their trade.

For example, consider a WETH-USDC pool with 100 WETH and 400,000 USDC. The current point on the curve is x = 100 WETH, y = 400,000 USDC, which means the initial price is 400,000 USDC / 100 WETH = 4,000 USDC per WETH. Deriving the constant product k, we get xy = k = 40,000,000. If a trader wants to buy 1 WETH, they add USDC to the pool, and the pool’s WETH balance decreases to 99. To maintain the constant k, the new x and y points must be along the curve, so the USDC balance must increase to 40,000,000 / 99 ≈ 404,040.40 USDC. The trader therefore paid 4,040.40 USDC for that 1 WETH, an effective price higher than the initial $4,000 due to price impact (also known as slippage). This is why the x y = k formula is also known as the price curve, because any possible price for that pool must be a point on the curve.

Why would a Market Maker choose an AMM design over a CLOB?

Let’s motivate why a market maker would want to use an AMM design for market making. Imagine you are a market maker on an onchain Central Limit Order Book (CLOB). To update your quotes, you must cancel and replace potentially thousands of individual limit orders. If you have N orders, this is an O(N) linear operation. This is slow and computationally expensive, especially onchain.

What if you could represent all your quotes as a single mathematical curve? Instead of managing N distinct orders, you would only need to update a few parameters that define the entire curve. This turns an O(N) problem into an O(1) constant operation.

To visualize how a price curve (ex. x*y = k) can lead to a range of different effective prices, let’s look at SolFi, the Prop AMM created by Ellipsis Labs. While the price curve is unknown and hidden, Ghostlabs produced a chart below that shows the effective SOL to USDC price for varying quantities of SOL wanting to be swapped at a given Solana slot. (For EVM readers, slot number is analogous to block number). Each line represents a different WSOL/USDC pool, demonstrating how they can offer different pricing tiers simultaneously. As the market maker updates the price curve, the following effective price chart below will change between different slots.

https://github.com/tryghostxyz/solfi-sim/blob/main/static/curves_333436948.png

The key takeaway here is that by using 1 update for a few price curve values, the market maker can change this effective pricing graph to their liking, rather than having to update N different orders. This is the core value proposition of a Prop AMM, and it allows a market maker to provide deep, dynamic liquidity with high capital and computational efficiency.

Why Solana’s Architecture works well for Prop AMMs

Prop AMMs are actively managed. This requires two things: cheap updates and priority execution. On Solana, having cheap updates leads to updates having priority execution.

Why do market makers need these two things? Firstly, market makers update their pricing curves at the speed at which the chain operates, based on factors like their current inventory and shifts in the asset’s index price (e.g., from centralized exchanges). On fast chains like Solana, this would be expensive if updates weren’t cheap.

Secondly, if the market maker isn’t able to get their update at the top of the block, their stale quotes will be “picked off” by arbitrageurs, resulting in guaranteed losses.

Without both of these properties, market makers won’t be able to operate as efficiently, and this would result in worse trade prices to the user.

For example Solana Prop AMMs like HumidiFi are seen updating their quotes 74 times a second (shoutout to @ SliceAnalytics for the data), as seen in the image below:

https://dune.com/queries/5980584/9644764

Coming from the EVM world, one might ask: “If Solana slots are ~400ms, how can a Prop AMM update its price 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 generally executed sequentially when a complete block is proposed and finalized. This means an update sent mid-block won’t be reflected until the next block begins.
• Solana: The leader validator doesn’t wait to build a full block. It breaks incoming transactions into small packets called “shreds” and streams them to the rest of the network continuously. There may be multiple swaps in a slot, but a price update in shred #1 impacts the price of swap #1, while price update in shred #2 impacts the price of swap #2.

Note: Solutions like Flashblocks are analogous to Solana’s shreds. As per @ Ashwinningg from Anza Labs during his talk at CBER’s conference, there is an upper bound of 32,000 shreds per 400ms slot. That’s as much as 80 shreds a millisecond! Whether 200ms Flashblocks are fast enough for market makers compared to Solana’s continuous architecture is an open question.

So how are updates so cheap on Solana, and how does it lead to updates having priority execution?

Firstly, while the implementation of Prop AMMs on Solana are a black box, there exists libraries like Pinocchio for creating Solana programs in a CU optimized way. Helius’s blog has a great writeup on this library (here), where it can be seen bringing Solana programs from ~4000 CU to ~100 CU.

https://github.com/febo/p-token?tab=readme-ov-file#compute-units

Let’s address the second part. At a high-level, Solana prioritizes transactions by picking transactions with the highest Fee / Computer Units ratio (note that Compute Units analogous to EVM’s Gas), similar to EVM.

• Specifically, if you’re using Jito, the formula is Jito Tip / Compute Units,
• if you’re not then it’s Priority = (Prioritization fee + Base fee) / (1 + CU limit + Signature CUs + Write lock CUs) (https://solana.com/docs/core/fees)

Comparing the Compute Units of a Prop AMM update and a Jupiter Swap, we see that a Prop AMM update is extremely cheap at a ratio of 1 to 1000.

Prop AMM Update: A simple curve update is incredibly cheap. Wintermute has updates as cheap as 109 CU, with a total fee for the tx being 0.000007506 SOL

https://orb.helius.dev/tx/325EwPasEyXYuVqow9aGT44i17cZzd9G5GYPHxJr1JmLKwyWTS6rJgV6EP1svqExo9TnoqqmMF15si17x2s7wnSu?cluster=mainnet-beta&advanced=true&tab=summary

Jupiter Swap: A swap routed through Jupiter can cost upwards of ~100,000 CU. The total fee for this tx was 0.000005 SOL.

https://orb.helius.dev/tx/4SbYyAEq6QBNv5YW517fLRatEPvBvh1kDit3C8NL84uBRXuE7FFEsVuX6BDG44reXtMt5WZCGxN7rS38jt4RSNY9?cluster=mainnet-beta&advanced=true&tab=summary)

Because of this massive difference, a market maker can achieve priority execution for their updates by paying a small fee to their update transaction and achieve a Fee/CU ratio that is orders of magnitude higher than a swapper. This effectively guarantees their update gets executed cheaply and at the top of the block, protecting them from being arbitraged by toxic flow.

Why aren’t Prop AMMs already on EVM?

Let’s assume that updates to a Prop AMM involve writing variables that determine the price curve of a trading pair. While Prop AMM code on Solana is a black box, where market makers want to maintain secrecy over their edge, we use this assumption after seeing Obric’s implementation of a Prop AMM on Sui, where variables that determine the quote for trading pairs are written to the smart contract via update functions.

https://suiscan.xyz/mainnet/object/0xb84e63d22ea4822a0a333c250e790f69bf5c2ef0c63f4e120e05a6415991368f/contracts

Shoutout to @ markoggwp for finding this!

Using this assumption, EVM’s architecture presents a major roadblock that makes Solana’s Prop AMM model unviable.

Recall that on OP-Stack Layer 2 blockchains like Base and Unichain, transactions are ordered by Priority Fee per Gas (similar to how transactions on Solana are prioritized by Fee / CU).

On EVM, gas usage for writes is high. A simple storage write on the EVM for one value via the SSTORE opcode is astronomically expensive compared to a Solana update.

• SSTORE (zero to non-zero value): ~22,100 gas
• SSTORE (non-zero to non-zero): ~5,000 gas
• Swap on a typical AMM: ~200,000 - 300,000 gas

Note that Gas on EVM is analogous to Compute Units on Solana.

Also note that the SSTORE gas numbers above are made with the assumption that there’s only 1 write per transaction (cold writes), which is reasonable as you wouldn’t send more than 1 update in a transaction.

While an update is still cheaper than a swap, the gas usage ratio is only about ~10x (note that an update may use multiple SSTORE’s), compared to Solana’s ~1000x ratio.

This leads to two conclusions that make the same Solana Prop AMM model more risky on EVM.

1. Because the gas usage is high in the first place, a small priority fee does not achieve a high Priority Fee / Gas. This means ensuring the update doesn’t get front-ran and is Top of Block will require a larger priority fee, which is more expensive.
2. Because the ratio between update gas usage and swap gas usage on EVM is only 1:10 as opposed to 1:1000 on Solana, this means an arbitrageur on the EVM only needs to increase their Priority Fee by 10x of an update transaction to outbid and front-run the market maker’s update, as opposed to 1000x on Solana. In this lower ratio environment on EVM, an arbitrageur is more likely to front-run a price update to take stale quotes because it’s not as expensive to do so.

Innovations like EIP-1153 (TSTORE for transient storage) offer 100-gas writes, but this storage is ephemeral and only lasts for the duration of a single transaction. It cannot be used to persist a price update for a subsequent swap transaction (such as for a duration of a block).

How can we bring Prop AMMs to EVM?

Before answering this question, let’s first briefly answer the “Why”. Users always want better quotes for their trades, as it means they get a better deal. Prop AMMs on Ethereum and Layer 2 blockchains would enable more competitive quotes for users on those blockchains, that would otherwise only be found on Solana and centralized exchanges.

To make Prop AMMs viable on the EVM, let’s recall one of the reasons Prop AMMs work well on Solana:

• Prop AMM updates being at the Top of Block on Solana protect the market maker from having their updates front-ran. Updates are at the ToB because they use very little Compute Units, where a low fee still results in a high Fee / CUs, especially compared to swaps.

So how do we bring Top of Block Prop AMM updates to Layer 2 EVM blockchains? There’s two approaches: either decrease cost of writes, or create a priority lane for Prop AMM updates.

The first option of decreasing the cost of writes is unlikely to work due to the state growth problem in EVM, where cheap SSTORE’s may make it cheaper to spam state.

We propose a solution via the second approach, of creating a priority lane for Prop AMM updates.

A novel approach, suggested by @ MarkToda from the Uniswap team, proposes a solution via a Global Storage smart contract (repo here) combined with a specialized builder policy.

https://github.com/flashbots/global-storage-smart-contract

Here’s how it works:

• Global Storage Contract: A single, simple smart contract is deployed to act as a public key-value store. Market makers write their price curve parameters to this contract (e.g., set(ETH-USDC_CONCENTRATION, 4000)).

Builder Policy: This is the critical offchain component. Block builders would implement a policy that recognizes transactions sent to the Global Storage contract address. The policy would automatically allocate the first 5-10% of a block’s gas exclusively for these update transactions, ordering them by priority fee. This is done to prevent spam.

Note that the transaction having a to value to the Global Storage address is important, as we don’t want to allow transactions that aren’t directly to this address and also call other swap functions to be at the Top of Block.

• Below is an example of how a custom block building algorithm would look like using rblib.

• Prop AMM Integration: The market maker’s Prop AMM contract is designed to read data that makes up the price curve from the Global Storage contract at the time of a swap, when determining the quote to give to the user.

This architecture elegantly solves both problems.

• Protection: The builder policy creates a “fast lane” that guarantees all price updates in a block are executed before any swaps, eliminating the risk of front-running within the same block.
• Cost Efficiency: Market makers are no longer competing against every DeFi user to reach the Top of Block with higher gas prices. Instead, they compete only against other update transactions in a local fee market for the reserved ToB section. This dramatically reduces the cost of securing priority execution.

A user’s swap would be executed against the price curve set by the market maker’s update at the very beginning of that same block, ensuring the quote is fresh and protected. This model effectively recreates the low-cost, high-priority update environment that has allowed Prop AMMs to thrive on Solana, paving the way for a new era of market efficiency on the EVM.

However, there are downsides to this model that I leave as questions open for discussion at the bottom of this writeup.

Conclusion

The viability of Proprietary AMMs hinges on solving a core economic problem: the need for cheap, priority execution to prevent front-running.

While the standard EVM architecture makes this prohibitively expensive and risky, a new design offers a different approach to this problem. By combining an onchain Global Storage contract with an offchain builder policy, we can create a dedicated “fast lane” for price updates. This model guarantees Top of Block execution for oracle updates while establishing a local, contained fee market, directly addressing the core barriers and making not only Prop AMMs possible, but potentially transformative for all types of EVM-based DeFi that rely on oracle updates being Top of Block.

Open Questions

• Are Prop AMMs operating on EVM at 200ms Flashblock speeds fast enough to compete with Solana’s continuous architecture?
• On Solana, most of the orderflow for AMMs comes from 1 aggregator, Jupiter, who conveniently provides an SDK for connecting an AMM to the aggregator. On Layer 2 EVM blockchains however, it is split up across multiple aggregators who don’t provide a public SDK. Does this pose a challenge for Prop AMMs on EVM?
• How are Prop AMMs implemented such that their updates on Solana only use ~100 CU?
• The proposed fast lane model only has Prop AMM updates at the Top of Block. Given a Flashblock is only as fast as 200ms, there may be a scenario where there are multiple swaps in a Flashblock and a market maker may want to update the price between those trades. How can that be implemented?
• Can languages like Yul or Huff be used to write optimized EVM programs, similar to Pinocchio how is used to write optimized Solana programs?
• How do Prop AMMs compare to RFQs?
• How do we prevent market makers from giving a great quote at block N that is displayed to the user to lure the user into sending a transaction at block N+1, where the market maker then updates the quote at block N+1 with a terrible quote? How does Jupiter prevent it?
• Jupiter’s Ultra V3 introduces “Ultra Signaling” that allows Prop AMMs to distinguish between toxic flow and non-toxic flow, to provide quotes that are 3 bps tighter. How important are aggregator features like this for bringing Prop AMMs to EVM?

P.S: I’m currently looking for conference speaker slots to talk about this topic. If you’re connected to any events during Devconnect, I’d love to chat with you about speaking opportunities!

Disclaimer:

1. This article is reprinted from [0xOptimus]. All copyrights belong to the original author [0xOptimus]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.