Raising Slippage Too Fast Out of FOMO? Jaredfromsubway.eth Could Put a Target on You!

3 Examples Show You How Jared Finds His Victim.

In the article Performance Appraisal of Jaredfromsubway.eth, we underscore Jared Bot's skill in using altcoin tokens. He employs them in sandwich attacks, generating profits of over $6.3 million since the launch. This article highlights the potential risks of hastily increasing slippage after a transaction failure. Specifically, it highlights the danger of becoming a target of Jared's attacks. In volatile market conditions, it's crucial to avoid recklessly raising the slippage and to stay alert to potential losses from sandwich attacks by trading bots.

Our EigenTx transaction visualizer plays a critical role in the analysis. Please feel free to download its use cases to find out how it can benefit your daily trading.

FOMO Makes You Vulnerable

Users often feel an urgent need to trade after a failed transaction for various reasons. One significant factor is the fear of missing out (FOMO), a common emotional response in financial markets. Users may strongly desire to participate and not get left behind when they see others making profits or spot a potential opportunity. This eagerness comes from believing they can recover their losses or secure potential gains by quickly entering another trade.

When a user's trade fails, they often feel tempted to increase the trade slippage to ensure the success of their resubmitted trade. This behavior allows Jared to launch sandwich attacks when users repeat these transactions. As users typically raise the slippage settings on subsequent trades, Jared can take advantage of this and maximize his profits.

The entire attack process unfolds in three key steps:

1. User's trade failure: The user primarily experiences a trade failure due to their low tolerance for slippage. The trade doesn't proceed as expected, leading to disappointment and a desire to rectify the situation.

2. User's increased slippage and trade resubmission: Motivated by the urgency to secure the desired price, the user decides to increase the slippage and resubmit the trade. They still see the value of the investment but choose a more flexible approach to avoid repeating the same mistake.

3. Jared bot's sandwich attack after slippage increase: Jared launches a sandwich attack on the user's resubmitted transaction. The user, eager to close the deal, had increased the slippage, allowing Jared to reap larger profits.

A common pattern occurs when a user's transaction to purchase a low-priced token enters the mempool, catching Jared's attention. Using his simulated front-running (censorship) mechanism, Jared deduces that this transaction will likely fail. Moreover, considering the significant purchase amount and potentially higher transaction fees, the bot speculates that the user's transaction sentiment is driven by a sense of urgency to acquire tokens, with less sensitivity to price fluctuations quickly. As a result, Jared launches an attack when the user resubmits the transaction. Although the above model is merely a conjecture based on the operational mechanics of the Sandwich bot, Jared's attack on the "slippage up trade" behavior allows him to generate higher profits.

In our research, we manually examined transactions where the 'block_number_diff' was a single digit, which led us to uncover several clues. Here, we will present a few examples highlighting the dangers of hastily increasing slippage.

Example1: Desiring INU via UNI

First is the failed transaction.

• Hash: 0x5e10ddb26018035f4174d44c15759030a327e08e4dbf8f63aa0d1ecbc0353df1

• Block_Number: 17412598

• From_Address : 0xAa1142709C149aae2ce961b6C6Fc85De2b5ec6b8

• To_Address: 0xb45A2DDA996C32E93B8c47098E90Ed0E7ab18E39

Then the victim transaction:

• Hash: 0xf0d939141e85fded068d6da9366d32cfe8231c8b77f5a4bf3971f48f89f1174c

• Block_Number: 17412602

• From_Address: 0xAa1142709C149aae2ce961b6C6Fc85De2b5ec6b8

• To_Address: 0xb45A2DDA996C32E93B8c47098E90Ed0E7ab18E39

More specifically, the "To" address of the transaction is TransitSwapRouterV4, and it involves swapping WETH for INU using Uniswap V2: Router 2. The transaction throws an error, stating "TransitSwap: insufficient return amount," because of a preceding transaction initiated through the Router. This prior transaction involved buying a significant amount of INU, which caused the token's price to rise beyond the pre-set slippage tolerance. Consequently, the final return amount fell below the specified minReturnAmount.

By analyzing the input content of FailTx and Resubmit Tx, we found the following results:

From the values of minReturnAmount/amount, we can see that after the initial transaction failed, the user adjusted the slippage and resubmitted the transaction. It successfully confirmed on the chain after 4 blocks and fell victim to Jared's sandwich attack. Analysis from EigenTx shows that in the end, Jared only spent $6.80 to earn a revenue of $19.75, yielding a staggering return of 190.44%.

