Solana has a very different architecture from Ethereum or EVM based chains, it is pretty known by now. The main difference is that Solana handles the transaction in a parallelized multi-threaded way instead of a single-thread EVM way.

This is possible due to Solana separates a traditional Ethereum smart-contract in many separate accounts such as:

• Program Account – stores executable code (like the logic of an SPL token, Serum, or a lending protocol).

• Data Accounts – store mutable state separately from the program logic (e.g., a user’s position in a lending protocol, or metadata about an NFT).

• Mint Account – defines a specific token, including its authority, supply, and decimals.

• Token Account – tracks how many tokens a specific wallet owns of a specific mint.

• Wallet (System) Account – standard public key accounts controlled by private keys, used to pay for transactions and sign them.

By decomposing smart contract logic and state into separate accounts, Solana enables parallel execution — because it knows up front which accounts a transaction will touch. That’s why Solana requires all accounts a transaction will read or write to be declared upfront — this allows its runtime to safely parallelize execution across multiple threads, unlike Ethereum where transactions are processed sequentially.

This leads to increasing complexity in reading the Solana Block Explorer with so many accounts involved in each transaction, just see a normal swap done using Jupiter(Solana’s 1inch) below-

Another biggest difference is lack of a public mempool in Solana and this is quite interesting as this is where all the critiques of Solana come in. The public mempool was omitted for increasing the TPS as public mempool adds extra latency and would not support the continuous block production pattern of Solana, but it leads to privatization of validators as for getting any transaction in a Solana’s block, the user has to send it directly to the validator instead of sending it to the public mempool and this mechanism has lots of grey area, such as :-

• Transaction Censorship: Validators can choose which transactions to include or exclude, which gives them outsized power. In the absence of a public mempool, there’s no open visibility into pending transactions, making it hard to detect censorship in real time.

• MEV (Maximal Extractable Value) Exploitation: Since transactions are privately submitted to validators, there's potential for MEV strategies to be executed in complete darkness. This creates a "dark forest" where validators or block producers may front-run or reorder transactions for profit without scrutiny.

• Lack of Fair Ordering: In Ethereum, public mempools at least give everyone a chance to compete for transaction ordering (via tips or gas auctions). In Solana, transaction ordering depends on validator discretion, which can favor private order flow arrangements or internal validator operations.

• Centralization Pressure: Entities that can strike deals with validators for priority access or protection from MEV may have a significant advantage. This may incentivize centralization around powerful validators or private transaction relayers.

So, the transaction before getting published to onchain ledger is done in a complete block-market/offchain way where block space can be purchased by getting in touch with validator or geospatially co-locating with the validator for faster inclusion.

So, how does a normal user who doesn’t know the validator personally can include his/her/its transaction without having any favour from the validator - SPAM

Spam is the biggest problem of Solana due to 3 main factors - extremely cheap costs ,extremely high TPS due to parallel thread execution and random inclusion of a transaction in any of the multiple parallel threads which leads to lock of the states. Anyone who want to include a transaction in a block can spam as many transaction as possible maybe for the MEV or maybe just to frontrun a NFT mint or maybe to arbitrage b/w 2 Liquidity pools.

Solana tries to mitigate this with

• priority fees(similar to ETH) and

• Stake Weighted QOS which states that all the transaction coming from various RPC’s to current leader/block producer will be weighted in the ratio of how much Solana is staked by the RPC counterparty Validator(it is a way to associate a RPC with the Validator that owns the RPC) which again centralizes the transaction inclusion process with advantage of effective spam protection through small RPC’s.

Jito is following Flashbot’s model for offchain block-space markets to mitigate this to some degree where it let the pre-made batch of transactions called bundles to be submitted to a validator which solves the two-fold problem that, it enhances the share of MEV that goes to the validator by multiple folds ass the usual priority fee is very small and due to lot of spams normally validator can’t make up how much MEV is being extracted, so in short democratizing the access to MEV to Validators and in subsequent ways to normal users.

This also de-incentivizes spammers to to spam more as the private flow of blockspace in an already private chain(i.e. Solana) has become somewhat more public because:-

• It is beneficial for Validators as they get more share

• It makes the blockspace more open and public

And to top upon all of this, there is no SLASHING for malicious validators where maliciousness can come from various ways as this is a more of a private market.

