Analysis of Loopring’s economy

Published in

Coinmonks

11 min readOct 2, 2023

This article discusses Loopring’s economic system, which is a ZK rollup protocol designed for decentralized exchanges (DEXes) and payments. We’ll take a close look at the policies and structures that support the Loopring economy and see if there are ways to make them better.

ZK rollup basics

But now, we face a problem. How can we comprehend Loopring’s economy if we don’t even know what Loopring is? And how can we understand Loopring without knowing the technical stuff behind it? That’s why it’s crucial to start by building a common understanding of the basic ideas that power Loopring: Zero-Knowledge Proofs (ZKP) and ZK Rollup. These are the key technologies behind Loopring.

ZKP

A zero-knowledge proof in cryptography is a method where one person can demonstrate their knowledge of something to another person, providing proof, without revealing the actual content of that knowledge.

Let’s use a simple example to explain. In the scenario pictured above, Alice wants to prove that she knows a passcode without revealing the actual code. She does this by showing that she can reliably reach Bob, no matter which route he tells her to take in response. This not only proves that Alice knows the code but also stops Bob from discovering it.

ZK rollup

A rollup is a layer 2 (L2) technology that makes blockchains faster and cheaper in the following ways:

It groups several transactions together in a batch and processes them off the main blockchain, which makes them faster and less expensive.
It verifies and finalizes transactions on established blockchains, like Ethereum, benefiting from their proven security measures.

As you may have guessed, a ZK rollup is a particular type of rollup that employs ZKP. When a batch of transactions is sent to the main blockchain and the rollup state is updated accordingly, you can verify it using a specific proof without revealing all the exact details of the entire batch.

Note: Moving forward, for simplicity’s sake, we’ll refer to ‘rollups’ in this article as those that operate with Ethereum.

Technical overview of Loopring

Loopring is a ZK rollup protocol that mainly deals with DEXes and payments. Here’s how Loopring works in simple terms:

Loopring users create transactions, sign them, and then send these transactions to an operator. You can use one operator or several operators, depending on your preference.
The operator gathers these transactions, processes them, and updates the Loopring state using Merkle Trees.
The operator gathers processed transactions, including the pre-updated Merkle Root and the updated Merkle Root, organizes them into a block, generates a proof, and then sends this information to Ethereum. Data related to blocks is compressed to lower the gas costs for calldata.
Once the blocks are verified, the updated Loopring state is confirmed as valid. The availability of transaction data within blocks is guaranteed through associated calldata.

Analysis of Loopring’s economy

You don’t have to take action simply because you have the means to do so. For instance, if Bitcoin is priced at $30,000 and you have $30,000, you can buy Bitcoin, but it’s not mandatory. You might choose not to because Bitcoin’s value can be quite unpredictable. To encourage people to take action, it’s not sufficient for them to have the capability; they need a compelling reason.

This principle also applies to the Loopring ecosystem. Just because there’s a system in place doesn’t guarantee that operators will process transactions or that users will engage in transactions. They will only act as expected if it benefits them. That’s why it’s crucial not only to strengthen the technical foundation but also to thoughtfully design Loopring’s economy. In this context, we will now consider how Loopring’s economic design motivates stakeholders to act responsibly and explore potential improvements.

Liquidity sharing

Overview

While Loopring can handle basic transactions like transfers, its main strength is in decentralized exchanges (DEXes), as we mentioned earlier. What’s interesting is that Loopring uses a unique order book model utilizing the concept of ‘liquidity sharing.’

Imagine Jack wants to buy 1 BTC with 10 ETH, and Peter is willing to sell 1 BTC for 9 ETH. When these orders match at a price of 1 BTC = 9.5 ETH, it’s a win-win situation for both Jack and Peter:

Jack buys 1 BTC for 9.5 ETH, saving 0.5 ETH.
Peter sells 1 BTC for 9.5 ETH, earning 0.5 ETH more than expected.

But there’s a problem. When you trade major cryptocurrencies like Bitcoin or Ether, the trading experience is usually smooth. However, when dealing with smaller cryptocurrencies with low trading volumes, you might face issues. You could either have difficulty trading these assets or experience significant price changes during the trade, known as slippage.

Loopring tackles this problem by pooling liquidity from multiple orders. This idea stems from a simple question: ‘What if more than two orders come together to form a larger trade?’

For example, let’s say Jack wants to buy 10,000 LRC with 1 BTC, but there isn’t enough LRC/BTC liquidity available. In this situation, if Peter wants to buy 1 BTC with 10 ETH, and Amy wants to buy 8 ETH with 11,000 LRC, setting the relative prices at 1 BTC = 9 ETH = 11,000 LRC can benefit everyone like this:

