分散型取引所（DEX）

What This Guide Will Cover

This guide is for those looking to launch their own decentralized exchange (DEX). By the end of reading this guide, you will have a better understanding of the most common DEX models that exist today and the strategies for successfully positioning your offering. You will learn about various design and technical considerations to guide you if you plan to build the solution yourself, as well as options available if you prefer to buy or fork an existing solution.

Intro to Decentralized Exchanges

Decentralized Finance (DeFi) has demonstrated that financial markets, similar to those in traditional Web2 environments, can operate in a decentralized and trustless manner. The primary example of DeFi is a Decentralized Exchange, or DEX, which facilitates transparent financial transactions (trades) directly on the blockchain via smart contracts. DEXs contain multiple components, such as a backend (smart contracts) and frontend interface (for users to interact with the DEX smart contracts easily), and APIs, allowing developers to integrate DEX functionality into their own applications or dApps such as wallets and other Web3 protocols.

DEX Models

Decentralized Exchanges (DEXs) have become the cornerstone of financial activity on blockchains. The three most common DEXs in use today are:

• Order Book DEXs

• Automated Market Makers (AMMs)

• Aggregated DEX Providers

Note that there are other types of financial instruments deployed on the blockchain such as derivatives (options, synthetics, etc.) but this won’t be in the scope of this guide.

To better understand these DEX models, let’s go a step further in detail.

Order Book DEXs

Order book DEXs utilize a traditional order book method to facilitate trades. In this model, a majority of the liquidity provided to the exchange is via market makers, who place limit orders on the order book. In the context of Web3, market makers are most commonly bots that run on specific strategies given market conditions. When one of their orders is filled by another user, they receive a percentage rebate of the order size being filled. Users can view the order book to see the current supply and demand and then place customizable orders (e.g., market, limit, bracket) that will be filled based on the order book at that current time.

Some protocols that implement the order book model model today include dYdX and Raydium.

Automated Market Makers (AMMs)

AMMs are smart contracts deployed on-chain that utilize a liquidity pool architecture to automatically facilitate trades between tokens using an algorithm. Unlike a traditional order book model, AMMs determine prices with mathematical formulas. For example, Uniswap, an AMM on Ethereum uses a simple but highly effective formula called the constant product formula (x * y = k) to determine the price of a token given the quantities of each respective token in a liquidity pool.

Users provide liquidity to a given pool (e.g., ETH/USDC) and when a trade occurs, there is a swap fee taken from the total value of the trade. This fee is then distributed to all liquidity providers in that respective pool, based on the share of the pool each liquidity provider holds. The earned fee can vary depending on the liquidity pool, and the amount being traded.

Popular Web3 protocols that implement the AMM model include Uniswap, Curve.finance, and Balancer.

Aggregated DEX Providers

These protocols aggregate liquidity from multiple DEXs to try and find the best rate for users. This includes scanning prices on different DEXs, optimizing how many tokens to swap on each exchange to minimize slippage (i.e., the quoted price of a trade vs. the actual executed price), and finding the optimal swap rate.

Notable protocols that implement the aggregator model include Paraswap, Matcha, and 1inch.

Hybrid DEXs

Hybrid DEXs combine Web2 and Web3 methods to try and provide a better experience for the end-user. Typically, they will use an off-chain order system to increase efficiency when matching orders and an on-chain system to settle the swaps.

One DEX of note that implements a hybrid model is Vertex.

Why Launch a DEX?

Launching a DEX can come with many opportunities, such as revenue, but also help add value to users who want to conduct financial transactions on-chain. Let’s explore some key reasons why you may want to build a DEX:

Revenue Opportunities

DEXs can generate revenue in several ways such as transaction fees and partnerships. For example, Uniswap charges a fee to users who conduct swaps via their front-end interface. Another opportunity for DEXs to generate revenue is via partnerships such as launching on a new blockchain so that users can swap tokens and are comfortable doing so on a reputable DEX. Here is a list of revenue opportunities you can explore when planning your DEX:

1. Protocol Fees: This is the most common way of earning revenue on your DEX. You can take a percentage of a trade.

2. Integrations / Partnerships: Charge for integrations with other Web3 protocols like blockchains, wallets, and more.

3. Premium Services: Offer supplemental products to help users interact on your DEX. This can be in the form of a REST API (to allow for easier interactions for more traditional developers not familiar with blockchain).

It’s important to note that revenue models can vary depending on the strategy you implement when building your DEX. You will most likely need to adapt to the different methods as Web3 evolves. The goal should be to generate sustainable revenue to continue developing features and keeping users happy while also maintaining competitiveness.

Low Cost of Ownership

Traditional financial systems can incur a lot of maintenance and infrastructure costs to keep backend systems running (e.g., trade operations, settlement, etc). Whereas since DEXs are built on-chain, the majority of the work needed to maintain these systems is built when creating the smart contracts, therefore reducing the time and cost needed to maintain and test in the future.

Build for the Future of DeFi

DEXs are meant to embody the ethos of Web3: decentralization, transparency, and user control. By building a DEX, you contribute to a more open and accessible financial system that is free of intermediaries. For example, DEXs solve a lot of the common problems users experience with Web2 financial instruments, such as:

Strategies for Building a DEX

Niche Markets

If there is a specific community or market with unique needs that are not currently met by existing DEXs, such as collectibles or specialized financial instruments. A custom DEX can cater specifically to these requirements. There are also opportunities in being the first DEX to a new blockchain, providing a first-mover advantage as users will initially have no other options but to trade on your platform, rather than swapping on another blockchain and bridging tokens.

Innovative Trading Mechanisms

