ERC-1363: Payable Token / Token Transfer with Callback
ERC-1363 layers a callback hook on top of ERC-20 so that a token transfer can trigger logic in the receiver in the same transaction — without requiring the receiver to do a separate approve + transferFrom dance. It's the "transferAndCall" ergonomic improvement that ERC-20 originally lacked.
Required Interface
function transferAndCall(address to, uint256 amount) external returns (bool);
function transferAndCall(address to, uint256 amount, bytes calldata data) external returns (bool);
function transferFromAndCall(address from, address to, uint256 amount) external returns (bool);
function transferFromAndCall(address from, address to, uint256 amount, bytes calldata data)
external returns (bool);
function approveAndCall(address spender, uint256 amount) external returns (bool);
function approveAndCall(address spender, uint256 amount, bytes calldata data) external returns (bool);The receiver implements IERC1363Receiver.onTransferReceived(...) and must return the magic selector 0x88a7ca5c to accept the transfer; the spender target implements IERC1363Spender.onApprovalReceived(...) returning 0x7b04a2d0. ERC-1363 is the design ancestor of NEP-17's payment callback.
Neo Equivalent: NEP-17 callback (built in)
NEP-17's required transfer(from, to, amount, data) already invokes onNEP17Payment(from, amount, data) on the recipient when the recipient is a contract. No separate "payable token" extension is needed — every NEP-17 token is "payable" by spec.
| ERC-1363 (Ethereum) | NEP-17 (Neo) | Notes |
|---|---|---|
transferAndCall(to, amount, data) | transfer(from, to, amount, data) | Built into the core NEP-17 spec |
IERC1363Receiver.onTransferReceived(...) returning magic value | onNEP17Payment(from, amount, data) | Recipient revert / not-implementing aborts the transfer |
transferFromAndCall(from, to, ...) | transfer(from, to, ...) with witness for from | Authorization via witness instead of allowance |
approveAndCall(spender, amount, data) | — | Neo has no allowance; spender pattern unnecessary |
Magic selector handshake (0x88a7ca5c) | onNEP17Payment presence + revert semantics | Neo enforces by missing-method semantics, not by selector match |
Why It's Built In on Neo
ERC-1363 exists because ERC-20 was designed without callback hooks; protocols that wanted "transfer + immediate logic" had to choose between trusting users to call two functions or shipping a wrapper. NEP-17 made the callback a mandatory part of every transfer to a contract, which is why NEP-17 receivers are guaranteed to know about every payment.
Migration Notes
Solidity contracts targeting Neo via neo-solc can drop ERC-1363 entirely: declare function onNEP17Payment(address from, uint256 amount, bytes calldata data) external on the receiver and the compiler routes Neo-side onNEP17Payment invocations to that function. The four-parameter transfer signature is the only correct shape on Neo.