And one more factor is there i.e. Epoch wise Validator pre-determination where all the validators for 2 days are chosen at once according the stake quantity which makes validators predictable and incoming transaction unpredictable which gives us quite interesting dynamics with Ethereum’s unpredictable Validators and predictable incoming transaction(due to public mempool)

Other things such as forks are common in both with Solana having much more due to much more block production and recently features such TVS(timely Voting Slashing) a and couple of proposals( 1 & 2)

This all things makes the co-ordination plays on Solana much more interesting and nuanced which ulimately makes MEV also much more interesting

So let’s took a look at that shall we now, but first layout the questions which are common for both ETH and SOL

• Per attack profit and cost analysis(low tx. cost)

• Which venues are targeted(memecoins etc.)

• As Solana separates the program logic with the token account or wallet, so which programs are used by how many bots

• And the contribution of Validator in facilitating the sandwiches either through Jito or normally

And some new questions unique to Solana

• Sandwiching in multiple slots as a Validator is block-producer for continuous 4 slots/block and pre-determined validator schedule for the whole epoch

• Validator - Protocol wars where each protocol has validators of there own and try to disturb other protocol’s transaction because of stake weighted doing of things

And some open questions

• Reverse Sandwiching / Futures-like manipulation

• Can sandwich be done between multiple pools cause of low cost of aggregation of routes?

• Can sandwiching be done within in small parts like buying in a single txn and then selling in multiple txn’s(maybe not because the order of transaction is determinant and to maximise profit there should be a single txn) - this may happen if there is some probability of randomness(either due to txn ordering or validators can be multiple reasons)

We would go the data route for this as Richard Feynman wanted us to go, yayy!!

I made a Dashboard on Flipside(better prompts than Dune, lmeow) but most of them have lower time-frame because of data indexing limitations, so let’s look at the primary metrics:-

The data suggests sophisticated, high-frequency trading strategies targeting market inefficiencies, with concentrated activity on platforms like Raydium and PumpSwap cause because of most volume in memecoins only with direct co-relation with most volume

And there is a significant involvement of validators which can be seen firstly through the skewed profit distribution among sandwich bots and then examining the distribution of the top bot’s sandwich among validator used.

An interesting thing to notice here the average sandwich returns which are more or less same for all with

• Modest returns between 0.04 and 0.20 WSOL

• Exponential distribution of profits

• Rare but significant profit spikes exceeding 1 WSOL

Now, coming onto some new questions which are specific to Solana

• Multiple Slot sandwich - Sandwiching in multiple slots as a Validator is block-producer for continuous 4 slots/block and pre-determined validator schedule for the whole epoch.

A “cross-block sandwich” would require:

Buying in block n → The victim’s txn in block n+1 (with you knowing this in advance) → Selling in block n+2

And let’s limit this to 4 slot difference only(multiple slot is also possible but that would take much more co-ordination and capital), this is assuming that you know future order flow, which is only possible if:

• You control or collude with a validator in block n+1

• There's out-of-band info leakage (e.g., private orderflow, off-chain OTC coordination)

This is essentially validator-level corruption, and it has happened (e.g., through Jito relays or dark MEV deals), but is rare, let’s look into this

To extract this data, I modified the original sandwich attack detection query with the following changes:

• Relaxed the block constraint: Instead of requiring both the buy and sell swaps to occur within the same block, I expanded the condition to allow a maximum difference of 4 blocks between the two transactions.

• Time and block delay metrics: I added calculations for the average number of blocks and average time (in seconds) between the entry (buy) and exit (sell) transactions of each sandwich pair.

• Profit segmentation: I split the analysis into:

  • Single-block sandwiches (where both swaps happen in the same block)

  • Multi-block sandwiches (where swaps are up to 4 blocks apart)For each category, I computed the total and average profit in WSOL.

• Outcome:

The outcome is as expected not much of multi block Sandwich is happening due to factors, first is that normal sandwiches are still plenty profitable and second that the extreme high number of transactions which are going in to the validator through multiple RPC overpower the computation needed for multi-block sandwich

So yes, multi-block sandwiching is theoretically possible, but it’s more like “dark MEV games” or time-delay attacks but with advancement in bandwidth and MEV game getting more and more exposure hence making the game difficult will definitely make this a future possibility.

• Validator - Protocol wars - There is low possibility of this as there are no reports for this as such and need extensive data and the reason for this not happening is that the portion of the pie for gas fee is still pretty big

