Proprietary AMMs and Ethereum
by mike & maryam – july 26, 2026.
\cdot
tl;dr; PropAMMs facilitate about one third of onchain trading volume on Solana. The contracts provide onchain composability with active market-making strategies through a clever design of cheap, fast oracle updates to the contract state that market makers make to ensure the contract trades at an up-to-date price. Some teams are starting to leverage the same mechanisms to improve onchain trading on Ethereum (though still with a very small combined 24h volume of 10mm USD compared to the 500mm on Solana PropAMMs). This post provides a simple primer on PropAMMs by walking through how onchain trading has evolved on Ethereum, before exploring PropAMMs on Solana and concluding with a discussion on the possible implications for Ethereum.
\cdot
Many thanks to apriori and Quintus for comments and review.
Proprietary AMMs (abbr. PropAMMs) have come to play an important role in the onchain trading landscape of Solana. We believe that these contracts and the infrastructure that powers them are a major development in onchain trading. This article serves as a jumping off point to understand PropAMMs from the Ethereum perspective and was partially inspired by Apriori’s recent series of Deeply Intents podcasts with Katia, Quintus, and Markus on PropAMMs – give those a listen.
We work through the evolution of trading flows in Ethereum to help place PropAMMs into familiar terms. Section 1 walks through traditional AMM trading, with passive liquidity provision. Section 2 examines RFQs, in which market makers are explicitly brought into the equation to facilitate trades. Section 3 describes aggregators, which pull liquidity from many sources to provide the best overall price to the user. Section 4 explains the life cycle of a PropAMM trade on Solana. Section 5 concludes with a brief discussion on the structural features that make PropAMMs on Ethereum different (and similar!) to Solana. Caveat emptor: the descriptions here are intentionally simplified to illustrate the key features of different trading paths, and as companies vertically integrate and offer different products, the lines between the different flows described here start to blur. This is a high-level explainer, but we hope it is a helpful starting point.
1. Traditional Automated Market Makers/DEXs
Starting most simply, let’s consider the “traditional” AMM, where anyone can provide liquidity to a pool for traders to swap against. Then we consider the flow involving the user, frontend, and Ethereum:
- Ask for swap details – The user initiates a request through a frontend (or wallet), specifying the details of the trade they want to make.
- Get pool data – The frontend reads the pool data from Ethereum smart contracts.
- Pool data – The chain state reflects the current liquidity in the pool.
- Show swap details – The frontend shows the user the price they will get by trading against the pool(s).
- Sign transactions – The user signs the transaction.
- Send transaction – The frontend sends the transaction to a mempool or through private channels to the builders.
- Confirm transaction inclusion – The transaction is included onchain.
- See transaction – The frontend shows the user the outcome of the trade.
Notes:
- The trade execution depends on where the transaction actually ends up in the block. For example, the transaction could be sandwiched and thus execute with the worst-possible price. The user specifies a slippage tolerance to protect against arbitrarily bad execution, but this is hard to do well during periods of high volatility or for low-liquidity assets.
- The liquidity that users interact with is usually not active on a per-block basis. For example, in a UniV2 pool, the LPs are passively providing liquidity at any price as defined by the price curve. The user is taking liquidity usually against a passive maker.[1]
- Multiple LPs permissionlessly combine their capital to make a pool, whose contents fully define a single curve and the prices at which the assets in the pool will be sold.
2. Request for Quotes (RFQs)
The traditional AMM model has serious flaws. Most notably, the liquidity providers, who serve as makers for the trades in a pool, are constantly being rebalanced against the true price of the asset on the venue where price discovery happens, which is typically a centralized exchange (c.f., LVR). As a downstream effect, users who trade against an AMM in isolation are often receiving worse prices than they would receive from a more liquid market. This reality has led product developers to find other ways to facilitate trading and get better prices for their users by relying on competition among multiple active market makers.
RFQs more explicitly incorporate market makers into the trading flow by having them submit quotes for filling a user’s desired trade direction and selecting the best quote. This is extremely different than the traditional DEX flow above because the logic of the trade is fully processed offchain and only the settlement happens onchain. Further, the liquidity being provided in RFQs is opaque (e.g., not possible to predict until a quote is made) and less interoperable with the rest of the DeFi ecosystem (e.g., a user waiting for a quote to be filled can’t atomically use the output tokens of that swap with another transaction until the fill transaction has been originated by the market maker).[2] The sequence diagram below schematizes this:
- Ask for swap details – The user initiates a request through a frontend (or wallet), specifying the details of the trade they want to make.
- Ask for quotes – The frontend reaches out to market makers for a bespoke quote for this specific trade.
- Quote – Market makers provide quotes.
- Show swap details – The frontend shows the user the price they were quoted.
- Approve token transfer – The user approves the token transfer (e.g., by signing an intent based on the quotes presented).
- Share transfer details – The frontend forwards the details of the user address to the market makers.
- Send token transfer txn – The market maker that fills the quote is able to atomically transfer tokens into and out of the user’s address.
- Observe token transfer txn – The frontend observes that the transfers have taken place.
- Show outcome – The frontend shows the user the outcome of the trade.
Notes:
- The trade price does not depend on the state of the chain; it just depends on the fill from the market maker.
- The “execution” of the trade doesn’t really occur onchain; only the settlement does. It just looks like ERC-20 token transfers that are done atomically together.
- The liquidity is opaque. The market makers have to decide what to quote and how to fill it, and they are working with the frontend. Suppose they give firm “executable quotes” (e.g., that expire 30s later), then the market makers bear the risk of the price moving against them and making a trade at a bad price (e.g., against an arbitrageur). If the quotes are non-committal, then the frontend risks the quote not getting filled and having a failed user interaction. Various agreements about fill rate and who is allowed to participate in the RFQ are handled offchain, leading to somewhere between firm and soft quotes in practice.
- RFQs often provide much better prices than trading against passive LPs because they explicitly induce competition between market makers and they don’t suffer from LVR.
- UniswapX is an example of an offchain RFQ. There are Dutch Auctions built in if the winning quoter doesn’t end up filling the order (as well as disincentives for not filling), but the happy path is exactly the flow described above.[3]
3. Aggregators/routers
The existence of multiple sources for on- and offchain liquidity leads to the natural evolution of trading to rely on aggregators/routers. Some examples of these are matcha, 1inch, and Kyber. In general, aggregators do exactly what the name suggests: they aggregate liquidity from numerous sources to try to get the best price for their users. This aggregate route can include onchain liquidity from multiple pools and offchain liquidity from an RFQ. The diagram below shows an aggregator filling a trade partially onchain and partially through an RFQ:
- Ask for swap details – The user initiates a request through a frontend (or wallet), specifying the details of the trade they want to make.
- Ask for quotes – The frontend reaches out to market makers for a bespoke quote for the trade.
- Quote – Market makers provide quotes.
- Get pool data – The frontend reads the pool data from Ethereum smart contracts.
- Pool data – The chain state reflects the current liquidity in the pool.
- Show swap details – The frontend shows the user the aggregate price they can get.
- Approve – The user approves the contents of the trade.
- Get partial fill – The aggregator gets the trade partially filled by market makers.
- Partial fill – Market makers fill their quote.
- Get partial fill (swap txn) – The aggregator gets the trade partially filled by onchain liquidity.
- Confirm swap txn – The swap transaction is confirmed.
- Show outcome – The frontend shows the user the outcome of the trade.
Notes:
- The aggregator flow can use onchain and offchain liquidity by combining DEXs and RFQs. The frontend is a lot “smarter” here and is expected to do some work on behalf of the user to find the best possible price. Most trading apps that we interact with regularly (e.g., app.uniswap.com) are doing some routing/aggregation under the hood, as they provide much better prices than using any specific source of liquidity in isolation.
- Much like RFQs, aggregators are platforms that are relying on external parties to fill a trade. The aggregator decides the rules of engagement and has to abstract the idiosyncrasies of each venue to make the UX as seamless as possible.
4. PropAMMs on Solana
With these preliminaries, we can now better frame PropAMMs on Solana. This trading path is different from what we have studied so far: market makers can play a highly active role in providing liquidity, and the execution logic of the trade happens onchain, meaning it is much more interoperable than RFQ liquidity. More than half of Solana trades go through a DEX aggregator (similar to what we describe in the previous section), but usually the aggregation is done with onchain liquidity. The sequence diagram below shows this, where Jupiter is the canonical example of a DEX aggregator:
- Ask for swap details – The user initiates a request through a frontend (or wallet), specifying the details of the trade they want to make.
- Get DEX data – Jupiter uses the AMM interface to read quotes from all the DEXs that are integrated into the router.
- DEX data – The DEXs quote prices based on the current state of the contract.
- Show swap details – The frontend shows the user the aggregate price they can get.
- Update oracle price txn – Market makers regularly update their PropAMM contract via low-cost oracle updates. These are streamed and serve to keep the contract trading at a fresh price.
- Sign transaction – The user signs the transaction.
- Send transaction – Jupiter sends the signed transaction to the next proposer.
- Confirm transaction inclusion – The transaction is included onchain.
- Show outcome – The frontend shows the user the outcome of the trade.
Notes:
- This flow is most similar to the “traditional DEX” flow in Section 1. In particular, the frontend reads the chain state, the actual execution of the trade occurs onchain, and the execution depends on the block contents.
- The main difference we include in this flow is the presence of a market maker, who sends a transaction to update the oracle price on their PropAMM. It is extremely important that the market maker is able to land their oracle update frequently, as it controls the price at which the PropAMM will execute trades. In Solana, the number of compute units (equivalent to gas in Ethereum) used by the oracle update transactions is much lower (e.g., 100x) than the amount needed to execute a trade. By default, Solana uses a greedy algorithm to include the highest fee-per-CU transactions. As a result, the market makers who run PropAMMS can afford to regularly send oracle update transactions which consume very few CU but pay a high per-CU fee (e.g., HumidiFi sending 6M oracle update transactions per day) to ensure their contract trades at the freshest price.
- The net effect of the oracle updates is a weak form of application-controlled execution (abbr. ACE), where PropAMM operators are able to land transactions before each trade (in effect having a last look to protect against filling at stale prices). In ACE, the transaction ordering is enforced either by the protocol or by some commitment mechanism; here, the oracle updates are simply smaller transactions that can pay a higher per-unit transaction fee that leads to their inclusion. This does mean that the price that the user sees may differ from the price they end up receiving in the transaction because the market maker could land an oracle update in the meantime.
- Critically, nothing about the oracle updates preceding take orders is enforceable by the protocol. This is the weakness of the current PropAMM construction, which relies on market makers successfully landing regular oracle updates and relying on non-strategic behavior from the proposer. A myopic, profit-maximizing block proposer should instead use their position of power to sell the ability to arbitrage against the PropAMM contract at the end of their slot. In particular, a rational proposer would probably make more money with the following strategy:
- Throughout the full 4 slots that they are block proposer (1.6s), censor all oracle update transactions.
- At the end of the 1.6s[4], run an open auction to allow searchers to trade against all pools and PropAMMs to rebalance the price to the CEX price (e.g., run a CEX-DEX arbitrage auction).
- The revenue of this auction would probably far exceed the transaction fees that are paid by the oracle update transactions.[5]
- The above behavior would completely defeat most of the value of PropAMMs, as the liquidity in the PropAMMs contract would face maximally toxic flow of constantly trading at 1.6s-stale prices against arbitrageurs. While this is the profit-maximizing strategy for proposers, it would be detectable and lead to significant response from the community (c.f., Jito’s ibrl.wtf dashboard and the corresponding discussion around block packing and transaction scheduling). Still, it remains to be seen how the Solana social layer would handle more adversarial strategic proposer behavior.
- It is also possible that a PropAMM quotes a relatively tight spread, but actually executes at a much worse price (indeed, this has actually been observed empirically on Base).[6] Jupiter handles this risk at the routing layer, and will punish AMMs that have poor performance – quoting from the Jupiter documentation: “a self-learning mechanism that automatically sidelines underperforming sources.” So while it is possible in the short-term to quote inaccurately, doing so will result in less flow getting routed to the PropAMM. In effect, this isn’t so different from the permissioned/trusted/reputation-based setup of RFQs. It is also possible to pull some of the routing logic onchain, meaning at execution time, a smart contract will decide which PropAMM to route to based on the exact chain state, further alleviating the spoofing risk.
5. PropAMMs and Ethereum
So far, the story is:
- On Ethereum, traditional DEXes are the most trustless, onchain-native way of trading, but they suffer from worse pricing because of passive liquidity provision and capital inefficiency.
- As a result, many Ethereum trades that historically would have occurred onchain get fully or partially filled by professional market makers through an RFQ (either in isolation or as part of an aggregation). These trades get better execution quality, but (i) aren’t composable, (ii) use reputation management by aggregators to provide reliable fills, and (iii) utilize less onchain logic than traditional swaps.
- On Solana, PropAMMs bring trading activity back onchain by enabling market makers to manage their liquidity at a much higher granularity through regular oracle updates. This realtime updating of liquidity is enabled by a combination of fast block times, the oracle updates being very low-cost, and block producers complying with priority-fee ordering. Jupiter allows PropAMMs to integrate into their routing layer through a standardized API implementation.
Turning our attention back to Ethereum, let’s consider how mainnet can facilitate PropAMMs. The main goal here is to re-home more trading activity on Ethereum L1, rather than pushing so many swaps to occur in offchain/trusted channels. Our informal definition of a PropAMM is a smart contract that implements the DEX interface using a parameterized pricing curve, whose capital is actively managed by a market maker who frequently updates the parameters based on an offchain pricing model. On the surface, there is no reason this can’t be built on Ethereum. There are, however, a few specific hurdles that are worth calling out.
- Long slots: If a market maker can consistently land a fresh parameter update transaction at the top of a block, then there is actually nothing different about long versus short slots in terms of the market makers; they only need to ensure that their parameter update transaction occurs in realtime precisely when the block is built. However, the long slots increase the risk a market maker takes if they aren’t able to update their contract in a given slot (12s of stale prices are much worse than 1.6s).
- PBS market structure: Ethereum already has a mature pipeline of block building where the block is sold as a unit to a builder, and the builder is expected to maximally extract value through that block in order to win the auction. As such, naïvely launching a PropAMM contract on Ethereum would result in the censor & arbitrage strategy at the builder level that we described as the myopically rational Solana proposer above. The fundamental incentives are exactly the same in both cases, but as observed, Solana proposers are not max-extracting, while Ethereum’s PBS auction explicitly rewards builders who are.
As a result of the above, the design currently being explored for PropAMMs on Ethereum involves a trusted relationship between the builder and the market makers. Titan, who builds more than 50% of blocks, offers a PropAMM service through which market makers can land parameter update transactions by sending them directly to Titan for inclusion in blocks. Quasar builder, who builds another 20% of blocks, offers the same service. The pamm.wtf dashboard shows the spreads of these PropAMMs compared to Binance. This configuration is a reasonable starting point, but has some obvious downsides.
- The PropAMM can only function when a trusted builder creates a block. On blocks of unknown origin, the market maker can’t be sure they will land the oracle update transaction, and thus the smart contract itself probably shouldn’t allow trades (or should trade at much wider spreads). This could lead to a weird reality where, as a user, the execution quality you get is really good some of the time and much worse otherwise (this sounds like bad UX).
- There is a risk of further entrenching the already centralized builder market. If PropAMMs attract a lot of value, the fees they pay and the value of the respective blocks might continue concentrating among builders that have established relationships with PropAMM operators and other market makers.
There is no silver bullet to address these issues for building PropAMMs on Ethereum. Just as in Solana, there is a fundamental issue that the incentives of the block proposer are not aligned with the incentives of the market maker. Solana is implementing multiple concurrent proposers exactly to provide in-protocol guarantees about realtime censorship resistance, which allows an enshrined implementation of application-controlled execution (see here for more specifics). Only with same-slot, top-of-block censorship resistance can market makers operate a PropAMM without running the risk of the proposer censoring their bids to auction off the option at trading against the PropAMM at the end of the slot. Ethereum’s censorship resistance EIP, FOCIL, does help the issue somewhat, as market makers that broadcast their oracle update transactions before the inclusion list deadline for a slot can have good guarantees that it will be included in the next block. However, FOCIL doesn’t enforce inclusion at the top of the block; there is a gap between when the inclusion lists are broadcast and when the block is built during which no such guarantee will apply to their oracle update transactions, and thus they risk being censored. Alternatively, in-protocol ACE would ensure that parameter update transactions always precede takes.
This is just the beginning of the PropAMM discussion on Ethereum. We strongly believe that as the Ethereum community, we should continue iterating on PropAMMs to facilitate onchain trading and prevent more liquidity from moving offchain.
Of course, more active management of onchain liquidity is possible with concentrated liquidity in UniswapV3, but the spirit of the design is not regularly updating positions given the expense of sending transactions. ↩︎
Note that you could have an RFQ system in which quotes are “executable” by the user, in which case the interoperability would be better, but this also provides the user a free option that the market makers would have to price in. ↩︎
Note that UniswapX is part of the broader suite of outcomes from trades starting on app.uniswap.org. People don’t really go to Uniswap and say, “I want to use the RFQ path today,” but instead it is part of the aggregation that takes place when the router is trying to find the best price for the user. Again, this is where the lines start to blur between RFQs, routers, and aggregators. ↩︎
We think it would be reasonable to consider Solana slot times to be 1.6s, because that is the duration that a single proposer has the authority to order transactions. The fact that they are supposed to publish four blocks in that period and further supposed to continuously stream transactions that they are processing as shreds even at a sub-400ms granularity is not something that the protocol enforces and thus a misrepresentation of the actual mechanics of block production. ↩︎
Further, it might be possible to auction off the top of the block for the CEX-DEX arb, and then still include the oracle update transactions after the pool has been traded against and still pick up those transaction fees too. There might be a technical reason that this isn’t possible today, but the real value would come from the CEX-DEX arb auction. ↩︎
The exact mechanics of the malicious behavior depend on the microstructure of the specific execution environment. On Base, for example, malicious PropAMM operators exploited the fact that quotes were read from the end of flashblocks for execution in the subsequent block. Thus, they could quote tight at the end of a block before widening at the beginning of the next block and thus fill the order at a much worse price that was absorbed by the slippage of the transaction. ↩︎