Introduction to DerivaDEX Architecture

This article explains the DerivaDEX architecture at a high level. Future posts will dig into the security model, specific components like the price feed or checkpointing system, or programs like trade mining or the insurance fund. If there’s a topic you’d particularly like to see covered, please reach out in the Discord!

The testnet with the latest stable development release of the exchange is available at beta.derivadex.io.

Overview

DerivaDEX is a decentralized derivatives exchange platform entirely controlled by the DerivaDAO. Deposits and withdrawals (of USDC) are handled on Ethereum, whereas all trading and other exchange-related transactions occur on the DerivaDEX operator network (you may have heard this referred to as a “custom L2”). Two tranches of insurance funds, “staked” (from insurance mining) and “organic” (from USD-paid fees) are managed by the DerivaDAO and used to backstop traders against auto-deleveraging.

Why use an off-chain network for exchange operations?

1. Speed. DerivaDEX will compete with centralized alternatives on performance, including enabling high-frequency trading and other modern strategies. This is only possible via off-chain matching (with sub-second finality).
2. Cost. Paying Ethereum gas transactions is unrealistic for trading at volume.

What is the DerivaDEX operator network?

The DerivaDEX operator network is a purpose-built sidechain of operators that execute code within “trusted execution environments” (TEEs). A TEE is a region of protected memory that cannot be tampered with by whoever owns or controls the machine itself. The TEE provides several important security guarantees: code that is executed within the enclave cannot be tampered with, and it is possible to prove which executions have taken place inside the enclave. TEEs must go through “registration” prior to being accepted as operators, which affirms the integrity of the enclave and specifies the code that it has been approved to run.

DerivaDEX utilizes two forms of consensus:

• Raft, which ensures the correct ordering and replication of the request log across all operators
• A checkpoint consensus mechanism which is implemented in the contracts and provides additional security over-and-above that provided by TEEs.

Raft is a leader-based consensus that enables operators to ensure that orders and other exchange transactions are valid, and that they cannot be lost or reverted in between “checkpoints”. In a checkpoint, which occur roughly every 10 minutes, a hash of the entire state of the exchange is committed to Ethereum. This architecture enables swift trade execution and gasless transactions for all trades without sacrificing security of funds and integrity of orders.

The DerivaDAO controls what code is added to the on-chain contracts, including a whitelist of approved operators, which trading pairs can be listed on the exchange, trading fees, target size for the insurance fund, what leverage limits are enabled per trading pair, and more. Importantly, the DerivaDAO also controls what off-chain code the operators are allowed to run. Governance can change the implementation of the operator’s trusted processor, which will require operators to re-register with the updated implementation. Additionally, the exchange can only be brought to mainnet via a successful proposal to the DerivaDAO.

How does it work?

This is the normal flow for trading on the DerivaDEX system:

Deposits

1. Users deposit USDC to the exchange on Ethereum.
2. After 6 confirmations on Ethereum, the deposit is available for trading on DerivaDEX.

Orders

1. Users submit an encrypted order (this can be a market order, or a limit order). This is called a “client request” by the DerivaDEX system. Other types of client requests include cancel order requests or withdrawal requests.
2. This order is submitted to the sequencer. In the DerivaDEX protocol, the sequencer verifies the order by checking the EIP-712 signature (which confirms that the address claiming to send the order is in fact that address), as well as confirms via several rules called safeties that the order is valid (for example, that the user has enough free collateral to place that order). Then, the request is sequenced in the enclave. This means that operators who perform sequencing and other exchange functions cannot tamper with the order flow. Because data is encrypted when it is ordered, operators cannot see or censor specific transactions. In other words, operators cannot front-run orders.
3. Operators commit orders to the RAFT network on the ordering of the request, and submit a receipt to the user (more information on RAFT and how it’s applied in DerivaDEX can be found in the technical appendix!). Users receive a response containing their signed ticket number, which also guarantees their order’s slot in order flow.
4. After the request is committed to the RAFT and receipts are sent to the user, the ordered, decrypted requests are submitted to the execution engine (which verifies the signature, and ordering of each request prior to execution). This prevents any modification to ordering.
5. Execution is performed (matching, liquidations, ADL, and all other exchange logic).
6. All executed transactions are added to the “transaction log”, which anyone can subscribe to and can validate the state machine in real-time. DEX Labs will ship an Auditor program which does this validation by replaying each transaction log entry through its reference implementation of the matching engine.

Withdrawals

1. Approximately every 10 minutes, a “checkpoint” is submitted to the DerivaDEX Ethereum contracts. These checkpoints contain a hash of the entire transaction log. If the exchange is ever stopped or brought down for some reason, the state can be restored by “replaying” the data stored in these checkpoints.
2. A user that initiates a withdrawal transaction in one checkpoint will be able to complete their withdrawal in the subsequent checkpoint.

DerivaDEX Compared

So, how does the DerivaDEX operator network compare to other decentralized exchanges?

• All funds are custodied on Ethereum, and updates to the account balances for each trader are made at each checkpoint.
• DerivaDEX is focused entirely on enabling the core properties of a centralized exchange, without requiring trust. To achieve this, the DEX uses traditional first-in first-out (FIFO) sequencing instead of complex decentralized algorithms, as well as a simple and fast Raft consensus. Also, DerivaDEX uses the abilities of hardware (i.e., for speed, security) where applicable. The architectural choices made by DerivaDEX are intended to make strategies that are possible on centralized exchanges possible on DerivaDEX.
• DerivaDEX requires instant finality, a feature that is necessary to trade highly leveraged derivatives with underlying external markets, so the exchange defensively implements safeguards (i.e., use of TEEs, checkpoints, RAFT) upfront.

How does the DerivaDEX design compare to other L2 solutions?

This chart draws from ethereum.org’s description of zkrollups and optimistic rollups, two common L2 solutions for decentralized exchanges that utilize off-chain execution, and contrasts them with the DerivaDEX operator network.

Future posts will dive deeper into the price feed, how operators are registered (and slashed or removed), the RAFT consensus model used by the operators, and the overall DerivaDEX security model. However, this post should provide you with a good foundation in how DerivaDEX works, what components are involved, and the lifecycle of a trading transaction.

What’s next?

In the coming weeks there will be a public trading competition for the DerivaDEX exchange. Stay tuned to get the latest updates and to sign up when registration opens for the competition! As always, if you have questions about this article (or other questions about DerivaDEX) please hop in the Discord and ask away!

Join the DerivaDAO!

Join the Discord and email list to learn more about upcoming products and early access opportunities.

Technical Appendix

• Registration of an operator includes undergoing “remote attestation”, which you can read more about here: https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/attestation-services.html
• Blockchain-like BFT (byzantine fault-tolerant) consensus algorithms create fundamentally different environments than are found in traditional exchanges. This means that the same strategies (e.g. high-frequency trading) would be impossible to perform in traditional blockchain (or even rollup) -based systems. Upcoming articles will expand upon this.
• Raft is the leader-based consensus algorithm used by operators to ensure that orders and other exchange transactions are valid, and that they cannot be lost or reverted in between “checkpoints”.
• “Checkpoints” utilize sparse merkle trees to store a hash of the entire state of the exchange. Additional documentation of the DerivaDEX checkpointing system is forthcoming.