Loopring Whitepaper

Monday, May 7, 2018
Download document
Save for later
Add to list
Whitepaper.io is a project of OpenBook

Loopring: A Decentralized Token Exchange Protocol Daniel Wang Jay Zhou Alex Wang [email protected] [email protected] [email protected] Matthew Finestone [email protected] https://loopring.org April 6, 2018 Abstract Loopring is an open protocol for building decentralized exchanges. Loopring operates as a public set of smart contracts responsible for trade and settlement, with an off-chain group of actors aggregating and communicating orders. The protocol is free, extensible, and serves as a standardized building block for decentralized applications (dApps) that incorporate exchange functionality. Its interoperable standards facilitate trustless, anonymous trading. An important improvement over current decentralized exchange protocols is the ability for orders to be mix-and-matched with other, dissimilar orders, obviating the constraints of two-token trading pairs and drastically improving liquidity. Loopring also employs a unique and robust solution to prevent front-running: the unfair attempt to submit transactions into a block quicker than the original solution provider. Loopring is blockchain agnostic, and deployable on any blockchain with smart contract functionality. At the time of writing, it’s operable on Ethereum [1] [2] and Qtum [3] with NEO [4] under construction. 1 Introduction it fails to uphold the virtues these decentralized projects espouse. There are also numerous practical risks and lim- With the proliferation of blockchain-based assets, the need itations in using centralized exchanges which are described to exchange these assets amongst counterparties has signifi- below. Decentralized exchanges (DEXs) [7] [8] [9] have cantly increased. As thousands of new tokens are introduced sought to address these issues, and in many cases have - including the tokenization of traditional assets - this need succeeded in alleviating security risks by using blockchains is magnified. Whether exchanging tokens for speculative for disintermediation. However, as DEX capability becomes trading motivations, or converting to access networks via crucial infrastructure for the new economy, there is substan- their native utility tokens, the ability to exchange one cryp- tial room for performance improvement. Loopring aims to toasset for another is foundational for the larger ecosystem. provide modular tools for said infrastructure with its dApp Indeed, there is a potential energy in assets [5], and realizing agnostic open protocol. this energy - unlocking capital - requires not only asserting ownership, which blockchains have immutably allowed for, but the ability to freely transfer and transform these assets. 2 Current Exchange Landscape As such, the trustless exchange of tokens (value) is a compelling use case for blockchain technology. Until now, 2.1 Inadequacies of Centralized Exchanges however, crypto enthusiasts have largely settled for trading tokens on traditional centralized exchanges. The Loopring The three primary risks of centralized exchanges are; 1) Lack protocol is needed because, just as Bitcoin [6] dutifully of security, 2) Lack of transparency, and 3) Lack of liquidity. emphasized that, in regards to peer-to-peer electronic cash, Lack of Security arises from users typically surrender- “the main benefits are lost if a trusted third party is still ing control of their private-keys (funds) to one centralized required to prevent double-spending”, so too are the main entity. This exposes users to the possibility that centralized benefits of decentralized assets lost if they must pass through exchanges fall prey to malicious hackers. The security and trusted, gated, centralized exchanges. hacking risks facing all centralized exchanges are well known Trading decentralized tokens on centralized exchanges [10] [11], yet are often accepted as “table stakes” for token doesn’t make sense from a philosophical perspective, as trading. Centralized exchanges continue to be honeypots for 1