Example2: Buying INU via 1inch

Let’s take a look at another failed transaction.

• Hash: 0xb062430f3bec8b661cae6207728149f1430c1fa6cafdd746cad3ee7aa79c8fde

• Block_Number: 17412588

• From_Address : 0x2a5031CF78af9a6eB3aD252A623E2A317e3993f5

• To_Address: 0x1111111254EEB25477B68fb85Ed929f73A960582

The victim transaction:

• Hash: 0x8745aa1c31ec12bae8ecf3c4e38a67f945af72cc1274ef9602ea3b037f176ad3

• Block_Number: 17412589

• From_Address: 0x2a5031CF78af9a6eB3aD252A623E2A317e3993f5

• To_Address: 0x1111111254EEB25477B68fb85Ed929f73A960582

To be precise, the "To" address of the transaction was 1inch v5: Aggregation Router, and it involved exchanging WETH for INU in UNI-V2. The transaction failed due to "ReturnAmountIsNotEnough." By analyzing the input content of both the FailTx and VictimTx, we found the following results:

From the values of minReturnAmount/amount, we can see that after the initial transaction failed, the user adjusted the slippage and resubmitted the transaction. The subsequent attempt succeeded and was confirmed in the following block. However, Jared's bot launched a sandwich attack against this transaction. Analyzing the EigenTx results, it's clear that Jared spent $57.95 to earn revenue of $66.23, resulting in a profit of $8.28. This translates to a remarkable return on investment of 14.25%.

Example3: bitcoin

The 3rd example involves bitcoin, well, not that Bitcoin. The failed transaction first:

• Hash: 0x27518e65d2895a79f5f760fa6c0d9c3e813b74f42d96b6e89ae082948058b9ea

• Block_Number: 17442646

• From_Address : 0x8c6704645654Ff80C4CB5c58F772B4c2dcCDfd56

• To_Address: 0x3fC91A3afd70395Cd496C647d5a6CC9D4B2b7FAD

The victim transaction:

• Hash: 0xc28d0b0364d1c45af9bd470a4630dffd55577227b2ae4fda86b1e754d342f54e

• Block_Number: 17442653

• From_Address: 0x8c6704645654Ff80C4CB5c58F772B4c2dcCDfd56

• To_Address: 0x3fC91A3afd70395Cd496C647d5a6CC9D4B2b7FAD

Specifically, the "To" address of the transaction was Uniswap: Universal Router, which involved exchanging BITCOIN for WETH in UNI-V2. The transaction failed due to "V2TooLittleReceived." By analyzing the input content of both the FailTx and VictimTx, we found the following results:

We can gain insight from the minReturnAmount/amount values. After the initial transaction failed, the user adjusted the slippage tolerance and reinitiated the transaction. This subsequent attempt succeeded and was confirmed in the following block. However, Jared's bot launched a sandwich attack against this transaction. A closer look at the EigenTx results shows that Jared spent $15.51 to earn revenue of $18.97, netting a profit of $3.46. This translates into a significant return on investment of 22.31%, an outcome of substantial interest.

How did we find these out?

Jared's strategy involves cross-block information, making it incredibly difficult to trace any evidence of his actions.

We break down the task into the following aspects:

1. Identify all transactions (VictimTx) that Jared subjected to sandwich attacks between June 5 and June 11. The total number of transactions subject to the sandwich attack between June 5 and June 11 was 37,110.

2. Identify all transactions (FailTx) that failed due to "execution reverted" within the week of June 5 to June 11. We found that any transactions based on routers like Uniswap Router and 1inch Router, if they involve an insufficient return amount, will ultimately result in the error being classified as "execution reverted” There were 271,022 failed transactions between June 5 and June 11, of which 268,970 were reported as "execution reverted".

3. Retain all data where the block_number of the failed transaction is smaller than the block_number of the transaction targeted in the sandwich attack. Additionally, introduce a new column called block_number_diff and keep only the data where block_number_diff is smaller than 15. The former condition selects the attack after the failed transaction, while the block_number_diff serves as an indicator - if it is too large, it implies a weaker causal relationship between the two transactions. In the subsequent manual investigation, sorting the data by block_number_diff in ascending order will be a more efficient approach. A block_number_diff below 15 suggests that the time gap between the two transactions is less than 3 minutes, which aligns with a reasonable time for individuals to reconsider, decide on slippage, and resubmit their transactions. The number of transactions corresponding to a sandwich attack on the “from” address within the next 15 blocks is 9153.