Introduce new innovative trading mechanisms not available in current DEXs. For example, at the time of Uniswap V2, there was no concept of concentrated liquidity. Now with Uniswap V3, liquidity providers are up to 4000x more capital efficient (relative to Uniswap v2), resulting in higher revenue share on their capital. We have seen other DEXs such as Balancer modify the Uniswap code to be more flexible, allowing for more than 2 assets to be traded within the same pool.

Enhanced User Experience

Creating a DEX with a focus on user experience can set your DEX apart from others. This could be supporting multiple platforms like Web, Mobile, Tablet, or catering to additional features like integrating your DEX within a wallet or supplemental features like integrated tax reporting and advanced trading tools (e.g., charts, portfolio analysis, etc.). A DEX that prioritizes user experience can attract and retain users by making trading easier, more efficient, and more user-friendly.

Design Considerations

Trust & Security

Ensure that your DEX is open-source and audited by a reputable security firm to prevent vulnerabilities and exploits. This is both on a backend level (smart contracts) and through your user interface (front-end). Additionally, take advantage of bug bounties and let developers in the ecosystem help strengthen your codebase. Emphasize decentralization to align with the ethos of Web3. This can reduce single points of failure and enhance trust between you and your users. For example, Uniswap has the UNI token, which holders can use to vote on how the DEX should operate. Provide documentation and educational resources for your users, helping support best practices and safe interaction with your DEX platform. Ensure your content is accurate and up-to-date with your DEX's latest changes.

Frontend Design

An efficient front end is crucial for ensuring a good user experience on your DEX. Prioritize a user interface that minimizes load times and keeps DEX information up to date. This can entail caching information that is accessed frequently (e.g., token lists) and implementing proper load balancing and RPC management to distribute traffic evenly across your usage.

Fee Structure

Assess how users providing liquidity to your DEX will earn revenue and compare this to other DEXs that may be competitors. Gather user feedback to understand user preferences and make decisions based on this feedback (along with your internal analysis). You may also want to consider a promotion to encourage users to deposit liquidity on your DEX. For example, it is common for DEXs to provide farming rewards for a set time. This will be dependent on whether your DEX has its own token, but other alternatives are available, such as partnering with another Web3 project that may want to grow the liquidity of its token and can do so via your DEX.

Regulatory Compliance

Look up relevant local regulatory requirements for jurisdictions you plan on operating in. Implement necessary compliance measures, such as KYC protocols, and ensure user data privacy and security in accordance with regulations. Regularly review and update compliance practices to adapt to regulatory changes.

Technical Considerations

Blockchain Compatibility

Ensure that your DEX can operate across different blockchain networks to maximize user reach and facilitate cross-chain transactions. Deploying on an EVM-compatible blockchain means that you will have less friction when trying to deploy on another EVM chain (e.g., Ethereum → Optimism) but you will want systems/checklists in place to ensure you deploy the same smart contracts, and access control as you did on your initial chain.

相互運用性

Make sure your smart contracts align with the latest token standards and EIPs to ensure compatibility with other dApps in the ecosystem. Additionally, more and more users want to use multi-sig wallets. Ensuring they are compatible with your platform allows larger entities and security-conscious users to use your platform without worry.

API Integrations

Develop RESTful APIs to allow developers to easily interact with your DEX programmatically. These APIs can provide endpoints for querying token prices, fetching order book data, retrieving trade history, and executing trades. This will also simplify integration for developers and encourage the creation of third-party tools and services built on top of your DEX.

Contract Upgradeability

Given the fast-paced evolution of blockchain and the continued advancement of technology, you may require further enhancements to your DEX design (e.g., security, new features, better design), and you will want to consider the different methods of contract upgradeability. While contract upgradeability offers easier upgradeability and less friction for your users, it can introduce new bugs. On the other hand, deploying new smart contracts when you have a new version ensures a clean slate and provides stronger security guarantees for users, as the contract cannot be altered once deployed, though it can cause challenges and friction when asking your users to migrate to your latest version.

Build vs Fork

When designing your DEX, it’s important to identify your niche and target market, and then make decisions based on that. For example, if you are targeting casual traders, a user-friendly interface will take precedence over more complicated features such as advanced order types.

Example Scenario: You are launching a new blockchain that currently has no other DEXs or native exchange. Your target market is the early users of the blockchain who are likely tech-savvy and care about simplicity. In this case, it’s probably better to worry about user interface and functionality, than try to cater to advanced orders. Therefore a DEX model like Uniswap may be more appropriate for this scenario.

Key Points to Consider

Who Is Your Target User Base?

• Who are you catering to? Newbies, professional traders, or another niche category

• What are their needs and expectations?

• How will your decision on the DEX model affect your size of user base and growth?

Time to Market

• Building a DEX from scratch requires a lot of code creation and testing but it comes with the advantages of custom features that may not be available elsewhere.

• Forking an existing DEX minimizes the time to market with code that’s already tested in production (and less likely to contain bugs)

Customization Needs

• Do you plan to offer features not available elsewhere? If so, a build approach may better fit your needs.

• Can you achieve your DEX goals by forking an existing solution? It still may be possible to fork an existing solution and customize/add to it, but this requires understanding the code base on a low level so you don’t introduce any new bugs.

Maintenance & Updates

Building your own DEX smart contracts means you are responsible for maintaining and updating them as the ecosystem evolves. On the other hand, relying on widely-used contracts often means benefiting from collective maintenance and updates, ensuring compatibility with new blockchain features and standards.

DEXs Available for Forking

Whether or not you plan to fork an existing DEX, reviewing those on the market will offer a strong point of reference as you get started. Note that DEXs designed for the Ethereum Virtual Machine could leverage a service like Neon, enabling support for chains compatible with the Solana Virtual Machine.