With the support of AI, I alone + AI essentially form a complete team.

Written by: Keegan

In fact, I had been planning this for a long time: to create a Perp DEX myself, but not to operate it; instead, I wanted to turn it into a white-label product to sell to teams that truly need it. For those teams in need, you can now contact me to pre-order this system.

This idea has been in my mind for a long time, and I have gone through many iterations of it. However, due to various real-world reasons, I had not truly started until now. Recently, I have become increasingly aware of one thing: if I don't start now, I will probably keep dragging it out. So this time, I didn't make excuses for myself. This weekend, I just got started.

Over the years, I have lost count of how many trading systems I have participated in designing and implementing. But to take on an entire system—from architecture, protocols, matching logic, risk control to front-end and back-end—by myself is indeed a first.

If this were two years ago, it would have taken at least a team of ten to twenty people and half a year to barely get the project off the ground.

But now, things are different.

With the support of AI, I alone + AI essentially form a complete team. And more importantly—when all the core details are controlled by me alone, I am more confident than ever before that I can get it right.

Of course, this task is not simple.

To truly complete a Perp DEX, it is far more than just stitching together contracts and front-end and back-end. From account models, matching and clearing logic, risk control, fund security, to handling exceptional scenarios, any link that is not deeply understood can lead to problems in real trading.

The DEX I am going to build will adopt a hybrid architecture of off-chain matching + on-chain settlement, and it will include many modules. Today, I will share some design thoughts on the deposit and withdrawal module.

Deposit and Withdrawal Module

The deposit and withdrawal module I designed for this DEX has several core functions:

• Users can directly call the contract deposit() through their wallets to complete deposits.
• Supports multi-chain deposits and withdrawals, specifically for the most commonly used EVM chains.
• Supports cross-chain deposits and withdrawals, allowing users to deposit on chain A and withdraw on chain B.
• Supports multi-currency deposits and withdrawals, enabling users to deposit with different tokens and withdraw in different tokens.

We need to deploy contracts on multiple different chains to provide deposit functions. The off-chain wallet service needs to listen for deposit events from all chains to settle the corresponding asset accounts in the user's wallet on-chain. The settlement assets should use a unified unit, and I will use USDC as the unified settlement unit.

For multi-currency deposits and withdrawals, the goal is to achieve automatic conversion between other tokens and USDC, which can be accomplished by integrating DEXs like Uniswap/PancakeSwap or aggregators like 1inch/OKX.

The main challenge actually lies in withdrawals.

Since it is an off-chain matching model, the user's position information and trading profits and losses are only known to the off-chain system; the contract cannot verify the user's withdrawable amount, which must be authorized by a backend signature. Therefore, preventing the leakage of the signing private key or malicious actions by the signer is a challenge.

Additionally, since cross-chain deposits and withdrawals are allowed, when a user withdraws on chain B, the contract on chain B may not have enough withdrawable assets. How to avoid or reduce this situation is another challenge.

Layered Withdrawal Mechanism

Regarding the first challenge, my solution mainly adopts a layered withdrawal mechanism, as shown in the table below:

I divided the withdrawal amounts into four levels. The first level is for small withdrawals, which can be signed directly by the backend Signer. However, to ensure the security of the backend Signer's private key, I plan to integrate Fireblocks' MPC wallet to avoid the Signer coming into contact with the private key while also enabling automation.

The second level also requires a signature from the backend Signer but adds a 1-hour time lock. During this 1-hour period, if the Guardian in the contract detects any issues with the withdrawal, they can cancel the withdrawal request on-chain. If there are no issues, the withdrawal can be executed after 1 hour.

The third and fourth levels will add an on-chain multi-signature review process. Three multi-signature review addresses will be configured on the contract, and for large withdrawal requests, at least two signatures from the three reviewers are required for approval.

Each specific threshold within these levels should be configurable, and the time lock should also be configurable.

The complete withdrawal routing is roughly as follows:

Fund Rebalancing Mechanism

To ensure that the target chain has sufficient balance when users withdraw, I designed a fund rebalancing mechanism.

For each chain, target balances are allocated based on historical withdrawal proportions, as illustrated below:

A scheduled task can be set up, for example, to check the asset amounts on each chain's contract every hour. If it detects that the balance on a certain chain is below a safety line, it will supplement the target balance from a surplus chain. For instance, if the rebalancing task finds that the balance on Arbitrum is only 40K, while there is 100K on the Base chain, it will transfer 60K of USDC from the Base chain to Arbitrum. After the transfer, the Base chain will still have 40K, which is above the safety line.

Additionally, if a user attempts to withdraw and finds that the contract balance is insufficient, this will also trigger a rebalancing, transferring assets from a surplus chain to the current chain.

For the cross-chain solution, I chose Circle CCTP, which is the most suitable cross-chain solution for USDC.

Summary

The above outlines some of my core design thoughts on the deposit and withdrawal module. I will continue to share the designs and progress of other modules, and I welcome everyone to follow along.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。