- SmartPy team proposed as new TZIP inspired by ERC677 with a
- You can read the whole here.
- Here is the merge request.
- Here is a example of a scenario using it: SmartPy.
- We are waiting for your comments and suggestions.
TZIP-23 extends FA2 token specifications by introducing a multi-action
transfer entry point. The entry point adds a proxy mechanism to the standard
transfer behavior, allowing the source to send a request or notify the recipient
after a successful transfer.
This TZIP adds a new entry-point to FA2 token contracts,
transfer_and_call which can be called to transfer tokens to a contract and
send a follow up call. Once the tokens are transferred, the token contract calls
the receiving contract’s entry-point given in argument with the specified data.
transfer_and_call is inspired by ERC677).
Currently, the FA2 transfer standard doesn’t offer any mechanism to allow the
sender to notify the recipient of a transaction. This mechanism is necessary to
improve the interoperability between contracts. As a result, it will turn the
communication more decentralized by removing off-chain dependencies.
Token contract implementing this TZIP standard MUST implement the given entrypoint:
(list %transfer_and_call (pair (address %from_) (list %txs (pair (address %to_) (address %callback) (bytes %data) (nat %token_id) (nat %amount) ) ) ) )
The entrypoint SHALL perform and only perform the following 3 actions:
- Regular transfer
- Callback verification
The entrypoint SHOULD NOT perform any extra logic and SHOULD NOT call any other
contract or rely on any other instruction that can fail because of a third party.
The transfer part of the
transfer_and_call MUST work exactly like a call to
transfer entrypoint would have do (see FA2#transfer).
The contract MUST verify the validity each
%callback address is in the form:
is in the form
%to_ address is in the form:
hash (even if nothing prevents
user sending an entrypoint).
The transaction MUST FAILWITH
%to_ differ by more than the
The contract MUST return a list of transfer operation for each
the same order that the transfer are performed without deduplicating or
aggregating them with the following type argument:
(pair (address %sender) (bytes %data) (nat %token_id) (nat %amount) ) )
Thank you for reading.
We are waiting for your comments and suggestions!