Key Takeaways
- Layer 1 Blockchain: Built using the Cosmos SDK and CometBFT, dYdX Chain is a dedicated Layer 1 for decentralized perpetual trading.
- Validators and Full Nodes: Validators manage block production, while full nodes support data indexing and serve blockchain data.
- Order Matching: Off-chain orderbooks and on-chain settlement ensure efficient and secure trading.
- Anti-MEV Measures: Designed to prevent malicious validator behavior through monitoring and penalization.
- Governance: dYdX token holders participate in decentralized governance through on-chain voting.
Introduction to the dYdX Technical Architecture
dYdX Chain is an independent Layer 1 blockchain platform designed to support a decentralized perpetual exchange.
This standalone network leverages the use of the Cosmos SDK and the CometBFT consensus protocol and is built to be fully decentralized in its entirety, including its front-end, orderbook, matching engine, and consensus mechanism.
The technical architecture of dYdX Chain is made up of three main components. These include:
- Protocol - the underlying Layer 1 blockchain that hosts the underlying infrastructure of the new flagship dYdX v4 exchange. The protocol is made up of two main node types: validators and full nodes.
- Indexer a read-only collection of services tasked with indexing and serving blockchain data (from dydX Chain full nodes) to end users in a highly efficient Web2-friendly manner.
- Front end the user-facing application that the trader sees when they interact with the exchange on their mobile device (via the dYdX mobile app) or computer.
It's important to note that each of the above components are available as open-source software and that none are run by dYdX Trading Inc.
The Main Architectural Components of dYdX
Blockchain Protocol
The open-source protocol that makes up the architectural backbone of the dYdX platform is a Layer 1 Proof of Stake (PoS) blockchain (dYdX Chain). dYdX Chain is built atop CometBFT consensus and the Cosmos SDK, while the node software is written in Go and compiles to a single binary.
Tasked with ensuring the protocol’s integrity and operational efficiency are two main node types, including:
- Validators: Validators are in charge of storing orders within an off-chain in-memory orderbook (which are not committed to consensus), gossiping transactions to other validators, and producing new blocks on dYdX Chain through consensus. In order for the consensus process to work as intended, validators take turns as the block proposer for a given round using a weighted-round-robin mechanism (weighted by the number of tokens staked within the validator). This is important because the proposer is responsible for the contents of the next block. In the event an order is matched, the proposer adds it to their proposed block and initiates a consensus round. If at least 2/3rd’s of validators (by weighted stake) within the set approve a block, then the block is considered legitimate and committed to the blockchain. Typically, users submit transactions directly to validators.
- Full Nodes: The main purpose of full nodes is to carry out specific processes on dYdX Chain that do not involve consensus. Full nodes have no weighted stake (no DYDX tokens are bonded within like validators) and do not submit or vote on proposals. That said, full nodes are interconnected with the validator set, participate in transaction gossiping, and process each newly committed block. Full nodes hold a complete record of dYdX Chain and its entire history and are designed to support Indexers. In order to reduce costs and increase performance, some parties choose to run their own full node and/or Indexer.
Misbehaving Validators and MEV
To complement dYdX Chain and its underlying v4 exchange, Skip Protocol developed the dashboard that allows the MEV committee to monitor (that allows users to observe prior to selecting the validator they delegate to) orderbook discrepancy among validators. This service is vital because it ensures the integrity of the exchange and underlying protocol.
It's important to understand that validators sometimes try to implement a strategy called maximal extractable value (MEV) that increases their profitability by deliberately including, omitting, or changing transaction ordering during block creation. This is done to extract additional rewards for themselves on top of the value they would normally obtain via transaction fees.
When a validator takes part in MEV extraction it is considered dishonest. On dYdX, this is possible because orders are stored in an in-memory orderbook (a highly performant matching engine) prior to execution. However, taking part in MEV is unacceptable because it comprises a transparent and equitable trading environment for users.
When a validator manipulates the ordering of transactions or unfilled orders on the network, it can impact the prices traders purchase assets at by making the trader pay more than they are actually required to spend at any given time.
The Skip protocol dashboard helps the community discourage and penalize malicious validators while also allowing exchange users to monitor which validators are matching orders honestly. Therefore, providing a more equitable trading experience for all involved.
Indexers
Indexers are a decentralized read-only collection of services tasked with indexing and serving blockchain data to end users in a streamlined Web2-friendly manner.
Indexers accomplish this by interpreting real-time data from a dYdX Chain full node, storing it in the required database, and serving that data via a websocket and REST request so it can be used by end users.
Although the open-source dYdX Chain protocol is able to expose endpoints related to service queries regarding basic on-chain data, those specific queries are typically quite slow because validators and full nodes are not optimized to handle them efficiently.
In addition, too many queries directed towards a validator often impairs its ability to participate in consensus. Because of this fact, many Cosmos validators choose to disable these APIs in production, meaning it is critical to build and maintain Indexer and full-node software separately from validator software.
It should be noted that Indexers employ Postgres databases for on-chain data storage, Redis for off-chain data storage, and Kafka as a means to stream and consume on/off-chain data to various Indexer services.
Front-ends
To provision the usability and utility of dYdX Chain (and dYdX v4), the platform leverages a user-facing decentralized open-source software called a front-end that a trader interacts with while using the exchange. On dYdX, these include: a web app, an Android app, and an iOS app.
- Web application: The dYdX website was developed utilizing JavaScript and React and interacts with the Indexer via an API to obtain off-chain orderbook data and send trades directly to the blockchain. Because dYdX has open sourced the front-end codebase and associated deployment scripts, anyone is able to simply deploy and access the dYdX front end to/from their independent domain or hosting solution via an IPFS or Cloudflare gateway.
- Mobile: The Android and iOS apps are built in native Kotlin and Swift, respectively, while the mobile apps interact with the Indexer in the same manner that the web application does to send trades directly to the blockchain. Both mobile applications are completely open sourced, enabling any party to deploy the mobile app via the App store or Play store.
Exchange Order Lifecycle
Now that we’re more familiar with the main architectural components that make up the dYdX Chain, let’s provide an overview of how the system comes together when placing an order. When an order is placed on dYdX Chain, it follows the below 5-step process:
- The user places a trade on one of dYdX Chain’s three decentralized front-ends (i.e., the website, or via the Android or iOS mobile application) or through an API.
- The order is then routed to a validator, then the validator gossips the transaction to the other validators and full nodes within the network so they are able to update their orderbooks with the new order.
- The consensus process selects a single validator to be the proposer, then the selected validator matches the order and adds it to its next proposed block.
- Next, the correctly proposed block continues with the consensus process.
- After the block is committed successfully, the updated on-chain data (and off-chain data) is streamed from the full nodes within the network to their corresponding Indexers. Finally, the Indexer makes the new data available via an API and the correct Websockets so it can be used by the front end and/or any additional outside services querying that specific data.
If your curious about more than the technical architecture, governance, and economics of dYdX and would like to dive into a comparative analysis of dYdX vs. other leading decentralized exchanges as well as the dYdX ecosystem and the project’s future, we’ve got you covered in our third installment of this series.
dYdX Tokenomics and Governance
Because dYdX is a Proof of Stake (PoS) blockchain, a tokenized unit of value (now known as native DYDX operating on dYdX Chain, and previously known as ethDYDX operating on Ethereum) is required to secure and govern the network.
During August 2021, more than 4 years after the development of dYdX began, the dYdX Foundation launched the ethDYDX token for the first time. Upon release in August 2021, the ERC-20 ethDYDX token was given a total supply of 1 billion with a distinct set of token distribution allocations for specific components of the dYdX project.
Though these distribution allocations were similar to present day, they were modified over the last two-and-a-half years because of the results of various community governance votes that changed how the tokens would be distributed moving forward.
It should be noted that these governance proposals only impacted the 50% community token allocation, while the remaining 50% allocation for investors, founders, employees, advisors, and future employees remained constant. In summary, the current token distribution for ethDYDX is as follows:
50% being distributed to the community as follows:
- 26.1% Community Treasury (261.1 million tokens)
- 14.5% Trading Rewards (144.7 million tokens)
- 5.0% Retroactive Mining Rewards (50.3 million tokens)
- 3.3% Liquidity Provider Rewards (32.8 million tokens)
- 0.6% Liquidity Staking Pool (5.8 million tokens)
- 0.5% Safety Staking Pool (5.3 million tokens)
With the remaining 50% allocated as follows:
- 27.7% Investors (277.3 million tokens)
- 15.3% Founders, Employees, Advisors, Consultants (152.7 million tokens)
- 7.0% Future Employees (70.0 million tokens)
In addition, the 50% community token distribution allocations can be changed in the event of another successful governance vote and there is no limit to how many times the community allocation specifics can be changed moving forward.
For the first 2.5 years after the initial launch, ethDYDX employed a gradual token release schedule to allocate rewards to protocol users. However, in December 2023, the circulating supply jumped from just over 194 million to 344 million because insider and investor tokens began to unlock. From December to August 2026, the token will be unlocked in small cliff intervals on the first of each month and continue to gradually unlock over the next 2.5 years up until August 3rd, 2026 (exactly 5 years after the initial token launch) when the full total supply will be in circulation.
The Ethereum version of the dYdX protocol employed a regular governance token (ethDYDX) and a wrapped version of the dYdX Ethereum token (wethDYDX). ethDYDX’s main uses entailed speculation and governance voting, while wethDYDX was used as a wrapped version of the ethDYDX token.
As of April 2024, the ethDYDX token is still live and trading on some exchanges. That said, on September 13th (prior to dYdX launching its new Cosmos chain on October 26th, 2023) in response to a dYdX community governance vote on dYdX v3, the dYdX Foundation commissioned the creation and open-sourcing of the wethDYDX Smart Contract.
Most importantly, the wethDYDX bridge contract is responsible for initiating the one-way token migration for both the Ethereum-based ethDYDX and wethDYDX tokens so holders can exchange them for the new DYDX token (at a 1:1 ratio via dYdX Chain).
If you'd like to learn more about the early days of dYdX and the journey it took to become one of the most well-respected and widely-used decentralized perpetual exchanges in crypto, feel free to read our introductory article in this series.
In addition, the newly launched DYDX token expands on the functionality of the tri-tiered token system we detailed above and its main uses are:
- Staking: Like any PoS blockchain, DYDX holders are able to serve as either a validator or a delegator (delegators are then able to choose which validator they’d like to delegate their stake to). The higher the number of DYDX delegated to a particular validator within the network, the higher the probability that validator will remain in the active set and continue contributing to consensus.
- Security: Staking the DYDX governance token is directly correlated to the security of DYDX Chain. Therefore, the more DYDX tokens are staked across a wide range of validators, the more secure the network ultimately becomes. This large scale validator-delegator distribution makes it harder for potential attackers to gain control of the network and disrupt network consensus.
- Governance: By staking DYDX, token holders are able to propose and vote on governance proposals that shape the direction of the dYdX ecosystem and dYdX Chain. As we’ll touch on below, governance proposals are able to modify the way community funds are spent to shape the project’s direction, change the ecosystem's tokenomic structure, update the system’s software, and more.
While the staking and delegation process we discussed above boosts the network’s security to improve the overall integrity of dYdX chain through network governance, it also allows community members participating in the dYdX Governance Forum to propose potential dYdX improvement proposals (DIPs) that shape the direction of the project.
DIPs follow a step-by-step sequentially ordered process utilizing both off-chain and on-chain components, including:
- Forum Discussion (off-chain) - any community member participating in the dYdX Governance Forum is able to create a thread to discuss a potential proposal.
- DRC Creation (off-chain) - a dYdX Request for Comments (DRCs) proposal is submitted to the forum by a community member outlining their proposed changes to the dYdX Chain and/or dYdX ecosystem.
- DRC Discussion and Feedback (off-chain) - after the proposer submits their DRC a discussion takes place on the forum to ensure all community members understand the proposal and the potential changes it would make to the ecosystem and/or blockchain. The goal of this step is to establish an overall consensus prior to a vote taking place.
- DIP Creation (off-chain) - once it's clear what is being proposed, the proposer drafts a DIP. The requirements for the intended proposal differ depending on if it's related to a: 1.) text proposal 2.) community spending proposal 3.) parameter change proposal, or 4.) software upgrade proposal.
- Proposal Submission (on-chain) after the DIP is created off-chain, it is then submitted to the blockchain via informatic code using the correct criteria.
- Proposal Deposits (on-chain) after the proposal is created, the required minimum DYDX deposit is initiated within the maximum deposit period. Upon creation, any dYdX community member is able to deposit (stake) their own DYDX tokens to show their support for the proposal.
- DIP Voting (on-chain) - next, after the minimum deposit criteria is fulfilled, the DIP is voted upon (via the governance tab within the dYdX dashboard in either the Keplr or Leap wallet) during the predetermined voting period. Of note, only users staking their DYDX can participate in on-chain governance by selecting one of four vote types: 1.) yes 2.) no 3.) no with veto, or 4.) abstain.
- Proposal Scoring and Execution (on-chain) - after the voting period ends the on-chain vote tallying parameter considers the quorum, threshold, and veto threshold parameters to determine if the proposal is either rejected or accepted (successful DIPs need 33.4% yes votes to be passed).
Resources
The information provided by DAIC, including but not limited to research, analysis, data, or other content, is offered solely for informational purposes and does not constitute investment advice, financial advice, trading advice, or any other type of advice. DAIC does not recommend the purchase, sale, or holding of any cryptocurrency or other investment.
