Badgers are known to take the same routes when they are out foraging for food during the night. This creates well-worn paths through fields and woods.
When a badger’s usual path is disturbed or obstructed in some way, this confuses the animal, and results in them rebasing to the incorrect pairing.
After researching further, we found that although there had been an exploit, the damage had already been contained, and what had been perceived as a threat to the entire SushiSwap protocol was simply a smart scavenger picking up food that had been left behind.
An already known wallet was taking advantage of an old loophole that had reopened due to a moment of forgetfulness by the SushiSwap team.
Although the transaction that caught our eye seemed alarming at first, once we spoke to the Sushi team, it became clear there was no huge cause for concern.
The transaction showed SushiMaker attempting to convert 0.05% of the DIGG/WBTC swap fees (for ~24hrs) through a DIGG/ETH pool with little liquidity and suffering high slippage, resulting in outsized fees for the liquidity providers of the DIGG/ETH pool.
These are fees that would have been paid to XSUSHI holders, but went to the attacker instead.
How did this happen?
Although a solution had been created some weeks earlier, it had to be applied manually along with each new pool. As this had not been applied, the scavenger was able to sneak in and take fees which should have gone to xSushi holders.
When new pairs were added in Sushiswaps’ Onsen, some non-ETH pairs were added, but no "bridge" was set up in the SushiMaker for DIGG/WBTC.
SushiMaker is the contract that takes 0.05% of trading fees and passes them on to users who have staked SUSHI as xSUSHI to earn additional SUSHI rewards without impermanent loss.
By default SushiMaker sells the accumulated fees (and their pairs) to ETH and then to SUSHI.
The bridge means that when SushiMaker sells the fees of an asset without an ETH pair, it can do so to an asset other than ETH that has appropriate liquidity.
Without a bridge, liquidity could be added to create an ETH pair through which SushiMaker would attempt to convert the fees for that asset and subsequently suffer a high price impact due to the small amount of liquidity.
This results in the fees accumulated up to that SushiMaker "serving" rewarding the liquidity providers for that ETH pair as opposed to the xSUSHI participants.
Fortunately, no underlying LP or xSUSHI positions were affected, only the earnings for the affected asset (0.05% fees for DIGG/WBTC swaps - 81 ETH) from the previous day were lost.
A bridge has been set up for DIGG through the maker contract to resolve this issue for xSUSHI participants. This bridge is also included in SushiMaker.
A conversation in the Sushiswap Discord gave us more insight into the mechanics of the exploit:
We analysed the address of the scavenger and found him to be a known user of bots and flash loans.
Data from Nansen
We found several transactions showing that this actor had been attempting to take advantage of this loophole and steal the LP fees.
What could have been a disaster turned out to be a slight humiliation for the Sushi team.
Although the attacker was successful in their exploit, we can consider this a close call for SushiSwap, who currently have $1.9B TVL to protect.
The conversation in Discord stating that they won’t be automating this fix and will continue to rely on remembering to apply it each time is somewhat concerning.
Why allow scope for human error if it’s not needed?
Although the code may be decentralised, developers take on huge responsibility when they work on protocols with such huge TVL. The effects of stress are often underestimated and we see many developers fall victim to “burn out”. There are many things that can go wrong when coding, so perhaps Sushiswap would benefit from some automation here.
This story serves as a reminder that protocols are under constant watch by hackers and arbitrageurs, who follow their every move and try to pick their pockets or knock them out completely.
However, this inspection goes both ways - even amateurs such as Twitter user “simp2win” can watch the hackers from afar. Their effort is commendable, but perhaps they should leave the analysis to the experts.
We love a hacker who has something to say, so we were pleased to see them send the following message via Ethereum call data.
REKT serves as a public platform for anonymous authors, we take no responsibility for the views or content hosted on REKT.
Donate (ETH / ERC20): 0x3C5c2F4bCeC51a36494682f91Dbc6cA7c63B514C
REKT is not responsible or liable in any manner for any Content posted on our Website or in connection with our Services, whether posted or caused by ANON Author of our Website, or by REKT. Although we provide rules for Anon Author conduct and postings, we do not control and are not responsible for what Anon Author post, transmit or share on our Website or Services, and are not responsible for any offensive, inappropriate, obscene, unlawful or otherwise objectionable content you may encounter on our Website or Services. REKT is not responsible for the conduct, whether online or offline, of any user of our Website or Services.