ERC-777

What Is ERC-777?

ERC-777 is an Ethereum token standard for fungible crypto assets that adds transfer hooks, operator permissions, transaction data, and safer contract-receiver checks to the basic token model.

Like ERC-20, it represents interchangeable units in which one token unit has the same value and properties as another unit of the same token.

The official ERC-777 specification is a Final Ethereum Request for Comments standard created to improve how fungible tokens interact with wallets and smart contracts.

Its main features are the

function, sender and recipient hooks, authorized operators, built-in burn functions, and optional data attached to token movements.

ERC-777 was designed to remain backward compatible with ERC-20 so one token contract could support both interfaces.

However, ERC-777 has seen limited adoption compared with ERC-20 because its callback behavior and ERC-1820 dependency make integrations more complex and can introduce serious reentrancy risks.

Is ERC-777 Still an Active Standard?

ERC-777 remains listed as a Final standard in the official Ethereum Improvement Proposal repository.

Final status means the specification completed the EIP standardization process, but it does not guarantee broad adoption, active library support, or suitability for every new token.

A major smart contract library deprecated its ERC-777 implementation in version 4.9 and removed the implementation from version 5.0.

The current OpenZeppelin Contracts changelog records the end of implementation support, while the related standard interfaces remain available.

This library decision did not cancel ERC-777 or change its Final status.

It does mean that developers should not expect a maintained ERC-777 token implementation in current versions of that library.

Existing ERC-777 contracts can continue operating according to their deployed code, but new integrations should evaluate their callback behavior, dependencies, audits, and ecosystem support carefully.

Why Was ERC-777 Created?

ERC-777 was created to address several usability and safety limitations associated with basic ERC-20 transfers.

An ERC-20 transfer to a contract does not require the recipient contract to acknowledge or process the tokens.

This can leave tokens trapped when a contract has no function for recovering or accounting for them.

ERC-20 applications also commonly use a two-step flow in which a user first approves a spender and then the spender calls

.

ERC-777 introduced

so tokens could be transferred with attached data while notifying a compatible recipient in the same transaction.

It also introduced operators as a named authorization model for accounts or contracts that move tokens on behalf of holders.

The standard aimed to make fungible tokens behave more like native ETH transfers while giving senders and recipients programmable control over token movements.

How ERC-777 Works

An ERC-777 contract stores token balances and total supply while exposing standardized functions for sending, burning, and delegating token control.

When tokens are sent, the contract checks whether the sender has registered a sender hook through ERC-1820.

If a sender hook exists, the token calls it before changing balances.

The token then decreases the sender’s balance and increases the recipient’s balance.

After updating balances, it checks whether the recipient has registered a recipient hook and calls that hook when required.

A hook can accept the movement, perform additional logic, or revert the entire transaction.

Because the operation is atomic, a revert in a required hook normally cancels the token movement and all related state changes from that transaction.

Core ERC-777 Functions

The ERC-777 interface includes functions for token metadata, balances, granularity, operators, transfers, and burns.

The

, , , and functions provide information familiar from ERC-20 tokens.

The

function reports the smallest indivisible amount that can be minted, sent, or burned.

The

function returns operators authorized for all holders by default, subject to each holder’s right to revoke them.

The

function checks whether one address may act as an operator for a particular holder.

The

and functions let a holder manage operator authority.

The

and functions move tokens, while and permanently reduce supply.

The send Function

The

function lets a holder transfer tokens directly to another address and attach a bytes field called .

The attached data can describe a payment, application action, reference number, or other information that the receiving system understands.

The function triggers registered sender and recipient hooks according to ERC-777 rules.

When the recipient is a contract, a native ERC-777 send must revert if the contract has not registered an ERC-777 recipient implementation through ERC-1820.

This receiver check is intended to reduce accidental transfers to contracts that cannot handle the tokens.

It does not prove that a registered recipient is honest, secure, or economically safe.

The operatorSend Function

The

function allows an authorized operator to move tokens from a holder to a recipient.

The operator must already be authorized for that holder under the token’s operator rules.