hackers to attack as their servers have custody over millions 2.2 Inadequacies of Decentralized Ex- of dollars of user funds. Exchange developers can also make changes honest, accidental errors with user funds. Simply, users are not in control of their own tokens when deposited at Decentralized exchanges differ from centralized exchanges a centralized exchange. in part because users maintain control of their private-keys (assets) by performing trades directly on the underlying Lack of Transparency exposes users to the risk of blockchain. By leveraging the trustless technology of cryp- dishonest exchanges acting unfairly. The distinction here is tocurrencies themselves, they successfully mitigate many of by the exchange operator’s malicious intentions, as users are the abovementioned risks surrounding security. However, not truly trading their own assets on centralized exchanges, problems persist in regards to performance and structural but rather, an IOU. When tokens are sent to the exchange’s limitations. wallet, the exchange takes custody, and offers an IOU in its Liquidity often remains an issue as users must search place. All trades are then effectively between users’ IOUs. for counterparties across disparate liquidity pools and stan- To withdraw, users redeem their IOU with the exchange, dards. Fragmented liquidity effects are present if DEXs and receive their tokens to their external wallet address. or dApps at large don’t employ consistent standards to Throughout this process there is a lack of transparency, interoperate, and if orders are not shared/propagated across and the exchange can shutdown, freeze your account, go a wide network. The liquidity of limit order books, and, bankrupt, etc. It is also possible that they use user assets specifically, their resiliency – how fast filled limit orders for other purposes while in custody, such as lending them are regenerated – can significantly affect optimal trading out to third parties. Lack of transparency can cost users strategies [13]. The absence of such standards has resulted without a total loss of funds, such as in higher trading fees, not only in reduced liquidity, but also exposure to an array delays at peak demand, regulatory risk, and orders being of potentially insecure proprietary smart contracts. front ran. Furthermore, since trades are performed on chain, DEXs inherit the limitations of the underlying blockchain, namely: Lack of Liquidity. From the point of view of exchange scalability, delays in execution (mining), and costly modifi- operators, fragmented liquidity inhibits entry by new ex- cations to orders. Thus, blockchain order books do not scale changes because of two winner-takes-all scenarios. First, the particularly well, as executing code on the blockchain incurs exchange with the greatest number of trading pairs wins, a cost (gas), making multiple order-cancellation cadences because users find it desirable to conduct all their trades on prohibitively expensive. one exchange. Second, the exchange with the largest order Finally, because blockchain order books are public, the book wins, because of favorable bid-ask spreads for each transaction to place an order is visible by miners as it awaits trading pair. This discourages competition from newcomers being mined into the next block and placed into an order because it is difficult for them to build up initial liquidity. book. This delay exposes the user to the risk of being front As a result, many exchanges command a high market share run and having the price or execution move against him. despite user complaints and even major hacking incidents. It’s worth noting that as centralized exchanges win market share, they become an ever-larger hacking target. 2.3 Hybrid Solutions From the point of view of users, fragmented liquidity For the above reasons, purely blockchain-based exchanges significantly reduces user experience. In a centralized ex- have limitations that make them uncompetitive with cen- change, users are only able to trade within the exchange’s tralized exchanges. There is a tradeoff between on-chain own liquidity pools, against its own order book, and be- inherent trustlessness, and centralized exchange speed and tween its supported token pairs. To trade token A for order flexibility. Protocols such as Loopring and 0x [14] token B, users must go to an exchange that supports both extend a solution of on-chain settlement with off-chain order tokens or register at different exchanges, disclosing personal management. These solutions revolve around open smart information. Users often need to execute preliminary or contracts, but navigate scalability limitations by performing intermediate trades, typically against BTC or ETH, paying several functions off-chain and giving nodes flexibility in bid-ask spreads in the process. Finally, the order books may fulfilling critical roles for the network. However, drawbacks not be deep enough to complete the trade without material remain for the hybrid model as well [15]. The Loopring slippage. Even if the exchange purports to process large protocol proposes meaningful differences in our approach to volumes, there is no guarantee that this volume and liquidity a hybrid solution throughout this paper. is not fake [12]. The result is disconnected silos of liquidity and a frag- 3 Loopring Protocol mented ecosystem that resembles the legacy financial sys- tem, with significant trading volume centralized on few Loopring is not a DEX, but a modular protocol for building exchanges. The global liquidity promises of blockchains hold DEXs on multiple blockchains. We disassemble the compo- no merit within centralized exchanges. nent parts of a traditional exchange and offer a set of public 2

30 smart contracts and decentralized actors in its place. The of 10 = 3.00A. In the case of fixing token B as reference, we say that Alice is selling 15 token A for the price of roles in the network include wallets, relays, liquidity-sharing 4 consortium blockchains, order book browsers, Ring-Miners, 15 = 0.26666667B and Bob is buying 10 token A for the 10 and asset tokenization services. Before defining each, we price of 30 = 0.33333334B. Hence, who’s the buyer or seller should first understand Loopring orders. is arbitrary. In the first situation Alice is willing to pay a higher 3.1 Order Ring price (3.75A) than the price Bob is selling his tokens for (3.00A), while in the second situation Bob is willing to pay a Loopring orders are expressed in what we call a Unidirec- higher price (0.33333334B) than the price Alice is selling her tional Order Model (UDOM)[16]. UDOM expresses orders tokens for (0.26666667B). It is clear that a trade is possible as token exchange requests, amountS/amountB, (amount to whenever the buyer is willing to pay an equal or higher price sell/buy) instead of bids and asks. Since every order is just than the seller’s price. an exchange rate between two tokens, a powerful feature of 15 10 the protocol is the mixing and matching of multiple orders in 4 30 15 10 = 4 = 4 · 30 = 1.25 > 1 (1) circular trade. By using up to 16 orders instead of a single 30 10 15 trading pair, there is a dramatic increase in liquidity and Thus, for a set of n orders to be able to be filled, fully or potential for price improvement. partially, we need to know if the product of each one of the ORDER#2 exchange rates as buy orders results in a number greater or 8B owner: Y amountS: 9B 98C equal to 1. If so, all the n orders can be either partially, or amountB: 12C totally filled [17]. If we introduce a third counterparty, Charlie, such that ORDER#1 ORDER#3 owner: X 7898A owner: Z Alice wants to give x1 token A and receive y1 token B, amountS: 10000A amountS: 100C amountB: 2B amountB: 160A Bob wants to give x2 token B and receive y2 token C, and Charlie wants to give x3 token C and receive y3 token A. The Figure 1: An order-ring of 3 orders necessary tokens are present, and the trade is possible if: x1 · x2 · x3 The above figure shows an order-ring of 3 orders. Each ≥1 (2) order’s token to sell (tokenS) is another order’s token to y1 · y2 · y3 buy (tokenB). It creates a loop that allows each order to See section 7.1 for more details about Loopring’s orders. exchange their desired tokens without requiring an opposing order for its pair. Traditional order pair trades can, of 4 Ecosystem Participants course, still be executed, in what is essentially a special case of an order-ring. The following ecosystem participants jointly provide all functionalities a centralized exchange has to offer. Definition 3.1 (order-ring) Let C0 , C1 , · · · , Cn−1 be n different tokens, O0→1 , · · · , Oi→i⊕1 , · · · , On−1→0 be n • Wallets: A common wallet service or interface that orders. Those orders can form a order-ring for trading: gives users access to their tokens and a way to send orders to the Loopring network. Wallets will be O0→1 → · · · → Oi→i⊕1 → · · · → On−1→0 , incentivized to produce orders by sharing fees with ring-miners (see section 8). With the belief that the where n is the length of the order-ring, and i ⊕ 1 ≡ i + 1 future of trading will take place within the safety of mod n. individual user’s wallets, connecting these liquidity pools through our protocol is paramount. An order-ring is valid when all component transactions can be executed at an exchange rate equal to or better than • Consortium Liquidity Sharing Blockchain/Relay- the original rate specified implicitly by the user. To verify Mesh: A relay-mesh network for order & liquidity order-ring validity, Loopring protocol smart contracts must sharing. When nodes run Loopring relay software, receive order-rings from ring-miners where the product of they are able to join an existing network and the original exchange rates of all orders is equal to or greater share liquidity with other relays over a consortium than 1. blockchain. The consortium blockchain we are Let’s assume Alice and Bob want to trade their token building as a first implementation has near real time A and B. Alice has 15 token A and she wants 4 token B for order sharing (1-2 second blocks), and trims old them; Bob has 10 token B and he wants 30 token A for them. history to allow for faster download by new nodes. Who is buying and who is selling? This depends only Notably, relays need not join this consortium; they on the asset we fix to give price quotations. If token A is can act alone and not share liquidity with others, or, the reference, then Alice is buying token B for the price of they can start and manage their own liquidity sharing 15 4 = 3.75A, while Bob is selling 10 token B for the price network. 3

