Exploring Sandwich Attacks on Solana
A common scenario: You find a promising coin on Solana. The market cap is still low ($50K) with high growth potential. You decide to pull the trigger and swap your SOL for the token. However, as you do this, something unexpected happens — the market cap suddenly jumps to $200K as your transaction is executed, then immediately drops back to around $50K, meaning you took an instant 75% loss on the token. What happened? Well, you’ve just been sandwiched.
Sandwich attacks are a popular MEV strategy and a common problem in AMM crypto markets, collectively costing users millions of dollars. In a sandwich attack, a bot detects your transaction and strategically places its own orders to profit at your expense. Essentially, the bot spots your transaction before it’s included in the block, places a buy order just before yours to push the price up, and then places a sell order right after your transaction, pocketing the difference and leaving you with a higher cost per token.
JITO-Based Sandwich attacks
There are several ways in which sandwiches may be executed on Solana, with one of the most popular methods being the use of Jito bundles. Jito is a platform on Solana designed to help validators make transactions more efficient and profitable by prioritising them based on their value. One of Jito’s key features is the ability to bundle transactions together, ensuring they are executed in a specific sequence. This capability can be exploited by malicious MEV bots to create bundles with sandwiched transactions, taking advantage of other users’ trades.
Analysis of a real-world sandwich attack
Let’s take a closer look at this real world example of a Jito bundle:
This is a classic example of a sandwich attack. A trader submitted a buy transaction that was sandwiched between two malicious transactions submitted by an MEV bot, and bundled together using Jito.
Now, let’s examine the sandwiched transaction:
As we can see, this is a standard Raydium swap involving WSOL (Wrapped Solana) and a token called SOLYMPICS.
Let’s take a closer look at the Raydium swap instruction data:
Here, we can see that a user submitted a swap transaction of ~7.86 WSOL for a minimum of approximately 650 tokens. Both Wrapped SOL (WSOL) and SOLYMPICS have 9 decimals. Therefore:
7885514939/9¹⁰ = ~7.89 SOL
650525758183/9¹⁰ = ~650.52 tokens
Given the token price at the time of the user’s transaction, they should have received approximately 650,000 tokens, implying a 99% slippage! (As an aside, my guess is that they may have had the wrong decimal settings for this token — 6 instead of 9 — and it was supposed to be set to 650k, but that’s not the focus of this article.)
This scenario is ideal for an MEV bot: they can manipulate the price as much as they want, as long as the user receives at least 650.525 tokens for their transaction. Typically, MEV bots maximise their extractable value by pushing the price right up to the slippage boundary. In the case of our example, the slippage was so exorbitantly high that the bot operator didn’t have enough SOL to fully exploit it.
The example I’ve picked is interesting for another reason: the bot first bought approx. 25.8 million tokens for 1007.99 SOL and then proceeded to sell just enough to cover the cost — 25.44 million tokens for 1009.14 SOL (the original cost plus a 1.15 SOL Jito validator tip).
This leaves us with 402,000 tokens worth approximately $1,000 for the bot operator. Most bots would dump the entire token amount immediately, but this suggests a more sophisticated, targeted approach. The bot operates on a selected set of tokens that the bot owner (or an algorithm) believes have growth potential and can be sold for a higher price in the future. Nevertheless, the principle remains the same: buy before the regular user, dump right after their buy, and cash out the difference.
Back to our user — well, tough luck for them. We can track the sell transaction to reveal the unfortunate truth. Even though the price has increased since their purchase (not accounting for the spike caused by the MEV bot), they were only able to sell their tokens for 0.8 SOL, resulting in a total loss of over 7 SOL (a -90% loss).
How are MEV bots able to send their own transactions along with users’ transactions as a single bundle?
As previously mentioned, Jito operates a custom type of validators connected to a Jito block engine and relayer, which accept both regular transactions and pre-made Jito bundles. Bundles are sets of transactions executed atomically and in sequence, meaning the entire set is either executed or not at all, making existing bundles unmodifiable. However, individual transactions can be attached to a bundle made by someone else. This is precisely what sandwich bots do — they create a buy transaction, a sell transaction, and inject the user’s transaction in between.
Because Jito processes transactions using a mempool-like off-chain mechanism, with each transaction residing there for approximately 200 milliseconds, malicious searcher programs have ample time to identify vulnerable transactions and bundle them with their own buy and sell transactions. The Jito Foundation is aware of this issue and, as a result, disabled features such as the mempool stream, which made it harder for malicious MEV bots to identify opportunities. It was a significant step, but it didn’t take long for MEV bot operators to discover alternative solutions.
Quick note on leader scheduling
For a better understanding of the issue, it is worth noting that Solana operates differently from most blockchains. In a conventional blockchain, miners compete to produce a block, and theoretically, any miner on the network has a chance to build any block. Instead, Solana uses a leader rotation mechanism, where only one validator node is able to produce a block at any given time. The leader schedule is known in advance, allowing us to predict who the next block producer will be (see “further reading” section for more info).
Sandwiching outside of JITO
Although the number of JITO validators is growing rapidly, not every validator on the Solana network runs a JITO client, meaning not every leader can produce bundles. So, if a transaction goes through a non-JITO validator, are you safe? Not quite. Sandwich attacks can still occur through other methods. The vanilla Solana Labs validator, like other building blocks of Solana, is open-source. This means that the default validator code can be modified, and as long as the changes are compatible, a custom validator can be launched on the Solana network alongside other validators. Consequently, it is possible to alter the code so that when a validator gains a leader slot, it reorders transactions to exploit MEV opportunities, including launching sandwich attacks, during the so-called banking stage. Here’s an example of such validator. Validators running such a client can front-run transactions, executing their own transactions before and after yours, thereby manipulating prices to their advantage.
Preventative methods
So, are we all doomed? Not necessarily. Several preventative methods, if executed correctly, can help you avoid being sandwiched:
- First of all, remember that sandwiches occur primarily when swapping wrapped Solana for another token (buying a token), not the other way around. Launching sandwich attacks when selling a token would require MEV bots to first buy and hold, then sell, and then rebuy the asset, which is riskier in the case of most memecoins due to inherent price fluctuations. In practice, this is very rare.
- When submitting a swap instruction manually, ALWAYS remember to set appropriate slippage (the minimumAmountOut parameter) so that even if you get sandwiched, there’s a limit to the damage done. You don’t want to be the person from our example. Double-check your decimals and make sure the slippage is appropriate.
- Use Jito bundles. Remember that Jito bundles are atomic — they can’t be edited, and either all transactions go through or none at all. This makes bundles an effective way to prevent MEV. The number of Jito validators is growing rapidly (Over 80% of Solana’s total stake is held by validators running Jito-Solana), thus it is an efficient method of sending swap transactions.
- Another preventative measure involves using services like the bloXroute API, which combines a traditional anti-MEV technique of sending Jito-bundled transactions with an optional function (fastBestEffort) of sending transactions to low-risk non-Jito leaders. BloXroute maintains its own database of validators deemed unlikely to use custom Solana validator clients for MEV extraction.
- Most Solana bots incorporate the anti-MEV techniques mentioned above. This includes our own Telegram bot, CaishenApp. If you are looking for a way to trade safely and efficiently, click here to sign up
In conclusion, sandwich attacks continue to be a significant concern within the Solana ecosystem, with various execution methods such as Jito-based bundles and custom validators. These attacks can manipulate transaction sequences and exploit users through sophisticated means. However, there are effective measures to mitigate their impact. Utilising Jito bundles can prevent transaction manipulation by ensuring atomic execution. Additionally, services like bloXroute offer another form of protection by routing transactions through trusted validators. It’s also a good practice to set appropriate slippage parameters to limit potential losses. By understanding and implementing these anti-MEV techniques, you can enhance your trading safety and efficiency on the Solana network.