And normally the failure rate of total transaction on Solana goes upto 50% which is mostly due failed arbitrages which are spammed and even if we go deep in a suspected big validator who is getting more failure rate than other can be accounted to various reasons other than protocl-validator wars such as:-

• Running or colluding with aggressive MEV searchers or arbitrage bots

• Relaying bundled transactions with tight slippage windows

• Hosting high-frequency trading strategies that rely on speculative execution

• Supporting private RPC endpoints where spam strategies are more feasible

• Participating in priority fee auction strategies that create localized congestion

And it is very hard to get data based evidence for that with current tech and anonymous validators and spammers

Now getting to open questions for both EVM and Solana MEV

• Reverse Sandwiching / Futures-like manipulation - this opens up a whole field of advanced MEV and adversarial trading, this looks similar to normal MEV but is very different is very relevant in all of the decentralized perp-dex and need an article of it’s own(maybe next), let’s look how it is done

  • Reverse Sandwich (aka "anti-sandwich") is where:

    • You sell before a large buyer

    • They push price up

    • You buy back after

  This works when:

  • You expect a large buy (e.g., liquidation, whale trade)

  • You position ahead of them, pushing price lower

  • After they buy, price pumps — you buy back

  This is very less relevant in Ethereum because of high transaction costs and no major perp-dex there, every perp-dex either has it’s own chain or shifts to high throughput chains like Solana

• Multiple transaction sandwich - Can sandwiching be done within in small parts like buying in a single txn and then selling in multiple txn’s, it is very low possibility because the order of transaction is determinant and to maximise profit there should be a single txn to be more determinant - this may happen if there is some probability of randomness(either due to txn ordering or validators can be multiple reasons), this is not done currently due to many reasons:-

  • You risk partial fills

  • You can lose the race condition to another MEV bot or fail atomicity

  • It’s harder to ensure exact ordering unless you're in control of the full block

But the future of MEV is bright as Multiple slot sandwiches, multiple transaction sandwiches, validator-protocol MEV wars are very possible in the future when normal MEV goes very less profitable for a single actor when the game gets divided into multiple actors like in PBS model

Solana has a very different architecture from Ethereum or EVM based chains, it is pretty known by now. The main difference is that Solana handles the transaction in a parallelized multi-threaded way instead of a single-thread EVM way.

This is possible due to Solana separates a traditional Ethereum smart-contract in many separate accounts such as:

• Program Account – stores executable code (like the logic of an SPL token, Serum, or a lending protocol).

• Data Accounts – store mutable state separately from the program logic (e.g., a user’s position in a lending protocol, or metadata about an NFT).

• Mint Account – defines a specific token, including its authority, supply, and decimals.

• Token Account – tracks how many tokens a specific wallet owns of a specific mint.

• Wallet (System) Account – standard public key accounts controlled by private keys, used to pay for transactions and sign them.

By decomposing smart contract logic and state into separate accounts, Solana enables parallel execution — because it knows up front which accounts a transaction will touch. That’s why Solana requires all accounts a transaction will read or write to be declared upfront — this allows its runtime to safely parallelize execution across multiple threads, unlike Ethereum where transactions are processed sequentially.

This leads to increasing complexity in reading the Solana Block Explorer with so many accounts involved in each transaction, just see a normal swap done using Jupiter(Solana’s 1inch) below-

Another biggest difference is lack of a public mempool in Solana and this is quite interesting as this is where all the critiques of Solana come in. The public mempool was omitted for increasing the TPS as public mempool adds extra latency and would not support the continuous block production pattern of Solana, but it leads to privatization of validators as for getting any transaction in a Solana’s block, the user has to send it directly to the validator instead of sending it to the public mempool and this mechanism has lots of grey area, such as :-

• Transaction Censorship: Validators can choose which transactions to include or exclude, which gives them outsized power. In the absence of a public mempool, there’s no open visibility into pending transactions, making it hard to detect censorship in real time.

• MEV (Maximal Extractable Value) Exploitation: Since transactions are privately submitted to validators, there's potential for MEV strategies to be executed in complete darkness. This creates a "dark forest" where validators or block producers may front-run or reorder transactions for profit without scrutiny.