The holder-provided

and operator-provided can both travel with the movement.

The operator address, holder, recipient, amount, and data are included in the standardized

event.

An unauthorized operator call must revert.

Operator authority should be treated as sensitive because it can allow another address to move or burn the holder’s tokens.

What Is an ERC-777 Operator?

An operator is an address authorized to send or burn ERC-777 tokens on behalf of a holder.

The token holder is always an operator for its own balance.

A holder can authorize another account or smart contract and later revoke that authorization.

Operators can support automated payments, contract-based account management, scheduled activity, recovery systems, or other delegated token workflows.

Unlike a numeric ERC-20 allowance, normal operator authorization is not limited to one specified token amount.

This broader authority can improve usability but creates greater loss potential if the operator is malicious or compromised.

A wallet should clearly explain that authorizing an operator can grant ongoing control over the holder’s balance.

Default Operators

An ERC-777 token can define default operators that are initially authorized for every holder.

The default-operator list must be fixed when the token contract is created and cannot later be expanded or reduced under the standard.

Each holder must be able to revoke a default operator for that holder’s own tokens.

A holder must also be able to reauthorize a previously revoked default operator.

Default operators can support system-wide services without requiring every holder to perform an initial authorization transaction.

They also create a major trust consideration because a default operator begins with broad authority across token holders.

Users should inspect the default-operator list and understand the operator’s purpose before holding a significant amount of an ERC-777 token.

Sender Hooks

The ERC-777 sender hook is called

.

A holder can register a contract that implements this hook through the ERC-1820 registry.

The token contract must call the hook before decreasing the holder’s balance during an ERC-777 send or burn.

The hook receives the operator, sender, recipient, amount, holder data, and operator data.

It can inspect the proposed movement and revert when the holder’s programmed rules reject it.

A smart wallet could use a sender hook to apply spending policies, notifications, or additional authorization logic.

The hook contract must verify that calls come from an expected token contract because the same registered hook can receive calls involving different ERC-777 tokens.

Recipient Hooks

The ERC-777 recipient hook is called

.

A receiving address can register a contract that implements this hook through ERC-1820.

The token calls the hook after increasing the recipient’s balance during a send or mint.

The hook can update internal accounting, trigger another contract action, record payment data, or reject the receipt by reverting.

This design allows a token transfer and a recipient’s response to happen in one atomic transaction.

It also means that receiving ERC-777 tokens can execute external code before the original token call finishes.

Any protocol that receives ERC-777 tokens must account for this callback behavior in every relevant state-changing function.

What Is ERC-1820?

ERC-777 relies on ERC-1820 to discover sender hooks, recipient hooks, and supported interfaces.

The ERC-1820 specification defines a universal registry in which an address can publish which interfaces it supports and which contract implements them.

The registry can represent interfaces for ordinary accounts as well as smart contracts.

An account can register itself as the implementer or designate a separate contract to handle an interface on its behalf.

Before calling an ERC-777 hook, the token queries the registry for the relevant sender or recipient implementation.

This registry dependency adds an external contract lookup to ERC-777 operations.

A supported network must have the expected ERC-1820 registry deployment and integration behavior for a standard implementation to work correctly.

ERC-777 Events

ERC-777 defines

, , , , and events.

The

event identifies the operator, sender, recipient, amount, holder data, and operator data.

The

event records new token creation and the receiving address.

The

event records token destruction and the affected holder.

Operator events allow wallets and monitoring services to track changes in delegated authority.

A token that also supports ERC-20 may emit ERC-20

events in addition to the ERC-777 events required by the specification.

Applications should avoid double-counting one economic movement when both event types describe the same transfer.

Granularity and Decimal Display

Granularity is the smallest internal token amount that an ERC-777 contract permits for minting, sending, or burning.

The value is set when the contract is created and cannot change under the standard.

Every balance and movement amount must be a multiple of the token’s granularity.

Most tokens use a granularity of one, which permits every whole internal unit to move.

ERC-777 defines its display denomination as 18 decimal places relative to the internal unit.

