Order Flow Auctions

TODO: * explain OFA's or link to explanation * make last few sections more accessible to lower-context people # Order Flow Auctions In recent months, much attention has been devoted to the notion of order flow auctions in the blockchain setting. The motivation is twofold: (I) help users achieve better execution than their degree of specialisation allows in such a complex environment. (II) allow users to internalise the value generated by their economic activity through a mechanism that is in line with blockchain design principles of decentralisation to combat the appeal of expedient mechanisms which threaten to erode decentralisation guarantees. The aim of this article is to highlight how the design space and objectives of blockchain-based order flow auction design make the task of finding an optimal solution more exciting, more challenging and meaningfully different from traditional settings and theory. The target audience in mind is one that is familiar with auction, mechanism or information design literature as well as a good high-level understanding of the workings of PBS and the transaction execution. The article will not attempt to outline a design which is "best," but rather establish a common understanding of the lay of the land and its obstacles from which the design tradeoffs can be explored in pursuit of satisfactory designs, given some goals. ## What's an OFA? (this section is a TODO - also should explain diff between intents and transactions) Double procurement auction. One problem here is positing two sides to a market. This doesn't take the world where users are paying each other into account (or does it?). Ultimately we **can** think of this as a two sided market. The case where one "user" is paying another is probably facilitated by a 3rd party so we can think of it as a transfer from user to counterparty to other user. ## Objectives Although the introduction lays out (I) and (II) as broad motivations, an order flow auction designer would naturally want a more actionable set of goals. Traditionally, a large emphasis has been placed on properties such as truthful bidding, envy-freeness and efficiency in mechanism design. In the case of OFA design, the desiderata arguably may not include some of these properties while encompassing different properties tailored to the setting. ### Whose Welfare? An order flow auction (OFA, henceforth) fits into a larger ecosystem of mechanisms - with blockchains at its core. These mechanisms are not soulless machines but are operated by economically rational agents with operating expenses. Often, these rational agents, by the design of the systems they operate, find themselves in powerful monopolistic positions, if only briefly. Some take this to suggest that mechanisms must be designed to take into directly into account the welfare of all ecosystem participants - both users and operators. Whereas it is true that the health of the system depends on the economic wellbeing of the actors which operate it and that ignoring the strong economic position of certain actors is not feasible, this article will take the position that it is ultimately the welfare of users of the system which must be taken into account. The health of the coordination system is important insofar as it impacts the welfare of its users and the economic power given to some of these actors serves only as a constraint in the design which cannot be ignored. Another way to arrive at the same conclusion is that overall welfare is likely maximised by new users joining the system, a likely consequence of user welfare increasing. Considering the OFA specifically, there are three broad classes of actor involved: the user ("seller"), the bidder and the auctioneer (a role which can be filled by many actors at once). Unlike much of the literature which focuses on bidders, the desiderata of the auction should be crafted with the welfare of the user in mind. This becomes complex when the seller is considered an agent instead of simply the recipient of auction revenue. One can broadly describe the setting as a **double auction designed for the seller.** ### Definition of Welfare Having identified the agents whose welfare is of importance, an OFA designer ought to determine what factors are most salient in affecting this welfare. Establishing a user as "anyone who seeks to realise some outcome on a blockchain(s)" is not particularly helpful in this regard. The form of engagement allowed with most blockchains is virtually unrestrained and each form of engagemeng implies a different utility function for the user. A possible solution to this is restriction to a narrow use case, such as desiging an OFA for retail users engaging in spot trading. This is certainly an important use case which would clearly benefit from the existence of an OFA. However, given the generality of the activity blockchains facilitate and can facilitate, and the potential complementarity between these activites, there is certainly room for expanding the scope of an OFA beyond this specific use case. Naturally, there is a limitation on how broad the activities ("items") in the auction can be in practice as a market of counterparties is required for the auction to have meaningful effect. This topic deserves further attention in a different post and this section will serve to highlight which factors could reasonable feature as part of the welfare function without perscribing the exact formulation. **Credibility** Instead of enforcing mechanisms through legal mechanisms that are assumed immune to contravention, the rules of mechanisms in blockchain are enforced by a combination of cryptography, rationality and trust in sets of actors. A user acting under the whims of some auctioneer who can deviate undetectably is taking on significantly more risk than one relying on the honesty of 1 out of n actors and the hardness of factoring. Hence, it is reasonable for us to consider users as having some preference over trust assumptions; or, stated differently, risk implied by participation in a mechanism. Given the variety of methods by which credibility of mechanisms in blockchain are enforced, the notion of credibility of auctions (as introduced by Akbarpour et al.) ought to be expanded into a more nuanced concept in our setting. For example, a mechanism might be credible in the traditional sense when the auctioneer is a single actor, but this property may not hold when the auctioneer consists of a network of agents. Similarly, if a system consists of a network of agents concentrated in one jurisdiction, the system is subject to the whims of a single regime, whereas a globally distributed system does not have the same risk. It should also be noted that different guarantees can be provided with different notions of credibility such that one failed assumption may only compromise a subset of properties. Naturally, designing a system which takes into account such a diverse range of preferences including preferences over the system itself seems difficult if not impossible. However, there are certainly practical designs which take some of these preferences into account. An auction with one slower channel that requires weaker security assumptions and another faster channel with weaker security guarantees is an example of a system which caters to preferences on different sides of a tradeoff.  **Latency** As the previous section hinted, the time delay a user experiences between their first action and execution of their intent certainly imposes a cost. This delay will be a function of the security assumptions (cryptographic computation and network communication impose time penalties), communication complexity and computational complexity of the auction. Apart from general user experience, this is also important because many blockchain applications are financial in nature and are sensitive to price movements. **Risk aversion** Between two outcomes with equal expected utility, users would prefer the one with lower variance in outcome. For example, an RFQ system is more desirable than one in which an order is submitted with the outcome only to be known afterwards. ### Other Properties **Truthfulness** This property Since we are creating a two-sided market, this notion has multiple interpretations. By the argument mentioned above, the only concern for truthful bidding on the buyer side of the market is insofar as it impacts the welfare of the sellers. A notion of truthfulness will need to be adapted for a setting in which users possible preferences extend past what can be expressed to a mechanism. Scoring rule/utility func bruv (probably not Scor rul bc it mae includ rep sco and rep sco is pat or repeted gam) ## Bidder Action Space Some settings see bidders’ action space limited to some single real number like a payment or price with bidders considered interchangeable. However, the complexity of the blockchain environment may necessitate a more complex consideration of bidders. To justify this case, let us understand execution risk: > **Execution Risk** Consider that, absent structural changes to the target blockchain, the OFA will be a separate mechanism from the blockchain where user intents are executed. As such, the OFA cannot control the full execution of the user intent. For example, one type of design might allocate the exclusive right to execute an intent to the bidder who commits to delivering the user the highest price. However, between auction conclusion and the next block, price movements may make this execution unprofitable for the winning bidder. It is up to the design of the OFA to minimise this execution risk as failed execution implies latency costs. It should be noted that there is an affect in which a higher bid in the OFA implies that a bidder has a narrower set of outcomes for execution which are profitable, meaning that there is a degree of adverse selection in choosing the most profitable bidder. ### Dimensionality of bids One response to the problem of execution risk would be to use a reputation system to distinguish between reliable bidders and to incentivise continued good behaviour. Another approach would be some way for bidders to commit to a strategy. For example, some designs could see bidders submit a commitment in the form of a blockchain transaction(s) that would dictate the execution path of the users intent. The auctioneer could then be sure that this is submitted to the blockchain for consideration in the next block. Unfortunately, since certain operations on a stateful blockchain may impact one another (like moving a price), such a design still cannot guarantee perfect execution. ### Sybil Bidders Since identities in the blockchain settings are cheap pseudonyms (it is easy to operate under multiple usernames), one must consider that a single agent may represent herself as multiple agents. Although some previous work focuses on the property of "sybil proofness" or "sybil resistance" that denotes a mechanism in which agents do not choose to represent themselves under more than one identity in equilibrium, we have a weaker requirement. The requirement for the system is that it provides its stated guarantees even when agents have access to cheap pseudonyms. Some auction formats have already been studied under this framework. For instance, the second price auction is known to be sybil proof (cite bruno & nikete) and combinatorial auctions have been studied in the presence of "false-name" bidders, which is the same concept. We know that no combinatorial auction is efficient in the presence of false-name bidders (Yokoo 2000). Of course, countermeasures like deposits or reputation systems can be put implemented, but these may introduce additional tradeoffs like high barriers to entry as discussed below. ### Collusion In the presence of coordination devices (blockchain), it would be unreasonable to assume that agents are unable to coordinate among themselves. Thus, an OFA must preserve its guarantees even in the presence of colluding agents. ### Bidder Utility Function Reasoning about bidder behaviour requires some notion of a utility function. It is difficult to reason about this in general, but it should be noted that at least some user intents, such as spot trades, would be common value. ## Seller action Space ### Expressiveness As mentioned before, the space of things that users may want to express preferences over (i.e. the form their intents may take) is practically boundless. An important dimension of auction design is how much of this space is expressible in the auction. For example, users may be able to express preferences over some smart contract, account balances, the state of multiple chains and the actions of other players. Currently on Ethereum users are able to express preferences over the order in which transactions are executed in a block. ### Programmable Privacy Additional dimensionality is introduced to the "items" in the auction once their informational structure is considered. Given the tools supplied by cryptography and distributed systems, complex notions of privacy are implementable in the OFA. A basic example is that one can run a single-item auction with full information about the item available to the bidders, but allow only the winning bidder to know the details of the auction. If the item being auctioned off is a large limit order in an illiquid market and the auction gives exclusive rights to execution, this allows the winning bidder to execute and arbitrage the transaction without informed competition and also trade with an edge in market. A basic implementation of the above would be to have bidders submit scripts which take items as input and give bids as output with outgoing traffic only allowed from the winning script. Doing this efficiently may require exposing *some* information to bidders upon which their scripts can be conditioned to ensure efficient execution. Finding the balance between privacy and efficiency is an interesting open research problem. Of course, these dynamics can be considered properties of the auction itself, but a useful framing is to consider the informational structure as a property of the order itself. This brings in the notion of programmable privacy which is the idea that a seller is able to specify arbitrary logic specifying the informational properties under which the order is to be auctioned off. The more complex the privacy parameters in the control of the seller, the closer the OFA is to the notion of programmable privacy. ### Sybil Sellers The problem of sybils is particularly interesting when considering the fact that the agent selling an item may be the very same entity bidding for that item. This problem is obvious in auction formats like a combinatorial auction in which a bidder can submit a 'dud' item to be sold. By bidding on the union of the set of desired items and the dud item, the bidder can place a higher bid than without the dud item since the payment they receive as seller of the item should subsidise the bid. This problem may be solved by an approximation of the Shapley value or a similar concept, but it is unclear if this is tractable in the presence of sybil bidders. ## The Mechanism While the above sections outline the nature of the agents and the objectives of the mechanism in question, little has yet been said about the design space for the mechanism itself, which is large. ### Allocation Rule Many allocation rules allocate items to bidders. One drawback of this approach is the introduced risk of execution failure. The fewer parties attempting to execute an order, the higher the risk, but one might expect an intuitive increase in "revenue". Alternative approaches include introducing additional dimensions to the allocation vectors and may be able to circumvent this problem. For example, the OFA could allocate every item to every bidder who is willing to commit to paying a percentage (chosen by the rule) of their final profit back to the user. Assuming the transactions are targeted at a blockchain that uses auctions for inclusion, one would expect the bidder that yields the seller the best outcome to be executed. The likelihood of an intent being executed is now a function of the percentage required to be paid to users. Of course, the feasibility of such an approach is yet to be tested.(link mev-share) ### Payment Rule (I know this section needs to be clearer). Many forms of intents can be viewed as valuable given that they allow certain state transitions on a blockchain's state machine. However, practical constraints mean that every intent allows for multiple possible state transitions. The state transition that is eventually chosen is a function of how the final block combines many user transactions, hence the realised value of a transaction can only be known after a block is constructed. As such, valuation of transaction execution has hitherto been a function of the state transition taken in the block. One approach to the payment rule is to fix payments before block execution happens. This approach has the benefit of simplicity, but means that the bidder must price in more risk and there is higher execution risk (as payments are fixed). Another approach is to do ex-post or interim payments. I.e. payments during or following block execution so that the value of intents is more clearly known. ### Tools The OFA designer has access to a broad set of tools. Most importantly, cryptography and malleability of related systems. **Cryptography** The OFA is a cryptoeconomic system. Unfortunately, understanding of the intricacies of both cryptography and economics is a tall order. A reasonable approach to reasoning about to simplifying this reasoning is to assume that all desired cryptographic primitives like functional, witness and homomorphic encryption are available as their functionality can be replicated with trusted execution environments (barring several caveats). **Malleability of the broader system** Fortunately some mechanisms surrounding the OFA can be changed to better integrate with a better design. Implicitly, this article has assumed that wallets may change the kind of messages that users may sign. Another powerful neighbouring mechanism that can be changed is the builder which aggregates user intents into a final output. An example of such a change is builders enforcing privacy guarantees (by running specific code within a TEE) in unison with the OFA such that programmable privacy guarantees can extend up until a block has been committed to. Naturally, such changes will need to be incentive compatible for the builder(s). ## Other Considerations ### Competing Systems The OFA being designed will not exist in isolation. Other systems playing similar roles will likely exist as well. The auction should not give up guarantees in the presence of such a competing system. ### Longevity Importantly, the guarantees provided by a certain auction design should hold over longer periods of time. A design should ideally not assume something like the presence of a competitive market, but engender a market structure which inevitably leads to an entrenched monopolist.