Skip to content

Protocol v1.0.0

Compare
Choose a tag to compare
@github-actions github-actions released this 24 Oct 01:52
bd3ff30

Protocol v1.0.0 Release Notes

Highlights

We're excited to announce the dYdX Chain software’s v1.0.0 release, which is the first production-ready version of the protocol. This release focuses on overall chain health and stability, and introduces the primary function of the chain: the central limit order book (CLOB).

There are many configurable parameters for this chain, and we have provided helper scripts to generate sample module parameters for genesis. See the annotated proto files for more details on what each parameter does.

Central Limit Order Book (CLOB)

The central limit order book (CLOB) is the core of dYdX Chain. The CLOB facilitates performant trading on a configurable set of perpetual markets, utilizing built-in price oracles to poll from customizable external price sources. Given the complexity of the core trading flows, the clob module is supported by various other modules. See below for details on what those supporting modules are and how they operate.

What's New?

In this inaugural release, we will briefly describe the purpose of each component of our Cosmos-SDK-based application. In future releases, a detailed changelog will instead be included to summarize more granular additions or changes to the application.

We've created the following custom modules to support our application's specific needs:

  • assets — Defines assets used for trading.
  • blocktime — Records metadata based on prior blocktime. Currently tracks previous block blocktime and chain downtime.
  • bridge — Responsible for processing events from a configured Ethereum contract. It communicates with the bridge daemon to learn about recent events.
  • clob — Contains business logic related to the in-memory order book, order processing, liquidations, and deleveraging. Contains the bulk of the trading flow logic.
  • delaymsg— Enables storing messages to be triggered at a future block. Used by x/bridge and x/feetiers and x/gov related functionalities.
  • epochs — Allows for the definition of recurring timers which can be used to perform some business logic on a cadence. Currently used by x/perpetuals for funding purposes.
  • feetiers — Configures fee tiers which enable collecting different fees based on individual user trading volume.
  • perpetuals — Contains logic related to perpetual futures products. It stores existing perpetuals and their configurations which are active on the protocol. It is responsible for computing funding samples, updating the funding index, and computing margin requirements for perpetuals.
  • prices — Contains functionality related to oracle prices. It stores the canonical oracle price for all markets, as well as messages for updating the oracle prices. It communicates with the pricefeed daemon to learn about the latest index prices.
  • rewards — Distributes trading rewards to users from a configurable treasury account.
  • sending — Allows for sending assets between subaccounts, as well as between subaccounts and bank.
  • stats — Records statistics such as user and global trading volume.
  • subaccounts — Contains functionality to support subaccounts. Every account (as defined in auth) can contain 128 subaccounts which can contain assets and perpetuals, and are individually collateralized. This module also contains logic to compute net collateral and margin requirements of a subaccount.
  • vest — Responsible for vesting of rewards to a configurable treasury account.

Our application also contains a set of "daemons" (actually long-running goroutines). These daemons run in the background and communicate information to modules through RPC. There are several flags that can tweak the operation of these daemons.:

  • bridge daemon — Polls an Ethereum node endpoint for updates to a contract and sends any updates to the x/bridge module.
  • liquidations daemon — Monitors the margining of all accounts and notifies the x/clob module if any are marked for liquidation.
  • pricefeed daemon — Polls external sources for price information and relays it to the x/price module.

Our application utilizes the following default modules from Cosmos SDK:

  • auth — Responsible for defining the base transaction and account types for dYdX chain. Also houses logic for replay protection, signature verification, etc.
  • bank — Responsible for defining the concept of coins (tokens in Cosmos SDK parlance) and balances for accounts. Defines messages for transferring coins between accounts.
  • capability — Dependency of ibc.
  • consensus — Allows modification of ABCI consensus params.
  • crisis — Responsible for detecting and handling critical failures in the network. Examples of such failures include double spends, invalid blocks, and other consensus failures that could cause the network to fork. We currently don’t make use of this module directly, but may in the future.
  • distribution — Responsible for implementing various distribution schemes for reward payouts to validators, delegators, and other stakeholders.
  • evidence — Provides evidence of faults and misbehavior such as double-signing.
  • feegrant — Enables granting fee allowances and usage of said fees.
  • gov — Enables governance functionality for the chain, including proposals, voting, and parameter changes.
  • ibc — Provide support for the IBC (Inter-Blockchain Communication) protocol. dYdX intends to use this functionality primary for cross-chain asset transfers.
  • params (deprecated) — Unused except for an ibc dependency. This will be removed in a future version once ibc is fully migrated.
  • slashing — Removes (jails) validators from the validator set when they fail to vote or propose on blocks for an extended period of time.
  • staking — Provides a mechanism for delegators to stake their tokens with validators, and for validators to compete for block rewards based on their stake.
  • upgrade — Enables on-chain upgrades to the protocol and modules.

Go version

1.21