# MEV Resources - Ethereum
This notes document includes various resources I've come across over the last 4 months. These 'Notes' should help shine light on the dark forest with many of these topics worth investigating further. Unless stated otherwise writing is pasta. TLDRs pulled from various source materials linked in the subheading or at the bottom of the subsection.

There is much research on the topic of MEV in the Ethereum and other ecosystens that I surely missed. Also the contents here are focused more on theory than practice, so there is clearly room to add practical information as well (eg. liquidation, stat arbs, LT strategies, etc).

Ultimately I hope this notes document saves you time which you can re-allocate to writing or other endeavors. Thank you to all of the authors who have provided outstanding research to build upon.

## Distributed Builder Idea

### Notes from this talk by [Vitalik](https://youtu.be/6F8ljJUhBRI):


Builders that decentralize internally, where the builder accepts bundles from an open market of actors called searchers.

A bundle could be an entire block or collection of transactions. The distributed builder takes bundles provided by a searcher and arranges by fee and publishes as a block body. The builder itself becomes this kind of market/aggregator.

Searchers become an open market. Anyone in the world can create their own strategies and specialize. Large sets of searchers aggregated by the open market creating this combined block offer that can bid higher than any single actor.

Key challenge is how to prevent builders and searchers from cheating other searchers. How can we prevent builder marketplace from MEV stealing. Its the same challenge of PBS but one layer back. We are basically going from block construction from 1 -> 3 layers even 4! You could have meta searchers that aggregate other searchers.

General solution path: Searcher bundles are encrypted until the block is locked in. The builder operates only over encrypted bundles everything is encrypted until the moment the block proposer agrees, can make it more robust and wait until attesters agree so even the block proposer can’t equivocate and slash people and only then does block get decrypted and revealed to network.

How to do Magic encryption?

Encryption has to have 2 properties:
1. Has to have guaranteed decryption when the proposer agrees and when the block is locked in
2. Have to be able to combine partial bundles, might want to verify proofs that txs are valid and what if some of txs are not valid in the context of other txs searcher may have to prove they are making fees not dependent on ordering

How to do this?
1. Trusted builder - close to what FB does today

2. Use SGX - trusted hardware, all searcher bundles get encrypted to a Public key where a private key is only accessible in TEE module. Entire system that creates blocks (aggregates bundles ) lives inside SGX

Instead of SGX could do MPC, overhead probably too high but could do it with fast ZK-SNARKs. Sets of encrypted txs come with proofs that they are encryptions of something valid. Once the proposer proposes, builder decrypts all of them and computes a state root and witness.

SNARKS > Encryption might require SNARKS over the EVM but good news is that might even be viable.

Still research problem.

If you can make a decentralized builder and one that’s good, can escape a world where Binance and Jane street control block building.

Mitigate censorship externality and other negative externalities, create a decentralized builder that can compete. Because decentralized builder has access to open market should be able to find opportunities.

In order for a builder to plug into an open market for searchers, you would need to convince them its not strategy stealing, which would require privacy for searchers. Any technique that’s good enough to prevent strategy stealing is good enough to allow searchers to include censored transactions that a centralized builder would want to censor.

Searchers need to be okay with paying fee for bundles but not getting benefits if there are conflicting txs.

### Sketch of Decentralized Building (@ralexstokes)
* Single-domain
* Agents compete in an order flow auction
* Tradeoff b/t privacy and execution
* CowSwap inside an MPC?
* Rook Model: properly incentivized searchers work in a private mempool?

* Cross-domain
* Builders compete in an auction across networks
* Coincedent proposals means atomic cross-domain MEV!
* Solution: another cryptoeconomic layer to coordinate trustless building?
* And Again, all while supporting the outcomes where users capture most of the value they leak

### Presentation at SBC

* [Video](https://youtu.be/fAgrIdyWIqc)
* [Slides](https://hackmd.io/@vbuterin/distributed_builders#/)

### Other Links on Topic
* [Alex Stokes Github notes ](https://github.com/flashbots/mev-boost/issues/139)
* [Jon Charb Summary](https://joncharbonneau.substack.com/p/decentralizing-the-builder-role)
* [Sharding Builder](https://mirror.xyz/apriori.eth/oXZaQd-gNReZVXbUJIiZehAltktFEYuIyzKf27iPGBE)
* [Enshrined Builder](https://mirror.xyz/apriori.eth/wiLKgkaN6JBwBDq4E3T_-BZ0OIPhlbIItgJdE3CFAMo)

## PEPC
### Protocol Enforced Proposer Commitments

This is the most current idea around IP-PBS (In Protocol PBS)
*[ Barnabe's Notes on PBS](https://barnabe.substack.com/p/pbs) - state of PBS research post

#### TLDR from Barnabe Ethresearch [post](https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879)

* We build towards a trustless, permissionless scheme for validators to enter into commitments with third parties. We start by protocolizing Eigenlayer, to ensure that out-of-protocol commitments entered into by validators are reflected into the protocol, e.g., tracking their effective balance if they are slashed by Eigenlayer middleware.
* We recognise that this is not enough, since it allows for attacks up to some “maliciousness upper bound”: the protocol cannot enforce the validator won’t deviate when the profit is greater than the slashed amount. So we need to go further, and not simply move to the protocol the outcome of commitments (if the validator is slashed or not) but also whether the commitment was satisfied or not, and base our protocol validity on it.
* As a stepping stone, I propose an optimistic block validity notion, where a validator could do something slashable with respect to the commitments they entered into, and such a slashable behaviour could be made canonical by attesters, but everyone involved eventually gets slashed.
* To return to pessimistic block validity (validator behaviour must be proven correct (no slashing) for block validity), we allow proposers to submit commitments expressed as EVM execution in their block. Attesters can then simply check validity of the block they receive with respect to the commitments that were made.
* We then need to deal with data availability, to ensure that neither proposer nor committed third-party is able to grief one another. Here we observe a fundamental difference between “selling auctions”, where the proposer auctions something valuable to a third-party, e.g., the right to make a block, and “procurement auctions”, where the proposer attempts to obtain something valuable from the third-party, e.g., a validity proof of the execution payload.
* Finally, assuming the existence of such a generalised market for commitments, we revisit the idea of “proposer dumbness”, as expressed by the addition of protocol features aimed at levelling the playing field between dumb and smart proposers.

## SUAVE

### TLDR from FB
From a high level, SUAVE is an independent network that can act as a plug-and-play mempool and decentralized block builder for any blockchain. Although SUAVE is a new blockchain, it is not a general-purpose smart contract platform that rivals Ethereum or any other participating chain. Instead, SUAVE unbundles the mempool and block builder role from existing chains and offers a highly specialized plug-and-play alternative.

SUAVE is a single environment where parties can collaborate on the expression, execution, and settlement of preferences in a decentralized way. It is composed of three main components:

1. Universal Preference Environment: A chain and mempool specialized for preference expression and settlement to surface and aggregate the preferences from users and searchers from all participating chains in a single place.
2. Optimal Execution Market: A network of special parties called executors who listen to the SUAVE mempool and compete to provide the best execution for user preferences.
3. Decentralized Block Building: A decentralized network for and of block builders to access the encrypted preferences from users and merge them into partial or full blocks.

### Roadmap

#### SUAVE Centauri
* Privacy-aware orderflow auction to return to users the MEV that their transactions create. In this auction, searchers compete for the right to back run a user, thereby bidding up the value returned to them. Initially, the auction assumes trust in Flashbots but is private for users and searchers
* SUAVE Chain testnet for stress testing and community experimentation.

#### SUAVE Andromeda
* SUAVE Chain mainnet will allow users to express preferences and send them to the Execution Market
* SGX-based orderflow auction to remove trust in Flashbots and make the auction for efficient for searchers
* SGX-based centralized block building to enable open but private orderflow for centralized builders

#### SUAVE Helios
* SGX-based decentralized building network to allow for permissionless and private collaborative block building across many entities
* Onboard second domain to Suave to address MEV on another domain and provide a foundation for cross-domain MEV
* Cross-domain MEV solutions that allow for expression and execution of cross-domain MEV preferences

### FB Links

* [Announcement FB Writing](https://writings.flashbots.net/the-future-of-mev-is-suave/)
* [Phil Daian unveils](https://www.youtube.com/watch?v=ACXAzLy3iWY)
* [Robert Miller Q&A Thread](https://twitter.com/bertcmiller/status/1595689626446053379?s=20&t=5rpJM2-oGQqCnzxNH4h60A)
* [Suave Threads](https://twitter.com/bertcmiller/status/1595496753352085509?s=20&t=5rpJM2-oGQqCnzxNH4h60A)
* [FB OSS relay announcemnet](https://writings.flashbots.net/Flashbots-Relay-open-sourcing)
* [Relay Github repo](https://github.com/flashbots/mev-boost-relay)
* [FB OSS builder announcement](https://writings.flashbots.net/open-sourcing-the-flashbots-builder)
* [Builder Github repo](https://github.com/flashbots/builder)

## Themis (Fair Ordering Protocol)
### TLDR (incomplete):

Themis is a scheme for introducing fair ordering of transactions into (permissioned) Byzantine consensus protocols with at most f faulty nodes among n ≥ 4f+1.

~ Kelkar, Deb, Long, Juels, Kannan

Themis has same communication complexity of underlying protocol. It is a minimum modification to any existing partially synchronous leader-based protocol

Existing fair ordering protocols require replicas to gossip tx orderings to everyone else as their first step. This results in n^2 communication complexity. Themis requires replicas only to send fair ordering to current leader. The Leader uses n-f of these to compute a fair proposal. The Leader computes a SNARK and provides this with a block proposal. Replicas check proof to ensure fairness. Everything else can be taken as is from the underlying protocol.

Due to granular fair ordering users face less adverse selection eliminating some forms of MEV like sandwiching, without sacrificing on user experience.

### Links

* [Themis Paper](https://eprint.iacr.org/2021/1465)
* [Mahimna Kelkar at MEV day](https://www.youtube.com/watch?v=vqEIz9bmZbs)
* [Mahinma @ SBC ](https://youtu.be/lB57a2wGo8Y)
* [Mahinma Conesunsus Day](https://www.youtube.com/watch?v=eFRNmkZ3OOo)

## FBA-FCFS (Frequent Batch Auctions First Come First Serve)
* [Arbitrum Research Post by Sexy Sun](https://research.arbitrum.io/t/transaction-ordering-policy/127/2)

### TLDR (this idea builds on Themis but includes auctions)

We use FBA-FCFS (frequent batch auction first come first serve) to refer the the proposed ordering protocol.

We show this proposal is better than the original non-FBA version of FCFS in two ways:

* makes the fairness of the ordering more robust (in the sense of network latency tolerance) than the vanilla version, allowing the domain to provide a smoother UX
* more fair in the sense that it removes the negative externality caused by inefficient resource allocation and increases the welfare (an upper bound on ordering efficiency) of users, thus allowing the domain to attract much more future users (who aren’t visible currently)

We also address potential concerns of this proposal:

* FBA-FCFS incurs negligible latency overhead
* FBA-FCFS validators has no incentive to coarsen the fairness granularity

## MEV-Boost: Min-bid

### TLDR
A new mev-boost feature allows validators to maximize Ethereum’s censorship resistance by building low-MEV blocks locally while still outsourcing the building of high-MEV blocks. Using this feature carries an opportunity cost—the price of resilience. As most blocks are actually low-MEV, however, forfeiting a little profit goes a long way in increasing resilience! This is a breakthrough in the tradeoff between maximizing MEV extraction and maximizing censorship resistance

* [FB Announcement](https://writings.flashbots.net/the-cost-of-resilience/)
* [Vitalik Thoughts](https://twitter.com/VitalikButerin/status/1595198944623165448)
* apriori [thread](https://twitter.com/apriori0x/status/1598077894353653760?s=20&t=e1fi8kTRrRfue6T2EcJrUQ) & [blog](https://mirror.xyz/apriori.eth/U5p0ZXMUc3Eiq9Dia3a22HDGbr7PLQJZ6yw3fZ3e7BI)
* [OFAC Compliance since announcement](https://twitter.com/JimmyRagosa/status/1597967678672891904?s=20&t=e1fi8kTRrRfue6T2EcJrUQ)

## MEV-Boost ++

apriori [summary](https://mirror.xyz/apriori.eth/U5p0ZXMUc3Eiq9Dia3a22HDGbr7PLQJZ6yw3fZ3e7BI):

MEV-Boost+ is an iteration on MEV-Boost which uses the Eigen Layer, a meta-slashing protocol on Ethereum, to return agency back to block proposers allowing them to partition an execution block into a builder_part and proposer_part. The proposal was initially put forth by Sreeram Kannan in writing here & via presentation at MEV workshop at SBC.

In MEV-Boost + there is the notion of a prefix & suffix; in a block there is a portion of the block created by the builder and another portion which the proposer creates. The Proposer receives a bid from a builder, then signs off on the builder_part; a special message that can be enforced by slashing on the Eigen Layer. The Message enforces a commitment by the proposer to include the builder portion of the block. The proposer now has freedom to include any transaction they desire.

Is there anything that can be done within this framework of MEV-Boost + to make the relay trust minimized? MEV-Boost++.

The builder takes their builder_part of the block and creates a secret shared version of the block then splits it into many chunks and encodes it. No one chunk exposes information about this block. The builder then sends the chunks to a decentralized escrow which is comprised of EigenDA nodes. The Builder sends one chunk to each of these nodes.

Each node sends back a signature saying they received a share corresponding to this commitment. The signatures flow back to the builder who signs off on commitment attesting to a certificate from EigenDA that certifies the builder’s action of dispersing data to EigenDA. The Builder then takes an aggregate signature (BLS?) and sends it to Block Proposer.

The Proposer chooses the highest possible bid which also has certificate from EigenDA. The Proposer then sends a signed message back to EigenDA. Once EigenDA sees the signed message for a specific block header the nodes release the chunks and the block’s secret share. After all the chunks are released the proposer can reconstruct the prefix of the block then add a suffix (as outlined above in MEV-Boost +) and propose it.

The relay is now fragmented into many entities who have to work together to break these cryptographic guarantees underlying the root of trust.

### Links
* [Eigen Layer Proposal](https://hackmd.io/@layr/SkBRqvdC5)
* [Sreeram Presentation](https://www.youtube.com/watch?v=ywJNXIUSqOw)
* [Sreeream Thread](https://twitter.com/sreeramkannan/status/1595864129512042497?s=20&t=e1fi8kTRrRfue6T2EcJrUQ)

## crLists aka Inclusion or Forward Inclusion Lists

### TLDR from Vitalik presentation:
The blocks either have to include all of the transactions or blocks are double filled until crList gets included (30M gas = double filled, EIP 1559), leveraging altruistic proposers here. It allows proposers to be altruistic cr backstop if they want to while still plugging into PBS market and getting highest revenue from every builder

Works to the extent it relies on honesty, not optimal. People being able to use smart contracts as wallets. If you have crList then crLists have to be aware of an object of user intent. So in order to do account abstraction in order to make etc 4337 fit into this model you have to do a bit of extra work perhaps enshrine parts of erc 4337. If you think public mempools should exist your probably think CrLists are better anyway.

If the builders can’t add their own txs then you bring back the incentive to be a proposer that runs fancy algorithms yourself.

### Links
* Vitalik [Inclusion Lists](https://ethresear.ch/t/how-much-can-we-constrain-builders-without-bringing-back-heavy-burdens-to-proposers/13808)
* Francesco OG Post Updated [crList => Forward Inclusion List](https://notes.ethereum.org/@fradamt/H1ZqdtrBF)
* [CrList & alternative](https://notes.ethereum.org/@fradamt/H1TsYRfJc)
* [Vitalik State of Research](https://notes.ethereum.org/s3JToeApTx6CKLJt8AbhFQ#Hybrid-PBS-can-we-use-proposers-only-for-inclusion-of-last-resort) (older but see idea on [Auxilary Blocks](https://notes.ethereum.org/s3JToeApTx6CKLJt8AbhFQ#Solution-1-can-we-run-many-pre-confirmation-private-PBS-auctions-in-parallel) similar to what I wrote about crList builder)
* [crList Builder](https://mirror.xyz/apriori.eth/Ow6EeeGXQ-6R1beflaO5ez6UOHx6KeJCZFVKTxiflMg)
* crLists as they relate to [Danksharding](https://notes.ethereum.org/@fradamt/H1TsYRfJc)
* [Mev-Boost + crLists?](https://twitter.com/apolynya/status/1586188234102435841?s=20&t=HG8-kZBWysg6J7-rv424Ug)

## Extra Builder services (abstractions)

### Examples (@ralexstokes)
* Gas sponsorships
* Gas Futures
* Custom authorization schemes (not just ECDSA as entrypoint)
* Event-triggered txs ("ethereum alarm clock")
* Builder pre-confirmations
* Builder Cancelations
* MEV rebates
* "Off-chain MEV-Smoothing"
* "Valued-based" building
* MEV "protection" schemes (eg. threshold encryption)

### Pre-Confirmations

Idea if user pays x priority fee get an enforcable comittment from builder for tx inclusion

Builder pre-confirmations will be a game changer for UX by minimizing the time a user waits to get their tx included in a block.

* (ex) users receive enforceable signed commitment from builder to include their tx if priority fee >= 5,

* users receives state root if >=8
* Internally the builder would run tender-mint.

Builders would be penalized for double signing or for contributing an incompatible signature. Assuming an internally distributed builder can win the market, those participates post a slash-able bond to be held accountable for equivocation of their commitment by opting into Eigen Layer slashing conditions.

### Links
* [Alex Stokes at MEV Day](https://youtu.be/Yx20UUTmgfU)
* [Alex Stokes at Bogata](https://youtu.be/KP5ppCRH0iM?t=692)
* [Vitalik slides](https://hackmd.io/@vbuterin/distributed_builders#/15)

## Tarun Research on Sandwhichs & Towards a Theory of MEV
### TLDR:
Sandwiches are ‘local’ ➡️ worst case price that a user gets vs. average case price by received by a user is O(log n. Sandwiches can *help* w/ routing (e.g. 1inch/Match) by making users avoid bad routes (and this holds asymptotically)

How could sandwiches *help* with routing? Don’t they always rob the user being sandwiched?? Yes but they encourage other users to avoid trading across a CFMM edge in a network, smoothing congestion (an inverse Braess paradox!l)

* [Sandwhich Thread](https://twitter.com/tarunchitra/status/1549134678036303873?s=20&t=fhyUJ7HGIZ0z8U-NloGDpw)

### Other Research & Links
* [Paper - Towards a Theory of Maximal Extractable Value I:
Constant Function Market Makers](https://people.eecs.berkeley.edu/~ksk/files/MEV_CFMM.pdf)
* [Slides - Improving Proof of Stake Economic Security via
MEV Redistribution](https://people.eecs.berkeley.edu/~ksk/files/MEV-Redistribution.pdf)
* ETH Bogota - [Cost of Fuedalism: Towards a Theory of MEV](https://youtu.be/6JA4_5QWG0s)
* A Formal Model of Post-MEV-Boost Blockspace Market Dynamics [video](https://www.youtube.com/watch?v=72G2t82ZkMg)
* Limits of AMM Privacy & MEV [video](https://www.youtube.com/watch?v=AE5H_6EO-eU)

## Order Flow Auctions
An auction mechanism where any Searcher/Builder can bid for user order flow. For example a wallet could provide an auction service to all searchers/builders where they exposed a stream of unsigned transactions to be bid on.

See Rook Docs for details of in production example of OFA.

### Links
* [Rook docs](https://docs.rook.fi/reference/rook-protocol/auctions)
* [Order flow, auctions and centralisation I](https://writings.flashbots.net/order-flow-auctions-and-centralisation)
* [Order flow auctions and centralisation II](https://writings.flashbots.net/order-flow-auctions-and-centralisation-II)
* [Order Flows: Kingmaker of The Block builders](https://noxx.substack.com/p/order-flows-kingmaker-of-the-block)
* [FB Discourse discussion](https://collective.flashbots.net/t/order-flow-auctions-and-centralisation-ii-order-flow-auctions/284/2)
* [Order Flow, Auctions, and Centralization](https://www.youtube.com/watch?v=ilc3EoSMMDg)
* [Order Flow has a solution - Fee Escalator](https://t.co/pA6IcDPFfG) @thegostep
* [Order Flow Auctions & The Enshrined Builder](https://mirror.xyz/apriori.eth/wiLKgkaN6JBwBDq4E3T_-BZ0OIPhlbIItgJdE3CFAMo)

## MEV Smoothing & Redistribution

### TLDR - Improving Proof of Stake Economic Security via MEV Redistribution (Chitra & Kulkarni)**

Maximal Extractable Value (MEV) has generally been viewed as a negative, parasitic aspect of economic transactions on blockchains that increases costs for non-strategic users. Recent work has shown that MEV is not always bad for social welfarein crypto networks. In this note, we demonstrate that if rational validators in Proof of Stake (PoS) protocols are able to earn a portion of MEV revenue, by a process we call MEV redistribution, they are disincentivized to unstake and lower economic security.

We construct a joint staking-lending dynamical system in which a fraction of MEV revenue is used to increase staking returns. We formally show that this MEV redistribution can avoid bad competitive equilibria between staking and lending in which no users stake under benign conditions on the reward inflation schedule of the protocol,and conduct numerical simulations that demonstrate this. This represents another potentially positive externality of MEV, provided that the mechanism for redistribution
is well-designed.

### Links
* [Improving Proof of Stake Economic Security via MEV Redistribution](https://people.eecs.berkeley.edu/~ksk/files/MEV_Redistribution.pdf)
* [Comittee driven MEV Smoothing](https://ethresear.ch/t/committee-driven-mev-smoothing/10408/3)

### TLDR - Burning MEV through block proposer auctions

The core idea of this proposal is to auction off the “right to build a block” on the consensus layer through an in-protocol burn auction. Once a winner is selected, the execution block they propose will be one that provably burns at least as much ETH as their bid. The idea is that the highest bid will naturally approach the maximal extractable value (MEV) in the block, therefore most of the MEV should be directly burned.

### Links
* [Spam resistant block creator selection via burn auction](https://ethresear.ch/t/spam-resistant-block-creator-selection-via-burn-auction/5851)
* [Burning MEV through block proposer auctions](https://ethresear.ch/t/burning-mev-through-block-proposer-auctions/14029)

## 3EV ~ MEV Philosophy
### TLDR
Monarch EV + Mafia EV + Molach EV = 3EV

* [This is MEV by sexy sun](https://youtu.be/8qPpiMDz_hw)

#### Mafia EV
Mafia Extractable Value arises when one agent (coalition of agents) gains an asymmetric knowledge of another agent's private information (asymmetric sophistication)

* Sandwhiching
* Generalized Frontrunning
* Trading on limit-order-book imbalance, gain knowledge of other agent's utility (intent): see more bid than ask, take best ask and make best bid

#### Molach EV

Molach Extractable Value is the value that is surrendered to the Molach, i.e., uncoordination

* Negative externalities caused by inexpressive mechanisms, eg. shrinked transaction quality trilemma because of spam from random ordering
* OG "HFT arms race" where arms race cost is transferred into higher spreads for users
* Lack of cross-domain bundles make searchers price-in the risk, does less arbs, making market less efficient

#### Monarch EV

Monarch Extractable Value arises from the fact that the coordinator (eg. sequencer, validator) has the ultimate power of deciding the ordering/allocation of spec-on-state(which specification/property does this new state satisfy)

* Validators accrue value because they have power of determing block content
* Cross-domain market maker bridge extracting value by market making swaps
* Colocation fees that accrue to exchange/latency service providers, who has power of deciding the outcome

#### Benefits
* Distinct Values (source)
* Formalizable (social process)
* Settle "bad" MEV
* Tradeoff (transform) space clear
* Implies clear solution recipe
* Research MonarchEV disttibution!
* Research programmable privacy!
* Presupposition test (context clear)

#### Links to other sxysun work
* [Optimistic Social Sequencing](https://www.youtube.com/watch?v=l_gkFntA1cA)
* [Rollups on MEV](https://www.youtube.com/watch?v=JCZDd0iCMsg)
* [Speeding up the EVM (unrelated)](https://writings.flashbots.net/speeding-up-evm-part-1)
* [Random Half-Baked thought](https://twitter.com/sxysun1/status/1578955022229872640?s=20&t=Fola9P0D_jzzSVeKtO23Lg)

## MEV Capturing AMM

### TLDR

A prevailing thought is that the power of transaction ordering is mostly in the hands of block-builders in the current MEV-Boost and PBS specifications. In this write-up, ideas for new AMM designs are presented that would shift the transaction ordering power, at least partly, to AMM designers and liquidity providers. These constructions would allow AMMs to capture part of the MEV that is currently only harvested by block-builders and proposers.

High-level idea:

New MEV capturing AMMs can auction off the right of the first trade per block via a smart contract auction. This would imply that normal users can only trade against the McAMMs after the auction winner has traded, as otherwise, their trade will fail. It turns out that in such a setup, it is game theoretically optimal for block-builders to respect the first execution right of the AMMs and sort trades such that the first trade is done by the auction winner and normal user trades are not reverting. By auctioning off the first trade per block, AMMs can basically sell their MEV and capture a revenue from it. Since most MEV can usually be extracted with the first trade in a block, McAMMs and their LPs can capture most of their MEV with this mechanism.

### Links
* [McAMM - MEV capturing AMM](https://ethresear.ch/t/mev-capturing-amm-mcamm/13336)
* [McAMM presentation at Devcon](https://youtu.be/kK8gt318WeI)
* [DMcAMM - Dynamic MEV capturing AMM](https://ethresear.ch/t/dynamic-mev-capturing-amm-dmcamm/13849)
* [MinMEV AMM - MEV Minimizing AMM](https://ethresear.ch/t/mev-minimizing-amm-minmev-amm/13775)

## Other Relevant Links
* [Since The Merge how things are changing](https://pintail.xyz/posts/since-the-merge/)
* [Modeling Realised Extractable Value in Proof-of-Stake Ethereum](https://www.youtube.com/watch?v=THKbs5YBWpk)
* [Structuring Blockspace Derivatives](https://mirror.xyz/0x03c29504CEcCa30B93FF5774183a1358D41fbeB1/WKa3GFC03uY34d2MufTyD0c595xVRUEZi9RNG-dHNKs)
* [Next-Block Base Fee Options: Towards a Practical Implementation](https://mirror.xyz/0x03c29504CEcCa30B93FF5774183a1358D41fbeB1/dKgbn5YA3S5AL_qbUWq4HHZAjQSJGZf8oEPZ5Q89aFc)
* [Thread on Encrypted Mempools](https://twitter.com/0xQuintus/status/1598726459723390976)
* [Rollup Day ~ MEV on L2s](https://youtu.be/gS6xHH5uboE)
* [Leader Election from Randomness Beacons and Other Strategies](https://a16zcrypto.com/leader-election-from-randomness-beacons-and-other-strategies/)
* [MEV Protection on a DAG](https://www.youtube.com/watch?v=9WLoJRrnTsA)
* [MEV mitigation using modular DAG-based protocols](https://twitter.com/samlafer/status/1569876740876673025)
* [Exploring MEV in the Modular stack](https://www.youtube.com/watch?v=lLuHFFbYv0Y)
* [Modular Summit MEV Panel](https://www.youtube.com/watch?v=DMUf4wZRp5I)
* [MEV at the Liquidity Layer of Bridges](https://www.youtube.com/watch?v=F_zi9oToHtU)
* [MEV in Message Passing](https://www.youtube.com/watch?v=jCKumKWtYVQ)
* [Symbolic MEV Extraction (brilliant)](https://www.youtube.com/watch?v=VkSR9jz_C-0)
* [MEV on Polygon](https://github.com/BrunoMazorra/Hamelin)

# MEV in Cosmos

## Ferveo: Fair Ordering Protocol
Ferveo is a fast platform for distributed key generation and threshold decryption that can be integrated into Tendermint. Using Ferveo, a validator set can generate a distributed private key where each validator's share of the private key is weighted proportionally to their staked amount.

The distributed key generation (DKG) is efficient enough to perform once per epoch and the underlying cryptographic schemes allow for real-time decryption of encrypted transactions. Ferveo allows the validator set to commit to encrypted transactions prior to threshold decryption, preventing public visibility of pending transactions and helping prevent transaction front-running.

Ferveo is a collaboration between Anoma & Osmosis Labs.

#### Links

* Ferveo: Threshold Decryption for Mempool Privacy in BFT networks [(Paper)](https://eprint.iacr.org/2022/898.pdf)
* Ferveo [presentation](https://www.youtube.com/watch?v=nDJ7qNFAqX0) at AMS 22' by Chris Goes
* Ferveo [Docs (Anoma)](https://github.com/anoma/ferveo/blob/main/book/src/SUMMARY.md)
* Anoma [White Paper](https://github.com/anoma/whitepaper/blob/main/whitepaper.md)
* ZK Hack Ferveo & Plonkup [Workshop](https://www.youtube.com/watch?v=5u5VIzjom5E)

## Skip
Skip is building ecosystem-aligned MEV products on Cosmos.

We amplify the effects of "good MEV" (arbitrage & liquidations) and reduce the effects of "bad MEV" (sandwiching & frontrunning), distributing the rewards to those who deserve it most: validators and their stakers.

Skip is currently on testnet for Juno, and will be launching on Evmos, Terra2, and other Cosmos chains soon. On Osmosis, Skip is building a custom MEV-capture module

* Documentation [searchers + validators](https://skip-protocol.notion.site/Skip-Documentation-a940cd75b99548c7880f1d35fb547d5b)
* Satellite [Dashboard](https://satellite.skip.money/) & [Explainer](https://medium.com/@skip_protocol/announcing-mev-satellite-the-first-cosmos-ecosystem-mev-dashboard-9c1445e29e22) tracking MEV on Osmosis
* State of MEV on [JUNO](https://medium.com/@skip_protocol/skips-state-of-mev-juno-667a51a17b70)
* [Skip Select](https://twitter.com/SkipProtocol/status/1582576810448994304)
* ProtoRev Module Community Proposal: Capturing MEV as Protocol Revenue on Chain [(Osmosis governance Proposal)](https://gov.osmosis.zone/discussion/7078-skip-x-osmosis-proposal-to-capture-mev-as-protocol-revenue-on-chain)
* Osmosis [Thread](https://twitter.com/bpiv400/status/1550600105706881037?s=46&t=mayA_3IyB0mG-xbsyOm-Rw)

## Mekatek

Mekatek is building an open blockspace market for the interchain future, that enables expression of a rich set of preferences and to guarantee fee distribution to all parties in the value chain.

Mekatek subscribes to the theory of MEV conservation, where MEV can neither be created or destroyed but instead exist at the intersection of varying security models. The best solution is to make it transparent and allow users to set their preferences as to how that value gets distributed.

* [Thesis](https://meka.tech/thesis)
* [Zenith product](https://meka.tech/zenith)
* [Analysis of Osmosis atomic arbitrage](https://meka.tech/writing/analysing-the-atomic-arbitrage-space-in-osmosis-9fc75742-09e7-4352-8145-176ad47049cc)
* [Toxic order flow thesis](https://meka.tech/writing/toxic-order-flow-5ab9af99-7b77-4efa-b360-31054046617e)
* [Potential & Risks video](https://www.youtube.com/watch?v=tH4dA8lKh9s&list=PLatdU75AYX9XAIw6X9dRlTsMa5EW4XUm-)

## FairBlock
Fairblock is a simple technique that allows eliminating bandwidth overheads for threshold-based commit-and-reveal schemes. Use it to protect against front-running.

FairBlock leverages Identity-Based Encryption to make a practical MEV prevention mechanism based on standard cryptographic schemes. In FairBlock, each encrypted block (or range of blocks) has its own private key named the block key. Any party can decrypt the transaction of that block (or range of blocks) with the proper block key. The block key will be available to compute only after the finalization of transactions’ ordering. To compute the block key, an honest majority of a committee e.g. 2/3 should send their share of the block key, and anyone can aggregate the shares to compute the block key.

FairBlock does not have limitations of previous approaches (which will be explained in a detailed blog post later) and also can be seen as a complement to well-known projects such as Sikka, Ferveo, and ChainLink FSS. Compared to threshold decryption, FairBlock does not need each validator to send a decryption share for each encrypted transaction in the block. To be more specific, validators in FairBlock send shares for each block, not for each transaction.

* [Sergey Gorbunov Thread](https://twitter.com/sergey_nog/status/1516593886696726532?s=46&t=K7nT_7yPWiZwxUHCxqXcFQ)
* [Medium Post](https://medium.com/@pememoni/the-cryptid-of-mev-1c0a65b72710)
* [Github Repo](https://github.com/pememoni/FairBlock)
* [FairBlock: Preventing Blockchain Front-running with Minimal Overheads,[Paper]](https://eprint.iacr.org/2022/1066)

## The Schedular (ATOM 2.0)

### TLDR from WP:
The Scheduler system works as follows:
1. When the consumer chain enables the Scheduler module, it can enter
into a cross-chain contract to provide a portion of their block space (e.g.,
one block every minute). Chains may sell as much blockspace in the
marketplace as they wish, above some minimal threshold.
2. Once the agreement is in place, the Scheduler issues non-fungible token
reservations representing each future block region on the consumer chain.
Reservation tokens from all participating chains are then periodically auc-
tioned in batches.
3. Optionally, tokenized reservations may be traded on a secondary market.
This is possible until the reservation is redeemed to the appropriate val-
idator on the partner chain, along with the desired transaction sequence.
4. Upon successful block execution, a split of proceeds from the Scheduler
auction are sent back to the partner chain.
By purchasing synchronous regions of block space on different chains, users can
lock-in arbitrage opportunities or schedule cross-chain settlement transactions
with strong execution guarantees.

### Links
* The Scheduler [updated Informal Post](https://informal.systems/2022/10/24/interchain-scheduler-design-update)
* ATOM 2.0 [White Paper](https://gateway.pinata.cloud/ipfs/QmWXkzM74FCiERdZ1WrU33cqdStUK9dz1A8oEvYcnBAHeo)
* Tarun skepticism [tweets](https://twitter.com/tarunchitra/status/1581781891341963265?s=20&t=e1fi8kTRrRfue6T2EcJrUQ)
* [Deep Dive video](https://www.youtube.com/watch?v=MUQVPqmtS4Q) with Zaki & Buchman

## Sunny on MEV
* [Nebular Summit](https://www.youtube.com/watch?v=d-NJ9aUqtwU)
* [MEV Roast on Private Mempools](https://youtu.be/Hnw_tMGNx3A)
* [Sunny & DEV ZKP](https://www.youtube.com/watch?v=ohHRqUf7OKE)
* [Cosmoverse conversation](https://www.youtube.com/watch?v=VxE-cGfUOvQ)
* [Cosmoverse Panel](https://www.youtube.com/watch?v=vRzX-trYsLI)
* [Classifying MEV, ETH Global](https://youtu.be/psY-hGQO9BI)

# MEV on Solana
Solana has experienced periods of network congestion from disorderly attempts by traders to capture MEV. Transaction fees are low so traders deploy bots to resend the same transactions hundreds of times, hoping one of those transactions lands profitably.
## Jito Labs

### TLDR

Jito released a new client for validators to eliminate the spam from MEV and provide rewards to stakers. The solution is an auction. Traders will submit bids for sequences of transactions they believe are profitable. Third party block engines run complex simulations to determine the combination of transactions that provides the highest value. These bids are then given to validators and stakers (jitoSOL).

Jito is the only liquid staking service for Solana that distributes MEV (maximum extractable value) rewards to holders. The Jito Stake Pool enables users to stake their Solana tokens in exchange for a liquid stake pool token (JitoSOL). The JitoSOL token provides liquidity while earning a combination of staking rewards and MEV rewards.

### Basic Architecture
Jito is a suite of products that enables validators to earn more revenue from MEV while eliminating unproductive network spam. Jito-Solana is the centerpiece of this network and manages communication with our relayer and third-party block engines. Jito Labs Block Engine is the first integration but additional third-party products will be added as available.

The result for validators is a way to profit from the MEV extracted during their leader slots. This revenue is collected in a non-custodial fashion and set up for effortless distribution to validators and stakers based on each validator’s custom fee parameters.

In addition to the client, the Jito Labs Block Engine connects relayers, searchers, and validators via an off-chain blockspace auction. The Block Engine simulates every transaction combination and forwards the highest paying batch of bundles to the leader for block inclusion.

The last component of the product suite is the Jito Relayer, which acts as an outsourced transaction processing unit (TPU) proxy. It filters and verifies transactions on a separate server to reduce the burden on validators. The relayer submits verified transactions to our Block Engine and the validator.

### Links
* [High Level TLDR video](https://youtu.be/GyYY_SJCNow)
* [High Level Slide deck](https://docs.google.com/presentation/d/1Ah7YB68HzSLWfB-cJkst8eWRtVNBYhGEWVwCt56_nYk/edit#slide=id.p)
* [Open Source Announcement](https://medium.com/@Jito-Foundation/jito-solana-is-now-open-source-e1028c53fae1)
* [Github repo](https://github.com/jito-foundation)
* [Docs](https://jito-foundation.gitbook.io/jitosol/)
* [MEV Dashboard](https://jito.retool.com/embedded/public/7e37389a-c991-4fb3-a3cd-b387859c7da1)
* [Solana Validator 101: Transaction Processing](https://jito-labs.medium.com/solana-validator-101-transaction-processing-90bcdc271143)
* [Jito Block Engine Expands Access to All Solana MEV Traders](https://jito-labs.medium.com/jito-block-engine-expands-access-to-all-solana-mev-traders-96704fd6faaf)
* [Co-Founder interview on Logan Pod](https://www.youtube.com/watch?v=WUBLLFTACVM)

### Other MEV resources
* [@0xmisaka MEV Cookbook: Arbitrage](https://twitter.com/0xmisaka/status/1506318206281170964?s=20&t=EVYARBvq3ivebZoI6rHEDw)

### Solana Overview
* [Toly Thread on current roadmap/engineering problems](https://twitter.com/aeyakovenko/status/1584676106460094464?s=20&t=Fola9P0D_jzzSVeKtO23Lg)
* [Docs](https://docs.solana.com/introduction)
* [Proof of History](https://medium.com/solana-labs/proof-of-history-a-clock-for-blockchain-cf47a61a9274?source=post_page---------------------------) - a clock before consensus
* [Tower BFT (Consensus)](https://medium.com/solana-labs/tower-bft-solanas-high-performance-implementation-of-pbft-464725911e79) - POH optimized version of PBFT
* [Turbine](https://medium.com/solana-labs/turbine-solanas-block-propagation-protocol-solves-the-scalability-trilemma-2ddba46a51db?source=post_page---------------------------) - block propogation protocol
* [Gulf Stream](https://medium.com/solana-labs/gulf-stream-solanas-mempool-less-transaction-forwarding-protocol-d342e72186ad?source=post_page---------------------------) - Mempool-less tx forwarding protocol
* [Sealevel Runtime (VM)](https://medium.com/solana-labs/sealevel-parallel-processing-thousands-of-smart-contracts-d814b378192) - runtime VM
* [Pipelining](https://docs.solana.com/validator/anatomy#pipelining) - tx processing unit for validation optimization
* [Cloud Break](https://medium.com/solana-labs/cloudbreak-solanas-horizontally-scaled-state-architecture-9a86679dcbb1?source=post_page---------------------------) - horizontally-scaled accounts database
* [Archivers](https://medium.com/solana-labs/announcing-the-solar-bridge-c90718a49fa2) - distributed ledger storage