• Relays/Ring-Miners: Relays are nodes that re- order books to be built in a certain way, such as first- ceive orders from wallets or the relay-mesh, maintain come-first-serve. Instead, relays have the power to public order books and trade history, and optionally make their own design decisions in building their order broadcast orders to other relays (via any arbitrary books. off-chain medium) and/or relay-mesh nodes. Ring- mining is a feature – not a requirement – of relays. 4. Liquidity Sharing: Relays broadcast the order to It is computationally heavy and is done completely other relays through any arbitrary communication off-chain. We call relays with the ring-mining feature medium. Once again, there is flexibility how/whether turned on “Ring-Miners”, who produce order-rings by nodes interact. To facilitate a certain level of network stitching together disparate orders. Relays are free in connectivity, there is a built-in liquidity sharing relay- (1) how they choose to communicate with one another, mesh using a consortium blockchain. As mentioned (2) how they build their order books, and (3) how they in the prior section, this relay-mesh is optimized for mine order-rings (mining algorithms). speed and inclusivity. • Loopring Protocol Smart Contracts (LPSC): A set of public and free smart contracts that checks ORDER 1 owner: X user X accountX order-rings received from ring-miners, trustlessly set- amountS: 10000 A amountB: 2 B tles and transfers tokens on behalf of users, incentivizes 8B ring-miners and wallets with fees, and emits events. ORDER 2 owner: Y Relays/order browsers listen to these events to keep amountS: 9 B 2 user Y 1 accountY 7898 A their order books and trade history up to date. See amountB: 12 C 98 C appendix A for details. ORDER 3 owner: Z amountS: 100 C user Z accountZ 6 • Asset Tokenization Services (ATS): A bridge amountB: 160 A between assets that cannot be directly traded on Loopring. They are centralized services run by trust- worthy companies or organizations. Users deposit relay M accountM Fee assets (real, fiat or tokens from other chains) and get 3 share liquidity tokens issued, which can be redeemed for the deposit settlement 4 in the future. Loopring is not a cross-chain exchange relay N accountN protocol (until a suitable solution exists), but ATS ring-mining enable trading of ERC20 tokens [18] with physical assets as well as assets on other blockchains. ORDER 1 5 owner: X amountS: 10000 A amountB: 2 B ORDER 2 submitRing 5 Exchange Process owner: Y amountS: 9 B LPSC amountB: 12 C ORDER 3 1. Protocol Authorization: In figure 2, user Y who owner: Z amountS: 100 C wants to exchange tokens authorizes the LPSC to amountB: 160 A handle amountS of token B the user wants to sell. This blockchain does not lock the user’s tokens, who remains free to move them while the order is processed. Figure 2: Loopring Exchange Process 2. Order Creation: The current rate and order book 5. Ring-Mining (Order Matching): Ring-miners try for token B vs token C, are provided by relays or to fill the order fully or partially at the given exchange other agents hooked up to the network, such as order rate or better by matching it with multiple other or- book browsers. User Y places an order (limit order) ders. Ring-mining is the main reason why the protocol specifying amountS and amountB and other parameters is able to provide high liquidity over any pair. If the through any integrated wallet interface. An amount of executed rate is better than what user Y specified, LRx can be added to the order as a fee for ring-miners; margin is shared amongst all orders in the order-ring. higher LRx fee means a better chance to be processed As a reward, the ring-miner chooses between claiming earlier by ring-miners. The order’s hash is signed with part of the margin (Margin-Split, and giving back the user Y’s private-key. LRx to the user), or simply keeping the LRx fee. 3. Order Broadcast: The wallet sends the order and 6. Verification & Settlement: The order-ring is re- its signature to one or more relays. Relays update ceived by LPSC. It makes multiple checks to verify their public order book. The protocol doesn’t require the ring-miner supplied data and determines if the 4

