Let’s start an open discussion on how best to future-proof the 0x protocol fee.
A portion of the fee revenues generated will be allocated to the 0x community treasury to fund ongoing development of the 0x ecosystem. The remaining fee revenues will be paid out to 0x market makers as a liquidity rebate. The rebate scheme rewards market makers in proportion to a) the amount of liquidity they provide and b) their stake of ZRX tokens.
- The protocol fee mechanism is working as intended
- It’s providing value for the ZRX ecosystem, market makers, and ZRX stakers
- APYs today are healthy, the top pools averaging around ~6% APY over the last 12 weeks
- Protocol fee doesn’t currently apply to RFQ volume, only open order book volume
- Flashbots has emerged, and 0 Gwei gas prices are becoming common
- Paying a protocol fee doesn’t make sense for very small orders
There as been a lot of internal discussions on this topic and I feel it’s time to open it up for a larger more visible discussion. The hope is that this leads to a future-proof solution. The good items above are wonderful, but for the purposes of this discussion, I’d like to focus mostly on the bad items.
----------Examples of challenges and possible solutions----------
One challenge here starts with the fact that the taker of the order has to pay gas in order to pay the fee. This results in what feels like a double fee, one fee to the miners and another to the protocol. And if the trade is small in size, then the fee feels like it outweighs the value of the trade.
One possible solution involves moving the individual fee payments offchain. The challenge with this is that we now introduce friction with the user forcing them to interact with an off-chain feature in order to prepare to pay a fee. Or worse, forcing them to stake something in order to pay for future fees.
Another possible solution is to completely waive protocol fees for small trades. This is not simple to maneuver, unfortunately. First, you’ll need to decide on a threshold, and then a base currency for that threshold. Let’s say it’s no protocol fee for trades under 10,000 USDC. This is easy to do when trades involve USDC. But what if they don’t? What if the user is posting a limit order swapping two random obscure tokens. We would somehow need a reliable mechanism that determines if it’s eligible based on some price oracle. But then the trading contract would need to pay gas to communicate with the price oracle and now we’re spending gas to save gas. Or worse, if you do end up needing to pay the fee you spent gas talking to the price oracle in order to pay the fee anyways. So now it feels like you paid a higher fee. So clients would need to simulate the trade ahead of time to determine if they will end up paying the fee or not, then taking a different more gas-efficient trading path based on the outcome. And this makes web client integrations more complex and adds more friction to integration partners.
A simple possible solution here is to strip as much out of the trade function as possible. And have the code that pays the fee cost as little gas as humanly possible. It’s possible that this has already been done, but still worth looking into.
Layer 2 could end up being the best solution here. But do keep in mind trading will always take place on layer 1 even after layer 2s become popular.
----------0 Gwei transactions = taker paying gas to pay a 0 wei fee----------
Flashbots has been growing in popularity and I see that trend continuing. We must now accept the fact that 0 Gwei gas prices are here to stay. Flashbots TLDR: bot traders communicate directly with miners and pay them a payment in exchange for mining an Ethereum block in a particular order such that the bot captures profit and shares a payment to the miner directly. This leads to the transaction have a 0 Gwei gas price and the miner getting a direct ETH payment via
On the KeeperDAO front, we’ll be launching the Coordination Game this summer and I anticipate lots of flashbots usage happening even within the Coordination Game. There are also several other protocols similar to flashbots starting to appear, so even if for some reason flashbots were to suddenly go out of style it would only be because something better took its place.
Let’s have an open discussion with the community and the 0x team on how best to proceed and future proof the protocol fee. Maybe we can even prototype some ideas or hold a hackathon. If any ideas look promising but appear potentially time-consuming, we could fund some R&D.