Rohan Shrothrium , Samuel Laferriere Introduction Chains like Sui and Aptos use multi-proposer based consensus algorithms that leverage Narwhal, a relatively novel total order broadcast DAG-structured mempool mechanisms. At the cost of slightly extra latency, their unique way of allowing every validator to propose partial blocks simultaneously is a breakthrough addressing one of blockchain's most persistent challenges: achieving high throughput. However, the questions of transaction ordering and MEV extraction on these blockchains remains criminally understudied and to our knowledge still a largely unresolved issue. As the Sui and Aptos TVL keep increasing these chains' sequencing algorithms will no-doubt come to the forefront of MEV-related interest, just like happened on ethereum, avalanche, solana, and others. In this article, we aim to provide the readers with a basic introduction to the Narwhal Mempool, the existing landscape of MEV on chains that use Narwhal-DAG-based consensus algorithms, and analyze how the ordering of transactions within the DAG impacts MEV. In this article we describe the parts of Narwhal/Bullshark that are relevant to MEV, but defer to the original paper for further details and full explanation of the protocol. Lexicon

Introduction Order manipulation attacks such as frontrunning and sandwiching have become an increasing concern in blockchain applications. Enforcing strict transaction ordering in a block is one of the many proposals for reducing MEV in blockchains. The paper Breaking the Chains of Rationality: Understanding the Limitations to and Obtaining Order Policy Enforcement explores the impossibility conditions for Order Policy Enforcement(OPE) under the assumption of rational actors. This article introduces a novel protocol design integrating a DAG-based consensus mechanism and Merkle Root commitments to circumvent this challenge. The Impossibility of OPEs The paper suggests that rational actors in a decentralized system can manipulate transaction order to their advantage. This typically manifests as front-running, where an actor places their transaction ahead of a seen pending transaction to profit from market impact. Implementation of OPE protocols like Themis works under the strong requirements of byzantine actors($f < n/4$ for Themis) which is rarely the case in the real world. The paper argues that an attacking set of rational nodes $A$ can collude and manipulate the transaction order such that they can extract maximal value in each block. The argument is based on the fact that you can't design a protocol that incentivizes actors in $A$ to incriminate colluding actors and subject them to slashing. Using a TEE ensures all proof of collusion is available only to nodes that are part of $A$. Proposed Protocol Design The following protocol incorporates several elements to mitigate the fair ordering challenge:

Introduction Order manipulation attacks such as frontrunning and sandwiching have become an increasing concern in blockchain applications. Enforcing strict transaction ordering in a block is one of the many proposals for reducing MEV in blockchains. The paper Breaking the Chains of Rationality: Understanding the Limitations to and Obtaining Order Policy Enforcement explores the impossibility conditions for Order Policy Enforcement under the assumption of rational actors. The paper also proposes AnimaguSwap, a DEX that uses rationally binding transactions to enforce the stakers and flippers to have conflicting interests by constructing a game with Pareto efficient outcomes in an inefficient Nash equilibrium. It further goes on to formally prove how this would not work with binding side contracts for stakers(exactly why governments enforce anti-collusion laws). This article dives deeper into the flipper game, how it is constructed, and why I believe this is not a strong enough rational binding for the flipper to not collude. This article uses a game theoretical approach and analyzes how a rational flipper would behave under different strategies employed by a set of colluding stakers. Game Mechanics The Flipper Game involves a set of $N$ stakers, with one staker elected as the flipper in each round. For simplicity, let us assume that this leader is elected in a round-robin fashion(can be stake-weighted random as well) and all the stakers have equal weights. Every epoch has $N$ rounds such that each staker has been elected as the flipper at least once. Let us understand the terminologies involved in the mechanism before we go ahead: Stakers: $s_{i} \in {s_{1}, s_{2}, .., s_{N}}$. Transaction: $tx$

Introduction Current shared sequencer solutions like Espresso use a pipelined BFT algorithm(HotShot) for achieving consensus among the several sequencer nodes. There are significant challenges in MEV (Maximal Extractable Value) extraction in blockchain systems using pipelined BFT algorithms to achieve consensus. This detailed analysis explores the nuances of these challenges and proposes innovative solutions to ensure liveness of the network. Problem Statement Understanding Pipelined BFT Consensus Algorithms Mechanism of Pipelined BFT: In pipelined BFT consensus algorithms, each block(n^th block) contains a Quorum Certificate (QC) or a Timeout Certificate (TC) for the previous block((n-1)^th block). The QC represents a majority of yes votes, while the TC indicates a majority of no or timeout votes. Alongside this, the block includes a list of transactions proposed by the current leader, Alice, for the n^th time slot. Roles in Block Propagation: The (n+1)^th block proposer, Bob, is responsible for gathering the QC/TC for the transactions proposed by Alice. This sequential responsibility is crucial for maintaining the integrity and order of transactions.

Introduction The DeFi ecosystem, rich in innovation, has birthed diverse trading mechanisms, each with its unique set of advantages and challenges. Central to these mechanisms are the Central Limit Order Books (CLOBs), known for their capacity to enable precise price discovery and offer traders unparalleled control. Historically, the transition of CLOBs to on-chain platforms was riddled with challenges. The inherent throughput limitations of traditional L1 and L2 solutions curbed the swift operations CLOBs demanded, often rendering them unprofitable for market makers. Additionally, the transparent nature of on-chain operations opened the door for validators to engage in front-running, exploiting the spread by manipulating transaction sequences. Furthermore, the intricate operations intrinsic to CLOBs could lead to skyrocketing gas costs, especially during network congestion periods. The emergence of advanced scaling solutions and faster EVMs is reshaping the landscape, presenting fresh opportunities and challenges for on-chain CLOB implementations. This article introduces an optimised on-chain CLOB tackling all these challenges. Algorithm Overview Orders are stored in a hash map and price ordering is not done on-chain. Sorted list price points/order IDs are sent as calldata while placing market orders which removes the scope for MEVs by front-running transactions. We rely on the fact that market orders want the best price and hence will send the sorted list of price points/order IDs. Only time priority is verified by the smart contract on-chain as there is no incentive for market orders to sort order IDs in this order. We use a sliding window mechanism to enforce time priority. Before we dive into the algorithm, let us understand some basic structures used for storing limit orders. Buy and sell limit orders are stored in separate hashmaps on-chain. The order is referenced by an orderId and stores the following data: