The Story Of MCDEX Part III

M: These are really helpful and interesting points. Taking a look at the DeFi space, we found out that a lot of projects, including those deployed to L2, are working to solve the liquidity issue. All of them finally came to the same solution, which is to improve capital efficiency. For example, Uniswap V3 aims to concentrate the liquidity within a custom price range

I have a question regarding the second point on permissionless. If I am a liquidity provider and I have created a liquidity pool, will there be a scenario whereby someone wants to trade against my pool? Also, liquidity providers may have concerns that the collateral of the pool is risky and thus they may not want to trade in my pool and create another one instead. Could you please walk us through the process?

L: Sure. We will need to touch on the role of the operator which is a crucial role in the MCDEX ecosystem. The operator’s responsibility is to create a pool and set some risk parameters. The pool is relatively flexible where risk and revenue can be changed by adjusting some parameters. But one thing to note is that the benefits and risks of different assets may be different. Therefore, the parameters of the pool can be adjusted — the operator can tune within the specified range in order. That means that the parameters are often not the optimal ones and requires some fine tuning which is similar to how centralized exchanges operate. For some important pool settings, parameters such as the depositing ratio takes care of the initial risks. Operators can change some parameters that are less critical parameters. This way, we can find a balance to keep MCDEX decentralised and efficient at the same time.

For Liquidity Providers (LPs), they can check the performance of each pool, such as risks, drawbacks and revenue. LPs only need to deposit one asset in the pool instead of two. For example, if the pool is an USDC pool, users will only need to deposit USDC. Then you can enjoy the market maker’s revenue and a share of the transaction fee. It is very simple for retail users to join the pool as a LP. Users can add and withdraw liquidity at any time. However, it is important to note that there are tons of pools out there and users have to use at their own risks when deciding which pool they wish to join. Simply checking the historical data could work. All these processes are on chain, which has no possibility of cheating.

Just one more thing, in order to maximize liquidity, our pools can support multiple perpetual swaps (no more than 10). In this case, the market maker’s funds will be fully used, just like a cross margin. If a user is dissatisfied with the existing pool, he can also create a pool by himself. If the risk parameters of this pool are well set, the return for LPs will be high and the liquidity will be good. This will in turn attract more LPs and traders to the pool. Interestingly, this is similar to the model adopted by Taobao — MCDEX is the platform, and the pools are stores. Finally, some boutique shops will be created through market competition.

M: I see. When improving the capital efficiency, it is equivalent to limiting the liquidity to a certain range — requiring LPs to provide liquidity within a custom range, which raises the bar of becoming an LP. Both Uniswap V3 and MCDEX V3 have the same approach here. For LPs if there are several USDC pools, LPs should evaluate each pool to manage risks. One interesting fact about Uniswap V3 is that there are some professionals providing some guidance for retail LPs on how to provide liquidity in a certain range. This is interesting. Of course, some people may find it contradictory because there are some protocols acting as middlemen here and it seems that we have returned to the old mode of providing liquidity.

L: I agree. In traditional finance, the “capital end” and the “asset end” are separated. Some services focus on the capital aspect whereas others focus on the asset. The capital aspect is closer to the user and its services will help users to choose assets in a professional way. This is a professional process, whether it is done through the protocol or people in general. This way, we get professional products and help the industry to mature which is not a bad thing in my opinion.

M: You just shared that users can add markets in a permissionless way. I’m curious that what markets are currently live now?

L: We are now on the testnet, mainnet has not launched yet. When launching, we shall have several markets. First one will be the pool operated by MCDEX DAO. There will be many basic markets such as BTC and ETH. We are also working with some index teams, who will operate some index markets, such as DPI. On our testnet, we have SP500 and Tesla markets running, so you can trade US stocks and US stock index contracts on MCDEX. Meanwhile, we are communicating with many teams, inviting them to become operators so as to enrich the markets, not only within crypto but also some assets in traditional finance. Someone is considering to do FX markets. I believe permissionless can amplify these possibilities.

M: Well, I understand, The index price is provided by an external oracle, so the performance of Ethereum layer one is not able to support it. Will you also deploy on Ethereum mainnet? or in addition to arbitrum, will you also consider other chains?

L: This is a very good question. The first point is that one of our assumptions is that the infra has a good performance, which the Ethereum mainnet doesn’t meet. The second point is about the external oracles. Our expectation is that off-chain assets, such as stock marekts, will use the external oracles. As for on-chain assets, we prefer to use an on-chain oracle. So we are seriously considering using uniswap v3 as oracles. For assets such as eth, the pricing power is already on-chain (on uniswap), which perfectly matches our needs.In this way,an on-chain circle is formed.

You mentioned other chains. We are definitely considering them. We have multi-chain deployment strategy. We believe that even after arbitrum is launched, it may not be able to solve all demands. The gas fee may increase in a few months. This is inevitable. Some users will find it too expensive and switch to other chains. Also, there are some users who don’t want to use Ethereum. For example, a user I talked to before told me that he is a fan of BSC. For such users, the best way to onboard him is to deploy on BSC.

M: You talked about oracles. I’ve thought about cross-chain oracles before.Just imagine whether cross-chain oracles make sense. Of course cross-chain oracles may have a delay problem, and I agree with the concept of on-chain oracles you just mentioned. There is no need for a decentralized exchange to use centralized exchanges as price feeds. Just like the previous case of DAI on Compound, coinbase was used as an oracle. There was an accident caused by that.M: I just talked about other chains. Actually, I also want to ask you why you chose arbitrum when people in China don’t know much about it yet. Can you briefly talk about which ETH Layer2 project you have researched? What are the characteristics and principles of arbitrum? Why did you choose arbitrum?

L: ok, this is also a very good question. In fact, I have learned about all the Layer 2 solutions. There are several categories. One is rollup. Rollup is divided into two categories, composable and not composable. Rollups that are composable means that the network is universal and there is no need to customize the network for decentralised applications deployed on it, include arbitrum , Optimism, zk sync. These rollups are all built for a goal that any developer can deploy smart contracts, and these contracts can interact with each other. The other type is non-composable, such as the starkware, which cannot directly interact with other rollups after it launched.

Then there are side chains, such as the well-known project — — polygon, xdai. Side chains are not bad choice. The only problem is that the degree of decentralization is somewhat low and cannot reach the security level of the mainnet. This is why the Ethereum community has been unable to recognize the sidechain as an ideal layer2 solution. In fact, I think the side chain is a good transition plan.

We have seriously considered whether to use the side chain, but we feel that according to the development progress of v3, when v3 is completed, arbitrum should be available, so we give up the side chain. There are also some products, such as Bsc or Heco exchange public chains, we also think it is good, these are technically the same as the side chains, but if large funds come in and out, you have to go to their main site.

We have also learned about earlier solutions, such as state channels, plasma, but they are all excluded because they are not composable. If we develop on these chains, we will have to rewrite the code and we can not interact with other smart contracts, so we gave up them in the early stages.

Building MCDEX V3 (Decentralized Perpetual) | Trade #PerpetualContracts - #Permissionless #1000x Uni’s capital efficiency #Anyone can create any market