Proprietary AMMs and Ethereum

[mikeneuder]

Thanks for the response!

@atiselsts

Perhaps I’m missing something, but wouldn’t encoding the block number in the oracle update remove the “censored parameter update” attack vector for exploiting market makers? Swaps that tried to execute on stale parameters would revert, instead of causing losses to the MM. (Or the swaps could use wider spreads, as you already hint at.) Arguably this is a simple form of ACE. The block number can even be packed in the same slots as other parameters to avoid an extra SSTORE.

This is for sure possible! I was talking a bit with Eugene and he said that Solana PropAMM operators actually implement something like this, where if the oracle is too old, the AMM just doesn’t accept any trades. I think the subslot stuff is not obvious to me though, which may be an issue for longer slot time chains like Ethereum. For example, if the operator is streaming updates throughout the entire slot, then a malicious proposer can just include the farthest one from the current price, just to satisfy the same slot update constraint and then trade against the contract in the worst way. But yes, I think in practice there are lots of tricks that the MMs do to protect themselves.

@atiselsts

If the existing Ethereum’s propAMMs don’t do that, isn’t it a deliberate design choice - they don’t need it because they’re using a fundamentally trust-based architecture?

Titan shared some comments with me after that I need to process and understand, but yes, I think there are more reasons to go for trust based. Fro example, in Ethereum, each transaction has to pay the 1559 base fee. So if you are streaming oracle updates, each of those has to pay, even if no one is trading against the AMM in the meantime. In this setup, having a trusted builder who only inserts the oracle update conditioned on if a trade actually lands in the block would help a lot with gas costs. This is just one example, but hopefully illustrates that point.

@atiselsts

I also don’t see how FOCIL would help. FOCIL requires using public mempool to force inclusion, but presumably, market makers want to keep their oracle updates private to avoid giving out their alpha.

I don’t think the public mempool is an issue actually. From conversations with Eugene, it seems like the main thing that the oracle update contains is the mid-price of the asset on a CEX, which is certainly not private information. I think the bigger issue with FOCIL is that it guarantees inclusion but not order, so you can just put the oracle update at the bottom of the block and do whatever toxic flow you were going to do before it. From my perspective, it seems like CR guarantee + ordering guarantee would be necessary (e.g., FOCIL + ACE).

@atiselsts

Conditional on the revert-if-stale logic, it seems that the post’s critique of long blocks is overstated. (To be fair, long blocks do have some relevant issues, but they are more subtle - e.g. fewer opportunities to trade; increased concentration risk.)

I think that is fair! I tried to communicate that as long as there are good guarantees about oracle inclusion at the time of block construction then the length of the slots don’t matter. But I included the discussion because it felt relevant to at least consider the fact that long slots have some impact on PropAMMs. I think it is good for Ethereum if the long slots don’t impact things too much.

@atiselsts

The remaining core issue is perhaps that there’s no way to make private transactions censorship resistant. Reordering is fixable at the contract level; full censorship of the update isn’t.

Like I said above, I think same-slot FOCIL with public oracle updates should be fine. I would push back on the statement that “reordering is fixable at the contract level.” I think enshrined ACE is good, but it def opens a can of worms that we tried to cover well in Application-controlled execution: A case study on cancel prioritization. It is also probably worth noting that given FOCIL won’t happen until Hegota, it is possible that the builder guarantees are just going to be the mechanism that gets adopted in the short term and are hard to get rid of. Maybe it is just OK and necessary to rehome trading activity on Ethereum L1 in the short-term, which seems like the most important thing to me.