If an ERC-777 token also exposes the optional ERC-20

function, the specification requires it to return 18.

Applications should use integer arithmetic and format values for display rather than calculating token balances with floating-point numbers.

ERC-777 and ERC-20 Compatibility

ERC-777 was designed so a token could implement ERC-20 functions alongside the ERC-777 interface.

The ERC-20 standard defines familiar functions such as

, , , and .

A dual-compatible token can work with older wallets and applications that understand only ERC-20.

ERC-777 hooks can still apply to compatible ERC-20 transfers when the relevant sender or recipient has registered a hook.

However, the contract-recipient protection differs between the two interfaces.

A native ERC-777

to an unregistered recipient contract must revert, while an ERC-20-compatible transfer may continue and leave the tokens at that contract.

Integrators must identify which function is being called instead of assuming that every movement of the same token has identical callback and receiver behavior.

ERC-777 vs. ERC-20 Allowances

ERC-20 commonly gives a spender a numeric allowance that limits how many tokens the spender can transfer from an owner.

ERC-777 gives an operator authority over a holder’s balance until that authority is revoked.

The operator model provides a clearer named role and supports standardized send and burn actions.

The allowance model can provide a narrower amount limit, although users sometimes approve amounts much larger than needed.

Both systems can create losses when users authorize malicious or compromised contracts.

Wallets should show whether an action creates a fixed allowance, an unlimited allowance, or ERC-777 operator authority.

Revoking one permission type does not necessarily revoke the other when a token supports both standards.

ERC-777 Reentrancy Risk

The most important ERC-777 integration risk comes from its hooks.

A recipient hook executes external contract code during the token transfer process.

That external code can call back into the sending protocol before the protocol’s original function has finished.

This behavior is called reentrancy.

A vulnerable protocol may calculate a balance, send ERC-777 tokens, receive a callback, and allow the callback to repeat an action using stale internal accounting.

The problem can appear even when the protocol calls an ERC-20-style function because a dual-compatible ERC-777 token may still invoke registered hooks.

Developers should never assume that a fungible token transfer is free from callbacks merely because the function name resembles a normal ERC-20 transfer.

Reducing Reentrancy Risk

A protocol should update its own critical accounting before making an external token call whenever the intended logic permits that order.

It should use a suitable reentrancy guard around sensitive entry points.

Related functions must be reviewed together because blocking reentry into one function may still leave another function exploitable.

The protocol should validate the token contract rather than accepting arbitrary assets with unknown callback behavior.

Tests should include a malicious sender hook, malicious recipient hook, nested token movement, reverted callback, and cross-function reentry.

Developers should also review minting and burning paths because ERC-777 hooks are not limited to ordinary sends.

An audit can reduce risk but cannot guarantee that every callback interaction is safe.

Receiver Protection and Its Limits

ERC-777 receiver checks were intended to reduce tokens becoming permanently stuck in contracts that cannot process them.

A contract receiving tokens through

must register an ERC-777 recipient implementation or the operation reverts.

This is stronger than a basic ERC-20 transfer, which can succeed even when the receiving contract has no token-handling logic.

However, registration proves only that an implementation was registered for the interface.

It does not prove that the recipient records balances correctly, allows withdrawals, or has passed a security audit.

A malicious recipient can intentionally accept tokens and then apply harmful logic.

Users must still verify the destination contract and the purpose of the transaction.

Benefits of ERC-777

ERC-777 can notify contracts when they receive fungible tokens.

It can combine transfer and recipient processing in one transaction.

It lets senders and recipients reject movements through programmable hooks.

It supports attached data that applications can use to interpret a payment or action.

Its operator model provides standardized delegated control and explicit revocation.

Native ERC-777 sends reduce accidental transfers to contracts that do not register token-receiver support.

Backward compatibility can allow one token to work with ERC-20 infrastructure while offering more advanced behavior to ERC-777-aware applications.

Limitations of ERC-777

Hooks make token movement harder for smart contracts to reason about safely.

The ERC-1820 lookup adds an external dependency and additional integration complexity.

