Meta-Summary
We wrote this post to serve as inspiration for future Rubicon Improvement Proposals (RIPs) and forum posts. In this example, we outline a proposal to change the feeBPS parameter on the RubiconMarket contract from 20 to 1. This would effectively lower the taker fee on the order book protocol from 0.20% to 0.01%.
Please note that our team already made this change in an upgrade on September 20, 2022, Rubicon’s one-year anniversary on Optimism Mainnet. That makes this a retroactive improvement proposal (still a RIP!), but the ideas and motivating factors outlined here were the same ones that led us to make the change. Hopefully, this can serve as a helpful template for future proposal authors!
Summary
@forrest proposes changing the feeBPS parameter on RubiconMarket.sol from the current value of 20 to the proposed value of 1. This effectively lowers the taker fee on the order book protocol from 0.20% to 0.01%.
Abstract
The feeBPS parameter was set to 20 (0.20%) during Rubicon’s launch on Optimism Mainnet on September 20, 2021. At the time, the 0.20% fee set by the team was in line with or slightly below the fees on other trading venues.
In 2022, crypto markets slowed down and trading volumes decreased across the board. In response, many centralized and decentralized exchanges lowered their trading fees, attempting to counteract the overall downtrend and continue growing market share. Given Rubicon’s growth in the past 13 months and the adjustments from comparable venues, we think it is time to revisit the Rubicon trading fee(s).
Revising the taker fee has many implications for Rubicon market structure. It’s a parameter optimization problem, and if the fee is set too low or too high, there could be significant negative effects on the protocol.
Motivation
Firstly, why does the protocol need any fees at all? While it’s still in the growth stage, it makes sense to have a take rate lower than comparable trading venues and protocols, and nothing is lower than zero!
However, zero-fee or free trading has some major problems. It enables wash-trading; malicious actors can trade with themselves without paying any fees and effectively distort prices. This damages the broader market’s confidence in the reliability of the trading venue. While venues with zero fees do gain volume in the short term, it comes at the expense of reliable and deep liquidity, confidence in price level, and abnormal volatility. These side effects make us feel very strongly that the feeBPS parameter should be non-zero.
The effects of maker and taker fees on trading venues are well studied by academic researchers, regulators, and of course, proprietary trading firms. It is worth noting here that Rubicon currently has no maker fees/rebates, traders who ‘make’ liquidity already have to pay for gas fees (and incorporate that cost into their spreads). This proposal is limited in scope to the taker fee, but separate discussions regarding the Rubicon maker fee are welcome.
Unlike other decentralized liquidity venues (AMMs), Rubicon liquidity providers do not receive this fee, so lowering it does not directly affect their profits. We believe this is a significant competitive advantage for Rubicon: liquidity providers and market makers can be profitable with a very low taker fee. This motivates us to set the fee much lower than competing venues.
Rubicon is building the world order book protocol! In the future, we think it is likely that a significant amount of the protocol’s volume comes from applications hosting their own front-end and charging users a ‘wrapper’ fee in addition to the base protocol fee. A 0.01% fee enables these applications to thrive and charge competitive rates, while the current 0.20% is much less accommodating to these types of applications.
We think that lowering the feeBPS to 1 (0.01%) will accelerate the growth of Rubicon trading volumes, enable new applications on top of the protocol to thrive, and promotes Rubicon’s advantages for all liquidity providers. Let us know your thoughts!
Specification
This table outlines all protocol parameters this proposal would change:
| Parameter | Current Value (bps) | Proposed Value (bps) |
|---|---|---|
| feeBPS | 20 | 1 |
Implementation
If this proposal passes, a member of the Protocol team will call the setfeeBPS function on RubiconMarket and set a new value of 1.