Future proofing the protocol fee

1

Let’s start an open discussion on how best to future-proof the 0x protocol fee.

Protocol fee’s origin

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 good

  • 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

The bad

  • 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 block.coinbase.

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.

----------Closing remarks----------

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.

6 Likes
2

after the first quick read, the allocation to the 0x community treasury can be implemented without additional gas costs for the trades, i.e. by adding a “royalty” to the rewards when they are paid out to the pools operators after the end of each epoch. This has the additional benefit of adding to the gas cost just once per-operator-per-epoch, as opposed to per-each-0x-trade, saving gas and storage on ethereum. Of course this will result in a marginally higher gas cost for completely finalizing an epoch, which could make sense as it’s 0x ecosystem participant/s that finalize epochs, therefore similar (or same in the future) stakeholders. This would require an upgrade to the 0x staking contract but would not require an upgrade of the 0x staking proxy contract, besides attaching the new staking contract to it, as pools operators would accept for a fact that a predetermined royalty goes to the DAO (as storage in the staking proxy contract is not upgradable).

5 Likes
3

This part is most annoying IMO. Maybe the protocol fee calculation could use a “default protocol fee” in case gas is 0. For limit orders I don’t see any added flashbot benefit for the parties, as these are not front-runnable transactions. So it could be legitimate to discourage using such mechanism for filling orders by setting the “default protocol fee” to a high value

But this obviously does not work if the protocol were to take a fee on the swaps (which is not the case currently) as it will place 0x swaps at a disadvantage compared to other protocols I think

Maybe we should also reconsider taking protocol fees in the nature of exchanged tokens, With current trading volumes, I think converting those fees into a common currency can be efficient, if done outside of the user transaction

4 Likes
4

Firstly, I think it’s safe to assume that there’s only so much the community can do about the tokenomics. There are few possible solutions, all implemented in different manners across the DeFi protocols which evolve around “take fee, send it to the treasury/stakers/token holders” and claiming that 0x model is somehow broken is simply wrong. I actually like it since it encourages active market making instead of inflationary/ponzi mechanics or subject to (im)permanent loss of assets.

I already raised the issue of unknown token prices and simply proposed that if anything of this kind gets implemented, one can start with the ETH-denominated markets which constitute vast majority of volume. Another solution is to waive the fees not for trades below certain threshold but for example with protocol fee <$20 (random number I chose), this price can be verified on-chain.

More generally, with L2 solutions already available and potentially non-EVM blockchains in the pipeline, the transaction prices will be pennies and in the long term making the trades “available for small users” will stop being an issue. I’d rather lean towards adding few cents fee for all 0x transactions on Polygon, even sourced through matcha or RFQ, as a payment for good service. If it’s cents, no one will care (MetaMask is a living proof, they’re making millions), the protocol gets extra monetization and matcha earns money.

3 Likes
5

@VolleyFire Do we have some data showing the impact of this? I guess the problem here is that orders need bigger price moves to get filled which leads to bad UX. It would be interesting to have some data showing the protocol fee share compared to filled orders value, gas and taker revenue

My feeling is that gas has the biggest impact here, so it would be very insightful to see limit orders on low gas chains/L2

6 Likes
6

Protocol fee causes a pricing mismatch on very small orders, causing new users that place limit orders using ZRX protocol thinking the protocol is “broken”. I personally saw multiple users saying this, and this causes a barrier for new users to came back. I as well would like to see a prototype with open limit orders running on Polygon or BSC to check if this will keep be an issue, or if we will have higher adoption from limit orders. At the moment the protocol is more optimized on RFQ orders which is good, but this is done more from specialized Market Makers, and we maybe are loosing the network effect that the crowd (small traders) using open limit orders could bring.

3 Likes
7

I personally do not. The data we’d need to back this up would be something like: “x% of trades are < $5000 in volume”. Maybe someone from 0x could provide this data. Or maybe it’s somewhere on https://0xtracker.com/

Say if gas prices are 100 Gwei and the user is paying a fee, the fee is essentially 70,000 * gasPrice + gas cost of the on chain computation of the fee all for only a $5,000 trade. That fee impacts the cost to trade more so than a $100,000 trade.

