dYdX is a decentralized exchange for trading financial derivatives that specializes in trading perpetual contracts on digital assets. Initially powered by StarkEx, dYdX is migrating its matching engine and orderbook to Cosmos.
The platform is renowned for its user-friendly interface, low fees, and the ability to provide up to 20x leverage on positions. These features have positioned dYdX as a leading choice for traders seeking a decentralized alternative to centralized exchanges (CEXs).
Since its inception, dYdX has gone through 3 versions and is in the process of transitioning to its own appchain (application-specific chain) – the dYdX chain on Cosmos.
Unlike the previous 2 versions, the exchange runs on an Ethereum layer 2 instead of Ethereum mainnet. In this version, even though the protocol remains non-custodial and settles trades and liquidations in a trustless manner, dYdX v3 perpetuals use a centralized orderbook. This way, by settling trades on an Ethereum L2, the exchange is able to offer much higher trade throughput and lower minimum order sizes, compared with systems settling trades directly on Ethereum (i.e. L1). This is achieved while maintaining decentralization, and the exchange remaining fully non-custodial. This way, it also becomes much faster to add new markets.
The L2 system for v3 was developed in collaboration with Starkware. With this transition to an Ethereum layer-2 the goal was to enhance the performance and scalability of the protocol. StarkEx enables efficient processing and verification of transactions, reducing costs and providing instant finality.
StarkEx offers two different modes, namely Validium and ZK-Rollup, each with its own trade-offs in terms of cost, trust, and transparency. Initially, dYdX did not have strong preferences, but after they considered the implications of cost and transparency, the team opted to use a ZK-Rollup solution and keep the data on-chain.
The rationale behind this decision was that the cost of publishing the data on-chain, although higher in terms of gas fees, was manageable for dYdX at the time. They chose to absorb the gas costs and not pass them on to the users, ensuring a seamless trading experience without gas fees.
The transition to Layer 2 meant that there would be less data available on the Layer 1 blockchain for users to see on a block explorer. On Layer 1, users can see the balances of all users, including synthetic assets and funding indices. This data provides information about the total amount of money in the system when the last batch was accepted. However, the transactions themselves are not published on-chain to save gas and keep trading strategies private.
To ensure the validity of off-chain data, the StarkEx protocol uses the Cairo program as its core. The Cairo program receives the sequence of transactions and adds the balances of the positions that were changed during the batch. This output is linked to proof, and if the transaction data cannot be shown on-chain, the proof will not be accepted.
Unlike Layer 1 where validators typically select transactions based on the highest gas price, on Layer 2, such as dYdX, they have the responsibility of ordering transactions. This means they act as the “miner” for every block. However, there are protections in place to ensure that users can withdraw their funds and that transactions cannot be censored entirely.
Similar to Layer 1, Layer 2 solutions like dYdX are non-custodial, meaning they cannot steal users’ funds. However, due to the more centralized matching engine in use, in v3 dYdX has the ability to restrict certain traders from accessing the system.
In this version, accounts may only have up to 20 open orders for a given market/side pair at any one time. (For example up to 20 open BTC-USD bids).
Collateral is held as $USDC, which is also the quote asset for all perpetual markets. Additionally, cross-margin is used by default – an account can open multiple positions that share the same collateral. In order to access the isolated margin, the user must create separate accounts (sub-accounts) under the same user.
Each market has 3 risk parameters that determine the maximum available leverage as well as how much value should be held in an account in order to open or increase positions (in the case of initial margin) or avoid liquidation (in the case of maintenance margin):
Besides, the following parameters are also monitored:
In dYdX v3, there is no distinction between realized and unrealized PnL for the purposes of margin calculations. Gains from one position will offset losses from another position within the same account, regardless of whether the profitable position is closed.
Where:
The margin requirement for the account as a whole is the sum of the margin requirement over each market i in which the account holds a position:
The total margin requirement is compared against the total value of the account, which incorporates the quote asset (USDC) balance of the account as well as the value of the positions held by the account:
The account value is also known as equity.
If the account’s total account value falls below the total initial margin requirement, the account is unable to open new positions or increase the size of existing positions without exceeding the available margin.
Free collateral, which indicates the amount of available funds, can be calculated using the formula:
Free collateral = Total account value – Total initial margin requirement
This way, changes in the account’s value can be monitored using the latest Oracle price obtained from the markets’ websocket.
The liquidation process is intended to protect the integrity of the system and ensure that accounts maintain sufficient margin. By automatically closing positions that fall below the maintenance margin requirement, the platform mitigates the risk of further losses and helps maintain stability in the trading ecosystem.
When the total account value falls below the total maintenance margin requirement, the account may be subject to liquidation. In such cases, the positions within the account are automatically closed by the liquidation engine. The profits or losses resulting from the liquidations are assumed by the insurance fund.
The close price for a position being liquidated is calculated differently depending on whether it is a short or long position:
Where:
These formulas are designed to ensure that the ratio V / W remains unchanged as individual positions are liquidated.
Funding payments play a vital role in encouraging the price of a perpetual contract to closely track the price of the underlying asset. These payments are exchanged between long and short traders.
In v3, funding payments are credited or debited at the start of each hour and are included in the realized profit and loss (PnL) calculation for the position. To obtain information about funding payments, the GET /v3/funding API endpoint can be used, while the predicted funding rate can be retrieved with the GET /v3/markets API endpoint.
The funding rate is typically represented as a 1-hour rate since funding payments occur on an hourly basis. This rate signifies the return or payment an account may expect to receive or pay per hour for a position.
The funding payment at the start of each hour is calculated using the following formula:
F=(-1) x S x P x R
Where:
The funding rate calculation includes a premium component, which considers market activity and is calculated every minute for each market. The premium component is determined based on the difference between the impact bid price (average execution price for a market sell) and the impact ask price (average execution price for a market buy), relative to the index price of the underlying asset.
Premium = (Max(0, Impact bid price – Index price) – Max(0, Index price – Impact ask price)) / Index price
Where the impact bid and impact ask prices are defined as:
Impact bid price = Avg Execution for a market sell of the impact notional value
Impact ask price = Avg Execution for a market buy of the impact notional value
The impact notional amount for a market is:
Impact notional amount = 500 USDC / Initial margin fraction
When calculating the funding rate, the premium component is adjusted to have a realization period of 8 hours. For example, if a perpetual market consistently trades at a 0.1% premium relative to the underlying asset, long traders can anticipate paying approximately 0.1% every 8 hours, while short traders may expect to earn a 0.1% return every 8 hours (excluding the interest rate component).
For example, for a market with a 10% initial margin fraction, the impact notional amount is 5,000 USDC.
At the end of each hour, the premium component is determined as the simple average (time-weighted average price – TWAP) of the 60 premiums calculated during the previous hour. Additionally, each market has a fixed interest rate component that accounts for the difference in interest rates between the base and quote currencies. The funding rate is then calculated as follows:
Funding rate = (Premium component / 8) + Interest rate component
Currently, the interest rate component for all dYdX v3 markets is 0.00125% (equivalent to 0.01% per 8 hours).
To ensure the solvency and stability of the system, contract loss mechanisms are in place to address situations where the value of accounts holding perpetual contracts drops below zero due to high volatility in the underlying markets.
Oracles ensure collateralization and determine liquidation thresholds.
The oracle price for each trading pair is determined based on the median of the reported prices from 15 independent Chainlink nodes.
The 15 independent Chainlink nodes responsible for reporting the prices include providers such as Chainlayer, Inotel, LinkForest, SimplyVC, DexTrac, Fiews, dMakers, linkPool, SDL, Ztake, stakFacils, infStones, 01node, Syncnode, and Vulcan. These nodes contribute to the determination of the Oracle price by reporting their respective price data.
By relying on the median of prices reported by independent Chainlink nodes, the platform obtains a reliable and decentralized price feed that is used to assess collateralization levels and trigger necessary actions such as liquidation. The use of multiple independent nodes enhances the accuracy and integrity of the oracle prices, reducing the potential for manipulation or single-point failures in price reporting.
The index price for each asset is used to calculate the funding rate and trigger orders, such as stop-limit and take-profit orders.
Index prices are equal to the median of several exchanges’ spot prices, where each exchange’s spot price is calculated as the median of the best-ask, best-bid, and last-traded prices of its spot pair.
dYdXv4, also known as dYdX Chain, was fully released on October 24, 2023, and represents significant enhancements and a new architecture.
Unlike the current version, v3, which relies on smart contracts deployed on existing chains with centralized cloud services, v4 is a standalone Layer 1 (L1) blockchain. This upgrade aims to scale and enhance decentralization using the CometBFT consensus and Cosmos SDK. Cosmos not only makes it easy to create a standalone blockchain but also offers strong cross-chain capabilities, high throughput, decentralization, and customizability. Additionally, each Cosmos chain has its own validators and layer 1 staking token.
The fundamental problem with most L1s and L2s is that they cannot handle the throughput needed to run a first-class orderbook and matching engine. To solve those problems, the core feature of v4 is the implementation of a fully decentralized, off-chain orderbook, and matching engine. This means that the orderbook and trade execution will be processed off-chain, offering improved scalability and efficiency.
While dYdX explored other trading models such as an AMM or RFQ system, the decision was made to go with an orderbook and matching engine. This is critical to offer the trading experience that pro users and institutions demand. In dYdX, each validator will run an in-memory orderbook that is never committed to consensus (i.e. off-chain). This way, orders placed and cancellations will be propagated through the network similar to normal blockchain transactions, ensuring that orders placed and cancellations will always make their way through the network. Furthermore, the orderbook that each validator stores is eventually consistent with one another. On a real-time basis, orders will be matched together by the network. The resulting trades are then committed on-chain each block. This is the key point that makes it possible for dYdX to offer high throughput for the orderbook while remaining decentralized.
Another notable feature is that there are no trading gas fees. The customizability of the Cosmos SDK makes it possible to develop these characteristics to suit the exact needs of the network. As a result, traders don’t pay gas fees to trade, but rather only pay fees based on the trades they execute, similar to dYdX v3 and centralized exchanges. These fees accrue value to validators and their stakers.
At the technical level, the dYdX Chain will be built on the Cosmos SDK, which provides a framework for developing scalable and interoperable blockchains. The node software is written in Go and compiles into a single binary. To ensure consensus and network security, v4 will utilize the CometBFT Proof-of-Stake (PoS) consensus protocol. PoS consensus allows validators to participate in block production and secure the network based on the number of tokens they hold and “stake” as collateral.
Note that once dYdX v4 is launched, all previous versions will be deprecated.
dYdX v4 is designed to be a completely decentralized end-to-end. The main components broadly include the protocol, the Indexer, and the front end. Each of these components will be made available as open-source software and none of the components will be run by dYdX Trading Inc.
The protocol operates as a network of nodes, and there are two types of nodes:
Validators take turns as proposers of new blocks in a weighted round-robin fashion, with the weight determined by the number of tokens staked to their node. When an order is matched, the proposer includes it in their proposed block and initiates a consensus round. If two-thirds or more of the validators (by stake weight) approve the block, it is considered committed and added to the blockchain. Users submit transactions directly to validators, who process and validate them.
Full nodes maintain a complete view of the dYdX Chain and its history. They are primarily intended to support the Indexer, a component that helps in querying and indexing blockchain data. For instance, some entities may choose to run their own full node and/or Indexer for performance or cost reasons.
The minimum recommended specs for running a node are:
An example of this would be an AWS instance like the r6id.2xlarge, or equivalent.
The Indexer serves as a read-only collection of services. Its main purpose is to index and efficiently serve blockchain data to users in a more accessible and user-friendly manner.
To accomplish this, the Indexer consumes real-time data from a v4 full node, and then stores this data in a database, typically using Postgres, and makes it available for retrieval and querying.
By indexing the blockchain data in a separate database, the Indexer can optimize the storage and retrieval processes, enabling faster and more efficient access to the data. It also provides a range of services such as websockets and REST APIs to serve this indexed data to end-users.
One advantage of the Indexer is that it allows for a more web2-friendly experience, meaning it provides data in a format that is compatible and easily consumable by traditional web applications. It helps overcome the limitations of directly querying the v4 protocol endpoints, which can be slower and less efficient due to the primary focus of validators and full nodes on consensus and block production.
The Indexer utilizes various technologies to handle the data efficiently:
These technologies work together to ensure the availability, scalability, and responsiveness of the Indexer’s data retrieval and serving capabilities.
By distinguishing between on-chain and off-chain data and handling them separately, the protocol allows different services to scale according to the specific throughput requirements of each data type. On-chain data is crucial for maintaining the integrity and transparency of the blockchain, while off-chain data provides real-time and ephemeral information for efficient order book management and processing.
The Indexer comprises several services that work together to ingest and serve data from v4 Full Nodes. These services facilitate the efficient storage and retrieval of blockchain information.
Hosting and deploying the Indexer requires certain infrastructure and personnel to ensure its availability and maintenance.
In addition to that, there are the following personnel requirements:
This comes with the following deployment and maintenance responsibilities:
To meet these requirements, the operator should have accounts for the mentioned AWS services and hire appropriate personnel, such as a DevOps engineer, to handle the deployment and maintenance responsibilities. This ensures that the open-sourced Indexer can be hosted in a highly available manner, with consistent uptime for public access.
The web front end provides an intuitive and performant UI/UX for traders who do not wish to interact with v4 programmatically. The web front-end application will interact with the Indexer via APIs/websockets to fetch and display both on-chain and off-chain information (e.g., orderbook, account balances, etc.). Orders will be placed directly to validators.
dYdX is developing three open-source front-ends to provide users with a decentralized experience: a web application, an iOS app, and an Android app.
By open-sourcing the front-end codebases and providing deployment scripts, dYdX aims to promote transparency, community involvement, and accessibility. Users and developers will have the ability to examine, modify, and deploy the front-end applications according to their own needs. This approach aligns with the decentralized nature of dYdX and empowers individuals to access and use the platform through a variety of interfaces.
To deploy a web front end for dYdX, one should follow these steps:
The deployment script is designed to simplify the hosting and updating process for the front end. As a deployer, your responsibilities include:
By following these steps, you can deploy and maintain a web front end for dYdX, allowing users to access the trading experience through your own domain.
MEV (Miner or Maximal Extractable Value) refers to the profits that validators or miners can earn by reordering or censoring transactions to their advantage. In the context of dYdX v4, the fully decentralized and performant in-memory orderbook used by the dYdX chain could potentially enable MEV extraction. To address this, dYdX is proactively working on researching and building MEV solutions that align the incentives of validators with the interests of users.
The Ethereum ecosystem generally takes a neutral approach toward MEV, with a Proposer-Builder Separation (PBS) approach used to auction off block space. PBS helps mitigate the centralization risks associated with MEV but still negatively impacts average users. In contrast, the Cosmos ecosystem, including Osmosis, takes a more opinionated stance towards MEV. It aims to mitigate harmful MEV and capture any benign MEV generated.
While dYdX v4’s design enhances performance, it introduces complexities like validator-driven MEV. Validators can manipulate transaction order and inclusion within a block, potentially benefiting themselves unfairly at the expense of others.
However, dYdX prioritizes user experience and has chosen the Cosmos infrastructure to create a fully decentralized exchange with high performance. This infrastructure enables the integration of unique MEV solutions into the dYdX v4 chain. By building MEV mitigations directly into the protocol code, dYdX aligns the incentives of validators and users on-chain. This way, unlike general-purpose smart contract environments, where validators are neutral towards the needs of application users, dYdX’s approach prevents validators from profiting at the expense of users.
dYdX is working closely with MEV experts such as Skip Protocol and ChorusOne to develop MEV mitigation strategies for the dYdX v4 chain.
The design of dYdX v4 introduces opportunities for MEV extraction through various methods beyond traditional forms like arbitrage, liquidation, and sandwich attacks.
To assess MEV on dYdX v4, research by Chorus One suggests using an estimator that quantifies the financial gain captured by the block proposer through privileged actions, such as manipulating the order book.
The MEV of a proposed block is calculated as the sum of absolute differences in profit and loss (PNL) at the subaccount level based on matched orders. This estimator measures how much the block proposer’s actions shift PNL values from other validators’ views.
Where PNLiBP is the PNL based on the block proposer’s matched trades for subaccount i and PNLiV is the PNL based on the block validator’s matched trades for subaccount i.
The MEV Estimator has two properties:
Some examples of MEV extraction are:
Suppose the order book on dYdX v4 looks like this:
During the intrablock period, the sub-account C submits the following order:
The block proposer, who knows that the block will end with a mid-price of $100, chooses to insert a sell order for their own sub-account X during the block proposal stage, ignoring the existing sell order from A. The result is that the block proposer captures the spread profit from the existing orders. The validator’s view of matched orders after these actions could be:
The MEV extracted by the block proposer is calculated using the estimator formula:
MEV = 1/2 * (|0 – 100| + |0 – 0| + |-100 – -100| + |100 – 0|) = 100
Imagine the order book on dYdX v4 initially as follows:
During the intrablock period, the sub-account B submits a cancel order to cancel their sell order at $102, and the sub-account E submits a buy order at $104.
The block proposer, who anticipates a mid-price of $105 at the end of the block, ignores the cancel order from B and the buy order from E, executing only their own matched orders. This action transfers profit from the canceled order to their sub-account X. The PNL calculations for both the validator and block proposer could look like:
Using the MEV estimator, the block proposer captures MEV of:
MEV = 1/2 * (|0 – 0| + |-300 – 0| + |0 – 0| + |900 – 0| + |0 – 300|) = 400
Consider an order book on dYdX v4 with the following orders:
During the intrablock period, the sub-account E submits a market sell order, aiming to fill at the market price.
The block proposer, aware that the block will end with a mid-price of $99, submits their own matched orders that capture the slippage between different market orders, resulting in profit extraction. The matched orders for both the validator and block proposer could be:
Using the MEV estimator, the block proposer captures MEV of:
MEV = 1/2 * (|0 – 300| + |100 – 0| + |0 – 0| + |-200 – 0| + |-300 – 0|) = 300
Suppose the order book on dYdX v4 looks like this:
Additionally, there are pending stop limit orders:
The block proposer, with the knowledge that the block will end with a mid-price of $110, submits matched orders to trigger a cascade of stop-limit orders by exploiting the price movement. This results in profit extraction by moving the price to their advantage. The matched orders for both the validator and block proposer could be:
Using the MEV estimator, the block proposer captures MEV of:
MEV = 1/2 * (|-800 – 0| + |500 – 0| + |800 – 0| + |-500 – 0|) = 1300
There are challenges related to the MEV estimation suggested by research from Chorus One, which could introduce some bias in the implementation of the estimator. One situation could involve a misbehaving block proposer and differing mempool views on different validators. In this scenario, each validator has a unique view of the mempool due to receiving different transactions based on the network topology. Specifically, the case involves ignored orders coming from the intra-block period.
The presence of dYdX could affect the overall MEV structure within the Cosmos ecosystem. To analyze that impact, one must account for different factors, such as:
During specific market conditions, validators proposing a block might be incentivized to create arbitrage opportunities between AMMs and dYdX v4, potentially impacting the users of the AMM.
We can look at two different scenarios: one where dYdX has liquidity supremacy and another where it doesn’t.
Additionally, pricing on dYdX v4 could be influenced by the presence of another Central Limit Order Book (CLOB) with higher liquidity for a given asset.
There is the possibility that market makers and trading firms reach partnership agreements with validators to engage in MEV strategies. Due to the existing moats of both parties, a partnership is the most probable way validator-driven MEV would manifest.
There is a broad range of conditions that can be explored for each individual partnership, but fixed fee arrangements might be more likely due to their stability and compatibility with market-making operations.
One way to mitigate validator-driven MEV is to introduce a slashing penalty that reduces a validator’s staked capital. This is often a significant deterrent for validators engaging in potentially harmful MEV activities. Even if a partnership with a trading firm were to generate revenue, the risk-adjusted benefit would likely favor the validator, making it an unfavorable proposition for delegators. Additionally, publicizing the risk carried by delegators and offering a way to re-delegate to good actors could serve as an effective approach to mitigating validator-driven MEV.
Overall, it is increasingly important to detect misbehaving validators through order book execution comparisons and outlining penalties for non-accidental infractions. For instance, the development of a dashboard in collaboration with Skip Protocol could help to measure MEV events.
dYdX was launched in 2017 by Antonio Juliano, a former engineer at Coinbase, and has since gained significant traction within the DeFi space. The protocol aims to address the limitations of traditional financial systems by providing a decentralized alternative that offers transparency, security, and accessibility.
In 2018, dYdX launched Expo, a simple trading app that allowed users to buy leveraged tokens. This app was built on the initial version of the margin protocol. The team continued to refine their protocols, and in 2019, they released a more advanced exchange product targeting experienced traders. This version, known as V2, introduced a powerful pool-based lending approach and implemented an order book system to enhance the trading experience.
A significant milestone for dYdX occurred in 2020 when it became the first decentralized exchange to offer perpetual contracts. In April 2020, the Bitcoin perpetual contract was launched, positioning dYdX as a pioneer in decentralized perpetual trading and solidifying its reputation as a product leader.
In 2021, when Ethereum gas fees soared, dYdX recognized the need for changes to their product. As a response, they transitioned to the layer 2 Starkware platform – StarkEx. This shift significantly improved throughput, introduced cross-margining, expanded trading markets, and increased liquidity. The most important reason for moving to a layer 2 was the order execution speed and associated costs. Another problem was the speed of getting oracle prices on-chain. When the price changes dramatically and gas costs increase, the oracle prices settle on-chain at a much slower pace, which also creates additional risk for users.
During the same year, dYdX took further steps towards decentralization by launching the $DYDX token. The token grants governance rights on the dYdX protocol, empowering the community to take ownership of protocol parameters and participate in community-led initiatives. The launch of the $DYDX token demonstrated dYdX’s commitment to decentralization and community involvement.
Moving forward, dYdX aims to achieve full decentralization by migrating the order book and matching engine to its standalone blockchain based on Cosmos in the V4 upgrade. By using the Cosmos SDK and Tendermint consensus, the goal is to ensure that the system remains as decentralized as possible.
The decentralization of a system is determined by its least decentralized component. Existing Layer 1 or Layer 2 blockchains cannot handle the required throughput for running a first-class orderbook and matching engine. dYdX v4 aims to process orders of magnitude more trades and order placements/cancellations per second.
In addition to that, Cosmos provides a high degree of customizability, allowing dYdX to design the blockchain to suit its specific needs. Validators in dYdX v4 will run in-memory orderbooks that are not committed to consensus. Orders and cancellations will be propagated through the network like blockchain transactions, ensuring their availability. Real-time matching of orders will take place off-chain, and the resulting trades will be committed on-chain. This approach allows for high throughput and decentralization.
While CEXs and DEXs serve similar purposes of facilitating the exchange of digital assets, they differ significantly in their underlying principles, control structures, security models, and user experience. DEXs, including dYdX, aim to provide users with self-custody, transparency, and greater control over their assets, aligning with the core principles of decentralization in the cryptocurrency ecosystem.
dYdX belongs to the decentralized finance (DeFi) sector, more specifically dedicated to financial derivatives. DEXs operate through smart contracts, eliminating the need for a centralized party. This offers advantages such as greater control over capital, streamlined onboarding, and direct peer-to-peer trading. However, they may be complicated for first-time users and typically have smaller trading volumes and less liquidity. DEXs also lack fiat on-and-off ramps, requiring users to obtain cryptocurrency elsewhere before trading. Smart contract risks exist, necessitating careful platform selection.
When compared to other derivatives, dYdX has consistently ranked among the top protocols both in TVL and trading volume. The exchange is positioned to become a decentralized replacement for centralized exchanges. As a matter of fact, many firms hedge their exposure to centralized custodians by trading on-chain with dYdX. This saved many platforms during the collapse of FTX since they were able to keep custody of their own funds when trading on dYdX.
Market makers note that dYdX can often offer more liquidity for instantaneous trades compared to centralized exchanges, let alone other oracle-based on-chain perpetuals. This is greatly appreciated by professional firms, due to the ease of accessing liquidity on DeFi, which contributes to higher volumes and fees for the protocol. Examples of market makers using dYdX include Cumberland, Wintermute, and Genesis Global Trading among others.
Ultimately, the goal of dYdX is to eventually become one of the largest exchanges in all of crypto. Since v1, the protocol has kept on improving and showing its dissatisfaction with existing infrastructure solutions. While dYdX could have opted for more standard options like an AMM or RFQ system on an L2 rollup, none of these solutions would get the protocol close to seeing its mission achieved.
The volume on dYdX today is largely thanks to the two major developments that took place in 2021. First, shifting to a layer 2 rollup enabled faster and cheaper transactions. Second, the launch of the $DYDX token made it more attractive to trade on the exchange, since you could get paid token rewards for doing so.
The early-moved advantage of dYdX cannot be understated either. Even without adding many new tokens and doing so very frequently the exchange still retains a dominant position among derivative DEXs. Instead of focusing on that front, that has allowed the team to focus on features such as improving the API, which makes it more useful and attractive for market makers and institutions.
Developing a decentralized, off-chain orderbook and matching engine and moving from Ethereum to a dYdX-specific chain as a major DeFi protocol is very much untested. However, dYdX believes that this is the best shot at developing a network that could offer a long-term competitive product experience with centralized exchanges.
One of the differentiating factors of dYdX is that it is heavily used by professional market-making firms. These companies can interact with the protocol using a standard API, just like they do with centralized exchanges. This way they don’t have to worry about the complexity and non-standard ways to interact with blockchains. These hedge funds and proprietary trading firms make up the majority of the trading volume, with “prosumer” retail users being the minority.
Cross-margining is also extremely helpful to attract professional traders and market makers, especially those who trade in multiple dYdX markets. With cross-margining on dYdX, market makers benefit from reduced collateral requirements compared to non-cross-margined platforms. This allows them to optimize their capital utilization and avoid the need for excessive collateral posting during volatile market conditions. It also provides flexibility for traders to switch between different markets easily.
Market makers on dYdX typically build their technology stack in-house. This approach minimizes reliance on third-party aggregators or APIs, reducing the risk of disruptions and ensuring they have control over their infrastructure. The need for real-time, high-speed, and responsive systems makes it challenging to find existing solutions that meet their requirements.
In addition to that, Central Limit Order Books (CLOBs) tend to utilize liquidity more efficiently than Automated Market Makers (AMMs). CLOBs can adjust their quotes freely and concentrate liquidity around the market price, while AMMs spread their liquidity across a range of prices.
This also opens up opportunities for arbitrage, where traders would most frequently execute the opposite leg of the arbitrage on another CLOB, possibly on a centralized exchange (CEX). Professional market makers on CEXs could benefit from low fees and performant infrastructure as well. In fact, strong market-maker partnerships could attract an increasing number of firms to trade on exchange. There is a potential incentive for market makers to partner with validators on dYdX v4 to more competitively execute cross-venue arbitrage.
Additionally, there is another form of arbitrage that comes into play: regulatory arbitrage. While constrained in the U.S. and Canada, dYdX is accessible in many jurisdictions where competitors like Binance or other centralized exchanges are not. Not only that, but dYdX’s trading fees are generally lower than those of centralized competitors, particularly when considering token rewards.
The v4 update will further decentralize the orderbook and matching engine. It will also enable quick addition of new trading pairs through on-chain governance and token holders will receive a share of transaction-fee revenue, promoting stakeholder engagement. This becomes increasingly important considering that unlike most crypto projects dYdX has recently turned profitable. This is a rare feat in the crypto space and suggests sustainable growth.
Perpetual futures contracts, also known as perpetual swaps, are a type of derivative financial instrument that enables traders to speculate on the price movements of an underlying asset without needing to own the asset itself.
The concept of perpetual futures was introduced by economist Robert Shiller in 1992 as a way to provide derivatives markets for less liquid assets. However, it wasn’t until 2016, with the launch of the first live perpetual futures contracts on the cryptocurrency exchange BitMEX, that perpetuals gained significant traction. Since then, perpetual futures have become popular in the crypto market, offering high-leverage trading opportunities.
Perpetual futures cater to the demand for advanced trading products in the crypto market, allowing traders to take advantage of price volatility. The ability to hold positions indefinitely and the potential for high leverage make perpetual contracts appealing to active traders. They provide capital efficiency by enabling traders to take large positions with limited capital, maximizing potential returns. However, it’s important to note that higher leverage also increases the level of risk involved.
In traditional futures contracts, traders agree to buy or sell an asset at a fixed price on a specified future date. In contrast, perpetual contracts lack an expiration date, allowing traders to maintain their positions for an indefinite period. Instead of directly buying the underlying asset, traders use perpetual contracts to speculate on the asset’s future price movements.
To maintain a price close to the underlying asset price, perpetual contracts utilize a funding rate mechanism. This mechanism tracks the difference between the contract price and the index price (the underlying asset’s price) and adjusts periodically. If the contract price deviates from the index price, a funding rate is applied to incentivize traders on the profitable side to balance the market. This mechanism ensures price convergence and keeps the contract price in line with the index price.
Finally, trading in perpetual contracts involves leveraged collateral, enabling traders to access larger positions with less capital. However, this leverage increases the risk associated with trading. One significant risk is the potential for liquidation, which occurs when the value of a trader’s position falls below a certain threshold. In such cases, the position is forcefully closed at a loss, which can be substantial for highly leveraged positions. Proper risk management and understanding of market conditions are crucial for traders to navigate the potential risks and maximize profitability in perpetual futures trading.
Leverage trading, often known as margin trading, allows users to borrow funds, thereby trading with a larger capital base. This strategy offers the potential for amplified returns but also increases the risk of losses. Leverage trading enables traders to open larger positions using the capital in their trading accounts.
In traditional financial markets, leverage trading is typically executed through a margin account. This account permits traders to borrow funds from a broker, enabling them to take larger positions. To do this, traders must maintain a minimum balance in their margin account, which serves as collateral for the borrowed funds. If the value of their account falls below this minimum balance, the broker may issue a margin call. This requires the trader to deposit additional funds or sell some of their positions to reduce exposure and restore the account balance to the required level. Failing to meet the margin call can lead to the broker liquidating the trader’s positions to repay the outstanding debt.
it’s crucial to highlight that leverage trading comes with an elevated level of risk. This is because traders are utilizing borrowed funds that must be repaid, irrespective of whether the trade results in a profit or a loss. In the event that the market moves against the trader, losses can accumulate rapidly and may surpass the capital originally invested. This situation can trigger a margin call, which necessitates additional funds or the sale of positions to cover losses. If a trader is unable to meet the margin call, it can lead to a forced liquidation of their positions.
Given these inherent risks, it’s of paramount importance for traders to thoroughly assess their risk tolerance and adopt appropriate risk management strategies when engaging in leverage trading. These strategies can include setting stop-loss orders, diversifying their portfolio, and only using leverage they are comfortable with, among other risk mitigation techniques.
Suppose a trader has $100 in their account and wants to trade an ETH-USD position worth $1,000 with 10x leverage. They can use the $100 of their capital and borrow the remaining $900 from dYdX. If the position doubles in value to $2,000, the trader can close the position, returning the initial $900 to the exchange and earning the trader $1,100 in profit. If the position depreciates, the trader can close the position to limit their losses. In either case, the trader must repay the borrowed funds that were leveraged in the position.
Market makers and market takers are two different types of participants that play distinct roles in the buying and selling of assets in an exchange.
Market makers are individuals or entities that provide liquidity to the market by continuously quoting both bid (buy) and ask (sell) prices for a specific asset. They essentially act as intermediaries between buyers and sellers. Market makers commit to facilitating trades by being willing to buy or sell at the prices they quote.
Market takers are participants who accept the prices quoted by market makers and execute trades by accepting existing orders from the order book. They “take” liquidity from the market by accepting the available prices rather than providing liquidity themselves.
Market takers rely on the liquidity provided by market makers and other participants in the market. They are looking to quickly enter or exit positions and are willing to accept the prevailing market conditions.
dYdX was made available on iOS on May 10, 2022.
The app offers the same functionality and experience that is available on the website, but with the added convenience of trading on the phone.
dYdX operates a decentralized exchange for trading financial derivatives and perpetual futures. Hence, the exchange’s business model is based on charging trading fees to users. There are two types of trading fees: maker fees and taker fees.
With V4 and the dYdX chain, the protocol also earns revenue from staking fees. Staking is the process of locking up tokens in order to participate in the security and governance of the network. This way, dYdX users who stake $DYDX tokens are rewarded with a portion of the exchange’s trading fees.
In addition to trading fees and staking fees, dYdX also earns revenue from margin lending. Margin lending is a service that allows users to borrow funds to trade with leverage. dYdX charges interest on margin loans, which is another source of revenue for the exchange.
These are the current fee breakdowns for V3.
dYdX uses a maker-taker fee model for determining its trade fees. There are two types of orders on dYdX, being Maker and Taker orders.
| Level | From (30D Volume in USD) | To (30D Volume in USD) | Maker | Taker |
| 1 | $0 | $1M | 0.02% | 0.05% |
| 2 | $1M | $5M | 0.015% | 0.04% |
| 3 | $5M | $10M | 0.01% | 0.035% |
| 4 | $10M | $50M | 0.005% | 0.03% |
| 5 | $50M | $200M | 0% | 0.025% |
| VIP | $200M+ | – | -0.0085% | 0.02% |
Trading Fee Discounts:
These are the current fee breakdowns for v4.
All fees (trading fees denominated in $USDC and gas fees for DYDX-denominated transactions or USDC-denominated transactions) collected by the protocol are distributed to Validators and Stakers.
The community treasury was allocated 24.2% of the $DYDX token supply, amounting to 241,735,862 tokens. The initial allocation was 5.0% of the token supply amounting to 50,000,000 $DYDX, and 766,703 $DYDX vests in the community treasury each epoch.
These proposals include:
The funds of the community treasury are used for the following:
The vested balance of the treasury, along with other information, can be viewed in this link.
Starting in Epoch 26, 3,595,890 $DYDX will accrue in the Rewards Treasury each epoch and can be used by the dYdX community with a governance vote.
The Liquidity Module was wound down in DIP-14.
The Safety Module was wound down in DIP-17.
$DYDX is the protocol token, and the dYdX protocol is governed by its token holders.
The v4 protocol is designed with a need for a layer 1 protocol token, and this will be fulfilled with the $DYDX token. This way, $DYDX will be used for staking to validators as well as for the development of the ongoing governance of the chain.
The current token variants of $DYDX are as follows:
A total of 1 billion $DYDX tokens have been minted and will become accessible over five years, starting on August 3rd, 2021, at 15:00:00 UTC.
The initial five-year allocation of the total supply of $DYDX was as follows:
Due to several governance proposals passing, the current allocations are as follows:
Starting five years after launch, a maximum perpetual inflation rate of 2% per year may be utilized by governance to increase the supply of $DYDX, ensuring the community has the resources to continue the development and growth of the Protocol. Inflation must be enacted via a governance proposal and is capped at 2% per year.
Although the community allocation has been established as laid out above, $DYDX holders have full control via governance over how the community allocation is used going forward.
There are 2 out of 3 rewards available on dYdX:
Retroactive Mining Rewards
These rewards were given to past users of dYdX who completed certain trading milestones on the Protocol before Epoch 0 and were meant to reward historical dYdX users with a retroactive reward based on past usage and also incentivize historical dYdX users to trade on dYdX’s Layer 2 Protocol.
7.5% (75M $DYDX) of the token supply was initially meant to be distributed, but the unclaimed portions were transferred back to the community at Epoch 0. As a result, only 5.0% of the token supply (50,309,197 $DYDX) was distributed.
With the launch of Epoch 0, the distribution of these rewards was completed.
Trading Rewards
These rewards are given to traders based on fees paid, incentivizing all traders to use the protocol and accelerating market liquidity and overall product usage.
25.0% of the token supply (250M $DYDX) was initially allocated for trading rewards but has been reduced to 14.5% (144,693,506 $DYDX), due to DIP 16 and 20. Trading rewards distributed in a given epoch were reduced from 3,835,616 $DYDX to 2,876,712 $DYDX in Epoch 15, and from 2,876,712 $DYDX to 1,582,192 $DYDX in Epoch 21.
$DYDX will be distributed on a 28-day epoch basis over five years and is not subject to any vesting or lockups.
Liquidity Provider Rewards
These rewards are given to liquidity providers based on formulas that reward a combination of maker volume, uptime, two-sided depth, bid-ask spreads, and the number of markets supported, in order to improve two-sided liquidity and programmatically reward liquidity providers. Any Ethereum address can earn these rewards, subject to a minimum maker volume threshold of 0.25% of maker volume in the preceding epoch.
7.5% (75M $DYDX) of the token supply was initially allocated for LP rewards but has been reduced to 5.2% (52,458,925 $DYDX) due to DIP 24.
$DYDX will be distributed on a 28-day epoch basis over five years and are not subject to any vesting or lockups. 575,343 $DYDX will be distributed per epoch.
Rewards are measured by the following:
| Market | Max Spread vs Mid-Market (Bid and Ask) |
| BTC-USD | 20 bps |
| ETH-USD | 20 bps |
| Other perpetual markets | 40 bps |
| Market | Min Depth (Bid and Ask) |
| BTC-USD | $5000 |
| ETH-USD | $5000 |
| Other perpetual markets | $1000 |
dYdX grants holders the right to propose and vote on changes to the Protocol. dYdX governance is based on the AAVE governance contracts and supports voting based on DYDX token holdings.
Proposals must pass a given threshold and percent of yes votes based on the type of proposal.
These dYdX tokens can be used to make proposals or vote on governance proposals or be delegated to other Ethereum addresses.
There are 6 smart contracts at the core of dYdX Governance:
dYdX on-chain governance allows for:
There are four types of proposals with different parameters that affect the length and execution of a proposal, i.e. critical proposals that affect governance consensus require more voting time and a higher vote differential, whereas proposals affecting only protocol parameters require less voting time and can be quickly implemented. An executor must validate each type of proposal.
These include the following:
The initial timelock parameters are as follows:
The dYdX Governance Process is fueled by governance forums at https://dydx.forum/ and ratified through the dYdX Improvement Proposal (“DIPs”).
The process consists of multiple stages.
Stage 0. Forum Discussion
Anyone can sign up and set up a thread on any topic on dYdX’s Governance forums hosted at https://dydx.forum/. Community members are required to register using an email address or an Ethereum wallet.
Stage 1. (Off-chain) DRC Creation
Off-chain dYdX Request for Comments (DRCs) creation is the first step in the governance improvement process. Anyone can participate in the Governance Forum, create off-chain DRCs, and discuss improvements.
To create a DRC, use this template. The DRC should cover all the information of the potential final DIP.
At a minimum, DRCs must include:
Stage 2. DRC Discussion & Feedback
Once posted on the governance forum, all questions and comments should be addressed & taken into consideration, to further improve the DRC.
Stage 3. DRC Snapshot Polling
Snapshot polls serve two purposes: sentiment signaling for future on-chain DIPs and binding votes for variables controlled off-chain.
Once an off-chain DRC has a very rough consensus, a community member with more than 10,000 $DYDX proposing power can create an off-chain vote for the DRC on Snapshot. It is encouraged for the dYdX Community to create Snapshot polls on Mondays to increase visibility during the regular workweek.
Snapshot is a simple voting interface that allows users to signal sentiment off-chain. Votes on Snapshot are weighted by the voting power of the address used to vote.
For Snapshot polls related to sentiment signaling, the proposer will need to provide:
For decisions that don’t require an on-chain smart contract call, notably changes to the Trading and Liquidity Provider rewards formulas, Snapshot votes are considered the binding and final vote. The proposer will need to include the requirements above and provide:
The proposed change(s) will be implemented by dYdX Trading Inc. if the results of the Snapshot poll satisfy:
dYdX Trading Inc. will have up to 1 Epoch (28 days), an execution grace period, to implement changes from a successful Snapshot poll.
Note that proposals and votes are just signed messages, stored on IPFS, and available via the Commonwealth portal.
Stage 4. (On-chain) DIP Creation
When a rough consensus is reached, an on-chain DIP may be submitted by a community member who holds enough proposition power for the type of proposal. An on-chain DIP is initiated via a smart contract call. The proposal should be based on the winning outcome of the off-chain DIP voting on Snapshot and can consist of one or multiple actions, up to a maximum of 10 actions per proposal.
A DIP creation is subject to a minimum number of tokens held/delegated required for an account. A Timelock executor must be specified when a proposal is created. The initial parameters are as follows (and can be modified by governance):
| Parameter | Description | Short Timelock Executor | Merkle-Pauser Executor | Long Timelock Executor | Starkware Executor |
| Proposal Threshold | Minimum tokens held/delegated to create proposal | 0.5% of total supply | 0.5% of total supply | 2% of total supply | 0.5% of total supply |
Stage 5. (On-chain) DIP Voting
After an On-Chain DIP is created, the proposal enters a pending state for a period defined by the Voting Delay, which is currently configured to 6570 blocks or approximately 1 day (assuming 13.2 seconds per block). In other words, user snapshots are recorded 1 day after the DIP is created, at which point the proposal transitions to an active state.
After the Voting Delay, the Voting Period is activated. The voting period length depends on the proposal type.
The following chart shows a DIP state flowchart:
After a DIP is created on-chain it is subject to a Voting Delay, Voting Period, Minimum Quorum, and a minimum Vote Differential. The initial parameters are as follows:
| Parameter | Description | Short Timelock Executor | Merkle-Pauser Executor | Long Timelock Executor | Starkware Executor |
| Voting Delay | Number of Ethereum blocks to wait before voting on a proposal may begin after a proposal is submitted | 6,570 blocks | 6,570 blocks | 6,570 blocks | 6,570 blocks |
| Voting Period* | Length of time for which proposals are available to be voted upon | 4 days | 2 days | 10 days | 4 days |
| Minimum Quorum | Minimum yes votes for a DIP proposal to pass | 2% of total supply | 1% of total supply | 10% of total supply | 2% of total supply |
| Vote Differential | Required yes-no gap for a DIP proposal to pass | 0.5% of total supply | 0.5% of total supply | 10% of total supply | 0.5% of total supply |
Only the voting delay can be modified by governance, and it can only be changed to values in between (inclusive) the minimum and maximum delay. The voting period, minimum quorum, and vote differential can’t be changed.
Stage 6. Proposal Queuing & Execution
After a DIP has passed, any address can call the queue method to move the proposal into the timelock queue. A DIP can only be queued if it has passed.
| Parameter | Description | Short Timelock Executor | Merkle-Pauser Executor | Long Timelock Executor | Starkware Executor |
| Timelock Delay* | After a proposal passes and is queued, delay before the proposal is executed | 2 days | 0 days | 7 days | 2-9 days |
| Execution Grace Period* | The time after which a proposal becomes executable, during which it must be executed. | 7 days | 7 days | 7 days | 7 days |
| Minimum Timelock Delay* | Minimum delay before a proposal is executed (after queuing) | 1 day | 0 days | 5 days | 4 days |
| Maximum Timelock Delay* | Maximum delay before a proposal is executed (after queuing) | 7 days | 1 day | 21 days | 21 days |
As soon as the voting period ends and a proposal has succeeded, anyone can call a queue to begin the timelock delay.
For the Starkware priority timelock executor, it has a priority period of 7 days out of the 9-day timelock delay. This means that after 9 days anyone can execute a proposal, but within days 2-9 (the priority period) Starkware has the option to execute the proposal.
In practical terms, it’s:
Stage 7. (Optional) Proposal Cancellation
At any point in a DIP lifecycle, the proposer can cancel the DIP. A proposal can be canceled by anyone before it is executed if the proposer does not have sufficient proposition power at the current block.
The Protocol is governed and upgraded by $DYDX holders and delegates.
There are two powers associated with each $DYDX token:
$DYDX holders receive governance powers proportionally to their sum of owned and delegated tokens at a given block.
The governance module for dYdX Chain (v4) was introduced on June 23, 2023.
dYdX Chain will utilize the standard x/gov module within the Cosmos SDK. The module enables Cosmos SDK-based blockchain to support an on-chain governance system, where holders of the native staking token can vote on proposals on a 1 token 1 vote basis.
Holders, via the governance process, will be able to alter the standard parameters across a variety of modules within the Cosmos SDK.
In addition, a non-exhaustive list of parameters that are adjustable includes:
Compared to governance in dYdX v3, there are several notable differences in how governance works on the dYdX Chain:
Smart Contract Audit Report – 2021 – PeckShield
V4 Chain Audit, Security Audit Report – September 15, 2023 – Informal Systems
V4 Chain Audit, Security Audit Report – September 28, 2023 – Informal Systems
dYdX has a bug bounty program for its dYdX Chain.
The rewards are as listed:
The vulnerability disclosure policy helps to ensure the security of dYdX by allowing users to report vulnerabilities found, via email, and including the following:
Scope
Any vulnerability not previously disclosed by dYdX or their independent auditors in their reports.
Guidelines
Reporters are required to adhere to the following:
On November 27th, 2021, a critical vulnerability was discovered in the proxy smart contract responsible for handling deposits to the dYdX exchange. This vulnerability allowed an attacker to steal ERC-20 balances up to the approved amount by manipulating contract calls. The dYdX team took immediate action to address the issue and protect user funds.
Upon confirming the bug, the dYdX team collaborated with external experts to execute a white-hat hack, rescuing approximately $2 million worth of vulnerable user funds. These funds were securely transferred to a non-custodial escrow contract, ensuring only the original owners can access them. Affected users were promptly notified and advised to revoke all approvals on the contract and avoid receiving ERC-20 tokens until completing this step.
A total of 730 addresses with allowances were identified as affected, with 180 of them holding funds directly at risk during the exploit. As of December 8th, all but 91 of the original affected addresses, which currently hold no exploitable funds, have revoked their allowances. The dYdX team continues to monitor these wallets to safeguard user funds. Users who have not yet revoked their allowances are strongly advised to take immediate action.
The smart contract containing the vulnerability was a “currency converter” proxy contract designed to allow deposits to dYdX from a broad range of currencies. The contract works by converting a user’s funds to $USDC and depositing them to the dYdX exchange in a single transaction. The implementation was based on a previous smart contract that was used with an earlier version of the dYdX exchange. The old contract uses a standardized “exchange wrapper” interface to support calls to various decentralized spot exchanges.
The new contract intended to perform swaps using 0x API. Quotes returned from the 0x /swap/v1/quote endpoint included calldata that can be submitted to the 0x contract to execute a trade.
Note that both the exchange and data parameters are untrusted: they are provided off-chain by 0x API and are supplied to the smart contract by the client/user. For dYdX’s use case, this is safe when the call to the 0x contract is made via the exchange wrapper interface.
The problem with the new design is that a single smart contract has both an ERC-20 approval set by the user, as well as the ability to make an arbitrary smart contract, calls to an untrusted address with untrusted calldata. This allows an attacker to steal an ERC-20 balance, up to the approved amount, by passing in parameters with exchange equal to the ERC-20 token address, and data encoding a call to transferFrom() transferring funds to the attacker.
The LinkedIn page lists 77 employees. Some of the notable employees include:
The dYdX Foundation is an independent not-for-profit foundation headquartered in Zug, Switzerland. The Council consists of Arthur Cheong, Rebecca Rettig, and Markus Spillman.
It was introduced on August 3, 2023, with the purpose of supporting and growing every aspect, technical or otherwise, of the current and future implementations of the dYdX Protocol, including but not limited to the related ecosystem.
The mandate empowers the Foundation to do the following:
As the dYdX Foundation assists with the development and growth of the dYdX ecosystem and governance-related matters, dYdX Trading’s core development team will spend its future time focused on, amongst other things, decentralizing the order book and matching engine components. Although a decentralized orderbook and matching engine will result in modifications, there is no expectation that it will enhance functionality. Instead, it will have the benefit of creating censorship resistance in all aspects of the protocol.
The dYdX Foundation does not have a profit-making purpose and does not seek any profits in general. Meanwhile, dYdX Trading will continue to charge maker-taker fees tied to trade volume, which will cover transaction fees for trades, earn revenue, and incentivize more liquidity.
By fostering decentralized governance and empowering traders with powerful, transparent, and open advanced financial products, the dYdX Foundation will help push dYdX towards community-led growth, development, and self-sustainability.
There have been 4 rounds of raises for dYdX, including a seed round. The total amount raised is $87M.
The dYdX Grants program (DGP) officially launched on January 12, 2022.
The long-term goal is for the grants program to support the creation and development of a self-sufficient development program that builds and maintains itself. The execution plan can be broken down into 3 phases:
Phase 1: Sourcing and Recruiting (0 – 6 months in)
In this phase, the primary focus was on sourcing new talent through one-time projects that make small but meaningful contributions to the community. The funding is much broader with low-hanging grants accessible to a large pool of community members and external contributors.
Expected output from these grants is less predictable as the team has to take risks with new contributors, of which few will become long-term contributors. Admittedly, funding in this phase will as a result not be the most capital efficient. Nonetheless, this contributor churn is a necessary building block for the growth trajectory.
This phase acts as a funnel for long-term 10x contributor recruitment while also benefiting the community with smaller one-off projects that tackle immediate needs. The program should not be judged on these initial RFPs however, it should be judged on its ability to attract future talent.
Phase 2: Deploying (6 months – 2 years out)
Having identified talented contributors, the program can now begin to shift its attention towards deploying these qualified, proven teams to build function-specific working groups around dYdX growth. They can expect Grants to move away from one-off individual projects to groups building around dedicated needs and providing individual community grants where applicable.
This working group structure split across functions (e.g. Treasury, Marketing, Tooling, etc..) will help streamline projects with qualified leaders taking ownership of growing the program. The productivity and capital efficiency of the program are expected to rise significantly as groups focus on their product needs with the shared goal of protocol growth.
Phase 3: Self-Governing (2 – 5 years out)
Autonomy at last. Assuming the program is successful, dYdX should expect to see a fully autonomous organization of dedicated working groups led by qualified teams acting on behalf of the community to grow and maintain the protocol. The community will have ownership over teams, treasury allocations, committees, and other grand scheme functions, while the teams themselves focus on building their specific functions with grants, hiring, projects, and more.
The program evolves into a collective organization of teams governed by the community. And through this dYdX reaches the final goal: An autonomous organization working towards the betterment of dYdX.
Application
Applicants can submit their interest via an application form, which will only be shared with the Grants lead and members of the committee. The Lead will contact you directly if the application is successfully considered for a Grant. Some of the completed funded grants include:
Hedgies were introduced on January 26, 2022.
They were a free-to-mint collection of 4,200 unique avatar NFTs on Ethereum distributed to voters, traders, and the community at large. They provided a 1 tier increase on dYdX’s fee tier discount system for holders, which has since been wound down on September 29, 2023, with Hedgies holders only being eligible for a 3% fee discount.
Initially, 2,443 were distributed during the initial phase, according to the following:
The remaining 1757 Hedgies would be distributed to traders on the dYdX exchange over 2 years.
dYdX provides a license specific to dYdX Trading Inc. that grants certain rights and imposes restrictions on the access, copying, and use of the code in their repository.
