ERCs, Solved
the standard · since November 2017
// standard · token hooks · operator model · niche

What is ERC-777?

The fungible-token hook standard that exposed how hard receiver callbacks are to retrofit.

ERC-777 ·EIP-777 ·by Jacques Dafflon + Jordi Baylina + Thomas Shababi

updated · 2 min read · by ercs-solved maintainers

ERC-777 is what happens when the ecosystem recognizes that ERC-20 transfer is too silent. The standard gives senders and recipients hooks, and gives token holders operator controls.

[ jump to what's broken → ]
on this page
  1. What is ERC-777?
  2. At a glance
  3. Origin story
  4. The spec
  5. What's broken
  6. Hooks create reentrancy risk
  7. ERC-1820 became another dependency
  8. ERC-20 network effects were stronger
  9. LUKSO alternative
  10. ERC-777 vs LSP7+LSP1
  11. When to use which
  12. FAQ
  13. Sources
  14. Keep reading
at a glance

The standard, in one card.

Standard
ERC-777 / EIP-777
Core additions
tokensToSend · tokensReceived · operators
Discovery
ERC-1820 registry
Canonical spec
eips.ethereum.org / EIP-777
how the standard came to be

The origin story.#

The standard was proposed after ERC-20's receiver and approval problems were already visible. It aimed to make fungible tokens more expressive without throwing away the balance model developers understood.

the spec, end to end

What ERC-777 actually is.#

ERC-777 EIP-777 interface solidity 
function name() external view returns (string memory);
function symbol() external view returns (string memory);
function granularity() external view returns (uint256);
function totalSupply() external view returns (uint256);
function balanceOf(address owner) external view returns (uint256);
function send(address recipient, uint256 amount, bytes calldata data) external;
function burn(uint256 amount, bytes calldata data) external;
function isOperatorFor(address operator, address tokenHolder) external view returns (bool);
function authorizeOperator(address operator) external;
function revokeOperator(address operator) external;
function operatorSend(address sender, address recipient, uint256 amount, bytes calldata data, bytes calldata operatorData) external;
function operatorBurn(address account, uint256 amount, bytes calldata data, bytes calldata operatorData) external;
ERC-777 interface, grouped
holder: send · burn · authorizeOperator · revokeOperator
operator: operatorSend · operatorBurn
hooks: tokensToSend · tokensReceived

ERC-777 adds send, burn, operatorSend, and operatorBurn. Hooks are discovered through ERC-1820 so sender and receiver contracts can react to movement.

the integration tax

What's broken about ERC-777.#

The same hook that lets a receiver react also runs external code during token movement. That made ERC-777 harder to compose safely with DeFi contracts that were written around ERC-20's no-callback assumption.

  1. Hooks create reentrancy risk.#

    Calling sender and recipient hooks during token movement gives contracts useful context, but it also lets external code run in the middle of transfer flow. Integrators have to design for reentrancy.

    ERC-777 tokensReceived hook
    external call reentrancy
    LSP1 universalReceiver
    known hook surface account-aware
    workarounds tried
    • checks-effects-interactions
    • reentrancy guards
    • ERC-20 wrappers
    • hook allowlists

  2. ERC-1820 became another dependency.#

    ERC-777 uses the ERC-1820 registry for interface implementers. That gives dynamic discovery, but it is another global dependency that token integrators must understand.

    ERC-777 ERC1820Registry lookup
    global registry
    LSPs ERC-165 + ERC-725Y
    interface + typed data
    workarounds tried
    • registry checks
    • fallback ERC-20 paths
    • custom adapters

  3. ERC-20 network effects were stronger.#

    Most DeFi integrations standardized on ERC-20. A richer token interface had to either masquerade as ERC-20 or ask the ecosystem to integrate another surface.

    ERC-777 richer fungible token
    compat friction
    LSP7 new ecosystem surface
    designed stack
    workarounds tried
    • ERC-20 compatibility
    • adapter contracts
    • wrapped tokens
the LUKSO alternative

LUKSO designed it differently.#

LSP7 carries forward the receiver-aware idea while pairing it with LSP1, LSP4, and LSP6. The point is not a hook alone; it is the whole account and asset system around the hook.

spec to spec, at a glance

ERC-777 vs LSP7+LSP1 in one table.#

row ERC-777 LSP7 plus LSP1
fungible balance yes yes
receiver notification tokensReceived via ERC-1820 LSP1 universalReceiver
operator model authorizeOperator / revokeOperator operators plus LSP6 account permissions
metadata limited token fields LSP4 typed metadata
be honest about scope

When to use which.#

people also ask

FAQ.#

  • Is ERC-777 compatible with ERC-20? #

    ERC-777 was designed with ERC-20 compatibility in mind, but its hook behavior and ERC-1820 dependency make integrations different from plain ERC-20.

  • Why did ERC-777 adoption stay limited? #

    ERC-20 network effects were strong, and receiver hooks introduced reentrancy concerns that many DeFi protocols preferred to avoid.

  • What is the LUKSO alternative to ERC-777? #

    LSP7 covers fungible assets, LSP1 handles receiver notifications, LSP4 handles metadata, and LSP6 handles account-level permissions.

primary sources

Where this page draws from.#

  1. EIP-777
where to go next

Keep reading.#