Callback

How callbacks work

A callback is a function that is invoked by another component as part of a larger operation. In many systems that means handing control to user-supplied logic at a specific event, which makes callbacks a powerful extension point but also a place where execution flow becomes less predictable.

In event-driven software, callbacks are the mechanism that turns a passive operation into a reactive one. They let code respond when data arrives, when a request completes, or when a state transition occurs, without continuously polling for change.

Callbacks in smart contracts

In smart contracts, callbacks are especially sensitive because the external call can transfer control before the original transaction has finished. That interruption can create reentry conditions if the contract updates state only after the callback returns, rather than before it hands control away.

This is why callbacks in blockchain code are not just a programming convenience. They alter the trust boundary during execution, so the contract must assume the callee may behave unexpectedly, recursively invoke functions, or try to observe inconsistent intermediate state.

Why callbacks are useful

Callbacks make asynchronous and modular systems possible. They support notification handlers, response processing, plugin-style extensibility, and integration points where a framework or runtime needs custom logic without hard-coding that logic into the core operation.

That flexibility is valuable in application code, libraries, user interface frameworks, message brokers, and smart-contract interactions. The trade-off is that the caller gives up some direct control over timing and execution order, which can make reasoning about state and side effects harder.

Security implications of callback-driven flow

Security concerns arise when callback timing influences authorization, state integrity, or external interactions. A callback may execute with more context than expected, observe partially updated data, or reach code paths that were not intended to be reentrant, which is why defensive ordering matters in callback-heavy designs.

When a callback can call back into the originating system, the failure is usually not the callback itself but the assumption that the original operation remains isolated until completion. That assumption breaks down in systems that expose mutable state, shared balances, or other sensitive transitions before the operation is fully settled.

Risk and Threat Considerations

Callbacks create risk when control is yielded to external or untrusted code before a transaction, state change, or security decision has fully completed. In smart contracts and other event-driven systems, that can expose inconsistent state and open a path for repeated invocation, logic abuse, or unauthorized side effects.

Failure mechanism: The caller invokes external logic too early, allowing the callee to re-enter, chain additional actions, or exploit intermediate state before the original operation finalises.

Impact: This can lead to double execution, incorrect balances, broken invariants, privilege or logic abuse, and broader compromise of transaction integrity.

Practitioner Guidance

Why practitioners should care: If a callback crosses a trust boundary, treat it as a control transfer rather than a simple function call. The practical question is whether the receiving code can observe or influence state before the caller has made that state safe.

What to watch for: Review callback paths where external logic is invoked during a sensitive lifecycle step, especially when the code later performs state updates, accounting, authorization checks, or settlement. Those are the places where execution order matters most.

Practitioner takeaway: The safest callback design is one that assumes the callee may be hostile, recursive, or slow, and that the caller must leave its state consistent before yielding control.

Related resources from NHI Mgmt Group

• Why do custom domains make OAuth callback governance harder?
• Why do OAuth and OIDC flows need both callback protection and token validation?
• What breaks when client secrets and callback URLs are not tightly controlled?
• What breaks when callback validation in SSO is too loose?