We’ve been hard at work building Loopring 2.0: upgrading the protocol smart contracts, making it much more feature-rich and flexible to accommodate more powerful matching functions.

One of the most exciting developments of 2.0 has been reimagining the protocol fee model, the role of our native token, LRC, within it, and how we can ensure token holders capture the value of the Loopring network.

Fee Model in Loopring 1.0

Up until this point, LRC has been a fee-payment token: a user needed LRC to pay fees to ecosystem participants for trading.

The three roles in the Loopring ecosystem that are involved in the trade process — and thus use LRC as payment — are traders, relayers (ring-miners), and wallets.

Traders generate orders in wallets, which sends them to relays (ring-miners) for order matching. The Loopring protocol is built for maximum flexibility — a wallet can speak to one or many relays, and relays can speak to each other to share liquidity. Wallets share fees with relays as they see fit, and relays can share fees with each other. Note: sometimes these roles are distinct, but often, a wallet and relay are operated by a single entity; combined, we can refer to that as a DEX.

In the figure below, a trader generates an order from their non-custodial wallet (buying/selling any two ERC20s) and pays 100 LRC as the fee. Of this 100 LRC fee, 20% goes to the wallet to pay for order management, and 80% goes to the ring-miner to pay for order matching. (The relayer pays the gas to submit the transaction to the Ethereum blockchain).

Fee model in Loopring protocol 1.0

“Needing” LRC was actually not strictly true, because, in addition to paying fees in LRC, we also had the unique mechanism of a margin-split , allowing a user to pay a ring-miner some of the margin found in order-rings. “Margin” is the price improvement (discount) that a user may receive if a ring-miner finds a better price than what the user-specified. It’s as if a ring-miner would say, “hey, trader, I found you a better price, want to split it?”.

Example: If you, as a trader, are selling 1000 LRC for 1 ETH, and the ring-miner is able to match the order at only 995 LRC for 1 ETH — saving you 5 LRC — you can split this savings between yourself, the ring-miner, and wallet, according to some predefined split percentage.

In the old model, an LRC fee gave a miner a base level of income, but also the ability to participate in upside if they find juicy margins. Best of all, incentives are aligned: more savings for a user comes with more income for a miner.

Read this article for more info on the original fee model.

Why We’re Open to Change

Utility tokens that act as a medium of exchange within a particular ecosystem have been popular in terms of projects issuing them, but, more recently, less popular in terms of expected value capture and actual usefulness.

Beyond the questionable value accretion for these types of utility tokens, the imposition of a specific token as the means of payment creates significant friction. dApps, including DEXs, are currently UX un-friendly enough without requiring users to pay with an esoteric and otherwise non-demanded token. Abstracting away token transfer behind the scenes helps, but is still only a half-solution.

Open financial infrastructure is in its infancy, and what was considered best practice last year will certainly change. Projects, protocols, and builders must remain adaptive and open to tweak their token dynamics, lest they stubbornly cling to suboptimal models.

Fee Model in Loopring 2.0

We knew we wanted to:

Make fee payment more flexible: remove the friction of requiring a specific fee-payment token. Ensure the LRC token is coveted and provides real utility to the network. Remain rent-free, with all benefits remaining in-protocol, accruing to every participant.

We realize that while incentives are the most powerful force to allow rational actors to organize themselves, mechanisms which optimize for the desired network behaviors are valuable.

Introducing the “LRC Burn Rate”

With this in mind, we have introduced a fee element, LRC burn rate (or burn rate). Wallets and ring-miners who earn fees by fulfilling roles on the Loopring protocol will have a portion of their fees converted into LRC (if not LRC already) and burned.

In the example below, the user pays for their trading fees using BNB. It does not matter if the trade actually involves BNB or not. Let’s assume the protocol-defined LRC burn rate for the BNB token is 20%, and the fee for the transaction is 100BNB. At settlement, the trader pays 100BNB and the wallet and relay earn 100*(1–20%)=80BNB, with the 20BNB being sent to a smart contract which buys and burns LRC.

Fee model in Loopring protocol 2.0

Burn Rate Settings

If the above fee were to be paid in LRC instead of BNB, for example, the burn rate would be lower, such as 5%, allowing the wallet and ring-miner to keep more of their earned fees. The burn rate associated with different ERC20 tokens will be configurable by LRC token holders governing the protocol. For now, we propose the following:

Default settings. Eventually will be configurable by LRC holders. We describe P2P orders in the next sections.

Now, a user can pay fees in any token, but there will be preferable treatment, and thus lower cost, to pay fees in LRC.

The preferable treatment is for the fee-earning participants: wallets and relays; for traders, the fee stays the same. However, our reasonable assumption is that wallets and relays will pass-upwards the fee (dis)savings, and calculate different fees for payment in different tokens.

Other Projects Burning LRC

We want other protocols and projects to be able to take advantage of the fee model. As such, it is possible for a third-party project to burn a certain amount of LRC to knock down the burn rates applied to their token when users pay fees in it. The exact burn rate schedule is TBD, and again, will ultimately be configurable.

