MEV Suppression and Fair Transaction Ordering: SUAVE vs. Anoma vs. Skip vs. Flashbots v2

Maximal Extractable Value (MEV) refers to the profit a blockchain “insider” (miner/validator or other privileged actor) can gain by arbitrarily reordering, including, or excluding transactions in a block. Unchecked MEV extraction can lead to unfair transaction ordering, high fees (from priority gas auctions), and centralization of power in block production. A number of protocols have emerged to suppress harmful MEV or enforce fair ordering of transactions. This report compares four prominent approaches: Flashbots v2 (the post-Merge Flashbots MEV-Boost system for Ethereum), SUAVE (Flashbots’ upcoming Single Unifying Auction for Value Expression), Anoma (an intent-centric architecture reimagining how transactions are matched and ordered), and Skip Protocol (a Cosmos-based toolkit for sovereign in-protocol MEV management). We examine each in terms of their transaction queuing/ordering algorithms, MEV mitigation or extraction mechanisms, incentive models, compliance and neutrality features, technical architecture (consensus and cryptography), and development progress. Structured summaries and a comparison table are provided to highlight their strengths and trade-offs in pursuing fairness and reducing the negative externalities of MEV.

Flashbots v2 (MEV-Boost & BuilderNet on Ethereum)

Flashbots v2 denotes the current Flashbots ecosystem on Ethereum post-Proof-of-Stake, centered around MEV-Boost and recent initiatives like BuilderNet. Flashbots v2 builds on the proposer/builder separation (PBS) paradigm to open up block construction to a competitive market of builders while protecting Ethereum users from public mempool MEV attacks.

• Transaction Ordering (Queuing & Algorithm): Flashbots MEV-Boost introduces an off-chain block-building marketplace. Validators (proposers) outsource block construction to specialized builders via a relay, instead of locally ordering transactions. Multiple builders compete to provide the highest-paying block, and the validator blindly signs the header of the top bid block (a PBS approach). This design effectively replaces the public mempool’s first-come, first-served ordering with a sealed-bid auction for entire blocks. Builders determine transaction ordering internally to maximize total payoffs (including MEV opportunities), typically preferring bundles with profitable arbitrages or liquidations at the top of the block. By using MEV-Boost, Ethereum avoided the chaotic priority gas auctions (PGAs) that previously determined ordering; instead of users and bots bidding via gas fees in real-time (driving up congestion), MEV-Boost centralizes ordering per block to the most competitive builder. Transaction queues are thus privately managed by builders, who can see incoming bundles or transactions and arrange them for optimal profit. One drawback is that this profit-driven ordering does not inherently enforce “fairness” for users – e.g. builders may still include toxic orderflows like sandwich attacks if profitable – but it does optimize efficiency by extracting MEV through a controlled auction rather than ad-hoc gas wars. Recent developments have aimed to make ordering more neutral: for example, Flashbots’ new BuilderNet (launched late 2024) allows multiple collaborating builders to share orderflow and construct blocks collectively in a Trusted Execution Environment, introducing verifiable ordering rules to improve fairness. This moves block ordering away from a single centralized builder towards a decentralized block-building network with rules that can be audited for neutrality.

• MEV Suppression vs. Extraction Mechanisms: Flashbots v2 primarily facilitates MEV extraction in a more benign form rather than eliminating it. The original Flashbots (v1) system in 2021 allowed searchers to send bundles (preferred transaction sets) directly to miners, which suppressed harmful externalities (no public frontrunning, no failed transactions due to racing) while still extracting MEV. In the MEV-Boost era, MEV is extracted by builders bundling profitable transactions, but negative-sum competition is reduced: searchers no longer spam the mempool with competing transactions and exorbitant gas fees, which mitigates network congestion and excessive fees for users. Flashbots v2 also provides MEV mitigation tools for users: for example, Flashbots Protect RPC allows users to submit transactions privately to a relay, preventing public mempool frontrunning (no one can see or reorder the tx before inclusion). Another initiative, MEV-Share, lets users share just enough info about their transactions to attract MEV bids while capturing a portion of the value for themselves. However, Flashbots v2 does not “prevent” MEV like sandwiches or arbitrage – it channels these activities through an efficient auction that arguably democratizes who can extract the MEV. Recently, BuilderNet’s design has an explicit goal of “neutralizing negative-sum orderflow games” and sharing MEV back with the community via on-chain refund rules. BuilderNet computes refunds paid to transaction orderflow providers (like wallets or DApps) proportional to the MEV their transactions generated, redistributing value that would otherwise be pure profit for builders. In summary, Flashbots v2 maximizes MEV extraction efficiency (ensuring nearly all extractable value in a block is actually captured) while introducing measures to curb the worst externalities and return some value to users. It stops short of enforcing fair ordering (transactions are still ordered by builder profit), but through private submission, multi-party building, and refunds, it suppresses the negative user harm (like front-run slippage and censorship effects) as much as possible within the auction model.

• Economic Incentive Structure: Flashbots v2 aligns incentives among validators, builders, and searchers through the PBS auction. Validators benefit by outsourcing block production – they simply accept the highest bid and get paid the bid amount (in addition to consensus rewards), which dramatically increased the share of MEV going to validators compared to the era where miners did not have such auctions. Builders are incentivized to out-compete each other by finding the most profitable ordering of transactions (often incorporating searcher strategies), and they keep any MEV profit left after paying the validator’s bid. In practice, competition forces builders to pay most of the MEV to validators (often >90% of profit), keeping only a thin margin. Searchers (now interacting with builders via bundles or direct transactions) still earn by discovering MEV opportunities (arbitrage, liquidation, etc.), but they must bid away most of their profit to win inclusion – effectively, searcher profits get transferred to validators via builder bids. This competitive equilibrium maximizes total network revenue (benefiting validators/stakers) but squeezes individual searcher margins. Flashbots v2 thus discourages exclusive deals: any searcher or builder with a private MEV strategy is incentivized to bid it through the open relay to avoid being undercut, leading to a more open market. The introduction of BuilderNet adds an incentive for orderflow originators (like DEXs or wallets) – by giving them refunds for the MEV their transactions create, it encourages users and apps to send orderflow to the BuilderNet ecosystem. This mechanism aligns users with the system: rather than being adversarial (users vs. MEV extractors), users share in the MEV, so they are more willing to participate in the auction fairly. Overall, Flashbots v2’s economics favor collaboration over competition in block building: validators get maximal revenue risk-free, builders compete on execution quality, and searchers innovate to find MEV but relinquish most profits to win bids, while users gain protection and possibly rebates.

• Compliance and Censorship Resistance: Regulatory compliance became a contentious issue for Flashbots after the Ethereum Merge. The default Flashbots relay initially implemented OFAC sanctions compliance (censoring certain transactions like Tornado Cash) – leading to ~~80% of Ethereum blocks in late 2022 being “OFAC-compliant” and raising centralization/censorship concerns in the community. Flashbots v2 addressed this by fostering a multi-relay ecosystem where validators can choose non-censoring relays (e.g. UltraSound, Agnostic) or even run their own. Flashbots open-sourced its relay code in mid-2022 to encourage global relay competition and transparency. Additionally, MEV-Boost v1.4 introduced features like a minimum bid setting so proposers could reject low bids from censoring builders and fall back to local blocks, trading some profit for inclusion of all transactions. This feature explicitly gave validators a way to improve Ethereum’s censorship-resistance at a small cost. By late 2024, Flashbots took a further step by deprecating its own centralized builder in favor of BuilderNet – a collaborative network aimed to be “uncensorable and neutral”. BuilderNet uses TEEs (Intel SGX) to keep transaction orderflow encrypted and verifiably commits to an ordering rule, which can help prevent individual builders from censoring specific transactions. With multiple participants jointly building blocks inside secure enclaves, no single party can easily exclude a transaction without detection. In short, Flashbots v2 has evolved from a single (and initially censoring) relay to a more decentralized infrastructure with open participation and explicit neutrality goals. Compliance is left to individual relays/builders policies (and validators can choose), rather than enforced by the protocol. The trajectory is toward credible neutrality: eliminating any Flashbots-controlled chokepoints that could be pressured by regulators. Flashbots has publicly committed to removing itself as a central operator and to decentralize all aspects of the MEV supply chain in the long run.

• Technical Architecture & Cryptography: Flashbots v2 operates off-chain and in-protocol hybrid. The core auction (MEV-Boost) happens off-chain via the builder and relay network, but it plugs directly into Ethereum’s consensus: validators run a sidecar client (mev-boost) that interfaces with relays using the standardized Builder API. Consensus-wise, Ethereum still uses standard PoS (Casper/Hotstuff) – MEV-Boost doesn’t alter L1 consensus rules; it only changes who assembles the block. Initially, the Flashbots auction required trusting the relay and builder not to steal transactions or censor – there were no cryptographic guarantees (the system relied on the economic incentive that builders must deliver a valid payload matching their bid or they lose the slot). Over time, Flashbots v2 has integrated more security technology. The introduction of Trusted Execution Environments (TEE) via BuilderNet is a notable architectural shift: builders run inside SGX enclaves so that even the builder operator cannot see the raw transaction orderflow (preventing them from leaking or frontrunning it). These enclaves collectively follow a protocol to produce blocks, which can enable verifiable fairness (e.g. proving that transactions were ordered by a committed rule or that no unauthorized entity saw them before inclusion). While SGX is used (a hardware-based approach), Flashbots research is also exploring pure cryptographic primitives – e.g. threshold encryption for mempool privacy and secure multi-party computation – to eventually replace or complement TEEs and further reduce trust. Flashbots v2’s software stack includes custom clients like MEV-geth (now obsolete) and Rust-based builders (e.g. rbuilder), and it adheres to Ethereum’s builder-specs for interoperability. In summary, the architecture is modular: a network of relays, builders, and now enclaves, sitting between users and Ethereum proposers. It prioritizes performance (fast bidding, block delivery) and is gradually adding cryptographic assurances of privacy and fair ordering. No new consensus algorithm is introduced; instead Flashbots v2 works alongside Ethereum’s consensus, evolving the block production pipeline rather than the consensus rules.

• Development Roadmap & Milestones: Flashbots has progressed through iterative phases. Flashbots v1 (2020–2021) involved the launch of MEV-geth and the first off-chain bundle auctions with miners. By mid-2021 over 80% of Ethereum’s hashrate was running Flashbots’ MEV-geth, confirming the approach’s adoption. Flashbots v2 (2022) was conceived in advance of The Merge: in November 2021 Flashbots published the MEV-Boost architecture for PoS Ethereum. After Ethereum switched to PoS (Sept 15, 2022), MEV-Boost was activated within days and rapidly reached majority uptake by validators. Subsequent milestones included open-sourcing the relay (Aug 2022) and Flashbots’ internal block builder (Nov 2022) to spur competition. In late 2022, Flashbots also added features focusing on censorship-resistance and resilience (e.g. min-bid for proposers) and wrote about the “Cost of Resilience” to encourage validators to sometimes prefer inclusion over profit. Throughout 2023, improving builder decentralization became a key focus: Flashbots released “rbuilder” (a high-performance Rust builder) in July 2024 as a reference implementation to lower the barrier for new builders. Finally, in late 2024, Flashbots launched BuilderNet (alpha) in collaboration with partners (Beaverbuild, Nethermind). By December 2024, Flashbots shut down its centralized builder and migrated all orderflow to BuilderNet – a significant step towards decentralization. In early 2025, BuilderNet v1.2 was released with security and onboarding improvements (including reproducible enclave builds). These milestones mark Flashbots’ transition from an expedient centralized solution to a more open, community-run protocol. Looking forward, Flashbots is converging with its next-generation vision (SUAVE) to fully decentralize the block building layer and incorporate advanced privacy tech. Many lessons from Flashbots v2 (e.g. the need for neutrality, multi-chain scope, and user-inclusion of MEV rewards) directly inform the SUAVE roadmap.

