The dYdX Exodus: The Battle Between Application Chains and L2 Rollups

Author: Bryan, Jiawei, IOSG Ventures

1: The dYdX Exodus Event and the Battle Between Application Chains and L2 Rollups

Main reasons for dYdX leaving Starkware: The long development cycle of Stark technology, the complete decentralization of the L2 Node Operator network still requires time, dYdX's exploration of future composability, and the Cosmos SDK provides a developer-friendly environment.

• In addition to considerations of transaction speed and cost, the imaginative space of application chains also lies in token empowerment.

• Compared to generalized public chains, application chains have better flexibility in terms of rapid updates and iterations.

• A new multi-chain narrative change: High-quality applications show a weak dependence on the underlying chain, while the underlying chain/network shows a strong dependence on high-quality applications. Previously, applications would think about how to retain users; now it is the turn of public chains to consider the issue of "application retention."

Introduction

On June 22, dYdX announced that its v4 version would be launched as an independent blockchain based on the Cosmos SDK and Tendermint consensus, featuring a fully decentralized off-chain order book and matching engine, capable of increasing throughput by several orders of magnitude. Additionally, it is proposed that $DYDX be used as the native token for dYdX v4 (depending on community opinion). The team plans to open-source dYdX v4 by the end of 2022.

To facilitate readers' understanding, let’s make an analogy before the main text begins: Ethereum Rollup is like an old building in the city center, with the advantage of being surrounded by a bustling business district and transportation facilities (composability), but the disadvantage is that the decoration is outdated (slow infrastructure iteration) and owners are not allowed to renovate (no support for custom application nodes). dYdX is a major tenant in this building, usually without social interactions (not relying on composability), so it decides to move to the suburbs to build a small villa. At this time, it happens to meet a good renovation team (Cosmos SDK), which has previously done great work in the suburbs (Terra), so they hit it off and leave Rollup behind.

2: Reasons for dYdX Abandoning StarkWare to Build Its Own Chain

Decentralized Derivatives Market Trading Volume Hits a Bottleneck

Taking the largest centralized exchange, Binance, as an example, its derivatives trading volume far exceeds its spot trading volume. (Taking data from June 26, 2022, for BTC/USDT, its contract trading volume is about 8 times that of the spot trading volume.)

Binance spot market trading volume

Binance Derivatives market trading volume

However, the situation in the decentralized trading market is different. Comparing the trading volume of spot and derivatives, the largest long-tail asset spot trading market on Ethereum, Uniswap V3, has surpassed mainstream derivatives trading protocols like dYdX/Perpetual Protocol.

This indicates that there is still significant untapped potential in on-chain decentralized derivatives. The current biggest obstacle to decentralized derivatives trading is that pro traders tend to use centralized exchanges mainly because on-chain infrastructure cannot support the throughput required for derivatives trading. This was also the initial reason dYdX chose Starkware - from a protocol perspective, the off-chain zero-knowledge proof generation + on-chain proof mechanism can ensure the high-frequency trading demands of derivatives protocols; from a user perspective, rollup can provide transaction fees that are significantly lower than Ethereum L1 (about $0.03 in fees per transaction).

And Starkware has indeed achieved this, leveraging the advantages of its validity rollup to provide real-time reporting in oracle updates and greatly enhancing the advantages of dYdX's trading model by separating logic/execution - the L2 version achieves a massive leap of 10x to 25x in leverage compared to L1. - This is also the reason we are long-term bullish on rollups.

So, since Starkware brought dYdX a lot of performance advantages, what exactly caused it to leave Starkware?

We believe there are four points:

1. The long development cycle of Stark technology

2. The complete decentralization of the L2 Node Operator network still requires time

3. dYdX's exploration of future composability

4. The Cosmos SDK provides a developer-friendly environment

1. The Long Development Cycle of Stark Technology

