Incident Report: Sandwich Attack Patch
TL;DR The Minswap Team was alerted to a sandwich attack being perpetrated by a malicious actor on the DEX. The attack exploited the ordering process of the batching used by the DEX. The appropriate safeguards have been put in place to refrain this attack from being perpetrated. We explain the attack and the prevention measures in full detail below.
As was described in our Laminar article, Minswap’s scalability solution uses off-chain batching to execute several orders in the same transaction. Now, the transactions included in a certain batch are done so in an order which is determined through an ordering process algorithm. It is very important to highlight that the surface of the attack was precisely this ordering process algorithm used for batching, and not a group of “insiders” or the Minswap team which conducts the batching of UTXOs.
Current analysis indicates the attack started on the 21st of November and spanned 880 trades for a total profit of around 11k ADA.
Sandwich Attack Explanation
When ordering transactions on the Minswap DEX, the batcher software will select orders in a first-in-first-out fashion. The batchers are run by trusted entities (currently only Minswap Labs) to ensure correct ordering of the transactions. However, within the same batch, the orders were executed by the default ordering of ledger inputs (lexicographically). This means that prior to the attack, the off-chain ordering process algorithm ordered transactions by their TX hash in ascending order. This is the surface that was used to perpetrate the Sandwich Attack.
Since transactions are ordered by TX hash, a frontrunner could create a transaction to buy or sell an asset at a price that takes advantage of an existing transaction, by simply composing a transaction with a smaller TX hash. For example, if a user created a transaction to buy an asset with a 1% slippage tolerance, a frontrunner could create a transaction to buy the same amount just prior, causing the original user to lose their 1% tolerance.
Sandwich Attack Example
To understand the attack better, let’s consider an example. Suppose there are 6 pending transactions on the DEX for a specific pair, and a user decides to spend 100k ADA on buying an asset with a 2% slippage tolerance. The user creates the transaction and the TX hash starts with “34df…”.
As soon as the user enters their transaction, a frontrunner can compose their own transaction to buy exactly the amount that would cause the original user to lose their 2% slippage tolerance (hence why it is called a Sandwich Attack). The attacker would simply have to monitor Cardano’s mempools (which is public information) and provided that they’re connected to enough relays on the blockchain, they can see most of the transactions before they get on-chain.
Now, the only thing the frontrunner needs to do is create a transaction with a smaller TX hash, which can be easily achieved by looping over different TX parameters and choosing the one that gives the best TX hash (in this case, as close to “0000000…” so this transaction is picked up first by the algorithm).
As such, both the frontrunner’s transaction (TX hash “0000000…”) and the transaction from the user (“34df…”) would be included in the same block. When they are about to get batched, the first transaction to be executed will be the one with the smallest TX hash (the frontrunner’s transaction). Once the swap is complete, the frontrunner simply has to sell the asset back, earning a profit at the expense of the user.
Solution and Lessons Learned
It is important to highlight that it is the “default setting” in the Cardano blockchain that transaction inputs are re-ordered based on TX hash. As such, the decision to order transactions based on TX hash in the batching algorithm was purely done so for optimization purposes.
After fully investigating the attack pattern and understanding how the malicious actor was able to perform a sandwich attack, the solution was simple: we just had to add in the off-chain batching algorithm the logic that the lexicographic order of orders within the same batch has to be the same as the chronical order of orders. This means it’s no longer the TX ID that orders transactions.
As indicated, current analysis indicates the attack started on the 21st of November and spanned 880 trades for a total profit of around 11k ADA. We have reached out to other DEXs in the ecosystem to ensure they are not vulnerable to this same attack.
We would like to thank the community members who alerted us of this issue. We truly appreciate having such an active and careful community that alerted us and the rest of the community of the attack that was being perpetrated.
