Deprecate ERC777 implementation
See original GitHub issueš§ Motivation
There is an opinion that ERC777 is over-engineered and is a bad practice to follow. Moreover it introduces bad abstractions to rely on and requires very important checks to be implemented by every integrator.
Letās switch to EIP2612 (Permit) to deprecate dangerous infinite approve behavior and make it mainstream ASAP: https://github.com/OpenZeppelin/openzeppelin-contracts/contracts/token/ERC20/extensions/draft-ERC20Permit.sol
š Details
Do we need to collect list of issues? Starting here:
-
Whole idea of avoiding spam tokens by having hook function is wrong. It is not possible to protect from spam tokens because developers of these tokens will always modify their tokens to allow spamming ā just ignore them.
-
Token fallback concept is wrong because the callback is being called from token smart contract and there is no way to verify who was the original
msg.sender
. There are so many possible ways to abuseERC777Receiver
. The only way to solve it I see ā work with whitelisted tokens only ā DeFi deserves better approach. Imagine you have DEX and wanna deposit token and do custom action (swap):function tokensReceived( address operator, address from, address to, uint256 amount, bytes calldata userData, bytes calldata operatorData ) external override { address token = msg.sender; balances[token][operator] += amount; _performSwap(operator, operatorData); // <- `operator` is not trustworthy, due `msg.sender` can be malicious smart contract } function _performSwap(address user, bytes memory data) internal { // ... }
Issue Analytics
- State:
- Created 2 years ago
- Reactions:14
- Comments:50 (34 by maintainers)
We donāt think it should be OpenZeppelin Contracts making the decision to deprecate the ERC.
Weāre happy to include comments in our documentation about the downsides and alternatives.
For actual deprecation, weāre happy to host the discussion here, but ultimately we feel that a deprecation requires a more ecosystem-wide consensus.
Hello @k06a, As a developper working with ERC777 during hackathon, I can only agree that this standard creates a lot of frustration ⦠and can result in very gas-extensive transactions.
However, deprecating contract breaks backward compatibility. This is not something we would consider doing during a āminorā release. The latest major release was v4.0, less then a month ago. Thus, we wouldnāt move with anything like that before a while.
Still, Iād love to build a case for/against ERC777 (and other contract that might not be relevant). This will help us taking decision whenever we fell like moving to the next major version.