3 Likes
8

The flashbots approach to capturing MEV offers a lot of benefits to traders. The biggest two are that failed trades do not cost traders gas and that traders don’t have to pay gas for a trade, they simply directly share the profit with miners instead. The later is nice because they don’t have to gamble on how much gas the trade costs vs how much profit they make.

For limit orders I don’t see any added flashbot benefit for the parties, as these are not front-runnable transactions

There’s still value to be had. WIth the KeeperDAO Hiding Game, for example, we’re capturing profit using the user’s limit order and then sharing the profit back with the user. A lot of our keepers will be using flashbots to do this.

3 Likes
9

With current trading volumes, I think converting those fees into a common currency can be efficient, if done outside of the user transaction

This is definitely an option. The question is, how do we do this without adding friction to the user.

2 Likes
10

Yep ! I agree, the KeeperDAO incentives are very powerful. I was more referring to pure 0x limit orders where the only shared profit is through the protocol fee, which is 0 when using Flashbots

3 Likes
11

I think eth denominated fees introduce more friction that fees taken on traded assets

  • For bots, they have to pay the protocol fee on top of the gas cost (except Flashbots)
  • If it was used for swaps, then traders will have to pay extra eth as well

Whereas, taking fees on traded volumes, will always be applied with less friction, as taker knows the fee in advance. Also it works in the flashbots case, even if gas is set to 0, the fee will be collected, it might be even a better way to share the profit between miners/searchers and the protocol.

There is more friction however on the staking fee distribution side, but I think this could be solved by auto converting the fees, I think sushi does the same with their sushi maker & sushi bar contracts

The aggregator part of the 0x protocol can even be used to get best prices for converting those fees.

So I think this needs some extra smart contract work/design but can be a valid alternative for the current fee structure, and maybe one that is more MEV friendly if I may say

3 Likes
12

Definitely agree with all of these points and think that future proofing protocol fees is fairly urgent. Another “bad” point not mentioned here is that the introduction of EIP-1559 will likely decrease protocol fees significantly. Ethereum transactions will now have to pay a base fee + tip, where only the tip portion corresponds to the gas price of the transaction. The vast majority of transactions are expected to not include a tip at all (meaning gas price of 0) or include a minimal tip (meaning a low gas price).

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.

This is pretty problematic on Ethereum, especially with most DEXs aggressively optimizing gas costs these days. Any per-trade fee automatically puts the liquidity at a minor disadvantage due to the gas overhead alone. Gas costs also constrain the design space and make any experimentation with new fee models pretty risky.

Another possible solution is to completely waive protocol fees for small trades. This is not simple to maneuver, unfortunately.

We’ve actually discussed this at length, and one solution we like is to only charge fees on trades that are split between multiple sources (either 2 or 3, depending on the desired threshold). This turns out to be a decent proxy for trade size in a lot of cases, auto-scales with gas prices (because single sources are more likely to be used in high gas price environments), and only charges a fee when users are getting excess value from aggregation. Not perfect, but it’s the solution I like the best at the moment. The downside is that fewer fees are collected as individual liquidity sources become more liquid.

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.

I’m a big fan of using Polygon (and/or other chains) as a testing ground for new token economics prototypes. We can test various ideas largely unconstrained by gas costs. There is also significant opportunity for the protocol to monetize multi-chain volume if fees are not only limited to open orderbook (~5-10% of Ethereum volume atm).

@VolleyFire I’m curious how you would feel about putting a pause on the current v3/v4 protocol fees from the perspective of a market maker and arbitrageur. Do you think they are still net beneficial, or do they do more harm than good at this point? Of course, we’d want to run experiments on other chains in parallel until we land on a replacement that the community can agree on.

4 Likes
13

Am I reading this correctly that swaps would become “fee-eligible” again (under certain conditions) whereas currently only filled limit orders (i.e., non-bridged) incur fees? Conversely, would this also mean that limit orders would no longer incur fees as there is no aggregation routing? Or would there be some hybrid appoach for fees depending on the type of order/fill?

