Arbitrary Fee Token

[PhABC]

Preamble

ZEIP: <to be assigned>
Title: Arbitrary Fee Token
Author: Philippe Castonguay <pc@horizongames.net>
Type: Standard Track
Category: Core
Status: Draft
Created: 2019-03-08

Simple Summary (2 Sentences)

Allow taker and maker fees to be paid in any ERC-20 token, not only ZRX.

Abstract

Currently, most relayers take their fee via a spread instead of accepting fees paid in ZRX. The main reasons for this are better UX, lower cost and because relayers and users do not want to transact using ZRX. This ZEIP proposes to allow maker and taker fees to be paid in any ERC-20, not only ZRX.

Motivation

While I haven't done any data analysis of the 0x exchange contract transactions, I strongly suspect that a very small percentage of trades use ZRX as a fee, because ZRX is not recognize as a good mean of exchange, unlike DAI or ETH for instance. Initially, ZRX was enforced as a fee in order to spread the tokens overtime to active participants in the 0x ecosystem. After almost two years, I believe it is safe to say that this mechanism as fallen short of its goals and impairs the 0x ecosystem more than it benefits it.

Indeed, I suspect enabling other tokens to be used for fees could grow the 0x community and usage substantially. The ZRX token being enforced within the protocol is a complain that many have raised since the creation of this project and I believe it has caused more harm than good to the players involved. If implemented, this ZEIP would also greatly facilitate NFT to NFT trades, which otherwise require a more expensive and complicated approach like a forwarding contract.

Specification

A new field feeToken: address in the 0x order schema would need to be added where users could specify the token used to pay for fees. If let to 0x0, the default feeToken could be ZRX, or DAI, or other token the community deems most useful.

Rationale (if a suggestion is proposed)

The additional CALLDATA cost is marginal compared to the benefits and especially compared to implementing the same logic in a forwarder contract. No matter how simple, I am confident in saying that forwarder contracts allowing fees to be paid in other tokens than ZRX will always be more complex and expensive than what this ZEIP proposes.

[BrendanChou]

Rather than adding feeToken to makerFee and takerFee, would it make more sense to combine all fee fields into a feeData field that more closely resembles the makerAssetData and takerAssetData fields?

[PhABC]

That's a good idea I think, since when fee is 0 (e.g. when taking a spread), then all these fields are just a 0x byte array, which would save some gas. However, I know Remco is trying to push for reducing the cost of CALLDATA, so maybe the gains wouldn't be worth the added complexity if such a change was to take place.

[recmo]

Why limit to ERC20? If we use the same AssetData mechanism as maker and taker, then we can use any token supported by asset proxy.

Note that none of these strategies will allow ETH to be used directly (WETH will work of course).

A more generic feeData field is interesting, could allow for a more extensible mechanism. One thing I've been researching is how to do fee-sharing for multi-hop relays. It looks like this can be done securely using BLS signatures. Currently BLS is way to gas expensive to use for this onchain though.

[PhABC]

We don't need to limit to ERC-20s indeed, I was trying to make the simplest proposal. That being said, I would personally be even happier with a general scheme similar to assetData!

[abandeali1]

Hey @PhABC, this s something we have been thinking about for a while now. Our proposal for version 3.0 will include allowing arbitrary fees (in addition to a new economic model that will be discussed in a separate ZEIP).

The implementation is actually fairly simple. As other people have mentioned in this thread, you can simply add makerFeeAssetData and takerFeeAssetData to the order schema. If these fields are the same as either the makerAssetData or takerAssetData in the order, this actually adds very little gas overhead (~200 gas per field) because dynamic data can be de-duped when ABI encoding. Note that to my knowledge the only ABI encoder that actually makes this optimization is the one used in the 0x-monorepo codebase.

[dorothy-zbornak]

A PR for this is currently in review.

[dorothy-zbornak]

A PR for this is currently in review.

Now merged into the 3.0 branch.

[dorothy-zbornak]

Please check PR #54 for the final version of this ZEIP.

[mintcloud]

Implemented in #56