• Lack of Fair Ordering: In Ethereum, public mempools at least give everyone a chance to compete for transaction ordering (via tips or gas auctions). In Solana, transaction ordering depends on validator discretion, which can favor private order flow arrangements or internal validator operations.

• Centralization Pressure: Entities that can strike deals with validators for priority access or protection from MEV may have a significant advantage. This may incentivize centralization around powerful validators or private transaction relayers.

So, the transaction before getting published to onchain ledger is done in a complete block-market/offchain way where block space can be purchased by getting in touch with validator or geospatially co-locating with the validator for faster inclusion.

So, how does a normal user who doesn’t know the validator personally can include his/her/its transaction without having any favour from the validator - SPAM

Spam is the biggest problem of Solana due to 3 main factors - extremely cheap costs ,extremely high TPS due to parallel thread execution and random inclusion of a transaction in any of the multiple parallel threads which leads to lock of the states. Anyone who want to include a transaction in a block can spam as many transaction as possible maybe for the MEV or maybe just to frontrun a NFT mint or maybe to arbitrage b/w 2 Liquidity pools.

Solana tries to mitigate this with

• priority fees(similar to ETH) and

• Stake Weighted QOS which states that all the transaction coming from various RPC’s to current leader/block producer will be weighted in the ratio of how much Solana is staked by the RPC counterparty Validator(it is a way to associate a RPC with the Validator that owns the RPC) which again centralizes the transaction inclusion process with advantage of effective spam protection through small RPC’s.

Jito is following Flashbot’s model for offchain block-space markets to mitigate this to some degree where it let the pre-made batch of transactions called bundles to be submitted to a validator which solves the two-fold problem that, it enhances the share of MEV that goes to the validator by multiple folds ass the usual priority fee is very small and due to lot of spams normally validator can’t make up how much MEV is being extracted, so in short democratizing the access to MEV to Validators and in subsequent ways to normal users.

This also de-incentivizes spammers to to spam more as the private flow of blockspace in an already private chain(i.e. Solana) has become somewhat more public because:-

• It is beneficial for Validators as they get more share

• It makes the blockspace more open and public

And to top upon all of this, there is no SLASHING for malicious validators where maliciousness can come from various ways as this is a more of a private market.

And one more factor is there i.e. Epoch wise Validator pre-determination where all the validators for 2 days are chosen at once according the stake quantity which makes validators predictable and incoming transaction unpredictable which gives us quite interesting dynamics with Ethereum’s unpredictable Validators and predictable incoming transaction(due to public mempool)

Other things such as forks are common in both with Solana having much more due to much more block production and recently features such TVS(timely Voting Slashing) a and couple of proposals( 1 & 2)

This all things makes the co-ordination plays on Solana much more interesting and nuanced which ulimately makes MEV also much more interesting

So let’s took a look at that shall we now, but first layout the questions which are common for both ETH and SOL

• Per attack profit and cost analysis(low tx. cost)

• Which venues are targeted(memecoins etc.)

• As Solana separates the program logic with the token account or wallet, so which programs are used by how many bots

• And the contribution of Validator in facilitating the sandwiches either through Jito or normally

And some new questions unique to Solana

• Sandwiching in multiple slots as a Validator is block-producer for continuous 4 slots/block and pre-determined validator schedule for the whole epoch

• Validator - Protocol wars where each protocol has validators of there own and try to disturb other protocol’s transaction because of stake weighted doing of things

And some open questions

• Reverse Sandwiching / Futures-like manipulation

• Can sandwich be done between multiple pools cause of low cost of aggregation of routes?

• Can sandwiching be done within in small parts like buying in a single txn and then selling in multiple txn’s(maybe not because the order of transaction is determinant and to maximise profit there should be a single txn) - this may happen if there is some probability of randomness(either due to txn ordering or validators can be multiple reasons)

We would go the data route for this as Richard Feynman wanted us to go, yayy!!

I made a Dashboard on Flipside(better prompts than Dune, lmeow) but most of them have lower time-frame because of data indexing limitations, so let’s look at the primary metrics:-

The data suggests sophisticated, high-frequency trading strategies targeting market inefficiencies, with concentrated activity on platforms like Raydium and PumpSwap cause because of most volume in memecoins only with direct co-relation with most volume

And there is a significant involvement of validators which can be seen firstly through the skewed profit distribution among sandwich bots and then examining the distribution of the top bot’s sandwich among validator used.