Operator authority can be broader than users expect.

Default operators introduce an important trust and permission consideration.

Dual ERC-20 compatibility creates different behavior depending on which transfer interface is used.

Applications can double-count transfers when they process both ERC-777 and ERC-20 events incorrectly.

Many current development tools and applications focus mainly on ERC-20, reducing the practical benefit of implementing ERC-777.

The removal of a maintained ERC-777 implementation from a widely used contract library increases the work required to build and maintain a new deployment safely.

Why ERC-777 Saw Limited Adoption

ERC-20 already had deep support across wallets, applications, analytics tools, and smart contract systems when ERC-777 was introduced.

Replacing that network effect required benefits large enough to justify new callback and registry logic.

Many protocols were built around predictable ERC-20 transfer and allowance behavior.

ERC-777 hooks introduced unexpected external calls into operations that integrators sometimes assumed were simple balance updates.

The motivation section of ERC-2612 notes that ERC-777 added substantial functionality that could create unexpected behavior in mainstream contracts.

Developers increasingly addressed individual usability problems through narrower ERC-20 extensions rather than adopting an entirely different transfer lifecycle.

ERC-777 therefore remains technically important but is not the default fungible-token choice for most new Ethereum projects.

Should Developers Create a New ERC-777 Token?

A developer should first identify which ERC-777 feature is essential to the proposed token.

If the main goal is signed approvals, a narrower ERC-20 extension may provide that feature without introducing universal transfer hooks.

If recipient callbacks are necessary, the developer must examine whether a purpose-built application contract can provide safer and more explicit behavior.

A new ERC-777 implementation requires careful review of the complete specification, ERC-1820 registration, hooks, operators, events, minting, burning, and ERC-20 compatibility.

Reusing an old unmaintained implementation without reviewing compiler changes and known security assumptions is unsafe.

The contract should receive extensive unit testing, fuzz testing, invariant testing, integration testing, and independent security review before controlling valuable assets.

Developers should also confirm that intended wallets, custody systems, bridges, and decentralized applications support the token’s callback behavior.

How Users Can Evaluate an ERC-777 Token

The first step is to verify the token’s contract address through an authoritative source.

The second step is to confirm whether the contract supports only ERC-777 or also exposes ERC-20 functions.

The third step is to inspect the default operators and determine what authority they hold.

The fourth step is to review minting, burning, pausing, freezing, upgrading, and administrator permissions.

The fifth step is to determine whether the contract uses a proxy whose logic can change after purchase.

The sixth step is to check audits, source-code verification, test coverage, and incident history.

The seventh step is to inspect operator authorizations and revoke permissions that are no longer required.

The eighth step is to verify that the receiving application explicitly supports ERC-777 and its hooks.

The ninth step is to test a small transaction before transferring a significant amount.

The tenth step is to remember that compliance with a token interface does not prove financial value, solvency, or investment safety.

Example of an ERC-777 Payment

Suppose a user wants to pay an on-chain subscription contract with an ERC-777 token.

The subscription contract registers an

implementation through the ERC-1820 registry.

The user calls

with the contract address, payment amount, and encoded subscription reference.

The token checks for the user’s sender hook and calls it before changing balances when one is registered.

The token decreases the user’s balance and increases the subscription contract’s balance.

It then calls the contract’s

hook with the payment details.

The subscription contract verifies the token address, payer, amount, and attached reference before extending the subscription.

If the hook rejects the payment, the complete transaction reverts and the token balances return to their earlier state.

This workflow demonstrates the atomic payment-and-notification feature that motivated ERC-777.

Common ERC-777 Mistakes

One common mistake is assuming that ERC-777 is simply a newer replacement for ERC-20.

Another mistake is treating a token transfer as a callback-free operation.

A third mistake is accepting calls to

without verifying the calling token contract.

A fourth mistake is authorizing an operator without understanding that the permission can cover the holder’s full balance.

A fifth mistake is ignoring default operators defined at token creation.

A sixth mistake is processing both

and events as separate economic movements.

