# dYdX Documentation

## Docs

- [Open Source Repositories](/repositories): Please find the open source repositories on our [GitHub](https://github.com/dydxprotocol):
- [Third-Party Integrations](/third-party-integrations): QuantConnect is a leading algorithmic trading platform that empowers developers and traders to research, backtest, and deploy quantitative strategies across various asset classes. The [integration with dYdX](https://qnt.co/dydx-docs) enables members to live trade Crypto Futures on the dYdX decentralized exchange from within the QuantConnect platform. QC's battle-tested infrastructure provides a stable environment that handles all the communication with the dYdX API, so you can focus on researching new strategies and monitoring your live algorithms. The LEAN engine that powers QC has an extensive suite of features to equip you with all the AI models, indicators, and dataset you'll need to take your trading to the next level with just a few lines of code.
- [TODO](/todo)
- [Faucet API](/faucet-client/intro)
- [Indexer API](/er-client/index): The Indexer is a high-availability system designed to provide structured data. It serves both over its [HTTP/REST API](/indexer-client/http) for spontaneous requests and over its [WebSockets API](/indexer-client/websockets) for continuous data streaming.
- [Connecting to dYdX](/interaction/endpoints): dYdX provides two networks for trading: a **mainnet**, and a **testnet**:
- [Guide](/interaction)
- [Wallet Setup](/interaction/wallet-setup): To manage your accounts, issue orders, and perform other operations that are required to be signed, a Wallet is required. To instantiate a Wallet, you must first have your associated **mnemonic**.
- [Noble API](/noble-client/intro)
- [Node API](/node-client): Nodes are the servers that manage and maintain the dYdX network. Trading transactions are broadcast to these, which then are evaluated and eventually comitted into state by the underlying consensus mechanim. It serves both a [Private API](/node-client/private), which receives transactions signed by the user, and a [Public API](/node-client/public), available for different data queries. The [Permissioned Keys API](/node-client/authenticators) is also available.
- [Network Constants](/nodes/network-constants): **mainnet**: `dydx-mainnet-1`
- [Resources](/nodes/resources): mainnet: [https://github.com/dydxopsdao/networks/tree/main/dydx-mainnet-1](https://github.com/dydxopsdao/networks/tree/main/dydx-mainnet-1)
- [Security](/policies/security): The protocol has been audited by the [Informal Systems](https://informal.systems/) team. Additional audits are planned as more protocol code is developed.
- [Terms-of-Use & Privacy Policy](/policies/terms): By using, recording, referencing, or downloading (i.e., any “action”) any information contained on this page or in any dYdX Trading Inc. ("dYdX") database or documentation, you hereby and thereby agree to the [v4 Terms of Use](https://dydx.exchange/v4-terms) and [Privacy Policy](https://dydx.exchange/privacy) governing such information, and you agree that such action establishes a binding agreement between you and dYdX.
- [Indexer Deep Dive](/concepts/architecture/indexer): A good way to think about the Indexer is as similar to Infura or Alchemy’s role in the Ethereum ecosystem. However, unlike Infura/Alchemy, and like everything else in dYdX Chain, the Indexer is completely open source and can be run by anyone!
- [OEGS](/concepts/architecture/oegs): The Order Entry Gateway represents the next step in dYdX’s multi-stage performance evolution:
- [Intro to dYdX Chain Architecture](/concepts/architecture/overview): dYdX Chain (sometimes referred to as "v4") has been designed to be completely decentralized end-to-end. The main components broadly include the protocol, the Indexer, and the front end. Each of these components are available as open source software. None of the components are run by dYdX Trading Inc.
- [Onboarding FAQs](/concepts/onboarding-faqs): <summary>1. How does the network work? </summary>
- [Account](/types/account): `address`: [Address]
- [AccountWithParentSubaccountNumber](/types/account_with_parent_subaccount_number): `address`: [Address]
- [Address](/types/address): An address of an account, represented by a string.
- [AddressResponse](/types/address_response): `subaccounts`: [SubaccountResponseObject] ⛁
- [ApiOrderStatus](/types/api_order_status): `ApiOrderStatus` is an enum consists of the following values
- [ApiTimeInForce](/types/api_time_in_force): `ApiTimeInForce` is an enum consists of the following values
- [AssetId](/types/asset_id): A string identifier representing a specific asset (e.g., "USDC"). Used to uniquely reference assets within the system.
- [AssetId](/types/asset_id_node): A `u32` integer identifier representing a specific asset (e.g., USDC, dYdX token).
See more on [Perpetuals and Assets](/concepts/trading/assets).
- [AssetPosition](/types/asset_position): `asset_id`: [u32]
- [AssetPositionResponseObject](/types/asset_position_response_object): `symbol`: [Symbol]
- [AssetPositionSubaccountMessage](/types/asset_position_subaccount_message): Update sub-message received on the `v4_subaccounts` channel.
- [AssetPositionsMap](/types/asset_positions_map): Key: [Ticker]
- [Authenticator](/types/authenticator): `Authenticator` is an enum represented by the following values
- [Bad Request](/types/bad-request): [https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.1](https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.1)
- [BaseAccount](/types/base_account): `address`: string
- [BigDecimal](/types/big_decimal): A high-precision decimal number type used to represent values requiring exact precision, such as prices or quantities. Typically serialized as a string to avoid precision loss.
- [Block](/types/block): \`header: [Header]
- [BlockHeightInitialMessage](/types/block_height_initial_message): Initial message received on the `v4_block_height` channel.
- [BlockHeightUpdateMessage](/types/block_height_update_message): Update message received on the `v4_block_height` channel.
- [BlockId](/types/block_id): `hash`: [u8] ⛁
- [BridgeEvent](/types/bridge_event): `id`: [u32]
- [BroadcastMode](/types/broadcast_mode): `BroadcastMode` is an enum consists of the following values:
- [BuilderCodeParameters](/types/builder_code_parameters): Represents the metadata for the partner or builder of an order. This allows them to specify a fee for providing their service which will be paid out in the event of an order fill.
- [CandleResolution](/types/candle_resolution): `CandleResolution` is an enum represented by the following values
- [CandleResponseObject](/types/candle_response_object): `ticker`: [Ticker]
- [CandlesInitialMessage](/types/candles_initial_message): Initial message received on the `v4_candles` channel.
- [CandlesUpdateMessage](/types/candles_update_message): Update message received on the `v4_candles` channel.
- [ClientId](/types/client_id): `ClientId` is represented by [u32]
- [ClientMetadata](/types/client_metadata): A wrapper around a [u32] value used to attach optional, client-defined metadata to orders or fills. Useful for tracking or categorizing actions on the client side.
- [ClobPair](/types/clob_pair): `id`: [u32]
- [ClobPairId](/types/clob_pair_id): A CLOB (Central Limit Order Book) Pair ID refers to the identifier for a specific order book (spot, perpetual, etc.). It uniquely identifies where liquidity rests, tick sizes, step sizes, and other trading configuration for that product.
- [ClobPairStatus](/types/clob_pair_status): `ClobPairStatus` is an enum consists of the following values:
- [Coin](/types/coin): `denom`: string
- [Commission](/types/commission): `commission_rates`: [CommissionRates]
- [CommissionRates](/types/commission_rates): `rate`: string
- [Commit](/types/commit): `height`: [i64]
- [CommitSig](/types/commit_sig): `block_id_flag`: [i32]
- [ComplianceReason](/types/compliance_reason): `ComplianceReason` is an enum consists of the following values
- [ComplianceResponse](/types/compliance_response): `restricted`: bool
- [ComplianceReason](/types/compliance_status): `ComplianceReason` is an enum consists of the following values
- [ComplianceV2Response](/types/compliance_v2_response): `status`: [ComplianceStatus]
- [Consensus](/types/consensus): `block`: [u64]
- [Cosmos](/types/cosmos): // TODO
- [Data](/types/data): `txs`: [u8] ⛁⛁
- [DateTime](/types/date_time): A a timestamp type representing a specific date and time in Coordinated Universal Time (UTC), with nanosecond precision.
- [DelayedCompleteBridgeMessages](/types/delayed_complete_bridge_messages): `message`: [MessageCompleteBridge]
- [Delegation](/types/delegation): `delegator_address`: string
- [DelegationResponse](/types/delegation_response): `delegation`: [Delegation]
- [Denom](/types/denom): `Denom` is an enum consists of the following values
- [Description](/types/description): `moniker`: string
- [EquityTierLimit](/types/equity_tier_limit): `usd_tnc_required`: [u8] ⛁
- [EquityTierLimitConfiguration](/types/equity_tier_limit_configuration): `short_term_order_equity_tiers`: [EquityTierLimit] ⛁
- [Evidence](/types/evidence): `sum`: [EvidenceSum]
- [EvidenceList](/types/evidence_list): `evidence`: [Evidence] ⛁
- [EvidenceSum](/types/evidence_sum): `EvidenceSum` is an enum consists of the following values:
- [FillId](/types/fill_id): A wrapper around a String that uniquely identifies a specific fill event.
- [FillResponseObject](/types/fill_response_object): Represents the details of a trade fill, including size, price, market information, and metadata related to the order and subaccount.
- [FillSubaccountMessage](/types/fill_subaccount_message): `id`: [`FillId`]
- [FillType](/types/fill_type): An enum representing the origin or nature of a fill. Possible string values are:
- [FundingPaymentResponseObject](/types/funding_payment_response_object): Represents the details of a funding payment, including payment amount, funding rate, position information, and metadata related to the perpetual market and subaccount.
- [FundingPaymentsResponseObject](/types/funding_payments_response_object): Represents a paginated response containing funding payment data for a subaccount or parent subaccount.
- [GasInfo](/types/gas_info): `gas_wanted`: [u64]
`gas_used`: [u64]
- [GetNodeInfoResponse](/types/get_node_info_response): `default_node_info`: [::tendermint\_proto::p2p::DefaultNodeInfo][::tendermint_proto::p2p::DefaultNodeInfo]
`application_version`: [VersionInfo]
- [GoodTilOneof](/types/good_til_oneof): `GoodTilOneof` is an enum consists of the following values
- [Header](/types/header): `version`: [Consensus]
- [Height](/types/height): A block number representing a specific point in the blockchain's history.
- [HeightResponse](/types/height_response): `height`: [Height]
- [HistoricalBlockTradingReward](/types/historical_block_trading_reward): `trading_reward`: [BigDecimal]
- [HistoricalFundingResponseObject](/types/historical_funding_response_object): `ticker`: [Ticker]
- [HistoricalTradingRewardAggregation](/types/historical_trading_reward_aggregation): `trading_reward`: [BigDecimal]
- [i32](/types/i32): signed integer
- [i64](/types/i64): signed 64 bit integer
- [KeyPair](/types/key_pair): `key`: string
- [Liquidity](/types/liquidity): An enum indicating the liquidity role of the fill. Possible string values are:
- [MarketMapperRevShareDetails](/types/market_mapper_rev_share_details): `expiration_ts`: int
- [MarketPrice](/types/market_price): `id`: [u32]
- [Market Type](/types/market_type): An enum indicating the type of market, with possible case-insensitive string values:
- [MarketsInitialMessage](/types/markets_initial_message): Initial message received on the `v4_markets` channel.
- [MarketsUpdateMessage](/types/markets_update_message): Update message received on the `v4_markets` channel.
- [MegavaultOwnerSharesResponse](/types/megavault_owner_shares_response): `address`: string
- [MessageCompleteBridge](/types/message_complete_bridge): `authority`: string
- [Metadata](/types/metadata): `Metadata` is an enum consists of the following values
- [Module](/types/module): `path`: string
`version`: string
`sum`: string
- [Not Found](/types/not-found): [https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.4](https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.4)
- [NumShares](/types/num_shares): `num_shares`: [u8] ⛁
- [OK](/types/ok): [https://datatracker.ietf.org/doc/html/rfc7231#section-6.3.1](https://datatracker.ietf.org/doc/html/rfc7231#section-6.3.1)
- [OraclePriceMarket](/types/oracle_price_market): `oraclePrice`: [`Price`]
- [Order](/types/order): Order represents a single order belonging to a `Subaccount` for a particular `ClobPair`.
- [OrderBatch](/types/order_batch): `clob_pair_id`: [u32]
`client_ids`: [u32] ⛁
- [OrderBookResponseObject](/types/order_book_response_object): `bids`: List of [OrderbookResponsePriceLevel]
- [OrderbookResponsePriceLevel](/types/order_book_response_price_level): `price`: [Price]
- [OrderFlags](/types/order_flags): `OrderFlags` is an enum represented by the following values
- [OrderId](/types/order_id): A string value that uniquely identifies a specific order. Used to track and reference orders within the system.
- [OrderId](/types/order_id_obj): `subaccount_id`: [SubaccountId]
- [OrderMarketParams](/types/order_market_params): `atomic_resolution`: [i32]
- [OrderResponseObject](/types/order_response_object): `client_id`: [ClientId]
- [OrderRouterRevShare](/types/order_router_rev_share): `address`: string
- [OrderSide](/types/order_side): An enum representing the direction of an order. Possible string values are:
- [OrderStatus](/types/order_status): `OrderStatus` is an enum consists of the following values
- [OrderSubaccountMessage](/types/order_subaccount_message): Update sub-message received on the `v4_subaccounts` channel.
- [OrderType](/types/order_type): An enum specifying the type of order to be placed or processed. Possible string values include:
- [OrdersInitialMessage](/types/orders_initial_message): Initial message received on the `v4_orderbook` channel.
- [OrdersInitialMessage](/types/orders_update_message): Update message received on the `v4_orderbook` channel.
- [PageRequest](/types/page_request)
- [ParentSubaccountNumber](/types/parent_subaccount_number): The value is represented by [u32].
- [ParentSubaccountResponseObject](/types/parent_subaccount_response_object): `address`: [Address]
- [ParentSubaccountTransferResponse](/types/parent_subaccount_transfer_response): `transfers`: [ParentSubaccountTransferResponseObject] <Array />
- [ParentSubaccountTransferResponseObject](/types/parent_subaccount_transfer_response_object): `id`: [TransferId]
- [ParentSubaccountsInitialMessage](/types/parent_subaccounts_initial_message): Initial message received on the `v4_parent_subaccounts` channel.
- [ParentSubaccountsUpdateMessage](/types/parent_subaccounts_update_message): Update message received on the `v4_parent_subaccounts` channel.
- [PartSetHeader](/types/part_set_header): `total`: [u32]
- [Perpetual](/types/perpetual): `params`: [PerpetualParams]
- [PerpetualClobMetadata](/types/perpetual_clob_metadata): `perpetual_id`: [u32]
- [PerpetualFeeTier](/types/perpetual_fee_tier): `name`: string
- [PerpetualMarket](/types/perpetual_market): `atomicResolution`: [i32]
- [PerpetualMarketMap](/types/perpetual_market_map): Key-value pair of [Ticker] and [PerpetualMarket] where [Ticker] is the `key`.
- [PerpetualMarketStatus](/types/perpetual_market_status): `PerpetualMarketStatus` is an enum represented by following values
- [PerpetualMarketType](/types/perpetual_market_type): `PerpetualMarketType` is an enum consists of the following values
- [PerpetualParams](/types/perpetual_params): `id`: [u32]
- [PerpetualPosition](/types/perpetual_position): `perpetual_id`: [u32]
- [PerpetualPositionResponseObject](/types/perpetual_position_response_object): `market`: [Ticker]
- [PerpetualPositionStatus](/types/perpetual_position_status): A `PerpetualPositionStatus` is an enum having one of the following string in case insensitive manner
- [PerpetualPositionSubaccountMessage](/types/perpetual_position_subaccount_message): Update sub-message received on the `v4_subaccounts` channel.
- [PerpetualPositionsMap](/types/perpetual_positions_map): Key: [Ticker]
- [PnlTickId](/types/pnl_tick_id): `PnlTickId` is represented by `string`.
- [PnlTickInterval](/types/pnl_tick_interval): `PnlTickInterval` is an enum consists of the following values
- [PnlTicksResponseObject](/types/pnl_ticks_response_object): `blockHeight`: [Height]
- [PositionSide](/types/position_side): An enum representing the direction of a position, with possible case-insensitive string values:
- [PositionStatus](/types/position_status): A PositionStatus is an enum having one of the following string in case insensitive manner
- [Price](/types/price): A [BigDecimal] value that is representing the execution price of a trade. Uses high-precision decimal format to ensure accuracy in financial calculations.
- [Quantity](/types/quantity): A numeric value representing the amount of an asset.
- [QueryMarketMapperRevShareDetailsResponse](/types/query_market_mapper_revenue_share_details_response): `details`: [MarketMapperRevShareDetails]
- [QueryMarketMapperRevenueShareParamsResponse](/types/query_market_mapper_revenue_share_params_response): `params`: [MarketMapperRevenueShareParams]
- [QueryMegavaultOwnerSharesResponse](/types/query_megavault_owner_shares_response): `address`: `string`
- [QueryMegavaultWithdrawalInfoResponse](/types/query_megavault_withdrawal_info_response): `shares_to_withdraw`: [NumShares]
`expected_quote_quantums`: [u8] ⛁
`megavault_equity`: [u8] ⛁
`total_shares`:
- [QueryOrderRouterRevShareResponse](/types/query_order_router_revenue_share_response): `order_router_rev_share`: [OrderRouterRevShare]
- [QueryUnconditionalRevShareConfigResponse](/types/query_unconditional_revenue_share_config_response): `config`: [UnconditionalRevShareConfig] ⛁
- [RecipientConfig](/types/recipient_config): `address`: string
- [RewardParams](/types/rewards_params): `treasury_account`: string
- [ShareUnlock](/types/share_unlock): `shares`: [NumShares]
- [SparklineResponseObject](/types/sparkline_response_object): `SparklineResponseObject` is a key-value pair of [Ticker] and List of [BigDecimal]
- [SparklineTimePeriod](/types/sparkline_time_period): `SparklineTimePeriod` is an enum consists of the following values
- [SpotClobMetadata](/types/spot_clob_metadata): `base_asset_id`: [u32]
- [String](/types/string): String
- [Subaccount](/types/subaccount): `address`: [Address]
- [SubaccountId](/types/subaccount_id): `SubaccountId` is represented by `string`.
- [SubaccountInfo](/types/subaccount_info): `id`: [SubaccountId]
- [SubaccountNumber](/types/subaccount_number): A [u32] integer used to identify a specific subaccount within a main account.
- [SubaccountResponseObject](/types/subaccount_response_object): `assetPositions`: [AssetPositionsMap]
- [SubaccountsInitialMessage](/types/subaccounts_initial_message): Initial message received on the `v4_subaccounts` channel.
- [SubaccountsUpdateMessage](/types/subaccounts_update_message): Update message received on the `v4_subaccounts` channel.
- [Symbol](/types/symbol): A string identifier representing a trading pair or asset (e.g., "BTC-USD").
- [Ticker](/types/ticker): A Ticker is a pair of currency like "BTC-USD", represented by a string.
- [Time in Force](/types/time_in_force): An enum which indicates how long an order will remain active before it is executed or expires.
- [TimeResponse](/types/time_response): `iso`: [DateTime in UTC]
- [Timestamp](/types/timestamp): `seconds`: [i64]
- [Tokenized](/types/tokenized): `denom`: [Denom]
`coin`: [Coin]
- [TradeId](/types/trade_id): `TradeId` is represented by `string`
- [TradeResponseObject](/types/trade_response_object): `id`: [TradeId]
- [TradeType](/types/trade_type): `TradeType` is an enum represented by the following values
- [TradeUpdate](/types/trade_update): `id`: [`TradeId`]
- [TradesInitialMessage](/types/trades_initial_message): `trades`: [`TradeResponseObject`] <Array />
- [TradesUpdateMessage](/types/trades_update_message): Update message received on the `v4_trades` channel.
- [TradingPerpetualMarket](/types/trading_perpetual_market): `atomicResolution`: [`i32`] <Opt />
- [TradingRewardAggregationPeriod](/types/trading_reward_aggregation_period): A `TradingRewardAggregationPeriod` is an enum having one of the following string
- [TradingRewardSubaccountMessage](/types/trading_reward_subaccount_message): Update sub-message received on the `v4_subaccounts` channel.
- [TransferResponseObject](/types/transfer_response_object): `id`: string
- [TransferSubaccountMessageContents](/types/transfer_subaccount_message): Update sub-message received on the `v4_subaccounts` channel.
- [TransferType](/types/transfer_type): TransferType is an enum having one of the following value
- [TwapParameters](/types/twap_parameters): When using TWAP parameters, the `OrderFlags` value must be set to 128 (TWAP) on `OrderId.OrderFlags` in the order placement message.
- [Tx](/types/tx): `Tx` is represented by binary/byte data.
- [TxHash](/types/tx_hash): `TxHash` is represented by a string.
- [TxOptions](/types/tx_options): `authenticators`: [i32] ⛁
- [u32](/types/u32): An unsigned 32-bit integer type, representing whole numbers in the range from **0** to **4,294,967,295** (2³² − 1).
- [u64](/types/u64): unsigned 64 bit integer
- [u8](/types/u8): An unsigned 8-bit integer type, representing whole numbers in the range from **0** to **255** (28 − 1).
- [UnbondingDelegation](/types/unbonding_delegations): `delegator_address`: string
- [UnbondingDelegationEntry](/types/unbounding_delegation_entry): `created_height`: [i64]
- [UnconditionalRevShareConfig](/types/unconditional_rev_share_config): `configs`: [RecipientConfig]
- [UserStats](/types/user_stats): `taker_notional`: [u64]
- [Validator](/types/validator): `operator_address`: string
- [VaultHistoricalPnl](/types/vault_historical_pnl): `ticker`: string
- [VaultPosition](/types/vault_position): `ticker`: string
- [VersionInfo](/types/version_info): `name`: string
`app_name`: string
`version`: string
`git_commit`: string
`build_tags`: string
`go_version`: string
`build_deps`: [Module] ⛁
- [Wallet](/types/wallet): `key`: [KeyPair]
- [Accounts and Subaccounts](/concepts/trading/accounts): Accounts and subaccounts serve as identifiers in the dYdX ecosystem.
- [Perpetuals and Assets](/concepts/trading/assets): Perpetual contracts, or "perps," is a derivative and a type of futures contract commonly used in crypto trading. Unlike traditional futures, they do not have an expiration date, allowing traders to hold positions indefinitely. This makes them ideal for continuous speculation on asset prices.
- [Permissioned Keys](/concepts/trading/authenticators): Permissioned Keys are a dYdX specific extension to the Cosmos authentication system that allows an account to add custom logic for verifying and confirming transactions placed on that account. For example, an account could enable other accounts to sign and place transactions on their behalf, limit those transactions to certain message types or clob pairs etc, all in a composable way.
- [Contract Loss Mechanisms](/concepts/trading/contract-loss-mechanism): During periods of high volatility in the markets underlying the perpetual contracts, the value of some accounts may drop below zero before they can be liquidated. In these cases, the protocol’s deleveraging system kicks in.
- [Funding](/concepts/trading/funding): Funding rates contemplated in the default v4 software will be subject to adjustments by the applicable Governance Community.
- [Governance Functionalities](/concepts/trading/governance): Below is a current list of all module parameters that `x/gov` has the ability to update directly. Further documentation will be released which outlines overviews of each custom module, how modules interact with one another, and technical guides regarding how to properly submit governance proposals.
- [Isolated Markets](/concepts/trading/isolated-markets): In v5.0.0 the Isolated Markets feature was added to the V4 chain software. The below is an overview of how trading will work on Isolated Markets on the V4 chain software.
- [Trading Isolated Markets](/concepts/trading/isolated-markets): Note: This document covers how the feature works from the protocol point of view and not the front end or the indexer. For more details on what isolated markets are see the [blog post](https://dydx.exchange/blog/introducing-isolated-markets-and-isolated-margin).
- [Querying for Isolated Markets](/concepts/trading/isolated-markets): Note: This document covers how the feature works from the protocol point of view and not the front end or the indexer. For more details on what isolated markets are see the [blog post](https://dydx.exchange/blog/introducing-isolated-markets-and-isolated-margin).
- [Isolated Positions](/concepts/trading/isolated-positions): **Isolated positions** on the **dYdX frontend** are perpetual positions held in subaccounts with a subaccount number greater than 127, up to the limit of 128,000. Each isolated position is held in a separate subaccount.
- [Limit Order Book and Matching](/concepts/trading/limit-orderbook): This document outlines the key differences between centralized exchanges and dYdX Chain, focusing on the decentralized limit order book and matching engine.
- [Liquidations](/concepts/trading/liquidations): As part of the default settings of the v4 open source software (”dYdX Chain”), accounts whose total value falls below their maintenance margin requirement may have their positions automatically closed by the liquidation engine. Positions are closed via protocol-generated liquidation matches where a protocol-generated liquidation order uses a calculated “Fillable Price” as the limit price to match against liquidity resting on the order book.\
Profits or losses from liquidations are taken on by the insurance fund.
A liquidated subaccount may have its position partially or fully closed. v4 open source software includes a liquidations configuration which — as determined by the applicable Governance Community — will determine how much of the position is liquidated.
- [Margining](/concepts/trading/margin): As part of default settings on the dYdX Chain open source software, each market has two risk parameters, Initial Margin Fraction (IMF) and Maintenance Margin Fraction (MMF):
- [MegaVault](/concepts/trading/megavault): MegaVault is a live feature on the dYdX that allows users to deposit **USDC** and earn yield by providing liquidity to various markets. It operates as an automated liquidity provisioning system, using deposited funds to run **automated market-making (AMM)** strategies across multiple trading pairs.
- [Oracle Prices](/concepts/trading/oracle): Oracle prices are aggregated prices that provide up-to-date price data for different assets. The oracle price for each trading pair is used for the following:
- [Orders](/concepts/trading/orders): An order is the way a trader manages positions in the dYdX markets. Different types of orders exist to support different trading strategies.
- [Quantums and Subticks](/concepts/trading/quantums): In dYdX, quantities and prices are represented in quantums (for quantities) and subticks (for prices), which need conversion for practical understanding.
- [HTTP API](/er-client/http/index)
- [WebSockets API](/indexer-client/websockets/intro): The WebSockets API provides data feeds providing the trader real-time information.
- [Quick Start with Python](/interaction/client/quick-start-py): This guide will walk you through the steps to set up and start using the dYdX API Python library.
- [Quick Start with Rust](/interaction/client/quick-start-rs): This guide will walk you through the steps to set up and start using the dYdX API Rust library.
- [Quick Start with TypeScript](/interaction/client/quick-start-ts): This guide will walk you through the steps to set up and start using the dYdX API TypeScript library.
- [Accounts](/interaction/data/accounts): All of your trading activity is associated with your account which corresponds to an address.
In dYdX, accounts are also composed by subaccounts. All trading is done through a subaccount. See more on the [Accounts and Subaccounts](/concepts/trading/accounts) page.
- [WebSockets](/interaction/data/feeds): The Indexer can provide realtime data through its WebSockets endpoint.
- [Trading Data](/interaction/data/market): This section guides you on how to fetch some important data points.
We focus here on getting data using spontaneous (single) requests. For continuous data streams of data see also the [WebSockets guide](/interaction/data/feeds).
- [Watch orderbook](/interaction/data/watch-orderbook): Depending on your trading strategy, keeping track of the current orderbook can be essential. The orderbook is a list of all the unmatched orders, divided into the **bids** (buy orders) and the **asks** (sell orders).
- [Other deposit methods](/interaction/deposits-withdrawals/other): **Coinbase deposits** involve an **automatic Noble Wallet to dYdX IBC transfer** without needing a third-party bridge.
- [Deposits and Withdrawals](/interaction/deposits-withdrawals/overview): This guide provides a **step-by-step** explanation of deposit and withdrawal processes on the dYdX Chain. It includes instructions for Skip Go Fast (`Instant`), Skip Go (`regular`), Coinbase deposits, and direct IBC transfers, along with troubleshooting methods and best practices to ensure seamless transactions.
- [Skip Go (](/interaction/deposits-withdrawals/skipgo): Skip Go API is a **universal interoperability platform**, allowing **seamless swaps and transfers** across multiple blockchain ecosystems via **bridges such as CCTP and Axelar**.
- [Skip Go Fast (](/interaction/deposits-withdrawals/skipgofast): Skip Go Fast is a **decentralized bridging protocol**, developed by **Skip**, that enables **rapid and secure cross-chain transactions** across major blockchain ecosystems such as Ethereum, Cosmos, and Solana. Go Fast accelerates cross-chain actions by up to 25 times, **reducing onboarding times from 10+ minutes to seconds**. Learn more [here](https://docs.skip.build/go/advanced-transfer/go-fast#go-fast).
- [Withdrawal and Deposit Troubleshooting](/interaction/deposits-withdrawals/troubleshooting): Verify transaction succeeded on source blockchain explorer
- [Withdrawal Process](/interaction/deposits-withdrawals/withdrawal): Withdrawing from dYdX Chain requires first moving funds from your trading subaccount to your main account before bridging to your destination chain.
- [Builder Codes](/interaction/integration/integration-builder-codes): Builder codes enables external parties to submit orders to dYdX and collect fees (per-order) for building and routing an order to the exchange.
The address and fee, in parts per million, needs to be configured via the `BuilderCodeParameters` in the order message itself. The fee will be paid out when the given order is filled.
- [Placing orders and verifying Order Router Address in Fills](/interaction/integration/integration-builder-codes): `builderAddress` - where fees will be routed
- [Compliance](/interaction/integration/integration-compliance): Per the [terms of service](https://dydx.exchange/v4-terms) of the open-source software, the following categories of persons are currently prohibited from using dYdX Software:
- [Data sources](/interaction/integration/integration-data): The client application would need the obtain the data from the following sources:
- [Market data](/interaction/integration/integration-markets): The client application typically displays a list of tradable and launchable markets as follows:
- [Onboarding](/interaction/integration/integration-onboarding): The client application onboards the user by asking the user to sign a message using an existing wallet address. The v4-client-js library provides a [function](https://github.com/dydxprotocol/v4-clients/blob/a2c7adcc64b33fefaf56ffb6fc1d2bb8b174601e/v4-client-js/src/lib/onboarding.ts#L43) that deterministically generates the dYdX chain address (see [accounts](/concepts/trading/accounts#main-account)) and keys from the signed message.
Once the keys are generated, the client application can use them to sign transactions on the dYdX chain on the user’s behalf, enabling secure and seamless interaction with the platform.
- [User Portfolio](/interaction/integration/integration-portfolio): After onboarding to dYdX and depositing funds, the app displays the portfolio view. Once the user places a trade, the app updates to show open positions.
- [Revenue Share](/interaction/integration/integration-revshare): Order Router Rev Share enables third-party order routers to direct orders to dYdX and earn a portion of the trading fees (maker and taker). The revenue share, specified in parts per million (ppm), must be voted in via Governance and set in the `order_router_address` field in the order message itself.
- [Placing a Trade](/interaction/integration/integration-trade): Market trade lets users execute an order based on the current state of the orderbook.
- [Integration Guide](/interaction/integration/integration): This guide outlines the development of a perpetual trading front-end application using the dYdX v4 application chain APIs.
It covers backend data interpretation and rendering for end users, as well as trade execution.
While maintaining a high-level perspective, it addresses specific details as needed.
For in-depth implementation details, refer to the dYdX source repository, where dYdX Trading Inc. maintains the trading application's source code for web, iOS, and Android platforms.
- [Permissioned Keys](/interaction/permissioned-keys): Permissioned Keys provide a way for different traders to share the same account.
Using this mechanism, the owner of an account can provide different types of permissions, allowing flexibility to what and what not the permissioned users can do with its account.
- [Trading](/interaction/trading): Interacting with the dYdX perpetual markets and managing your positions is done by placing orders. Enter `LONG` positions by placing buy orders and `SHORT` positions by placing sell orders.
- [Permissioned Keys](/node-client/authenticators)
- [gRPC Streaming Example](/nodes/full-node-streaming/example): [Indexer-based orderbook streaming](/interaction/data/watch-orderbook), due to the increased latency introduced by the Indexer, can cause issues like more outdated orders or a crossed orderbook.
In a full node, the orderbook available will be more up-to-date and should be preferred over the Indexer-based solution.
This requires a full node with [gRPC streaming enabled](/nodes/full-node-streaming).
- [Full Node gRPC Streaming](/nodes/full-node-streaming): Enable full node streaming to expose a stream of orderbook updates (L3), fills, taker orders, and subaccount updates, allowing clients to maintain a full view of the orderbook and various exchange activities. Note that the orderbook state can vary slightly between nodes due to dYdX's offchain orderbook design.
- [Hardware Requirements](/nodes/running-node/hardware-requirement): The minimum recommended specs for running a node is the following:
- [Optimize Your Full Node](/nodes/running-node/optimize): Optimizing your full node helps keep it online, up to date, and operating quickly. Faster nodes have an advantage over slower nodes because they tend to receive new data first and they minimize the time between placing and resolving orders. Optimize your full node by connecting to trusted nodes, taking precautions against falling out of sync with the network, and configuring storage settings.
- [Peering Directly with Order Gateway](/nodes/running-node/peering-with-gateway): For improved order latency of the network, the community might spin up an order gateway node to directly peer with. A chain coordination party may share this in the form of `$gateway_node_id@$gateway_ip_address:$port`.
- [Addendum](/nodes/running-node/peering-with-gateway): Share the full peering info of your validator node (`node_id@ip_address:port`) with the coordination party, which can be added as a `persistent_peer` to the gateway node. It's important that raw IP address (as opposed to a loadbalancer URL) of the validator node (as opposed to a sentry node) is shared. This ensures that the a direction connection can be maintained across node restarts.
- [Required Node Configs](/nodes/running-node/required-node-configs): These configurations must be applied for both full nodes and validators.
- [Running a Validator](/nodes/running-node/running-a-validator): 💡Note: failure to set up below configurations on a validator node may compromise chain functionality.
- [Set Up a Full Node](/nodes/running-node/setup): Installing and running a full node allows you to read orderbook and onchain data from a network, as well as place, confirm and cancel orders directly on that network.
- [Snapshots](/nodes/running-node/snapshots): Services that provide snapshots for the network can be found [here](/nodes/resources#snapshot-service).
These snapshots will be used as a backup point in case an upgrade fails or a new node wants to start up and does not want to start from block 1 to catchup.
- [Voting](/nodes/running-node/voting): Save the [chain-id](/nodes/network-constants#chain-id). This will make it so you do not have to manually pass in the chain-id flag for every CLI command.
- [Cosmovisor](/nodes/upgrades/cosmovisor): `cosmovisor` is a small process manager for Cosmos SDK application binaries that monitors the governance module for incoming chain upgrade proposals. If it sees a proposal that gets approved, `cosmovisor` can automatically download the new binary, stop the current binary, switch from the old binary to the new one, and finally restart the node with the new binary.
- [Performing Upgrades](/nodes/upgrades/performing-upgrades): Validators can choose how to run a validator and manage software upgrades according to their preferred option:
- [Types of upgrades](/nodes/upgrades/types-of-upgrades): Major and minor changes can be consensus breaking. These upgrades usually go through a governance proposal and happen at specific heights.
- [Using Cosmovisor to stage dYdX Chain binary upgrade](/nodes/upgrades/using-cosmovisor): Linux (Ubuntu Server 22.04.3 recommended)
- [Rate Limits](/concepts/trading/limits/rate-limits): All rate limits are subject to change. The latest limits can be queried via the `https://<REST_NODE_ENDPOINT>/dydxprotocol/clob/block_rate` endpoint.
- [Withdrawal Limits](/concepts/trading/limits/withdrawal-limits): In an effort to reduce risk across the protocol, withdrawals can be rate limited and gated in specific circumstances.​
- [Rewards, Fees and Parameters](/concepts/trading/rewards): There are several reward mechanisms available with the protocol software.
- [Staking Rewards](/concepts/trading/rewards/staking-rewards): Staking rewards are designed to reward `Validators` and `Stakers` (=Delegators). The sources of staking rewards are trading fees and gas fees collected by the protocol.
- [Trading Rewards](/concepts/trading/rewards/trading-rewards): Trading rewards are subject to adjustments by the applicable Governance Community.
Note that the community has voted to set the C parameter to 0