ERC-777 is a fungible token standard, backwards-compatible with ERC-20, that added hooks — functions called on the sender and receiver during every transfer — and “operators” who can send tokens on a holder’s behalf. It aimed to fix ERC-20’s lost-token problem and enable richer payment flows. In practice, its hooks created re-entrancy risks that contributed to real exploits, and major libraries have since deprecated it. Understanding why helps you design safer RWA tokens.
Key takeaways
- Hooks (
tokensToSend,tokensReceived) are registered through the ERC-1820 registry. - Operators can move tokens for holders; default operators can be set at deployment.
- Hooks call external code mid-transfer, enabling re-entrancy against protocols that assumed ERC-20 behaviour.
- Today, prefer ERC-20 (with careful integrations) or ERC-1155 (hooks with known patterns) — and keep compliance logic inside the token, not in external hooks.
How it works
send(to, amount, data)replacestransfer, carrying data for the receiver.- Before balances change, the sender’s
tokensToSendhook is called (if registered); after, the receiver’stokensReceivedhook is called. - Contracts that do not register a receiver hook cannot receive tokens via
send, preventing accidental loss. authorizeOperator/revokeOperatorreplace allowances with full operator rights.
What went wrong
Many DeFi protocols integrated ERC-777 tokens as if they were ERC-20. The tokensToSend hook let attackers re-enter the protocol before state updated, draining liquidity in several incidents. Complexity (ERC-1820 dependency, operators, dual interfaces) also increased audit cost, and widely used libraries removed ERC-777 from new releases.
Lessons for RWA token design
- Avoid external callbacks in transfer paths where possible; where unavoidable (ERC-721/1155 receivers), apply checks-effects-interactions and re-entrancy guards.
- Keep compliance checks internal and view-only — e.g. ERC-3643 compliance modules or ERC-7943
canTransfer— rather than calling arbitrary user contracts. - Be explicit about operator powers; investors and regulators need to know who can move tokens.
- Design for integrators’ assumptions. If your token behaves differently from ERC-20, document it and test integrations. See smart contract audits for RWA.
Should you ever use ERC-777?
Rarely. If you inherit an ERC-777 token, review every integration for re-entrancy, consider wrapping it into ERC-20, and plan a migration. For new tokens, choose ERC-20, ERC-3643 or ERC-1155.
Anatomy of a hook-based re-entrancy
A simplified version of the pattern behind real incidents:
- A lending or AMM protocol calls
token.transferFrom(user, protocol, amount)and then updates its internal accounting. - Because the token is ERC-777, the transfer triggers the sender’s
tokensToSendhook before balances change. - The attacker’s hook re-enters the protocol (e.g. calls
borroworswapagain) while the protocol’s state still reflects the old balances. - The protocol pays out more than it should; the attacker repeats until funds are drained.
The root cause is an unexpected external call in what integrators assumed was a simple balance update. The same lesson applies to ERC-721 and ERC-1155 receiver hooks.
Defensive patterns for any token with callbacks
- Checks-effects-interactions: update state before making external calls.
- Re-entrancy guards on functions that move value.
- Pull over push: let users withdraw instead of pushing tokens in loops.
- Integration allow-lists: for regulated platforms, only integrate tokens whose behaviour you have reviewed.
Wrapping an inherited ERC-777 token
If you must support an existing ERC-777 asset, a common approach is a wrapper ERC-20: users deposit the ERC-777 token into a wrapper contract (written defensively) and receive a plain ERC-20 representation that your platform integrates instead. Redemption unwraps back to ERC-777.
Frequently asked questions
Yes, it implements the ERC-20 interface, which is precisely why integrations assumed ERC-20 behaviour and were exposed to hook-based re-entrancy.
Because of its complexity, ERC-1820 dependency and the security issues caused by hooks.
Receiver checks in ERC-721/1155, permit-style approvals (ERC-2612) and account abstraction (ERC-4337) cover most of its goals more safely.
Yes, by deploying a new token and offering a 1:1 swap or wrapper, with a snapshot and clear holder communication.
Only if the sender or receiver has registered hook implementations in the ERC-1820 registry; otherwise transfers behave like ERC-20.
ERC-1155 receiver hooks also call external code, so the same defensive patterns apply — but the risks are widely understood and handled by modern libraries.
NUVZ is the RWA and Web3 engineering brand of ESS ENN Associates (est. 1993). Our team has designed and shipped tokenization platforms for real estate, education loans, solar PPAs, energy, carbon credits, bank deposits and trade documents. About us · Case studies
This article is for general information only and is not legal, tax or investment advice. Token standards evolve — always confirm the current status of an ERC at eips.ethereum.org and take advice from qualified counsel in each jurisdiction before issuing tokens.
