Although MCDEX V3 will apply a multi-chain deployment strategy in order to better serve more communities over various ecosystems, Ethereum is still the central focus. However, both the skyrocketing gas fee and the heavy congestion of Ethereum L1 are hindering a smooth user experience of the platform. We are rigorously searching for an appropriate L2 solution due to the following reasons:
- Decrease Gas Fees: Due to the complexity of perpetual swap trading, the gas fee of perpetuals on MCDEX is approximately 5 times higher than that of a typical spot trading (e.g. Uniswap) transaction. When L1 is congested, the gas price keeps reaching new peaks, causing the trading costs to shoot up even higher.
- To Improve Liquidation Efficiency: Liquidation efficiency is extremely important to our platform because users would like to apply higher leverage (aka smaller maintenance margin) and, in order to provide such opportunities, the platform must have the capability to promptly liquidate positions with insufficient maintenance margin. In order to achieve this, we need to build our platform on infrastructure with higher capacity and throughput, that can process larger volumes with quicker finality. Under certain circumstances, small compromises on decentralization may be appropriately sacrificed to massively improve liquidation efficiency.
So…what are we looking for?
Product Readiness: First and foremost, the technology itself has to be mature. An ideal situation would be one that has its mainnet published and has been explored by users and dAPPs. One that’s still under development would still be acceptable as long as it is able to match our development timeline.
Decentralization: In order to support a platform that will be handling up to billions of dollars in transaction value, we need an L2 solution that is highly decentralized. A system with a security level comparable to and derived from Ethereum L1 would be perfect.
Developer-Friendliness: The L2 solution should be EVM-compatible and should provide a mature and complete toolchain (e.g. compiler, debugger, and sandbox), nodes (L1 API compatible), and basic infrastructure (The Graph, etc.).
Fee and performance: This L2 solution should drastically decrease gas fee, maximize TPS, and minimize confirmation time. These qualities are essential for improving the liquidation efficiency of MCDEX.
Available L2 solutions include:
1. State channels
We can first eliminate state channels, Plasma, and Starkware because EVM compatibility is indispensable. Although ZKRollup by Matter Labs promised to support EVM smart contracts in the future, the exact progress and timeline of this are still unknown. In this sense, ZKRollups do not match our V3’s development progress. With respect to sidechains, while they are actually a great “transition” choice, considering that the Optimistic Rollups will become available for mainnet within 3 months and are more decentralized in nature, we have chosen to focus on various Optimistic Rollup options.
Optimism OVM vs Offchain Labs Arbitrum
Both OVM by Optimism (aka Optimistic Rollup) and Arbitrum (aka Arbitrum Rollup) by Offchain Labs are wonderful Optimistic Rollup solutions. The technical difference is that OVM utilizes single-round interactive fraud proofs, whereas Arbitrum applies multi-round interactive fraud proofs. There are no other major differences on how each derives security from Ethereum, so we can assume that these two solutions have similar levels of decentralization.
After much research, MCDEX has decided to launch V3 Arbitrum at the moment for the following reasons:
- On-chain cost: A multi-round interactive rollup has a lower cost than a single-round interactive, which allows for higher throughput on the rollup.
- Product readiness: Neither solution has launched its mainnet, but Arbitrum provides detailed documentation, code, and a permissionless testnet. The code is under audit and its mainnet launching timeline aligns with the MCDEX V3 developing progress.
- Developer-friendliness: Arbitrum provides a completely EVM-compatible developing environment and node API. We have deployed MCDEX V2 on Arbitrum’s permissionless testnet without revising a single line of code. Infrastructures including The Graph work smoothly as well. In contrast, OVM requires developers to revise the code when dealing with timing-related operations. Moreover, a bigger problem is that OVM requires team approval at an early stage, which restricts the developer’s exploration freedom.
- Sequencer Model: The Sequencer Model is an upcoming new feature of Arbitrum. It allows Arbitrum users to quickly confirm their transaction status directly on L2 without having to wait for the transaction to transfer onto L1. Although this feature makes the product slightly less decentralized, it speeds up the confirmation process a lot. In addition, the Arbitrum team is working on solutions that will decentralize the sequencer model even more over time. With the Sequencer model, both the trading speed and liquidation efficiency will be drastically increased.
While we believe a ZK-Rollup is a more suitable technology, in the long run, ZK-Rollup still has a higher risk and longer development time. Therefore, our project would like to start with a relatively mature solution like Arbitrum. Additionally, in the future, as the ZK-Rollup technology develops, the Offchain Labs team is planning to add ZK proofs to Arbitrum, thus incorporating the benefits of zero-knowledge technology into their rollup solution.