SUAVE (Flashbots’ Single Unifying Auction for Value Expression)

SUAVE is Flashbots’ ambitious next-step protocol designed as a decentralized, cross-domain MEV marketplace and fair transaction sequencing layer. It aims to unbundle mempools and block building from individual blockchains and provide a unified platform where users express preferences, a decentralized network executes transactions optimally, and block builders produce blocks across many chains in a credibly neutral way. In short, SUAVE seeks to maximize total value extraction while returning value to users and preserving blockchain decentralization. Flashbots introduced SUAVE in late 2022 as “the future of MEV” and has been developing it in the open since.

• Queuing and Transaction Ordering: From a high level, SUAVE functions as an independent blockchain network that other chains can use as a plug-and-play mempool and block builder. Rather than transactions being queued in each chain’s mempool and ordered by local miners or validators, users can send their transactions (or more generally, preferences) into the SUAVE network’s mempool. SUAVE’s mempool then serves as a global auction pool of preferences from all participating chains. Ordering of transactions is determined through this auction and subsequent execution optimization. Specifically, SUAVE introduces a concept of preferences: a user’s submission isn’t just a raw transaction for one chain, but can encode a goal or conditional trade (possibly spanning multiple chains) and an associated bid the user is willing to pay for fulfillment. The ordering/queuing algorithm in SUAVE has multiple stages: First, users post their preferences to the SUAVE mempool (the “Universal Preference Environment”), which aggregates all orders privately and globally. Next, specialized nodes called executors (analogous to searchers/solvers) monitor this mempool and compete in an Optimal Execution Market to fulfill these preferences. They effectively “queue” transactions by finding matches or optimal execution ordering for them. Finally, SUAVE produces block outputs for each connected chain via a Decentralized Block Building layer: many builders (or SUAVE executors acting as builders) collaborate to construct blocks using the (now optimized) transaction order derived from user preferences. In practical terms, SUAVE’s ordering is flexible and user-driven: a user can specify conditions like “execute my trade only if price < X” or even express an abstract intent (“swap token A for B at the best rate within 1 minute”) instead of a strict transaction. The system queues these intents until an executor finds an optimal ordering or match (possibly batching with others). Because SUAVE is blockchain-agnostic, it can coordinate ordering across chains (preventing scenarios where cross-chain arbitrages are missed due to uncoordinated separate mempools). In essence, SUAVE implements a global MEV auction: all participants share one sequencing layer, which orders transactions based on aggregated preferences and bids rather than simple time or gas price. This has the effect of leveling the playing field – all orderflow goes through one transparent queue (albeit encrypted for privacy, as discussed below) instead of exclusive deals or private mempools. SUAVE’s ordering algorithm is still being refined, but it will likely involve privacy-preserving batch auctions and matching algorithms so that “fair” outcomes (like maximum total surplus or user-optimal prices) can be achieved rather than pure first-come-first-served. Notably, SUAVE intends to prevent any single actor from manipulating ordering: it is Ethereum-native and MEV-aware, with a privacy-first encrypted mempool that protects against any central points of control. In summary, SUAVE’s queue is a unified orderflow pool where ordering is determined by a combination of user bids, executor strategy, and (eventually) cryptographic fairness constraints, rather than by block proposers racing for priority.

• MEV Suppression/Extraction Mechanisms: SUAVE’s philosophy is that MEV can be harnessed for users’ benefit and for network security if done in a cooperative, decentralized manner. Instead of either ignoring MEV or letting it concentrate in a few hands, SUAVE explicitly surfaces MEV opportunities and returns the value to those who create it (users) as much as possible. The primary mechanism is the orderflow auction: whenever a user’s transaction (preference) has MEV – for example, it could be backrun for profit – SUAVE will conduct an auction among executors (searchers) for the right to execute that MEV opportunity. Searchers (executors) bid by promising a portion of the profit back to the user as a payment (this is the user’s “bid” field in their preference, which goes to whoever fulfills it). The result is competitive MEV extraction that pushes revenue to the user rather than the extractor. For instance, if a user’s large DEX trade creates a $100 arbitrage opportunity, searchers on SUAVE might bid the profit down by offering, say, $90 back to the user as a rebate, keeping only $10. This suppresses the negative aspects of MEV like user value extraction, and turns MEV into a user benefit (users effectively get price improvement or rebates). SUAVE’s design also suppresses front-running and other malicious MEV: transactions in the SUAVE mempool can be kept encrypted until a block is being built (using SGX enclaves initially, moving toward threshold cryptography). This means no external actor can see pending transactions to frontrun them; only when enough transactions are collected and a block is finalized are they decrypted and executed, similar in spirit to batch auctions or encrypted mempools that remove the time-priority advantage of bots. Additionally, because executors optimize execution across many preferences, SUAVE can eliminate inefficient competition (like two bots fighting over the same arbitrage by spamming). Instead, SUAVE selects the best executor through the auction and that executor performs the trade once, with the outcome benefiting the user and the network. SUAVE thus acts as a MEV aggregator and “fairy godmother”: it doesn’t eliminate MEV (the profitable opportunities are still taken), but those opportunities are realized under transparent rules and with proceeds largely distributed to users and validators (and not wasted on gas fees or latency wars). By unifying mempools, SUAVE also addresses cross-domain MEV in a user-friendly way – e.g. an arbitrage between Uniswap on Ethereum and a DEX on Arbitrum could be captured by a SUAVE executor and a portion paid to the users on both sides, rather than being missed or requiring a centralized arbitrageur. Importantly, SUAVE suppresses the centralizing forces of MEV: exclusive orderflow deals (where private entities capture MEV) become unnecessary if everyone is using the common auction. SUAVE’s ultimate vision is to reduce harmful MEV extraction (like sandwich attacks causing slippage) by either making them unprofitable or refunding the slippage, and to use “good MEV” (arbitrage, liquidations) to strengthen networks (through revenue sharing and optimal execution). In Flashbots’ own words, SUAVE’s goal is to ensure “users transact with the best execution and minimum fees” while “validators get maximum revenue” – i.e. any MEV present is extracted in the most user-aligned way.

• Economic Incentive Structure: SUAVE introduces new roles and incentive flows in the MEV supply chain. The main participants are users, executors, block builders/validators, and the SUAVE network operators (validators of the SUAVE chain). Users set a bid (payment) in their preference, which will be paid out if their conditions are met. This bid is the carrot for executors: an executor who fulfills the user’s intent (e.g. backruns their trade to get them a better price) can claim the bid as a reward. Users are therefore directly paying for execution quality, rather like posting a bounty. Executors (Searchers) are motivated to pick up user preferences from the SUAVE mempool and optimize them because they earn the user’s bid plus any extra arbitrage profit inherent in the transaction. Executors will compete to offer the best outcome to the user because the user can set their bid in a way that they only pay if the executor actually achieves the desired result (the bid can be conditional on on-chain outcomes via oracles). For example, a user might say “I’ll pay 0.5 ETH to whoever executes this transaction such that I get at least X output; if not, no payment.” This aligns executor incentives with user success. SUAVE Validators/Builders: The SUAVE chain itself will likely be a Proof-of-Stake network (design TBD), so validators (who produce blocks on SUAVE) earn transaction fees on SUAVE (which come from users posting bids and other operations). Since SUAVE is an EVM-compatible chain, there may also be a native token or gas fee system for those transactions. These validators also play a role in sequencing cross-domain blocks; however, final block inclusion on each L1 is still done by that L1’s validator. In many cases, SUAVE will produce a partial or full block template that an Ethereum or other chain proposer can adopt. That builder might pay SUAVE (or SUAVE’s executors) some portion of the MEV. Flashbots has mentioned that SUAVE validators are incentivized by normal network fees, while executors are incentivized by bids. Value Distribution: SUAVE’s approach tends to push value to the edges: users capture value (through better prices or direct refunds), and validators capture value (through increased fees/bids). In theory, if SUAVE fulfills its mission, most MEV will be either returned to users or used to compensate validators for securing the network, rather than concentrating with searchers. Flashbots itself has indicated it does not plan to rent-seek from SUAVE and will not take a cut beyond what’s needed to bootstrap – they want to design the marketplace, not monopolize it. Another incentive consideration is cross-chain builders: SUAVE allows block builders to access cross-domain MEV, which means a builder on one chain can earn additional fees by including transactions that complete arbitrage with another chain. This encourages builders/validators of different chains to all participate in SUAVE, because opting out means missing revenue. In essence, SUAVE’s economic design tries to align all participants to join the common auction: users because they get better execution (and maybe MEV rebates), validators because they get maximum revenue, and searchers because that’s where the orderflow is aggregated. By concentrating orderflow, SUAVE also gains an information advantage over any isolated actor (all preferences in one place), which economically pressures everyone to cooperate within SUAVE rather than break away. In summary, SUAVE’s incentives promote a virtuous cycle: more orderflow → better combined MEV opportunities → higher bids to users/validators → more orderflow. This stands in contrast to the zero-sum competition and exclusive deals of the past, aiming instead for “coopetition” where MEV is a shared value to grow and distribute.

• Compliance and Regulatory Considerations: SUAVE is being built with credible neutrality and censorship-resistance as core tenets. By design, SUAVE removes central intermediaries – there is no single mempool or single builder to attack or regulate. Transactions (preferences) in SUAVE can be fully encrypted and private until they are executed, using secure enclaves and eventually cryptographic techniques. This means that censorship at the transaction content level is impractical, since validators/builders cannot even read the transaction details before finalizing the order. SUAVE essentially forces a “don’t trust, verify” approach: participants don’t need to trust one entity not to censor, because the system architecture itself (decentralized network + encryption) ensures everyone’s preferences are included fairly. Moreover, SUAVE is intended to be an open, permissionless network – Flashbots explicitly invites all parties (users, searchers, wallets, other blockchains) to participate. There is no KYC or permission gating in its design. This could raise questions with regulators (e.g. the protocol could facilitate MEV extraction on sanctioned transactions), but because SUAVE is just a decentralized platform, enforcement would be difficult and analogous to trying to regulate a blockchain’s mempool. SUAVE’s focus on privacy (through SGX and later cryptography) also protects user data and orderflow from unwanted monitoring, which is positive for user security but might conflict with regulatory desires for transparency. On the other hand, SUAVE’s approach could be seen as more fair and compliant with the spirit of open markets: by creating a level playing field and returning value to users, it reduces the exploitative aspects of MEV that could draw regulatory ire (like backrunning users without their consent). SUAVE can also help eliminate unregulated dark pools – one reason regulators might be concerned about MEV is exclusive orderflow sales (which resemble insider trading). SUAVE replaces those with a transparent public auction, arguably a more compliant market structure. In terms of explicit compliance features, SUAVE could allow multiple ordering policies: for example, communities or jurisdictions could deploy their own executors with certain filters or preferences. However, the baseline is that SUAVE will try to be maximally neutral: “eliminate any central points of control, including Flashbots” and avoid embedding any policy decisions at the protocol level. Flashbots has stressed that it will not itself control SUAVE’s marketplace as it matures – meaning no central kill-switch or censorship toggle. The governance (if any) of SUAVE is still undefined publicly, but one can expect it to involve the broader community and possibly a token, rather than a company’s fiat. In summary, SUAVE is designed to align with decentralized principles, which by nature resists certain regulatory control (censorship), while potentially alleviating some regulatory concerns by making MEV extraction more equitable and transparent.

