ERC-777 Token Standard
Abbreviation: ERC-777
Pronunciation: EE-AR-SEE seven-hundred-seventy-seven
Also known as: ERC-777
Definition
ERC-777 defines fungible tokens with operator controls and send or receive hooks while preserving compatibility with core ERC-20 behavior. Hooks let contracts react to incoming or outgoing tokens and can prevent accidental transfers to unsupported recipients. They also create reentrancy and integration complexity, especially when older applications assume ERC-20 transfers do not execute recipient code.
Overview
Meaning and scope
ERC-777 defines fungible tokens with operator controls and send or receive hooks while preserving compatibility with core ERC-20 behavior. Hooks let contracts react to incoming or outgoing tokens and can prevent accidental transfers to unsupported recipients. They also create reentrancy and integration complexity, especially when older applications assume ERC-20 transfers do not execute recipient code.
Mechanism and operation
ERC-777 adds richer fungible-token interactions through send and receive hooks discovered through the ERC-1820 registry. Authorized operators can move tokens on behalf of holders, and transactions can carry data for application logic. Developers should authenticate operators, secure hooks, understand default operators, and apply checks-effects-interactions or reentrancy protection. Teams adopting ERC-777 should track errata, compatibility changes, and the deployed software versions that enforce it. Operational records for ERC-777 should retain the version and configuration used for each relevant transaction or message. When evaluating ERC-777, this allows reproducible debugging when a later upgrade changes parsing, validation, signing, or interoperability behavior.
Practical payment example
A contract integrating ERC-777 tokens tests recipient hooks and reentrancy defenses because token callbacks can invoke additional logic.
Operational checks
ERC-777 should be implemented against an exact document revision, status, and activation context. When evaluating ERC-777, draft, final, optional, and network-activated specifications have different authority, and similarly named deployments may support different subsets or extensions. Conformance to ERC-777 requires more than matching a field name or example.
Distinctions and limits
Payment processors should validate actual contract behavior and execution receipts rather than assuming ERC-20 compatibility makes every ERC-777 transfer operationally identical. When evaluating ERC-777, a published standard does not prove universal adoption, safe implementation, or activation on a particular blockchain or payment network.
Related reading
Related definitions: payment network, transaction.
Example
A contract integrating ERC-777 tokens tests recipient hooks and reentrancy defenses because token callbacks can invoke additional logic.
Comparison
They also create reentrancy and integration complexity, especially when older applications assume ERC-20 transfers do not execute recipient code. Payment processors should validate actual contract behavior and execution receipts rather than assuming ERC-20 compatibility makes every ERC-777 transfer operationally identical.
Key Takeaway
ERC-777 adds powerful token hooks and operators, but callback reentrancy, authorization, and compatibility require careful integration.
Sources
- Ethereum Improvement Proposal EIP-777 — Ethereum Foundation (2026-07-30)
- Ethereum Documentation: Smart Contracts — Ethereum Foundation (2026-07-30)
- Ethereum Documentation: Transactions — Ethereum Foundation (2026-07-30)