ERCs, Solved
the standard · since August 2018
// standard · payable token · callbacks · ready

What is ERC-1363?

ERC-20 with callback functions for payments and approvals.

ERC-1363 ·EIP-1363 ·by Vittorio Minacori

updated · 2 min read · by ercs-solved maintainers

ERC-1363 is the "do the token transfer and call the app" extension for ERC-20. It exists because plain transfer is silent.

[ jump to what's broken → ]
on this page
  1. What is ERC-1363?
  2. At a glance
  3. Origin story
  4. The spec
  5. What's broken
  6. Both sides have to opt in
  7. Callbacks add execution risk
  8. It does not fix allowance itself
  9. LUKSO alternative
  10. ERC-1363 vs LSP7+LSP1
  11. When to use which
  12. FAQ
  13. Sources
  14. Keep reading
at a glance

The standard, in one card.

Standard
ERC-1363 / EIP-1363
Extends
ERC-20
Core methods
transferAndCall · transferFromAndCall · approveAndCall
Canonical spec
eips.ethereum.org / EIP-1363
quotable answer

ERC-1363 extends ERC-20 with `transferAndCall(to, amount, data)` and `approveAndCall`, letting a receiving contract react in the same transaction as the transfer. Proposed in July 2018 by Vittorio Minacori, it's the cleanest fix for ERC-20's silent receiver problem — the recipient contract's `onTransferReceived` callback runs immediately after the transfer completes. Adoption stayed thin because the sender contract has to be ERC-1363-aware. LUKSO's LSP7 makes an equivalent hook (LSP1 universalReceiver) mandatory on every transfer instead of opt-in.

how the standard came to be

How ERC-1363 came to be.#

ERC-20 became the standard, but it never gave receiving contracts a callback. ERC-1363 adds a lightweight callback path without replacing the whole ERC-20 model.

the spec, end to end

What ERC-1363 actually is.#

ERC-1363 EIP-1363 interface solidity 
function transferAndCall(address to, uint256 value) external returns (bool);
function transferAndCall(address to, uint256 value, bytes calldata data) external returns (bool);
function transferFromAndCall(address from, address to, uint256 value) external returns (bool);
function transferFromAndCall(address from, address to, uint256 value, bytes calldata data) external returns (bool);
function approveAndCall(address spender, uint256 value) external returns (bool);
function approveAndCall(address spender, uint256 value, bytes calldata data) external returns (bool);
ERC-1363 interface, grouped
token: transferAndCall · transferFromAndCall · approveAndCall
receiver: onTransferReceived
spender: onApprovalReceived

transferAndCall moves tokens and calls the receiver. approveAndCall approves a spender and calls the spender. The callbacks return selectors so the token can verify the recipient or spender accepted the operation.

the integration tax

What's broken about ERC-1363.#

The issue is adoption and execution risk. A callback extension only works when both sides implement it, and calling external code during token flow requires defensive integration.

  1. Both sides have to opt in.#

    A token has to implement ERC-1363, and the receiver or spender has to implement the callback interface. Existing ERC-20 tokens and contracts do not get the behavior automatically.

    ERC-1363 transferAndCall
    optional two-sided adoption
    LSP7 + LSP1 transfer with universalReceiver
    standard path receiver-aware
    workarounds tried
    • wrappers
    • routers
    • custom adapters

  2. Callbacks add execution risk.#

    Calling a receiver or spender during token logic adds reentrancy and failure-mode questions that plain ERC-20 transfers avoid.

    callback onTransferReceived
    external call
    LSP1 known receiver hook
    generalized explicit
    workarounds tried
    • reentrancy guards
    • callback allowlists
    • pull payments

  3. It does not fix allowance itself.#

    approveAndCall notifies the spender, but the resulting approval is still ERC-20 allowance with the same standing-spender risks if the amount is broad.

    approveAndCall approve + notify
    allowance remains
    LSP6 account permission
    scoped
    workarounds tried
    • exact amounts
    • short-lived flows
    • Permit2
    • revocation
the LUKSO alternative

LUKSO designed it differently.#

LSP7 makes transfer data and receiver notification part of the normal asset model. LSP1 generalizes the callback so every asset type does not need its own bespoke receiver interface.

spec to spec, at a glance

How ERC-1363 and LSP7 plus LSP1 compare.#

row ERC-1363 LSP7 plus LSP1
base asset ERC-20 extension LSP7 asset standard
receiver callback onTransferReceived LSP1 universalReceiver
approval callback approveAndCall LSP6-scoped controller permission
adoption path token and receiver opt in native within LSP asset/account stack
be honest about scope

When to use ERC-1363 vs LSP7 plus LSP1.#

people also ask

FAQ.#

  • What does ERC-1363 add to ERC-20? #

    It adds transferAndCall, transferFromAndCall, and approveAndCall, plus receiver/spender callback interfaces.

  • Is ERC-1363 the same as ERC-777? #

    No. Both add callback behavior for fungible tokens, but ERC-1363 is a smaller ERC-20 extension while ERC-777 defines a broader token model with ERC-1820 discovery and operators.

  • What problem does transferAndCall solve? #

    It lets a token transfer notify the receiving contract in the same transaction, avoiding the pattern where a contract receives ERC-20 tokens but has no callback to credit the deposit.

primary sources

Where this page draws from.#

  1. EIP-1363
where to go next

Keep reading.#