🚨 New paper alert 🚨 Active Liquidity On Chain: Evidence from PropAMMs Across Chains w/ Ozan Solmaz @jason_of_cs Liquidity providers on traditional AMMs such as Uniswap are passive and suffer from adverse selection. As a result, their price only moves through trades. When an external market moves, these LPs get picked off on their stale quotes. PropAMMs, a new design, emerged in 2024 attempting to combat this. In them, a single operator quotes from its own inventory and reprices actively. By 2026, propAMMs carried more than half of SOL/USDC volume on Solana and had been found, among other chains, on Base and Monad. Our work seeks to elucidate the benefits of this new design both for LPs and for retail users. Do propAMM operators really have an edge over passive LPs, and if so, where does this edge come from? Can propAMMs offer tighter quotes to retail users? We measured a full year of propAMMs on Solana, Base and Monad, and decoded the closed-source on-chain logic of Tessera, the largest propAMM on Base. The result: propAMMs have a measurable edge over passive LPs: two seconds after a fill, propAMMs earn 0.37 bps on Solana, 1.19 bps on Base and 1.69 bps on Monad, while passive LPs on AMMs comparatively lose 0.22, 0.62 and 2.06 bps. We trace the edge to four sources: 🟠 Cheap, frequent repricing: updates use at least 25 times less resources than swaps on Solana, and 5 to 15 times less on Base and Monad. Generally, the default block order on all three chains is by priority fee per unit of computation. Thus, an update pays far less than a swap for the same priority placement. 🟠 Pricing by counterparty: five of the six largest Solana propAMMs offer tighter spreads to aggregator flow than to non-aggregator flow. For Tessera on Base, we show that it whitelists, penalizes or blacklists individual addresses. 🟠 Arbitrage against AMMs: when a reference price moves, propAMMs reprice while AMMs do not, and arbitrageurs trade the two. A propAMM fills at its updated quote, so it may break even on these legs on Solana and Base and even earn 1.55 bps on Monad. 🟠 Spoofing: aggregators route on the quote from the end of the previous block. For Tessera on Base, we show that the operator consistently raises its default fee early in the block and lowers it again late in the block, so aggregators read stale state that carries the lower fee. As a result, only 39% of swaps execute at the quoted price, and the average swap receives 1.08 bps less. The second question we ask is: can propAMMs offer users tighter quotes as a result of their edge? The answer is yes: on fills that arrive while the price is not moving (our proxy for retail flow) propAMMs take 0.26 bps on Solana, 1.26 bps on Base and 1.62 bps on Monad, where AMMs take 2.59, 1.38 and 8.60 bps respectively. Retail also makes up a larger share of propAMM volume: 32%, 43% and 17% on Solana, Base and Monad, against 9%, 16% and 8% on AMMs. What did we learn? PropAMMs avoid the losses of passive liquidity provision, yet still manage to give retail tighter quotes. However, users also have to bear the cost of spoofing, which we expect to change as aggregators move to an on-chain methodology. Link:

🚨 New paper alert 🚨 No Place to Hide: An Analysis on Protected Order Flow Sandwich Attacks w/ Ozan Solmaz @boez95 @ChristofTorres Bots watch every pending trade in Ethereum's public mempool and sandwich the ones worth attacking. Hence the nickname: the dark forest. In response, Ethereum and other chains built protections, from private RPCs to mechanisms native to the chain, that shield trades from these bots. We call this protected order flow. How well are these users actually protected? We measured it in a three-year study of sandwich attacks by persistent bots against protected order flow on Ethereum, Solana, Tron, Base, Arbitrum, and Monad. The protections on these chains range from private RPCs on Ethereum and private submission to a centralized sequencer on Base and Arbitrum, to first-come-first-served ordering in Tron's public mempool and local mempools on Solana and Monad. Local mempools were never meant as a full front-running prevention, but they do limit who sees a trade before it lands. On four of the six chains, we observe protected order flow sandwich attacks: 28.0M attacks on Solana, 38,567 on Tron, 30,607 on Ethereum plus 2,576 more through reorged blocks, and 1,889 on Base. We trace each chain's exposure and find that it sits in various places along a transaction’s path. 🟠 Ethereum: OFAs can expose enough information to make private trades sandwichable, especially when the same transaction reaches multiple OFAs or when searchers receive full transaction details. Reorged blocks also expose private transactions. We find transactions that were private and untouched in a block that got reorged, and then sandwiched on the canonical chain. 🟠 Solana: transactions are sent to the upcoming leaders, and early on we find that a few leaders carry far more attacks in their blocks than their share of blocks, i.e., they are likely the exposure source for these transactions. From 2025 that fades, but we see that victims concentrate around a few apps. 🟠 Tron: we presume that bots win latency races in the public mempool, so the first-come-first-served ordering in block building does not fully prevent sandwiches. 🟠 Base: we see two different kind of exposure. One lines up with a documented RPC bug that exposed pending transactions. The other has attackers preying on victims who trade on a predictable schedule, if the vicim does the same trade every couple of blocks, the attacker can front-run them without observing the pending trade. Protected order flow sandwiches look very different from public mempool sandwiches. The attacker's transactions often land in a different block than the victim's, and unlike in the public mempool, their success is not guaranteed. These attackers simply don't act with the same certainty. The dark forest may have shrunk, but we show there's an even darker corner of it, where users who think they're protected still get front-run. Protection has to hold at every layer, from the app to the RPC to the block producer. Encrypted mempools and TEE-based designs can help, by keeping transaction contents out of attackers' reach until inclusion. But even they might not be enough on their own without privacy, for example if the victim is too predictable. Link: