MEVconomics.wtf Part 4
Intro
The idea of using concepts from social choice theory to make blockchains more fair through transaction ordering is interesting, but there are problems with how it has been implemented so far :
- Fair ordering mechanisms guarantee certain transaction orderings but don't analyze the economics or costs
- It's unclear if the extra work required by validators to enforce fair ordering has economic value or is harmful
The main goal is to dive deeper into the economics of fair ordering to see if there is real net value, given the costs and tradeoffs. Tarun just want to point out issues, not attack previous work
What is "Fair Ordering" ? (1:45)
Kenneth Arrow's impossibility theorem proves perfect fairness is unattainable in ranked voting systems, which are analogous to validators ordering transactions.
Fair ordering algorithms try to approximate majority votes, but can't fully escape limitations like centralization and "dictatorships" where one validator has too much influence.
The problem lurks in fairness definitions. These definitions describe the properties of the partial transaction orders that result from fair ordering. However, they do not quantify the economic value or rent extracted per partial order, whereas MEV is an economic profit.
Fair ordering is a lie (3:30)
Themis, Acquitus, and Quick Block Ordering claimed Fair Ordering eliminates MEV. Intentions are good, but it faces several problems :
- It doesn't make sense to be agnostic to all applications when some generate regular MEV (AMMs) and others generate spiky MEV (liquidations)
- Fair ordering is not universally applicable to all applications. Because MEV profiles differ across applications, what improves fairness for one app may hurt another app.
- It may be harmful to force validators to do extra work without economic payoff
Furthermore, Other fields like decision theory and AI get impossibility results when studying order fairness for objectives like model quality. The same should be expected for Fair Ordering's impact on the objective of MEV's economic value.
How to break Fair Ordering
Given the above issues, the talk will now dive into the details of why fair ordering is fundamentally problematic
Game Theory (6:00)
Let's consider a two player game :
- The fair ordering protocol that constrains which transaction orderings are allowed
- An adversarial DeFi developer trying to design a protocol that exploits the fair ordering
Following the game mechanics (described above), we analyze this game using a min-max loss function that aims to measure fairness. The choice of loss function affects notions of fairness.
- If the game value is positive, the developer was able to exploit the fair ordering
- If negative, the fair ordering limited exploitation.
The more constrained the set of allowed orderings, the more power the fair ordering protocol has to win.
Why does this game represents Fair Ordering protocols ? (8:45)
Fair ordering protocols permit a large set of transaction orderings, making it easy for adversarial developers to find ways to exploit the protocol. On the other hand, Restricting the set can limit exploitation.
Combinatorial constraints from the allowed ordering set bound the game value.
How this game breaks Fair Ordering ? (9:30)
Given sufficient randomness in orderings, adversarial payoff functions can be constructed to exploit fair ordering.
A DeFi Protocol with liquidation rules that perform poorly on fair ordering's allowed permutations proves that Fair Ordering implicitly picks winners/losers by preferencing some apps over others.
And preferencing some apps is, well...Not fair
About Payoffs
Payoffs represent economic value to users from transactions. Some examples :
- AMM payoffs : The economic value gained by users of an automated market maker protocol based on the transaction order.
- Liquidation payoffs : The economic value from liquidations being triggered based on asset price thresholds and the transaction order
In general, payoffs aim to quantify the profits, rents, or economic welfare generated for users by the execution of transactions in some order
The tradeoff which discriminates (12:15)
The more constrained the set of allowed orderings, the less flexibility adversarial developers have to construct payoff functions that exploit certain orderings.
However, overly restricting orderings makes it difficult for fair ordering protocols to accommodate randomness from things like network latency. This can violate assumptions and lead to unintended consequences.
These constraints create a tradeoff between set size and manipulability. Shrinking the set reduces manipulation but makes the protocol too rigid. On the other hand, expanding the set increases adaptability but enables more manipulation.
If the Fair Ordering protocol allows a sufficiently large set of orderings, the min-max game value is positive, meaning the adversarial DeFi protocol does worse. Hence, Fair Ordering is discriminatory
Let's be optimistic (16:30)
Rather than one universal approach, order preferences tailored to specific applications could be more effective, for 2 reasons :
- A research looked at first-come-first-serve (Arbitrum style) just for the top transaction and formally proved it is always suboptimal versus the best ordering
- The lowest possible manipulation depends on how complex the payoff function is. In other words, simpler smart contracts can be fairer
Instead of seeking perfect universal fairness, we can analyze specific simple policies or simplifying smart contracts.
Overview (1:30)
Most mev research has focused on the current system where users sign transactions that get broadcast to the public mempool. However, there are signs this model is shifting, with more transactions going through private mempools. Analysis by BlockNative showed 3.8% of transactions don't hit the public mempool and the percentage is likely higher now.
The standard mev supply chain relies on searchers seeing transactions in the public mempool, but more private mempools mean searchers can't access that transaction data. So assumptions about how MEV works are becoming outdated
Researchers have proposed better mev auction designs to make things more fair, but these designs only work if transactions are public. If we don't have incentives to encourage people to participate in the auctions they kind of end up going to waste.
Most discussions just complain that privatization of order flow is harmful, as it leads to centralization of block building with a few big players and creates a flywheel effect (described above)
But instead of criticizing, we need to understand why and how privatized order flow is made. From this point, we can get how to incentivize decentralized participation
MEV Supply Chain overview (3:30)
Standard mev supply chain is user -> wallet -> searcher -> builder -> validator, but this view is too simplistic. The wallet to searcher step is where there is the most leverage and negotiating power
Being further upstream in the supply chain confers more leverage. For example, wallets have leverage over searchers in terms of which transactions get passed on.
So this is how transactions get formed :
- UI sends signature request to wallet
- Wallet asks user to sign
- User sends signed transaction to wallet
- Wallet sends transaction to RPC endpoint
- Enters public mempool
Who the fuck Order Flow belongs to ?
All parties in the transaction lifecycle want to capture more of it for themselves. And this flow sort of started to break down because of that.
RPC Providers (5:15)
Common perception is RPC providers control order flow, but custom RPCs face challenges :
- Building custom RPCs has tough barriers to entry for new projects
- Many wallets don't allow easily changing default RPC provider
- It's unclear how custom RPC providers can monetize or get paid
One option is security-focused RPCs : they can provide extra security vs just blasting txs into public mempool, intercept and scan each transaction for risks (Harpie) and Offer options like 2FA approval for high-risk transactions
Another option is RPCs focused on user experience : they improve ease of use compared to existing providers (Infura, public RPCs...). For example, they can Optimize gas prices, avoid failed txs, or wait for price quotes.
Both options should be superior to existing RPCs, but difficult to get users to change default providers. So instead of having users switch their RPC over, we can sell directly to wallets :
- Wallets have more leverage, new monetization options
- Can outsource mev extraction to others
- Users may get some mev share, improving wallet stickiness
- New revenue stream for wallets beyond swap fees
Wallets (9:00)
Wallets have a lot of leverage : they control where signed transactions get sent to, and they decide which RPCs get access to the order flow. Furthermore, they need to find alternate sources of revenue (not all wallets can have a Metamask Swap)
Order Flow is a relevant source of revenue, because not all order flow is created equal. Order flow from bots/arbs has little extractable mev, but less price sensitive users generate more MEV.
Therefore, Metamask is swallowing up the RPC providers and having their own layer on top of them, where they can again provide a lot of these UX security benefits as well but also potentially extract MEV
But having our own layer on top of RPC providers is centralized. The question is, why should wallets open up MEV extraction instead of doing it themselves ? Spoiler alert : we don't need answers right now
Wallets swap fees are more lucrative than mev extraction for now, so wallets aren't prioritizing MEV monetization. Discussion assumes users send txs to wallet and wallet controls flow...For now
Dapps (11:45)
Dapps can initiate signing without a wallet transaction. User signs a hash representing intention, which is not an actual transaction. One example is Sushi with "Sushi Guard", where user signs intent and Sushi Guard extracts MEV. So the wallet doesn't actually see this transaction in this flow and therefore the RPC providers don't even see this transaction
According to Tom, this is not optimal :
- A message can, given certain conditions, be malicious. It's risky for users to sign things they don't understand.
- We don't control transactions that much if the majority of volume is going through a third-party (aggregator, bot...)
Takeaways (14:15)
- Upstream supply chain has more power, that's why everyone is trying to move it up. Actors are behaving rationally, not maliciously
- Current MEV systems assume transactions are public, but this assumption is decreasingly correct
- Early data suggests private mempools are a growing problem
- We don't really want a world where centralized entities control more of the stack (MetaMask does self extraction with swaps + becomes a builder)
- We need to make open/fair MEV auctions to avoid centralized private pools, but we can't rely on benevolence
- More research needed to quantify public vs private mempool issues (we're in a similar spot as before MEV Explorer existed)
Open Questions
- Where extracted MEV ultimately flows (users, wallets, builders) ?
- Do incentives exist for actors to provide open order flow ?
- Would competition lead to sharing MEV with users ?
Intro
An "auction" can be defined more broadly than just price discovery. It can be a mechanism for discovering the best way to interact with blockchains through competition along dimensions other than price.
Quintus wants to give an overview and direction for exploring a broader design space of auction mechanisms beyond what people have discussed
Auctions (1:40)
Reverse auctions are an example where participants compete on dimensions like speed or reliability rather than price. Auctions are useful here because we don't know the best way to accomplish users' goals
The ideal end state would be having an auction mechanism between users and blockchains that helps users accomplish their goals in an optimized way
In this talk, we will not talk about the entire MEV system, but focus on Order Flow Auctions specifically (the green bar)
Taxonomy (3:15)
- Sealed bid auctions determine winner in advance, resemble traditional finance methods
- Auction houses have variations where people bid on single items. Items often relate to what users are trying to execute on-chain (combinatorial auctions allow bidding on subsets of items)
- Batch auctions are similar to combinatorial auctions but batch composition is fixed
- Dutch auctions involve bidding over time
This taxonomy shows some existing design space, but misses an interesting dimension : control over information flow and privacy during the auction. Quintus believes that controlling information flow and privacy opens up new possibilities
Schrodinger's other cat
How it works (6:00)
Let's make a thought experiment involving "Schrodinger's cat" as the auctioneer controlling information flow. This illustrates the concept of controlling access to information.
The cat controls all actions inside its "box" and crucially controls what information can permeate the boundaries of the box. The cat also allows bidder agents/bots inside the box but not necessarily the bidders themselves. This limits information flow.
If the box is fully transparent, then all bidders know full auction details, but this may not be desirable. Fortunaltely, other options exist to limit information leakage
- Only winner knows details
- No one knows until later
Concrete example : Auctioning a large trade without leaking the full trade size to all bidders :
- If fully transparent, competitors can front-run the trade execution since they know the details. This raises execution costs.
- If only winner knows, execution is more favorable since they limit information leakage.
This could be an interesting usecase for oracles. Some examples :
- All of the bidders are aware of an oracle update, but only the winner get information
- Selling early access to oracle updates before they are public.
Bidders now have incentive to bid more for this update, because it gives them an edge in the market
Recap (11:25)
- Auction designs can select for competition that increases revenue, while limiting detrimental impacts like front-running that hurt users.
- Information asymmetry can be monetized, e.g. Oracle updates (described above)
- Controlling information flow allows controlling actions, like keeping sensitive details private to prevent unwanted front-running.
The "cat in a box" example illustrates one way to control information, but many approaches are possible by combining cryptography, distributed systems, etc. The key guiding principle is to link controlling information availability to enabling or limiting actions.
How do you control information access here without leaking ? (13:15)
SGX provides confidential computing but has trust assumptions. Alternatives like multi-party computation exist, like multiple parties running these SGX, or have the bidders themselves running different instances.
This is an open design space anyway. As there are likely possibilities that are still undiscovered in designing auctions, there would be new approaches to information control as well.
Order Flow Auctions (1:30)
- Users initiate transactions through a DApp, wallet, or RPC provider
- MEV services act as matchmakers between users and searchers
- Searchers bid on user transactions to maximize profits, send bundles to try to win (if no searcher bids, fallback to mempool)
- Builders include bundles from winning searchers in their blocks
- Validators validate blocks and receive payouts from builders
Who takes what ? (2:30)
- Users : In the current model, users do not get any MEV revenue directly. But in the future, they may be able to request a share of the profits.
- MEV Services : They act as middlemen and may take a fee in the future as their revenue.
- Searchers : Get a significant portion of MEV profits, some on-chain and some unknown/off-chain. This is their main revenue.
- Builders : Can keep some of the MEV profits passed to them by searchers. The rest they distribute to validators.
- Validators : Receive MEV revenue from builders as payouts for including their blocks. This is their main source of MEV revenue currently.
- Relays : Do not receive MEV revenue directly as of now.
Defining all the value (3:30)
More roles are taking a share of MEV revenue than before, and it can potentially split further. Now that searchers are separated from wallets/builders, we go through order flow auctions
In the past, Searchers kept ~70% of MEV profits and Validators/Builders received ~30% of MEV profits
In the present, things were inverted : Builders and validators now receive a larger portion, about 70% of MEV profits and Searchers receive around 30%
What we can expect in the future :
- MEV services may take a cut as a fee for matching users and searchers
- Users may be able to request a specific share of MEV profits
- Order flow auctions could allow users to negotiate a higher percentage
- The split between searchers/builders/validators may continue shifting
- More roles are taking a portion of the MEV revenue over time
MEV revenue split of today's roles
Disclaimer (5:30)
We can only see on-chain MEV profits on DEX platforms. We cannot quantify off-chain MEV on centralized exchanges, and CEX-DEX is another sort of MEV.
Total MEV reality is under-indexed here, because much more MEV occurs off-chain but we can't quantify it.
Searcher on-chain profits (6:00)
On-chain MEV profits attributed to searchers are estimated between $50k and $100k daily
In a normal flow, searchers transfer profits to builders, and builders can keep some profits and transfer the rest to validators. But there are exceptions which make the analysis difficult :
- Some builders have zero profit
- Searchers skipping builders
- Validators set directly as fee recipients
Proposer revenue (8:30)
Considering this is hard to quantify builder vs validator split, we look at combined revenue, and daily total proposal revenue increased from $600k/day in late 2022 to $1M/day in early 2023
Since the beginning of the year, the MEV Split Shifted to much less for searchers, and more to builders & proposers
Where can we extract and return ?
The funnel of MEV (10:15)
Looking at the flow again, when the order flow auction take the order information from the application team or the users, they will be able to also know maybe how much the user already request or they want to be shared back. So Searchers see user requests, can offer high % back for exclusive order flow.
MEV Boost data enables extracting enforceable bidding surplus amount :
- Can calculate "bidding surplus" between 1st and 2nd highest bids
- Deducting surplus still leaves highest bid, validators must take it
- So surplus could be extracted for user revenue share
Searcher on-chain profits (12:30)
The first approach is to look at searcher profits from MEV trades as percentage of total trade volume, and quantified profitability per MEV transaction :
- Median profit margin is about 3 bps (0.03%)
- Most trades have 0-5 bps margin
- 95th percentile (top 5%) trades reaches profit margins of hundreds bps
- 99th percentile (top 1%) trades have ~1000 bps margin
Estimates from EigenPhi are likely upper bounds. Actual amounts are likely lower in reality, as not all trades are profitable
The block bidding "surplus" (15:15)
The Second approach is to analyze block bidding surplus. The difference between highest and 2nd highest bid as we described earlier is considered as like a bidding surplus :
Methodology
- Get latest bid from each builder
- Take top 2 bids
- Surplus is difference between them
Consistent numbers
- ~$5 surplus per block
- ~$25k surplus per day
- ~2 ETH over 1000 blocks
As a result, surplus is 2-5% of total top bid. Based on maket share :
- 5% of DEX market share gets $37.5k surplus
- 50% of DEX market share gets $375k surplus
Those estimates are lower bound, it's the enforceable part that's coming from the block beating layer
Full picture (18:30)
- We saw that validator/builder share shift from 30% to 70%
- Builder/proposal revenue share unclear (marked red unknown %)
- The searcher on-chain profits part is like through the OFA design we know that users can already specify how much percent they want to give it back (marked green unknown %)
- Total estimated on-chain revenue is $1.4M daily and $42M monthly (upper bound)
OFAs may shift on-chain vs off-chain portions. From the user's perspective, this is our MEV. We want to get a percentage back essentially because we are the value originator
Validators can earn returns from various sources (staking, lending, MEV, derivatives) and view returns from these sources as a portfolio to optimize. As a result, different sources of return compete for allocation in the validator's portfolio.
But staking is special. It serves the dual purpose of providing returns and securing the network. It has a privileged status that makes it different than returns from lending, derivatives etc. that don't directly contribute to network security. This raises several questions :
- Can we use MEV as an incentive to in some sense improve the security of the chain ?
- Can MEV act as some kind of an economic lever to incentivize security ?
- Can it be used as a way to get validators to avoid some bad economic equilibria that might arise ?
We will try to answer this in this talk
Proof-of-Stake protocols (3:00)
This formula explains how the supply changes over time : take the supply last time step, add however much reward got inflated, and then add or subtract the protocol-owned or burned liquidity
From math point of view, the validator side is viewing this as a portfolio optimization problem, which is basically a risk/reward ratio.
A portfolio optimization perspective (4:00)
To optimize, validators are going to look at the sources of return they can get, and they're going to compute a mean return for each of those sources.
Of course this could include other things like derivatives if they're engaging in those assets according to their risk/reward ratio.
This is a well-studied optimization problem that can be solved with good estimates of returns and risks
Staking-Lending Dynamics (5:00)
- Staking yield comes from Natural reward inflation and MEV bonus redistributed back to validators (MEV bonus is redistributed proportional to validator's portfolio)
- Lending yield based on Borrow demand and scaled by a risk-free rate
Key question : How do validator portfolio choices and MEV redistribution affect incentives?
Staking VS Lending (7:30)
Prior work showed staking often needs inflationary rewards to compete with lending yields. With constant or deflationary rewards, validators prefer lending over staking : If validators prefer lending, it can compromise network security since fewer validators are staking.
Research showed a similar dynamic occurs between staking and derivatives returns
Redistributing MEV could provide an alternative way to incentivize staking and avoid highly inflationary rewards. But how does MEV redistribution impact the staking-lending dynamics ?
Staking VS Lending VS MEV (10:45)
While MEV is often viewed negatively as parasitic on networks, redistributing it can incentivize the beneficial behavior of staking
If the MEV redistribution parameter α is set high enough, the model shows validators can be sufficiently incentivized to stake without relying on highly inflationary staking rewards
MEV redistribution provides an alternative way to incentivize staking and prevent validators from leaving staking for other returns. That said, The precise mechanics of how MEV is redistributed are very important for aligning incentives properly
Distributive Properties of Redistribution (12:30)
Aligning incentives properly may not suffice. We must allow validators to have some kind of predictable revenues to make MEV redistribution effective
Like said before, validators are trading off a risk/reward to optimize their portfolio, and predictable revenues reduce risk
Future directions (14:00)
An important area for future research is analyzing the potential centralization risks of MEV redistribution, especially feedback loops.
Existing transaction fee mechanisms could potentially be modified to implement MEV redistribution in practice :
- We need appropriate mechanisms to prevent validators from making off-chain agreements or defecting from redistribution
- We must analyze the cooperative game theory of validator pools under MEV redistribution
Open question : Can the compatibility of closed-loop incentives be formally proven for MEV redistribution ?