• Technical Architecture (Consensus & Crypto): SUAVE will operate its own blockchain environment – at least initially. It is described as an EVM-compatible chain specialized for preferences and MEV. The architecture has three main components: (1) the Universal Preference Environment (the SUAVE chain + mempool, where preferences are posted and aggregated), (2) the Execution Market (off-chain or on-chain executors who solve/optimize the preferences, akin to a decentralized “order matching engine”), and (3) Decentralized Block Building (a network of SUAVE participants that assemble blocks for various domains). At its core, SUAVE’s consensus will likely be a Proof-of-Stake BFT consensus (similar to Ethereum or Cosmos) to operate the SUAVE chain itself – though whether SUAVE becomes an L1, an Ethereum L2, or a suite of “restaking” contracts is still being decided. One possibility is that SUAVE could start as a layer-2 or sidechain that uses Ethereum for finality, or leverage existing validator sets. The security model is TBD but discussions have included making it an Ethereum L3 or a Cosmos chain. Cryptographically, SUAVE leans heavily on Trusted Hardware and encryption in its early roadmap. The SUAVE Centauri phase implements a “privacy-aware orderflow auction” in which Flashbots (centrally) operates SGX enclaves to keep searcher and user orderflow private. In SUAVE Andromeda, they plan to use SGX-based auctions and block building without trusting Flashbots (the enclaves provide confidentiality so even Flashbots can’t peek). By SUAVE Helios, the aim is to have a SGX-based decentralized building network – meaning many independent parties running enclaves that collectively build blocks, achieving both privacy and decentralization. Long-term, Flashbots is researching custom secure enclaves and cryptographic replacements like threshold decryption and multi-party computation to reduce reliance on Intel’s SGX. For example, they might use a threshold encryption scheme where validators of SUAVE jointly hold a key to decrypt transactions only after ordering is decided (ensuring no one can frontrun). This concept is similar to Anoma’s Ferveo or other “fair ordering via threshold encryption” ideas. Additionally, SUAVE treats user preferences as smart contracts on its chain. A user’s preference might contain a validity predicate and a payment condition – this is essentially a piece of code that says “if X outcome is achieved on chain Y, then pay executor Z this amount”. The SUAVE chain needs to handle oracles and cross-chain verification to know when a preference has been fulfilled (e.g. reading Ethereum state to see if a swap happened). This implies SUAVE’s architecture will involve on-chain light clients or oracle systems for connected chains, as well as potentially atomic cross-chain settlement (to ensure, for instance, that an executor can execute on Ethereum and Arbitrum and atomically claim the bid). SUAVE plans to be highly extensible: because it’s EVM-compatible, arbitrary contracts (SUAVE-native “preferences” or even normal dapps) could run on it, although the intention is to keep it focused on orderflow coordination. Consensus-wise, SUAVE might innovate by being an intent-centric chain rather than a transaction-centric one, but ultimately it must order messages (preferences) and produce blocks like any chain. One can imagine SUAVE adopting a consensus algorithm optimized for throughput and low-latency finality, since it will sit in the critical path of transactions for many chains. Perhaps a Tendermint-style instant finality or even a DAG-based consensus could be used to quickly confirm preferences. Regardless, SUAVE’s distinguishing features are on the transaction layer, not the consensus layer: the use of privacy tech (SGX, threshold encryption) for ordering, cross-domain communication, and smart-order routing logic built into the protocol. This makes it a kind of “meta-layer” on top of existing blockchains. Technically, every participating chain will need to trust SUAVE’s outputs to some extent (e.g. an Ethereum proposer would need to accept a SUAVE-built block or include SUAVE suggestions). Flashbots has indicated SUAVE will be introduced gradually and opt-in – domains can choose to adopt SUAVE sequencing for their blocks. If widely adopted, SUAVE could become a de facto MEV-aware transaction routing network for Web3. To sum up, SUAVE’s architecture is a marriage of blockchain and off-chain auction: a specialized chain for coordination, married with off-chain secure computation among executors, all anchored by cryptographic guarantees of fairness and privacy.

• Development Roadmap & Milestones: Flashbots outlined SUAVE’s roadmap in three major milestones, named after star systems: Centauri, Andromeda, and Helios. Centauri (the first phase, under development in 2023) focuses on building a centralized but privacy-preserving orderflow auction. In this phase, Flashbots runs the auction service (likely in SGX) that allows searchers to bid to backrun user transactions, returning MEV to users privately. It also includes launching a SUAVE devnet for early testing. Indeed, in August 2023 Flashbots open-sourced an early SUAVE client (suave-geth) and launched Toliman, the first public SUAVE testnet. This testnet has been used to experiment with preference expression and basic auction logic. Andromeda (the next phase) will roll out the first SUAVE mainnet. Here, users will be able to express preferences on a live network, and the Execution Market will operate (executors fulfilling intents). Andromeda also introduces SGX-based auctions and block building in a more distributed fashion – removing the need to trust Flashbots as an operator, and making the system truly permissionless for searchers and builders. One deliverable in this phase is using SGX to encrypt orderflow in a way that even block builders can’t peek yet can still build blocks (i.e. “open but private” orderflow). Helios is the ambitious third phase where SUAVE achieves full decentralization and cross-chain functionality. In Helios, a decentralized network of builders in SGX collaboratively produce blocks (no single builder dominance). Also, SUAVE will “onboard a second domain” beyond Ethereum – meaning it will handle MEV for at least two chains, demonstrating cross-chain MEV auctions. Additionally, cross-domain MEV expression and execution will be enabled (users can post truly multi-chain intents and have them executed atomically). Beyond Helios, Flashbots anticipates exploring custom hardware and advanced crypto (like zk-proofs or MPC) to further harden trust guarantees. Key updates and milestones so far: November 2022 – SUAVE announced; August 2023 – first SUAVE code release and testnet (Toliman); ongoing 2024 – Centauri phase orderflow auction running (Flashbots has hinted this is being tested with user transactions in a closed environment). A notable milestone will be the launch of the SUAVE mainnet (Andromeda), which as of mid-2025 is on the horizon. Flashbots has committed to building SUAVE in the open and inviting collaboration from across the ecosystem. This is reflected in the research and forum discussions, such as the “Stargazing” series posts that update on SUAVE’s design evolution. The endgame for SUAVE is that it becomes a community-owned piece of infrastructure – the “decentralized sequencing layer” for all of crypto. Achieving this will mark a major milestone in the fight for fair ordering: if SUAVE succeeds, MEV would no longer be a dark forest but a transparent, shared value source, and no single chain would have to suffer the centralizing effects of MEV on its own.

Anoma (Intent-Centric Architecture for Fair Counterparty Discovery)

Anoma is a radically different approach to enabling fair ordering and MEV mitigation – it is an entire architecture for intent-based blockchain infrastructure. Rather than bolting on an auction to existing chains, Anoma rethinks the transaction paradigm from the ground up. In Anoma, users don’t broadcast concrete transactions; they broadcast intents – declarations of what end state they desire – and the network itself discovers counterparties and forms transactions that fulfill these intents. By integrating counterparty discovery, fair ordering, and privacy at the protocol level, Anoma aims to virtually eliminate certain forms of MEV (like frontrunning) and enable “frontrunner-free” decentralized exchange and settlement. Anoma is more of a framework than a single chain: any blockchain can be a “fractal instance” of Anoma by adopting its intent gossip and matching architecture. For this discussion, we focus on Anoma’s first implementation (sometimes called Anoma L1) and its core protocol features, as they relate to fairness and MEV.

• Queuing and Transaction Ordering: Anoma discards the conventional mempool of transactions; instead it has a gossip network of intents. Users broadcast an intent, e.g. “I want to swap 100 DAI for at least 1 ETH” or “I want to borrow against collateral at the best rate.” These intents are partial orders – they don’t specify exact execution paths, just the desired outcome and constraints. All intents are gossiped throughout the network and collected. Now, ordering in Anoma works in two stages: (1) Counterparty Discovery/Matching, and (2) Transaction Execution with Fair Ordering. In stage 1, specialized nodes called solvers continuously monitor the pool of intents and try to find sets of intents that complement each other to form a valid transaction. For example, if Alice intends to trade DAI for ETH and Bob intends to trade ETH for DAI, a solver can match them. If multiple intents are compatible (like an order book of bids and asks), solvers can find an optimal matching or clearing price. Importantly, this happens off-chain in the solver network – effectively an algorithmic matchmaking. Once a solver (or group of solvers) have constructed a complete transaction (or set of transactions) that fulfill some intents, they submit it to the chain for execution. This is where stage 2 comes: Anoma’s consensus will then order these solver-submitted transactions into blocks. However, Anoma’s consensus is designed to be order-fair: it uses cryptographic techniques (threshold encryption) to ensure that transactions are ordered without being influenced by their content or precise submission timing. Specifically, Anoma plans to use Ferveo, a threshold encryption scheme, at the mempool level. The way this works is: solvers encrypt the transactions they want to propose using a collective public key of the validators. Validators include these encrypted transactions in blocks without knowing their details. Only after a transaction is finalized in a block do validators collectively decrypt it (by each contributing a share of the decryption key). This ensures that no validator can selectively front-run or reorder based on a transaction’s content – they commit to an ordering blind. The consensus algorithm effectively orders transactions (really, intents) in something closer to a first-seen or batched manner, since all transactions in a given “batch” (block) are encrypted and revealed simultaneously. In practice, Anoma can implement batch auctions for certain applications: e.g. an intent to trade can be gathered over N blocks (kept encrypted), then all decrypted together after N blocks and matched by solvers in one batch. This prevents fast actors from seeing others’ orders and reacting within that batch – a huge advantage for fairness (this technique is inspired by Frequent Batch Auctions and has been proposed to eliminate high-frequency trading advantages). Additionally, Anoma’s validity predicates (application-level smart contracts) can enforce fairness constraints on ordering outcome. For example, an Anoma DEX application might have a rule: “all trades in a batch get the same clearing price, and solvers cannot insert additional transactions to exploit users”. Because these rules are part of the state validity, any block containing an unfair match (say, a solver tried to sneak in a self-trade at a better price) would be invalid and rejected by validators. In summary, ordering in Anoma happens as match then encrypt+order: intents are conceptually queued until a solver forms a transaction, and then that transaction is ordered by a fair-order consensus (preventing typical MEV). There’s effectively no mempool race, since user intents are not directly competing on gas price or time priority. Instead, the competition is for solvers to find matches, and then those matches are executed in a way that no one can change the order or intercept them while in flight. This architecture promises to neutralize many MEV vectors – there is no concept of frontrunning an intent because intents aren’t actionable until the solver assembles them, and by then they’re encrypted into the block. It’s a fundamentally different queuing model aimed at eliminating time-based priority exploits.

