Remarks on Loopring’s Fee Model

During the last couple of days, I discussed Loopring’s current fee-model with several community members, especially @jonasshen, @supersimmetry, and @thomas in our Slack channels. I enjoyed those conversations, and also realized I need to tell people how the current fee model came into being, and to put together a simple framework to better evaluate any proposed fee model for Loopring protocol.

For those of you who are not familiar with our project: Loopring is a decentralized token exchange protocol. It is implemented as an ethereum smart-contract at the core of its ecosystem. You can learn more about the background and general design of the loopring protocol in our whitepaper or on https://docs.loopring.org/overview.

Loopring adopts the OTC trading model. Order's creation time is irrelevant for matching, so there is no first-come-first-serve promise. Price is the most dominant factor that decides if orders can match in a market. When we are talking about its fee model, it’s important to understand one concept, the margin-split.

But first, Let's talk about margin?

I’ll take an example from @supersimmetry’s the example in his Remarks on Loopring:

Alice has 15 tokens A and she wants 4 tokens B for them (order#1)
Bob has 10 tokens B and he wants 30 tokens A for them (order#2).

Using Loopring, these two orders can form a ring of size 2, and according to the math of the protocol[1]:

Bob gives 4 tokens B and receives 13.41640786 tokens A, more than the 12 he was expecting for those 4 tokens. Alice receives 4 tokens B as intended but gives only 13.41640786 tokens A in exchange, less than the 15 she was willing to give for those 4 tokens.

In this case, Alice or order#1’s margin is 1.41640786 tokens A; and Bob or order#2’s margin is 1.58359214 tokens A.

*[1] Note that this is a simplified example, Loopring actually calculates margins based on another parameter `buyNoMoreThanAmountB`, which makes the margin calculating more complicated but fairer.

What’s margin split?

Each order can specify how a percentage of the margin to be paid as an incentive to ring miners. This portion of the margin is called the margin split. Splitting the margin puts miners and order owners on the same side of the game: the larger the margin is, the more the miner will gain, and the more the order’s owner will save. This idea is not new and is how OTC middlemen make money.

Loopring’s current fee model

In a market with sufficient liquidity, the price spread will be quite small. In other words, the margin and hence the margin split will become smaller as the liquidity gets higher. In such a mature market, margin split as an incentive is not good enough for miners to continue their services, as they have to spend ETH as gas to submit order-rings in form of Ethereum transactions to the Ethereum blockchain.

LRC fee is then introduced to save the day. When margin split is too small or zero (we call such a match a zero-margin match or a perfect match), LRC fee is supplementary way to incentivize miners to stay in the game. The problem now becomes how to decide the amount of LRC to pay. We believe order owners desire the option to specify any amount of LRC they want, to either save money or speed up order fulfillment. We suppose wallets that support Loopring trading will need to provide LRC price — with respect to their users’ local fiat — to help them adjust LRC fee amount, and wallets may also need to provide a suggested LRC fee amount based on order size and value. Providing LRC fee references and suggestions is not considered part of the protocol.

So now we have {LRC Fee + Margin Split} as miners income. The LRC fee amount should be specified in a way such that it is large enough to cover miner’s cost (electricity, gas, service hosting, etc), and incentivize miners even in the case of zero-margin matches, which means {LRC Fee + Margin Split} is probably too high for non-zero-margin matches, from order owner’s perspective. To fix this, we change this fee model to the our current one:

Allowing miners to either charge LRC Fee, or margin split but pay the same amount of LRC fee back to the order owner.

This will force miners to choose LRC fee if the margin split is smaller than twice the value of LRC fee.

The picture above illustrates the differences between these two fee models.

One may argue why miners pay the exact amount of LRC fee back to order owner, why not {a-ratio *LRC Fee}. That’s a question to which I don’t yet have a satisfying answer.

A Framework for Evaluating Loopring Fee Model

The current fee model might not be be the best one, but in order to evaluate any of its variances, we need a framework. Here are some criterias that I came up with:

  • The fee mode shall incentivize miners to find order-rings that have the largest margin.
  • The fee model shall incentivize miners even for zero-margin trades.
  • The overall fee shall be as low as possible to complete with other decentralized protocols.
  • The fee model shall not rely on centralized price oracles as this will introduce all kinds of trust related issues.
  • The fee model shall not rely on on-chain price stats as these stats are subject to performance issues, market manipulation, and possibly a new way of frontrunning-like attack.
  • The fee model shall increase demand of LRC token and its liquidity.
  • The fee model shall be easy to understand by users.
  • The fee model shall be easy to implement in smart contract as well as by ring-miner software.

If we apply these criteria to the current fee model, the result is quite satisfying. Maybe we should add more criteria.

Feedback and LIPs Requested

If you have any feedback on our current fee model or the evaluation framework, please feel free to join our slack channels; if you would like to propose an enhanced fee model, please submit an issue on https://github.com/Loopring/LIPs so we can discuss there for consensus.

Loopring token (LRC) is now listed on hitBTC and a couple of other smaller exchanges. Although we are working on more exchanges, the main focus of the team is on delivering our protocol and open-source projects as planned.

Thanks for reading. Stay tuned.

— Daniel W