Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Arbitrary Fee Token #28

PhABC opened this issue Mar 8, 2019 · 6 comments


None yet
5 participants
Copy link

commented Mar 8, 2019


ZEIP: <to be assigned>
Title: Arbitrary Fee Token
Author: Philippe Castonguay <>
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.


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.


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.


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.


This comment has been minimized.

Copy link

commented Mar 9, 2019

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?


This comment has been minimized.

Copy link
Contributor Author

commented Mar 9, 2019

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.


This comment has been minimized.

Copy link

commented Mar 9, 2019

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.


This comment has been minimized.

Copy link
Contributor Author

commented Mar 11, 2019

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!


This comment has been minimized.

Copy link

commented Mar 14, 2019

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.

@abandeali1 abandeali1 added 3.0 and removed 3.0 labels May 3, 2019

@dorothy-zbornak dorothy-zbornak referenced this issue May 18, 2019


Arbitrary Fee Tokens #1819

0 of 4 tasks complete

This comment has been minimized.

Copy link

commented May 18, 2019

A PR for this is currently in review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.