{"id":"ERC-777","name":"Token Standard","status":"Final","chain":"both","category":{"id":"transaction-friction","name":"Transaction Friction","description":"Reducing clicks, signatures, and mental overhead"},"journeyStages":[{"id":"approving","name":"Approving & Permissioning","description":"Granting permissions for actions"},{"id":"executing","name":"Executing Transactions","description":"Performing on-chain actions"}],"uxImpact":"ERC-777 is a token standard with sender and recipient hooks plus operator permissions. It can support hook-aware transfers and operator-managed sends, but those semantics are different from ERC-1363 payable callbacks and ERC-4337 account-abstraction infrastructure. Treat adoption, integration, and hook reentrancy risk as separate design and security questions.","officialUrl":"https://ercs.ethereum.org/ERCS/erc-777","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-777","summary":"ERC-777 is a token standard with sender and recipient hooks plus operator permissions. It can support hook-aware transfers and operator-managed sends, but those semantics are different from ERC-1363 payable callbacks and ERC-4337 account-abstraction infrastructure. Treat adoption, integration, and hook reentrancy risk as separate design and security questions.","applicability":{"whenToUse":["The selected ERC-777 token and recipient use hooks to react to transfers.","The product can explain operator scope for one ERC-777 token contract and provide revocation where supported.","The flow can show hook effects, reentrancy-sensitive behavior, and callback failure states.","You are designing an automatic deposit or transfer experience with visible integration states and recovery paths."],"whenToAvoid":["The token or integration cannot safely handle sender and recipient hooks or their reentrancy risk.","The product needs ERC-1363 transferAndCall or approveAndCall semantics instead.","Users need a token flow with no operator or hook behavior."]},"designerTakeaways":["Show when the selected ERC-777 token and recipient register sender or recipient hooks.","Scope operator authorization to all holdings of this ERC-777 token contract, and show the operator address.","Explain that a recipient hook may reject a transfer when its own checks fail.","Preview hook effects and the operator's scope before a user confirms.","Keep hook registration, execution, and reentrancy handling as integration-specific behavior."],"problemsSolved":[{"problem":"Contracts can't react to incoming token transfers","oldWay":"Approve → Call contract → Contract pulls tokens (3 steps)","newWay":"A compatible ERC-777 recipient hook can run during a token transfer","impact":"high"},{"problem":"Users must approve each contract individually","oldWay":"Approve Uniswap, approve Aave, approve each dApp","newWay":"Authorize an operator for all holdings of this ERC-777 token contract, with a visible revoke path","impact":"high"},{"problem":"No way to reject incoming unwanted tokens","oldWay":"Anyone can send you tokens, no way to refuse","newWay":"A registered recipient hook can reject a transfer according to the recipient's rules","impact":"medium"},{"problem":"Token transfers don't carry context","oldWay":"Transfer is just amount, no additional data","newWay":"data and operatorData fields carry context","impact":"medium"},{"problem":"No standard way for users to be notified of sends","oldWay":"Send completes without user-side hook","newWay":"tokensToSend hook runs before tokens leave","impact":"medium"}],"uxPatterns":[{"name":"Automatic Deposit on Transfer","description":"Send an ERC-777 token to a compatible recipient whose hook processes the transfer","userFlow":["User enters stake amount","UI explains auto-deposit feature","Single transaction initiated","Recipient hook processes the transfer according to its rules","App reports the resulting state or hook rejection"]},{"name":"Operator Authorization","description":"Grant an operator permission over one ERC-777 token contract's holdings","userFlow":["User views operator dashboard","Sees authorized operators for this token","Each shows that operator scope","Can revoke any operator","Add new operators with authorization tx"]},{"name":"Receive Hook Notification","description":"Show when a registered recipient hook may run","userFlow":["Incoming transfer detected","UI shows the registered hook or unknown integration state","Explains the expected callback effect","Shows the final state or rejection","User confirms the transfer in the wallet"]},{"name":"Send Hook Configuration","description":"Show sender-hook behavior when the integration exposes it","userFlow":["User opens hook details","Sees the configured sender hook","Reviews its effect and source","Uses the integration's supported controls","Hook runs on a future send when registered"]}],"uiComponents":[{"name":"OperatorManager","description":"Manage operator authorizations","states":["loading","empty","has-operators","adding"],"props":["operators[]","onAuthorize","onRevoke"]},{"name":"HookPreview","description":"Show what hooks will execute","states":["no-hooks","has-hooks","simulating"],"props":["hooks[]","transfer","outcome"]},{"name":"TransferWithHooks","description":"Transfer UI showing hook involvement","states":["preparing","hooks-running","complete","hook-rejected"],"props":["amount","recipient","activeHooks"]},{"name":"HookRegistry","description":"Register and manage send/receive hooks","states":["viewing","adding","removing","configuring"],"props":["sendHooks[]","receiveHooks[]","onUpdate"]}],"antiPatterns":[{"pattern":"Describing an ERC-777 operator as controlling every token asset","why":"Operators have significant power, users may not understand","instead":"Name the ERC-777 token contract and explain that the operator can send that token's holdings until revoked","severity":"critical"},{"pattern":"Hiding hook effects on transfers","why":"Users surprised when hooks change expected outcome","instead":"Preview hook effects before confirming transfer","severity":"high"},{"pattern":"Using ERC-777 where ERC-20 suffices","why":"Added complexity and reentrancy risks without benefit","instead":"Use ERC-777 features only when hooks genuinely needed","severity":"high"},{"pattern":"No dashboard for hook/operator management","why":"Users forget what they've authorized","instead":"Clear management UI showing all hooks and operators","severity":"medium"},{"pattern":"Treating ERC-777 as superseded by an unrelated standard","why":"ERC-4337 is account-abstraction infrastructure and ERC-1363 is a transfer-and-call token interface; neither is a general semantic replacement for ERC-777 hooks and operators.","instead":"Choose ERC-777, ERC-1363, or account abstraction based on the capability the product needs, and document the security tradeoffs.","severity":"medium"}],"specConstraints":[{"id":"display-denomination","constraint":"Present ERC-777 amounts in the required 18-decimal display denomination; make raw ABI units explicit if exposed.","appliesTo":"wallet","normativity":"normative","specQuote":"In other words, the internal denomination is similar to a wei\nand the display denomination is similar to an ether.\nIt is equivalent to an [ERC-20]'s `decimals` function returning `18`.\nE.g. if a token contract returns a balance of `500,000,000,000,000,000` (0.5×1018) for a user,\nthe user interface MUST show `0.5` tokens to the user.\nIf the user wishes to send `0.3` tokens,\nthe contract MUST be called with an amount of `300,000,000,000,000,000` (0.3×1018).","specSection":"Specification > ERC777Token (Token Contract)","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#erc777token-token-contract","designImplication":"Token balances, amount inputs, and confirmation copy should use the 18-decimal display denomination. If a raw uint is shown for debugging, label it as the internal denomination instead of presenting it as user-facing tokens."},{"id":"granularity-lifecycle","constraint":"Treat granularity as creation-time state that cannot later change.","appliesTo":"account-implementation","normativity":"normative","specQuote":"- The *granularity* value MUST NOT be changed, ever.","specSection":"Specification > ERC777Token (Token Contract) > View Functions","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#view-functions","designImplication":"Any amount-entry or token-details surface that exposes granularity should present it as a fixed token property and explain when an amount is not representable."},{"id":"granularity-multiple","constraint":"Balances and minted, sent, or burned amounts must be multiples of granularity.","appliesTo":"application","normativity":"normative","specQuote":"- All balances MUST be a multiple of the granularity.\n- Any amount of tokens (in the internal denomination) minted, sent or burned\n MUST be a multiple of the *granularity* value.","specSection":"Specification > ERC777Token (Token Contract) > View Functions","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#view-functions","designImplication":"Validate amount inputs against the token granularity before signing and show the smallest transferable unit when it changes the available amount choices."},{"id":"granularity-revert","constraint":"An operation producing a non-multiple balance must revert.","appliesTo":"application","normativity":"normative","specQuote":"- Any operation that would result in a balance that's not a multiple of the *granularity* value\n MUST be considered invalid, and the transaction MUST `revert`.","specSection":"Specification > ERC777Token (Token Contract) > View Functions","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#view-functions","designImplication":"Give the user a recoverable invalid-amount state before submission and explain that the failure is a token rule, not a generic wallet error."},{"id":"default-operator-scope","constraint":"A default operator is implicitly authorized for every holder of the token.","appliesTo":"wallet","normativity":"normative","specQuote":"The token MAY define *default operators*.\nA *default operator* is an implicitly authorized *operator* for all *holders*.\n`AuthorizedOperator` events MUST NOT be emitted when defining the *default operators*.\nThe rules below apply to *default operators*:","specSection":"Specification > ERC777Token (Token Contract) > Operators","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#operators","designImplication":"Operator-management UI must show default operators as token-wide permissions and distinguish them from an operator authorized only by this holder."},{"id":"default-operator-invariant","constraint":"Default operators are fixed invariants and cannot be added or removed later.","appliesTo":"account-implementation","normativity":"normative","specQuote":"- The *default operators* MUST be invariants. I.e., the token contract MUST NOT add or remove *default operators* ever.","specSection":"Specification > ERC777Token (Token Contract) > Operators","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#operators","designImplication":"Do not design a control that implies users can change the token contract’s default-operator set; provide per-holder revoke/re-authorize controls instead."},{"id":"default-operator-revocation","constraint":"A holder must be able to revoke a default operator unless the holder is that operator.","appliesTo":"wallet","normativity":"normative","specQuote":"- A *holder* MUST be allowed to revoke a *default operator*\n (unless the *holder* is the *default operator* in question).","specSection":"Specification > ERC777Token (Token Contract) > Operators","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#operators","designImplication":"Expose a clear revoke action for a default operator and explain the self-operator exception when it applies."},{"id":"default-operator-reauthorization","constraint":"A holder must be able to re-authorize a previously revoked default operator.","appliesTo":"wallet","normativity":"normative","specQuote":"- A *holder* MUST be allowed to re-authorize a previously revoked *default operator*.","specSection":"Specification > ERC777Token (Token Contract) > Operators","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#operators","designImplication":"Show revoked default operators as restorable permissions rather than permanently removed entries."},{"id":"operator-status","constraint":"Operator status is derived through isOperatorFor and operator authorization/revocation history.","appliesTo":"wallet","normativity":"normative","specQuote":"*NOTE*: To know which addresses are *operators* for a given *holder*,\none MUST call `isOperatorFor` with the *holder* for each *default operator*\nand parse the `AuthorizedOperator`, and `RevokedOperator` events for the *holder* in question.","specSection":"Specification > ERC777Token (Token Contract) > Operators","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#operators","designImplication":"Operator lists should communicate how status was determined and include the token contract context; do not infer permission from a stale event alone."},{"id":"sender-hook-before-state","constraint":"The sender hook runs before token state is updated.","appliesTo":"application","normativity":"normative","specQuote":"- The token contract MUST call the `tokensToSend` hook *before* updating the state.","specSection":"Specification > ERC777Token (Token Contract) > Sending Tokens","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#sending-tokens","designImplication":"Preview and transaction-status UI should explain that sender-hook effects happen before balances change and may cause a send to fail."},{"id":"recipient-hook-after-state","constraint":"The recipient hook runs after balances are updated.","appliesTo":"application","normativity":"normative","specQuote":"- The token contract MUST call the `tokensReceived` hook *after* updating the state. \nI.e., `tokensToSend` MUST be called first,\nthen the balances MUST be updated to reflect the send,\nand finally `tokensReceived` MUST be called *afterward*.\nThus a `balanceOf` call within `tokensToSend` returns the balance of the address *before* the send\nand a `balanceOf` call within `tokensReceived` returns the balance of the address *after* the send.","specSection":"Specification > ERC777Token (Token Contract) > Sending Tokens","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#sending-tokens","designImplication":"A recipient integration should model the callback as part of the transfer lifecycle and provide a distinct callback-failure/reverted state."},{"id":"hook-revert","constraint":"Transfers must revert when a required hook or transfer rule fails.","appliesTo":"application","normativity":"normative","specQuote":"The token contract MUST `revert` when sending in any of the following cases:","specSection":"Specification > ERC777Token (Token Contract) > Sending Tokens","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#sending-tokens","designImplication":"Keep hook rejection attached to the transfer attempt in the UI and provide recovery guidance rather than showing a misleading pending success."},{"id":"mint-recipient-hook","constraint":"Minting must call the registered recipient hook and initial supply counts as minting.","appliesTo":"account-implementation","normativity":"normative","specQuote":"- The token contract MUST call the `tokensReceived` hook of the *recipient*\n if the *recipient* registers an `ERC777TokensRecipient` implementation via [ERC-1820].","specSection":"Specification > ERC777Token (Token Contract) > Minting Tokens","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#minting-tokens","designImplication":"Mint/admin flows should disclose recipient callback behavior, including for initial supply, and estimate the resulting integration effects."},{"id":"burn-sender-hook","constraint":"Burning must call the holder’s registered sender hook.","appliesTo":"account-implementation","normativity":"normative","specQuote":"- The token contract MUST call the `tokensToSend` hook of the *holder*\n if the *holder* registers an `ERC777TokensSender` implementation via [ERC-1820].","specSection":"Specification > ERC777Token (Token Contract) > Burning Tokens","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#burning-tokens","designImplication":"Burn controls and status should account for the holder hook and its possible rejection before presenting the burn as final."},{"id":"gas-estimation","constraint":"DApps and wallets should estimate gas for send, mint, and burn operations.","appliesTo":"wallet","normativity":"normative","specQuote":"Dapps and wallets SHOULD first estimate the gas required when sending, minting, or burning tokens—using\n[`eth_estimateGas`][eth_estimateGas]—to avoid running out of gas during the transaction.","specSection":"Specification > ERC777Token (Token Contract) > Note On Gas Consumption","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#note-on-gas-consumption","designImplication":"Transaction confirmation should use an ERC-777-aware estimate and show an actionable insufficient-gas state before signing."},{"id":"erc20-hook-precedence","constraint":"For ERC-20-compatible tokens, registered ERC-777 hooks take precedence on transfer and transferFrom.","appliesTo":"application","normativity":"backwards-compatibility","specQuote":"The difference for new contracts implementing [ERC-20] is that\n`tokensToSend` and `tokensReceived` hooks take precedence over [ERC-20].\nEven with an [ERC-20] `transfer` and `transferFrom` call, the token contract MUST check via [ERC-1820]\nif the `from` and the `to` address implement `tokensToSend` and `tokensReceived` hook respectively.\nIf any hook is implemented, it MUST be called.\nNote that when calling [ERC-20] `transfer` on a contract, if the contract does not implement `tokensReceived`,\nthe `transfer` call SHOULD still be accepted even if this means the tokens will probably be locked.","specSection":"Backward Compatibility","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#backward-compatibility","designImplication":"An ERC-20-looking flow must still disclose callback behavior when the deployed token is ERC-777-compatible; do not promise hook-free transfers based on the method name."},{"id":"event-accounting","constraint":"Do not double-count ERC-777 and ERC-20 compatibility events when presenting transfer history.","appliesTo":"application","normativity":"backwards-compatibility","specQuote":"There is no particular action to take if `tokensToSend` is not implemented.\nThe movement MUST proceed and only be canceled if another condition is not respected\nsuch as lack of funds or a `revert` in `tokensReceived` (if present).","specSection":"Backward Compatibility","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#backward-compatibility","designImplication":"Normalize compatible event streams into one user-visible transfer and clearly distinguish a mint or burn from an ordinary send."},{"id":"operator-multiplicity","constraint":"A holder may have multiple operators at the same time; permission views should represent them as a token-specific collection.","appliesTo":"wallet","normativity":"normative","specQuote":"*NOTE*: A *holder* MAY have multiple *operators* at the same time.","specSection":"Specification > ERC777Token (Token Contract) > Operators","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#operators","designImplication":"Show every active operator for this ERC-777 token contract, with its scope and an individual revoke action; do not collapse multiple operators into one generic permission."},{"id":"decimals-interface-optional","constraint":"For a pure ERC-777 token, decimals() is OPTIONAL and SHALL NOT be relied upon; the implied decimal value is 18. ERC-20-compatible implementations MUST provide decimals() returning 18.","appliesTo":"wallet","normativity":"normative","specQuote":"*[ERC-20] compatibility requirement*: \nThe decimals of the token MUST always be `18`.\nFor a *pure* ERC-777 token the [ERC-20] `decimals` function is OPTIONAL,\nand its existence SHALL NOT be relied upon when interacting with the token contract.\n(The decimal value of `18` is implied.)\nFor an [ERC-20] compatible token, the `decimals` function is REQUIRED and MUST return `18`.\n(In [ERC-20], the `decimals` function is OPTIONAL.\nIf the function is not present, the `decimals` value is not clearly defined and may be assumed to be `0`.\nHence for compatibility reasons, `decimals` MUST be implemented for [ERC-20] compatible tokens.)","specSection":"Specification > ERC777Token (Token Contract) > View Functions","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#view-functions","designImplication":"Use the ERC-777 implied 18-decimal denomination even when decimals() is absent; never treat a missing function as zero decimals. Only use a returned decimals() value as an ERC-20 compatibility signal, and label raw units when exposing them."},{"id":"self-operator-invariant","constraint":"The holder is always an operator for itself and that self-operator right cannot be revoked.","appliesTo":"wallet","normativity":"normative","specQuote":"*NOTE*: The *holder* (`msg.sender`) is always an *operator* for itself.\nThis right SHALL NOT be revoked.\nHence this function MUST `revert` if it is called to authorize the holder (`msg.sender`)\nas an *operator* for itself (i.e. if `operator` is equal to `msg.sender`).","specSection":"Specification > ERC777Token (Token Contract) > Operators","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#operators","designImplication":"Do not offer a misleading self-revocation control; explain that the connected holder retains its own operator authority."},{"id":"operator-send-authority","constraint":"An authorized operator may send the holder's tokens to any recipient other than the zero address.","appliesTo":"wallet","normativity":"normative","specQuote":"- Any authorized *operator* MAY send tokens to any *recipient* (except to `0x0`).","specSection":"Specification > ERC777Token (Token Contract) > Sending Tokens","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#sending-tokens","designImplication":"Before authorization or an operator-initiated send, name the token contract, operator, recipient, and full send authority in plain language."},{"id":"chained-movements","constraint":"Token movements may be chained, with the send rules applying to each movement in order.","appliesTo":"application","normativity":"normative","specQuote":"*NOTE*: Movements of tokens MAY be chained.\nFor example, if a contract upon receiving tokens sends them further to another address.\nIn this case, the previous send rules apply to each send, in order.","specSection":"Specification > ERC777Token (Token Contract) > Sending Tokens","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#sending-tokens","designImplication":"A receipt or transfer flow should expose downstream movement and callback states instead of treating the first transfer as the whole outcome."},{"id":"burn-permission","constraint":"A token contract may prevent some or all holders from burning and may define other burn functions.","appliesTo":"application","normativity":"normative","specQuote":"Burning tokens is the act of destroying existing tokens.\n[ERC-777] explicitly defines two functions to burn tokens (`burn` and `operatorBurn`).\nThese functions facilitate the integration of the burning process in wallets and dapps.\nHowever, the token contract MAY prevent some or all *holders* from burning tokens for any reason.\nThe token contract MAY also define other functions to burn tokens.","specSection":"Specification > ERC777Token (Token Contract) > Burning Tokens","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#burning-tokens","designImplication":"Burn screens should disclose whether the selected token permits this holder and which actor or contract controls the burn path before confirmation."},{"id":"sender-hook-registration","constraint":"An address may register an ERC777TokensSender implementation through ERC-1820 to receive notifications of token debits.","appliesTo":"application","normativity":"normative","specQuote":"The `tokensToSend` hook notifies of any request to decrement the balance (send and burn) for a given *holder*.\nAny address (regular or contract) wishing to be notified of token debits from their address\nMAY register the address of a contract implementing the `ERC777TokensSender` interface described below via [ERC-1820].","specSection":"Specification > ERC777Token (Token Contract) > ERC777TokensSender And The tokensToSend Hook","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#erc777tokenssender-and-the-tokenstosend-hook","designImplication":"When a product exposes hook-aware sending or burning, show whether a sender hook is registered, what address implements it, and how it can affect the transaction."},{"id":"recipient-hook-registration","constraint":"An address may register an ERC777TokensRecipient implementation through ERC-1820 to receive notifications of token credits.","appliesTo":"application","normativity":"normative","specQuote":"The `tokensReceived` hook notifies of any increment of the balance (send and mint) for a given *recipient*.\nAny address (regular or contract) wishing to be notified of token credits to their address\nMAY register the address of a contract implementing the `ERC777TokensRecipient` interface described below via [ERC-1820].","specSection":"Specification > ERC777Token (Token Contract) > ERC777TokensRecipient And The tokensReceived Hook","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#erc777tokensrecipient-and-the-tokensreceived-hook","designImplication":"Incoming transfer UI should identify recipient-hook registration and explain that the callback can process or reject the credit."},{"id":"erc20-hook-continuation","constraint":"For an ERC-20 transfer or transferFrom call to a contract without a recipient hook, the transaction SHOULD continue, while the token may still become locked.","appliesTo":"application","normativity":"normative","specQuote":"- SHOULD continue processing the transaction\n if the `tokensReceived` hook is called from an ERC-20 `transfer` or `transferFrom` call.","specSection":"Specification > ERC777Token (Token Contract) > ERC777TokensRecipient And The tokensReceived Hook","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#erc777tokensrecipient-and-the-tokensreceived-hook","designImplication":"Make the compatibility warning explicit: acceptance is recommended for this path, but a contract recipient without the hook can leave tokens inaccessible."},{"id":"erc20-recipient-fallback","constraint":"The ERC-20 compatibility path SHOULD continue when a contract recipient lacks ERC777TokensRecipient, but MAY revert when avoiding locked tokens is paramount.","appliesTo":"application","normativity":"backwards-compatibility","specQuote":"\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
ERC1820to addressERC777 Sending And MintingERC20 transfer/transferFrom
\n ERC777TokensRecipient
registered\n 		regular address\n MUST call tokensReceived\n
contract
\n ERC777TokensRecipient
not registered\n 		regular addresscontinue
contractMUST revertSHOULD continue1
","specSection":"Backward Compatibility","specUrl":"https://ercs.ethereum.org/ERCS/erc-777#backward-compatibility","designImplication":"Treat continuation versus protective rejection as a visible risk decision, with a clear warning about potentially locked tokens and no claim that SHOULD means MUST."}],"keyTakeaways":["ERC-777 provides sender/recipient hooks and operator permissions scoped to a token contract.","Warn about operator power and hook effects before transfers.","Preview hook outcomes and handle reentrancy-sensitive integrations.","Compare alternatives by required semantics; ERC-4337 and ERC-1363 are different layers."],"technicalNotes":"ERC-777 uses tokensToSend and tokensReceived hooks registered through ERC-1820, and operators can send on a holder's behalf. ERC-1363 defines transferAndCall and approveAndCall, while ERC-4337 defines account-abstraction infrastructure; neither supersedes ERC-777's hook/operator semantics. Hook execution also requires reentrancy-aware integration.","lastUpdated":"2026-09-18","sources":[{"label":"ERC-777 official specification","url":"https://ercs.ethereum.org/ERCS/erc-777","type":"official-spec"}],"lastReviewed":"2026-09-18"},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-777","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-777","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-777","markdown":"https://www.eipsfordesigners.com/standards/ERC-777/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-777/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-777","official":"https://ercs.ethereum.org/ERCS/erc-777","discussion":"https://ethereum-magicians.org/search?q=ERC-777"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}