• MEV Suppression/Extraction Mechanisms: Anoma is designed to minimize “bad MEV” by construction. By having trades resolved via batch solving and threshold encryption, typical MEV attacks like sandwiching are impossible – no one sees an intent and can insert their own before it, because intents are not transactions that live in a transparent mempool. Solvers only output final matched transactions after the opportunity for insertion has passed (due to encryption and batching). In an Anoma-based DEX, users wouldn’t be frontrun or backrun in the traditional sense, because all trades in a batch execute together at a uniform price (preventing an attacker from exploiting price change between them). This essentially suppresses predatory MEV like DEX arbitrage or sandwiching; the value that would have been taken by a bot is instead retained by users (they get a fair price). Anoma’s approach to arbitrage is also noteworthy: in many cases, if multiple intents create an arbitrage opportunity, the solver that matches them will incorporate that profit into the match (e.g. match different prices and net out a profit). But since multiple solvers can compete to provide the best match, competition can force solvers to give most of that edge back to users in the form of better fill terms. For example, if one user wants to sell at price A and another wants to buy at price B (B > A implies a gap), a solver could fulfill both at an intermediate price and capture the difference as profit – but if another solver offers users an even closer price to each other (leaving less profit), it will win the intent. Thus, solvers compete away MEV margins to benefit users, akin to how searchers in Flashbots compete via fees. The difference is this happens algorithmically via intent matching rather than gas bidding. There may still be “extracted MEV” in Anoma, but it is likely confined to solvers earning modest fees for their service. Notably, Anoma expects most orderflow to be internalized by the protocol or application logic. In some cases, this means what would be an MEV opportunity becomes just a normal protocol fee. For instance, Anoma’s first fractal instance (Namada) implements an on-chain bonding curve AMM; arbitrage on that AMM is captured by the AMM’s mechanism (like a built-in rebalancer) rather than external arbitrageurs. Another example: a lending intent offering high interest could be matched with a borrowing intent; no third party liquidator is needed if collateral falls, because the intents themselves could handle rebalancing or the protocol could auto-liquidate at a fair price. By cutting out third-party extractors, Anoma reduces the prevalence of off-chain MEV extraction. Additionally, Anoma emphasizes privacy (through the Taiga subsystem of ZK circuits). Users can choose to keep their intents partially or fully shielded (e.g. amounts or asset types hidden). This further suppresses MEV: if the details of a large order are hidden, nobody can target it for value extraction. Only after matching and execution might details emerge, by which time it’s too late to exploit. In summary, Anoma’s mechanism is largely about preventing MEV rather than extracting it: by batching transactions, encrypting the mempool, and baking economic alignment into matching, it tries to ensure there’s little opportunity for malicious arbitrage or frontrunning. The necessary MEV (like arbitrage to equalize prices across markets) is handled by solvers or protocol logic in a trust-minimized way. One could say Anoma aims for “MEV minimization”, striving for outcomes as if every user had access to the perfect counterparty instantly with no leakage. Any value extracted in facilitating that (the solver’s reward) is akin to a small service fee, not a windfall from exploiting asymmetry.

• Economic Incentive Structure: In Anoma, solvers take on the role analogous to both matchmakers and block builders. They incur costs (computation, maybe posting collateral) to find intent matches, and they are rewarded when they successfully propose transactions that get included. Solvers can earn in a few ways: they might charge a fee or spread within the transaction they construct (for example, giving users slightly less favorable terms and keeping the difference, similar to how a DEX aggregator might take a small cut). Or, certain intents might explicitly include a reward for the solver (like “I’m willing to pay up to 0.01 ETH to get this done”). The exact compensation model is flexible, but the key is that solvers compete. If one solver tries to take too high a fee, another can propose a solution with a better user outcome and win inclusion. This competitive dynamic is intended to keep solver profits in check and aligned with providing value. Validators (Block Producers): Anoma validators run the consensus that orders and executes transactions. They are incentivized by block rewards and fees, as in any blockchain. Notably, if intents are matched across multiple users, the resulting transaction could have multiple fee sources (each user might contribute a fee or a portion of assets). It’s possible Anoma’s fee model could allow fee splitting, but typically validators will get the standard gas fees for processing transactions. In future phases, Anoma plans an “on-demand consensus” and a native token. The idea is that many Anoma instances (or shards) could exist, and some could spin up temporarily for specific tasks (“ad-hoc consensus” for particular application needs). The token would likely be used to stake and secure these instances. Incentives here ensure that the network has enough validators to process all the matched transactions reliably and that they behave honestly in the threshold decryption process (perhaps slashing conditions if they try to decrypt early or censor). Users: Users in Anoma potentially save money and earn better outcomes rather than paying MEV implicitly. For example, they might consistently get better trade prices than on a traditional chain, meaning value stays with them. In some cases, users might also pay explicit fees to incentivize solvers, especially for complex intents or when they desire faster matching. But since users can express intents without specifying how to do them, they offload the heavy lifting to solvers and only pay if it’s worth it. There’s also a notion of “intent owners can define their own security/performance trade-offs” – e.g. a user could say “I’ll wait longer for a better price” or “I’ll pay more for immediate execution.” This flexibility lets users themselves decide how much to offer to solvers or validators, aligning economic incentives with their needs. MEV redistribution: If any MEV does occur (like cross-chain ARB or so), Anoma architecture could allow capturing it into the system. For instance, multiple Anoma shards or instances might coordinate to settle an atomic multi-chain arb, and the profit could be shared or burned (depending on design) rather than letting an external arbitrageur keep it all. In general, because Anoma gives applications control over transaction flow, it’s possible to implement protocol-owned MEV strategies (similar to Skip’s philosophy) at the application level. For example, a DeFi app on Anoma could automatically route all user trades through an in-protocol solver that guarantees best execution and shares any additional profit with users or with liquidity providers. The net effect is that third-party MEV extractors are disintermediated. Economically, this is positive-sum for honest participants (users, LPs, etc.), but it might reduce opportunities for classic searchers. However, new roles like specialized solvers (maybe one focuses on NFT matching, another on FX swaps, etc.) will emerge. These solvers are analogous to today’s MEV searchers, but they operate within the system rules and likely have less insane profit margins due to competition and protocol constraints. Lastly, the Anoma Foundation’s vision hints at Anoma being a public good infrastructure. There will be a native token, presumably ANOMA, which might capture value via fees or be required for staking. One can foresee token incentives (inflationary rewards, etc.) for validators and perhaps even for solvers to bootstrap activity. At time of writing, details on token economics are not final, but the roadmap confirms an Anoma token and native on-demand consensus are planned in future phases. To summarize, Anoma’s incentive model encourages cooperative behavior: solvers earn by helping users get what they want, not by exploiting them; validators earn by securing the network and ordering fairly; and users “pay” mainly through giving up some MEV to solvers or fees, but ideally much less than the implicit MEV they’d lose in other systems.

• Compliance and Neutrality: Anoma, being a framework, not a single network, can be instantiated in various ways – some could be permissioned, but the flagship Anoma L1 and similar instances are meant to be permissionless and privacy-enhanced. By incorporating heavy privacy features (like shielded intents using zero-knowledge proofs in Taiga), Anoma aligns with the view that financial privacy is a right. This could put it at odds with certain regulatory regimes that demand open visibility into transactions. However, Anoma’s design might also avoid certain regulatory pitfalls. For instance, if front-running and unfair order selection are eliminated, market manipulation concerns are mitigated – a regulator might appreciate that users aren’t being systematically exploited by insiders. Additionally, the concept of “user-defined security models” implies that users or communities could opt into different trust assumptions. Potentially, a regulated application could be built on Anoma where, say, the solver or some subset of validators are KYC’d entities ensuring compliance for that particular intent domain. Anoma as a base layer wouldn’t enforce KYC on everyone, but one could implement validity predicates requiring (for example) a proof of eligibility for certain transactions (like a proof of not being a sanctioned address, or a credential check) if an application needed it. The architecture is flexible enough to support compliance at the application level without compromising the base layer neutrality. Regarding censorship: Anoma’s threshold encryption means that even if validators wanted to censor, they cannot target specific intents because they don’t see them in plaintext. The only thing they could do is refuse to include encrypted transactions from certain solvers or users, but that would be obvious (and against the protocol rules if done arbitrarily). The expectation is that consensus rules will discourage censorship – for example, perhaps if a block doesn’t include all available decrypted intents from the last batch, it could be deemed invalid or less preferable. In any case, the decentralization of validators and the encrypted nature of payloads together ensure a high degree of censorship-resistance. On neutrality: Anoma aims to be a general platform not controlled by any single entity. The research and development is spearheaded by Heliax (the team behind Anoma and Namada), but once live, an Anoma network would be community-run. There is likely to be on-chain governance for upgrades, etc., which could raise compliance questions (e.g. could a government subvert governance to change rules?), but that is a general blockchain issue. One interesting compliance-related feature is that Anoma supports multiple parallel instances – meaning one could have an isolated intent pool or shard for certain asset types or jurisdictions. This isn’t explicitly for regulation, but it could allow, for instance, a CBDC intent pool where only authorized banks run solvers, coexisting with a free DeFi pool. The architecture’s modularity provides flexibility to segregate if needed, while still allowing interoperability via intents bridging. Finally, in terms of legal compatibility, Anoma’s entire concept of intents might avoid some classifications that bedevil traditional crypto: since an intent is not a binding transaction until matched, one could argue users maintain more control (it’s like posting an order on an exchange, which has clearer legal precedent, versus directly executing a trade). This might help with things like tax treatment (the system could potentially give a unified receipt of a multistep trade rather than many transactions) – though this is speculative. Overall, Anoma prioritizes decentralization, privacy, and user autonomy, which historically can clash with regulatory expectations, but the fairness and transparency gains might win favor. It essentially brings the sophistication of traditional financial matching engines on-chain, but without centralized operators. If regulators come to understand that model, they might see it as a more orderly and fair market structure than the free-for-all of mempools.

