Arbitrary Fee Token #28
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
Rationale (if a suggestion is proposed)
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
Why limit to ERC20? If we use the same
Note that none of these strategies will allow ETH to be used directly (WETH will work of course).
A more generic
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