If you want to lower the rate of a certain token, such as GTO, to the same third-tier burn rate as WETH for 24 months, you may need to burn 1% of the total LRC supply (currently equivalent to $500,000 USD); if you want to lower the burn rate to the first tier — LRC’s burn rate — for 24 months, it may be necessary to burn 1.5% of the total LRC. As more LRC is burned, the total LRC supply will decrease, and the number of LRC that need to be burned to switch tiers will decrease accordingly.

Lowering the burn rate is particularly appealing for other decentralized exchanges that use their own platform payment tokens:

The cost of burning LRC to obtain a lower rate is much less than the cost of developing a new DEX/protocol, or bootstrapping liquidity. This mechanism actually gives the respective DEX token increased utility and value. After the third-party DEX platform token is enabled for a lower burn rate, using that token to pay fees is no different to the user than using LRC, which should enhance the competitiveness of the platform.

P2P vs ‘Normal’ Orders

In 2.0, we distinguish between normal orders — as seen in all the examples above — and P2P orders.

A ‘normal’ order is what most of us are used to: you submit an order to a DEX and leave it to them to match and settle it on the Ethereum blockchain. On the backend, a ring-miner is the one finding the match and submitting it, and that is why you pay them a fee in the first place.

P2P orders do not pay matching fees, because they do not want to be matched by a third party (ring-miner), but want to match it themselves with a counter-party. Thus, the fees for P2P orders are paid only to the wallet.

However, we must define a P2P order more strictly at the protocol level.

P2P order: If the order’s tokenSFeePercentage or tokenBFeePercentage is greater than zero, the order is a P2P order. Other fee parameters in the P2P order will be ignored by the protocol.

Normal Order Parameters:

address feeToken : optional and defaults to LRC token address if not specified. This is the type of ERC20 token to be paid to the miner as matching fees.

: optional and defaults to LRC token address if not specified. This is the type of ERC20 token to be paid to the miner as matching fees. unit feeAmount : optional and defaults to 0. This is the amount of feeToken to be paid. This number should be calculated by the wallet software off-chain.

: optional and defaults to 0. This is the amount of to be paid. This number should be calculated by the wallet software off-chain. uint16 feePercentage : optional and defaults to 0. This is the percentage of tokenB (the token that user is buying) to be paid as matching fees if the order does not have enough feeToken to pay. This parameter should also be supplied by the wallet.

: optional and defaults to 0. This is the percentage of tokenB (the token that user is buying) to be paid as matching fees if the order does not have enough to pay. This parameter should also be supplied by the wallet. uint16 waiveFeePercentage : optional and defaults to 0. If this number is positive, the miner will waive a waiveFeePercentage% percentage of the fees before the burn; if this number is negative, the miner will reward -waiveFeePercentage% of its total fee after the burn to the order — the reward is also subject to burn.

P2P Order Parameters:

tokenSFeePercentage : optional and defaults to 0. The percentage of tokenS to charge by the wallet.

: optional and defaults to 0. The percentage of tokenS to charge by the wallet. tokenBFeePercentage : optional and defaults to 0. The percentage of tokenB to charge by the wallet.

The wallet here is a broader concept, including any tools that can help you generate orders. As a fee, the wallet can obtain a percentage of the purchase token ( tokenB ) and the sell token ( tokenS ) from a P2P order. This percentage is set by the wallet, approved by the user, and is not provided by the protocol itself.

Let’s assume that both fees set by a wallet are 0%. In the example below, two P2P orders are swapped between 100DAI and 400GTO:

Two orders of zero-fee P2P orders

However, if the wallets corresponding to the two P2P orders are set to charge different tokenSFeePercentage or tokenBFeePercentage , the actual fee and transaction calculation are more complicated:

Two orders consisting of P2P orders with commissions

There are many instances in the real world that will make use of P2P orders and do not require third-party matching:

You create an order for 100 AnyTokens for 1 WETH on your Loopring-enabled wallet, and show the QR code to your friend. She scans it from her wallet, signs it, and submits it directly to the Ethereum blockchain in one tap, resulting in a trustless token swap. Your friend was the ring-miner here, because she submitted the transaction. You’re launching your ICO and plan to distribute it by submitting sell orders for your NewToken on a Loopring-built DEX. You send this order out in emails to your subscribers, or put the QR code printed on the back of your team’s t-shirts. Any interested buyer can fill these orders with a Loopring-enabled wallet, and act as ring-miner by submitting the transaction to the Ethereum blockchain.

In the ICO example, the wallet/ICO platform can charge the project fees for this service in a few different ways:

Use NewTokens as income. Ex: for every 100 NewTokens sold, 5 NewTokens are charged from the project side as a handling fee (the project party distributes a total of 105 tokens, the buyer buys 100 tokens); or every 100 NewTokens sold, 5 are charged from the buyer (the project party distributes a total of 100 tokens and the buyer receives 95 tokens). Use ETH as income. Ex: if there are 100 ETH received from ICO buyers, 7 ETH will be charged from the project side (the project party will get 93 ETH); or the 7 ETH will be charged from the user (the user actually needs to pay 107 ETH). Any combination of the above four different methods.