• Technical Architecture (Consensus & Cryptography): Anoma’s architecture is complex, comprising several components: Typhon (network, mempool, consensus, execution) and Taiga (the zero-knowledge privacy layer). The core of Typhon is the intent gossip layer and a novel approach to combined consensus + matching. Anoma’s consensus protocol extends typical BFT consensus with the concept of “Validity Predicates” and “Proof-of-Order-Matching”. Essentially, each application in Anoma can define a validity predicate that must be satisfied for transactions (think of it like smart contract conditions that apply at the block level, not just tx level). This allows enforcing properties like batch auction clearing prices, etc., as described. The consensus algorithm itself is likely building on Tendermint or HotStuff style BFT (since Anoma is in the Cosmos realm and supports IBC). Indeed, Anoma’s initial testnet (Feigenbaum in 2021) and Namada use Tendermint-style consensus with modifications. One major modification is the integration of threshold encryption (Ferveo) in the mempool pipeline. Typically, Tendermint selects a proposer who orders transactions. In Anoma, the proposer would order encrypted intents/transactions. Ferveo likely works by having validators periodically agree on a threshold public key, and each intent submitted by solvers is encrypted to that key. During block proposal, all encrypted transactions are included; after proposing, the validators run a protocol to decrypt them (perhaps the next block contains the decrypted outputs or some scheme like that). This adds a phase to consensus but ensures order fairness. Cryptographically, this uses distributed key generation and threshold decryption (so it relies on assumptions like at least 2/3 of validators being honest to not leak or early-decrypt data). On the privacy side, Taiga provides zkSNARK or zk-STARK proofs that allow intents to remain partially or fully shielded. For example, a user could submit an intent to swap without revealing the asset type or amount; they provide a ZK proof that they have sufficient balance and that the transaction will be valid if matched, without revealing specifics. This is analogous to how shielded transactions in Zcash work, but extended to intents. The use of recursive proofs is mentioned, meaning multiple steps of a transaction (or multiple intents) can be proven in one succinct proof for efficiency. The interplay of Taiga and Typhon means that some solvers and validators might be operating on ciphertext or commitments rather than plaintext values. For instance, a solver might match intents that are expressed in a confidential way, solving an equation of commitments. This is cutting-edge cryptography and beyond what most current blockchains do. Another key piece is IBC integration: Anoma instances can communicate with other chains (especially Cosmos chains) via the Inter-Blockchain Communication protocol. This means an intent on Anoma could potentially trigger an action on another chain (via an IBC message) or consume data from another chain’s state. The Mainnet Phase 1 in Anoma’s roadmap specifically mentions an “adapter” on Ethereum and rollups to allow Anoma intents to tap into EVM liquidity. Likely, an Anoma solver could compose a transaction that, say, uses Uniswap on Ethereum, by crafting an intent that when matched sends a message to Ethereum to execute a swap (perhaps via a relayer or via something like an IBC bridge). Consensus has to ensure atomicity: presumably, Anoma’s output might be like a single transaction that spans multiple chains (something like initiating a tx on chain A and expecting an outcome on chain B). Achieving atomic cross-chain settlement is hard; possibly Anoma will start by settling on one chain at a time (Phase 1 focuses on Ethereum ecosystem, probably meaning Anoma intents will settle onto Ethereum L1 or L2s in one go). Later, “Chimera chains” and on-demand consensus might allow custom sidechains to spin up to handle particular cross-chain matches. Performance-wise, Anoma’s approach could be more computationally intensive (solvers doing NP-hard matching problems, validators doing heavy crypto). But the trade-off is vastly improved user experience (no failed transactions, better prices, etc.). The development of Anoma requires building these novel components nearly from scratch: Heliax has been creating Juvix, a new language for writing validity predicates and intents, and lots of research (some references from Anoma’s site talk about these concepts in detail). Major milestones: Anoma’s first public testnet Feigenbaum launched Nov 2021 as a demo of basic intent gossip. Subsequently, Heliax shifted focus to launching Namada (a privacy-focused L1 that can be seen as an instance of Anoma focusing on asset transfers) – Namada went live in 2023 and includes features like shielded transfers and Ferveo threshold encryption for its mempool. This shows the tech in action on a narrower use-case. Meanwhile, Anoma’s full vision testnets have been rolling out in stages (“summer 2023 testnet” mentioned in community as well). The roadmap indicates Phase 1 mainnet will integrate Ethereum, Phase 2 adds more chains and advanced cryptography, and eventually native consensus and token come in. The separation of “consensus and token in future phase” suggests initial Anoma mainnet might rely on Ethereum (e.g. leveraging Ethereum security or existing tokens rather than having its own from day one). Possibly they launch an L2 or sidechain that posts to Ethereum. Then later spin up their own PoS network with a token. This phased approach is interesting – it might be to lower the barrier for adoption (use existing capital on Ethereum rather than launching a new coin initially). In conclusion, Anoma’s architecture is novel and comprehensive: it marries cryptographic fairness (threshold encryption, ZK proofs) with a new transaction paradigm (intent-based matching) and cross-chain capabilities. It’s arguably the most aggressive attempt to eradicate traditional MEV at the protocol level, by doing what no legacy chain does: built-in fair matching engines. The complexity is high, but if successful, an Anoma chain could provide users near CEX-like execution guarantees in a decentralized setting, which is a holy grail in blockchain UX and fairness.

Skip Protocol (Cosmos Sovereign MEV Control and Fair Ordering Toolkit)

Skip Protocol is a leading MEV solution in the Cosmos ecosystem, focused on giving each blockchain (“app-chain”) the tools to manage transaction ordering and MEV capture on its own terms. Unlike Flashbots or Anoma which propose network-spanning systems, Skip aligns with Cosmos’s philosophy of sovereignty: each chain can integrate Skip’s modules to enforce custom fair ordering rules, run in-protocol blockspace auctions, and capture MEV for the chain’s stakeholders or users. Skip can be thought of as a suite of Cosmos SDK modules and infrastructure that together enable Protocol-Owned Blockbuilding (POB) and flexible transaction sequencing. It has been adopted on chains like Osmosis, Juno, Terra, and others in Cosmos, and is also collaborating with projects like dYdX’s upcoming chain for MEV mitigation. Key elements include an on-chain auction mechanism for priority transactions, consensus-level transaction ordering logic, and in-app mechanisms to recycle MEV (“good MEV”) for the protocol’s benefit.

• Transaction Queuing & Ordering Algorithms: In a typical Cosmos chain (using Tendermint/BFT consensus), the mempool orders transactions roughly by fee and arrival time, and the block proposer can pick any ordering when creating a block (with no algorithmic constraints beyond including valid txs). Skip changes this by introducing consensus-enforced ordering rules and multi-lane mempools. Using Cosmos’s new ABCI++ interface (which allows customizing block proposal and processing), Skip’s Protocol-Owned Builder (POB) module can partition the block into distinct lanes with different ordering policies. For example, one lane could be a Top-of-Block auction lane where the highest-bid transactions (perhaps from arbitrage bots or urgent trades) are placed first in the block in a fixed order, another lane could be a Free lane for ordinary user transactions with no fees, and a Default lane for normal transactions with fees. The Skip module’s BlockBuster component allows developers to define these lanes and their ordering logic in a modular way. Crucially, these rules are enforced by all validators: when a proposer constructs a block, the other validators will verify that the block’s transactions adhere to the agreed ordering rules (via the ProcessProposal ABCI checks). If not, they can reject the block. This means even a malicious or profit-seeking proposer cannot deviate (e.g. cannot slip in their own front-run transaction ahead of a winning auction bidder, because that would violate the ordering rule). Some examples of ordering rules Skip enables: (a) Order transactions by descending gas price (fee) – ensuring the highest fee tx always get priority. This formalizes a fair “pay-for-priority” scheme instead of random or time-based. (b) Must include at least one oracle price update tx before any trades – ensuring data feeds are updated, which prevents scenarios where a proposer could ignore oracle updates to exploit stale prices. (c) Limit the number of special transactions at top-of-block – e.g. only one auction-winning bundle can occupy the very top, to prevent spamming of many small MEV grabs. (d) No transactions that violate a state property – Skip allows stateful ordering rules, like “after building the block, ensure no DEX trade was executed at a price worse than if it were last in the block” (a way to enforce no sandwich attack occurred). One concrete rule described is a “zero frontrunning condition across all DEXs”, which could mean if any transaction would have been affected by later ones in a way that indicates frontrunning, the block is invalid. This is powerful: it’s essentially making fairness part of block validity. Cosmos chains can implement such rules because they control their full stack. Skip’s framework gives a structured way to do it via the AuctionDecorator in the SDK, which can check each tx against configured rules. Additionally, Skip provides a mempool enhancements: the node’s mempool can simulate blocks ahead of time, filter out failing tx, etc., to help proposers follow the rules efficiently. For instance, if a block’s auction lane must have highest bids, the mempool can be sorted by bids for that lane. If a block must include only transactions that result in a certain state condition, the proposer’s node can simulate transactions as it picks them to ensure the condition holds. In summary, Skip enables deterministic, chain-defined ordering rather than leaving it entirely to proposer whim or simple gas price priority. Chains adopt Skip’s builder module to effectively codify their transaction ordering policy into the protocol. This fosters fairness because all validators enforce the same rules, removing the opportunity for a single proposer to do arbitrary reordering for MEV unless it’s within the allowed mechanism (like the auction, where it’s transparent and competitive). Queuing of transactions in Skip’s model might involve separate queues per lane. For example, an auction lane might queue special bid transactions (Skip uses a special MsgAuctionBid type for bidding for top-of-block inclusion). Those bids are collected each block and the highest is selected. Meanwhile, normal tx are queued in the default mempool. Essentially, Skip introduces a structured queue: one for priority bids, one for free or others, etc., each with its own ordering criteria. This modular approach means each chain can customize how it balances fairness and revenue – e.g. Osmosis might say “we want no MEV auction at all, but we enforce order-fairness via threshold encryption” (they did implement threshold encryption with help from Skip and others), whereas another chain might say “we allow auctions for MEV but require some proceeds to be burned”. Skip supports both. This configurability of ordering is Skip’s hallmark.

• MEV Mitigation and Extraction Mechanisms: Skip’s approach to MEV is often described as “protocol-owned MEV” and “multiplicity.” Protocol-owned MEV means the blockchain protocol itself, via its code and governance, captures or redistributes MEV rather than leaving it to individual validators or outsiders. Multiplicity refers to ensuring the “right” (multiple) transactions get included – essentially not excluding legitimate user tx in favor of only MEV tx, and perhaps including multiple MEV opportunities in one block if possible (so no single searcher monopolizes). Concretely, Skip provides tools to capture MEV in ways that benefit the network: one is Skip Select, a blockspace auction system for top-of-block inclusion. In Skip Select, searchers (like arbitrage bots) submit bundles with tips to validators, similar to Flashbots bundles, except it’s done natively on-chain via Skip’s modules. The highest paying bundle (or bundles) are then automatically inserted at the top of the block in the specified order. This guarantees those transactions execute as intended, and the validator (or chain) collects the tip. This mechanism takes what was an off-chain OTC process (in Ethereum) and makes it an open, on-chain auction – improving transparency and access. Another mechanism is ProtoRev (Prototype Revenue module), which Skip developed for Osmosis. ProtoRev is an on-chain arbitrage module that automatically detects and executes cyclic arbitrages (like those involving multiple pools) within the block’s execution and accumulates the profit to the chain’s treasury or community pool. Essentially, Osmosis decided that certain “good MEV” (like arbitrage that keeps prices aligned) should still happen (for market efficiency) but the protocol itself does the arbitrage and captures the profit, then later distributes it (e.g. to stakers or as liquidity mining incentives). This eliminates the need for external arbitrage bots on those opportunities and ensures the value stays in the ecosystem. ProtoRev was the first of its kind on a major chain and demonstrates how deep integration can mitigate MEV’s externalities: users trading on Osmosis face less slippage because if an arbitrage exists after their trade, the protocol will close it and essentially rebate the value back to Osmosis (which could indirectly benefit users via lower fees or token buybacks, etc.). Moreover, Skip empowers chains to implement anti-MEV measures like threshold encryption for the mempool. For example, Osmosis, in collaboration with Skip and others, is implementing mempool encryption where transactions are submitted encrypted and only revealed after a fixed time (similar to Anoma’s idea, but at the chain level). While not a Skip product per se, Skip’s architecture is compatible – Skip’s auction can run on encrypted transactions by doing the auction based on declared bids rather than reading tx content. In terms of suppressing harmful MEV: Skip’s consensus rules like “no front-running allowed” (enforced by state checks) are a direct measure to stop malicious behavior. If a validator tries to include a sandwich attack, other validators would detect that the state outcome violates the no frontrunning rule (for instance, they could check that no trade was immediately preceded and followed by another from the same address in a way that took advantage). That block would be rejected. Knowing this, validators won’t even try to include such patterns, thus users are protected by protocol law. Skip also encourages burning or redistributing MEV revenue to avoid perverse incentives. For example, a chain could choose to burn all auction proceeds or put them in a community fund rather than give them all to the block proposer. This reduces the incentive for validators to re-order transactions themselves, since they might not personally profit from it (depending on the chain’s choice). In summary, Skip’s toolkit allows each chain to surgically extract MEV where it’s beneficial (e.g. arbitrage to maintain market efficiency, liquidations to keep lending markets healthy) and ensure that value is captured by the protocol or users, while strictly forbidding and preventing malicious MEV (like user-unfriendly frontrunning). It’s a pragmatic mix of extraction and suppression, tailored by governance: rather than one-size-fits-all, Skip empowers communities to decide which MEV is “good” (and automate its capture) and which is “bad” (and outlaw it via consensus rules). The result is a fairer trading environment on Skip-enabled chains and an additional revenue source that can fund public goods or lower costs (one of Skip’s blog posts notes fair MEV capture can be used to “fairly distribute revenue among all network participants”).