Jack gives 1 BTC to Peter and gets 11,000 LRC from Amy, which is 1,000 LRC more than he initially expected.
Peter receives 1 BTC from Jack and gives 9 ETH to Amy, spending 1 ETH less than he initially expected.
Amy gets 9 ETH from Peter and gives 11,000 LRC to Jack, gaining 1 ETH more than she initially expected.

What if there are four, five, or more traders? Can we generalize the cases we discussed earlier? Absolutely. If the following inequality holds true, we can match all the orders in a way that benefits every trader:

p1 * p2 * p3 * … * pn >= 1, where pk = yk / xk

Let’s delve deeper into this concept. Imagine each trader wants to purchase their specific assets (T1, T2, T3, etc.) at a certain price (pk). This works only if the selling price is lower than the trader’s buying price, allowing us to discover an intermediary price that benefits all traders. What’s intriguing is that we can think of this selling price within the context of a “trade ring.”

Consider Trader 1 in this ring. Here, T2 is exchanged for T3, T3 for T4, and so on until Tn is swapped for T1. By multiplying all the relative prices in this sequence, we can figure out how many units of T1 can be acquired with one unit of T2:

T2 = (p2 * p3 * p4 * … * pn) * T1

It’s simple to figure out how many units of T2 you can get with one unit of T1, which is the selling price of T1 stated in terms of T2:

T1 = T2 / (p2 * p3 * p4 * … * pn)

When we compare p1, which is the buying price of T1, to the selling price of T1 that we calculated earlier, it becomes clear that this comparison is essentially the same as the matching inequality we established earlier:

p1 >= 1 / (p2 * p3 * p4 * … * pn) <=> p1 * p2 * p3 * … * pn >= 1

This logical framework applies to other traders as well.

Improvements

We can relax the rules for liquidity sharing so users can quickly complete their trades even if there’s a bit of slippage. While the idea of liquidity sharing might work in theory, it’s not clear if it benefits everyone often. Some users might be okay with a small slippage if it means getting their trades done faster. So, loosening the rules might be a solution:

p1 * p2 * p3 * … * pn * (1+r)^n >= 1, where r is the maximum acceptable slippage.

Let’s go back to the example with Jack, Peter, and Amy. Jack wants to buy 10,000 LRC with 1 BTC, Peter wants to exchange 1 BTC for 10 ETH, and Amy now wishes to purchase 12 ETH instead of 8 ETH using 11,000 LRC. With the original rules, they can’t make these trades:

(1/10,000) * (10/1) * (11,000/12) = 110,000/120,000 < 1

But if all traders are willing to accept a 3% slippage, the trades can happen like this: ((1+3%)³ = 120,000/110,000)

Jack gives 1 BTC to Peter and gets 9,709 LRC from Amy, which is 291 LRC less than he expected. (10,000 LRC per BTC / 1.03 = 9,709 LRC per BTC)
Peter receives 1 BTC from Jack and gives 10.3 ETH to Amy, spending 0.3 ETH more than he expected. (10 ETH per BTC * 1.03 = 10.3 ETH per BTC)
Amy gets 10.3 ETH from Peter and gives 9,709 LRC to Jack, spending 26 LRC more per ETH than she expected. (917 LRC per ETH * 1.03 = 943 LRC per ETH )

All three traders have split the inevitable loss evenly.

Performance-based fee with protocol-level tax

Overview

Running the Loopring infrastructure does come with expenses. For instance, handling transactions and performing complex polynomial calculations requires specialized servers and software. There are also less obvious costs, such as the opportunity cost of assets used as liquidity. This is why Loopring users are required to pay certain fees when they conduct transactions.

Loopring’s fee structure includes compensation based on performance and a protocol-level tax. When you participate in token trading, the default way to cover fees is by using a portion of the tokens you’re purchasing. If this isn’t possible, like in the case of NFTs, fees will be covered using a portion of the tokens you’re selling. If both the bought and sold tokens are NFTs, fees can’t be paid. In practice, assuming typical token trading not involving NFTs, the interests of users and operators align well. In other words, operators are encouraged to seek deals that offer more tokens bought for a set amount of tokens sold, which is also beneficial for users.

It’s also worth mentioning that 10% to 20% of the transaction fees are set aside as ‘protocol fees.’ These fees are used to reward active contributors who can’t be directly compensated through the regular operation of Loopring. Currently, protocol fees are distributed as follows:

liquidity providers: 45%
LRC stakers: 45%
Loopring DAO: 10%

Note: For other types of transactions like transfers or NFT minting, you can pay fees with a fixed amount of any ERC20 token.

