Loopring is an order-based DEX protocol. The 3.0 version scales by migrating most storage and computation off the Ethereum blockchain. User balances and order trading histories are maintained as part of an off-chain Merkle tree per DEX.
Requests, such as deposits, withdrawals, order cancellation, and trade settlements, are processed as batches to update the Merkle tree. For each batch, the DEX operators only need to publish a 32 bytes post-processing Merkle tree root to Ethereum — and then, asynchronously, provide a Zero-Knowledge proof to verify user balances and order trading histories have been updated strictly by the rules enforced by the protocol.
Thanks to SNARKs, Loopring can settle up to 660 trades per second. If the on-chain data-availability feature is enabled, Loopring can still settle 200 trades per second. We expect to implement a more efficient data compression solution to offer even higher throughput.
The current beta release,
v3beta2, supports the following features:
- Symmetric order modeling: All orders take the same format, regardless if they are maker orders or taker orders.
- Dual Authoring: This is inherited from the previous versions to prevent orders or settlement requests from being stolen.
- Order auto-scaling and partial matching.
- Withdrawal mode: When a DEX fails to fulfill duties enforced by the protocol, users can withdraw their full balances by providing valid Merkle proofs (and the DEX operator got slashed). If on-chain data-availability is on, Merkle proofs can be generated merely from on-chain data; otherwise, users will have to request data from DEX operators.
- Maintenance mode: Loopring provides a way for DEX operators to temporarily suspend user requests so they can upgrade their infrastructure. This is critical to ensure DEXes can be truly production-ready.
- Proactive withdrawal distribution: Loopring DEX operators distribute approved withdrawn balances back to users’ addresses in a proactive way. This means users do not have to take a second action to get their tokens back to their own wallets — same as centralized exchanges.
- We’ll pay up to 250,000 LRC for each critical bug, defined as a bug that causes all funds to be susceptible to loss; up to 100,000 LRC for each bug that loses one user’s fund; and up to 50,000 LRC for other bugs.
- Performance enhancement suggestions are welcomed but do not qualify for bounties. We have many existing ideas on how to improve the throughput and/or lower the cost. That said, if your idea is truly inspiring and eventually gets adopted, we may still grant you some tokens at our discretion.
- This bounty program is set up only for the Smart Contracts in
v3beta2, circuits excluded. Bugs found in other versions don’t qualify. The
Design Docis something you must read to understand the overall design and solidity code.
- This bounty program is valid for 3 months (Oct 13, 2019).
How to submit your findings
- Create an issue at https://github.com/Loopring/protocols/issues.
- Prefix your issue with
[Protocol3], and add
Loopring Protocol 3as Projects. Please also label it as
- If you just want to reach out to ask questions, please also create an issue — unless there is a duplicate one, and label it as
Thanks! Looking forward to the community’s help. Here is this same bug bounty as a GitHub issue. We will also be using Gitcoin to handle the bounty program, so please feel free to check it out here too.
⭑ Twitter: twitter.com/loopringorg
⭑ Reddit: reddit.com/r/loopringorg
⭑ Telegram: t.me/loopring_en & t.me/loopringfans (Chinese)
⭑ Discord: discord.gg/KkYccYp
⭑ GitHub: https://github.com/Loopring
⭑ Kakao: open.kakao.com/o/gJbSZdF (Korean)