A seventh mistake is sending tokens to a contract through the ERC-20 interface and assuming ERC-777 receiver protection will force a revert.

An eighth mistake is deploying an old implementation without modern testing and dependency review.

A ninth mistake is assuming that Final EIP status means current library support or broad ecosystem adoption.

A tenth mistake is treating standards compliance as proof that a token is legitimate or secure.

FAQ

What does ERC-777 mean?

ERC-777 is a Final Ethereum fungible-token standard that defines hooks, operators, data fields, token sends, and token burns.

Is ERC-777 fungible or non-fungible?

ERC-777 is a fungible-token standard in which units of the same token are interchangeable.

Is ERC-777 still valid?

Yes, the official proposal remains Final, although adoption is limited and a major contract library removed its ERC-777 implementation.

Is ERC-777 the same as ERC-20?

No, ERC-777 adds hooks, operators, attached data, and receiver checks, although a token can support both standards.

What is the main feature of ERC-777?

Its best-known feature is the ability to notify registered sender and recipient contracts during token movements.

What is tokensReceived?

is the recipient hook called after an ERC-777 balance is increased through a send or mint.

What is tokensToSend?

is the sender hook called before an ERC-777 balance is reduced through a send or burn.

What is an ERC-777 operator?

An operator is an address authorized to send or burn tokens on behalf of a holder.

Can an ERC-777 operator move all of a user’s tokens?

Normal operator authority is not a numeric allowance, so an authorized operator may have broad control until the holder revokes it.

What is a default operator?

A default operator is an address authorized for every holder at token creation, although each holder must be able to revoke it personally.

Why does ERC-777 use ERC-1820?

ERC-1820 lets the token discover which contracts implement sender hooks, recipient hooks, and supported token interfaces.

Can ERC-777 tokens be sent to a smart contract?

Yes, but a native ERC-777 send must revert when the recipient contract has not registered the required recipient hook.

Can ERC-777 tokens become stuck in a contract?

Receiver checks reduce this risk for native sends, but ERC-20-compatible transfers and faulty recipient logic can still create inaccessible balances.

Does ERC-777 have decimals?

The standard uses an 18-decimal display denomination, and an optional ERC-20-compatible

function must return 18.

What is ERC-777 granularity?

Granularity is the smallest internal amount that can be minted, sent, or burned.

Why can ERC-777 cause reentrancy?

Its hooks execute external contract code during token operations, allowing a recipient or sender implementation to call other functions before the original call finishes.

Is every ERC-777 token unsafe?

No, but every integration must deliberately handle callbacks, operator permissions, ERC-1820 lookups, and token-specific contract logic.

Why was the ERC-777 implementation removed from OpenZeppelin Contracts?

The implementation had limited adoption and its complex hook behavior was difficult to support safely as a general-purpose component.

Can an existing ERC-777 token continue working?

Yes, deployed contracts continue according to their code unless their own upgrade or administration mechanism changes them.

Should a new token use ERC-777?

The decision depends on whether hooks and operators provide essential benefits that justify the added security, integration, and maintenance complexity.

Conclusion

ERC-777 is a Final Ethereum fungible-token standard designed to improve token interactions through hooks, operators, transaction data, and contract-recipient checks.

Its

function can transfer tokens and notify a compatible receiving contract in one atomic transaction.

The

and hooks allow programmed sender and recipient rules.

Operators provide standardized delegated control, while default operators can offer system-wide functionality subject to holder revocation.

ERC-1820 supplies the registry used to discover these hooks and interfaces.

ERC-777 can remain compatible with ERC-20, but transfers through the two interfaces do not always have identical receiver behavior.

The same callback features that improve composability can enable reentrancy and make integrations difficult to reason about.

Developers must verify callers, protect all related state-changing functions, inspect operator authority, test malicious hooks, and understand the complete transfer lifecycle.

Although the standard remains Final, its limited adoption and removal from a major current contract library make it a specialized rather than default choice for new tokens.

Understanding ERC-777 helps crypto users and developers recognize both the benefits of token callbacks and the security risks created when fungible-token transfers can execute external code.