Everything you need to know about the new OFA based paradigm, protocol architecture, main order types, best products, tokenomics and a perspective assessment on the revenue model.
In a crypto world now completely detached from fundamentals and dominated by attention trading (a phenomenon that prompts market participants to shift liquidity from one mainstream trend to another, blowing up and down market capitalisations), , Rakki seeks to turn the spotlight back on quality because he believes that, at the end of the day, it is still the aspect on which to focus attention (at least in the long run).
What I write expresses just my personal point of view and does not represent financial advice. But sure, beat me at beer pong and I will tell you the next 100x.
The dex spot category is among the most evolved in DeFi because it has been around for a very long time (the first experiments date back to 2017), is a financial service as basic as it is vital, and has the potential to generate high profits (ask the Uniswap team for confirmation) and thus has always attracted a significant amount of VC funding. One of the few common elements of all successful spot dex projects from their inception to the current days has undoubtedly been the AMM infrastructure, declinated with different formulas and approaches over time...until recently. Let me introduce COW protocol and the cutting edge solutions developed by the team over the past few years to fully understand the project and more rationally evaluate a potential investment on the governance token ($COW).
Cow Protocol is a decentralized and permissionless meta-DEX aggregation infrastructure (or an aggregator of aggregators, if you prefer) that leverages the new concept of intent and a price finding mechanism based on batch auctions to offer extremely competitive prices, lowering both swap and gas costs and stronger protections to users against MEV risk.
Cowswap, on the other hand, is the first of Cow Protocol's trading interfaces, as well as undoubtedly the most famous because it is basically managed by the same team responsible for the backend architecture.
The new concepts mentioned may seem complex at first glance but will be examined in depth in order to clarify any doubts.
Cow's journey into the crypto world is intimately bound up with the birth of AMM-based spot dexes: in 2016 the team (at that time still a subsidiary of the Gnosis staff) was working on the implementation of a system for managing prediction markets outcomes based precisely on the x * y = k formula. This formula was later taken up by Buterin in his famous reddit post and then successfully implemented by Uniswap: thus, it can be said that the MM formula paternity belongs to them (i.e. to the Cow team).
Almost paradoxically, the Gnosis team quickly moved away from the AMM model because it was deemed inefficient and overly exposed to MEV risks. Gnosis initially pivoted to Dutch auctions to address MEV vulnerabilities in traditional AMMs but the implemented solution was unsuccessful because it struggled with the token diversity and slow trading speed on Ethereum.
To provide an effective solution to the problems faced with the previous model, the Gnosis team developed a new DEX paradigm based on batch auctions, leading to the creation of CoW Protocol in 2021. The new product exploits a delegated trading execution model and a batch auction system based on competition between qualified third-party entities (solvers)
Comparing auction models: dutch and batch systems
Let’s quickly examine how the 2 main auction models work to understand what prompted Cow Protocol to take an alternative approach to traditional AMM.
Dutch Auctions (Dutch auctions) in general are a type of auction in which the auctioneer sets an extremely high initial price that drops over time until one of the participants (or bidders) accepts it. When declined in the crypto sphere, however, dutch auctions take on peculiar connotations which are worth knowing (in a nutshell, because each project concretely modulates the process based on its own needs): first of all, the price of a given token usually starts from a high initial value (ceiling, ceiling) and gradually goes down by a fixed amount at regular intervals (e.g., $0.2 every 10 minutes).
Participants submit their bids specifying the number of tokens they wish to buy and the price they are willing to pay. As the auction price decreases, bids placed at a price higher than the current auction price will be accepted in the order in which they were received.
The auction ends when:
a) the current demand meets or exceeds the bid;
b) or the reserve price is reached (the so-called reserve price is the minimum value that the seller is willing to accept from the buyer). When the auction ends, bids above the final price are accepted while lower bids are canceled. All successful bidders must then pay the same final reserve price for each token.
The distribution/auction mechanism described above is extraordinarily fair because each participant buys tokens at the same price and everyone collectively contributes to its determination, but it:
a) is also centralized by nature;
b) does not support more than one asset per auction;
c) suffers from the problem of liquidity fragmentation (because the liquidity for each asset is spread across different locations, not aggregated);
d) is too slow relative to the needs of modern trading.
These are the main reasons that prompted the Gnosis team to move toward the batch auctions model.
Batch auctions are a trading mechanism where buy / sell orders are first collected and then aggregated over a certain period of time (batch period) at the end of which all the orders are executed simultaneously at the same uniform clearing price within the same transaction.
The described model allows more users to trade multiple assets within a single auction (thus solving one of the congenital drawbacks of Dutch auctions). Having multiple orders within a single batch even allows for peer-to-peer trades, which inherently guarantee better prices than any on-chain trading venue (because the p2p approach bypasses DeFi protocols and their associated swap fees).
Lastly, while Dutch auctions are based on a so-called price-decay bidding process (i.e., through which the asset being bid on undergoes precisely a price decay), batch auctions encourage solvers to find the best execution path for each trade, thus valuing execution efficiency rather than merely faster settlement.
The advantages of the batch model are clear:
Competition among solvers and MEV protection: just like the Dutch auctions, batch auctions are based on a delegated execution model whereby solvers compete in order to find the best prices for users and protect orders from potential MEV risks (and as we know, competition has always stimulated the market efficiency, regardless of the relevant field).
Higher efficiency, lower costs: batch auctions offer an additional level of efficiency compared to Dutch auctions, because they bundle multiple orders into a single transaction and thus manage not only to enable p2p trading solutions between orders (with significant cost savings, such as swap fees) but also to decrease overall gas costs.
Multiple trades per auction: unlike Dutch auctions, batch auctions are not limited to one asset per auction; this means that a single settlement can include multiple traders, each of whom trades a different asset.
Natural fit to $ETH: batch auctions are a natural fit for Ethereum because they reflect the same mechanism of transaction flow within blocks (which is in fact based on auctions), but at the dAPP level.
The batch model, like any other, is certainly not free of flaws or potential critical issues.
The first as well as the most evident of these is undoubtedly the excessive latency: while other trading modes settle orders instantaneously, batches must remain open for a certain period of time required to collect orders before executing them on-chain; However, this speed problem can be mitigated by running a batch on each Ethereum block so that auctions run at the same settlement speed as Mainnet blocks.
The second shortcoming concerns their lack of flexibility, especially when compared to AMM models.
I attach below a comparative table highlighting the pros and cons of the batch auction model versus AMM infrastructure.
A plunge into the depths of OFAs
Before going through all the specs related to Cow protocol, let’s first take a closer look at the category to which the Cow trading model belongs: the Order Flow Auctions.
As we have seen previously, Cow protocol is a complex delegated execution trading infrastructure that exploits a batch auctions based model, a large network of bonded solvers and the new intent order concept to offer extremely competitive prices and the lowest value leakage caused by MEV operations.
The paradigm developed by Cow represents a specific declination of the broader category of OFAs, Order Flow Auctions, a primitive that needs to be framed immediately to fully appreciate the team's contribution to the broader topic.
OFAs reflect on-chain the same mechanics of PFOF (Payment For Order Flow), a common practice in the world of tradFi in which brokerage firms receive compensation from market makers for routing retail orders to them for execution. This system allows brokerages (like Robinhood) to offer zero trading fees to retail investors.
The interest in this new trading architecture is demonstrated both by the percentage of volume represented by solvers auctions across all trading interfaces and by the players involved (Paradigm & Flasbots, Uniswap, Cow and 1Inch to name the most famous).
Order Flow Auctions (OFAs) are a competitive bidding system with a flexible design which relies on third parties, ensuring highly accurate pricing and effective Maximal Extractable Value (MEV) risk avoidance measures.
OFA can also be defined as an optimization mechanism for transactions settlement designed to capture the maximum possible value from each transaction and mitigate the negative externalities of MEV, which is implementable on 3 different stack levels (and provides a wide range of customization opportunities at each):
dapp level;
builder level;
validator level.
Dapp level is the first stage in which an OFA can take place as well as the simplest and most traditional form of interaction with the protocol; the most famous example of an OFA at the dapp level is Cowswap.
Builder level Is the second phase of potential implementation offering the ability to setup a private mempool in order to further limit the value leakage from each transaction; it is an implementation phase focusing on specific goals (which in the case of dapps may be to build up an application-specific OFA and in the case of the builder may be to return as much value as possible to users).
Validator level represents the third and final implementation layer; it is more generic than the previous ones, targets validators, and is aimed merely at extracting the maximum possible value from the block for each transaction.
OFA is also a very versatile mechanism in terms of decisions that can be made at the design stage, and devs should be aware of the range of options available if they want to optimally achieve a specific outcome (and thus to deliver a specific service to their users). In the following section we will take a quick look at the different types of design decisions.
On-chain vs Off-chain Elements
On-chain: Offers decentralization, transparency and security but lowers performance;
Off-chain: Increases computational complexity and efficiency but introduces centralization risks;
Example: Uniswap X uses off-chain RFQ for low latency and precision but it relies on a centralized set of market makers. Suave instead is fully on-chain, avoiding centralization but potentially less efficient.
Open or closed/restricted participation
More open permissionless systems promote both decentralization and greater equity of access, but cannot guarantee high standards of efficiency (because carrying out this activity requires a high level of professional expertise in market making activities, optimal order management in inventories and the definition of algorithms for optimizing trade execution paths across multiple liquidity sources, etc, that amateur entities can hardly meet).
More permissioned systemsprovide better performance (lower latency, improved price discovery, increased computational complexity) because they limit access to a select number of qualified entities, i.e., market makers, but increase the overall centralization level.
Order types
The choice on the order type is crucial because it defines upstream the degree of flexibility of the overall auction system:
orders can be structured as intents, which are fully composable and encode only the input (such as the source asset and the related amount), while leaving wide discretion in the output definition (i.e. the settlement details), or they can be structured as transactions, which are instead constrained in the settlement specs (like asset quantities and counterparty addresses).
Settlement rights
On-chain settlement can be:
public (anyone can settle orders if they win the auction);
public permitted (i.e. limited to those who meet certain requirements);
private (only the auctioneer decides who has the right to execute the order settlement).
Auction goals
The purpose of the auction must be defined because it leads the bidders’ behaviour (and thus their optimisation algorithms) and steers the entire process towards a specific outcome.
The auction could be finalized:
- to minimize trading fees;
- to maximize the value extracted from transactions (MEV);
- to minimize the spread (in this way, the depth of liquidity is valued).
Information goals
The amount of data revealed on intent/transaction and the time at which they are revealed affect both front running likelihood and optimisation capabilities (for e.g. a large amount of information promptly shared increases front running risks but also optimisation strategies).
There are obviously other important choices in terms of design that must be made, such as:
the function for selecting winning bids (the best price, the higher extractable value from the block, etc);
the approach to the bidding process (which can be individual and thus occur for each individual transaction, or it can be aggregated and occur in batches for a set of orders);
the auction access gateway (e.g. we can have OFAs accessible through a private RPC, such as Flashbots Protect and Cow’s MEV Blocker, or through API calls, such as DFlow and Propeller Heads, or integrated directly on a dex interface, such as Cowswap, Uniswap X and 1Inch Fusion);
many others.
The list is not exhaustive but already underlines how high the level of customisation of the analyzed model is.
Let's see now what types of OFAs exist. The main distinction on the topic is that between generalized and specialized OFAs. The former are structured to handle any arbitrary transaction and not just the mere swap function; they can also be defined as flexible frameworks designed to meet any need (e.g. Suave, a platform for the creation of customisable auction systems based on the desired outcome). The latter are instead optimized in all their parameters for the swap function (for instance, auction based dexes such as Uniswap X and Cowswap).
Within the specialized OFAs category, we can then identify at least three other types with a strong PMF (Product Market Fit):
RFQ (Request For Quotes) auction is a type of OFA optimized for price discovery because it solicits multiple quotes from many participants and only awards the winner (this encourages competition, which benefits the user who wishes to buy/sell). Bidders need professional skillset to pool liquidity from multiple sources and provide the best quote price: in other words they must be market makers or other specialized entities
How does it work?
Stage 1. User Request: The user creates a request for quote (RFQ) detailing the trade they want to execute, including the assets to be traded, the related amount, the destination asset and even optional parameters (such as timing).
Stage 2. Broadcast: The RFQ is sent to a group of liquidity providers who are able to handle that specific trade.
Stage 3. Provider Analysis: Each liquidity provider reviews the RFQ, checks their current assets and market conditions, and then offers a binding quote with their prices and fees.
Stage 4. Comparison: The user reviews all the received quotes, comparing them based on price, slippage, fees, timing, and other terms.
Stage 5. Selection: The user picks the quote that best meets their needs and confirms acceptance with the chosen liquidity provider.
Stage 6. Execution: The chosen liquidity provider carries out the trade according to the details in the accepted quote.
Stage 7. Settlement: The trade is settled, with the user receiving the swapped assets and the liquidity provider making a profit from the bid-ask spread.
Stage 8. Recording: Metrics such as the number of responses, quote spreads, and the winning price are recorded to improve future RFQs and provider selections.
Frequent Batch Auction is a type of OFA optimized for both price discovery and trade execution that aggregate and settle multiple transactions in batches at regular intervals rather than executing each trade individually and immediately.
How does it work?
Transaction Collection: User transactions are collected over a short, predetermined time window (e.g., 30-60 seconds) and then held in a batch, creating a kind of "dark pool" where details are not immediately visible to all participants
Bidding: Bidders (market makers or liquidity providers) first analyze the transactions batch and then respond with optimized strategies for executing the entire batch efficiently, potentially identifying peer to peer matching opportunities (even multi dimensional or trilateral matching).
Execution: After receiving bids, the auctioneer selects the winning strategy and executes the batch of transactions on-chain according to the pre-established set of rules for the type of OFA. All trades within the batch receive the same pricing and execution based auction results (but as we have seen, specific design choices can modify the selection criteria for the winning bid).
Block Space Aggregator Auction, as the name suggests, is a type of OFA optimized for maximizing block space utilization through the bundling of multiple user transactions in efficient batches. This approach seeks to promote the efficient use of block space and shares any profits generated with users who have submitted transactions (unlike traditional MEV extraction, which retains profits).
How does it work?
Collection: Transactions from various users are gathered over a set time period and combined into a single batch.
Bidding: Bidders propose optimized orderings and strategies for executing the batch to maximize available block space.
Optimization: Transactions are reordered to prevent redundant data propagation.
Execution: The chosen strategy is applied, executing the batch in a manner that optimizes block space usage, enabling more transactions per block and reducing fees.
