OKExChain mainnet launching in January as EVM smart contract deployment reaches completion
What is OKExChain?
An in-depth look at the decentralized blockchain protocol created by OKEx
Table of Contents
- OKExChain's operation process and its role in the ecosystem
- OKExChain and OpenDEX
- Conclusion — OKExChain summary
OKExChain is open-source, public blockchain technology developed by OKEx for building blockchain-based trading applications. It is designed to establish a safe and efficient decentralized-finance architecture that can be used to create a decentralized exchange, or DEX, that features community-based operations, transparent trading rules and allows the users to control their own assets.
We know that, in the blockchain world, cross-chain technology is a key link in realizing interaction between assets and data, and is the technological base for DeFi. As the name implies, cross-chain means the realization of asset transfer, information exchange and application collaboration between different blockchain platforms. Acting much like a bridge that connects different public chains, cross-chain technology helps realize data transmission between different blockchain networks while, at the same time, greatly reducing the transmission costs. It is simple and effective to use the cross-chain module to achieve value, user and scenario application-based interconnection among blockchains — which lays the foundation for jointly building a shared ecosystem and value-added system.
Considering the above, the team used Cosmos SDK and Tendermint to construct OKExChain. Cosmos introduces an Inter-Blockchain Communication, or IBC, protocol that — together with the Tendermint consensus algorithm, featuring instant finality — can be used to realize value transmission between blockchains. In the future, we will be able to use Cosmos to solve issues regarding the multi-directional circulation of value by adding support for heterogeneous cross-chaining.
Cosmos is a network composed of many independent and parallel blockchains that are inter-connected by nodes.
Within Cosmos, all consensus layers adopt Tendermint, a consensus engine that supports Byzantine-fault tolerance and boasts high efficiency, high performance, consistency and other characteristics.
Cosmos network is mainly composed of two parts:
Each Zone and Hub is an independent blockchain with independent state consensus. Zones are used to solve specific application needs, and Hubs are designed specifically to handle cross-chain transactions between Zones — much like a central bank handling the settlement between banks. Cross-chain value transfer is achieved by realizing intercommunication and interoperation between different Zones and their shared Hub, which are based on the IBC protocol for cross-chain communication.
It’s the aim of Cosmos to realize simplified blockchain development and achieve interconnection between blockchains. The key to the former lies in the Tendermint consensus algorithm, while that to the latter lies in its cross-chain mechanism.
Tendermint contains two main technical components:
- Tendermint Core, which is the blockchain consensus engine.
- ABCI, which is the general API.
Tendermint Core is used to realize Byzantine consensus and the data transmission between nodes. By using the consensus algorithm combining Byzantine-fault tolerance and delegated proof of stake, it can achieve ultimate finality in block generation — which means that the transaction has been written into the block, added to the blockchain and cannot be reversed or tampered with thereafter — ensure that each node records the same transaction in the same order and pave the way for extremely fast transaction confirmations and high throughput. In general, Tendermint Core is mainly used to construct the network layer and consensus layer of the blockchain in a way that allows the developer to personalize the blockchain without worrying about the realization of consensus and network transmission.
ABCI is a blockchain API and a protocol that supports the implementation of transaction processing in any programming language. For developers, the only thing they need to do when conducting blockchain development based on the Cosmos framework is to write applications that are compatible with the ABCI interface.
In order to further reduce the complexity of blockchain development on top of Tendermint Core and ABCI, Cosmos has introduced the Cosmos SDK, a tool that is based on the standardization of some common blockchain modules. Cosmos SDK can be deemed a "chain-making tool" of Cosmos, as it makes blockchain design within the network as simple as adding modules — such as governance, staking and pledge — which, coupled with the innate interoperability between blockchains created with it, serves to greatly reduce the complexity of blockchain project development.
Depending on whether the related blockchains are based on different technology platforms, the cross-chain mechanism can be either homogeneous cross-chain or heterogeneous cross-chain. The former refers to the interaction between blockchains with the same underlying structure in terms of the encryption algorithm, address, account algorithm rules, etc. One example is trading Ethereum-based tokens. Although we have seen relatively mature applications of a homogeneous cross-chain in many projects, it remains powerless in solving issues preventing the interaction between mainstream assets — such as Bitcoin (BTC), Ether (ETH) and Tether (USDT) — with the greatest consensus.
Homogeneous cross-chain, which realizes value locking and value exchange between blockchains with different chain structures, provides the answer to the problem of multi-directional circulation of value. Cosmos, which adopts a relay-based multi-chain and multi-layer architecture, will support cross-chain asset interaction.
In order to support cross-chain interoperation between parallel chains, Cosmos introduces the Inter-Blockchain Communication protocol and the Tendermint consensus algorithm — featuring instant ultimate finality — to realize value and data transmission between multiple heterogeneous chains. All parallel chains are connected to the Hub through IBC, and the Hub acts as the relay chain to assist the verification and transfer of cross-chain transactions.
Specifically, the Hub helps each Zone synchronously record the status of each other Zone — and the object of this function is the block headers of other Zones. When Zone 1 sends a cross-chain message to Zone 2, all of its information is packed into a data packet that is stored in its block header. The Hub waits for Zone 1 to reach a consensus regarding the block containing the information and then transfers the information stored in the block header of Zone 1 to a new block. After the Hub completes the block consensus, Zone 2 will receive the verification message broadcasted by the Hub, which involves the block header of Zone 1. After that, Zone 2 must verify whether the proof regarding Zone 1 is true. If it is true, Zone 2 will start to perform related operations and send feedback to the Hub about the related block.
Let's use the transfer of 10 OKTs from OKExChain to Cosmos as an example to illustrate cross-chain interaction based on IBC:
- 1. To perform cross-chain transactions between OKExChain and Cosmos, chains at both ends need to run each other's light blockchain node services.
- a. In this way, the block header information of the other party can be received in real time, which is convenient for subsequent execution of Simple Payment Verification-like confirmation, in which SPV nodes verify the existence of the transaction by requesting proof of the Merkle path and verifying the proof of work in the blockchain.
- 2. The OKExChain chain initializes the IBC protocol and freezes the related assets — 10 OKTs, in this example — after which it generates the corresponding proof and sends it to the Cosmos Hub blockchain.
- 3. After receiving the corresponding message, the Cosmos Hub chain confirms that OKExChain has indeed frozen the corresponding assets by checking the block header information of the OKExChain chain before generating an asset of equivalent value — again, 10 OKTs, in our example.
- 4. The 10 OKTs are transferred from OKExChain to Cosmos.
OKT is the native token issued on the main network of OKExChain. All tokens contained in the OKExChain genesis block are allocated to OKB holders in proportion to their OKB holdings. OKT is the carrier of value for the OKExChain ecosystem, and its value determines the development prospects of DEX, DeFi and other applications on OKExChain.
OKT adopts the issuing mechanism of genesis block + annual additional issuance, with the former generating a total of 10 million tokens and the latter set at the ratio of 1:100, and all additional tokens issued every year will be distributed equally among all blocks according to the corresponding proportions.
Use of system resources
A program running on the OKExChain network requires OKExChain to allocate certain network resources — such as computation, storage, bandwidth, etc. — according to its operational needs.
As such, OKExChain adopts the Ethereum model of charging according to resource usage — that is, a corresponding transaction fee must be paid for the execution of the relevant transaction. The specific pricing method is as follows: the cost of executing a transaction = "ceil" (Gas x Gas Price), where Gas Price is the consideration the operator is willing to pay for each Gas, which is priced in OKT.
In order to avoid malicious behaviors, it's required to pledge a certain amount of OKT before applying for a node to become a validator/proxy node, submitting a chain governance proposal or executing an order pending operation.
Users who hold a certain amount of OKT can issue new tokens on the OKExChain network, which can be freely traded on OpenDEX once the relevant proposal application and activation are completed through digital asset trading pairs. Each of the relevant operations — token issuance and activation, additional issuance and destruction of digital asset trading pairs — would incur a corresponding handling fee that needs to be paid.
Each block only has a limited capacity and, as the volume of pending orders on OpenDEX continues to rise, the number of transactions that need to be processed by the block in a single cycle may exceed the carrying capacity of the block, resulting in the system being unable to distinguish junk token pairs from those with values. In this case, how does OpenDEX select the transactions to be processed by the block?
Match-making security is introduced to solve this problem, which means that an operator can deposit any amount of, or 0, OKT as a security for each trading pair it operates. The match-making system will give priority to trading pairs with higher securities or, if the securities are the same, select transactions according to the chronological order of submission.
The above-mentioned solution, which is based on dynamic bidding auctions, may expand OKT's usage scenarios while also quantifying the strength of DEX operators. Suppose that the match-making capacity of each block is limited to 100 transactions, but 200 transactions are generated in a certain block generation cycle — 100 of which belong to transaction pair A and the other 100 to transaction pair B — 100 of those transactions cannot be placed in this block for processing for the duration of this cycle. In such a case, if the security provided for A is greater than that for B, the match-making system will give priority to the 100 transactions in trading pair A and, if the securities provided for both trading pairs are of the same amount, the match-making system will give priority to the first 100 transactions ranked by the chronological order of their submission.
For token holders, voting is the most important way of participating in validator elections and on-chain governance. Holders obtain voting rights by pledging their tokens, with 1 OKT corresponding to one vote that may be used in an election with up to 30 nodes.
During the block-production process, the validators are elected by calculating their voting weights — which are determined by the vote of holders or their proxies.
In on-chain governance, decisions on proposals are also made by validators through voting.
OKExChain adopts the consensus algorithm of Tendermint (BFT-DPOS), and there are six basic steps to create a block:
- Become a full node.
- Register as a candidate node.
- Vote to elect a validator.
- Select a block generation node.
- Make a proposal.
- Generate a new block after reaching Tendermint consensus.
Before becoming a block producer, a token holder needs to first become a full node in the distributed blockchain network by running a node client. To participate in the validator election, a full node needs to register as a candidate after pledging a certain number of tokens for the purpose. The nodes ranked in the top 21 in the election become the validators in the next cycle. After the election, the system will calculate the corresponding voting weights based on the votes obtained by the 21 nodes and select the block generation nodes from them by running a random algorithm with such weights. These selected nodes will then produce blocks according to the Tendermint consensus protocol.
Block generation based on the Tendermint consensus mechanism requires two stages of voting:
A selected block producer will monitor and collect all transactions in the entire network, then assemble a new block (i.e., the proposal block) within a certain period of time and broadcast it to the entire network.
After receiving the broadcast about the proposal block, all validators will read all transactions in the block and verify them. If there is no problem, a pre-vote message will be broadcast to all validators. The second stage (pre-commit) will commence if votes approving the proposal block account for more than two-thirds of all votes received. If pre-commit votes approving the proposal block account for more than two-thirds of all votes received, the proposal block will be written to the local blockchain and the new block is created with ultimate finality.
After a new block is generated, the system will enter the next round of block generation.
If a current proposal block goes offline, due to poor connection and other reasons, the block producer may fail to submit a block — in which case, the protocol will choose the next validator to become the block producer and propose a new block at the same height and restart the voting process.
Additionally, Tendermint introduces a locking mechanism — which means that, once a validator pre-commits a block, it is "locked" to that block and it must also pre-vote for that block. Only if a block is not successfully submitted in the previous round of pre-proposal and pre-vote can the corresponding validator be unlocked from it and participate in the next round of pre-commit for a new block. Assuming that less than one-third of validators are Byzantine nodes, Tendermint guarantees that validators will never repeatedly submit blocks at the same height, which may lead to conflicts.
For token holders, voting is the most important way of participating in validator elections and on-chain governance.
A validator election is determined by votes from token holders or proxy nodes, and each voter can vote for up to 30 nodes. All nodes that receive a vote are sorted by voting weight from highest to lowest, and the top 21 nodes will be selected by the system to become validators. The remaining nodes will become standby (candidate) nodes. The validator election is a periodic event, meaning a new election will take place at the beginning of a new cycle.
If token holders or proxy nodes didn't participate in the voting for on-chain governance, validators they've chosen can directly inherit their voting rights and vote on relevant proposals — but the token holders or proxy nodes still have the right to change the votes afterward.
The voting weight coefficient is calculated by dividing the difference from the starting time to voting time by the total number of seconds in 364 days, which will increase with the increase in said difference.
The voting weight is the pledge amount multiplied by the Xth power of 2 and the "X" equals the weight coefficient.
We can see that the voting weight coefficient increases when the deposit security increases as well as when the difference from starting time to voting time decreases. To a certain extent, users are encouraged by said calculation method to provide larger deposits and continue to participate in voting.
- In the formula, "Weight" is the voting weight coefficient, which changes with time (i.e., the greater the difference from starting time to voting time, the greater the weight coefficient).
- now_timestamp is the timestamp for the current vote.
- start_timestamp is the starting timestamp, which is 946684800 (00:00:00 UTC on Jan. 1, 2000).
- seconds_per_day is the number of seconds per day — i.e., 60*60*24.
- weeks_per_year is the number of weeks per year — i.e., 52.
- "Shares" is the calculated voting weight.
- delegated_Tokens is the amount of pledged OKT.
The validator election is decided by the voting of OKT holders, who can either vote directly or by proxy. To register as a voting proxy, users need to deposit a certain number of OKTs in their pledge account. If a proxy chooses to withdraw from the locked voting, it can't withdraw the pledged token until the 14-day lock-up period expires.
In terms of fund security, because the user does not need to hand over any key and the proxy account only obtains the voting rights with respect to the token, the whole delegation is an on-chain process that has no effect on the actual ownership of the token — which still remains in the user's personal address. However, when users change the number of tokens pledged for the proxy, all their voting weights will also be updated accordingly.
In view of the fact that rewards and punishments of a validator will also affect any proxy who voted for it, proxies should use browsers on OKLink or other OKExChain blocks to learn about validators and conduct detailed investigations and screenings before voting. After voting, the proxy also needs to continuously observe the operation of the validator to ensure that it acts correctly — such as ensuring uptime, not double signing or becoming compromised, and participating in governance. If there is any warning sign, the proxy can quickly unbind the vote or switch the vote to another validator with immediate effect.
OKExChain relies on a set of validators to maintain network security, each of which is a full node that participates in the consensus through voting by broadcast. To become a validator, the node must meet certain requirements proposed by the system, including a security deposit in tokens, as well as meet the requirements for hardware and software configurations.
The following is a list of the validators’ responsibilities:
- Validators must avoid double signatures. Once a double signature is found in the test network, an automatic penalty will be executed immediately.
- Validators must be able to continuously run the correct version of the software. Proposers need to ensure that their servers are always online and their private keys are not compromised.
- Validators must keep their node versions actively updated to increase security.
- Validators must keep an eye on hardware requirements when the system is updated and keep hardware updated to meet the requirements.
- Validators must protect against DDoS attacks when they occur.
- Validators must actively participate in governance. Proposers are required to vote on each proposal.
To become a validator, the node must be connected to the OKExChain network and have a security deposit of 10,000 OKTs.
OKExChain's minimum system requirements are:
- Desktop or laptop hardware running recent versions of MacOS, Windows or Linux.
- 500 GB of free disk space, accessible at a minimum read/write speed of 100 MB/s.
- Four cores of CPU and 8 gigabytes of memory (RAM).
- A broadband internet connection with upload/download speeds of at least 1 megabyte per second.
As you can see, at the beginning of the project, the node configuration requirements seem average at best — but, over time, the hardware requirements will be elevated with the increase in network usage. Compared with other blockchains, such as Ethereum or Bitcoin, the OKExChain network has much higher throughput and, thus, requires higher bandwidth to maintain smooth communication between various nodes. Additionally, as the size of the block data will increase and the block-generation node needs to have enough hard-disk capacity to store complete block data, there is also the need to expand the hard-disk capacity of a node whenever necessary.
The currently available servers are mainly divided into two types:
- Self-built server: A server that is purchased, assembled and connected to a relevant network by oneself. This type of server entails relatively high upfront costs, including hardware costs, site costs and operating costs, and also high-impact requirements (around-the-clock power supply and network connection). The advantage of a self-built server is that it allows direct adjustments to certain service supports.
- Cloud server: A ready-made cloud server that runs related services through it after completing corresponding dynamic parameter configuration. The advantages of cloud servers include flexibility and low cost. At present, most of the existing nodes use cloud servers — such as Amazon's AWS, Google's cloud services, Alibaba Cloud, etc. — due to the aforesaid advantages. All you need to do after purchasing a cloud service is to configure it in accordance with the official tutorial. Of course, this node configuration method has long been criticized in the decentralization community because it means handing over control of the node services of the decentralized networks to the centralized IT giants providing said services.
The validator server's data center should be equipped with redundant power supplies, connectivity and storage backup facilities. Other than several redundant network boxes for fiber optic connection, firewall operations and switching, validators are also expected to have small servers with redundant hard drives and failover functions. The relevant hardware can be placed at the bottom of the data center.
It is best for OKExChain nodes to have complete monitoring, warning and management solutions against attacks and interruptions so that they can maintain the security and isolation of their data centers and thereby avoid accidental unbinding or events that trigger system punishments.
The economic-incentive mechanism designed for bookkeeping nodes is an indispensable and important part of any blockchain project. The rewards for BTC accounting nodes (miners) include block-generation rewards and transaction fees. Since OKTs generated by the OKExChain genesis block are distributed to OKB investors in a 1:1 ratio, where do the rewards for miners come from?
Such rewards mainly come from two sources:
- The first source is the 1% annual additional issuance by the system (which will be proportionally distributed to each block), 25% of which will be deemed as generation rewards and distributed among 21 validators according to their voting weights.
- The remaining 75% will be distributed to all candidate nodes according to the voting ratio. This method helps to avoid inaction of generation nodes, because they can still get voting rewards by acting as the candidate nodes after failing to obtain block generation rewards.
Another source is the handling fee, which is allocated only to 21 validators, according to their voting weights. There are two types of handling fees — namely, the system handling fee and business handling fee. The former is the gas fee and the latter includes handling fees incurred from the issuing of token–currency pairs by operators, activation of digital asset transaction pairs and additional issuances, among other things.
The token security provided by the node can also be regarded as a security deposit for verification activities. A node may lose the qualification to produce blocks if it is inactive or has any improper or malicious action during block production, whether advertently or inadvertently, due to attacks.
The specific penalty rules are as follows:
- Not participating in the block's verification signature will result in a ban for 10 minutes — that is, the node cannot participate in block generation in the next 10 minutes.
- Double signing — that is, signing two blocks of different chains at the same height — will result in the node being permanently disqualified for block production.
In addition to creating new blocks, validators must also participate in on-chain governance.
If the creation of new blocks is to ensure the continuity of the blockchain, on-chain governance determines the parameter settings of the entire system — which, in turn, determines the developmental direction of the entire network.
OKExChain's on-chain governance mainly involves four aspects:
- Brainstorming on a given topic.
- Changing system parameters.
- Deleting trading pairs in DEX.
- Supporting network upgrades.
To prevent meaningless and malicious proposals, each governance proposal must be accompanied by a security deposit of at least 100 OKTs, and the amount of the deposit determines the weight of the proposal. Each proposal meeting the aforementioned requirements will enter a two-week voting period. At the end of the voting period, the proposal is passed if affirmative votes, excluding abstentions, account for 50% of total votes and negative votes, excluding abstentions, account for less than 33.33% of total votes.
OpenDEX is an open, decentralized exchange based on the OKExChain ecosystem.
Before introducing OpenDEX, we need to understand the characteristics of centralized and decentralized exchanges and their respective advantages and shortcomings.
Trading is the most important function of any exchange, and the advantage of a centralized exchange is that it has good liquidity and makes it very convenient to deposit and withdraw in legal currency — but it requires placing tokens in its custody, which is an obvious shortcoming because it entails huge risk. There is an old saying in the blockchain world: "Not your keys. Not your coins."
Pain points for centralized exchanges
The risk of information leakage
Centralized exchanges require users to provide detailed personal information, which is a tedious process. Moreover, this information and users' transaction data stored on the servers are controlled by centralized exchanges. Users currently have no way of knowing how and when this information and data is used.
There are many problems with current identity systems. Users' identity data is scattered on the servers of different service providers. In the absence of unified management, users need to provide a username and password each time they use a website service and are forced to use different usernames and passwords on different websites, since failure to do so may lead to serious security risks.
The risk of misappropriation of funds
As users’ tokens are stored on the servers of centralized exchanges, and user assets are managed by them, there is no way to rule out the possibility of such exchanges misappropriating user assets or tampering with user information.
The risk of theft
All DEXs must face security risks, and more money means greater motivation for hackers to attack — which leads to more attack schemes. If the wallet of a centralized exchange is hacked, all tokens in the wallet will be lost.
In the past 10 years, there have been more than 30 incidents of funds being stolen from centralized exchanges, such as Coincheck and now-defunct Mt. Gox. Until now, there has not been any significant improvements on this front as, every day, countless hackers are still working hard to find vulnerabilities in the centralized systems.
The risk of network crash
Network crashes refer to situations in which services cannot be used due to various reasons, such as server crashes, deactivations, shutdowns, etc. During network downtime, users cannot carry out normal transactions, which often leads to time and money losses to users or service providers.
Transaction pair needs to be reviewed before being published
All transaction pairs must be reviewed before being published on a centralized exchange. To trade different tokens, users often need to register on multiple exchanges. As a result, the identity data is scattered across different service providers, and repeated logins are required for use of website services. Other than BTC and ETH, each token usually has only one or two trading pairs with assets of high market value. Therefore, even if the same exchange supports the two tokens required for the transaction, we may still fail to find a currency pair directly corresponding to the transaction when trading two digital assets with a lower market value. As a result, the transaction process will become much more complicated.
Users' funds used for trading in decentralized exchanges are stored in their wallet addresses or smart contracts, giving them total control over such funds. When a transaction is initiated, the exchange executes a smart contract to complete the transaction and relevant asset transfer is performed on the chain.
Transaction records are stored on-chain, making them open and transparent. However, due to scalability limitations of the underlying public chain and the transaction attributes of assets, many people still prefer the higher liquidity of centralized exchanges over the desire to control private keys.
Advantages of decentralized exchanges
Lower security risk
Decentralized exchanges adopt a simpler model, which mainly involves match-making transactions. A decentralized exchange doesn't take custody of users’ assets, and their funds are stored in their wallet addresses or smart contracts, giving them total control over such funds and ruling out any possibility of misappropriation. By using code rules to ensure the safety of users' funds, the business model of decentralized exchanges eliminates the risks of hacker attacks and unethical acts from service providers.
Only one public key is required to trade on a DEX. At the same time, some DEX creators claim that they are not responsible for how the community uses the open-source software they released, which helps avoid KYC and AML issues.
As DEX is built on the underlying public chain, which uses distributed node accounting, its overall efficiency won't be affected by any single point of failure — which entails exponentially higher security and the elimination of downtime risk.
Pain points for decentralized exchanges
Public chain's security risks
The decentralized exchange is built on the underlying public chain, which makes it vulnerable to security risks of the public chain. If information on the public chain can be tampered with, the transaction information of the decentralized exchange will become untrustworthy, and there will be no security assurance for user assets.
Liquidity is an important indicator for all exchanges. Higher liquidity means it is easier to conduct transactions on the exchange. Many decentralized exchanges suffer from significant trading slippage — i.e., the difference between the price where an order is placed and the price where the last transaction is made — caused by poor liquidity.
At present, EtherDelta, 0x Project and other well-known decentralized exchanges in the market are all built on public chains such as Ethereum or EOS, and objective conditions such as small user bases and insufficient transaction depth have become serious issues that hinder their development.
It can be seen that centralized and decentralized exchanges have their own pros and cons — and the current target groups of the two are different.
Exchanges are essentially places for completing transactions. The vast majority of users tend to choose centralized exchanges because they offer better user experiences, thanks to higher liquidity as well as more convenient deposits and withdrawals. Additionally, the financial strength of mainstream exchanges and their outstanding performance in multiple crises make them more trustworthy in the eyes of many users.
Of course, there are still some groups who value the security and anonymity of funds more than transaction convenience. For these groups, decentralized exchanges are clearly the better choice.
OKExChain was introduced specifically to meet the needs of these niche groups because OKEx can satisfy the needs of most users who value transaction convenience. Based on different technical forms, the two complement each other and jointly achieve wider user coverage and better user experience by playing to their respective advantages.
As a DeFi project of the OKExChain ecosystem, OpenDEX provides OKExChain users with services that ensure safe and stable digital asset trading. The OKExChain mainnet forms the underlying support structure for the decentralized exchange and OpenDEX serves the purpose of making it easy to release DEXs. Just like Ethereum makes it easy to issue digital assets through smart-contract technology, OKExChain has provided various basic functions required to operate DEXs, making it easy for everyone to create a DEX.
Unlike traditional DEXs, OpenDEX completely transfers the match-making engine and order book to the chains — which improves the transparency and security of related information. Its match-making system, based on the collective bidding model, helps improve transaction fairness by weakening the influence of the transaction ranking in the block on the final match-making result. Compared with projects based on Ethereum, OKExChain's collective-bidding-based match-making system can complete matching operations in a tighter time window.
OpenDEX adopts the on-chain order book model, which is a completely blockchain-based DEX architecture that ensures every order and status change will be recorded as a transaction on the blockchain network. All outstanding orders will be recorded in a collective order list on the blockchain, and whether each of such orders is executed or not depends on the transaction strategy agreed by the buyer and seller upon the creation of the transaction. When matching assets on buy and sell orders, transactions of assets of different types can be completed by direct trading through listings.
According to the OpenDEX technical solution, all deposits, withdrawals, order placements and settlements are completed by smart contracts. The basic process is as follows:
- The maker signs an order with a private key and submits it to the chain, upon which the maker can set a limit on how many blocks an order can go through until it is automatically canceled.
- Subsequently, the taker selects the order to be filled from the order book and generates a corresponding transaction to be signed and then submitted to the on-chain smart contract, which then executes the transaction after verifying relevant order information, such as trader's signature and the effective time of the order.
OpenDEX's match-making system adopts a call auction model. We know that, in a blockchain system, orders are not generated continuously but discreetly, according to the intervals of block generation — so, unlike most centralized exchanges that use continuous bidding algorithms for order selections, DEX performs order match-making periodically according to the intervals of block generation by means of collective bidding.
By applying the call auction model to the level of each block, it is guaranteed that a digital asset trading pair in a block will only have one transaction price, and all orders are executed according to the principle of price-time priority — therefore, greatly weakening the impact of the ranking of transactions in the block on the final match-making result and further ensuring the fairness of transactions.
Security of funds
According to the custody mode, DEXs can be roughly divided into two categories:
- Custodial DEXs
- Self-custodial DEXs
A custodial DEX needs to transfer funds to contracts controlled by others. In order to reduce the risk of foul play, a custodial second-layer DEX uses technologies such as multisignature or threshold signature to achieve decentralized key management by multiple parties.
A self-custodial second-layer DEX has the following characteristics:
- Not allowing any fund transfer without definite user signature.
- Giving the user access to all information (through the user experience design of the wallet) upon signature signing.
- Allowing exits at any time.
- Maintaining the integrity of the operation mechanism, even if the code upgrade rules are being abused.
In view of the characteristics above, self-custodial DEXs can ensure that funds are actually controlled by users, and operators have no means to freeze, or even use, assets belonging to users. OpenDEX adopts the self-custodial operation model, which entails higher security for funds.
Public chain security
OKExChain uses the Tendermint consensus algorithm, which ensures that each new block has ultimate finality.
The "probability finality" of Bitcoin blocks is calculated according to the chain length, meaning that transactions on longer chains are less likely to be tampered with. However, this algorithm cannot completely eliminate the possibility of tampering. The "ultimate finality" refers to a transaction that is deemed finalized immediately after being included into the block and added to the blockchain as well as that, once an agreement is reached, the corresponding block is immediately finalized and the transactions in which can no longer be reversed.
By making use of said features of Tendermint, OpenDEX can achieve high transaction throughput and extremely fast confirmations while avoiding malicious behaviors — such as initiating a double-spend — therefore ensuring the safety of funds as well as providing cross-chain clearing and settlement services.
Unlimited number of trading pairs
To solve the issue of only supporting a limited number of trading pairs, OpenDEX introduces DEX operators that are allowed to issue any token or token-transaction pairs on the network.
Compared to traditional decentralized exchanges, which need to establish all trading pairs, OpenDEX is an open convergent exchange, in which token-trading pairs are operated by DEX operators.
To become a DEX operator in the OKExChain network requires spending a certain amount of OKT. The specific process is as follows:
- You need to first pay the OKTs required for issuing the token and publish the transaction pair.
- After that, you can submit the application proposal and activate the digital asset transaction pair.
After these steps are completed, the newly issued token can be freely traded on the OKExChain network. DEX operators can issue any token and token-trading pair. However, since the system does not allow duplicate trading pairs to exist, DEX operators often need to apply faster than others to obtain the right to operate popular trading pairs.
Exchanges running on order books need market-makers to provide liquidity through order-pending operations. In terms of transactions, traditional decentralized exchanges put too much emphasis on platforms and pay less attention to the operating entity that provides liquidity for transactions. Taking Alibaba as an example, it is the platform that provides services to sellers that are actually providing services to users.
By introducing the role of a DEX operator and adding more incentive mechanisms, OKExChain aims to solve the problem of insufficient liquidity faced by traditional decentralized exchanges.
Deductions and exemptions of handling fees
Users need to pay gas fees and transaction fees when trading on DEX. The gas fee, which is earned by the validator responsible for accounting, must be higher than the minimum amount allowed, and the node will give priority to packaging transactions with higher gas fees. The transaction fee goes to the DEX operator, the charging ratio of which is 1:1,000 of the transaction amount.
Of course, in order to attract more users to use DEX and promote the development of the ecosystem, more permissions to offer deductions and exemptions of handling fees — such as match-making fees for certain currency pairs or gas fees that DEX operators need to pay for certain currency pairs — will be granted in the future.
Compared to the centralized exchanges in the market, OpenDEX hands over the control of funds to users, therefore eliminating the fund-security risks caused by the flaws of centralized management. Additionally, OpenDEX can also provide better anonymity, transparency and censorship-resistance, while also maintaining overall efficiency on any single point of failure (by basing on the public chain that uses distributed-node accounting) and allowing users to submit transaction pairs without limitations.
While there are other DEXs on the market, OpenDEX — which is based on the OKExChain ecosystem cross-chaining capability — allows its users to use any two available cryptocurrencies to conduct cross-chain asset transactions through corresponding cross-chain solutions. Its Tendermint consensus algorithm enables new blocks to have ultimate finality, thereby achieving high transaction throughput and extremely fast confirmations. By introducing the role of DEX operators and corresponding incentive mechanisms, OpenDEX also overcomes the problem of insufficient liquidity faced by traditional decentralized exchanges. In the future, it will give users more benefits by granting more permissions to offer deductions and exemptions of handling fees.
It can be seen that OpenDEX, based on the OKExChain ecosystem, overcomes several major pain points for centralized exchanges and other DEXs on the market.
OKExChain is a set of open-source public chains developed by OKEx for blockchain applications. It is designed to establish a safe and efficient DeFi architecture that can be used to create a decentralized exchange that features community-based operations and transparent trading rules, and allows the users to control their own assets.
The team used Cosmos SDK and Tendermint to construct OKExChain. The Inter-Blockchain Communication protocol, together with Tendermint consensus algorithm featuring instant finality, can be used to realize value transmission between blockchains. In the future, we will be able to use Cosmos to solve issues regarding the multidirectional circulation of value by adding support for heterogeneous cross-chaining.
As an open decentralized exchange based on the OKExChain ecosystem, OpenDEX overcomes not only several major pain points faced by centralized transactions — such as the risks of information leakage, fund embezzlement, theft and network crash, and the limited number of trading pairs — but also the problem of insufficient liquidity faced by other existing DEXs through the introduction of DEX operators.
Author: Zhang Xiuxiu
Instructors: Fan Haiyang, Xu Qian, Meng Xiangjian
- OKExChain GitHub
- Introduction and Practical Analysis of Tendermint
- OKEx Research Report: Staking Economy, a New Mining Ecosystem Based on PoS Consensus (Chinese language)
- Analysis and Ideas of Cross-Chain Technology (Chinese language)
- In-depth Analysis of Tendermint and How It Will Quickly Integrate Into the Cosmos Ecosystem (Chinese language)
Disclaimer: This material should not be taken as the basis for making investment decisions, nor be construed as a recommendation to engage in investment transactions. Trading digital assets involve significant risk and can result in the loss of your invested capital. You should ensure that you fully understand the risk involved and take into consideration your level of experience, investment objectives and seek independent financial advice if necessary.
Telegram group (English): https://t.me/OKExOfficial_English
Telegram group (Russian): https://t.me/okexofficial_ru