2

Reference https://github.com/OpenZeppelin/exploit-uniswap

Apparently, an years ago, there was reentrancy exploit on uniswap that was caused by ERC777 functionality: "Technically, the main logic behind these two incidents is the incompatibility between ERC777 and those DeFi smart contracts, which might be misused by the attacker to utterly hijack a normal transaction and perform additional illicit operations."

There are some other records of ERC777 causing major exploits in Uniswap, I wasn't able to confirm if it was the same case like this, and if it was legit in general, here is the little review from openzeppelin forum: https://blog.openzeppelin.com/exploiting-uniswap-from-reentrancy-to-actual-profit/ that might be the most trusted source so far.

The question is since V3 contracts came out, was this fixed? Did they make ERC777 compatible with new contracts?

P.S I will ask around with Uniswap support too and will post an answer if I get one, I'm sure this is a very sensitive subject and must be answered ASAP

1 Answer 1

3

I can't guarantee that this attack vector isn't possible anymore but I can guarantee that Uniswap states the following in their Uniswap v2 whitepaper

Uniswap v1 also makes the assumption that calls to transfer() and transferFrom() cannot trigger a reentrant call to the Uniswap pair contract. This assumption is violated by certain ERC-20 tokens, including ones that support ERC-777’s “hooks” [5]. To fully support such tokens, Uniswap v2 includes a “lock” that directly prevents reentrancy to all public statechanging functions. This also protects against reentrancy from the user-specified callback in a flash swap, as described in section 2.3.

But I highly recommend that you write your own tests for Uniswap and your ERC-777 token on a testnet to be on the safe side.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.