• at a high level,, it is not exactly true but conceptually okay to say that PEPC is in-protocol SUAVE if SUAVE is only used for Ethereum preference aggregation
  • SUAVE is the preference aggregation engine, I don’t think PEPC is meant to replace that, PEPC is the supply disaggregator (take a container and parcel its volume between various buyers)
• differences: SUAVE supports private transaction from users and computation on those txns, while PEPC does not, PEPC is purely proposer commitments, does not have private processing of user intents, nor allow user commitments, etc,.
  • The proposer could commit to include a user transaction/bundled intent, which would effectively remove all strategic uncertainty for the user before block-building time. They are guaranteed that no matter what, the block will be built according to the proposer commitments (PCs), unless the block isn’t revealed in the second phase
    • OR, there could be an in-protocol facility to convert [proposer commitment to include user transactions] ⇒ [full block containing user transactions]
• difference: SUAVE has a “fast” speed of common knowledge, this means SUAVE is able to theoretically mediate more games (ofc the credibility guarantee is lower), for example, AMMs implemented on top of SUAVE is able to have lower LVR and faster settlement, and is able to use liquidity outside Ethereum as well (e.g., SUAVE native liquidity or Optimism liquidity) -> and PEPC cannot do that because PEPC’s credibility is tied with the block validity proof which only happens per 12s, so PEPC’s speed of common knowledge flows at 12s
  • This is correct, but could you increase PEPC speed (with credibility tradeoff) via “proposer commitment pre-confirmations”? Proposers commit to PCs earlier than ethereum finality of the commit phase elsewhere, e.g., write their PCs on SUAVE? This is very meta, hard to see the use tbh.
• from those two we can already map out how different MEV-time applications are to be implemented on those two platforms, e.g., games that are not so latency sensitive but are credibility-sensitive should be implemented on PEPC, such as cr-lists, while the other types of games, such as DEXes, should be implemented on SUAVE
  • Loving that distinction, unbundling credibility and speed and allowing mechanisms to choose their optimal tradeoff
• difference: at the 12s level, PEPC as a protocol should be able to “see” more things than SUAVE (ofc SUAVE can also see, but only as an oracle, so not credible), because it is in-protocol
  • If SUAVE is a rollup on Eth, information could flow atomically between SUAVE and PEPC?

followup questions

• market would be pretty fragmented if proposers all do different commitments, it leads to pretty bad UX, is there any better way we can structure those? e.g.,there was a partial block auction in the last slot but not in this? how do app devs think about this? they must want some kind of “smoothing” around proposer commitments
  • I don’t think proposer commitments are great for dapps, I think they should use them exclusively to secure their relationships with third party builders. PCs used for Dapps is imo a somewhat far-fetched use-case atm
• imagine if PFOF deals happen and some proposers commit to only taking blocks made by some specific builder or MEV-time app, for example Coinbase signs an exclusive deal with Espresso to say that: all coinbase validators must only propose blocks sequenced by espresso. Do you see this kind of exclusive deals happening? What would be the impact of those deals? → You could even make the PFOF deal as a smart contract, i.e., a contract that checks if the proposer has made a exclusive commitment, and if the proposer has, airdrop some token to the proposers’ address, I could easily imagine ponzis like this popping up a lot, where some SUAPP devs just put up airdrop contracts on PEPC for growth hacking
  • I mean these types of commitments could be made with Eigenlayer, and I also imagine that there will be airdrops directed at proposers which have made specific commitments with Eigenlayer. PEPC just enshrines that pattern a bit more, but doesn’t uniquely enable it
• we’ve talked enough about the differentiation between PEPC and SUAVE, what about the synergy? where do you see this “atomic information flow” happen?
  • SUAVE can build a block/partial blocks “on specs” given some proposer commitments. The other way would be: a proposer can make commitments conditional on sth happening on SUAVE, so for instance they can play a fast game even if they only make moves on PEPC (write a conditional commitment on PEPC, sth happens on SUAVE, the block built can atomically feed information from SUAVE to the block verification function and evaluate)
• to push PEPC to realization, what is the biggest obstacle you see? finding good applications (proposer commitments) examples on it? It seems to me like the technical/implementation side is pretty much thought out, just the economic analysis of the applications on it is not clear.
  • Technically I don’t think it’s trivial, but yes use cases would be excellent. On my mind now is separating top-of-block bidding from rest-of-block bidding, and thinking about how mev-capture works with PEPC.