• Economic Incentive Structure: Skip’s introduction fundamentally shifts incentives especially for validators and chain communities in Cosmos. Traditionally, a validator in Cosmos might extract MEV by privately reordering transactions in their block (since Cosmos lacks an MEV auction by default). With Skip, validators instead agree to a protocol where MEV is captured via auctions or modules and often shared. Validators still benefit: they can receive a cut of the auction proceeds or extra fees from Skip’s mechanisms, but importantly all validators (not just the proposer) can benefit if designed that way. For example, some Skip auctions can be configured such that the revenue is split among all stakers or according to governance decisions, rather than a winner-takes-all for the proposer. This aligns validators collectively to run the Skip software because even non-proposers get safety (knowing if someone tries an invalid block, it won’t pay off) and possibly revenue. Some chains might still give the proposer most of the MEV auction fee (to maximize immediate incentive to include it), but even then it’s transparent and competitive, arguably reducing the chance of under-the-table deals. Chain/Community: The concept of protocol-owned MEV means the blockchain and its stakeholders capture MEV. For example, Osmosis directs ProtoRev profits to its community pool, effectively turning MEV into an additional protocol revenue that could fund development or be distributed to OSMO stakers. This makes the community at large an “owner” of that MEV, aligning everyone’s interest in extracting MEV in healthy ways. If users know the MEV is going back to improving the chain or tokenomics, they might be more accepting of it than if it goes to a random bot. Searchers: In Skip’s model, independent searchers/bots may have less to do on-chain because some opportunities are taken by protocol logic (like ProtoRev) and others are channeled through auctions. However, Skip doesn’t eliminate searchers – rather, it channels them into bidding through the proper routes. A searcher can still attempt a complex strategy, but to guarantee inclusion at a particular spot, they should participate in Skip’s auction (Skip Select) by submitting their bundle with a bid. If they don’t, they risk a validator ignoring them in favor of someone who did bid or the chain’s own mechanism taking the opportunity. So searchers in Cosmos are evolving to work with Skip: e.g. many arbitrageurs on Osmosis now submit their arbs via Skip’s system. They pay a portion to the chain, keeping less profit, but it’s the price to play. Over time, some “searcher” roles might be entirely absorbed (like backrunning arbitrage – ProtoRev handles it, so no external searcher can compete). This might reduce spam and wasted effort in the network (no more multiple bots racing; just one protocol execution). Users: End-users stand to gain because of a fairer environment (no surprise MEV attacks). Also, some Skip configurations explicitly reward users: MEV redistribution to users is possible. For instance, a chain could decide to rebate some MEV auction revenue to the users whose trades created that MEV (similar to Flashbots’ refund idea). Astroport, a DEX on Terra, integrated Skip to share MEV revenue with swappers – meaning if a user’s trade had MEV, part of that value is returned to them by default. This aligns with the ethos that MEV should go to users. While not all chains do this, the option exists via Skip’s infrastructure to implement such schemes. Skip Protocol itself (the company/team) has a business model where they provide these tools often for free to validators (to encourage adoption), and they monetize by partnering with chains (B2B). For example, Skip might take a small fee from the MEV captured or charge chains for advanced features/support. It’s mentioned that Skip is free for validators but uses a B2B model with chains. This means Skip has an incentive to maximize MEV captured by the chain and community (so that the chain is happy and perhaps shares a portion as per agreement). But because governance is involved, any fee Skip takes is usually agreed upon by the community. The economic effect is interesting: it professionalizes MEV extraction as a service provided to chains. In doing so, it disincentivizes rogue behavior – validators don’t need to individually make shady deals, they can just use Skip and get a reliable flow of extra revenue that’s socially accepted. Honest behavior (following the protocol rules) yields nearly as much or more profit than trying to cheat, because if you cheat, your block might be invalid or you might get slashed socially, etc. Governance plays a significant role: adopting Skip’s module or setting the parameters (like auction cut, distribution of proceeds) is done via on-chain proposals. This means the economic outcomes (who gets the MEV) are ultimately determined by community vote. For instance, the Cosmos Hub is debating adopting Skip’s builder SDK to possibly redirect MEV to the Hub’s treasury or stakers. This alignment via governance ensures that the use of MEV is seen as legitimate by the community. It turns MEV from a toxic byproduct into a public resource that can be allocated (to security, users, devs, etc.). In summary, Skip reshapes incentives such that validators collectively and users/community benefit, while opportunistic MEV takers are either co-opted into the system (as bidders) or designed out. Everyone is better off in theory: users lose less value to MEV, validators still get compensated (even possibly more in total, due to auctions), and the network as a whole can use MEV to strengthen itself (financially or via fairer experience). The only losers are those who thrived on zero-sum extraction without returning value.

• Compliance and Regulatory Compatibility: Skip’s framework, by empowering chain governance, actually makes it easier for chains to ensure compliance or specific policies if they desire. Because Skip operates at the protocol level, a chain could choose to enforce certain transaction filtering or ordering rules to comply with regulations. For example, if a chain wanted to block sanctioned addresses, they could integrate an AnteHandler or AuctionDecorator rule in Skip’s module that invalidates blocks containing blacklisted addresses. This is arguably simpler than in Ethereum, where censorship is an off-chain choice by individual validators; in Cosmos with Skip, it could be a chain-wide rule (though it would be controversial and goes against decentralization ideals for many). Alternatively, a chain could enforce something like “FIAT onramp transactions must appear before others” if mandated by some law. The Skip toolkit doesn’t come with preset compliance rules, but it’s flexible enough to implement them if a community is compelled to (through governance). On the flip side, Skip can bolster censorship-resistance: by distributing MEV revenue and giving equal access, it reduces the advantage of any single validator that might censor for profit. Additionally, if threshold encryption mempools (like the one Osmosis is adding) become standard with Skip, that will hide transaction contents, making censorship harder (like in Anoma). Skip is neutral infrastructure – it can be used to either comply or resist, depending on governance. Since Cosmos chains are often jurisdiction-specific (Terra’s community might worry about Korean laws, Kava might worry about US laws, etc.), having the option to configure compliance is valuable. For instance, a permissioned Cosmos chain (like an institutional chain) could still use Skip’s builder module but maybe require that only whitelisted addresses can bid in auctions, etc., aligning with their regulations. Regulatory compatibility is also about transparency: Skip’s on-chain auctions produce a public record of MEV transactions and who paid what. This could actually satisfy some regulatory concerns about fairness (everyone had a chance to bid, and it’s auditable). It’s more transparent than under-the-table payments to validators. Also, by capturing MEV on-chain, Skip reduces the likelihood of off-chain cartels or dark pools, which regulators fear due to opaqueness. For example, without Skip, validators might make private deals with searchers (as was seen with relay censorship issues). With Skip, the expectation is you use the official auction – which is open and logged – to get priority. This fosters an open market accessible to all bots equally, which is arguably fairer and less prone to collusion (collusion is possible but governance oversight exists). Another compliance angle: since Skip deals with value capture, if MEV revenue goes to a community pool or treasury, that might raise questions (is it a fee, is it taxable, etc.?). But those are similar to how transaction fees are handled, so nothing fundamentally new legally. In Cosmos, chain communities can also decide how to use that fund (burn, distribute, etc.), which they can align with any legal guidance if needed (for example, they might avoid sending it to a foundation if that triggers tax issues and instead burn it). In terms of censorship-resistance, one interesting note: by enforcing block validity rules, Skip prevents validators from censoring certain tx if that would break rules. For example, if a chain had a rule “must include at least one oracle update”, a censoring validator couldn’t just omit all oracle tx (which might come from certain sources) because their block would be invalid. So, ironically, Skip rules can force inclusion of critical transactions (anti-censorship) just as they could be used to force exclusion of disallowed ones. It’s all about what the community sets. Neutrality: Skip’s default stance is empowering chains to “protect users from negative MEV and improve user experience”, which implies neutrality and user-friendliness. There isn’t a central Skip network making decisions – each chain is sovereign. Skip as a company might advise or provide defaults (like a recommended auction format), but ultimately the chain’s token holders decide. This decentralization of MEV policy to each chain’s governance can be seen as more compatible with regulatory diversity: e.g. a US-based chain could implement OFAC compliance if legally pressured, without affecting other chains. It’s not one relay censoring across many chains; it’s per-chain choice. From a regulator perspective, Skip doesn’t introduce any additional illicit activity – it just reorganizes how transactions are ordered. If anything, it might reduce volatility (fewer gas wars) and create more predictable execution, which could be a plus. Summing up, Skip’s architecture is highly adaptable to compliance needs while preserving the option for maximal censorship-resistance if communities prioritize that. It keeps MEV in the daylight and under collective control, which likely makes blockchain ecosystems more robust against both malicious actors and regulatory crackdowns, since self-governance can proactively address worst abuses.

