Can sombody explain why ERC777 was removed?

Given that when Fabien Vogelsteller launched LUKSO he used an ERC777 and not an ERC20 which he was a co-author of, it seems weird that the ERC777 should be removed from the OpenZeppelin libraries.

It may not be as popular as the ERC20 but I cannot even see any explanation as to its removal anywhere. The only arguments that I have heard is that it is possible to leave vulnerabilities if you use it wrongly - but that same argument can be applied to ERC1155 or 721's safetransfer.

1 Like

Hey @DaveAppleton,

The ERC777 contract was deprecated in 4.9 but not removed until 5.0
We did it this way for backwards compatibility reasons.

Regarding the reasons behind the removal, the ERC777 standard was created with the motivation of extending an ERC20 with hooks. This was allegedly in order to provide users more control over their ownership (eg. bypassing approve/transferFrom for a single hooked send call).

However, the hooks system in practice (among other features) became difficult to reason about and very error prone.

The potential vulnerabilities (although similar to ERC1155's and ERC271's cases) not only have to do with reentrancy when calling the acceptance check on the recipient (onERC*Received \ tokensReceived) but with reentrancy when calling the tokensToSend hook since it breaks the check-effects-interactions pattern.

It was solved with ERC1820 registry but at that point there was some community consensus that ERC777 was becoming over-engineered, a source of frustration, and better alternatives came out. You can see more of the discussion here.

Currently, the new _update mechanism in v5's ERC20 is more than enough for extending capabilities in a secure way

1 Like

Very annoying for projects that implement ERC777 for completely valid reasons and have taken care to do so correctly.

Can you elaborate on these valid reasons to use ERC777?

Perhaps a project using an ERC777 may find an alternative in other standards/solutions but I'd be interested in hearing if the removal left some needs unmet.

The issue is not with the project that implement tokens using ERC-777, its with the other projects/contracts that will interract with these tokens in a potentially dangerous way ... and all the user of account abstraction that have to deal with ERC-1820 registration.

So we need to protect people who cannot code properly?

Perhaps we should remove ERC1155 for the same reason and get rid of safeTransfer in ERC721?

When people send ETH they face exactly the same issues - that the contract that they are sending to can

  1. refuse the ETH
  2. commit a re-entrancy attack

This is why we have re-entrancy guard and teach people to update the state before sending. Nobody would argue that the receive function is a bad thing. ERC777 offers something similar to the ETH receive function.

Failing that, implement ERC677 so that we have an audited specific transferAndCall mechanism that can be used without the call being trigered on standard ERC20 operations.

This is even worse - we introduce a new standard that is problematic because we have an existing standard that makes it hard to implement and so junk the old standard and ignore its existence regardless of any old tokens that may be out there?

Its funny how you say "So we need to protect people who cannot code properly?" and then go on to justify re-entrancy guards, which IMO, are the best example of something you do when you don't code properly.

The issue with ERC-777 is not that its by itself unsafe, its that it reuses the ERC-20 interface to do there things. ERC-1155 has a safeTransfer that allow execution of arbitrary call on the receiver, but it uses a dedicated interface that is known to include that feature. ERC-777 will perform this arbitrary call when the caller thinks its performing a simple ERC-20 call.

Project like uniswap only relies on ERC-20. They should not have to worry that sometimes in the future, an alternative token implementation will appear compatible, but add features that are liability. That is what ERC-777 did on top of ERC-20, and it caused many issues.
Also, the fact that a smart contract nees to register in 1820 in order to be able to receive tokens is insane. I've seen wrapped BTC lost, because it was implemented as ERC-777, and users tried to send it to a smart wallet. The transaction reverted and the "wrapper bridge" did not include recovery systems.