ERC-1363 is an Ethereum token interface that lets an ERC-20-compatible token call a receiver or spender contract immediately after a transfer or approval. The standard adds transferAndCall, transferFromAndCall, and approveAndCall, along with callback interfaces for the contracts receiving the tokens or allowance.
How it works
With an ordinary ERC-20 flow, a token transfer and the application action that follows it are usually separate calls. ERC-1363 combines them: the token contract transfers tokens and calls the recipient’s onTransferReceived function, or creates an allowance and calls the spender’s onApprovalReceived function. The callback can accept the operation or revert it. The optional data argument lets the caller pass information to the receiving contract.
An implementation must also support ERC-20 and ERC-165 interface detection. A receiving contract must explicitly implement the appropriate callback to accept this kind of interaction.
Scope and limitations
ERC-1363 is an optional extension; it does not change every ERC-20 token into a callback-enabled token. Wallets and applications need to use a compatible token and receiver. The callback is external contract code, so integrators still need to validate the token and protect their own logic against unsafe calls and reentrancy.
The standard also does not remove ERC-20 allowance risks. In particular, changing an approval can still create transaction-ordering issues if an existing allowance is replaced directly.
Why it matters
The interface can let a payment trigger an application action in one transaction, such as recording a token payment or starting a contract workflow. That can simplify integrations, but it does not guarantee that every service accepts ERC-1363 or that a callback-based payment is safer by itself.
History
- 2018 — ERC-1363 was created as an optional interface extension that builds on ERC-20 and ERC-165.
Common Misconceptions
“Every ERC-20 token supports transferAndCall.” ERC-1363 is optional. A token and the receiving or spending contract must implement the relevant interfaces for the callback flow to work.
Criticisms
- A callback executes external contract code in the same transaction, so integrations must validate the token and guard against unsafe calls and reentrancy.
- The extension does not remove the allowance risks inherited from ERC-20 approval patterns, and support is not universal.
Social Media Sentiment
Sampled r/ethdev discussion focuses on implementation details, especially why a receiver must return the expected callback selector and what should happen when a recipient does not implement the interface. That reflects a practical compatibility and safety debate: callbacks can make payments composable, but only when both sides handle the interface correctly.
Last updated: 2026-10
Related terms
See Also
Sources
- ERC-1363 specification — defines the callback functions, interface requirements, and allowance security considerations.
- ERC-20 specification — defines the base token transfer and allowance interface extended by ERC-1363.
- ERC-165 specification — defines the interface-detection mechanism used by ERC-1363 implementations.
- r/ethdev discussion of ERC-1363 callback return values — a developer discussion about callback acceptance and compatibility with contracts that do not implement the receiver interface.