• Technical Architecture & Implementation: Skip Protocol is built tightly into the Cosmos SDK stack. The core delivery is a set of modules (e.g. x/builder) and modifications like the BlockBuster mempool implementation. Cosmos chains run a consensus (Tendermint/CometBFT) which offers ABCI hooks for preparing and processing proposals. Skip leverages the ABCI++ extensions that allow executing code between block proposal and finalization. This is how it enforces ordering: PrepareProposal can reorder the block transactions according to lane rules before broadcasting the proposal, and ProcessProposal on receiving validators can check the ordering and state validity matches expectations. This is a modern feature (Cosmos SDK v0.47+), and Skip’s POB is compatible with recent SDK versions. Under the hood, Skip’s modules maintain data structures for auctions (e.g. an on-chain order book of bids for top-of-block). They also likely use priority transaction types. The README shows a special MsgAuctionBid and custom logic to handle it. So searchers interact by sending these messages through normal Cosmos transactions, which then the module intercepts and places accordingly. The builder module’s AnteHandler (the AuctionDecorator) can consume auction bids and decide winners in the block assembly phase. Cryptographically, Skip doesn’t inherently add new cryptographic requirements (aside from whatever the chain chooses, like threshold cryptography for mempool, which is separate). It relies on the honesty of >2/3 validators to enforce the rules and not collude to break them. If a majority did collude, they could technically change the rules via governance or ignore them by making that the new de facto rule. But that’s the case with any chain logic. Skip’s design tries to make it mechanically impossible for a single validator to cheat small-scale. For example, any attempt to deviate ordering will be caught by others because it’s objective. So it reduces trust in single proposers. In performance terms, running auctions and extra checks does add overhead. However, Cosmos blocks are relatively small and time between blocks is often a couple seconds, which is enough for these operations in most cases. Simulation (pre-executing txs to ensure no failure and ordering constraints) might be the heaviest part, but validators already do block execution normally, so this is similar. The presence of multi-lane means mempool separation: e.g. a transaction might need to specify which lane it’s targeting (auction vs free vs default). The Skip BlockBuster design indeed had separate lanes like lanes/auction, lanes/free etc., likely separate mempool queues. That ensures, for instance, free transactions don’t delay or interfere with auction ones. It’s a bit like having multiple priority classes in scheduling. Another aspect is security and misbehavior: If a proposer tries to game the auction (e.g. include their own tx but claim it followed rules), other validators will reject the block. Cosmos consensus then likely moves to the next proposer, slashing the previous one for double signing or just missing (depending on scenario). So the chain security model handles that – no special slashing by Skip needed beyond existing consensus. One could extend skip to slash for malicious ordering but probably unnecessary if block simply fails. Development and Tooling: Skip’s code has been open-sourced (initially at skip-mev/pob and now likely moved to a new repo after stable releases). They’ve been through testnets and iterations with partner chains. On the roadmap, we’ve seen: Osmosis Prop 341 (passed in fall 2022) to integrate ProtoRev and auctions with Skip – delivered in early 2023. Terra’s Astroport integrated MEV sharing with Skip in 2023. The Cosmos Hub is evaluating Skip’s “Block SDK” which would bring similar features to the Hub. Another interesting frontier is cross-chain MEV via the Interchain Scheduler – the Cosmos Hub community is exploring an interchain MEV auction where MEV from many chains could be traded on the Hub, and Skip is involved in those discussions (the Zerocap research noted IBC’s planned interchain scheduler). Skip’s tech could serve as the backbone for such cross-chain auctions because it’s already doing auctions on single chains. That would be analogous to SUAVE’s cross-domain goal but within Cosmos. As for key updates: Skip launched around mid-2022. By mid-2023, they had a stable POB release for SDK v0.47+ (which many chains upgrading to). They raised seed funding as well, indicating active development. Another competitor in Cosmos, Mekatek, offers similar functionality. This has perhaps accelerated Skip’s roadmap to keep ahead. Skip continues to refine features like private transaction lanes (maybe for hide-your-tx until included) and more complex validity rules as use cases arise. Because it’s modular, a chain like dYdX (which will have an orderbook) might use Skip to ensure fairness in order matching on-chain, etc., so Skip’s tools might adapt to different app logic. Technically, Skip’s solution is simpler than building a whole new chain: it’s upgrading existing chains’ capabilities. This incremental, opt-in approach has allowed fairly quick adoption – e.g., enabling auctions on Osmosis did not require a new consensus algorithm, just adding a module and coordinating validators to run the updated software (which they did, since it was beneficial and passed by governance). In summary, Skip’s architecture is embedded in each chain’s node software, customizing the mempool and block proposal pipeline. It’s a pragmatic engineering approach to fair ordering: use what’s already there (Tendermint BFT), add logic to guide it. The heavy lifting (like finding arbitrages) can even be done by the chain’s own module (ProtoRev uses Osmosis’ built-in Wasm and Rust code to scan pools). So a lot of MEV handling moves on-chain. This on-chain approach does have to be carefully coded for efficiency and security, but it’s under the community’s scrutiny. If any rule is problematic (too strict, etc.), governance can tweak it. Thus, technically and socially, Skip turns MEV into just another parameter of the chain to be optimized and governed, rather than a wild west. This is a unique stance enabled by Cosmos’s flexibility.

Comparative Analysis of SUAVE, Anoma, Skip, and Flashbots v2

These four protocols approach the MEV and fair ordering problem from different angles, tailored to their respective ecosystems and design philosophies. Flashbots v2 is an incremental, pragmatic solution for Ethereum’s current architecture: it embraces MEV auctions but tries to democratize and soften their impact (via off-chain coordination, SGX privacy, and sharing mechanisms). SUAVE is Flashbots’ forward-looking plan to create an inter-chain MEV platform that maximizes total value and user benefits – essentially scaling the auction model to a decentralized, privacy-preserving global network. Anoma is a ground-up reimagining of how transactions are formulated and executed, aiming to eliminate the root causes of unfair ordering by using intents, solver-mediated matching, and cryptographic fairness in consensus. Skip is a sovereign chain approach, integrating fairness and MEV capture at the protocol level on a per-chain basis, especially in Cosmos, through configurable rules and auctions.

Each has strengths and trade-offs:

• Fairness and Ordering Guarantees: Anoma offers the strongest theoretical fairness (no frontrunning by design, encrypted batches), but it requires a new paradigm and complex tech which is still being proven. Skip can enforce concrete fairness rules on existing chains (preventing front-runs or enforcing first-in-first-out within lanes) but is limited by what each community chooses to enforce. SUAVE and Flashbots v2 improve fairness in terms of access (open auctions rather than secret deals, protection from public mempool sniping), but they do not inherently prevent a determined MEV strategy from executing – they just make sure it pays the users or is done neutrally.
• MEV Redistribution: SUAVE and Flashbots explicitly aim to give MEV “back” to users/validators: SUAVE via user bids/refunds, Flashbots via builder competitions and refunds. Skip can channel MEV to users (as configured, e.g. Astroport’s case) or to community funds. Anoma avoids explicit redistribution because the goal is to avoid extraction in the first place – ideally users just get fair prices, which is equivalent to not losing value to MEV.
• Scope (Single vs Multi-domain): Flashbots v2 and Skip focus on their own domains (Ethereum and individual Cosmos chains respectively). SUAVE is inherently multi-domain – it sees cross-chain MEV as a major motivation. Anoma also eventually considers multi-chain intents, but in initial phases it might be within one fractal instance at a time, then bridging out via adapters. SUAVE’s cross-chain auction could unlock arbitrage and coordination that others can’t do as easily (except maybe an Interchain Scheduler with Skip’s help in Cosmos).
• Complexity and Adoption: Flashbots v2 was relatively easy to adopt (a client sidecar) and quickly captured the majority of Ethereum blocks. Skip also leverages existing tech and is seeing adoption in Cosmos with straightforward governance proposals. SUAVE and Anoma are more revolutionary – they require new networks or major changes. SUAVE’s challenge will be getting many chains and users to opt in to a new layer; Anoma’s challenge is creating a new ecosystem and convincing developers to build in an intent-centric model.
• Compliance and Neutrality: All four offer improvements in transparency. Flashbots v2/SUAVE remove dark forest elements but have had to manage censorship issues – SUAVE is explicitly being built to avoid those central points. Anoma, with privacy by default, maximally protects users (but might concern regulators due to encrypted activity). Skip’s model gives each chain autonomy to strike a compliance trade-off. If a regulator demanded “no MEV auctions” or “no privacy”, an Ethereum using Flashbots might face conflict, whereas a Cosmos chain using Skip could simply not implement those features or adjust them. In terms of neutrality: SUAVE and Anoma aim for credible neutrality (everyone accesses one system on equal terms; both are essentially public goods networks). Flashbots v2 is neutral in offering open access, but some centralization exists in builder market (though mitigated by buildernet efforts). Skip’s neutrality depends on governance – ideally it makes MEV not favor any single insider, but one could configure it poorly and harm neutrality (though unlikely as it’d require governance consensus to do so).
• Technical Architecture Differences: Flashbots v2 and SUAVE are off-chain marketplaces layered on chain: they introduce specialized roles (builders, relays, executors) and use hardware or cryptography to secure them. Anoma and Skip integrate directly into the consensus or state machine. Anoma alters the transaction lifecycle and consensus itself (with threshold encryption and unified intents). Skip hooks into consensus of Tendermint via ABCI++ but doesn’t change the fundamental algorithm – it’s an application-layer tweak. This difference means SUAVE/Flashbots can theoretically serve many chains without each chain upgrading (they run in parallel to them), whereas Anoma/Skip require each chain or instance to use the new software. SUAVE is somewhat middle: it’s a separate chain but to use it effectively, other chains need minor adjustments (to accept SUAVE-built blocks or output to SUAVE). The cryptographic sophistication is highest in Anoma (ZK, MPC, threshold crypto all in one), moderate in SUAVE (threshold crypto and SGX, plus normal crypto for bridging), and relatively low in Flashbots v2 (SGX, standard signatures) and Skip (mainly standard signatures, plus whatever the chain uses like threshold decryption if opted).
• Development Stage: Flashbots v2 is in production on Ethereum (since Sep 2022). Skip is in production on multiple Cosmos chains (2022–2023 onward). SUAVE is in testnet/devnet phase with parts rolling out (some auction functionality in testing, testnet Toliman live). Anoma is also in testnet phase (a vision paper, partial implementations like Namada mainnet, and likely an Anoma testnet requiring invite codes in 2023). So in terms of real-world data: Flashbots v2 and Skip have demonstrated results (e.g., Flashbots v2 delivered millions to validators and lowered average gas prices during high MEV periods; Skip’s ProtoRev made significant funds for Osmosis community and prevented many sandwich attacks as threshold encryption began). SUAVE and Anoma are promising but have to prove themselves operationally and economically.

To crystallize these comparisons, the table below summarizes key aspects of each protocol side-by-side:

