MEV has become a much-discussed topic in recent years, progressing from a niche area of research to a full-fledged ecosystem and a lucrative source of validator revenue. In the article below, we’ll explore how we leverage MEV to boost staking rewards in Ethereum, what are its implications for stakers, and even understand what exactly is MEV.
First things first, MEV generally stands for “maximum extractable value” and refers to the total amount of economic value that can be gained as a function of the ordering of transactions in a block.
For example, a user may swap a large amount of token A for token B on a decentralized exchange (DEX), affecting the exchange rate between these two assets.
If this rate is then inconsistent with the pricing in the wider market, traders (“searchers”) can take advantage of the imbalance through arbitrage. Intuitively, a trader would be rewarded for committing capital to re-establish efficient pricing.
It is easy to intuit that there are desirable and less desirable forms of MEV.
For example, arbitrages and loan liquidations serve to increase and preserve the integrity of on-chain capital markets. These types of transactions take place after an opportunity has been created, i.e. these are often referred to as “back-running”.
On the flip side, there is a class of transactions characterized as “front-running”. These strategies involve creating or compounding a profit opportunity by submitting a trade before a user transaction hits the chain.
While there are some counter-arguments, most people agree that front-running increases transaction costs for ordinary users, and it is, therefore, less desirable than back-running, which can in theory decrease user transaction costs (e.g. through efficient pricing).
The upshot is that the feasibility of any MEV-type trade is dependent on the ordering of transactions in the block.
Ideally, a searcher would like to trade directly after the opportunity has been created. There are some exceptions to this (i.e. where the opportunity will compound with other transactions), but in any case, there is always an ideal timing for a trade when there’s money on the table. And there are sophisticated actors waiting to exploit these opportunities.
Validators ultimately control the ordering of transactions in a block. As there is always an ideal timing to trade (or the best estimate thereof), searchers are incentivized to bargain with validators to ensure their transactions are placed well.
On Ethereum, this process has been automated via an auction system, spearheaded by the Flashbots team. In this post-Merge, Proof-of-Stake Ethereum world, the main tool to perform these auctions is called “mev-boost”. This is a private communication channel between searchers and validators, which allows the efficient pricing of a block. As a result of this, validators receive “tips” for proposing the most price-efficient block, on a secure commit-reveal scheme.
We have created some tools to decode MEV and ‘mev-boost’ transactions under Proof-of-Stake Ethereum, check our Dune Analytics dashboard.
The higher the network penetration score of an individual validator or group of validators (known or unknown), the more chances it will get to propose blocks, and consequently benefit from a block price auction, which is often a matter of luck. Validators under these conditions are also more likely to be present when particularly lucrative opportunities occur, and so luck turns into opportunity.
This means that a large validator set working together is more likely to generate smooth staking returns, versus a small validator with more irregular windfalls.
For stakers, this process results in additional rewards that are immediately accessible on the Execution Layer of the network — responsible validators share a portion of MEV rewards with stakers.
Volatile markets generate more MEV opportunities through collective price discovery, and various inefficiencies which reveal themselves in unusual conditions. For example, more liquidations if the ETH price drops significantly below what market participants expect.
Therefore, you can expect your staking rewards to go up in conditions of uncertainty.
Profits from on-chain trading can be enormous. For example, the all-time largest MEV arbitrage on Ethereum in June 2022 yielded a gross profit of 2518.5 ETH; of this sum, 74.52 ETH went to the block proposer.
A well-thought-out MEV strategy can boost your staking returns significantly. For example, in March 2023, up to 15% of validator revenues have been derived from MEV so far. At Chorus One, we have experimented with different mev-boost setups and relayers, always working on tweaking our strategy to reach higher levels of efficiency. Moreover, we only charge a small staking commission on all returns, allowing you to keep the vast majority of MEV rewards your validator generates. We wrote about how we view MEV and our policies here: Chorus One’s MEV Policy: Transparency, Sustainability, Reward Optimization.
Optimization of MEV rewards coupled with our performant infrastructure and round-the-clock supervision allows us to deliver highly competitive returns to our delegators, sometimes exceeding other validators by up to 30%. Don’t take our word for it, real-time statistics can be accessed via Rated.
Chorus One is a leading advocate for MEV transparency and efficiency. Our team has been at the forefront of MEV research, actively developing solutions to support the nascent yet rapidly evolving MEV landscape. We have executed MEV-type transactions on both Solana and Cosmos, and our recent release of an open-source MEV-client on Solana demonstrates our commitment to advancing the space. Additionally, our expertise in the MEV domain has been recognized with a grant from dYdX to produce a comprehensive report on MEV for their v4 platform.
Reach out to us at sales@chorus.one to understand more about how our MEV-enabled infrastructure can help you earn superior returns.
About Chorus One
Chorus One is one of the biggest institutional staking providers globally operating infrastructure for 35+ Proof-of-Stake networks including Ethereum, Cosmos, Solana, Avalanche, and Near amongst others. Since 2018, we have been at the forefront of the PoS industry and now offer easy enterprise-grade staking solutions, industry-leading research, and also invest in some of the most cutting-edge protocols through Chorus Ventures. We are a team of over 50 passionate individuals spread throughout the globe who believe in the transformative power of blockchain technology.
For more information, please visit chorus.one
The MEV supply chain is critical to the future performance and business models of the Solana network. Solana is in a phase of actively searching for, and ultimately choosing its MEV supply chain. One approach is to replicate the model established on Ethereum, building a searching and block-building marketplace. This path has multiple downsides, such as artificially introducing a global mempool that would increase Solana’s latency, and may also increase the risk of centralization and censorship.
We’re happy to announce that Chorus One has released a whitepaper today where we contrast the most relevant characteristics of Ethereum and Solana; review some of the features of the block-building marketplace model, i.e “flashbots-like model”, and what retrofitting it onto Solana would entail.
Given the particularities of Solana, we also propose an alternative to the block-building marketplace: the solana-mev client. This model allows for decentralized extraction by validators, through a modified Solana validator client, capable of handling MEV opportunities directly in the banking stage of the validator. Along with the whitepaper, Chorus One is also releasing an open-source prototype implementation of the approach detailed inside the whitepaper itself.
The client can be run by any validator. Even small validators or those with no specific expertise can benefit from MEV rewards by choosing to run the solana-mev client. That means the validators will be able to execute MEV strategies as they appear in their slot, in contrast with the current competitive aspect of searching, which results in a few winner bots extracting the value.
The model shrinks the incentive for independent bots to spam the network which ultimately contributes to episodes of intense traffic, as most of them send transactions targeting the same MEV opportunities.
Given that not all MEV strategies can be implemented inside the validator, independent searchers will continue to play a relevant role in the MEV space on Solana. That is guaranteed by their advantage of quickly building and updating sophisticated strategies, as well as expanding their focus to newly deployed programs and pools. This includes long-tail MEV.
In summary, the MEV client enables permissionless and decentralized extraction that benefits the ecosystem through transparent and ethical strategies, as well as increased financial returns for network participants.
For a comprehensive overview of the motivations and the model, please refer to the whitepaper here.
At Chorus One, we pride ourselves in being a full-stack partner to the protocols we choose to operate and support. This goes beyond the highly available infrastructure we provide to secure and maintain networks. It includes assisting in ecosystem-building via our ventures and business development teams, as well as participating in network governance and — most notably — deep research. Since our inception, we have been at the forefront contributing to core topics of interest in Proof-of-Stake such as liquid staking.
In recent months, we have shifted a big part of our research focus onto a complex topic that underpins the core fabric of any crypto protocol: MEV (Maximal Extractable Value). This emerging field deals with the value that can be extracted through reordering transactions in the block production process. (A collection of resources on MEV can be found here).
MEV has become an ubiquitous topic for many ecosystem participants. Primarily being a validator, our position in the network places us at a spot within the MEV supply chain that comes with great power, thus also great responsibility. Generally speaking, our mission is to maximize freedom for crypto users and to contribute to the creation of long-term sustainable, user-owned decentralized network infrastructure. Since MEV is a crucial domain that — if not adequately dealt with — might threaten the mission we are set towards; we recognized that we should leverage our expertise and resources to contribute to the MEV space in a way that ultimately benefits networks and their users.
The goals we want to contribute towards in the MEV space are two-fold. On one hand, we aim to make visible and help minimize extraction of value from users through e.g. front-running, sandwiching, and other exploitative practices. On the other hand, we strive to redistribute revenues from non-exploitative MEV that comes into existence from market inefficiency to our delegators that contribute security to the underlying network.
The rest of this article lays out the core pillars of our approach to MEV providing examples of our existing and planned engagements in the area.
What is MEV and how does it impact networks and their users?
Before deciding how we should engage with MEV, we seek to understand what we are dealing with. We are proponents of the open-source crypto ethos and don’t want to keep the information we are gathering to ourselves, but rather share it with the wider ecosystem. Thus, the first pillar of our MEV policy is Transparency. We are actively researching, building dashboards, and publishing other materials to create a shared understanding and to help lighten up the “dark forest” that is MEV.
Our exemplary work in the MEV Transparency domain: Dune Analytics Ethereum MEV dashboard, MEV Extraction Twitter bot, various MEV-related articles (e.g. our series on MEV on Solana).
How can we help to minimize negative externalities of MEV?
As a result of our research effort, we deeply understand MEV in the context of the ecosystems we are a part of. We recognize that MEV can pose negative externalities to users and ultimately the protocols they are trying to utilize. We are actively engaging to help minimize negative externalities in various ways, depending on how deep our engagement in the respective ecosystem is. This can include creating awareness and participating in the dialogue around MEV, research on related problems, as well as supporting and building solutions seeking to minimize exploitative MEV and to decentralize MEV extraction.
Our work in the Network Sustainability domain: operating and participating in public discourse and communities of block building solutions such as Flashbots, investments in projects seeking to minimize front-running (including e.g. Anoma and Osmosis). We have additional projects in this domain in the pipeline and are looking into operating infrastructure to help decentralize block building and relayer infrastructure.
How can we optimize and distribute MEV rewards to our delegators?
It would be hypocritical to say we are in this for the good of it only. There are clear incentives associated with engaging in MEV. Practically speaking, we are looking to optimize the return we can achieve through MEV and pass it through to our delegators creating a differentiated service while helping to improve network usability, security, and ultimately sustainability via the first two of our MEV pillars (see also Phil Daian’s early post “MEV wat do?” on this topic).
For institutional clients that want to offer staking to their users, we are happy to assist in navigating the space and finding the optimal solutions as part of our white label staking services.
If you are building in the MEV space, are trying to understand how MEV will affect your protocol, or are interested to work with us on research topics, feel free to reach out to us through the appropriate channels:
Research: research@chorus.one
Ventures: ventures@chorus.one
Sales: sales@chorus.one
The Ethereum Merge is one of the most anticipated events in crypto history.
The transition, meant to take Ethereum from its current Proof-of-Work consensus mechanism to a Proof-of-Stake model, has been in the works since Ethereum’s inception. However, it took its first step in December 2020, when the Beacon Chain was successfully launched. And now, with the consensus mechanism running unimpeded for a year and a half and over 13 million staked ETH, developers feel confident enough to move to the second step. This requires joining the consensus layer of the Beacon Chain with the execution state of the main Ethereum chain, the process known as “the Merge”.
This new era to the Ethereum protocol brings better security, greater energy efficiency, and sets the stage for future scaling efforts meant to take Ethereum to the moon.
Chorus One has been closely following the development efforts to bring Proof-of-Stake Ethereum to reality. As a trusted staking provider in the ecosystem, we are participating in testing the Merge at this critical point with our Prater/Goerli nodes ready for transition. We are particularly aware of the risks associated with such a significant change of operations in a blockchain that has captured a major part of the economic activity in the crypto ecosystem. For that reason, our goal remains to support decentralised networks to promote the security and availability of our services, and to increase the rewards of our clients under such a standard.
As we think of the future for both our operations in the Ethereum ecosystem and the existential threats that can compromise the integrity and stability of the network, we have devoted a lot of effort into understanding MEV and clarifying our position towards it.
On our path to support a more decentralised, democratic and fair distribution of MEV rewards for our stakers, we would like to announce our support for MEV-Boost.
Although MEV continues to be a controversial and cutting-edge space for research, we believe that this can be an interim solution as we wait for more sophisticated in-protocol upgrades. On a high level, MEV-Boost is an implementation of proposer-builder separation (PBS) built by the Flashbots team for Proof-of-Stake Ethereum. As a free, open-source and neutral software, we believe it embraces the values of the Ethereum community and can be a valuable asset for all validators, big or small.
By participating in the fair extraction of MEV, we believe we are unlocking the real value of the networks we support, as well as increasing the value of staking to promote higher rates of participation, and an increase in the security of the PoS protocol.
As staking providers, running MEV-Boost allows us to maximize the staking rewards of our clients while protecting Ethereum decentralization, with an estimated increase of 60% in the rewards we can share.
Unlike previous Flashbots’ offerings, this software is compatible with all client implementations of the Ethereum protocol, making it a big step towards further client diversity, a topic that has been the subject of research at Chorus One in the past year.
Finally, we are committed to evaluate and continue to monitor different approaches to our MEV implementations, and to the risks of single-relay and single-block producers, working with different teams to find the most balanced system. Fair MEV extraction continues to be something we iterate on going forward.
In the coming days we will be getting ready to test MEV-Boost on our Goerli infrastructure to best prepare in time for the mainnet Merge. We have been working closely with Flashbots and collaborating with other node operators to ensure that the product is ready and tested by the time it goes live.
MEV is an inevitable part of participating, not only on blockchains, but in all ordered economic systems. Our intent is to be responsible participants of Ethereum and beyond, with MEV research spanning Solana and Cosmos, there is more to come. For the time being, follow our node readiness for MEV-Boost here.
Chorus One is one of the largest staking providers globally. We provide node infrastructure and closely work with over 30 Proof-of-Stake networks.
Website: https://chorus.one
Twitter: https://twitter.com/chorusone
Telegram: https://t.me/chorusone
Newsletter: https://substack.chorusone.com
YouTube: https://www.youtube.com/c/ChorusOne
The Ethereum Merge is one of the most anticipated events in crypto history.
The transition, meant to take Ethereum from its current Proof-of-Work consensus mechanism to a Proof-of-Stake model, has been in the works since Ethereum’s inception. However, it took its first step in December 2020, when the Beacon Chain was successfully launched. And now, with the consensus mechanism running unimpeded for a year and a half and over 13 million staked ETH, developers feel confident enough to move to the second step. This requires joining the consensus layer of the Beacon Chain with the execution state of the main Ethereum chain, the process known as “the Merge”.
This new era to the Ethereum protocol brings better security, greater energy efficiency, and sets the stage for future scaling efforts meant to take Ethereum to the moon.
Chorus One has been closely following the development efforts to bring Proof-of-Stake Ethereum to reality. As a trusted staking provider in the ecosystem, we are participating in testing the Merge at this critical point with our Prater/Goerli nodes ready for transition. We are particularly aware of the risks associated with such a significant change of operations in a blockchain that has captured a major part of the economic activity in the crypto ecosystem. For that reason, our goal remains to support decentralised networks to promote the security and availability of our services, and to increase the rewards of our clients under such a standard.
As we think of the future for both our operations in the Ethereum ecosystem and the existential threats that can compromise the integrity and stability of the network, we have devoted a lot of effort into understanding MEV and clarifying our position towards it.
On our path to support a more decentralised, democratic and fair distribution of MEV rewards for our stakers, we would like to announce our support for MEV-Boost.
Although MEV continues to be a controversial and cutting-edge space for research, we believe that this can be an interim solution as we wait for more sophisticated in-protocol upgrades. On a high level, MEV-Boost is an implementation of proposer-builder separation (PBS) built by the Flashbots team for Proof-of-Stake Ethereum. As a free, open-source and neutral software, we believe it embraces the values of the Ethereum community and can be a valuable asset for all validators, big or small.
By participating in the fair extraction of MEV, we believe we are unlocking the real value of the networks we support, as well as increasing the value of staking to promote higher rates of participation, and an increase in the security of the PoS protocol.
As staking providers, running MEV-Boost allows us to maximize the staking rewards of our clients while protecting Ethereum decentralization, with an estimated increase of 60% in the rewards we can share.
Unlike previous Flashbots’ offerings, this software is compatible with all client implementations of the Ethereum protocol, making it a big step towards further client diversity, a topic that has been the subject of research at Chorus One in the past year.
Finally, we are committed to evaluate and continue to monitor different approaches to our MEV implementations, and to the risks of single-relay and single-block producers, working with different teams to find the most balanced system. Fair MEV extraction continues to be something we iterate on going forward.
In the coming days we will be getting ready to test MEV-Boost on our Goerli infrastructure to best prepare in time for the mainnet Merge. We have been working closely with Flashbots and collaborating with other node operators to ensure that the product is ready and tested by the time it goes live.
MEV is an inevitable part of participating, not only on blockchains, but in all ordered economic systems. Our intent is to be responsible participants of Ethereum and beyond, with MEV research spanning Solana and Cosmos, there is more to come. For the time being, follow our node readiness for MEV-Boost here.
Chorus One is one of the largest staking providers globally. We provide node infrastructure and closely work with over 30 Proof-of-Stake networks.
Website: https://chorus.one
Twitter: https://twitter.com/chorusone
Telegram: https://t.me/chorusone
Newsletter: https://substack.chorusone.com
YouTube: https://www.youtube.com/c/ChorusOne
Maximum Extractable Value (MEV) represents a fundamental concept in cryptoeconomics, highly affecting permissionless blockchains. MEV is the consequence of the design of protocols and brings with it bad and good externalities. Indeed, not all MEV can be considered benign as some represent an invisible tax on the user, e.g. check out one of our previous articles — Solana MEV Outlook. In general, MEV can also be an incentive for consensus instability, see e.g. the time bandit attack. However, considering all types of MEV as bad externalities is wrong. There exist benign forms of MEV that ensure protocol efficiency, and one prominent example is arbitrage. Let’s imagine that some user swaps a huge amount of token A on a specific AMM (huge with respect to the total amount in the pool) and that this transaction creates a $5,000 arbitrage opportunity. All users that swap tokens in the same pool and same direction will see their output lowered with respect to the actual value. Thus, whoever exploits this MEV opportunity will also bring the market back to parity with the true price. This will make the AMM more efficient without harming its users in the process.
On Solana, MEV still represents a dark forest since no one has pointed a flashlight at it. This is because Solana is a much younger blockchain compared to Ethereum, which can be seen in the lack of products like Flashbots. One project that is moving in this direction is Jito Labs, which recently delivered the first MEV Dashboard for Solana representing an explorer aimed at illuminating MEV — see here for an introduction. However, it is not the only one trying to fulfill this duty. Pointing lights on some Solana Decentralized Exchanges (DEXs) in order to illuminate the dark forest is one of the key objectives at Chorus One. MEV is a consequence that will be a crucial factor for the future of PoS networks and we are continually looking for the best way to ride it. You can explore our Solana MEV dashboard here.
It is important to understand that a simple copy of Flashbots may not be good for Solana, since it represents a drastically different network from Ethereum — and Jito seems to be something intrinsically different. In this article, we are going to assess what are the MEV challenges Solana faces. We’ll also review the status of our internal research regarding MEV.
In Section 2, we’ll analyze the current and future status of MEV on Solana, with a detailed analysis of what we found on-chain in Section 2.1.
In Section 3, we’ll discuss some implications of the current MEV strategies and how these can affect the functionality of a PoS network.
MEV has a specific supply chain, which “describes the chain of activity which helps users transform intentions into finalized state transitions in the presence of MEV ”. However, despite this “universal” definition, MEV on Proof of Stake (PoS) networks is drastically different from what it represents on Proof of Work (PoW) networks. This is for several reasons. For sure, the most important difference relies on the possibility of knowing for sure that a validator will propose a block at some point. Further, validators have delegators and can offer to them a portion of the MEV revenue (e.g. lowering the commission) attracting users to delegate with them. This makes MEV on PoS networks a growing business model, which constitutes one of the building blocks for cryptoeconomic incentives. From one side, we have validators who can use MEV revenue to reduce commission rate — even go to negative values — by returning all incomes to the delegators. On the other side, we have incentives for Layer-1 (L1) blockchains to improve network performance. This is because, if the “scaling problem” is solved by the introduction of L2s, the MEV and transaction (txs) fees are also moved away from the main chain, weakening the L1 business model.
This is exactly what blockchains like Ethereum are facing right now, representing one of the great risks over the next few years. See this Twitter thread for a better understanding of the topic.
But, what is the current status of MEV on Solana? Let’s start from the beginning. Solana does not have a public mempool, meaning that some bad externalities of MEV are very difficult to achieve. However, Solana is not free from them since MEV extraction may produce a bad performance of the network, e.g. spam txs, dropped txs, etc. Indeed, some MEV opportunities only exist if searchers run their own validator, inspect txs that come to them, and run an MEV-extraction code on top of it. Having a high stake and getting access to more MEV opportunities is not an easy task. This dramatically reduces the likelihood of being highly profitable, as the distribution of MEV revenues averages around zero, with a tail towards higher values — see Fig. 2.2.
Note that this is obtained in a specific time window, so it is only representative of the shape of the actual distribution.
Since txs fees on Solana are low and MEV opportunities can bring validators more profit, validators are incentivized to auction off their block space to searchers, or at least some rumors are pointing towards this possibility.
Further, on Solana, fees are currently fixed and cheap, meaning that if there is high competition in a specific market, users face the risk of not getting transactions executed. Since a gas-fee auction is still missing, currently MEV searchers spam transactions to the leader (and following validators in the leader schedule) in the hopes of “winning the battle”.
Lastly, on Solana, MEV competition may incentivize validators to perform denial of service (DoS) attacks on other validators in order to leave the spotted MEV opportunities just there, sitting on the table where they are until the attacker can extract them.
The current status of MEV indicates how bad the problem of blockspace-waste is, which resulted in degraded performance for normal users. At the time of writing, according to what can be found on Jito’s MEV dashboard, we have 12,072,328 successful arbitrages against the 350,179,786 unsuccessful ones in 6 months (i.e. a 3.3% of success rate). If we also include liquidations, the success rate goes down to roughly 3%. The total extracted “good” MEV is around $33M. Of course, this is only a lower-bound since MEV can be created any time a user interacts with a blockchain, and smart contracts enable a functionally infinite number of potential interactions. Thus, it is computationally infeasible to calculate a blockchain’s total potential MEV by brute force. Further, we have some previous analyses that show how a huge amount was extracted during periods of stressful market conditions, e.g. $13M MEV during Wormhole Incident and $43M Total MEV from Luna/ UST Collapse on Solana.
Future Solana improvements aim to introduce several features, forcing current MEV strategies to change. Introducing these new features represents a two-sided coin for MEV searchers. Indeed, some spamming bots would be forced to shut down since the local fee market will make it unprofitable to massively spam txs. However, improving the network means more and more users are attracted to use it. This has the immediate consequence of also increasing the total amount of MEV, allowing the chain of implications to continue by incentivizing competition around MEV and “inviting” new searchers to step in.
One of the main problems that can worsen an AMM’s functionality is pool congestion. This is because if there are too many txs happening on a specific pool, users may experience a worse trade due to pool unbalancing. This is why arbitraging is a sort of service that normalizes DEXs functionality. But, despite the fact that we know MEV is happening on Solana, where are the greatest opportunities? In other words, what are the DEXs with the highest pool congestion, and who is “solving” it? To answer these questions, we built an MEV dashboard on Dune Analytics. This is because, by looking at the exchanged volume, — using Solscan — you can definitely have an idea of where the congestion is, but nothing is clear when the question is if searchers are solving for it.
Our preliminary research shows that in 10 days (from July 16th to July 26th), the paths with the highest extracted MEV on Solana were live on Orca and Raydium with a lower bound of 20,775 USD extracted, see Fig. 2.5. There were 68 MEV extractors on these cross DEXs during the analyzed period, thus not a great number in terms of competition. Fig. 2.6 shows how the extracted revenues are concentrated among a few searchers. Precisely, 5 different accounts extracted 80.1% of the total MEV.
It is worth mentioning that none of the studied DEX combinations show a uniform distribution in terms of MEV opportunities, according to what we show in Fig. 2.2.
If we extend the analysis by looking at the USDC Token Accounts belonging to the most profitable MEV searchers, we have that 7 accounts were able to extract 95.6% of total extracted MEV, see Fig. 2.7. Two of them, GjT…m2P and G9D…y2m, interact with the same smart contract, which may indicate that these two accounts belong to the same user. Since these accounts are in the top 7 accounts, this means that it is likely that only 6 users were able to extract 95.6% of the total extracted MEV.
By deep diving, we also found two accounts interacting with a smart contract with clear reference to Jito, Jito…HoMA, with a total extracted MEV in 10 days of 3,342.30 USDC (at time of writing), over a total of 158,132 USDC extracted — i.e. 2.1% of the total amount.
We already stated that, on PoS networks, MEV can be seen as a business model since validators can share a portion of the extracted amount with their delegators. However, as shown in Sec. 2.1, this sometimes can constitute a deal that does not truly mean high returns. MEV revenues are strongly correlated with market conditions and DEXs’ usage, meaning that we’re unable to estimate a fixed income to share with delegators. Further, if competition does not grow fast, the promise of sharing revenue with delegators may bring a centralization problem.
To assess this statement, let’s try to formulate a “gedanken-experiment”. Imagine that the volume exchanged by DEXs on Solana grows by a factor 30, and assume that there is only one validator extracting MEV and redistributing the revenues to delegators. The implication of the increased volume is that MEV also increases. Indeed, a factor of 30 means that in 30 days the DEX’s volume on Solana is greater than $30B, and assuming that the 0.04% of it is MEV — as it happens on Ethereum — this means more than $144M yearly. The implication of having only one validator playing this game is that the extracted amount also increases, making the delegation to them an appealing deal. We can just think that a validator with ~2% of the total stake can extract an MEV of ~ $2.9M yearly. Once the delegation starts to concentrate around a single validator — the sole player — again we have a boost in MEV revenues, since the leader schedule is “stake-dependent” on Solana. This is because the revenue per block is not uniformly distributed, so a higher stake means an increased likelihood of capturing a rare juicy opportunity, pushing up the median of the extracted MEV. If there is no competition, this gedanken-experiment has a single outcome: concentration of stake — i.e. centralization.
Risks become higher if one considers that at the moment Solana is one of the fastest blockchains and that future development aims to improve this even further. The high number of processed txs per second could pave the way for prop firms to enter the market, meaning that more SOL can be delegated to a single validator — the winner of the MEV war.
This, without any doubt, points toward the necessity of building competitive validators for what regards MEV extraction. Once Jito delivers its third-party client for Solana that’s been optimized for efficient MEV extraction (plus its bundle), the risk of centralization can be mitigated. However, even with decentralized block building, as Flashbots aims to achieve with MEV-boost, we remain still far from a definitive solution. Indeed, such an environment makes it easier for builders to buy the blockspace of all validators and thereby isolate the centralization to the builder layer, see e.g. here. At the moment a decentralized MEV from top to bottom is a chimera. The first step toward this direction would require open-sourcing the MEV-extracting validator, starting collaboration between many validators, in the true spirit of open source. Indeed, it is worth noting that adopting validator products developed — and belonging — to a single entity reduces the problem of stake concentration, but can decrease the network’s censorship resistance. If block production is centralized to a single entity, that may represent an enormous censorship risk, regardless of how many validators participate.
For example, let’s assume that this entity gets adopted by 50% of the stake. Suppose now that this entity is regulated by a specific government, which demands that all transactions are blocked. Then, at best, users would need to get their transactions into the other blocks, but in the worst case, this entity can refuse to include vote transactions that vote on blocks that contain sanctioned transactions. This is a simple example that shows how some MEV strategy outcomes could pave the way for censorship risks.
Before concluding, it is worth mentioning that other possibilities do exist. One of them is to frame MEV-extraction as a service, where it is the protocol itself that takes the MEV and shares the corresponding revenue with protocol-token stakers, see e.g. recent rumors on Osmosis development. Despite this “method” seeming to be less prone to a centralization risk, it remains unclear if the time needed to extract MEV is enough to guarantee the AMM functionality — remember that poor competition means some opportunities may remain there for a “long” time. The outcome is the difficulty of assessing all the details of how this will affect the future of the chain.
This article aims to collect some thoughts on how framing MEV may affect the future of PoS ecosystems, focussing on some of its “bad” consequences. Despite the fast development around this huge and complex topic, we at Chorus One are continuously researching this topic with an eye to the future: the healthiness of all networks is always our first priority.
If you’re interested in framing the topic and require research/advisory services on MEV, you can contact our Research Team at research@chorus.one
This is the second article of the Solana MEV outlook series. In this series, we use a subset of transactions to extrapolate which type of Maximum Extractable Value (MEV) is being extracted on the Solana network and by whom.
MEV is an extensive field of research, ranging from opportunities created by network design or application-specific behaviour to trading strategies similar to those applied in the traditional financial markets. As a starting point, our attempt is to investigate if sandwich attacks are happening. In the first article, we examined Orca’s swap transactions searching for evidence of this pattern. Head to Solana MEV Outlook — part 1 for a detailed introduction, goals, challenges and methodology. A similar study is performed in the present article. We are going to look at on-chain data, considering approximately 8 h of transactions on the Raydium DEX. Given the magnitude of 4 x 10⁷ transactions per day, considering only Decentralized Exchanges (DEX) applications on the Solana ecosystem. This simplification is done to get familiarity with data, extrapolating as much information as we can to extend towards a future analysis by employing a wider range of transactions.
Raydium is a relevant Automated Market Maker (AMM) application on the Solana ecosystem, the second program in the number of daily active users and the third in terms of program activity.
Raydium program offers two different swap instructions:
Although the user interface (“UI”) interacting with the smart contract sets the swap instruction to use the first instruction type, leaving SwapBaseIn responsible for 99.9% of successfully executed swap instructions:
We built a dataset, extracting the inputs from the data byte array passed to the program, and the actual swap token amounts by looking at the instructions contained in the transaction. Comparing the minimum amount of tokens specified in the transaction and the actual amount the user received, we estimate the maximum slippage tolerance for every transaction. By computing the corresponding slippage, we obtain the histogram:
The default value for slippage on the Raydium App is set to 1%. We can assume that at least 28% of transactions use the default value. Since it is not possible to know the state of the pool when creating the transaction, this number could be a bit higher.
It can be assumed that nearly 0% of slippage values are only achieved by sophisticated investors using automated trading strategies. Orca swaps’ histogram, presented in Fig 2.2 of the previous article, shows a peak in transactions with slippage of around 0.1%. On Raydium, a relevant proportion of transactions lies below 0.05%. This fact can suggest that trading strategies with lower risk tolerance, i.e price-sensitive strategies correspond to 25% of the swaps transactions (accumulating the first two bars in the histogram).
Other evidence of automated trading being common on this DEX is that on average, 40% of transactions fail, mostly because of the tight slippage allowed by user settings.
We are considering more than 30,000 instructions interacting with the Raydium AMM program, from time 02:43:41 to time 10:25:21 of 2022–04–06 UTC. For statistics purposes, failed transactions are ignored.
Although 114 different liquidity pools are accessed during this period, the SOL/USDC pool is the most traded pool, with 4,000 transactions.
The sample contains 1366 different validators as leaders in more than 35000 slots we are considering, representing 93% of the total stake and 78% of the total validator population by the time of writing, according to Solana Beach.
Of 5,101 different addresses executing transactions, 10 accounts concentrate 23% of the total transactions. One of the most active accounts on Raydium, Cwy…3tf also appears in the top 5 accounts in Orca DEX.
The graph below shows the total number of transactions for accounts with at least two transactions in the same slot. If used as a proxy to identify automated trading, on average 9 different accounts can be classified:
We can also look at the pools where these accounts execute more often. It is possible to notice they tend to specialize in different pools. The table below shows the two pools with more transactions for each of the 5 more active addresses:
By deep-diving into account activity by pool, we can see that two accounts concentrate transactions on WSOL/USDT pool; one account is responsible for half of all transactions in the mSOL/USDC pool; most of the transactions in the GENE/RAY pool are done by only one account (Cwy…3tf).
Searching for sandwich behaviour means we need to identify at least 3 transactions executed in the same pool in a short period of time. For the purpose of this study, only consecutive transactions would be considered. The strategy implies the first transaction to be in the same direction of the sandwiched transaction and a transaction in the opposite direction of the initial trade, closing out the positions of the MEV player.
The need for price impact implies a dependence on the amount of capital available to be used in every trade. Some MEV strategies can be performed atomically, with a sequence of operations executed in the same transaction. These strategies usually benefit from flash loans, allowing for anyone to apply it disregarding the capital they have access to. This is not the case for sandwich attacks, since the profit is realized after the successful execution of all the transactions (Fig. 10).
As shown in the first article, the amount of capital needed in order to create value depends on the Total Value Locked in the pool — the deeper the liquidity, the more difficult it is to impact the price. Head to Fig. 2.4 of the first article for the results of simulation into the Orca’s SOL/USDC pool. The figure shows the initial capital needed in order to extract a given percentage of the swap.
In the current sample, we have found 129 blocks with more than three swaps in the same pool, most of the swaps are in the same direction — no evidence of profit-taking. As shown in Fig. 11 below, the pool SAMO_RAY is the pool with more occurrences of multiple swaps in the same slot.
When searching for blocks and pools with swaps in opposite directions as a proxy to profit-taking, 9 occurrences are left with a potential sandwich attack pattern, as shown in the table below (Fig 12). After further investigation of the transactions and the context in which the instructions were executed, it is fair to assume the operations are related to arbitrage techniques between different trading venues or pools.
In this report, we were able to access the activity of the Raydium DEX. The conclusions are based on a limited amount of data, assuming our sample is comprehensive enough to reflect the general practices involving the dApp.
It is possible to notice relevant activity from automated trading and price-sensitive strategies such as arbitrage, which corresponds to 25% of swap transactions. On average, only 40% of transactions are successfully executed and 72% of all reverted transactions fail because of small slippage tolerance. Approximately, 28% of transactions can be classified as manual trading, since they use the default slippage value.
Of 5101 different accounts interacting with the Raydium program, 10 accounts concentrate 23% of the total transactions. One of the most active accounts on Raydium, Cwy…3tf also appears in the top 5 accounts in Orca DEX transactions. This same account is responsible for 77% of swaps in the GENE/RAY pool.
There were 9 occurrences of a potential pattern of a Sandwich attack discarded after further investigation.
It is important to mention that this behaviour is not only dependent on the theoretical possibility but largely biased by market conditions. The results in $13m MEV during Wormhole Incident and $43m Total MEV from Luna/ UST Collapse on Solana demonstrate the increase in profit extracted from MEV opportunities during stressful scenarios. Although the study focuses attention on different strategies and does not mention sandwich attacks, the probability of this strategy happening can also increase, given the smaller liquidity in pools (TVL) and the occurrence of trades with bigger size and slippage tolerance.
This is my first published article. I hope you enjoyed it. If you have questions, leave your comment below and I will be happy to help.
Solana is a young blockchain, and having a complete picture of what is happening on-chain is a difficult task — especially due to the high number of transactions daily processed. The current number of TPS is around 2,000, meaning that we need to deal with ~ 10⁸ transactions per day, see Fig. 1.1.
When processing transactions, we have to deal with the impossibility of a-priori knowing its status before querying information from an RPC node. This means that we are forced to process both successful and failed transactions. The failed transactions, most of which come from spamming bots that are trying to make a profit (e.g. NTF, arbitrage, etc.), constitutes ~ 20% of the successful ones. The situation slightly improves if we consider only program activity. By only considering what happens on Decentralized Exchanges (DEXs), we are talking about 4x10⁷ transactions per day, see Fig. 1.2. This makes it clear that a big effort is required to assess which type of Maximum Extractable Value (MEV) attack is taking place and who is taking advantage of it, even because tools like Flashbots do not exist on Solana.
In what follows, we are going to estimate what happened on-chain considering only ~5 h of transactions on Orca DEX, from 11:31:41 to 16:34:19 on 2022–03–14. This simplification is done to get familiarity with data, extrapolating as much information as we can to extend towards a future analysis by employing a wider range of transactions. It is worth mentioning that Orca DEX is not the program with the highest number of processed instructions, which indicates that a more careful analysis is needed to look also into other DEX — this is left for future study.
The aim of this preliminary analysis is to gain familiarity with the information contained in usual swap transactions. One of our first attempts is to extrapolate if sandwich attacks are happening, and if so, with which frequency. In Section 2, we are going to look at the anatomy of a swap transaction, focussing on the type of sandwich swap in section 2.1. Section 2.2 is devoted to the description of “actors” that can make a sandwich attack. In Section 3, we describe the dataset employed, leaving the description of the results in Section 4. Conclusions are drawn in Section 5.
On Solana, transactions are made by one or more instructions. Each instruction specifies the program that executes them, the accounts involved in the transaction, and a data byte array that is passed to the program. It is the program’s task to interpret the data array and operate on the accounts specified by the instructions. Once a program starts to operate, it can return only two possible outcomes: success or failure. It is worth noticing that an error return causes the entire transaction to fail immediately. For more details about the general anatomy of the transaction see the Solana documentation.
To decode each of the instructions we need to know how the specific program is written. We know that Orca is a Token Swap Program, thus we have all the ingredients needed to process data. Precisely, taking a look at the token swap instruction, we can immediately see that a generic swap takes as input the amount of token that the user wants to swap, and the minimum amount of token in output needed to avoid excessive slippage, see Fig. 2.1.
The minimum amount of tokens in output is related to the actual number of tokens in output by the slippage S, i.e.
from which
Thus, we can extract the token in input and the minimum token in output from the data byte array passed to the program, and the actual token in output by looking at the instructions contained in the transaction.
By computing the corresponding slippage defined in Eq. (2.2) we obtain the histogram in Fig. 2.2. From this picture, we can extrapolate different information. The first one is, without doubt, the distribution of transactions around the default value of slippage on Orca, i.e. 0.1%, 0.5% and 1%. This makes complete sense since the “common-user” is prone to use default values, without spending time in customization. The second one is the preference of users to select the lowest value for the slippage. The last one concerns the shape of the tails around the default values. A more detailed analysis is needed here since it is not an easy task to have access to what actually is contained inside them. The shape surely depends on the bid/ask scatter, which is a pure consequence of the market dynamic. The tails may also contain users that select a different slippage with respect to the default values. However, one thing is assured: this histogram contains swaps from which the slippage can yet be extracted. As we will see, from this we can extrapolate an estimate of the annualized revenue due to sandwich attacks.
The goal of this report is to search for hints of sandwich swaps happening on Orca DEX. All findings will be used for future research, thus we think it is useful to define what we refer to as sandwich swaps and how can someone take advantage of them.
Let’s start with its basic definition. Let’s assume a user (let’s say Alice) wants to buy a token X on a DEX that uses an automated market maker (AMM) model. Let’s now assume that an adversary sees Alice’s transaction (let’s say Bob) and can create two of its own transactions which it inserts before and after Alice’s transaction (sandwiching it). In this configuration, Bob buys the same token X, which pushes up the price for Alice’s transaction, and then the third transaction is the adversary’s transaction to sell token X (now at a higher price) at a profit, see Fig. 2.3. This mechanism works until the price at which Alice buys X remain sbelow the value X･(1+S), where S represents the slippage set by Alice when she sends the swap transaction to the DEX.
Since Bob needs to increase the value of the token X inside the pool where Alice is performing the swap, it is evident that the core swaps inserted by Bob should live on the same pool employed by Alice.
From the example above, it may happen that Bob does not have the capital needed to significantly change the price of X inside the pool. Suppose that the pool under scrutiny regards the pair X/Y and that the AMM implements a constant product curve. In the math formula we have:
where k is the curve invariant. If we set the number of tokens Y in the pool equal to 1,000,000 and the number of tokens X equal to 5,000,000 and assuming that Alice wants to swap 1,000 token Y, we have that the amount of token X in output is:
It is worth noting that here we are not considering the fee that is usually paid by the user. If Alice set a slippage of 5%, this means that the transaction will be executed until the output remains above 4'745.25. This means if Bob is trying to take this 5%, he will need an initial capital of 26,000 token Y.
Sometimes this capital may be inaccessible, allowing Bob to only take a portion of the 5% slippage. For example, let’s consider the Orca pool SOL/USDC, with a total value locked (TVL) of $108,982,050.84 at the time of writing. This pool implements a constant product curve, which allows us to use Eqs. (2.3) and (2.4) to simulate a sandwich attack. Fig. 2.4 shows the result of this calculation.
It is clear that the initial capital to invest may not be accessible to everyone. Further, it is important to clarify that the result is swap-amount independent. Indeed, for each amount swapped by Alice, the swap made by Bob is the one that “moves” the prices of the initial tokens inside the pool. The scenario is instead TVL dependent. If we repeat the same simulation for the Orca pool ETH/USDC, with a TVL of $2,765,189.76, the initial capital needed to extract a higher percentage of the slippage of Alice drastically decreases, see Fig. 2.5.
From the example above, let’s consider the case in which Bob has an initial capital of 2,000 token Y. If he is able to buy the token Y before Alice’s transaction, Alice will obtain an output of 4,975.09 token X, which is only 0.4% lower than the original amount defined in Eq. (2.4).
At this point, Bob has another possibility. He can try to order transactions that are buying the same token X after its transaction, but immediately before Alice’s swap. In this way, he can use the capital of other users to take advantage of Alice’s slippage, even if Bob’s initial capital is not enough to do so, see Fig. 2.6. This of course results in a more elaborate attack, but likely to happen if Bob has access to the order book.
It is not an easy task to spot the actors behind a sandwich attack on Solana. In principle, the only profitable attackers are the leaders. This is because there isn’t a mempool, and the only ones that know the exact details of the transactions are the validators that are in charge of writing a block. In this case, it may be easier to spot hints of a sandwich attack. Indeed, if a leader orders the swap transactions to perform a sandwich, it should include all of them in the same block to prevent an unsuccessful sandwich.
The immediately following suspect is the RPC service that the DAPP is using. This is because the RPC service is the first to receive the transaction over HTTP, since it is its role to look up the current leader’s info using the leader schedule and send it to the leader’s Transaction Processing Unit (TPU). In this case, it would be much more difficult to spot hints of sandwiching happening since in principle the swap transactions involved can be far from each other. The only hook we can use to catch the culprit is to spot surrounding transactions made by the same user, which will be related to the RPC. This is a consequence of the lower price fee on Solana, which raises the likelihood that a sandwich attack can happen by chance spamming transactions in a specific pool. This last one is clearly the riskiest since there is no certainty that the sequence of transactions is included in the exact order in which the attacker originally planned it.
Before entering the details of the analysis, it is worth mentioning that, standing on what is reported on Solana Beach, we have a total of 1,696 active validators. Our sample contains 922 of them, i.e. 54.37% of the total validator population. The table below shows the validator that appears as the leader in the time window we are considering. Given the likelihood-by-stake for a validator to be selected as a leader, we retain fair to assume that our sample is a good representation of what’s happening on Orca. Indeed, if a validator is running a modified version of the vote account program to perform sandwich swap, the rate of its success will be related to the amount of staked tokens, not only by actual MEV opportunities. Further, modifying the validator is not an easy task, thus smaller validators will not have the resources to do that. Since we have all the 21 validators with a supermajority plus a good portion of the others (i.e. we are considering half of the current number of active validators), if such a validator exists, its behaviour is easily spotted in our sample. However, it is worth mentioning that a complete overview of the network requires the scrutiny of all validators, without making assumptions of that kind. Such achievement is behind the scope of this report, which aims primarily to explore which type of sandwich can be done and how to spot them.
Having clarified this aspect, we firstly classify the types of swaps that are performed on the Orca DEX. The table below shows the accounts that are performing more than two transactions. It is immediately visible that most of the transactions are done by only 2 accounts over 78 involved.
As explained in Section 1, we are considering 5H of transactions on Orca DEX, from 11:31:41 to 16:34:19 on 2022–03–14. This sample contains a total of 12,106 swaps, with pool distribution in Fig. 3.1.
By deep-diving into the swap, we can see that most of the transactions in the 1SOL/SOL [aq] and 1SOL/USDC [aq] are done by only two accounts, see Fig. 3.2. Here [aq] stands for Aquafarm, i.e. an Orca’s yield farming program. We can also see the presence of some aggregate swaps in the SOL/USDC [aq] and ORCA/USDC [aq] pools.
We started searching for the presence of leaders performing sandwich swaps. As we described in Section 2.1, in general, a swap can happen in two ways. For both of them, if such a type of surrounding is done by a leader, we should see the transactions under scrutiny included in the same block. This is because, if a leader wants to make a profit, the best strategy is to avoid market fluctuations. Further, if the attacker orders the transactions without completing the surrounding, the possibility that another leader reorders transactions cancelling the effect of what was done by the attacker is not negligible.
By looking at the slots containing more than 3 swaps in the same pool, we ended up with 6 slots of that kind, out of 7479. Deep diving into these transactions, we found that there is no trace of a sandwich attack done within the same block (and so, from a specific leader). Indeed, each of the employed transactions is done by a different user, marking no evidence of surrounding swaps done to perform a sandwich attack. The only suspicious series of transactions is included in block # 124899704. We checked that the involved accounts are interacting with the program MEV1HDn99aybER3U3oa9MySSXqoEZNDEQ4miAimTjaW, which seems to be an aggregator for arbitrage opportunities.
As mentioned in Section 2.2, validators are not the only possible actors. Thus, to complete the analysis we also searched for general surrounding transactions, without constraining them to be included in the same block. We find that only 1% of the total swaps are surrounded, but again without strong evidence of actual sandwich attacks (see Fig. 4.1 for the percentage distribution). Indeed, by looking at those transactions it comes out that the amount of token exchanged is too low to be a sandwich attack (see Sec. 2).
Before ending this section, it is worth mentioning that if we extrapolate the annual revenue that a leader obtains by taking 50% of the available slippage for swaps with a slippage greater than 1%, we are talking about an amount of ~ 240,000.00 USD (assuming that the attacker is within the list of 21 validators with supermajority), see Fig. 4.2. Of course, this is not a real estimate since it is an extrapolation from only 5h of transactions, thus we need to stress that the actual revenue can be different. Further, this is not an easily accessible amount due to what we showcased in Sec. 2. However, the amount in revenue clearly paves the way for a new type of protection that validators should offer to users, especially if we take into account that Orca is not the DEX with the highest amount of processed swaps. Since at the moment there is no evidence that swaps are sandwiched, we will take no action in this direction. Instead, we will continue monitoring different DEXs by taking snapshots in different timeframes informing our users if a sandwich attack is spotted on Solana.
In this report, we define two types of sandwich attacks that may happen on a given DEX. We further describe who are the possible actors that can perform such a type of attack on Solana and how to spot them. We analyzed data from ~5 h of transactions on Orca DEX, from 11:31:41 to 16:34:19 on 2022–03–14 (that is, 12,106 swaps). Despite the cutting of the number of transactions employed, we argued why we believe this sample could fairly be a “good” representation of the entire population.
Our findings show no evidence that sandwich attacks are happening on Solana by considering two possibilities. The former is that a validator is running a modified version “trained” to perform a sandwich attack on Orca. The latter is that an RPC is trying to submit surrounding transactions. We discovered that only 1% of transactions are actually surrounded by the same user, but none of them is included in the same block — excluding the possibility that a leader is taking advantage of the slippage. By deep-diving into this, we discover that the amount exchanged by these transactions results are too low for capital to be invested to exploit the slippage and submit a profitable sandwich attack.
We also show how the capital needed to make sandwich attacks profitable may not be accessible to everyone, narrowing the circle of possible actors.
