Ethereum PropAMMs: today and tomorrow
\cdot
by Mike and Maryam – October 7, 2026.
\cdot
Special thanks to George for inspiring this article by highlighting nuances we missed in our previous article and for reviewing it. Any errors are our own.
\cdot
Relevant links
| Description | |
|---|---|
| Titan’s PropAMM taker interface | link |
| Titan’s PropAMM maker interface | link |
| Blockworks’ Solana DEX Winners article | link |
| Our first PropAMM article | link |
\cdot
Relevant terms
| Term | Definition |
|---|---|
| Take | A transaction that trades against the liquidity in a PropAMM. Think of this as a “swap” or “trade” that can come from a normal user or from a sophisticated arbitrageur. |
| Update | A transaction from the market maker that changes the state of the PropAMM contract (e.g., by changing the mid-price). These are sometimes called “oracle updates” or “quotes.” |
\cdot
Motivation: current PropAMM volumes on Ethereum
In the first few months of their existence, Ethereum PropAMMs have grown steadily and now account for roughly 5-10% of swapping volume on Ethereum mainnet. The table below includes the volumes of Uniswap (data from defillama) and the two largest Ethereum PropAMMs (data from pamm.wtf) for reference.
| Category | Venue | Sept 14–20, 2026 |
|---|---|---|
| DEX | Uniswap | 6.0 billion USD |
| PropAMM | Fermi | 280.17 million USD |
| PropAMM | Metric | 177.89 million USD |
This is already a significant portion of onchain trading volume, but when compared to Solana, it seems plausible that the relative share of PropAMM volume on Ethereum may continue increasing. The table below lists the volumes of the four largest DEXes and three largest PropAMMs on Solana (data from defillama) for comparison.
| Category | Venue | Sept 14–20, 2026 |
|---|---|---|
| DEX | Pump | 3.3 billion USD |
| DEX | Raydium | 2.2 billion USD |
| DEX | Meteora | 1.4 billion USD |
| DEX | Orca | 1.6 billion USD |
| PropAMM | BisonFi | 2.8 billion USD |
| PropAMM | HumidiFi | 1.8 billion USD |
| PropAMM | Tessera V | 1.0 billion USD |
| Total DEX volume | 8.5 billion USD | |
| Total pAMM volume | 5.6 billion USD |
We see that PropAMMs account for about 40% of combined volume from the largest Solana trading venues.
Our previous article introduced PropAMMs in the language of other trading flows, while leaving some of the mechanics already in place for Ethereum PropAMMs out of the discussion. In Section 1, we drill down into the details of existing PropAMMs on Ethereum, distilling what issues they need to solve, how Solana PropAMMs address them, and what makes the Ethereum execution environment structurally different. In Section 2, we examine some of the second-order effects of PropAMMs and project their long-term impact on PBS, MEV, and Ethereum trading generally.
1. The sub-slot mechanics of PropAMMs
When discussing the necessary conditions for implementing PropAMMs on Ethereum in our previous article, we focused heavily on same-slot censorship resistance. While intuitively this makes sense (especially when considered alongside an in-protocol ordering mechanism à la discussions in our ACE post), George pointed out that this is a necessary but not sufficient condition because within a slot, it is also important that the market maker has a chance to respond to price moves in realtime. Consider, for example, a price move that happens 11 seconds into the slot. Even if the market maker landed an update several seconds earlier, the price reflected by their PropAMM contract is now stale, and if a taker is able to land a transaction while the market maker isn’t, the maker still faces adverse selection. Thus, implementing viable PropAMMs using only in-protocol features would require a stronger notion of “realtime” censorship resistance. Neither Ethereum nor Solana has that guarantee (because it is hard to achieve!), but still, PropAMMs exist in both ecosystems and are instantiated by a combination of in- and out-of-protocol mechanisms.
It is helpful to understand the existing PropAMM designs through the following two problems that need to be solved to make a viable onchain market. For each problem, we describe how Solana circumvents it, what makes the Ethereum environment fundamentally different, and how Titan’s PropAMM instantiation works.
- Problem #1: Latency races with toxic takers: Market makers compete to update the liquidity in their contract before arbitrageurs trade against their pool at a stale price. To protect against this, makers need good assurances that (i) their updates are included with low latency, and (ii) their transactions will be given priority (included in a block before takes).
- How Solana PropAMMs solve this: There is no explicit guarantee about maker inclusion and priority on Solana. There are, however, two structural features that allow PropAMM operators to win latency races with a higher probability. First, Solana blocks are “continuously” built. In practice, the 400ms slot is divided into 50ms batches that are auctioned off through Jito. These regular, low-latency intervals allow market makers to update their liquidity with low latency and receive confirmation that their transaction was included. Second, within each batch, transactions are generally ordered by the fee paid per compute unit (abbr. CU). Since the maker updates consume much less CU than a take, the makers can afford to pay a much higher fee-per-CU to get their updates included first. Combined, shorter effective slots and priority ordering sufficiently protect market makers from latency races with toxic takers. As described in this post, market makers operating Solana PropAMMs send millions of updates per day.
- What makes the Ethereum environment different: First and most obviously, Ethereum slots are much longer than Solana slots. This means that makers face a higher risk of the price moving significantly between updates. More importantly, however, Ethereum has neither a notion of “continuous block building” nor the default priority-fee ordering. Blocks are built as discrete objects, and PBS provides an interface for builders to order transactions arbitrarily. To be clear, there is nothing fundamentally different about the Solana transaction supply chain aside from the shorter slots. A maximally adversarial proposer in Solana can do a lot of damage to PropAMMs by censoring maker updates, by not publishing the block continuously, and/or by ignoring the priority fee ordering to place toxic takes ahead of updates. In the long run, it is possible for proposers to have a more adversarial approach to maximizing revenue, but for now, social forces seem strong enough to enforce desired behavior.
- How Titan solves this in Ethereum: Titan mitigates latency races with toxic takers through a combination of “maker priority” and “maker freshness” (see docs). Maker priority guarantees that in any specific block, a take that lands on a PropAMM will be preceded by a maker update. This is an explicit ordering guarantee that the builder provides to makers. Maker freshness states that for any incoming trade against the PropAMM, the trade is only valid if it is at least 50ms older than the latest update from the maker (this value is configurable, and they use 50ms as the canonical example). Maker freshness provides a structural latency advantage to market makers (a last look) to ensure they have time to update before any take lands on their PropAMM. Note that this almost feels backwards, where the take has to be at least 50ms older than the update transaction. Described from the taker’s point of view, a trader is trying to take against a PropAMM. They submit this trade at time
t, but it won’t get matched until at leastt+50ms, at which point all of the market makers will have had a chance to post an update. These features together create a much more hospitable environment for active market making on Ethereum, and are facilitated through the market maker trusting the builder.
- Problem #2: Throughput limitations: Active market making necessitates extremely frequent updates. A PropAMM thus requires a very large amount of throughput to land these updates onchain.
- How Solana PropAMMs solve this: Solana has a large bandwidth and little global congestion, setting a floor on the gas prices. Thus, market makers can afford to simply pay outright to continuously land update transactions onchain. Humidifi, for example, averaged 6 million updates and spent about $10,000 in transaction fees daily (link). While this is large, it is reasonable for a market maker doing significant volume, and is nowhere near the cost of landing that many transactions on Ethereum. In particularly volatile environments, the required fees to land updates onchain may become too large for the makers, and Solana PropAMMs have circuit breaking in place to pause trading if an update hasn’t landed recently (e.g., in the last slot).
- What makes the Ethereum environment different: Ethereum has significantly lower throughput than Solana. To meter this, EIP-1559 implements a base fee controller that is dynamically updated based on blockspace utilization. This results in much higher overall fees for Ethereum transactions, making landing continuous maker update transactions cost-prohibitive.
- How Titan solves this in Ethereum: Titan implements a “conditional inclusion” guarantee, where a market maker’s updates can be configured to only land onchain if there is a corresponding take that gets routed through the PropAMM. This construction leverages the fact that maker updates only have semantic meaning if there is a trade that is routed against the PropAMM. Including an update that doesn’t get traded against is effectively a no-op and wasted blockspace, as that update will become stale and need to be replaced before any subsequent take can be executed against the PropAMM. This “pay-per-use” feature greatly increases the viability of Ethereum PropAMMs. Further, since block building is a discrete event in Ethereum PBS, the makers can be sure that only a single update is included per block (rather than one every 50ms throughout the 12s slot). Effectively, this means that at block construction time, the most recent update from each PropAMM operator is included (applying maker priority and freshness as described above) if there is a corresponding take on that PropAMM.
It is striking just how much Ethereum and Solana PropAMMs differ, but both instantiations aim to satisfy the necessary latency, priority, and bandwidth requirements for active onchain market making. There are also a few more details about Titan’s PropAMM implementation that are worth digging into.
- Taker ordering: There are many possible ways you could order PropAMM takes in Ethereum. Solana uses frequent batches and low transaction fees to approximately implement first-come, first-served processing of the takes. However, within a specific 50ms Jito batch, the takes are ordered by priority fee; thus, the takers compete within their batch to route against the PropAMM liquidity. As mentioned above, Ethereum block construction takes place over longer slots, giving the builder a lot of flexibility in deciding the ordering for PropAMM takes. Titan implements the following procedure:
- Maintain a pool of existing PropAMM takes that have arrived during a slot.
- Maintain a pool of the latest PropAMM market maker updates (one per PropAMM).
- At block construction time, process the takes together with the other transactions to be included, using the normal block building algorithm (e.g., greedy by fee-per-gas or more sophisticated rules). A take is only included if it is more than 50ms older than the latest update. The latest maker update for the corresponding PropAMM is inserted immediately before the first take (maker priority).
- For any subsequent takes that trade against the same PropAMM, they can be included without a corresponding maker update because the update is already included above.
- This procedure effectively treats sufficiently old takes as “normal” transactions for the purposes of the block construction algorithm, and enforces maker priority once a take has been included in the block.
- Note that this iterative process means that the exact state of the PropAMM during the slot will be unknown both to the maker and takers. In particular, the intermediate state will depend on the set of takes that have traded against the PropAMM at that point in the block, because these takes will change the state of the liquidity in the PropAMM contract and correspondingly change the price that the PropAMM will trade at.
- State and price streams: To help takers who are trying to route against PropAMM liquidity, Titan’s implementation creates two streams of data that can be consumed.
- Price stream: This stream originates from Titan and simulates the current liquidity of various PropAMMs if the current maker update were applied at the top of the block. In effect, they simulate an order book showing the depth levels for different trade sizes according to the state at the end of the previous block. Importantly, this stream is not updated as the block is constructed, so the actual prices could differ as a result of the prefix takes moving the price of the PropAMM due to the fade built into the pricing curve. In practice, it seems like the PropAMMs are liquid enough to make this distinction not important. In the future, it is possible that the routing decisions, which are currently made on the taker side, are integrated more directly into the builder (e.g., by the builder finding the best execution at block construction time) or through onchain routing (e.g., where a smart contract implements a search for the best liquidity). Both of these solutions have the benefit of being deterministic based on the state of the chain when the transaction itself executes, rather than being probabilistic based on the state at the top of the slot.
- State stream: This stream originates from the market makers and can be configured according to the maker preferences (e.g., permissioned, delayed, etc.). The market makers publish this stream of state updates to try to make it easier to route against their PropAMM liquidity, while trying to avoid leaking too much information to expose themselves to toxic flow.
The following sequence diagram captures most of the salient features of PropAMMs on Ethereum. See the per-step descriptions below.
- Take A: The user/wallet constructs and sends a transaction to the builder. Assume that this transaction trades against the PropAMM operated by market maker 1 and pays a fee of 1.
- Take B: A second user constructs and sends a different trade transaction to the builder. Assume this transaction also trades against market maker 1’s PropAMM, but pays a fee of 2.
- Send update 1: Market maker 1 sends an update to the block builder. By maker freshness, the take A and take B will not execute unless 50ms have elapsed between their receipt time and the maker update.
- Send update 2: Market maker 2 sends an update to the block builder.
- Publish block: The builder runs the block creation process. By treating the takes as normal transactions, take B precedes take A because it gets scored higher due to the higher fee. Since block takes are against market maker 1, only update 1 is included, and it is inserted before take B. Take A could be much farther down the list of transactions, and trades against the state of the PropAMM after the maker update and take B. Because there are no takes against market maker 2’s PropAMM, update 2 is not included (conditional inclusion). After the block is published, the makers and takers will see the new state of the PropAMMs.
The entire flow looks more like traditional market making, where the order book is updated in 12-second batches, and the takers have a 50ms speed bump. One interesting feature of this whole pipeline is that as more of the matching process is internalized by the builder, the more the exchange migrates from onchain to offchain. Titan’s implementation doesn’t provide preconfirmations for the makers or takers, but Titan does know the full state of the exchange before landing a block and settling the outputs of the trades onchain. This means that if they had exclusive access to a PropAMM, then they could provide preconfirmations and faster execution for makers and takers separately from the cadence of Ethereum and settle asynchronously. Of course, preconfirmations would only be possible if a single builder had exclusive access to execute against a PropAMM (otherwise the trade could become invalid by a different builder sequencing some takes against the PropAMM and winning the block auction). Exclusive access to PropAMMs doesn’t seem to be the direction things are headed. Nevertheless, it is still worth considering what the builder-maker relationship implies, as we will discuss more below.
Hopefully, the above provides a much clearer picture of how the PropAMM sausage is being made in Ethereum today and what motivated this design.
2. The implications of PropAMMs on MEV & block building
Zooming out, let’s consider a few of the implications of a larger share of Ethereum trading flow being facilitated through PropAMMs. Below we provide four takes; the first two we already discussed in our previous post, but we reiterate briefly here. The third and fourth are somewhat non-obvious and more future-looking, but we think they’re worth considering.
Take 1: PropAMM growth raises the barrier to entry of block building
This follows directly from the fact that market makers have to integrate directly with builders for PropAMMs to work on Ethereum. There are efforts to standardize this interface. Titan’s original PropAMM API has been adopted by Quasar and BuilderNet (the second and third largest builders). ERC-8324 proposes a more general contract to standardize per-state ordering constraints that builders can choose to respect. The harder problem arises from having to convince market makers that you are good for your word in actually enforcing these constraints, because they aren’t enforced in-protocol. We hope that the market-maker relationship doesn’t further entrench the builder market.
Take 2: PropAMM growth leads to heterogeneous execution quality across blocks
This also follows directly from the fact that only a trusted set of builders will be able to interact with the PropAMM contracts. If a user happens to want to trade on a slot that is self-built by a proposer, then their quality of execution (the price they get for their trade) will be much worse than if they had traded during a block built by Titan. Note that this builder-dependence is very different from Uniswap today, where the same swap transaction can be included by any builder (in both cases, the price received for the swap does depend on whether the builder front-ran you). Multi-party block construction (abbr. MPBC) could help ameliorate this exclusivity by allowing contiguous sub-blocks to be built by different builders. If a market maker has a trusted relationship with a single builder, then that builder could append their PropAMM flow to a block built by a separate builder (in effect, the trust is transitive). Due to its recency, we haven’t had much time to form a first-principles opinion on MPBC, but it is at least a hopeful direction.
Take 3: PropAMM growth leads to a reduction of proposer MEV yield
This may seem counter-intuitive, as PropAMMs aim to bring more volume back to Ethereum L1, but consider the following feedback loop:
- PropAMMs gain volume and offer much better execution than DEXes.
- Users migrate from swapping against DEXes to using PropAMMs.
- DEX LPs continue facing adverse selection arising from LVR, but now earn much less from normal swapping fees. DEX LPs pull capital as a result.
- CEX-DEX arbitrage and DEX-DEX arbitrage volumes decrease correspondingly, as there is less liquidity in DEXes.
MEV today is largely driven by CEX-DEX (non-atomic) and DEX-DEX (atomic) arbitrage. If the amount of liquidity in DEXes significantly declines, so does the corresponding MEV associated with these arbitrage strategies. From the validators’ perspective, a significant decline in MEV revenue is an important consideration.
Note that this argument hinges on DEX volumes migrating to PropAMMs and DEX LPs pulling liquidity as a result. Either of those statements could not play out. It is also possible that PropAMMs simply bring in new demand for trading without reducing the amount of DEX volume. In Solana, DEXes still serve the long tail of small market-cap assets (e.g., memecoins), because there aren’t market makers who will actively provide liquidity on these assets through PropAMMs. However, even if there is more volume from PropAMMs, that volume doesn’t necessarily translate to a correspondingly larger amount of fees paid to the proposer (because EIP-1559 will increase the base fee to match the increased demand for blockspace).
While reducing MEV seems antithetical to the block builder business model, there is a subtle reason why it might be the right decision for builders to facilitate PropAMMs. We don’t know the exact numbers here, but structurally the current competitive MEV auction doesn’t seem easy to monetize from the builder’s perspective; the value flows more naturally to the edges of the transaction supply chain. If capturing a specific MEV opportunity is too competitive, most of the value goes to the proposer. If an order-flow provider has exclusive access to valuable transactions, then they have bargaining power with builders and can capture most of the value themselves. On the other hand, the business model of PropAMMs is a volume-based fee paid to the block builder. This aligns the builder’s incentive with maximizing the volume of trades going through a PropAMM, and might be a more stable and sticky revenue source than MEV in the long run.
Take 4: PropAMMs could gatekeep good quality trade execution
This follows from a similar line of reasoning as Take 3. In particular, assume as we argued above that we are in a situation where the best onchain execution for trading goes through PropAMMs instead of DEXes, and further, DEXes have less liquidity than they do today. Since PropAMMs are facilitated by active market making, it is likely that those market makers are known entities with compliance requirements (e.g., ensuring that they aren’t trading with a deny-listed set of addresses). This compliance can be enforced by the PropAMM contract itself or by the builder, but the effect is the same: access to good quality onchain trading execution will not be fully permissionless. Note that this isn’t unique to PropAMMs; DEXes can also build in compliance; KYC and/or deny-lists have been proposed and implemented as Uniswap v4 hooks for several years. The difference is that, to this point, we haven’t seen large amounts of liquidity and trading volume migrate to permissioned DEXes, whereas it seems plausible that PropAMMs can attract significant volume given they are a fundamentally more efficient trading mechanism. (Of course, native privacy on the L1 could fully alleviate these concerns, but we aren’t there yet.)
Note that this degradation of permissionless execution quality is very different from the canonical definition of censorship, where malicious block producers refuse to include transactions from a specific address (or worse, actively fork out blocks that do). Instead, it is a form of “economic censorship,” where there is unequal access to financial services (e.g., trading at the best price). This is similar to other economically aware definitions of censorship (e.g., Fox, Pai, and Resnick) rather than just “eventual inclusion,” which has historically been the benchmark. We reiterate that this potential increase in censorship is not unique to PropAMMs. Many blockchain protocols offer similar guarantees, where access to some applications is facilitated by a central intermediary that is ultimately the arbiter of the allowable activity in that domain (e.g., L2s, stablecoins, RWAs). PropAMMs don’t restrict the core property rights of assets, but they could centralize the L1 trading flow into a less permissionless equilibrium.
Overall, we are excited to see the innovation and traction of PropAMMs on Ethereum and think very highly of the goal of bringing more activity to Ethereum L1. We also think these second-order effects are important to consider. Thanks for reading!