Zero-knowledge proofs have always been one of the most challenging topics in cryptography, not just in crypto. One of the biggest difficulties in zero-knowledge proofs lies in the generation of zero-knowledge proofs - how to translate a computational integrity (a provable statement) into a verifier-friendly proof through an efficient (succinct) and secure (transparent) circuit has been a focus of academic efforts. (Indeed, the terms succinct/scalable and transparent describe Stark, which is the underlying technology of Starkware's rollup.) Stark is considered the ultimate form of zero-knowledge proof but is naturally the most time-consuming and labor-intensive to develop at the practical level.

In practice, it seems that this is indeed the case - the dYdX founder hinted that the performance of rollup nodes is insufficient to support the required TPS (throughput is crucial for order books).

Interestingly, the original quote cited in the blog is off-chain and decentralized, but the only way to achieve both off-chain and decentralized is by relying on zk technology. So whether dYdX will completely detach from Starkware in the future, or even return to the same zk faction of zkSync, is still a question mark. Or they might build a zk chain on Cosmos, but that doesn't seem logical.

2. The Complete Decentralization of the L2 Node Operator Network Still Requires Time

Currently, the Rollup network faces the issue of insufficient decentralization of Node Operators/Sequencers, and Vitalik has proposed some solutions for this, such as: sequencer auction, random selection from PoS set, DPoS voting, etc. (See: An Incomplete Guide to Rollups).

There is also this problem in the Starkware network, where the number of sequencers is very small and all are deployed by Starkware Labs themselves. Although this is a common situation for rollups, referencing the recent downtime of the Arbitrum sequencer, the dYdX team is not reassured by this highly centralized sequencer setup, as downtime poses significant risks for both traders and the protocol: traders are profit-driven, and any concerns about security will greatly challenge the platform's user retention. Of course, in the long term, the security brought by zk rollup + Ethereum L1 is far superior to Cosmos. However, one understanding is that such security, while guaranteed, is entirely dependent on Starkware's progress (development progress).

Earlier this year, dYdX expressed its determination and confidence to achieve decentralization in its roadmap outlook. This explains why dYdX did not choose another relatively centralized rollup solution.

3. dYdX's Exploration of Future Composability

Currently, dYdX is built on StarkEx, which does not support composability between dApps, while StarkNet is a universal virtual machine that allows composability within the ecosystem and interaction with smart contracts on Ethereum L1 (the known forms of interaction currently include relatively simple asset interactions), but dYdX has not yet migrated to StarkNet.

In addition, with the development of DeFi, a series of composable products based on decentralized derivatives trading markets, such as structured products, are a new direction for the future, and dYdX naturally does not want to miss such opportunities due to the current technical limitations of Starkware. (Currently, some arguments suggest that the derivatives market relies more on oracles for real-time value updates rather than composability. This theory has some logical support, and composability may not be as high a priority for the derivatives trading market as TPS.)

4. The Cosmos SDK Provides a Developer-Friendly Environment

Tendermint is regarded by developers as a very complete set of tools for developing L1, significantly lowering the threshold for developers to create public chains. Some excellent L1s have been developed based on this, whether it is the relatively independent Terra or EVMOS within the Cosmos ecosystem. Moreover, IBC has bridged communication between heterogeneous chains, laying the foundation for dYdX to use BTC as collateral on the Cosmos chain in the future.

Most importantly, the autonomy provided by Tendermint means that a public chain can have dedicated nodes, ensuring that these nodes have a certain level of specialization compared to Starkware's self-operated nodes (which are generalized), as prover nodes have to face not just dYdX's project but also the off-chain proof needs of other projects. Currently, there is no strong evidence indicating that Starkware intends to provide technical support for dYdX's needs - order book matching.

In an earlier published blog, it clearly pointed out the need for customized nodes.

Furthermore, from the perspective of token value capture, the value positioning of L1 tokens far exceeds that of a dApp, while nodes can capture a large amount of MEV value, which in the economic model of L2 is captured by Starkware's native nodes, providing no value for dYdX tokens.

Another possible reason: A lack of strong native belonging to the Starkware ecosystem.

Cairo and Solidity are two completely different programming languages, and there is no logical interoperability between them (one is mainly for writing zk circuits, while the other is for writing smart contracts; currently, to attract more developers, Starkware has created a third-party compiler to help complete the compilation from Solidity to Cairo), and at that time, Starkware Labs basically helped dYdX complete the entire Cairo code writing (Cairo is the language developed by Starkware itself). Therefore, from the perspective of the project party, there is not much sense of belonging to this language or even the ecosystem.

3: What Potential Impact Will the dYdX Exodus Event Have on Ethereum and Layer 2?

Image source: https://finematics.com/yearn-vaults-eth-vault-explained/

The strong gravitational pull of Ethereum, aside from its first-mover advantage, also lies in its "composability" and "network externality."

Composability is a system design principle that deals with the relationships between components. A highly composable system provides optional components that can be combined in various ways to meet specific user requirements.

Unlike the walled gardens established by traditional Web2 oligarchs, composability empowers the core innovation of DeFi. For example, yield aggregation protocols like Yearn rely on complex composability (lending, liquidity mining, yield farming, etc.) to build strategies that optimize capital efficiency. Imagine if these protocols were distributed across different chains; the complexity and risk of strategies would increase exponentially.

The main product of dYdX is the perpetual contract platform, with external dependencies limited to oracle price feeds. **We can envision dYdX's composability use case as the emergence of derivatives aggregators in the future, building structured products based on existing derivatives DEXs, such as using dYdX's order book to launch new products, just as Perpetual Protocol references Uniswap's trading information. However, compared to yield aggregators like Yearn or more basic lending protocols and DEXs, composability is not *indispensable* for dYdX.**

Network externality refers to: the utility each user derives from using a product is positively correlated with the total number of users. The more users there are, the higher the utility for each user. The network externality on Ethereum is particularly evident, as a solid user base makes Ethereum the preferred platform for application development over a long period.

Similarly, considering trading depth and slippage, dYdX itself has network externality; the more users there are, the better the depth and lower the slippage; but it does not rely on Ethereum's network externality. As a leading perpetual contract DEX, dYdX has already accumulated a certain user base, and traders are a relatively fixed group, capable of maintaining good user retention. Therefore, it is speculated that after migrating to Cosmos, with further optimization of trading speed and costs, in addition to the migration of existing users, dYdX may gradually attract more users.

That said, it is precisely because of Ethereum's massive scale that every small step forward requires careful justification, and development progress is often an unknown. After Vitalik proposed the "Rollup-Centric Ethereum Roadmap" and "Endgame," Ethereum's roadmap has shifted to focus on optimizing the base layer to serve Rollups, proposing new sharding solutions like Danksharding (expected to be realized in 18-24 months) and interim solutions like Proto-Danksharding (to be realized within 6-9 months). In the crypto world, time is money. Such timelines are evidently too long, and the development process is still accompanied by many uncertainties.

Due to the broad and deep involvement of generalized public chains, it is impossible to take significant steps in upgrades and optimizations too quickly, which constrains projects that require rapid updates and iterations. Application chains, on the other hand, have more flexibility, allowing project parties to operate more freely around application chains compared to relying on underlying chains.

The same logic applies to games, which are another type of application scenario that does not rely on composability. Games have their self-operating ecosystems, and external requirements are often limited to capital inflows and outflows between systems. Moreover, user experience is paramount in games; if the underlying chain cannot meet performance requirements, the game itself has the motivation to move away.

Looking back at Layer 2, we revisit the foundational logic of its narrative: Ethereum's throughput is insufficient to support large-scale applications, and poor transaction costs and speeds harm user experience. However, under the market conditions of a bear market, gas fees and transaction speeds remain within relatively reasonable ranges, which somewhat weakens user demand for Layer 2.

Additionally, dYdX was originally a leading native project on Ethereum, and as an early adopter of Layer 2, its approach to building an application chain will naturally be observed by other projects: since it is possible to operate outside of Ethereum, why bother with Layer 2? Considering this, if leading applications begin to follow suit and start building their own application chains, we may need to adjust our expectations for Layer 2 valuations accordingly.

4: Where Will Application Chains Go in the Future?

Before dYdX, some projects had already begun exploring the direction of application chains.

As early as June 2020, Axie Infinity proposed the idea of establishing the Ronin chain in a Medium blog post, and officially launched Ronin in February of the following year, with a peak TVL close to $1.5 billion. However, in April of this year, the Ronin bridge was hacked, resulting in the theft of $625 million worth of assets.

In March of this year, DeFi Kingdoms launched DFK Chain based on Avalanche, verified by Avalanche's subnet, and achieved compatibility with EVM.

In addition to considerations of transaction speed and cost, the imaginative space of application chains also lies in token empowerment.

Dan Elitzer, co-founder of Nascent, mentioned the idea of UNIChain in a tweet: Currently, the costs for Uniswap users mainly lie in trading fees, gas fees, and potential MEV expenses, with the latter two paid to Ethereum miners. If UNIChain were launched, could these two expenses be empowered to $UNI? Although Uniswap has over $5 billion in TVL and holds an absolute leading position among DEXs, the performance of $UNI has been lukewarm. Capturing the value of $UNI through an application chain is indeed a good idea.

Of course, as a DEX, Uniswap still has considerable reliance on Ethereum, as most tokens are still based on the ERC-20 standard. Unless cross-chain facilities are sufficiently developed, UNIChain may remain merely a conceptual idea.

However, this concept can extend to other protocols. The aforementioned DeFi Kingdoms has already taken a step forward, expanding the use case of $JEWEL from a governance token to gas fee payments on DFK Chain. Among these, $JEWEL collected as gas fees will reward 25% to validators, burn 50%, and reward the remaining 25% to the community. It can be seen that the adoption of application chains provides a broader space for the native tokens of projects.

Additionally, security is an issue that application chains must consider. For example, Aave's TVL is nearly 7 times its token market value; if it detaches from Ethereum's security guarantees, it will pose significant risks to on-chain funds.

Therefore, for applications with strong security needs, joining the multi-chain ecosystems of Polkadot or Cosmos is a viable option. At the same time, compared to the potential security risks of building their own chains, Polkadot and Cosmos also provide integrated security guarantees.

Developers can develop blockchains based on Substrate, and if they want to join the Polkadot ecosystem, they need to stake DOT to participate in bidding for Polkadot parachain slots or rent parachains to enjoy the shared security provided by the relay chain.

On Cosmos, developers can build application chains based on the Cosmos SDK and connect to the Cosmos ecosystem through IBC. As for security issues, Cosmos offers the Interchain Security solution, allowing multiple chains within the ecosystem to share the same validator set for block production, effectively outsourcing the block production work to the validators of mature networks, enabling relatively weaker new networks (the low market value of tokens may trigger security risks) to rent the security of mature networks.

5: The Application Retention Issue: Weak Dependence of High-Quality Applications on Underlying Platforms

A brief overview of the narrative logic of public chains: Back in 2017 and 2018, we aimed to create generalized public chains, proposing to become Ethereum killers and achieve millions of TPS, but these once-promising killers eventually faded away, even becoming assistants; then came the summer of DeFi in 2020, where sparks ignited into a prairie fire, making Ethereum's scalability an urgent issue, thus paving the way for expansion and multi-chain narratives; until two years later, everyone realizes that these valuation monsters are either dragging their feet or experiencing downtime, and they don't seem very reliable------ ultimately, they simply decide to create their own chains.

Image source: https://www.dapp.com/dapps/

From the above image, aside from games, there are very few applications on Ethereum that capture over 1,000 users. For applications, it is more appropriate to have a certain scale and user accumulation before creating an application chain. For smaller-scale applications, many current public chains can meet their throughput needs. For emerging applications, being backed by a large public chain can provide a certain level of exposure and convenience (considering user learning costs and capital inflows/outflows). Creating an application chain before reaching a certain scale also increases unnecessary cost burdens.

If a native application on Ethereum decides to create an application chain, it needs to consider migration costs------ will users be willing to migrate along with the application? How substitutable is the product on the original chain? (For example, if Uniswap creates an application chain, users can turn to Sushiswap.) If more application chains begin to emerge in the future, the entire ecosystem may become fragmented compared to the original, and good cross-chain infrastructure will be necessary.

Furthermore, stepping out of the context of Ethereum and dYdX to examine the relationship between underlying chains and applications, the best scenario is: applications rely on strong underlying chains to enjoy the composability they provide; and high-quality applications will also feed back into the underlying chains, bringing user growth.

However, we believe that high-quality applications have a weak dependence on underlying chains, while underlying chains have a strong dependence on high-quality applications. Firstly, in the current multi-chain landscape, if an application is good enough, finding a foothold is not difficult; secondly, the intersection between underlying chains and users mainly manifests at the application layer, and beyond that, users' perception of underlying chains is reflected only in terms of speed and cost. If there are only good infrastructures without high-quality applications, the value of the underlying chains cannot be fully realized.

Previously, applications would think about how to retain users; since dYdX, perhaps it is time for public chains to consider the issue of "application retention."