order-ring can be settled fully or partially (depending 7 Protocol Specification on the fill rate of orders in-ring and tokens in users’ wallets). If all checks are successful, the contract 7.1 Anatomy of an Order atomically transfers the tokens to users and pays the ring-miner and wallet fees at the same time. If user An order is a pack of data that describes the intent of the Y’s balance as determined by the LPSC is insufficient, user’s trade. A Loopring order is defined using the Uni- it will be considered scaled-down: a scaled-down Directional Order Model, or UDOM, as follows: order will automatically scale up to its original size if sufficient funds are deposited to its address, unlike message Order { a cancellation, which is a one way manual operation address protocol; and cannot be reversed. address owner; address tokenS; address tokenB; uint256 amountS; 6 Operational Flexibility uint256 amountB; It’s important to note that Loopring’s open standard allows unit256 lrcFee participants significant flexibility in how they operate. Ac- unit256 validSince; // Seconds since epoch tors are free to implement novel business models and provide unit256 validUntil; // Seconds since epoch value for users, earning LRx fees on volume or other metrics uint8 marginSplitPercentage; // [1-100] in the process (if they so choose). The ecosystem is modular bool buyNoMoreThanAmountB; and meant to support participation from a multitude of uint256 walletId; applications. // Dual-Authoring address address authAddr; // v, r, s are parts of the signature 6.1 Order Book uint8 v; bytes32 r; Relays can design their order books in any number of ways bytes32 s; to display and match users’ orders. A first implementation // Dual-Authoring private-key, of our own order book follows an OTC model, where limit // not used for calculating order’s hash, orders are positioned based on price alone. Timestamps of // thus it is NOT signed. orders, in other words, have no bearing on the order book. string authKey; However, a relay is free to design their order book in such a uint256 nonce; way as to emulate a typical centralized exchange’s matching } engine, where orders are ranked by price, while respecting timestamps as well. If a relay was inclined to offer this type To ensure the origin of the order, it is signed against of order book, they can own/integrate with a wallet, and the hash of its parameters, excluding authAddr, with the have those wallet orders sent solely to the single relay, who user’s private-key. The authAddr parameter is used for would then be able to match orders based on time. Any signing order-rings that this order is part of, which prevents such configuration is possible. front-running. Please reference section 9.1 for more details. Whereas other DEX protocols at times require Relays The signature is represented by the v, r, and s fields, and to have resources - initial token balances to place taker is sent alongside the order parameters over the network. orders - Loopring Relays need only find matchable orders to This guarantees the order stays immutable during its whole consummate a trade, and can do so without initial tokens. lifetime. Even though the order never changes, the protocol can still compute its current state based on the balance of 6.2 Liquidity Sharing its address along with other variables. UDOM doesn’t include a price (which must be a floating- Relays are free to design how they share liquidity (orders) point number by nature), but, instead uses the term rate or with each other. Our consortium blockchain is but one solu- r, which is expressed as amountS/amountB. The rate is not tion to accomplish this, and the ecosystem is free to network a floating-point number but an expression that will only be and communicate as they wish. Besides joining a consortium evaluated with other unsigned integers on demand, to keep blockchain, they can build and manage their own, creating all intermediate results as unsigned integers and increase rules/incentives as they see fit. Relays can also work alone, calculation accuracy. as seen in the time-sensitive wallet implementation. Of course, there are clear advantages in communicating with 7.1.1 Buy Amounts other Relays in pursuit of network effects, however, different business models could merit peculiar sharing designs and When a ring-miner ring-matches orders, it’s possible that split fees in any number of ways. a better rate will be executable, allowing users to get 5

more tokenB than the amountB they specified. How- 7.2.1 Sub-Ring Checking ever, if buyNoMoreThanAmountB is set to True, the pro- This step prevents arbitrageurs from unfairly realizing all tocol ensures users receive no more than amountB of the margin in an order-ring by implementing new orders tokenB. Thus, UDOM’s buyNoMoreThantokenB parameter within it. Essentially, once a valid order-ring is found by a determines when an order is considered completely filled. ring-miner, it could be tempting to add other orders to the buyNoMoreThantokenB applies a cap on either amountS or order-ring to fully absorb the users’ margin (rate discounts). amountB, and allows users to express more granular trade As illustrated by figure 3 below, carefully calculated x1, y1, intentions than traditional buy/sell orders. x2 and y2 will make the product of all orders’ rate be exactly For example: with amountS = 10 and amountB = 2, the 1 so there will be no rate discount. rate r = 10/2 = 5. Thus the user is willing to sell 5 tokenS for each tokenB. The ring-miner matches and finds the user ORDER 2 owner: Y a rate of 4, allowing the user to receive 2.5 tokenB instead amountS: 9B amountB: 12C of 2. However, if the user only wants 2 tokenB and set the buyNoMoreThanAmountB flag to True, the LPSC performs ORDER 1 ORDER 3 the transaction at a rate of 4 and the user sells 4 tokenS for owner: X amountS: 10000 A owner: Z amountS: 100 C each tokenB, effectively saving 2 tokenS. Keep in mind this amountB: 2 B amountB: 160 A does not take into account mining fees (See section 8.1). ORDER 5 ORDER 4 Indeed, if we use owner: addressM owner: M amountS: x2 C amountS: x1 A amountB: y2 A amountB: y1 B Order(amountS,tokenS, Figure 3: An order-ring with sub-ring amountB,tokenB, buyNoMoreThantokenB) This is zero-risk, zero-value add to the network, and is considered unfair conduct by the ring-miner. To prevent to represent an order in a simplified form, then for this, Loopring requires that a valid loop cannot contain any ETH/USD markets on a traditional exchange, traditional sub-rings. To check this, the LPSC ensures a token cannot buy-sell modeling can express the 1st and the 3rd order be in a buy or sell position twice. In the above diagram, we below, but not the other two: can see that token A is a sell token twice and a buy token twice, which would be disallowed. 1. Sell 10 ETH at price of 300 USD/ETH. This order can expressed as: Order(10, ETH, 3000, USD, False). 7.2.2 Fill Rate Checking The exchange rate calculations in the order-ring are made 2. Sell ETH at price of 300 USD/ETH to by ring-miners for reasons stated above. It is the LPSC get 3000 USD. This order can expressed as: that must verify they’re correct. First, it verifies that the Order(10, ETH, 3000, USD, True). buy rate the ring-miner can execute for each order is equal to or less than the original buy rate set by the user. This 3. Buy 10 ETH at price of 300 USD/ETH, This order can ensures the user gets at least the exchange rate they asked expressed as: Order(3000, USD, 10, ETH, True). for or better on the transaction. Once the exchange rates are confirmed, the LPSC ensures that each order in the 4. Spend 3000 USD to buy as many ETH as possible at order-ring shares the same rate discount. For instance, if price of 300 USD/ETH, This order can expressed as: the discounted rate is γ, then the price for each order will Order(3000, USD, 10, ETH, False). be: r0→1 · (1 − γ), r1→2 · (1 − γ), r2→0 · (1 − γ), and satisfy: 7.2 Ring Verification r0→1 · (1 − γ) · r1→2 · (1 − γ) · r2→0 · (1 − γ) = 1 (3) The Loopring Smart Contracts do not perform exchange hence: 1 rate or amount calculations, but must receive and verify γ =1− √ . (4) 3 r0→1 · r1→2 · r2→0 what the ring-miners supply for these values. These cal- culations are done by ring-miners for two main reasons: If the transaction crosses n orders, the discount is: (1) the programming language for smart contracts, such as 1 solidity[19] on Ethereum, does not have support for floating γ = 1 − qQ , (5) n−1 i point math, especially pow(x, 1/n) (calculating the n-th n i=0 r root of a floating point number), and (2) it is desirable for the computation to be made off-chain to reduce blockchain where ri is the order turnover rate of i-th order. Obvi- computation and cost. ously, only when the discount rate is γ ≥ 0, can these orders 6

be filled; and the i-th order (Oi )’s actual exchange rate is During implementation we can safely assume any order rˆi = ri · (1 − γ), rˆi ≤ ri . in the order-ring to have the lowest value, then iterate Recall our prior example where Alice has 15 token A and through the order-ring at most twice to calculate each wants 4 token B for them, Bob has 10 token B and wants 30 order’s fill volume. token A for them. If token A is the reference, then Alice is Example: If the smallest amount to be filled compared to buying token B for 154 = 3.75A, while Bob is selling token B the original order is 5%, all the transactions in the order-ring 30 for 10 = 3.00A. To calculate the discount: 120 150 = 1.25 thus are scaled down to 5%. Once the transactions are completed, 1 2 1.25 = 0.8 = (1 − γ) . Thus the exchange rate that renders the order that was considered to have the smallest amount √ the trade equitable for both parties is 0.8 · 3.75 ≈ 3.3541 remaining to be filled should be completely filled. token A per token B. Bob gives 4 token B and receives 13.4164 token A, more 7.3 Ring Settlement than the 12 he was expecting for those 4 tokens. Alice receives 4 token B as intended but gives only 13.4164 token A If the order-ring fulfills all the previous checks, the order-ring in exchange, less than the 15 she was willing to give for those can be closed, and transactions can be made. This means 4 tokens. Note, a portion of this margin will go towards that all n orders form a closed order-ring, connected as in paying fees to incentivize miners (and wallets). (See section figure 4: 8.1). O3 O2 7.2.3 Fill Tracking & Cancellation A user can partially or fully cancel an order by sending O4 O1 a special transaction to the LPSC, containing the details about the order and the amounts to cancel. The LPSC takes that into account, stores the amounts to cancel, and emits O5 On an OrderCancelled event to the network. The LPSC keeps track of filled and cancelled amounts by storing their values Figure 4: Ring Settlement using the order’s hash as an identifier. This data is publicly accessible and OrderCancelled / OrderFilled events are To make the transactions, the LPSC uses the emitted when it changes. Tracking these values is critical TokenTransferDelegate smart contract. The introduction for the LPSC during the order-ring settlement step. of such a delegate makes upgrading the protocol smart LPSC also supports cancelling all orders for any trading contract easier as all orders only need to authorize this pair with the OrdersCancelled event and cancelling all delegate instead of different versions of the protocol. orders for an address with the AllOrdersCancelled event. For each order in the order-ring, a payment of tokenS is made to the next or the previous order depending on the implementation. Then the ring-miner’s fee is paid depending 7.2.4 Order Scaling on the fee model chosen by the ring-miner. Finally, once all Orders are scaled according to the history of filled and the transactions are made, a RingMined event is emitted. cancelled amounts and the current balance of the senders’ accounts. The process finds the order with the smallest 7.3.1 Emitted Events amount to be filled according to the above characteristics and uses it as a reference for scaling all transactions in the The protocol emits events that allow relays, order browsers, order-ring. and other actors to receive order book updates as efficiently Finding the lowest value order can help to figure out the as possible. The emitted events are: fill volume for each order. For instance, if the i-th order is the lowest value order, then the number of tokens sold from • OrderCancelled: A specific order has been can- each order ŝ and number of tokens purchased b̂ from each celled. order can be calculated as: • OrdersCancelled: All orders of a trading pair from an owning address have been cancelled. ŝi = si , b̂i = ŝi /r̂i , ; ŝi⊕1 = b̂i , b̂i⊕1 = ŝi⊕1 /r̂i⊕1 ; • AllOrdersCancelled: All orders of all trading pairs from an owning address have been cancelled. ŝi⊕2 = b̂i⊕1 , b̂i⊕2 = ŝi⊕2 /r̂i⊕2 ; ... • RingMined: An order-ring has been settled success- fully. This event contains data related to each inner- where si is the balance left after orders are partially filled. ring token transfer. 7

8 LRx Token Figure 6: Loopring’s Fee Model LRx is our generalized token notation. LRC is the Loopring where f is the LRx fee, x is the margin split, y is the token on Ethereum, LRQ on Qtum, and LRN on NEO, etc. mining income. y = max(f, x − f ) as indicated by the Other LRx types will be introduced in the future as Loopring solid line; if the LRx fee for the order is 0, the equation is deployed on other public blockchains. is y = max(0, x − 0) that simplifies to y = x as indicated by the gray line. 8.1 Fee Model The consequences are: When a user creates an order, they specify an amount of 1. If the margin split is 0, ring-miners will choose the flat LRx to be paid to the ring-miner as a fee, in conjunction LRx fee and are still incentivized. with a percentage of the margin (marginSplitPercentage) 2. If the LRx fee is 0, the gray line results and the income made on the order that the ring-miner can claim. This is is based on a general linear model. called the margin split. The decision of which one to choose (fee or margin split) is left to the ring-miner. 3. When the margin split income is greater than 2x(LRx A representation of the margin split: fee), ring-miners choose the margin split and pay LRx to the user. AdditionalBuyAmount It should be noted that if the LRx fee is non-zero, M arginSplit no matter which option the ring-miner chooses, there will OrderOriginalBuyAmount always be a transfer of LRx between the ring-miner and the order’s sender. Either the ring-miner earns the LRx fee, or pays the LRx fee back to the sender to take the margin split. Ring-miners will share a certain percentage of fees with wallets. When a user places an order through a wallet and T otalBuyAmount gets filled, the wallet is rewarded with a portion of the fees or OrderActualBuyAmount M argin margin split. Although this is modular, and unique business models or implementations are possible, our inclination is for Figure 5: A 60% Margin Split wallets to receive approximately 20%-25% of earned fees. Wallets represent a primary target for Loopring protocol If the margin on the order-ring is too small, a ring- integration as they have the user base, but little or no source miner will choose the LRx fee. If, on the contrary, the of income. margin is substantial enough for the resulting margin split to be worth much more than the LRx fee, a ring-miner will 8.2 Decentralized Governance choose the margin split. There is another proviso, however: when the ring-miner chooses the margin split, they must At its root, the Loopring protocol is a social protocol in pay the user (order creator) a fee, which is equal to the LRx the sense that it relies on coordination amongst members to the user would have paid to the ring-miner as a fee. This operate effectively towards a goal. This is not dissimilar to increases the threshold of where the ring-miner will choose cryptoeconomic protocols at large, and indeed, its usefulness the margin split to twice the LRx fee of the order, increasing is largely protected by the same mechanisms of coordina- the propensity of the LRx fee choice. This allows ring-miners tion problems [20], grim trigger equilibrium, and bounded to receive a constant income on low margin order-rings for rationality. To this end, LRx tokens are not only used to the tradeoff of receiving less income on higher margin order- pay fees, but also to align the financial incentives of the rings. Our fee model is based on the expectation that as the various network participants. Such alignment is necessary market grows and matures, there will be fewer high margin for broad adoption of any protocol, but is particularly acute order-rings, thus necessitating fixed LRx fees as incentive. for exchange protocols, given that success rests largely on We end up with the following graph: improving liquidity in a robust decentralized ecosystem. LRx tokens will be used to effectuate protocol updates y through decentralized governance. Smart contract updates will, in part, be governed by token holders to ensure continuity and safety, and to attenuate the risks of siphoned liquidity through incompatibility. Given that smart con- tracts cannot be altered once deployed, there is a risk that f ExpectedM iningIncome dApps or end users continue to interact with deprecated versions and preclude themselves from updated contracts. x Upgradeability is crucial to the protocol’s success as it must f 2f adapt to market demands and the underlying blockchains. 8

Decentralized governance by LRx stakeholders will allow for Dual Authoring process: protocol smart contract updates without disrupting dApps or end users, or relying too heavily on smart contract 1. For each order, the wallet software will generate a abstraction. LRx tokens have a fixed supply, and in the case random public-key/private-key pair, and put the key of LRC, certain percentages are frozen from the Loopring pair into the order’s JSON snippet. (An alternative is Foundation, and allocated to community-purposed funds to use the address derived from the public-key instead [21]. of the public-key itself to reduce byte size. We use However, LRx token owners are not the only stakeholders authAddr to represent such an address, and authKey to consider in steering the protocol’s direction: relays/ring- to represent authAddr’s matching private-key). miners, wallets, developers, and others are an integral part 2. Compute the order’s hash with all fields in the order of the ecosystem and their voice must be heard. In fact, except r, v, s, and authKey), and sign the hash using given that these agents need not hold any LRx to perform the owner’s private-key (not authKey). their respective roles (since traditional makers/takers and market-makers are nonexistent, initial token reserves are 3. The wallet will send the order together with the not mandatory) we must allow alternative methods for their authKey to relays for ring-mining. Ring-miners will interests to be respected. Furthermore, ”simple” token- verify that authKey and authAddr are correctly paired based voting, both on-chain and off, is an imperfect salve and the order’s signature is valid with respect to owner for disagreement, as low voter turnout and token ownership address. concentration pose risks. Thus, the goal is to implement a governance model that is built in layers, and rests on a 4. When an order-ring is identified, the ring-miner will shared knowledge that some set of decision-making processes use each order’s authKey to sign the ring’s hash, is the norm. This can be facilitated by coordination institu- minerAddress, and all the mining parameters. If an tions that offer signals from a diverse set of participants, and, order-ring contains n orders, there will be n signatures perhaps, from pre-established protocol focal points. As this by the n authKeys. We call these signatures the comes to fruition, the Loopring Foundation will inevitably authSignatures. The ring-miner may also need to evolve from protocol developers into protocol stewards. sign the ring’s hash together with all mining parame- ters using minerAddress’s private-key. 9 Fraud and Attack Protections 5. The ring-miner calls the submitRing function with all the parameters, as well as all the extra 9.1 Front-running Prevention authSignatures. Notice that authKeys are NOT part of the on-chain transaction and thus remain unknown In decentralized exchanges, front-running is when someone to parties other than the ring-miner itself. tries to copy another node’s trade solution, and have it mined before the original transaction that is in the pending 6. The Loopring Protocol will now verify each transaction pool (mempool). This can be achieved by authSignature against the corresponding authAddr specifying a higher transaction fee (gas price). The major of each order, and reject the order-ring if any scheme of front-running in Loopring (and any protocol for authSignature is missing or invalid. order-matching) are order-filch: when a front-runner steals one or more orders from a pending order-ring settlement The result is that now: transaction; and, specific to Loopring: when a front-runner steals the entire order-ring from a pending transaction. • The order’s signature (by the private-key of the owner When a submitRing transaction is not confirmed and address) guarantees the order cannot be modified, is still in the pending transaction pool, anyone can easily including the authAddr. spot such a transaction and replace minerAddress with • The ring-miner’s signature (by the private-key of the their own address (the filcherAddress), then they can re- minerAddress), if supplied, guarantees nobody can sign the payload with filcherAddress to replace the order- use his identity to mine an order-ring. ring’s signature. The filcher can set a higher gas price and submit a new transaction hoping block-miners will pick his • The authSignatures guarantees the entire order-ring new transaction into the next block instead of the original cannot be modified, including minerAddress, and no submitRing transaction. orders can be stolen. Previous solutions to this problem had important down- sides: requiring more transactions and thus costing ring- Dual Authoring prevents ring-filch and order-filch while miners more gas; and taking at least twice the blocks to still ensuring the settlement of order-rings can be done settle an order-ring. Our new solution, Dual Authoring[22], in one single transaction. In addition, Dual Authoring involves the mechanism of setting up two levels of authoriza- opens doors for relays to share orders in two ways: non- tion for orders - one for settlement, and one for ring-mining. matchable sharing and matchable sharing. By default, 9

