Atomic Arbitrary Asset Transfers

[BrendanChou]

Summary

Rather than structuring an order as an asset swap (plus optional fees), consider structuring an order as an arbitrary number of asset transfers.

Motivation

Inspired by the Arbitrary Fee Token proposal (#28) which I thought should be added as a third assetData field. In this case, paying a fee to a relayer becomes an additional token transfer (or two if both maker and taker are paying relayer fees) in addition to the maker->taker and taker->maker transfers that we usually think about when describing a 0x order.

So why not just structure a 0x Order to facilitate atomic movement of an arbitrary number of asset transfers that may have arbitrary sender and receiver addresses?

• This supports the common use cases
  • Trades without fees
  • Trades with relayer fees from one or more parties
• This supports the use case described in #28
• This supports the use case of #23 without using a proxy
• This supports single-transfer orders
  • Example: Someone could agree to send tokens by signing a single-transfer 0x order, but would require the receiver to accept the tokens by submitting the order on-chain and paying gas fees
• This allows for more complicated structures without use of a proxy
  • Example: circular asset trades between 3 or more parties (A->B & B->C & C->A).
  • Example: multiple parties mutually agreeing to lock up the same amount of funds in the same smart contract (A->X & B->X).
• This allows a user to send multiple tokens at once with a single transaction

These are all important use cases to transferring assets in an atomic way, but many use cases may not be thought of as traditional trades.

Specification

(TODO: Complete this section)

• An array of addresses would be provided (senders and receivers)
• An array of transfers would be provided
  • Each would specify the index number of the sender and receiver of the transfer
  • Each would contain arbitrary data and a signature of which proxy contract would complete the transfer
• Each sender of a transaction must either sign the entire order or be the msg.sender to 0x
• Receiver-only addresses would not need to sign or approve the order in any way

Rationale

It would be great if the 0x protocol were used not only for trading, but also in other ways where asset transfers must be atomic (without having to use second-layer protocols built on top of 0x). This proposed change would make the protocol much more flexible. It is also a more general way of solving the Arbitrary Fee Token issue (#28) and the Multiple-Asset issue (#23)