Improvement

Charging transaction fees for token trading based on the quantity of tokens sold can create conflicts of interest. As previously explained, in Loopring, when an NFT is purchased and the token sold is not NFT, fees are covered using the tokens that are sold. However, this approach isn’t ideal because what benefits operators may harm users, and vice versa. To clarify, from the operators’ point of view, they would prefer NFTs to be sold for a higher quantity of tokens, as it results in higher fees for them. However, this isn’t favorable for users because they would have to buy NFTs at a higher price.

Staking

Overview

Staking is a common method used to ensure the security of blockchains. From the perspective of the protocol, it involves locking up native tokens within the ecosystem, which helps reduce the pressure to sell these tokens. Additionally, it provides a way to deter malicious behavior by stakers through penalties like slashing or restricting access to their staked assets. For users, staking offers the opportunity to earn rewards, either in the form of more native tokens or reduced fees.

Loopring also employs staking for its benefit, and it’s divided into three categories: exchange staking, protocol fee staking, and LRC staking.

First, through exchange staking, operators are required to stake a specific amount of Loopring’s native token, LRC, before they can submit a block to Ethereum. This staked LRC can only be reclaimed when exchanges are closed, and users’ funds are automatically returned. To put it simply, operators pledge not to interfere with users’ assets by putting up collateral.

Note: Technically, entities other than operators can also participate in exchange staking. However, because there aren’t many rewards for them, I’m assuming that only operators engage in exchange staking, and this assumption works for most cases without losing the overall meaning.

Additionally, with protocol fee staking, you can stake LRC to lower protocol fees, and the key difference from exchange staking is that you have the flexibility to unstake LRC at any time. However, in protocol fee staking, only half of the staked LRC is counted towards the reduction in fees. For example, if you stake 100 LRC to decrease protocol fees, it’s treated as if you staked 50 LRC. The reduction in protocol fees is directly proportional to the amount of LRC you stake.

Lastly, with LRC staking, users who keep their LRC staked for a minimum of 90 days have the opportunity to earn rewards from the protocol fees.

Note: Three staking mechanisms mentioned above are mutually exclusive. In simpler terms, the same LRC tokens cannot be staked for more than one purpose simultaneously.

Improvements

We can improve exchange staking by adding extra rewards and penalties. Currently, exchange staking doesn’t generate extra value, which might not motivate many to participate. Furthermore, because there is no risk of losing staked LRC as long as exchanges can be closed, operators might become overly passive. To address these concerns, we can distribute some of the protocol fees to exchange staking and impose penalties, like reducing a portion of staked LRC, if operators behave poorly, such as frequently going offline.

LRC staking can also become more versatile by offering various combinations of minimum staking periods and rewards. Currently, it only supports one pairing, which doesn’t suit users with various risk-reward preferences. To address this, we can offer multiple options, ranging from short periods with low rewards to long periods with higher rewards.

Furthermore, LRC staked in LRC staking can be lent out to generate extra income. For now, staked LRC just sits idle until it’s unstaked, which isn’t efficient. If we can predict when LRC will be unstaked based on the minimum staking period, stakers can confidently lend their staked LRC, improving capital efficiency.

Block trading

Overview

Block trading in Loopring enables users to execute large trades by tapping into the substantial liquidity of centralized exchanges (CEXs). To explain further, market makers who have accounts on both Loopring and a CEX act as intermediaries, placing orders on behalf of Loopring users within the CEX. For instance, if a user wishes to sell a substantial amount of LRC for USDC, a market maker with an LRC balance can sell their own LRC for USDC on the CEX and then transfer the obtained USDC to the user in exchange for the user’s LRC tokens.

This benefits users for two primary reasons. Firstly, users are spared from experiencing significant slippage, thanks to the substantial liquidity cushion available on CEXs. Additionally, users can maintain custody of their assets because it’s the market makers who deposit assets into the CEX, when necessary, and execute orders on the CEX.

Improvements

The efficiency of block trades can be significantly improved without compromising self-custody too much if market makers use their assets as collateral and execute orders with users’ assets. One of the challenges market makers face in Loopring is the requirement to possess the tokens that users want to sell, as they need to trade with their own assets on CEX. We can address this issue by mandating market makers to provide collateral and permitting them to trade with users’ assets.

For example, if a user wants to sell LRC for USDC, and a market maker doesn’t have LRC, they can put up a corresponding amount of ETH as collateral, acquire the user’s LRC, and sell it for USDC on a CEX. Unless the market maker delivers the promised amount of USDC to the user, the ETH collateral will be transferred to the user.