ERC-777 Tokens Received Hook is a callback function in the ERC-777 token standard that runs when tokens are sent to a recipient contract. It lets the receiving contract react to an incoming transfer, for example by updating balances or triggering follow-on logic, and also creates a re-entrancy risk if the recipient calls back into external contracts before state is finalised.
How the ERC-777 Tokens Received Hook Works
The tokens received hook is the ERC-777 recipient callback that fires after a token transfer reaches a contract. It gives the receiver a chance to react immediately, but it also means the transfer is not always a passive balance update.
That callback model is what makes ERC-777 more expressive than a simple token transfer. A receiving contract can record receipt, trigger internal workflows, or enforce acceptance rules, but any logic executed at that point becomes part of the transfer path and must be treated as security-sensitive code.
Why the Hook Exists in the Token Standard
ERC-777 was designed to support richer transfer behaviour than older token patterns. The hook lets contracts respond to incoming tokens without requiring an external wrapper or a separate post-transfer transaction, which can simplify integrations and stateful applications.
In practice, the hook is useful when the recipient needs to coordinate deposits, accounting, or automated actions as soon as tokens arrive. That convenience is exactly why the standard exposes a callback surface instead of forcing every recipient to poll for balance changes.
Security Implications of Receiver Callbacks
The security significance is that the receiving contract can execute code during the transfer flow, before every dependent state change has necessarily been completed. If that code makes external calls, relies on provisional balances, or assumes the transfer is already fully settled, it can open a re-entrancy path.
Because the callback is invoked on receipt, defenders should treat it as an interaction boundary rather than a harmless notification. A seemingly simple receipt handler can become the place where ordering, state consistency, and trust assumptions fail.
Where This Pattern Usually Matters
This hook matters most in contracts that maintain ledgers, process deposits, mint internal credits, or chain token receipt into additional logic. The higher the value or the more complex the downstream workflow, the more careful the recipient must be about call ordering and state finalisation.
It also matters in composable DeFi and application contracts, where one incoming transfer can trigger other protocol calls. In those environments, the hook is not just an implementation detail, it is part of the protocol surface that other code may depend on.
Risk and Threat Considerations
Receiver callbacks can create a re-entrancy window if the contract performs external interaction before its own state is safe to reuse. That makes the hook attractive in exploitation chains that try to observe, reuse, or manipulate interim state during a transfer.
Failure mechanism: The recipient executes callback logic while balances, accounting records, or invariants are still in a transient state, and an external call allows control to re-enter the contract before the transfer flow is complete.
Impact: Attackers may be able to duplicate effects, bypass balance checks, desynchronise internal accounting, or trigger unintended follow-on actions that assume finalised state.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token and hook flows depend on protected secret and token lifecycle handling. |
| SI-10 — Information Input Validation | Callback-driven receipt logic must validate assumptions before using externally influenced state. | |
| SC-39 — Process Isolation | Re-entrancy risk arises when control returns into shared contract state during execution. | |
| Recommendation — Protect token material with lifecycle controls that support secure rotation and revocation. Validate callback-triggered inputs and state assumptions before acting on them. Isolate sensitive execution paths so re-entry cannot disturb in-flight state changes. | ||
| OWASP ASVS | V8 — Authorization | Receipt callbacks must not let an untrusted flow obtain unintended privileged actions. |
| V15 — Secure Coding and Architecture | The hook creates an architectural re-entrancy hazard that belongs in secure design review. | |
| Recommendation — Enforce authorization checks before any privileged action reached through the callback. Design receipt handlers to preserve state integrity across all callback paths. | ||
Practitioner Guidance
Why practitioners should care: The hook is safe only when the recipient treats it as part of the trusted execution path and keeps state transitions tightly ordered. If the callback is needed, it should be designed around the assumption that adversarial code may be reached during token receipt.
What to watch for: Review any contract that accepts ERC-777 tokens for external calls, shared mutable state, or logic that assumes receipt implies final settlement. The most dangerous designs are those that combine receipt handling with value transfer, callback chaining, or balance-dependent decisions in the same execution window.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org