Without the new P2P model in 2.0, these scenarios cannot be achieved.

P2P Fee Burn Rate

For P2P orders, the protocol specifies different burn rates. Assuming that the burn rates for DAI and GTO are 10% and 20%, respectively, the transaction calculations need to be adjusted as follows:

P2P fee burn rates. See the table in the ‘Burn Rate Setting’ section above for default P2P burn rates.

Burn Contract Specifications

With the new fee model, a small piece of every transaction will be directed to this smart contract and ultimately reduce LRC supply. As such, more Loopring network activity results in more burn, and in LRC holders owning a larger share of the token supply. So now, we have an economy where LRC holders:

Pay the lowest fees for their transactions, Benefit from all network-wide activity.

You may have a few questions:

Who burns the LRC tokens?

Given that the Loopring Foundation is a non-profit and ultimately wants to take a backseat as the protocol flourishes, the burning smart contract (aka holding smart contract) will be coded to allow any user (willing to pay the small gas cost to trigger the function) to burn the tokens.

What happens to the non-LRC (WETH, BNB, etc) that are sent to the burning smart contract?

Like the burn rates, this will ultimately be configurable. LRC holders may be inclined to send the tokens to some external address to fund a community project, but for now, they will be used to buy and burn more LRC.

The means by which non-LRC tokens will be sold for LRC is quite an interesting topic and highlights the spirit of open financial infrastructure. We will allow anyone (willing to pay the gas cost) to trigger functionality in the smart contract that queries other DEXs — specifically Dutch auction models — for any token’s price vs LRC, and submits the tokens to be sold on the open market. This allows the burning contract to trustlessly sell our non-LRC tokens at discrete times, all at once.

The purchased LRC will then be burned. This has the effect of:

Increasing LRC demand Reducing LRC supply

LRC Lockup for Fee Rebates

Loopring 2.0 also allows LRC token holders to lock up LRC in a smart contract in exchange for receiving a percentage of fees that would have otherwise been burned — effectively, a rebate. This would apply for each and every order during the lockup period.

For example, an order has a total fee of 10 AnyToken, and 4 AnyToken (40%) is to be burned. Assuming the fee payer locked up 1 million LRC and has a 50% rebate rate, he/she will end up paying only 8 AnyToken, 2 of which will be burned. The rebate comes from the fee component that is to be burned, not the wallet or relay income. Please note that a wallet/relay can also lockup LRC for rebates.

A rebate rate of 100% ensures all orders are burn-free. The Fee-Rebate feature will be very helpful for high-frequency traders.

Incentivizing Market Makers

Market making is not a protocol level consideration, but a business decision made by a ring-miner on their own. It is up to them to incentivize market makers by waiving fees for orders, so we introduce the parameter waiveFeePercentage .

If this parameter is positive, say, 50%, then if the original fee paid to the ring-miner is 80BNB, it now becomes 40BNB, before the burn. The waived fee is applied to the ring-miner’s part of the fee, but not the wallet’s.

Waiving 50% of fee for Market Maker Alice

This waiveFeePercentage parameter can also be negative. If it were -50%, the order does not pay any fees to the relayer, but can also get 50% of the fee other orders to pay in the ring. For example, in the below diagram, the ring-miner will pay Alice half of the 40 LRC fee paid by Bob. Alice’s rebates are also subject to the corresponding burn.

Giving a -50% fee rebate to Market Maker Alice

With this functionality, the relay can choose to make some or all of the fees of a market maker’s order exempt, and even pay part of the fees earned on other orders. Market makers will be incentivized to provide liquidity to generous and prosperous ring-miners.

Decentralized Governance

Please note that in addition to its utility, we’ve always planned on giving LRC holders governance rights. While this is easy to say, and just about every project can throw that in as a catchall, well-defined rights are truly important to us as the Loopring Foundation will cede control. However, in isolation, we find a pure-governance token to be lacking, and are excited to reveal our 2.0 model which supports further utility and value capture.

With that said, there is now more to govern within the protocol itself. Important future governance issues of the Loopring protocol will not only relate to smart contract upgrades — but also to the various burn rate parameters, and which ERC20s should be placed in certain tiers.

Decentralized governance is incredibly difficult and nuanced, and faces risks such as plutocracies and voter apathy. We are currently exploring how to best implement this aspect, and hope to provide an upgraded version in the first half of 2019, allowing community parameter proposal and voting.

We Welcome Feedback

We’re extremely excited about Loopring 2.0, and about the revised fee model. Not only does the new fee model reduce friction by allowing payment in any token, but it strengthens the network and supports LRC token holders.

If you have any questions or comments, please reach out to foundation@loopring.org or comment below. We’d really love your feedback.