Is 0x Labs doing any research/analysis that can be shared on how other aggregators and apps building on top of 0xAPI are implementing fees and what revenue that is generating (for them)?

Is there more recent granular data on the breakdown of types of orders, volume, fees, etc., from this post last year? Open discussion on ZEIP-79 (decreasing protocol fee multiplier)

I like the idea of using Polygon as a testing ground for new fee/tokenomics models!

1 Like
14

Yes @nikita the idea is that it’s possible to be ‘situational’ about extracting value, depending on where value is being created. Aggregated liquidity (2-3+ sources) is the result of protocol work that creates net new value (‘matching’ best-adjusted price according to user needs), so intuitively it’s a good place to look.
Aggregation should be agnostic of order type, in the way that I understand it (meaning, the 3 sources could be a combination of AMM+RFQ+limit order from Open Orderbook).

When assessing more efficient fee models, it seems fair to look at ways of extracting only where and when you create value.
It’s difficult to define a horizontal extractive model (uniformly defined on all market types/pairs/liquidity types). The most intuitive one is a %-based fee, like on AMMs. But when it comes to 0x aggregating different liquidity sources, it’s probably best to imagine a world where fee extraction is tailored based on the type of market (asset, liquidity type, other params - trade size is difficult though).

It’s also useful to throw into the mix two technical constraints:

  • It costs gas to extract a fee (the more complicated the onchain methodology of extraction, the more it hurts price competitiveness at lower trade sizes)
  • It’s very complicated to involve oracles, seems better to avoid

Zooming out

Like @abandeali1, I am curious about what @VolleyFire thinks about the current fee model, which de facto extracts and redistributes within the 0x Open Orderbook ‘micro-cosmo’.
The strongest PMF for that market type is still ~70% between market makers and arb bots (so ~10 participants) and 20-30% between limit order users and arb bots (maybe ~1000 participants).
In other words, fee extraction is active on markets that are just a subset in volume (5-10% of total 0x) and participants (I don’t have the data, but my hunch is ~1%) of 0x user base.

Zooming out even more - scope creep alert!

It’s a complicated puzzle: I feel we should keep an eye on how we’re faring wrt incentives to grow the pie, looking at the two sides of the marketplace we want to grow:

  • supply side: Open Orderbook Makers, RFQ Makers, AMMs, limit order users
  • demand: 0x API integrators and their users, arb bots

The system is governed by ZRX holders, whose distribution of voting power should overlap with the market participants, following their degree of ‘skin in the game’.
In bold the participants that are part of the redistribution system today - not really a strong representation of what 0x network. What about 0x API integrators? RFQ Makers, AMMs? They’re all participating to the network growth.

Apart from the extraction question (where to get the fees from?), it is worth thinking redistribution, meaning expanding the sides/participants involved in redistribution, keeping our north star aligned: an ever-growing public network (supply/demand), governed by ZRX holders.
Testing can be very helpful for that.

5 Likes
15

I’m curious how you would feel about putting a pause on the current v3/v4 protocol fees from the perspective of a market maker and arbitrageur. Do you think they are still net beneficial, or do they do more harm than good at this point?

Since arbitrage bots are filling 99% of the open orderbook limit orders, removing the protocol fee would increase volume. Fills should cost less gas and be overall cheaper to arbitrage. There would probably be a bit of a delay while bots adjust their trading algorithms, but there should be a noticeable uptick.

This is probably a matter of determining if that open orderbook volume increase is worth the protocol fee removal in the short term while we find a solution. The APYs on 0x Protocol Governance would effectively go to zero right? This would of course be knowing that a better long term solution is coming, and hopefully that doesn’t take a year to discover and implement.

This is of course all based on the assumption that between Flashbots and EIP 1559, the current gas price based fee mechanism is completely obsolete and not efficient. Maybe we should lay out some thoughts on this front before we make any assumptions.

Thought 1.) Exactly how much cheaper, in gas, is a 0xv4 open orderbook limit order trade with the protocol fee completely removed from the solidity code?

