Joint work by Finn Casey Fierro & Conor McMenamin, both Nethermind.
This is the first of a series of articles on the Economic Viability of Preconfirmations, a project which has received funding from a Lido LEGO grant. In this article, we take the first step towards understanding the economic feasibility of preconfirmations. Our analysis applies to preconfirmations on any blockchain, although we base our analysis on data sourced from Ethereum L1.
Our analysis identifies a wide gap between current proposer revenues and the expected revenue from offering preconfirmations through independent sub-slot auctions, the latter being 26% of the former. This in line with Vitalikâs hypothesis that âproposers have an incentive to maximize their optionality as long as possibleâ. Still, hope remains for preconfirmations. The identified additional revenue needed from preconfirmation tips for this class of preconfirmation protocol is low in absolute terms for a low latency global system which preconfirmation enables, at ~0.075 ETH needed in tips per slot.
More than this, there is another class of preconfirmation protocol that is not analysed below, the conveniently named âdependent sub-slot auctionsâ. Later in this research series, we will present these dependent sub-slot auctions and demonstrate that they can increase the expected revenue of proposers, albeit with tradeoffs. Watch this space!
Many thanks Lin Oshitani, Michal Zajac, and Swapnil Raj for their reviews and comments.
Introduction / TL;DR
- We introduce independent sub-slot auctions (ISSAs) as a classification of preconfirmation protocol that represents many of the preconfirmation protocols in use today, e.g. Jito, Polygon PoS, Optimism. ISSAs result in sub-blocks being built at intervals throughout a proposerâs proposal slot. These sub-blocks are selected by the proposer according to an auction mechanism, such as Flashbotsâ MEV-Boost or a priority gas auction.
- Taking Ethereum block and transaction data, we investigate how an Ethereum proposerâs revenue is expected to change when moving from the current MEV-Boost paradigm for block building; 1-slot, 1 block, to the preconfirmation paradigm described by ISSAs; 1-slot, many-(sub-)blocks.
- We demonstrate that without preconfirmation-specific fees, preconfirmations through ISSAs significantly reduce a proposerâs revenue. Our analysis estimates this reduction to tend towards 74% as the number of sub-slots increases, summarized in the graph below. This corresponds precisely to the amount of preconfirmation-specific fees that this type of preconfirmation protocol needs to generate to become economically viable. We observe an average proposer rewards of 0.164 ETH in our dataset, which would at its worst (continuous preconfirmations) reduce to 0.042 ETH per block, requiring at maximum 0.121 ETH per block as inclusion tip compensation.
Figure 0. Expected Proposer Rewards per Ethereum slot as a % of average block rewards, and required preconfirmation tip to compensate for change in proposer revenue.
Organisation of the article
We start by introducing what we mean by independent sub-slot auctions. We provide a Preliminaries section describing model assumptions as well as a description of the data we use to create our proposer reward model. We then outline our classification of proposer revenues, followed by a section on how we model these revenues changing with the introduction of sub-slots. The proceeding Results section presents our models for each classification of revenue, which combine to provide the results highlighted in the TL;DR section. We then conclude, and discuss avenues for future work.
Independent Sub-Slot Auctions
In this article, we focus on an intuitive and seemingly viable subset of preconfirmation protocols which we term independent sub-slot auctions (ISSAs). In an ISSA, the proposer for a blockchain slot holds auctions among block builders to build sub-blocks at intervals (sub-slots) throughout the slot in question. These sub-blocks are then concatenated and proposed as a block for consensus at the end of the slot.
Importantly, the builders competing in the sub-slot auctions to build sub-blocks know that the proposer retains the right to propose the remaining part of the block throughout the remainder of the slot. More than this, we also assume the proposers are low-resource and do not participate in sub-slot auctions themselves. Given these independent sub-slot auctions, all builders=bidders in each auction are trying to maximise the value of the respective sub-block for themselves, without consideration for how this affects the value of proceeding sub-blocks.
ISSAs come in many flavours. The most relevant examples of ISSAs with respect to opting in to preconfirmations are Jitoâs partial block auctions, an opt-in auction mechanism that splits a Solana block into ordered sub-blocks, and multi-round MEV Boost, a theoretical representation of ISSAs. That being said, any blockchain where a single proposer proposes multiple blocks/sub-blocks/batches in a row and is trusted to run independent auctions at each update interval to determine transaction execution can be considered examples of ISSAs. This extended definition applies to Polygon PoS (with e.g. Fastlane), Optimism Superchain, and beyond.
Multi-Round MEV Boost
For the purposes of this document, when discussing ISSAs, we focus on the well-defined multi-round MEV Boost (MR-MEV) as it neatly represents the broader class of ISSAs as specified in the previous section. MR-MEV is described as follows (for a more detailed description and discussion see the original post on MR-MEV).
During each sub-slot of MR-MEV, the proposer conducts a MEV Boost auction through relayers, amongst competing builders to build a sub-block. At the end of each sub-slot, the proposer signs and broadcasts the winning sub-block for that sub-slot. Any transactions included in the winning sub-block are considered preconfirmed. At the end of the Ethereum slot, a block is published adhering to the sequence of sub-blocks that were preconfirmed by the proposer. Indeed, in user-experience terms, MR-MEV is comparable to reducing block times on the base layer of Ethereum.
Although ISSAs are free to choose their own auction at each sub-slot, we believe the magnitude of economic consequences from opting into MR-MEV applies to all ISSAs. For this reason, we focus on MR-MEVâs design when referring to ISSAs.
Preliminaries
Given this broader class of ISSAs, we analyse how current proposer rewards would change if the proposer engaged in offering preconfirmations through ISSAs.
To do this, we first break down proposer rewards into their distinct components, creating a classification of total rewards by sub-category. For each component, we develop a specific model to analyse how these rewards would scale when divided into sub-blocks.
Assumptions
In our analysis, we make the following assumptions:
- Perfect competition among builders in the market.
- Constant base fee per gas throughout the analysis. In reality, if more transactions are being executed as a result of sub-slots, this assumption must be revisited.
We also make assumptions regarding how revenue types scale as the time between sub-slot auctions increase. These assumptions are specified in the respective sections describing each revenue type.
The Data
Our data comes from Brontes, a blockchain analytics tool developed by Sorella Labs. Brontes transforms raw Ethereum black data into a structured, analyzable format, which it then uses to identify various types of MEV (Maximum Extractable Value) transactions including CEX-DEX Arbitrage, Sandwich Attacks, Atomic Arbitrage, JIT Liquidity, Liquidations, and Searcher âUnclassifiedâ transactions. Their tool outputs both transaction and block-level data, which can be converted to parquet format for our analysis.
Our analysis specifically focuses on different types of MEV transactions, examining coinbase transfer values, priority tips, and final builder transfers to assess the value generated by each MEV category. We analyze data provided by Brontes spanning blocks 20000001 to 20604799, covering the period from June 1st, 2024 to August 25th, 2024.
Brontesâ data has a limitation in how it identifies CEX-DEX transactions - it only looks at trading patterns between centralised and decentralised exchanges, missing important details about where transactions originate and their placement within blocks. To fix this gap, we use a modified version of Danningâs Flashbots method, which identifies CEX-DEX arbitrage based on stricter criteria. For a transaction to qualify, it must: appear in the first 10% of a block, include a hedged swap, have either a non-zero coinbase payment or connected transactions with positive fees from the same sender, be the first swap in its pool, avoid retail routers, and involve exactly two ERC20 token transfers. Applying Flashbots criteria to transactions that Brontes had marked as âUnclassifiedâ, we identified additional CEX-DEX arbitrage trades that were previously overlooked.
Classifying Proposer Rewards
Towards modelling proposer rewards and how rewards change with the addition of sub-slot auctions, we must first classify the components of proposer rewards. With a proposer classification of proposer reward components, we can then more accurately estimate how each of these components change in the presence of ISSAs.
When selected as block proposer, a validator gains temporary but complete control over block proposal, including which transactions to include and their ordering. This brief period of transaction control introduces whatâs known as Maximal Extractable Value (MEV) - representing the additional value a proposer can extract from their block proposal privileges, beyond the standard block rewards and priority fees.
Modern MEV strategies are highly complex and resource-intensive to compute and capture. In response to this, Flashbots developed MEV-Boost, which allows proposers to outsource block building to a set of specialised builders through an auction run by a trusted intermediary known as a relayer. MEV-Boost has seen widespread adoption, with over 90% of Ethereum proposers now using MEV-Boost to outsource block-building.
The total proposer rewards per block \Pi can be expressed as the sum of the following components:
with:
- \Pi_{\text{CEX-DEX}}: Rewards from CEX-DEX Arbitrage.
- \Pi_{\text{SA}}: Rewards from Sandwich Attacks.
- \Pi_{\text{AA}}: Rewards from Atomic Arbitrage.
- \Pi_{\text{JIT}}: Rewards from Just-In-Time (JIT) Sandwich Attacks.
- \Pi_{\text{LM}}: Rewards from Liquidation MEV.
- \Pi_{\text{CPLX}}: Rewards from Complex MEV strategies.
- \Pi_{\text{RMDR}}: Rewards from the remainder, we suppose these are those of user wallet transactions and transactions not related to MEV.
Each of these components are paid to the proposer through priority fees, direct transaction transfers (coinbase transfers), and portions of the final block payment from the builder to the proposer. Each component is described in more detail in the Results section.
We are interested in how these components change when we move to sub-slots and sub-blocks as in ISSAs. When considering sub-blocks, our goal is to model the rewards \Pi_i(s) for each MEV activity i as a function of the number of splits s in the full block, where the block is divided into a corresponding s+1 sub-blocks, before summing all these component models to receive an overarching model for total proposer rewards for s splits:
Here, the observed of proposer rewards \Pi in the previous equation is equivalent to \Pi(0), where zero splits occur. To analyse how these rewards change as a function of s, we define or estimate the specific form of how \Pi_{i}(s) changes with relationship to s. This could involve empirical analysis, theoretical application or simulation based on historical blockchain data. The scaling of each component in our analysis falls into one of the following two categories:
- Constant: For completeness, we retain the case where the reward is unaffected by the splitting. In this case, \Pi_{\text{i}}(s) would remain constant i.e \Pi_{\text{i}}(s) = \Pi_{\text{i}}(0).
- Sub-additive Scaling: \Pi_{\text{i}}(s) is described by a concave function, such as \Pi_{\text{i}}(s) = \Pi_{\text{i}}(0) \cdot log(1 + \alpha_i \cdot s) , where \alpha_i represents the scaling factor. This reflects diminishing proposer rewards as the number of sub-blocks increases.
An Iterative Methodology for Sub-Block Reward Scaling
The following section introduces a methodology that examines for any amount of splits, the total proposer rewards for a block as the sum of all executed MEV within the sub-blocks that comprise it.
Modelling Proposer Rewards from the Builders Perspective
Looking ahead to our model for proposer rewards, for each strategy i, our data enables us to model gas cost for each strategy, as well as the revenue that the builder can generate from that strategy ignoring gas costs. This section guides steps through how we were first able to isolate builder revenue from on-chain data, and then use this to predict how proposer rewards change under sub-slots.
For a particular strategy i, \gamma the average priority fee per gas unit, g_{i} the average gas consumed executing strategy , b the average base fee per gas unit, and c_{i} the average coinbase transfer made. Under this terminology, the proposer revenue can be expressed as:
Both of these variables we have available in our data. However, we still need to isolate builder revenue from this representation, as this is the variable that we can accurately model. We let let R_{i} be the builder revenue generated for a particular strategy i. From the builderâs perspective, the builderâs profit can be expressed as P_i= R_{\text{i}} - (\Pi_{i}+ b \cdot g_{i}), that is, builder profit equals builderâs revenue minus the amount that must be paid as gas and proposer rewards. Under our perfect builder competition assumption from the Preliminaries section, the profit of the winning builder must be 0. Setting P = 0, we are left with the following representation of proposer rewards for each strategy:
This is a representation we can work with, as the gas needed to execute each strategy is fixed in expectation each time the strategy is executed. However, to calculate \Pi_{i}(s), we need to examine how the revenue component scales with the introduction of sub-slots, and how this affects proposer rewards. This is the focus of the next subsection.
Algorithm for Calculating Proposer Rewards with Sub-Slots
When considering proposer rewards over s splits (s+1 sub-slots), we cannot simply sum over s+1 scaled down builder revenue numbers minus the gas cost for that strategy. As s grows larger, builder revenue per subslot would tend to 0, while the total gas cost would grow linearly in s. This approaches negative infinity proposer rewards, and is clearly wrong. In our model, we take a more realistic approach (almost anything is more realistic than negative infinity).
For a specific strategy i, builders let revenue R_{\text{i}}() accumulate in sub-slots where the strategy is not executed until it reaches a sub-slot where the accumulated revenue for the strategy is greater than the cost to execute, and then execute. For a given number of splits s, and some quantity of sub-slots 1 \leq \tau \leq s+1, we introduce a function R_i(s, \tau) to track the accumulated exepcted revenue of strategy i given \tau sub-slots since the last time strategy i was executed. R_i(s, \tau) can then be defined as follows:
- Non-CEX-DEX MEV transactions. We model arrival of these opportunities (and subsequently revenue) as a Poisson process, following Auer, Farina, and Frost identification of blockchain transactions following a random, independent nature. The process is characterised by a constant rate λ and follows the probability distribution P(N(t) = k) = \frac{(λt)^k}{k!} \cdot e^{-λt} for observing k events in time t. For a block split into s splits (resulting in s+1 sub-blocks), the the expected revenue of each sub-slot is the same, with the sum over s+1 sub-slots being that of the expected revenue of the entire slot, R_i(0). The revenue for Ï of these subblocks is therefore:
-
CEX-DEX transactions. We adopt the approach of Milionisâs Loss-Vs-Rebalancing model in the presence of fees. In this case, revenue in a sub-block scales with the number of sub-blocks raised to the power of 1.5.
R_{CEX-DEX}(s, Ï) = \frac{{R_{CEX-DEX}}(0)}{(\frac{s+1}{Ï})^{\frac{3}{2}}}.
For a given i \text{ and } s, \Pi_{\text{i}}(s) can then be recursively defined as follows:
Initialize \Pi_{\text{i}}(s)=0, \tau=1.
For x \in [1,...,s+1]:
- If R_i (s,Ï )-b \cdot g_i >0, then:
- \Pi_{\text{i}}(s)=\Pi_{\text{i}}(s)+ R_i (s,Ï )-b \cdot g_i .
- \tau=1.
- else: \tau=\tau+1.
After simulation to calculate the proposer rewards \Pi_{\text{i}}(s) for discrete values of s, where possible we fit an appropriate continuous model to approximate the \Pi_{\text{i}}(s) . This continuous form approximation is used in finding a final form of the proposer rewards as a function of how all components change with splits s, \Pi(s).
Results
This section highlights observed trends in proposer revenue from our data, as well as the predicted trends according to our models.
Average Proposer Rewards for each Revenue Class
Our analysis of expected proposer rewards under sub-block pre-confirmations begins by examining observed total rewards and its distribution across different MEV types with zero splits, corresponding to \Pi(0) . The following figure shows the average percentage breakdown of these MEV categories throughout our observation period.
Figure 1. Proposer Rewards Breakdown Pie Chart
Table 1. Proposer Rewards Breakdown
Figure 2. Proposer Rewards Breakdown Per Day
As discussed, proposer rewards consist of three components: priority tips, individual coinbase transfers within transactions, and final builder payments to the proposer. Since final builder payments can be viewed as compensation for transactions with zero priority fees and zero coinbase payments, we assume their MEV distribution mirrors that of transactions with classified MEV (identified through non-zero priority fees and coinbase payments) and haved allocated them proportionally across our identified MEV categories.
We observe an average proposer reward of \Pi=0.1640 ETH, with MEV activities dominating proposer rewards at 74.35% of the total (with CEX-DEX arbitrage leading at 24.45%, followed by Sandwich attacks at 15.08%, Atomic Arbitrage at 9.40%, Complex strategies at 21.1%, and Just-In-Time Sandwich attacks at 3.97%), while the Remainder accounts for 25.65%. These average composition values \Pi_i (0) serve as initial parameters for subsequent simulations.
Remainder
We define a Remainder category for transactions that donât fit into our classified MEV categories, calculated by subtracting all classified MEV rewards from total proposer rewards, which likely represents ordinary user transactions.
Remainder transactions require no MEV attack transactions to capture. From our analysis, Remainder transactions follow an approximate uniform arrival process, to which we can fit a Poisson model. Under this model, we are left with:
In other words, we do not expect subslots to affect proposer rewards from Remainder transactions.
CEX-DEX Arbitrage
CEX-DEX arbitrage refers to the practice of exploiting price discrepancies between centralised exchanges (CEX) and decentralised exchanges (DEX) for profit.
Figure 3. CEX-DEX Proposer Rewards on the number of Sub-Blocks
Our iterative simulated model for CEX-DEX rewards is illustrated in the figure above, using key data points: \Pi_{CEX-DEX} = 0.04 ETH average proposer reward per block (at s=0), b\cdot g_{CEX-DEX}=0.0105 average gas cost per block, resulting in R_{CEX-DEX} (0) =0.0505 ETH the average builder revenue without subslots.
Applying our methodology from the âAlgorithm for Calculating Proposer Rewards with Sub-Slotsâ Section over 40 values of s, we are left with \Pi_{CEX-DEX}(s) described in Figure 4. We then fit an exponential decay function to capture the trend of this simulation:
When transactions are continuously streamed and confirmed (effectively infinite splits), CEX-DEX arbitrage opportunities disappear. This makes sense: any substantial price differences between centralised and decentralised exchanges would be instantly arbitraged away when it arrives, after accounting for swap fees, eliminating the delay in price updates that is used by arbitrageurs.
Sandwich Attacks
Sandwiching âsandwichesâ a victimâs transaction on a DEX between a MEV searcherâs buy and sell orders. Sandwich attackers can sandwich a single transaction, or multiple transactions, from many different pools. As discussed by Richardson, the more victim volume there is within the sandwich, the larger the revenue that is possible.
Figure 4. Sandwich Proposer Rewards on the number of Sub-Blocks
Our iterative model for sandwich rewards is illustrated in the figure above, using key data points: \Pi_{SA} = 0.025 ETH average proposer reward per block (at s=0), and b\cdot g_{SA} = 0.0017 ETH average gas cost per block, resulting in R_{SA}(0) = 0.0264 ETH average predicted revenue. We are then left with an estimate for \Pi_{SA}(s) as described in Figure 4. As in CEX-DEX, we can apply an exponential decay function to capture and describe the overall trend of the simulation.
JIT Sandwich Attacks
Just-In-Time (JIT) Liquidity is an MEV strategy used in concentrated liquidity pools, where traders strategically sandwich large swap transactions by providing and swiftly removing highly concentrated liquidity. This three-step process begins with a front-run of adding focused liquidity at specific price ticks expected to be active during an incoming large swap. The targeted swap then occurs, interacting with this newly provided liquidity. Finally, the trader back-runs by quickly removing their liquidity position post-swap, and collecting the generated fees. This method allows JIT providers to profit from significant trading fees without long-term pool exposure. Notably, JIT Liquidity can be combined with traditional sandwich attacks, creating âJIT Sandwiches.â For the purposes of this research, JIT is considered as the combination of both strategies.
Figure 5. JIT Sandwich Proposer Rewards on the number of Sub-Blocks
Our iterative model for JIT Sandwich rewards is illustrated in the figure above, using these key data points: initial proposer reward \Pi_{JIT} = 0.0065 ETH per block (at s=0), gas cost cost b\cdot g_{JIT} = 0.0023 ETH per block (expectedly higher than traditional sandwich attacks given the additional front-run and back run), corresponding to R_{JIT} = 0.0088 ETH. We are again left with an exponential function describing the trend of the JiT strategy (Figure 5), described as follows:
Atomic Arbitrage
Atomic arbitrage is a trading strategy that exploits price differences between tokens across different liquidity sources. This method involves atomically executing 2 or more buy and sell orders across multiple liquidity sources, locking in a risk-free profit for the executor.
Figure 6. Atomic Arbitrage Proposer Rewards on the number of Sub-Blocks
Our iterative model for Atomic Arbitrage rewards is illustrated in the figure above, using key data points: \Pi_{AA} = 0.0154 ETH average proposer reward per block (at s=0), b\cdot g_{AA} = 0.0047 average gas cost per block, resulting in R_{AA}(0) = 0.0201 ETH average predicted revenue. We fit an exponential decay function to capture the trend of this simulation (Figure 6):
Complex MEV
Brontes has introduced a new category called âSearcherTXâ to classify complex MEV-related transactions that defy standard categorisation. We label these transactions as as âComplexâ, these transactions typically combine various elements such as swaps, mints, and liquidations.
The inherent complexity of these strategies mean we do not have a clear definitive measure of victim, arbitrage or liquidation volume. We therefore make the assumption that the revenue observed scales down linearly, identically to volume. That is, the revenue for the first sub-block of two is equal to half the revenue of a full block.
Figure 7. Complex Proposer Rewards on the number of Sub-Blocks
Our iterative model for Complex MEV proposer rewards is illustrated in the figure above, using key data points: initial proposer reward \Pi_{CMPLX} = 0.0345 ETH per block (at s=0), a substantial gas cost cost of b\cdot g_{CMPLX} = 0.101 ETH per block, resulting in predicted revenue \hat{R}_{CMPLX} = 0.1355 ETH. We can again fit an exponential decay function fitted to our simulation data (Figure 7):
Liquidation MEV
Liquidation MEV arises from opportunities to liquidate under-collateralised positions in DeFi lending protocols like AAVE, Morpho, and Compound.
Liquidation events are almost always triggered by oracle updates, either automated temporally, or when the underlying price of the collateral according the oracle moves in favour of the liquidator. Currently, the most widely used oracle by volume for lending protocols on Ethereum is Chainlink. Without a large price movement that triggers a âdeviation thresholdâ oracle update, price feed Oracles update on the routine of at a most once per hour. For this reason, and given liquidations represent very small proportion of total rewards (0.37%), it would be highly unlikely to observe the case in which two of the same price feed oracle updates enter two different sub-blocks to create twice the liquidation MEV opportunities. Thus, we are left with our modelling of liquidation MEV not depending on time:
Final Proposer Reward Composition
Observing the scaling factors for each of our components, we are left with a final model of:
with:
CEX-DEX arbitrage decays most rapidly with a coefficient of -0.262, followed by complex MEV (-0.2396) and JIT liquidity provision (-0.1677). Atomic arbitrage shows moderate decay (-0.1322), while sandwich attacks have the slowest decay rate (-0.0614). These differences suggest that time-sensitive operations like CEX-DEX arbitrage are most vulnerable to block splitting (while also notably being the largest share of proposer rewards). Liquidations and remainder activities remain resilient to sub-blocks under our model.
To summarise how splits affect total proposer rewards, we take the values from Table 1 and divide total proposer rewards for each split scenario by the baseline rewards (when no splits occur, s=0). By expressing the results as percentages of the original rewards, this normalisation makes it easier to understand how increasing ISSA splits reduces proposer rewards generally.
Figure 8. Expected Proposer Rewards per Ethereum slot as a % of average block rewards, and required Preconfirmation tip to compensate for change in proposer revenue.
From this graph, we can see that at 7 splits (8 * 1.5-second blocks), rewards decrease to approximately 50% of the âno sub-slotsâ value. With continuous preconfirmations (s = â), rewards eventually stabilise at 26.03% of full block proposer rewards, supported entirely by time-independent components, those of Remainder MEV (25.65%) and Liquidation MEV (0.37%). For ISSAs to be economically viable, proposers must receive compensation for this reduction in rewards. The âPreconfirmation Tip Compensationâ curve demonstrates this minimum percentage of current proposer rewards needed as tips to offset these losses.
Conclusion
Under the current MEV & block-building landscape, proposer rewards would significantly decrease with the implementation of ISSAs, dropping to approximately half of their original value with 8 sub-slots, ultimately stabilising at approximately 26% with continuous pre-confirmations, maintained by time-independent components. This reduction of 74% represents the preconfirmation-specific tips that must be generated through ISSAs in order to compensate for proposersâ loss in revenue compared to todayâs block-building revenue.
Potential Avenues for Future Work
We invite other researchers to verify and build upon this work, motivated by our results. Some interesting questions and topics include:
- Are there alternative preconfirmation protocols that do not reduce proposer revenue?
- What factors incentivise proposers to adopt ISSAs to compensate for the loss in revenue that ISSAs cause? Case studies can include e.g. Jito-Solana, Polygon PoS, Optimism, etc.
- How realistic are preconfirmation tips in excess of 74% of current block building revenue?
- We could make a more expressive model to consider competition in the PBS market to better reflect dominant buildersâ profit potential, though measuring actual profits will require careful validation.
- Examine how multiple executions of each MEV strategy through the sub-block approach affects gas fees. Specifically, one could examine their impact on base fee dynamics and market elasticity, considering the feed-back loop that makes sub-block MEV execution less viable.
As part of our LEGO-funded series on economic viability of preconfirmations, Nethermind are actively looking at topics 1 & 2.
Repository Access
We implore further replication and expansions on our findings.
One is required to download from Sorella Labs Rust CLI client, to export their parquet data into the repository, and to run each distinct component processing function at their discretion.
