dYdX Chain: Analysis of Voting Power Distribution and Trading Optimization
CometBFT: The Consensus Engine Behind dYdX Chain
In late 2023, dYdX launched the dYdX Chain, a Layer 1 blockchain built using the Cosmos SDK and powered by CometBFT (formerly Tendermint) as its consensus algorithm.
CometBFT is Byzantine Fault Tolerant: this means that network security is guaranteed as long as failures impact less than ⅓ of the nodes on the network, under any circumstances.
In this system, Validators are responsible for proposing blocks of transactions. One validator is selected to become the proposer of a specific block in a round-robin fashion based on its total stake. This means that validators with greater voting power are more frequently chosen as block proposers compared to those with lower voting power.
dYdX uses a vanilla version of CometBFT, meaning that transactions included in a block are processed in a first-in-first-out fashion. This system fundamentally impacts the way trades occur on dYdX for two reasons:
- As a trader on the dYdX chain, the only way to gain an edge is to compete for speed and have the trades included faster than anyone else.
- As validators with large voting power are most likely to propose blocks, latency-aware traders optimize their setup to quickly submit their transactions to these prominent nodes.
In this article, we will understand more about the voting power distributions and the geographic distribution of the different nodes on the network. We will also explore methods that traders could use to minimize latency.
Understanding Validator Voting Power Distribution on dYdX
As of the time of writing, on January 28, 2024, here is the distribution of voting power among the 60 validators on the dYdX Chain.
As a first analysis of the voting power distribution, we can see that one validator, Ex Machina, has more than 27% of the voting power. This means that, on average, that validator will propose around 27% of the blocks on the dYdX Chain. Additionally the voting power of Ex Machina is close to the ⅓ threshold, if this threshold is reached by that validator, that single entity can halt the Chain and prevent events such as liquidations from happening.
In addition to that, the top 7 validators: Ex Machina, Santorini, Chorus One, Imperator.co, Pareto, Kepler, and Figment have enough power (+66% VP) to have control over block creation.
What does that mean exactly?
- These 7 validators can control the chain. They have enough power to influence the consensus process, manipulate transactions, disrupt the network, or even execute a double-spending attack
- If these 7 validators collectively have enough voting power (more than 2/3) to reach consensus, they can commit a block without waiting for additional validators. This implies that other validators who fail to commit on time would miss the block. On the mainnet, we observed that when a very large validator based in Europe gained sufficient voting power to get 2/3, most of the validators in Asia missed the block proposed by that European validator.
- If these seven validators fail to commit on time, another round starts, meaning that no other blocks would be created as long as these major validators are not fast enough, don’t want to reach consensus on purpose, or are offline.
Note: The chain is 4 months old, and the situation on the dYdX chain is still much better than when it was on the StarkWare Layer 2, because the chain is more robust and decentralized than on the L2 with a centralized sequencer. We can expect more work from the foundation and the dYdX community to improve decentralization over time.
Now, let’s analyze where the nodes are in majority located, by using Observatory this is what we can see on dYdX:
A very large majority of the nodes (85.58% of the total voting power) is located in Japan. If we want to do it even more gradually and check the nodes by cities, this is what we get:
A majority of the nodes (around 80%) are based in Tokyo, Japan. The reason behind this is that a lot of traders are located in Japan because Binance has its servers located in the Tokyo zone as well and use AWS.
Therefore, by also being located in the Tokyo zone, dYdX validators and the dYdX protocol would be able to attract Binance traders and offer them an optimal latency as well.
In conclusion, the optimal setup for a trader to trade on dYdX is where the majority of the voting power is, which is in Tokyo, Japan.
Optimizing Trading on dYdX Chain: Strategies and Challenges
In this section, we will analyze the different solutions for a trader to optimize for trade execution and latency, but also the risks that could come from doing this.
It is also important to note that traders, such as market makers, play a crucial role in this context, leading to positive outcomes. Market makers optimizing for latency on dYdX make the market more efficient and offer more accurate prices for other traders on the platform, such as directional traders or speculators.
In order to optimize for latency, there are a few strategies that a trader can employ. Here, we will mention the most obvious ones.
Being located in Japan:
Most of the voting power and nodes are located in Japan, and more precisely in Tokyo as we’ve seen in the previous part. By being located in Tokyo as well, theoretically the latency should be the smallest for traders, simply because the distance for the orders to reach a node is small.
This means that traders in Tokyo should be able to have their transactions included in a block faster than someone based in Europe or the US.
Getting access to specific RPCs or APIs
Public RPC and APIs aren’t always reliable and may cause delays when used for specific queries. This means traders could be disadvantaged if they rely on public RPC or APIs for data and transactions. Accessing a private RPC or API with real-time data could give traders a slight advantage over those without access. However, traders also need to be close to the nodes proposing blocks to benefit from low latency on RPC/API and proximity to validators.
Co-locating with another validator
Some traders may choose to co-locate with a validator, meaning their servers or trading bots are physically located in the same data center as the validator to minimize distance and latency. By doing so, trading bots can communicate and have their transactions included in a block faster than other traders, which provides a competitive edge in trade execution.
However, co-location makes sense with validators that have a significant voting power within the network. For example, co-locating with a validator like ex-Machina, which has over 27% of the voting power and consequently proposes on average 27% of the blocks on the dYdX chain, would offer a competitive advantage to traders co-locating with that validator for 27% of the time. This advantage isn’t guaranteed for the remaining 73% of the time.
Having its own validator
Having one’s own validator offers more than just a latency advantage. A trading firm with its own validator could act dishonestly, by using a forked version of the client to manipulate the order books, and thereby maximizing their profits.
To maximize profitability, the malicious validator needs to have significant voting power within the network to propose many blocks. However, even with a relatively small amount of voting power, such manipulation can still generate some profits but only in the short run. This kind of behavior can be detected rapidly, leading to a slashing penalty that would outweigh profits.
To learn more about MEV generally and the mitigation of undesirable MEV on the dYdX chain, feel free to read our research paper co-authored by Michael Moser and Umberto Natale from Chorus One.
The Skip Dashboard to Mitigate MEV on dYdX
To minimize MEV extraction, the Skip team created a dashboard that compares the trades proposed by the validators and the honest nodes run by Skip (which don’t propose blocks) to compute the order book discrepancy between the two. A high discrepancy can indicate potential MEV extraction. However, there may also be false positives, depending on latency and the geographical location of the nodes.
This is why Reverie put in place a social mitigation strategy for MEV on dYdX, which consists of implementing a governance-enforced social slashing model through a committee. This committee will be responsible for proactively investigating and reviewing the discrepancy data, and recommend actions based on the findings, such as slashing the malicious validator.
In this regard, at Chorus One we have researched MEV mitigation on dYdX v4 and, therefore, have a good understanding of it. Chorus One does not realize additional yield through MEV on dYdX, nor do we offer any additional MEV-related services on dYdX. Engaging in either of these activities would pose a slashing risk.
If you are interested in this topic and would like to engage in a discussion, please feel free to reach out.
Acknowledgements: Special thanks Michael Moser, Umberto Natale, Thalita Franklin, Luis Nuñez, Gabriella Sofia, Xavier Meegan and Yannick Socolov for their comments and feedback.