4. Check that the "From" and "To" addresses of the attacked transaction are the same as the "From" and "To" addresses of the failed transaction and that there is no sandwich attack by another person in between. The number of transactions where the "From" and "To" addresses of the attacked transactions are the same as the "From" and "To" addresses of the failed transactions and where there are no sandwich attacks by others in between is 8890.

5. Sort the data according to the first 10 bits of INPUT, find the one with the most at first, and then Parse the INPUT data to extract the Tokens, AmountIn, and AmountOutMin for each transaction. The Top Five first 10 bits of INPUT are:

The final number of transactions successfully parsed for INPUT content is 4545.

6. Check if the failed transaction and the sandwich-attacked transaction involve the same token. Since Tokens encapsulate a list containing the transaction tokens being traded, they inherently carry transaction sequence information. Consequently, when matching Tokens are identified, it suggests a substantial degree of correspondence between the Failed Transaction (FailTx) and the Targeted Transaction (VictimTx). Out of 90 failed transactions fitting our criteria, 80 have been targeted by Jared within the past 15 blocks, accounting for an impressive 88.9%.

Who Caused the Failed Transactions?

In practical terms, the Router initiates the transactions that seem to make users fail. In other words, based on the currently available findings, it's unlikely that bots are involved.

We researched 100 consecutive blocks ranging from block number 17410600 to 17410699. We found that over 70% of these blocks involved failed transactions of Morty, a token associated with smaller cryptocurrencies. For example, in block 17410624, we identified the transactions with hashes 0x8d65a684be4a8bae2bef3db2b88a7c13bbec1f3a6439e2efddc4cbe950c05a94 and 0xb0f058b3dfcc1916159b581757ee86c430c39cc51f4ab6ab96f6c37611dd16d4 as failed transactions.

Upon analysis, we discovered that a transaction initiated by Uniswap: Old Universal Router with the hash 0x86a0998ee944356f136d81aee2d88c568c303b88b8f37bc87a3a8ff7a3074d8f caused these failed transactions. This transaction involved swapping 1 ETH for 239,449,158,677,312.7200 Morty tokens, which resulted in a price surge for Morty. Consequently, the slippage settings in the aforementioned failed transactions were inadequate, leading to their failure. Hence, most of these failed transactions can be attributed to the enthusiasm of investors driven by the issuance of lower-priced tokens.

In theory, for the Sandwich Bot to intentionally cause a user's transaction to fail, it would need to front-run the user's transaction, which inherently carries risks for the bot itself. Instead, the bot might find it more advantageous to wait for market frenzy or congestion, target the user's adjusted slippage, and resubmit the transaction after the initial failure.

Any other MEV Bots like Jared?

Based on our analysis results, transactions from Jared the bot account for 88.9% of highly suspicious trades. While we found other bots exhibiting similar suspicious behavior, their numbers are significantly fewer than Jared's. We identified the address 0x0000cf7a76d3e41656cc2ac4005016008d470000 engaging in potential sandwich attacks between blocks 17412588 and 17412619. Here are the details:

Take Your Time, Not Risks

From the analysis in this article, it's clear that when users hastily increase their slippage following a failed transaction, they make profits for Jared. This piece aims to enhance users' understanding of "transaction failures" and "slippage settings" when trading low-value tokens while underscoring the potential risk of mindlessly ramping up the slippage only to fall prey to Jared's attacks. It serves as a reminder for users to exercise caution and avoid impulsive decisions when adjusting their slippage settings, thus warding off unnecessary losses.

There is much more to discover about jaredfromsubway.eth, such as:

• Does Jared prefer certain pools and tokens while exploiting users' emotions for Sandwich attacks?

• What special techniques or strategies does Jared use to generate such significant profits?

• Are any bots intentionally front-run others' trades to cause them to fail and engage in Sandwich Attacks? If you want to find answers to these questions, please stay tuned for our future analysis.

And don’t forget to download its use cases to find out how it can benefit your daily trading!!

---

Follow us via these to dig more hidden wisdom of DeFi:

Website | Discord | Twitter | YouTube | Substack | Medium | Telegram | EigenTx