A Tale of Two PFOF Models
NB: this is an adaptation of my Latex publication, hopefully no Latex left in here. I am adding the article here so that we can more easily debate it.
Abstract: Flow Providers (FP) are now offered a variety of Payment For Order Flow (PFOF) Solutions to choose from. The approach is the same: an Order Flow Auction (OFA), by which Market Makers (MMs) bid for some flow, but the underlying mechanisms vary from solution to solution. While it is difficult to give a definitive answer as to which solution is the best, we can categorize them broadly into 2 categories: the first one is the batch auction where, as in TradFi, Market Makers (MMs) bid for the total incoming flow over a future period of time and the second is the individual bidding model where each MM is bidding for each transaction separately. In this short article, we want to explore, modelize and compare these two models. Note that this article is less of a definitive answer to a question and more a trial at researching and modelizing the question itself, I do not pretend to give a definite answer to the problem, there might be a lot of flaws in my reasoning, and I just want to lay out my reasoning and to move forward this discussion with all of you.
Acknowledgements: I would like to thank Stephane Gosselin for sparkling this debate on a cold evening in London, as well as Eric Siu, Badri Natarajan, Alex N. and Ankit Chiplunkar for their thoughts on the topic.
I. Value Extraction Modelling
Given an incoming transaction (not necessarily a trade, or swap as such), we define V the total (maximal) value (MEV) that can be extracted from it. This value is composed of the value that everyone with public access to the markets and blockchain can extract, we call it V_\beta, such an example is your typical atomic arbitrage (be it a simple backrun or a sandwich), and another value which depends on each market participant access to private information, be it private order flow, or some other signal, we call it V_\alpha.
We then have V=V_\beta+V_\alpha.
I.I In the absence of alpha
In the absence of V_\beta, we have V=V_\alpha.
Each of the k market participants looking at an incoming transaction will try get an estimate \hat{V}=E[V] of V, and with enough sophistication, everyone will end up with the same estimate as they all have access to the same information, and this estimate is going to be unbiased, i.e. \hat{V}=E[V]=E[V_\beta]=V_\beta.
I.I.I. Bidding on individual transactions
In this section, we are placing ourselves in a PFOF model where each market maker/mev searcher bids for each transaction individually and separately.
For a given transaction, market makers/mev searchers will bid an amount b such that:
b=\hat{V} \cdot (1-m)
where m is the discount on the expected value they plan to extract, i.e. the net profit they will keep. Note that in on-chain reality, m is split with the validators as execution-costs for the MM that will bribe the validator for inclusion. And because of competition, as the number of market makers/mev searchers increases, their marginal profit diminishes as competition intensifies, in other words:
\text{lim}_{k \to \infty} m = 0
and
\text{lim}_{k \to \infty} b = \hat{V}
meaning the FP gets the fair value of the transaction.
I.I.II. Batch auctions on total future flow
We now model what happens if the market maker bids for all the incoming transactions from the FP for the next period \tau (where period can range from a few seconds to months or years).
In period \tau there will be n transactions, such that the total value to extract from the flow is given by:
V_T=\sum_{i=1}^n \frac{V_i}{(1+r)^{t_i}}
for each transaction i \in \{1,...,n\} happening at time t_i, the value V_i is discounted at the risk free rate r (or any rate you might use for cash flow discounting purpose). Now, when a market maker is bidding for such a flow, he needs to estimate V_T, it can be done based on the average of the last periods, if there is data, and the more periods, the more robust the estimator (probably).
The estimation of V_T made by the market maker is:
\bar{V_T} = E[V_T] = E\left[\sum_{i=1}^n \frac{V_i}{(1+r)^{t_i}}\right]
Now, most of the random variables in the above formula make it hard to get an unbiased estimator of V_T:
- there is uncertainty over n
- there is uncertainty over each of the V_i
- the bigger \tau, the bigger the uncertainty
Also, note that because these are often longer terms agreements (a la TradFi), mev searchers do not compete here, and only market makers will compete, thus reducing the set of competitors.
Due to the reduced competition and larger uncertainty, it is clear that bidders are going to be more conservative and the bid for the total flow B= (1-m) \cdot E[V_T] is such that the resulting average bid per transaction b'=\frac{B}{n} will be lower than the average bid b for individual transactions. It is also worth noting that when the market maker is bidding for a total flow, the FP might not redistribute the value to the end users proportionally to the value of their transactions.
This model results in an underbidding and a less fair distribution of the value to the end users.
I.I.III. Batch auctions on total current flow
Now, if the batch auction is happening at a high frequency, (eg: on a block basis), and bidders can actually see the transactions they are bidding for then, they can compute the expected value of each of the transactions separately as in the individual transaction bidding, but some transactions might collude and result in a lower total extracted value. It is better to be able to chose which transactions to take or not. It then results in a lower or equal value for the bidder, and thus a lower or equal bid. This situation is then better than the batch auction on future flow but worse than the individual transaction bidding model from a FP perspective.
I.II. With alpha
In reality is alpha exists and V_\alpha \geq 0. Now this value is different for every bidder, meaning: V_\alpha^i \neq V_\alpha^j, \forall i\neq j \in \{1, ..., k\}. We assume that bidders are sophisticated enough to predict, on average, the true value of their own alpha, i.e. \hat{V_\alpha^i}=E[V_\alpha^i]=V_\alpha^i.
We then have that the value of a given transaction for bidder i is
E[V^i]=E[V_\beta] + E[V_\alpha^i]=V_\beta +V_\alpha^i
And the bid is given by:
b^i = (1-m) \cdot (V_\beta +V_\alpha^i)
As the number of bidders k increases, the margin m tends to 0.0, and we can get a lower bound for the bid:
\text{lim}_{k \to \infty} m = 0
and
\text{lim}_{k \to \infty} b \geq \hat{V_\beta}
meaning end users get at least the public value of their transaction.
When bidding for a total flow on a given period, the reasoning described previously can be re-applied, adding one more random variable to the formula and the derived conclusion still holds true.
II. Objections
In this section we address the objections our reasoning have faced.
II.I. Value leakage
In the individual transaction bidding model, the losers of the auction know that the target transaction is going to be brought on-chain, they can then:
- front-run it on CEX and backrun it on DEX: Yes but this causes no harm to target transaction
- front-run it on CEX and front it on DEX if they can get top of block access: most likely they are a block builder and because block builders always have last look right, they can do it anyways, whether there is PFOF or not whichever of the two models it goes through, so this makes no difference
So, information leakage is not really a concern here.
II.II. Winner’s curse
If a MM won the auction, it means he bid more than the others and he might be concerned about that: do the other MMs know something that he does not? Maybe they have some private information (V_\alpha) telling them that this transaction is not worth that much. Yes, this is indeed possible, or the winner has the V_\alpha that the others do not, like some private flow that is coming in and offsetting it. This is a very similar situation to RFQ auctions in TradFi. In any case, this only negatively impacts the MM itself, not the end-user.
III. Conclusion
From our modeling, it seems that the FP (and by extension the end users) would receive a fairer and higher value for their transactions with the individual transaction bidding model. Now, this is of course more complex to implement in practice, especially in TradFi, and it adds some latency to the user tx. On Ethereum, the perceived latency is effectively zero as blocks are already 12s long and this would not delay the transaction by a block. On lower latency chains, this can be different and it may add some blocks of latency to the user transaction. It is to note that most end users transacting on the blockchain are not rushed and would probably be happy to experience some delay in returns for a better price/lower fees.
Interestingly, this is the model that the SEC recently suggested in their latest proposal [1] on the topic.
References
[0] Ankit Chiplunkar & Stephane Gosselin - The Orderflow Auction Design Space
[1] SEC - Press Release
SEC Proposes Rule to Enhance Competition for Individual Investor Order Execution
[2] Quintus Kilbourn -
Order flow, auctions and centralisation II: order flow auctions
