ERC-777

The tokensReceived and tokensToSend hooks allow for arbitrary code execution during transfers, creating a classic reentrancy risk. A malicious contract receiving tokens can call back into the sender's contract before the initial transfer is finalized, potentially draining funds. This is similar to the vulnerability exploited in the 2016 DAO hack but is a fundamental design aspect of ERC-777's hook system.

ERC-777 introduces operators—addresses authorized to send tokens on behalf of a holder. This creates a trust and centralization risk:

• A compromised operator can drain all tokens from accounts that authorized it.
• Users may inadvertently grant excessive permissions to poorly secured dApps or contracts.
• The standard requires explicit user approval for each operator, but UX patterns can obscure this risk.

ERC-777's advanced features can break compatibility and create integration hazards:

• Backwards Incompatibility: Not all ERC-20 wallets and exchanges support ERC-777, leading to potential fund loss if sent to an incompatible address.
• Unexpected Behavior: Contracts expecting simple ERC-20 transfers may malfunction when interacting with ERC-777's hook logic, causing failed transactions or locked funds.
• The standard requires extra validation in integrating contracts to safely handle both token types.

A critical design flaw in the initial proposal was the discrepancy between implicit and explicit balances. The tokensToSend hook could prevent a debit, but the tokensReceived hook could reject a credit, leaving the total supply invariant but individual balances in an inconsistent state. This could be exploited to create tokens from nothing or freeze funds. Later implementations and the final standard require rigorous checks to mitigate this.

The hook mechanism significantly expands the attack surface of a token contract:

• Each transfer becomes a potential interaction with an external, untrusted contract.
• Gas costs are unpredictable and can be driven high by malicious hook contracts, leading to failed transactions or denial-of-service.
• Auditing is more complex as the token's state can be altered by callback logic outside the main contract, breaking standard invariant checks.

To use ERC-777 securely, developers should adopt specific mitigation strategies:

• Apply the Checks-Effects-Interactions pattern rigorously to prevent reentrancy in hook implementations.
• Use ERC777Sender and ERC777Recipient interfaces correctly to signal and validate hook support.
• Implement a strict allowlist or circuit breaker for operators to limit blast radius.
• Thoroughly audit any contract implementing hooks, treating them with the same scrutiny as a main contract function.

The defining feature of ERC-777 is the tokensToSend and tokensReceived hooks. These are functions called automatically in the sender's and recipient's contracts, allowing for atomic, conditional logic on transfers.

• A decentralized exchange can receive tokens and instantly trade them in a single transaction.
• A smart contract wallet can require multi-signature approval before allowing tokens to be sent.
• This prevents the common ERC-20 pattern where users must first approve and then call a separate function, reducing complexity and gas costs for certain operations.

ERC-777 introduces the concept of operators—trusted addresses (like smart contracts) authorized to send tokens on a user's behalf. This is more granular than ERC-20's blanket approve function.

• An auction contract can be authorized as an operator to transfer a user's tokens only if they win a bid.
• A payment processor can be set as a default operator for all users, streamlining subscription payments.
• Operators can be revoked individually, providing better security and control over delegated spending.

ERC-777 tokens are designed to be backward compatible with the ERC-20 standard. They implement all required ERC-20 functions, meaning they can interact with every wallet, exchange, and contract that supports ERC-20.

• Wallets like MetaMask can hold and transfer ERC-777 tokens using the standard interface.
• Decentralized exchanges (DEXs) built for ERC-20 can list ERC-777 tokens without modification.
• This compatibility was crucial for adoption, allowing the new standard to leverage the massive existing ERC-20 ecosystem.

Golem Network migrated its GNT token to the ERC-777-compliant GLM token. This migration showcased key ERC-777 benefits:

• Atomic Swaps for Payments: Providers on the Golem network can receive GLM tokens and, via the tokensReceived hook, automatically register the payment and release computational results in one transaction.
• Enhanced Utility: The hook system allows the Golem smart contract infrastructure to react programmatically to incoming payments, creating a more seamless user experience compared to the previous ERC-20 model requiring multiple steps.

The ERC-777 standard includes built-in mitigations for a reentrancy attack vector it could introduce. The tokensReceived hook, if not carefully implemented, could allow malicious contracts to re-enter the token contract during a transfer.

• The standard mandates the ERC1820 registry to securely identify which contracts implement hooks.
• Developers must follow the checks-effects-interactions pattern rigorously in their hook logic.
• This proactive design addresses the type of vulnerability famously exploited in The DAO hack, making the ecosystem more secure when hooks are used correctly.

While both are advanced token standards, ERC-777 and ERC-1155 (Multi Token) serve different primary use cases.

• ERC-777: Focuses on enhancing fungible tokens with transaction hooks and operators. Ideal for sophisticated financial applications and improving user experience for a single token.
• ERC-1155: Focuses on gas efficiency for batch operations and managing both fungible and non-fungible tokens within a single contract. Ideal for gaming asset marketplaces and projects issuing large collections.
• ERC-777's hooks provide deeper, per-transfer programmability, while ERC-1155 optimizes for scalability and mixed asset types.

The foundational fungible token standard on Ethereum that ERC-777 is designed to improve upon. It defines the core interface for transferring tokens and checking balances.

• Key Differences: ERC-20 lacks the send/receive hooks and operator model of ERC-777.
• Backward Compatibility: ERC-777 tokens are designed to be compatible with wallets and exchanges that only support ERC-20, but require careful implementation to avoid security issues.

A core innovation of ERC-777. These are functions that are automatically called when tokens are sent to or received by a contract.

• tokensToSend: Called in the sender's contract before debiting their balance.
• tokensReceived: Called in the recipient's contract after crediting their balance.
• Purpose: Enables contracts to automatically react to token movements, allowing for atomic, complex interactions like paying for a service immediately upon receipt of tokens.

Trusted addresses authorized to send tokens on behalf of a token holder, a concept expanded from ERC-20's approve/transferFrom.

• Granular Control: Users can authorize specific operators for specific amounts.
• Use Case: Essential for decentralized exchanges (DEXs) and payment processors to move tokens without requiring multiple transactions from the user.
• Revocable: Users can revoke an operator's permission at any time.

A critical, universal registry contract that enables the ERC-777 hook system to function without requiring prior knowledge of recipient interfaces.

• How it Works: Contracts implementing hooks register their interface with the ERC-1820 registry.
• Discovery: Before transferring tokens, the ERC-777 contract queries this registry to see if the recipient has registered hook functions.
• Foundation: This decentralized interface discovery mechanism is what makes ERC-777's backward-compatible hooks possible.

A major security consideration for ERC-777 due to its callback (hook) mechanism, similar to risks in ERC-1155 and ERC-721.

• The Risk: The tokensReceived hook can call back into the token contract before its state is fully updated, potentially allowing recursive, malicious withdrawals.
• Mitigation: Requires the use of Checks-Effects-Interactions pattern or reentrancy guards (like OpenZeppelin's ReentrancyGuard) in both the token and receiving contract logic.

A related standard that defines an interface for payable tokens, enabling token transfers with callback execution on the recipient in a single transaction.

• Similar Goal: Like ERC-777, it aims to combine transfer and action atomically.
• Different Approach: ERC-1363 uses explicit transferAndCall functions rather than implicit hooks, offering a different trade-off in design complexity and security model. It is often seen as a simpler alternative for specific payment use cases.