# ERC-777

## Gather feedback before influencing

* who already used the ERC777 interface?
* is it a useful improvement over ERC20?
* aware of other EIPs improving ERC20? (ERC223, ERC667, permit EIP, ?)

## History


### [ERC-20](https://eips.ethereum.org/EIPS/eip-20) - end 2015
Pretty minimal, pretty liberal.

### [ERC23/223](https://github.com/ethereum/EIPs/issues/223) early 2017
Wanted to fix _people losing tokens due to bad UX_, e.g. sending to token contract itself. [Happening to this day](https://twitter.com/geeet_eth/status/1487739969422585857).
Already [concerns about the safety of callback](https://github.com/ethereum/EIPs/issues/223#issuecomment-285421887) (This was the year after [TheDAO blew up](https://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/)). Probably killed by ERC-20 incompatility][1](https://github.com/ethereum/EIPs/issues/223#issuecomment-325738654), [2](https://github.com/ethereum/EIPs/issues/223#issuecomment-344655054) - Nick Johnson: feels like bandaid - [warning against hazards for devs](https://github.com/ethereum/EIPs/issues/223#issuecomment-335374020) - [consensus failure declared in Dec](https://github.com/ethereum/EIPs/issues/223#issuecomment-348425189)
[This!](https://github.com/ethereum/EIPs/issues/223#issuecomment-326433427)

### [ERC-677](https://github.com/ethereum/EIPs/issues/677) - mid 2017

Simple addition of

transferAndCall(address receiver, uint amount, bytes data) returns (bool success)

with callback handler

function onTokenTransfer(address from, uint256 amount, bytes data) returns (bool success)

Never made it beyond draft, but was implemented e.g. by [POA/xDai Tokenbridge](https://docs.tokenbridge.net/).

### [ERC-777](https://eips.ethereum.org/EIPS/eip-777) - end 2017

Made it (final)!
* Wants to be a comprehensive update to ERC-20.
* Full lifecycle - adds minting and burning
* Addition of data fields
* Hooks (one-tx-transfer-with-callback, fine grained control)
* relies on [ERC-1820](https://eips.ethereum.org/EIPS/eip-1820) and [ERC-165](https://eips.ethereum.org/EIPS/eip-165) (registry, interface detection)

Also see: [Master Thesis about ERC-777](https://github.com/0xjac/master-thesis/blob/master-pdf/JacquesDafflon-masterthesis.pdf)

**The difference for new contracts implementing ERC-20 is that tokensToSend and tokensReceived hooks take precedence over ERC-20. Even with an ERC-20 transfer and transferFrom call, the token contract MUST check via ERC-1820 if the from and the to address implement tokensToSend and tokensReceived hook respectively. If any hook is implemented, it MUST be called. Note that when calling ERC-20 transfer on a contract, if the contract does not implement tokensReceived, the transfer call SHOULD still be accepted even if this means the tokens will probably be locked.**

The EIP was discussed for a year - overall positive feedback, but some concerns about complexity.
The authors then became less responsive (frozen in crypto winter?), leading to delays. Also blocked by issues of its ERC-820 dependency.

[Declared final in May 2019](https://github.com/ethereum/EIPs/issues/777#issuecomment-490229544). OpenZeppelin impl immediately available.

Weeks later, [OpenZeppelin published a PoC exploit](https://blog.openzeppelin.com/exploiting-uniswap-from-reentrancy-to-actual-profit/) for Uniswap V1 abusing ERC-777 reentrancy, uncovered by a [previous audit of the protocol](https://github.com/ConsenSys/Uniswap-audit-report-2018-12#31-liquidity-pool-can-be-stolen-in-some-tokens-eg-erc-777-29).

Nevertheless, ~1 year later, drama unfolded.

First [Uniswap V1](https://blog.openzeppelin.com/exploiting-uniswap-from-reentrancy-to-actual-profit/) (~300k $ drained)
Then lendf.me (defunct) (~24m $ drained)

[Uniswap V2 Whitepaper](https://uniswap.org/whitepaper.pdf):
_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 state-
changing functions. This also protects against reentrancy from the user-specified callback
in a flash swap, as described in section 2.3.)_

I suspect that to this day many contracts make this assumption and that thus ERC-777 as is poses a hazard. May have gone differently had ERC-777 had more adoption.

TOGAv1 issue was also somewhat related.

Other reasons for little adoption:
probably considerably higher complexity than ERC-20 - especially considering the tooling available back then.
Chicken - egg problem with adoption. Contracts <-> wallets, exporers, ...

### Current relevance

Ethereum, ordered by token holders:
1. [C1ORP](https://etherscan.io/token/0xb1656c8fe15b1ac60760777a8e45f5d7cd1d24ec)
2. [imBTC](https://etherscan.io/token/0x3212b29e33587a00fb1c83346f5dbfa69a458923)
3. [pBTC](https://etherscan.io/token/0x5228a22e72ccc52d415ecfd199f99d0665e7733b)

### Super Token

Has an opportunity to upgrade to ERC-777 since it's extending ERC-20 anyway.
violating the standard vs hazard vs redefining the standard.
Redefining could also be an opportunity to extend, e.g. with meta-tx supporting functionality [[1]](https://github.com/ethereum/EIPs/issues/965).

Fran: what about callbacks in mint, burn, upgrade, ...
Miao: userdata could be a hint for callback