An interesting thing to notice here the average sandwich returns which are more or less same for all with

• Modest returns between 0.04 and 0.20 WSOL

• Exponential distribution of profits

• Rare but significant profit spikes exceeding 1 WSOL

Now, coming onto some new questions which are specific to Solana

• Multiple Slot sandwich - Sandwiching in multiple slots as a Validator is block-producer for continuous 4 slots/block and pre-determined validator schedule for the whole epoch.

A “cross-block sandwich” would require:

Buying in block n → The victim’s txn in block n+1 (with you knowing this in advance) → Selling in block n+2

And let’s limit this to 4 slot difference only(multiple slot is also possible but that would take much more co-ordination and capital), this is assuming that you know future order flow, which is only possible if:

• You control or collude with a validator in block n+1

• There's out-of-band info leakage (e.g., private orderflow, off-chain OTC coordination)

This is essentially validator-level corruption, and it has happened (e.g., through Jito relays or dark MEV deals), but is rare, let’s look into this

To extract this data, I modified the original sandwich attack detection query with the following changes:

• Relaxed the block constraint: Instead of requiring both the buy and sell swaps to occur within the same block, I expanded the condition to allow a maximum difference of 4 blocks between the two transactions.

• Time and block delay metrics: I added calculations for the average number of blocks and average time (in seconds) between the entry (buy) and exit (sell) transactions of each sandwich pair.

• Profit segmentation: I split the analysis into:

  • Single-block sandwiches (where both swaps happen in the same block)

  • Multi-block sandwiches (where swaps are up to 4 blocks apart)For each category, I computed the total and average profit in WSOL.

• Outcome:

The outcome is as expected not much of multi block Sandwich is happening due to factors, first is that normal sandwiches are still plenty profitable and second that the extreme high number of transactions which are going in to the validator through multiple RPC overpower the computation needed for multi-block sandwich

So yes, multi-block sandwiching is theoretically possible, but it’s more like “dark MEV games” or time-delay attacks but with advancement in bandwidth and MEV game getting more and more exposure hence making the game difficult will definitely make this a future possibility.

• Validator - Protocol wars - There is low possibility of this as there are no reports for this as such and need extensive data and the reason for this not happening is that the portion of the pie for gas fee is still pretty big

And normally the failure rate of total transaction on Solana goes upto 50% which is mostly due failed arbitrages which are spammed and even if we go deep in a suspected big validator who is getting more failure rate than other can be accounted to various reasons other than protocl-validator wars such as:-

• Running or colluding with aggressive MEV searchers or arbitrage bots

• Relaying bundled transactions with tight slippage windows

• Hosting high-frequency trading strategies that rely on speculative execution

• Supporting private RPC endpoints where spam strategies are more feasible

• Participating in priority fee auction strategies that create localized congestion

And it is very hard to get data based evidence for that with current tech and anonymous validators and spammers

Now getting to open questions for both EVM and Solana MEV

• Reverse Sandwiching / Futures-like manipulation - this opens up a whole field of advanced MEV and adversarial trading, this looks similar to normal MEV but is very different is very relevant in all of the decentralized perp-dex and need an article of it’s own(maybe next), let’s look how it is done

  • Reverse Sandwich (aka "anti-sandwich") is where:

    • You sell before a large buyer

    • They push price up

    • You buy back after

  This works when:

  • You expect a large buy (e.g., liquidation, whale trade)

  • You position ahead of them, pushing price lower

  • After they buy, price pumps — you buy back

  This is very less relevant in Ethereum because of high transaction costs and no major perp-dex there, every perp-dex either has it’s own chain or shifts to high throughput chains like Solana

• Multiple transaction sandwich - Can sandwiching be done within in small parts like buying in a single txn and then selling in multiple txn’s, it is very low possibility because the order of transaction is determinant and to maximise profit there should be a single txn to be more determinant - this may happen if there is some probability of randomness(either due to txn ordering or validators can be multiple reasons), this is not done currently due to many reasons:-

  • You risk partial fills

  • You can lose the race condition to another MEV bot or fail atomicity

  • It’s harder to ensure exact ordering unless you're in control of the full block

But the future of MEV is bright as Multiple slot sandwiches, multiple transaction sandwiches, validator-protocol MEV wars are very possible in the future when normal MEV goes very less profitable for a single actor when the game gets divided into multiple actors like in PBS model