Thought 2.) Is there still a protocol fee gas overhead cost when there is a zero gas price? Example: A bot uses flashbots and pays 0 gas, do you still have to pay gas to pay a 0 fee, or does the solidity code see that hte gas price is zero and it just completely skips the protocol fee code all together?

Thought 3.) We should further analyze the 1559 issue you brought up and estimate what % of 0x open orderbook fills will have a gas price associated with them. This is essentially a follow up thought to thought 1 above.

2 Likes
16

Given the direction this seems to be heading (pause/removal of protocol fees on limit orders), I would also like to know:

  1. Can 0x Labs simulate the expected increase in trading volume so that we can assess the second and third order effects?
  2. Can 0x Labs simulate the impact on tokenomic incentives and staking behavior if there is no revenue, nor staking rewards, for some (possibly extended) period of time? There are some logical conclusions we could draw, but I am looking for something more quantifiable.
2 Likes
17

It’s a bit complicated. For the simple case (an EOA calling fillLimitOrder() on a single order, no refund necessary, pool/fee collector is established), I’d estimate you’d save about 14k gas (post-Berlin) if the fee multiplier was set to 0. The gas-heavy logic will be skipped in the EP when the fee is 0, yes. However, there’s a 9k overhead every time you attach ETH to a call (not counting the root-level call). This quickly adds up if you’re doing something more complex like an arb since you add at least one extra runtime call-with-value to your execution.

3 Likes
18

I was brainstorming internally some ideas to replace the protocol fee for other venues, as is now it removes completely the advantage of the protocol for small traders, as solutions ZRX protocol could:

  1. A portion of all limit orders with fee set goes to the staking pools. These kind of orders are already with fee so, the integrator is already collecting a fee for using the protocol, so it makes sense to take a portion of it for the protocol itself. Cons: Additional gas to do this additional transfer. Not many integrators uses this field so at begin this will result on zero revenue.
  2. Market makers stake/pay ZRX to access RFQ system on the future proportional to the revenue they generate from having access to this infraestructure. Market makers are the ones that benefit and profit from this system, they could pay or stake ZRX to access to this liquidity. RobinHood profit from this. Cons: This can add additional burden to Market Makers
  3. Integrators stake/pay ZRX to access the API KEY to offer RFQ system to their users. Cons: This can add additional burden to Integrators
  4. Fee only on routing for more than 3 sources. Cons: This could take out the competiveness of the order routing

I would like to see first 0x working on other chains like Polygon, to confirm if the protocol fee it continuous to be such a problem for small traders like it is on Ethereum. Looking at Polygon fees for each transfer this would not be such a burden.

Another solution would be switch off protocol fees or decrease it according to GWEI. so when ETH is struggle, the limit orders keep competitive to the rest of the market. Cons. This will be really hard for bots to compute always the right protocol fee. Need to investigate if this is even possible with current smartcontracts or even feasible

3 Likes
19

Another “bad” point not mentioned here is that the introduction of EIP-1559 will likely decrease protocol fees significantly.

Quick update on this - this was actually an incorrect assumption. Turns out that the tx.gasprice will include both the base fee and tip, so I wouldn’t expect protocol fees to decrease at all as a result of EIP-1559.

Increased usage of flashbots is more concerning. 32% of limit order fills in June used flashbots! See below:

Screen Shot 2021-07-02 at 4.02.22 PM
Screen Shot 2021-07-02 at 4.02.22 PM818×337 20.2 KB

2 Likes
20

Great. Thanks for clarifying.

Increased usage of flashbots is more concerning. 32% of limit order fills in June used flashbots
Nice chart.

So it sounds like if this % of limit order fills hits a certain threshold it makes sense to pause/disable the protocol fee until we come up with a future proof plan. This is based on the assumption & discussion above that temporarily disabling the protocol fee would save gas (thus increasing trading volume opportunities).

The ZRX staking pool APYs have been down recently but it’s likely more so due to gas prices being so low way more so than this recent 32% flashbots number. Gas prices for the month of June were in the low 20’s, as opposed to prior months which were in the hundreds.

Screen Shot 2021-07-02 at 10.53.33 PM
Screen Shot 2021-07-02 at 10.53.33 PM2688×1096 165 KB

3 Likes