Loopring Protocol 2.0 Has Launched: What It Means
Loopring protocol 2.0 recently completed smart contract audits by third-party smart contract security firm SecBit, and has been deployed.
We wanted to go over some of the new features, and give a bit more detail on the technical aspects.
More Efficient Ring Settlement
Orders can be filled a lot more efficiently than in Loopring 1.X.
Loopring 1.X was limited to a single ring per transaction. In Loopring 2.0 multiple rings can be submitted in a single transaction. This allows Loopring 2.0 to settle rings a lot more efficiently:
- Orders can be used in multiple rings but the order data only needs to be sent once (saving on expensive calldata)
- Expensive token transfers are merged so we need to do less of them
- We can batch state queries and updates. Every external contract call costs gas, so doing less of them reduces cost.
- Updating the trade history (i.e. how much orders are filled) only needs to be done once, no matter how many times the orders are used in the rings. This saves a lot on expensive SSTOREs
We also introduced a contract for holding fees. The fee that is paid by the order owner can be shared between multiple parties (wallet, miner and burn rate). This would take expensive separate token transfers to send fees to each party every time. By sending the fees to a contract where each party can withdraw the fees, we further reduce the number of token transfers we need to do.
On top of this, we compress the data that needs to be sent to the smart contract (calldata) by packing the data together and reusing data between orders.
Fee Model 2.0
We released a post on this a few months ago, but now the fee model is live. If you recall, fees can be paid in any token, with a portion of wallet/miner income being burned in LRC. Here are the updated burn rate parameters, which will ultimately be configurable:
More Ways to Create Orders
In Loopring 1.X all orders had to be signed by the order owner. In Loopring 2.0 orders can be created in more ways:
- The owner can of course still sign and cancel its own orders
- The owner can allow a broker to submit and cancel orders on its behalf. This is done by registering the broker in the broker registry contract. You can allow as many brokers as you want to trade for you. You can of course also unregister the broker.
- The order can be registered in the order registry. This allows even contracts to create orders (contracts cannot sign orders like normal Ethereum accounts because they do not have a private key). Contracts can now also cancel orders by using msg.sender for authentication instead of tx.origin.
All or None Orders
All or None orders are orders that need to be filled completely or not at all. Protocol 2.0 supports All or None orders on the transaction level. This means that the All or None order can be filled in multiple rings, as long as the order is completely filled at the end of the transaction!
Support for More Signature Types
Protocol 1.X was limited to the standard ECDSA signing method of Ethereum. In Protocol 2.0 was designed in a way to support any signature type possible by storing the signature in the multihash format. Currently, we support the standard Ethereum signing method and EIP712. Signing data with EIP712 is great because it allows you to see what data you sign!
On-chain Order Sharing
Orders can now be submitted to the on-chain order book by the order owner or its broker. The data of the order is emitted in an event, which allows sharing orders without relying on off-chain mechanisms.
No Token Registration
In Loopring 1.X every token needed to be registered in the smart contracts before it was possible to trade it. In Protocol 2.0 this is not needed anymore. All tokens can be traded by the protocol. It’s purely up to the DEX to decide which tokens are tradable.
Coming Soon
We’re not stopping here! New features are already being developed:
- We added ERC1400 security token support to the protocol, ready for release once the ERC1400 token standard is finalized! Read here why we think security tokens are important.
- An integration with DutchX for fee burning is well underway. In the new fee model any token can be used to pay fees. A part of the fee earned by wallets and miners is reserved to burn LRC (we call this the burn rate). If the fee is paid in a non-LRC token we will use the Dutch auction model provided by DutchX to buy LRC and burn it in a decentralized way.
- We will add support for paying directly with ETH for the taker instead of having to manually wrap ETH in WETH.
Much more to come. Stay tuned during the next week for the 2019 updated roadmap, where our sights are already on 3.0.
Thanks to Brecht Devos, Loopring protocol dev, for help with this post (not to mention actually building this stuff! :).
To stay up-to-date with Loopring, please sign up for Loopring’s Bi-Weekly Update, and find us here:
⭑ 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)