Protocol	Transaction Ordering	MEV Mechanism (Suppress vs Extract)	Economic Incentives (Alignment)	Compliance & Neutrality	Architecture & Tech	Development Status
Flashbots v2 (Ethereum)	Off-chain builder auctions decide block ordering (PBS via MEV-Boost). Public mempool transactions bypassed for private bundles. Ordering is profit-driven (highest-paying bundle first).	Extracts MEV via sealed-bid block auctions, but mitigates harmful side-effects (no gas wars, no public frontrunning). Provides private tx submission (Flashbots Protect) to suppress user-visible MEV like direct frontrunning. Censorship resistance improving through multi-relay & builder decentralization.	Validators maximize revenue by outsourcing blocks (earn highest bids). Searchers compete away profits to win inclusion (most MEV paid to validators). Builders earn a margin if any. Emerging refunds share MEV with users (via BuilderNet). Incentives favor open competition over exclusive deals.	Initially faced OFAC censorship (central relay) but moved to multiple relays and open-source builders. Now pursuing credible neutrality: BuilderNet’s TEE network ensures no single builder can censor. Overall more transparent than mempool, but still reliant on off-chain entities (relays).	Off-chain marketplace integrated with Ethereum PoS. Utilizes Trusted HW (SGX) for private orderflow in BuilderNet. No consensus change on L1; uses standard builder API. Heavy on engineering (sidecar clients, relays) but light on new cryptography.	Production on Ethereum mainnet (since Sep 2022). >90% of blocks via MEV-Boost. Continual upgrades: open-sourced builder, BuilderNet alpha live (late 2024). Proven stable, with ongoing decentralization efforts.
SUAVE (Flashbots’ next-gen)	Unified cross-chain mempool of preferences (user intents + bids). Executors form optimal tx bundles from these. Decentralized sequencing – SUAVE outputs ordered block fragments to domains. Ordering based on user bids & global welfare (not simple FIFO or gas). Privacy (encryption) prevents order manipulation until execution.	Suppresses “bad MEV” by returning MEV to users: e.g. orderflow auctions pay users for being backrun. Aggregates “good MEV” (like cross-domain arbs) for maximal extraction, but redistributes to users/validators. Uses encrypted mempool & collaborative blockbuilding to prevent frontrunning and exclusive access.	Users post preferences with payable bids; competing executors earn the bid by fulfilling user’s goal. Validators of each chain get higher fees due to optimal blocks and cross-chain MEV capture. SUAVE’s own validators earn network fees. Design pushes MEV profit to users and validators, minimizing searcher rent. Flashbots aims to remain just a facilitator.	Built for credible neutrality: a neutral public platform not controlled by any single actor. Privacy-first (transactions encrypted in SGX or via cryptography) means no entity can censor based on content. Hopes to avoid any Flashbots trust requirement by progressive decentralization. Compliance is not explicitly built-in, but neutrality and global reach are prioritized (could face regulatory questions on privacy).	Independent chain (EVM-compatible) for preferences & auctions. Uses Intel SGX enclaves extensively (for private mempool and collaborative block building). Plans to introduce threshold encryption and MPC to eliminate trusted hardware. Essentially a blockchain + secure compute layer on top of others.	In development – Centauri testnet phase active (devnet, basic auctions). Open-sourced SUAVE client (Aug 2023); Toliman testnet launched for community testing. Mainnet not yet live (expected in phases: Andromeda, Helios). Ambitious roadmap, unproven at scale yet.
Anoma (Intent-centric protocol)	No conventional mempool; users broadcast intents (desired outcomes). Solvers gather intents and produce matched transactions. Uses threshold encryption of transactions so validators order them without seeing content, preventing reactive MEV. Often employs batch processing (e.g. decrypt and match intents in batches every N blocks) for fair pricing. Consensus ensures order commitments before reveal, achieving order-fairness.	Strong MEV mitigation by design: Frontrunning impossible (transactions revealed only after ordering final). Batch auctions eliminate priority advantages (e.g. all trades in batch share clearing price). Solvers compete to fill intents, which drives prices toward user-optimal, leaving little MEV. Essentially minimizes extractable value – any necessary arbitrage is done as part of matching, not by outsiders.	Solvers earn fees or spreads for finding matches (akin to DEX aggregators), but competition forces them to deliver best deals to users. Validators get fees and stake rewards; they also ensure fair execution (no extra MEV via consensus). Users gain via better execution (they only trade at fair prices, not losing value to MEV). Value that would be MEV is retained by users or protocol (or shared minimally with solvers as a service fee). The architecture aligns incentives for honest participation (solvers and validators are rewarded for facilitating trades, not exploiting them).	Privacy and fairness are core – intents can be partially or fully shielded (with ZK proofs), protecting user data. Censorship-resistance: validators can’t selectively censor what they can’t see (encrypted tx) and must follow algorithmic matching rules. Highly neutral – all intents are treated by the same matching logic. Regulatory compliance isn’t baked in (strong privacy might be challenging for KYC), but intent framework could allow compliant designs at application layer.	New blockchain architecture. Uses BFT consensus with integrated intent gossip & solver layer. Relies on threshold cryptography (Ferveo) for mempool privacy and ZK SNARKs (Taiga) for data privacy. Execution is guided by validity predicates (application-specific logic enforcing fair outcomes). Interoperable via IBC (multi-chain intents possible in future). Very advanced cryptographically (encryption, ZK, MPC concepts combined).	Testnets and partial launches. Anoma’s first testnet Feigenbaum (Nov 2021) demonstrated basic intent matching. Many concepts are implemented in stages; e.g. Namada (2023) launched with Anoma’s privacy tech and Ferveo on a single-chain use-case. The full Anoma L1 with intents is in testnet (invite-only tests mid-2023). Mainnet Phase 1 (planned) will target Ethereum integration; native token and full consensus later. Still under heavy R&D, not yet battle-tested.
Skip Protocol (Cosmos)	In-protocol transaction ordering rules and block lanes configured by each chain’s governance. E.g. auctions determine top-of-block order, then default transactions, etc. Consensus-enforced: validators reject blocks that violate ordering (like an invalid tx sequence). Allows custom policies (order by gas price, include oracle tx first, disallow certain patterns) – effectively deterministic ordering algorithms chosen by the chain.	Hybrid approach – extracts MEV in controlled ways (via on-chain auctions and protocol-owned arbitrage) while suppressing malicious MEV (via rule enforcement). Frontrunning can be outlawed by chain rules. Backrunning/arbitrage can be internalized: e.g. chain does its own arbitrage (ProtoRev) and shares revenue. Blockspace auctions (Skip Select) let searchers bid for priority, so MEV is captured transparently and often redistributed. Overall, negative MEV (sandwiches, etc.) is curtailed, while “positive MEV” (arbs, liquidations) is harnessed for the chain’s benefit.	Validators gain a new revenue stream from auction fees or protocol-captured MEV without breaking consensus rules. Risk of individual rogue MEV is reduced (must follow rules or block is invalid), aligning validators collectively. Chain/community can direct MEV revenue (e.g. to stakers or community fund). Searchers must compete via auctions, often giving up part of profit to chain/validators. Some MEV roles are subsumed by on-chain modules (so searchers have fewer easy wins). Users benefit from fewer attacks and can even receive MEV rebates (e.g. Astroport shares MEV with traders). Incentives become community-aligned – MEV is treated as public revenue or not allowed at all if harmful, rather than private profit.	Sovereign compliance: each chain chooses its policy. This means a chain could enforce strict anti-MEV, or include KYC requirements if needed, via module configuration. Skip’s transparency (on-chain bids) and governance control improve legitimacy. It inherently increases censorship-resistance within each chain’s chosen rules – e.g. if rule says “always include Oracle tx”, a censoring validator can’t omit it. But if a chain decided to censor (by rule), Skip could enforce that too. Generally, Skip promotes transparency and fairness as determined by the community. No single entity (like a relay) controls ordering – it’s in protocol and open source.	Cosmos SDK modules (Protocol-Owned Builder) added to node software. Uses ABCI++ hooks for custom block assembly and validation. Implements on-chain auctions (contracts or modules handle bidding and payouts). No specialized cryptography by default (beyond standard Cosmos tech), but compatible with threshold encryption – e.g. Osmosis added encrypted mempool with Skip in mind. Essentially, an extension of Tendermint BFT that adds MEV-aware logic in block proposal. Lightweight for chains to adopt (just module integration, no new consensus protocol).	Live on multiple chains. Skip’s auction and builder module deployed on Osmosis (2023) – ProtoRev module yielded protocol revenue and auctions live for top-of-block. Used on Terra/Astroport, Juno, etc., and being considered by Cosmos Hub. Code is open-source and evolving (v1 of POB for SDK 0.47+). Proven in production with real MEV captured and distributed. Continues to roll out features (e.g. new lane types) and onboard chains.

Each solution targets the MEV problem from a different layer – Flashbots v2 works around L1 consensus, SUAVE proposes a new L1.5 layer, Anoma redesigns the L1 itself, and Skip leverages modular L1 customization. In practice, these approaches are not mutually exclusive and could even complement each other (for instance, a Cosmos chain could use Skip internally and also send intents to SUAVE for cross-chain MEV, or Ethereum might implement some Anoma-like order-fairness in the future while still using Flashbots for builder markets). The table illustrates their comparative properties: Flashbots v2 is already delivering improvements on Ethereum but still extracts MEV (just more equitably and efficiently); SUAVE aims for a maximal synergy outcome where everyone cooperates through one network – its success will depend on broad adoption and technical delivery of promised privacy and decentralization; Anoma offers perhaps the most powerful MEV repression by changing how transactions work entirely, but it faces the steep challenge of bootstrapping a new ecosystem and proving its complex protocol; Skip strikes a pragmatic balance for Cosmos, letting communities actively govern MEV and fairness on their own terms – it’s less radical than Anoma but more embedded than Flashbots, and is already showing tangible results in Cosmos.

Conclusion and Outlook

MEV suppression and fair ordering remain one of the “Millennium Prize Problems of crypto”. The four protocols analyzed – Flashbots v2, SUAVE, Anoma, and Skip – represent a spectrum of solutions: from immediate mitigations in existing frameworks to total paradigm shifts in transaction processing. Flashbots v2 has demonstrated the power of open MEV markets to reduce chaos and redistribute value, albeit while navigating trade-offs like censorship which are being addressed via decentralization. It shows that incremental changes (like PBS auctions and private mempools) can significantly reduce the pain of MEV in the short term. SUAVE, Flashbots’ next step, carries that ethos forward into a unified cross-chain arena – if it succeeds, we might see a future where users routinely get paid for the MEV their trades create and where block production across many networks is collaborative and encrypted for fairness. Anoma points to a more fundamental evolution: by removing the concept of priority transactions and replacing it with an intent matchmaking system, it could eliminate entire classes of MEV and unlock more expressive financial dApps. Its fair ordering at the consensus layer (via threshold encryption and batch auctions) is a glimpse of how blockchains themselves can provide fairness guarantees, not just off-chain add-ons. Skip Protocol, meanwhile, exemplifies a middle ground in a multi-chain context – it gives individual chains the agency to decide how to balance MEV revenue and user protection. Its early adoption in Cosmos shows that many of MEV’s ill effects can be tackled today with thoughtful protocol engineering and community consent.

Going forward, we can expect cross-pollination of ideas: Ethereum researchers are studying order-fair consensus and threshold encryption (inspired by projects like Anoma and Osmo’s encrypted mempool) for potential inclusion in L1 or L2 solutions. Flashbots’ SUAVE might interface with Cosmos chains (perhaps even via Skip) as it seeks to be chain-agnostic. Anoma’s intent concept could influence application design even on traditional platforms (e.g., CoW Swap on Ethereum already uses a solver model; one can view it as an “Anoma-like” dApp). Skip’s success may encourage other ecosystems (Polkadot, Solana etc.) to adopt similar in-protocol MEV controls. A key theme is economic alignment – all these protocols strive to align the incentives of those securing the network with the welfare of users, so that exploiting users is not profitable or not possible. This is crucial for the long-term health of blockchain ecosystems and to avoid centralization.

In summary, SUAVE, Anoma, Skip, and Flashbots v2 each contribute pieces of the puzzle toward fair ordering and MEV mitigation. Flashbots v2 has set a template for MEV auctions that others emulate, Skip has proven that on-chain enforcement is viable, Anoma has expanded the imagination of what’s possible by rebuilding the transaction model, and SUAVE seeks to unify and decentralize the gains of the past years. The ultimate solution may involve elements of all: privacy-preserving global auctions, intent-centric user interfaces, chain-level fairness rules, and collaborative block building. As of 2025, the fight against MEV-induced unfairness is well underway – these protocols are turning MEV from a dark inevitability into a managed, even productive, part of the crypto economy, while inching closer to the ideal of “the best execution for users with the most decentralized infrastructure”.