Transfer and call, a new entrypoint for FA2

TZIP
1

Transfer and call

Key points

  • SmartPy team proposed as new TZIP inspired by ERC677 with a transfer_and_call entry-point.
  • 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.

A new entry-point for FA2

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.

The transfer_and_call is inspired by ERC677).

Motivation

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.

Interface Specification

Token contract implementing this TZIP standard MUST implement the given entrypoint: transfer_and_call

transfer_and_call 

(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:

  1. Regular transfer
  2. Callback verification
  3. Callback

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.

Regular transfer

The transfer part of the transfer_and_call MUST work exactly like a call to
the transfer entrypoint would have do (see FA2#transfer).

Callback verification

The contract MUST verify the validity each %callback.

The %callback address is in the form: prefix hash suffix where suffix
is in the form %entrypoint
The %to_ address is in the form: prefix hash (even if nothing prevents
user sending an entrypoint).

The transaction MUST FAILWITH "FA2_CALLBACK_AND_RECEIVER_DIFFERS" if
%callback and %to_ differ by more than the suffix.

Callback

The contract MUST return a list of transfer operation for each %callback in
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!

1 Like
2

Might want to adjust the wording here.

3

Thank you.
Changed to third party

4

i get it but is there any way to keep this entrypoint optional? message passing in Tezos is still pretty unsafe even with DFS. So like I’m sure there would be folks who want to use this, so i support the TZIP generally. but if I want to make a complex contract and embed an FA2 token inside, I don’t want to be forced into implementing this endpoint to get my little “FA2” badge.

5

I updated the proposal.

Now we can specify a callback address that is totally different from the receiving address. The receiving address is now passed in the callback args.

It removed the need of same_underlying_address verification which was not well standardize in Michelson.

Callback is now

(pair
  (nat %amount)
  (bytes %data)
  (address %receiver)
  (address %sender)
  (nat %token_id)
)