Loopring operates an OTC model and only supports limit- • Free, public smart contracts enable any dApp to build price orders, meaning that orders’ timestamps are ignored. or interact with the protocol. This implies that front-running a trade has no impact on • Standardization among operators allows for network the actual price of that trade, but does impact whether it effects and an improved end user experience. gets executed or not. • Network maintained with flexibility in running order books and communicating. 10 Other Attacks • Reduced barriers to entry means lower costs for nodes 10.1 Sybil or DOS Attack joining the network and end users. Malicious users – acting as themselves or forged identities – • Anonymous trading directly from user wallets. could send a large amount of small orders to attack Loopring nodes. However, since we allow nodes to reject orders based 12 Acknowledgements on their own criteria – which they may hide or reveal – most of these orders will be rejected for not yielding satisfying We would like to express our gratitude to our mentors, profit when matched. By empowering relays to dictate how advisers and to the many people in the community that they manage orders, we do not see a massive tiny order have been so welcoming and generous with their knowledge. attack as a threat. In particular, we would like to thank Shuo Bai (from ChinaLedger); Professor Haibin Kan; Alex Cheng, Hongfei 10.2 Insufficient Balance Da; Yin Cao; Xiaochuan Wu; Zhen Wang, Wei Yu, Nian Duan, Jun Xiao, Jiang Qian, Jiangxu Xiang, Yipeng Guo, Malicious users could sign and spread orders whose order Dahai Li, Kelvin Long, Huaxia Xia, Jun Ma, and Encephalo value is non-zero but whose address actually has zero Path for reviewing and providing feedback on this project. balance. Nodes could monitor and notice that some orders actual balance is zero, update these order states accordingly and then discard them. Nodes must spend time to update References the status of an order, but can also choose to minimize the effort by, for example, blacklisting addresses and dropping [1] Vitalik Buterin. Ethereum: a next generation smart related orders. contract and decentralized application platform (2013). URL {http://ethereum. org/ethereum. html}, 2017. [2] Gavin Wood. Ethereum: A secure decentralised gen- 11 Summary eralised transaction ledger. Ethereum Project Yellow The Loopring protocol sets out to be a foundational layer Paper, 151, 2014. for decentralized exchange. In so doing, it has profound [3] Patrick Dai, Neil Mahi, Jordan Earls, repurcussions in how people exchange assets and value. and Alex Norta. Smart-contract value- Money, as an intermediate commodity, facilitates or replaces transfer protocols on a distributed mobile barter exchange and solves the double coincidence of wants application platform. URL: https://qtum. problem [23], whereby two counterparties must desire each org/uploads/files/cf6d69348ca50dd985b60425ccf282f3. other’s distinct good or service. Similarly, Loopring protocol pdf, 2017. aims to dispense of our dependencies on coincidence of wants in trading pairs, by using ring matching to more easily [4] Viktor Atterlönn. A distributed ledger for gamification consummate trades. This is meaningful for how society and of pro-bono time, 2018. markets exchange tokens, traditional assets, and beyond. [5] Hernando de Soto. The Mystery Of Capital. Basic Indeed, just as decentralized cryptocurrencies pose threat Books, 2000. to a nation’s control over money, a combinatorial protocol that can match traders (consumers/producers) at scale, is a [6] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic theoretical threat to the concept of money itself. cash system. 2008. Protocol benefits include: [7] Fabian Schuh and Daniel Larimer. Bitshares 2.0: Financial smart contract platform, 2015. • Off-chain order management and on-chain settlement means no sacrifice in performance for security. [8] Bancor protocol. URL https://bancor.network/, 2017. • Greater liquidity due to ring-mining and order sharing. [9] Yaron Velner Loi Luu. Kybernetwork: A trustless decentralized exchange and payment • Dual Authoring solves the pernicious problem of front service. https://kr.kyber.network/assets/ running faced by all DEXs and their users today. KyberNetworkWhitepaper.pdf, Accessed: 2018-03-05. 10

[10] Fortune. How to steal $500 million in [17] Supersymmetry. Remarks on loopring. cryptocurrency. http://fortune.com/2018/01/ https://docs.loopring.org/pdf/ 31/coincheck-hack-how, Accessed: 2018-03-30. supersimmetry-loopring-remark.pdf, Accessed: 2018-03-05. [11] Robert McMillan. The inside story of mt. gox, bitcoins 460 dollar million disaster. 2014. [18] Fabian Vogelsteller. Erc: Token standard. URL https://github.com /ethereum /EIPs /issues /20, 2015. [12] Sylvain Ribes. Chasing fake volume: a crypto-plague. https://medium.com/@sylvainartplayribes/ [19] Chris Dannen. Introducing Ethereum and Solidity. chasing-fake-volume-a-crypto-plague-ea1a3c1e0b5e, Springer, 2017. Accessed: 2018-03-10. [20] Vitalik Buterin. Notes on blockchain gover- [13] Rossella Agliardi and Ramazan Genay. Hedging nance. https://vitalik.ca/general/2017/12/17/ through a limit order book with varying liquidity. 2014. voting.html, Accessed: 2018-03-05. [14] Will Warren and Amir Bandeali. 0x: An open protocol [21] Loopring Foundation. Lrc token documents. for decentralized exchange on the ethereum blockchain, https://docs.loopring.org/English/token/, 2017. Accessed: 2018-03-05. [15] Iddo Bentov and Lorenz Breidenbach. The cost of [22] Daniel Wang. Dual authoring looprings solution to decentralization. http://hackingdistributed.com/ front-running. URL https://medium.com/loopring- 2017/08/13/cost-of-decent/, Accessed: 2018-03-05. protocol/dual-authoring-looprings-solution-to-front- running-d0fc9c348ef1, 2018. [16] Daniel Wang. Coinport’s implemenation of udom. https://github.com/dong77/backcore/blob/ [23] Nick Szabo. Menger on money: right and wrong. master/coinex/coinex-backend/src/main/scala/ http://unenumerated.blogspot.ca/2006/06/ com/coinport/coinex/markets/MarketManager. menger-on-money-right-and-wrong.html, Accessed: scala, Accessed: 2018-03-05. 2018-03-05. Appendices Appendix A Loopring Implemented on EVM LoopringProtocol - Defines interfaces and events NameRegistry LoopringProtocolImpl TokenRegistry - Registers wallets and relays - Validates order-rings - Registers ERC20/ERC223 tokens - Transfers tokens for settlement - Emits events TransferableMultsig TokenTransferDelegate - Enables multisignature - Transfers tokens on behalf of users ownership Figure 7: Smart Contracts 11

Appendix B Deployment B.1 Ethereum The following smart contracts have been deployed on Ethereum mainnet: • LRC: 0xEF68e7C694F40c8202821eDF525dE3782458639f • TokenRegistry: 0xa21c1f2AE7f721aE77b1204A4f0811c642638da9 • TokenTransferDelegate: 0x7b126ab811f278f288bf1d62d47334351dA20d1d • NameRegistry: 0xd181c1808e3f010F0F0aABc6Fe1bcE2025DB7Bb7 • LoopringProtocolImpl: 0x0B48b747436f10c846696e889e66425e05CD740f B.2 Qtum The following smart contracts have been deployed on Qtum mainnet: • LRQ: 2eb2a66afd4e465fb06d8b71f30fb1b93e18788d • TokenRegistry: c89ea34360258917daf3655f8bec5550923509b3 • TokenTransferDelegate: 60b3fa7f461664e4dafb621a36ac2722cc680f10 • NameRegistry: e26a27d92181069b25bc7283e03722f6ce7678bb • LoopringProtocolImpl: 5180bb56b696d16635abd8dc235e0ee432abf25d 12