Is ERC777 and Uniswap drama resolved?

Question

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

Answer 1

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.