Open discussion on ZEIP-79 (decreasing protocol fee multiplier)

[mintcloud]

Hello everyone, the vote on ZEIP-79 (decrease protocol fee multiplier to 70,000) is now live, and will run until 10th July at 4PM PST.

In addition to the proposal rationale detailed directly on the ZEIP page, there have been good discussions in the Discord staking-zrx channel that we feel would be useful to copy here so to have a productive discussion during the voting period.

There were in particular two questions by members of the community that triggered the conversation. Their core parts can be quoted directly

I have a bit of a conflict of interest here and also the other market makers here. So I would like to get feedback from the community. If the cut results in at least twice the number of transactions, then it is positive. However, it is otherwise a reduction of earnings per $ of liquidity offered.`

And another one:

So if the protocol fees are cut in half, which is what is proposed, that is not just affecting the market makers, it is affecting everyone, including stakers, because the rewards pool could also be cut in half by this change (if the volume doesn’t double).

These are great questions that we addressed in the conversation. Quoting excerpts of the answers

We think that by lowering protocol fees, we will ultimately get more volume (and # fills).
[…]
This good liquidity is then served to all DEX apps connecting to 0xAPI/Mesh.
However, transaction costs overhead (a mix of contracts cost + protocol fee, which acts as a fixed gas cost) make these quotes less competitive. Apps like 1inch are very sophisticated and find the best price net of gas costs. That means that 0x quotes can result in not being competitive because of this extra gas cost.

As a proxy analysis, we compared the adoption of Uniswap vs Kyber during the last couple of months. We were curious to check if the difference in gas costs (Kyber requires ~ 5X Uniswap gas) would make a difference in adoption when gas prices rise. We have observed a negative correlation.
In the graph below, the orange line represents the difference in trades on Uniswap vs Kyber (higher = more trades on Uniswap relative to Kyber), and the blue line represents increasing gas prices. We can see that there is a high correlation between higher gas prices and additional share of trades on Uniswap.

One of the assumptions of the protocol fee model was that MM would eventually ‘price-in’ protocol fee in their quotes. This would strongly mitigate the considerations above. But according to the conversations we had so far with a few MM, this has not happened yet. We are confident this will eventually happen as order flows rise.
Finally, all of the above is exacerbated by high gas prices, and that’s what led us to this proposal.

And also, related to the profitability ‘hit’ on market makers profitability:

I don’t think it is as simple as saying that market makers now need 2x the trades to be equally profitable. Lowering costs for takers will increase order flow to market makers, allowing them to capture the spread more often. I’d expect a much larger profit increase from the additional order flow than any decrease in profit from fewer protocol fee rewards.

We wanted to post a summary of the conversation here so to make it available to everyone, and we’d like to open up a forum on this topic to address any other questions on the rationale behind the proposal

[Craig_Braun_Fractal]

Hi 0x team and the community. Regarding ZEIP 79, can you provide any background on why 70,000 is proposed?

Generally, I’m interested in learning more about what our understating is of demand elasticity (i.e. taker-volume elasticity) for the protocol fee. For example, has anyone performed research on how much more often 0x would be routed to via 1inch and others with this new fee at 70,000 or 120,000 or 50,000, etc?

Similar to @nikita’s comments above, more information would be (a lot) more helpful in helping us make an educated decision on the ZEIP.

[mintcloud]

Thanks @Craig_Braun_Fractal I’ll let other chime in if more data points are available.
Our understanding of demand elasticity is limited, as it’s difficult to estimate how aggregators like 1Inch or others perform their order routing. We opted for proxies like the ones shown above, that show the demand elasticity of the share of Uniswap fills VS Kyber’s during these last 2 months.

It’s also important to remember that the protocol fee multiplier is an upgradeable parameter of the staking system. This gives quite a bit of flexibility in setting up votes on this even in the future, going through the standard ZEIP process.
This change would allow us to measure/assess demand elasticity for 0xV3 orders with real data over a long enough period, to then make informed adjustments later on, if needed.

[nikita]

Hi team. After listening to the dev call and learning about the FillNonNative Transformer that will be implemented at the end of July, have you done any modeling on how this is likely to impact average order costs and overall protocol fee revenue? What portion or $ value of volume would be impacted?

I ask because I’m concerned about reducing the protocol multiplier at the same time as implementing this transformer for two reasons: 1) the transformer by itself may be sufficient to improve the UX, order routing, and price competitiveness, and 2) doing both at the same time will make it more difficult to determine the impact of either one in isolation. Thoughts?

[mintcloud]

that’s an excellent question @nikita, thanks.

To try and answer your first question, based on the current 0xV3 fills, approximately 10% of the protocol fees were coming from bridge contracts. That represents the amount of protocol fees that would stop being charged, as for that type of trade there the FillNonNative transformer would be utilized. I don’t have handy the % of volume.

I personally think that the two changes are complimentary and don’t actually have a lot of overlap in terms of impact on users, and maybe on ‘measurability’. Here are a few examples on how that could be assessed.

We could observe changes in 0x ‘native orders’ (‘vanilla’ 0x orders, no onchain liquidity orders) volumes from non-exclusive 0xAPI aggregators, such as 1Inch or Paraswap. Changes in volume in this particular order type could be correlated to the effect of a decrease in the protocol fee multiplier - the object of the ZEIP. These integrators compare OO/RFQt liquidity with Uniswap/Kyber/etc on their own backend or contracts, and they typically do not consume 0xAPI smart order routing directly. A cheaper 0x transaction (incl. protocol fee) means higher chances for 0x orders to be part of their routing.

On the other end, with the NonNativeFill transformer, users of applications that utilize the full 0xAPI order routing (like Matcha, Zerion, DeFi Saver) should experience an even more significant decrease in gas costs in cases where the order is 100% routed on onchain sources. With this change, we are addressing directly the feedback we received during the Matcha beta (and from other 0xAPI integrators) that find it difficult to digest a high gas/fee overhead when they could have done the same trade directly on the onchain source.
In that sense, a potential way to observe impact of such a change would be to measure the share of fills for specific pairs on Matcha VS vanilla protocol exchanges like kyberswap or uniswap.exchange.

Having said that, I am afraid it is tough to have a very clean measurement. But we wouldn’t be proposing both changes if we weren’t optimistic that they can both help to provide a better experience for DeFi users and ultimately drive more volume.

[nikita]

Thanks @mintcloud.

It sounds like the NonNativeFill with full 0xAPI use case is relatively non-controversial and an easy win for now given the user base. Thanks for explaining it in more detail.

Regarding other aggregators’ routing algorithms – In the discord @gabririgo mentioned that he had observed that the 0x protocol fee might be overestimated by some aggregators, which would cause their routing to bypass 0x even though 0x might have a better price. Would it be possible for 0x to estimate the fee for them or some other way to ensure that the estimation is more accurate?

[0x_peter]

I wanted to share some of my thoughts on the proposed multiplier update.

First some numbers. Under our current status quo (gas@30 gwei, ETH@230 USD, multiplier@150k), the protocol fee works out to about $1.03 per trade. Gas usage for of filling a 0x order is also about 150k, so that the total cost of filling a 0x order works out to around $2.06.

At present, Uniswap v2 is our main competitor. Filling a Uniswap v2 order uses around 100k gas which works out to a fixed cost of ~$0.69. The differential in fixed costs between 0x and Uniswap v2 is about $1.37.

At the same time, slippage for 0x orders is often significantly lower than slippage for Uniswap v2. The end result is that 0x is generally cheaper than Uniswap for large orders, whereas Uniswap is cheaper for smaller orders. Suppose that on average 0x slippage is 10 basis points lower than Uniswap. In that case, a trader would be better off going to Uniswap for a trade smaller than $1370.

The next question is whether 0x’s current competitive position is viable or not. In principle, 0x could focus on handling orders for large amounts. However, a major problem here is that, even with the increase in gas cost, DEX trade sizes continue to be relatively small. Using ETH-DAI as an example: For Uniswap, the median trade size is $311. For Kyber, $459. Considering all pairs, the median 1inch trade is ~$600.

As you can see, we’re currently not a good deal for the majority of trades. From one perspective, that doesn’t matter much because these small trades don’t drive much volume. However, we believe that this affects user behavior for large trades too. Most Uniswap/Kyber traffic is originated directly at their front-ends rather than through aggregators like 1inch or Matcha. We see a large # of trades move through these front-ends even when much better prices are available elsewhere. For example, when Balancer opened up a $6 million ETH-USDC pool at a 0.9 bp fee. The Uniswap v2 ETH-USDC pool continued to double their volume at a 30 bp fee. Likewise, Uni v2 typically does more than double the volume of Uni v1 even when pools have equivalent liquidity. The Uniswap homepage directs to Uni v2 by default. Most users just go there, even though they could often save 15 bips by clicking one button.

My interpretation is that this is really a battle for eyeballs. In this context, we want to get a larger number people coming habitually to Matcha (or other relayers), making trades for a few hundred dollars, and coming away with a good experience (i.e. not getting sticker shock from a big fee). If we succeed at this, then I believe a small number of these traders we’ll stick around and move larger amounts.

[abandeali1]

@Craig_Braun_Fractal here are the results of a simulation we just ran through 0x API routing with protocol fee amounts of 150K (/prod/quote), 110K, and 70K. It is hard to get exact data on how this would affect 1inch routing, but I think this is a decent proxy.

Assumptions in the simulation:

• This includes all trade permutations of ETH/DAI/USDC only.
• Gas prices were between 25 and 31 during the course of the simulation (every simulated fill used real time gas prices). We can expect the differences to be magnified as gas prices increase.
• Fill sizes were random amounts between $250 and $1,000. This is pretty representative of the median trade sizes mentioned by @0x_peter above.
• For external liquidity sources, we assumed a protocol fee of 0. This will be the case once the ExchangeProxy is deployed and is also what we can expect from other DEX aggregators.

[nikita]

Super helpful. Thanks @0x_peter and @abandeali1!

[mintcloud]

Yeah we observed the same with 1Inch aggregation of 0x orders. We are chatting directly with their team to make sure protocol fees and gas costs of contracts (which might be the cause of the overestimation actually) are evaluated correctly in their order routing.

[Craig_Braun_Fractal]

Thanks @mintcloud @abandeali1, this information adds a lot of helpful context.

Based on the assumptions above we might expect ~22% increase in the times 0x is selected over Uniswap with a 70,000 protocol fee. Am I reading that right? (~22% = 76%/62%-1. I’m eyeballing the bar chart).

[Craig_Braun_Fractal]

The ZEIP mentions API integrators (1inch, Zerion, etc.) have given pushback due to the current protocol fee. Have you run the new 70,000 number by them and does it address their concerns?

[mintcloud]

that’s about right @Craig_Braun_Fractal, and this is in the context of 0x API integrations. It’s important to distinguish between integrations that have their own order routing (1Inch, Paraswap) VS integrations where the 0x API order routing is used (Zerion). The simulation above is directly relevant in the context of the latter, and can only be inferred in the context of the former (as we simulated the behavior of 0x API, but we don’t have visibility on other aggregators order routing).

Having said so, we need to consider that the DEX ecosystem is growing and evolving aggressively. With these variables are in play, it’s difficult to isolate environments and make predictions (even with public blockchains!). Marginal competitive advantages can produce disruptive swings in adoption.

Finally (and related to the point above) these parameters are upgradable, and can be changed in the future pretty easily. We believe there is value in adopting a ‘test-and-iterate’ approach with this, to gather more data in the wild to make better informed decisions later.

[abandeali1]

@Craig_Braun_Fractal I’ll add that Curve, Oasis, and Kyber were all actually included in the simulation but were never the most competitive for trade sizes <$1000 due to gas costs. I also want to emphasize that this simulation was done at relatively low gas prices between 25-31 gwei. Just earlier today gas prices were 70-80 for a few hours, which would definitely magnify the differences we see here.

All of the feedback I’ve heard from takers (Zerion, Tokenlon, etc) so far has been positive and supportive of this change. That being said, as @mintcloud mentioned it is difficult to pin down an exact number with so many moving variables. We’ll have to closely monitor the impact of lower protocol fees and propose more adjustments if necessary.

[Craig_Braun_Fractal]

@abandeali1 and @mintcloud Thanks again. Very helpful.