From 0afe0158516347daa04305678a12732948c173d5 Mon Sep 17 00:00:00 2001 From: Christopher-Li Date: Thu, 23 May 2024 15:14:23 -0400 Subject: [PATCH 01/18] Update Slinky version to v0.4.6 (#196) * Update Slinky version to v0.4.4 * update --- pages/validators/running_a_validator.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pages/validators/running_a_validator.md b/pages/validators/running_a_validator.md index a85be0a2..1eb822d3 100644 --- a/pages/validators/running_a_validator.md +++ b/pages/validators/running_a_validator.md @@ -20,6 +20,6 @@ Starting in `v5.0.0`, running a validating full node requires a Skip Protocol's Support issues with Skip's Sidecar should be directed [here](https://discord.gg/7hxEThEaRQ). -For mainnet deployment by dYdX Operation Services, Ltd. run: `N/A` +For mainnet deployment by dYdX Operation Services, Ltd. run: [`v0.4.6`](https://github.com/skip-mev/slinky/tree/v0.4.6) (`ghcr.io/skip-mev/slinky-sidecar:v0.4.6`) -For testnet run: [`v0.4.1`](https://github.com/skip-mev/slinky/tree/v0.4.1) (`ghcr.io/skip-mev/slinky-sidecar:v0.4.1`) +For testnet run: [`v0.4.6`](https://github.com/skip-mev/slinky/tree/v0.4.6) (`ghcr.io/skip-mev/slinky-sidecar:v0.4.6`) From bb8e1a247bab71749e83ad27aa08f31e68d64ca5 Mon Sep 17 00:00:00 2001 From: Dimitar Petkov <796902+2dpetkov@users.noreply.github.com> Date: Tue, 28 May 2024 04:48:35 +0300 Subject: [PATCH 02/18] remove Autostake gRPC endpoint (#207) --- pages/network/resources.mdx | 1 - 1 file changed, 1 deletion(-) diff --git a/pages/network/resources.mdx b/pages/network/resources.mdx index 0305d7be..50fa36e7 100644 --- a/pages/network/resources.mdx +++ b/pages/network/resources.mdx @@ -190,7 +190,6 @@ For **the deployment by DYDX token holders**: | Bware Labs | `https://dydx-mainnet-full-grpc.public.blastapi.io:443` | 20 req/s | | KingNodes | `https://dydx-ops-grpc.kingnodes.com:443` | 250 req/m | | Lavender.Five | `https://dydx-grpc.lavenderfive.com:443` | | -| AutoStake | `https://dydx-mainnet-grpc.autostake.com:443` | 4 req/s | | PublicNode | `https://dydx-grpc.publicnode.com:443` | | From a917650ecc4a46bb7c10358fe97eb7b383f03cc1 Mon Sep 17 00:00:00 2001 From: Jonathan Fung <121899091+jonfung-dydx@users.noreply.github.com> Date: Tue, 28 May 2024 15:16:02 -0400 Subject: [PATCH 03/18] Add back disclaimer on blocking grpc stream consumers (#205) * add back disclaimer on blocking * more updates --- pages/validators/full_node_streaming.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/pages/validators/full_node_streaming.md b/pages/validators/full_node_streaming.md index 51c267b6..ecfc34b3 100644 --- a/pages/validators/full_node_streaming.md +++ b/pages/validators/full_node_streaming.md @@ -6,9 +6,9 @@ Last updated for: `v4.1.3` This feature aims to provide real-time, accurate orderbook updates and fills. Complete orderbook activities and fills are streamed to the client and can be used to construct a full depth L3 orderbook. Streams are implemented using the existing GRPC query service from Cosmos SDK. -The current implementation provides information on orders and fills. Note that by dYdX V4’s design, the orderbook can be slightly different across different nodes. +The current implementation provides information on orders and fills. Note that by dYdX V4’s optimistic orderbook design, the orderbook can be slightly different across different nodes. -**Disclaimer:** We recommend you use this exclusively with your own self-hosted node. +**Disclaimer:** It’s possible for the full node to block indefinitely when sending a message to an unresponsive client, so right now we recommend you use this exclusively with your own node and that the client always close the gRPC stream before shutting down. This issue will be fixed in the next version (v4.1.4) ## Enabling GRPC Streaming @@ -168,7 +168,7 @@ func (l *LocalOrderbook) AddOrder(order v1types.IndexerOrder) { ### OrderUpdateV1 When `OrderUpdateV1` is received, update the order's fill amount to the amount specified. -- This message is only used to update fill amounts (Fill Amounts). It carries information about an order's updated fill amount. +- This message is only used to update fill amounts. It carries information about an order's updated fill amount. - This message is sent out whenever an an order's fill amount changes from an action that isn't a `ClobMatch`. - This includes when deliverState is reset to the checkState from last block, or when branched state is written to and then discarded if there was a matching error. - An update message will always accompany an order placement message. @@ -253,9 +253,10 @@ func (l *LocalOrderbook) RemoveOrder(orderId v1types.IndexerOrderId) { ## Maintaining Order Fill Amounts -This message is only used to update fill amounts (Fill Amounts), it does not cause any modifications to the orderbook data structure (Bids, Asks). +### StreamOrderbookFill/ClobMatch +This message is only used to update fill amounts, it does not cause any modifications to the orderbook data structure (Bids, Asks). -The `ClobMatch` data structure exposed contains either a `MatchOrders` or a `MatchPerpetualLiquidation` object. Match Deleveraging events are not emitted. Within each Match object, a `MakerFill` array contains the various maker orders that matched with the singular taker order and the amount of quantums matched. +The `ClobMatch` data structure contains either a `MatchOrders` or a `MatchPerpetualLiquidation` object. Match Deleveraging events are not emitted. Within each Match object, a `MakerFill` array contains the various maker orders that matched with the singular taker order and the amount of quantums matched. Note that prices are always matched at the maker order price. The `orders` field in the `StreamOrderbookFill` object allow for price lookups based on order id. It contains all the maker order ids, and in the case of non-liquidation orders, it has the taker order. From 1900e54af5033d837fb0ef4eec26cda2ab6fdc33 Mon Sep 17 00:00:00 2001 From: Jonathan Fung <121899091+jonfung-dydx@users.noreply.github.com> Date: Wed, 29 May 2024 17:08:57 -0400 Subject: [PATCH 04/18] Add documentation for grpc streaming v4.1.4 (#209) * add buffering documentation and some QA * nits --- pages/validators/full_node_streaming.md | 36 ++++++++++++++++++++----- 1 file changed, 29 insertions(+), 7 deletions(-) diff --git a/pages/validators/full_node_streaming.md b/pages/validators/full_node_streaming.md index ecfc34b3..2a8bf9ad 100644 --- a/pages/validators/full_node_streaming.md +++ b/pages/validators/full_node_streaming.md @@ -2,17 +2,21 @@ # Full Node GRPC Streaming -Last updated for: `v4.1.3` +Last updated for: `v4.1.4` -This feature aims to provide real-time, accurate orderbook updates and fills. Complete orderbook activities and fills are streamed to the client and can be used to construct a full depth L3 orderbook. Streams are implemented using the existing GRPC query service from Cosmos SDK. +This feature aims to provide real-time, accurate orderbook updates and fills. Complete orderbook activities and fills are streamed to the client and can be used to construct a full depth L3 orderbook. Streams are implemented using the existing GRPC query service from Cosmos SDK. Note that by dYdX V4’s optimistic orderbook design, the orderbook can be slightly different across different nodes. -The current implementation provides information on orders and fills. Note that by dYdX V4’s optimistic orderbook design, the orderbook can be slightly different across different nodes. - -**Disclaimer:** It’s possible for the full node to block indefinitely when sending a message to an unresponsive client, so right now we recommend you use this exclusively with your own node and that the client always close the gRPC stream before shutting down. This issue will be fixed in the next version (v4.1.4) +This implementation maintains a length-configurable buffered queue of streaming updates to ensure slow or unresponsive clients do not induce full node lag during bursts of updates. If the buffer reaches maximum capacity, all connections and updates are dropped, and subscribers will have to re-subscribe. Metrics and logs are emitted on buffer length to help tune this parameter. ## Enabling GRPC Streaming -This feature can be enabled via a command line flag (`--grpc-streaming-enabled=true`) when starting your full node. This feature can only be used when grpc is also enabled. + +| CLI Flag | Type | Default | Short Explanation | +| -------- | ----- | ------- | -------- | +| grpc-streaming-enabled | bool | false | Toggle on to enable full node streaming.
Can only be used when grpc is enabled. | +| grpc-streaming-buffer-size | int | 1000 | Size of protocol-side updates buffer to
maintain before dropping all messages and connections | + +**Disclaimer:** We recommend you use this exclusively with your own node, as supporting multiple public GRPC streams with unknown client subscriptions may result in degredated performance. ## Consuming the gRPC Stream @@ -312,6 +316,8 @@ By protocol design, each validator has their own version of the orderbook and op ![full node streaming diagram](../../artifacts/full_node_streaming_diagram.jpg) +Note that DeliverTx maps to exec mode `execModeFinalize`. + ## Example Scenario - Trader places a bid at price 100 for size 1 @@ -327,6 +333,15 @@ By protocol design, each validator has their own version of the orderbook and op - OrderUpdate, set total fill amount to be 0 (no-op) from checkState -> deliverState reset - MatchOrder emitted for block proposer's original order match, total filled amount = 1 +## Metrics and Logs + +| Metric | Type | Explanation | +| -------- | ----- | ------- | +| grpc_streaming_buffer_size | gauge | protocol-side update buffer size | +| grpc_streaming_num_connections | gauge | number of grpc stream subscriptions | + +All logs from grpc streaming are tagged with `module: grpc-streaming`. + ## FAQs Q: Suppose the full node saw the cancellation of order X at t0 before the placement of the order X at t1. What would the updates be like? @@ -361,4 +376,11 @@ Q: What are the exec modes? ExecModeEndBlock = 101 ExecModePrepareCheckState = 102 ``` - \ No newline at end of file + +
+ +Q: I only want to listen to confirmed updates. I do not want to process optimistic fills. +- A: You will want to only process messages from DeliverTx stage (`execModeFinalize`). This step is when we save proposed matches from the block proposer into state. These updates will have exec mode execModeFinalize. + +Q: Why do I see an Order Update message for a new OrderId before an Order Place message? +- A: During DeliverTx, the first step we do is to reset fill amounts (via OrderUpdate messages) for all orders involved in the proposed and local operations queue due to the deliver state being reset to the check state from last block. We "reset" fill order amounts to 0 for orders that the block proposer has seen but has not gossiped to our full node yet. In the future, we may reduce the number of messages that are sent, but for now we are optimizing for orderbook correctness. From ece2a817dff983103b042152b114b42662deceba Mon Sep 17 00:00:00 2001 From: James Jia Date: Wed, 29 May 2024 17:30:22 -0400 Subject: [PATCH 05/18] =?UTF-8?q?Restructure=20docs,=20add=20emojis=20?= =?UTF-8?q?=F0=9F=A4=A0=20(#210)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Restructure docs * move onboarding faqs back to intro --- pages/_meta.json | 46 +++++++++++-------- .../cli_commands.md | 0 .../how_to_send_usdc_from_ethereum_to_dydx.md | 0 .../rate_limits_and_gating.md | 0 .../_meta.json | 0 .../clients/_meta.json | 0 .../clients/composite_client.mdx | 0 .../clients/indexer_client.mdx | 0 .../clients/socket_client.mdx | 0 .../clients/validator_client.mdx | 0 .../constants.md | 0 .../indexer/_meta.json | 0 .../indexer/indexer_api.mdx | 0 .../indexer/indexer_websocket.md | 0 .../open_source_repositories.md | 0 .../_meta.json | 0 .../cli_python_script.md | 0 .../how_to_interpret_block_data_for_trades.md | 0 .../how_to_uncross_orderbook.md | 0 ...setting_up_raspberry_pi_for_api_trading.md | 0 .../_meta.json | 0 .../guides.json | 0 .../order_types.md | 0 .../other_limits.md | 0 .../rate_limits.md | 0 .../short_term_vs_stateful.mdx | 0 .../_meta.json | 0 .../architectural_overview.md | 0 .../indexer.md | 0 .../margin.md} | 0 .../rewards_fees_and_parameters.md | 0 pages/getting_started/_meta.json | 6 --- .../_meta.json | 0 .../faucet.mdx | 0 .../network_constants.mdx | 0 .../resources.mdx | 0 .../_meta.json | 0 .../indexer_usage_estimates.md | 0 .../software_checklist.md | 0 .../_meta.json | 0 .../full_node_streaming.md | 0 .../hardware_requirements.md | 0 .../how_to_set_up_full_node.md | 0 .../required_node_configs.md | 0 .../running_a_validator.md | 0 .../running_full_node.md | 0 .../snapshots.md | 0 .../upgrades/_meta.json | 0 .../upgrades/cosmovisor.md | 0 .../upgrades/performing_upgrades.md | 0 .../upgrades/types_of_upgrades.md | 0 .../upgrades/upgrading_sidecar.md | 0 ...isor_to_stage_dYdX_Chain_binary_upgrade.md | 0 ...eys.md => introduction-getting_started.md} | 0 ...aqs.md => introduction-onboarding_faqs.md} | 0 pages/{security.md => other-security.md} | 0 ... other-terms_of_use_and_privacy_policy.md} | 0 pages/{FAQ.md => users-faqs.md} | 0 .../_meta.json | 0 .../functionalities.md | 0 .../proposing_a_new_market.md | 0 .../slashing_a_validator.md | 0 .../submitting_a_proposal.md | 0 .../voting.md | 0 pages/{rewards => users-rewards}/_meta.json | 0 pages/{rewards => users-rewards}/overview.md | 0 .../staking_rewards.md | 0 .../trading_rewards.md | 0 68 files changed, 27 insertions(+), 25 deletions(-) rename pages/{deposits_and_withdrawals => api_integration-deposits_and_withdrawals}/cli_commands.md (100%) rename pages/{deposits_and_withdrawals => api_integration-deposits_and_withdrawals}/how_to_send_usdc_from_ethereum_to_dydx.md (100%) rename pages/{deposits_and_withdrawals => api_integration-deposits_and_withdrawals}/rate_limits_and_gating.md (100%) rename pages/{developers => api_integration-developers}/_meta.json (100%) rename pages/{developers => api_integration-developers}/clients/_meta.json (100%) rename pages/{developers => api_integration-developers}/clients/composite_client.mdx (100%) rename pages/{developers => api_integration-developers}/clients/indexer_client.mdx (100%) rename pages/{developers => api_integration-developers}/clients/socket_client.mdx (100%) rename pages/{developers => api_integration-developers}/clients/validator_client.mdx (100%) rename pages/{developers => api_integration-developers}/constants.md (100%) rename pages/{developers => api_integration-developers}/indexer/_meta.json (100%) rename pages/{developers => api_integration-developers}/indexer/indexer_api.mdx (100%) rename pages/{developers => api_integration-developers}/indexer/indexer_websocket.md (100%) rename pages/{developers => api_integration-developers}/open_source_repositories.md (100%) rename pages/{guides => api_integration-guides}/_meta.json (100%) rename pages/{guides => api_integration-guides}/cli_python_script.md (100%) rename pages/{guides => api_integration-guides}/how_to_interpret_block_data_for_trades.md (100%) rename pages/{guides => api_integration-guides}/how_to_uncross_orderbook.md (100%) rename pages/{guides => api_integration-guides}/setting_up_raspberry_pi_for_api_trading.md (100%) rename pages/{trading => api_integration-trading}/_meta.json (100%) rename pages/{trading => api_integration-trading}/guides.json (100%) rename pages/{trading => api_integration-trading}/order_types.md (100%) rename pages/{trading => api_integration-trading}/other_limits.md (100%) rename pages/{trading => api_integration-trading}/rate_limits.md (100%) rename pages/{trading => api_integration-trading}/short_term_vs_stateful.mdx (100%) rename pages/{architecture => concepts-architecture}/_meta.json (100%) rename pages/{architecture => concepts-architecture}/architectural_overview.md (100%) rename pages/{architecture => concepts-architecture}/indexer.md (100%) rename pages/{getting_started/margin_calculations.md => concepts-trading/margin.md} (100%) rename pages/{getting_started => concepts-trading}/rewards_fees_and_parameters.md (100%) delete mode 100644 pages/getting_started/_meta.json rename pages/{network => infrastructure_providers-network}/_meta.json (100%) rename pages/{network => infrastructure_providers-network}/faucet.mdx (100%) rename pages/{network => infrastructure_providers-network}/network_constants.mdx (100%) rename pages/{network => infrastructure_providers-network}/resources.mdx (100%) rename pages/{operators => infrastructure_providers-operators}/_meta.json (100%) rename pages/{operators => infrastructure_providers-operators}/indexer_usage_estimates.md (100%) rename pages/{operators => infrastructure_providers-operators}/software_checklist.md (100%) rename pages/{validators => infrastructure_providers-validators}/_meta.json (100%) rename pages/{validators => infrastructure_providers-validators}/full_node_streaming.md (100%) rename pages/{validators => infrastructure_providers-validators}/hardware_requirements.md (100%) rename pages/{validators => infrastructure_providers-validators}/how_to_set_up_full_node.md (100%) rename pages/{validators => infrastructure_providers-validators}/required_node_configs.md (100%) rename pages/{validators => infrastructure_providers-validators}/running_a_validator.md (100%) rename pages/{validators => infrastructure_providers-validators}/running_full_node.md (100%) rename pages/{validators => infrastructure_providers-validators}/snapshots.md (100%) rename pages/{validators => infrastructure_providers-validators}/upgrades/_meta.json (100%) rename pages/{validators => infrastructure_providers-validators}/upgrades/cosmovisor.md (100%) rename pages/{validators => infrastructure_providers-validators}/upgrades/performing_upgrades.md (100%) rename pages/{validators => infrastructure_providers-validators}/upgrades/types_of_upgrades.md (100%) rename pages/{validators => infrastructure_providers-validators}/upgrades/upgrading_sidecar.md (100%) rename pages/{validators => infrastructure_providers-validators}/upgrades/using_cosmovisor_to_stage_dYdX_Chain_binary_upgrade.md (100%) rename pages/{getting_started/depositing_and_user_journeys.md => introduction-getting_started.md} (100%) rename pages/{getting_started/onboarding_faqs.md => introduction-onboarding_faqs.md} (100%) rename pages/{security.md => other-security.md} (100%) rename pages/{terms_of_use_and_privacy_policy.md => other-terms_of_use_and_privacy_policy.md} (100%) rename pages/{FAQ.md => users-faqs.md} (100%) rename pages/{governance => users-governance}/_meta.json (100%) rename pages/{governance => users-governance}/functionalities.md (100%) rename pages/{governance => users-governance}/proposing_a_new_market.md (100%) rename pages/{governance => users-governance}/slashing_a_validator.md (100%) rename pages/{governance => users-governance}/submitting_a_proposal.md (100%) rename pages/{governance => users-governance}/voting.md (100%) rename pages/{rewards => users-rewards}/_meta.json (100%) rename pages/{rewards => users-rewards}/overview.md (100%) rename pages/{rewards => users-rewards}/staking_rewards.md (100%) rename pages/{rewards => users-rewards}/trading_rewards.md (100%) diff --git a/pages/_meta.json b/pages/_meta.json index ed361e86..ee2979ec 100644 --- a/pages/_meta.json +++ b/pages/_meta.json @@ -1,48 +1,56 @@ { "----------INTRODUCTION----------": { - "title": "INTRODUCTION", + "title": "🦔 INTRODUCTION", "type": "separator" }, "index": "Introduction", - "getting_started": "Getting Started", - "architecture": "Architecture", + "introduction-getting_started": "Getting Started", + "introduction-onboarding_faqs": "Onboarding FAQs", "----------INFRASTRUCTURE PROVIDERS----------": { - "title": "INFRASTRUCTURE PROVIDERS", + "title": "🏘️ INFRASTRUCTURE PROVIDERS", "type": "separator" }, - "validators": "Validators & Full-Nodes", - "network": "Network Configuration", - "operators": "Indexer Operators", + "infrastructure_providers-validators": "Validators & Full-Nodes", + "infrastructure_providers-network": "Network Configuration", + "infrastructure_providers-operators": "Indexer Operators", "----------API INTEGRATION----------": { - "title": "API INTEGRATION", + "title": "🔗 API INTEGRATION", "type": "separator" }, - "trading": "Trading", - "deposits_and_withdrawals": "Deposits and Withdrawals", - "developers": "Developers", - "guides": "Guides", + "api_integration-trading": "Trading", + "api_integration-deposits_and_withdrawals": "Deposits and Withdrawals", + "api_integration-developers": "Developers", + "api_integration-guides": "Guides", "----------USERS----------": { - "title": "USERS", + "title": "👥 USERS", "type": "separator" }, - "rewards": "Rewards", - "governance": "Governance", - "FAQ": "FAQs", + "users-rewards": "Rewards", + "users-governance": "Governance", + "users-faqs": "FAQs", + + "----------CONCEPTS----------": { + "title": "🤔 CONCEPTS", + "type": "separator" + }, + + "concepts-architecture": "Architecture", + "concepts-trading": "Trading", "----------OTHER----------": { - "title": "OTHER", + "title": "💬 OTHER", "type": "separator" }, - "security": "Security", - "terms_of_use_and_privacy_policy": "Terms & Policies", + "other-security": "Security", + "other-terms_of_use_and_privacy_policy": "Terms & Policies", "testnet app": { "title": "Testnet App ↗", diff --git a/pages/deposits_and_withdrawals/cli_commands.md b/pages/api_integration-deposits_and_withdrawals/cli_commands.md similarity index 100% rename from pages/deposits_and_withdrawals/cli_commands.md rename to pages/api_integration-deposits_and_withdrawals/cli_commands.md diff --git a/pages/deposits_and_withdrawals/how_to_send_usdc_from_ethereum_to_dydx.md b/pages/api_integration-deposits_and_withdrawals/how_to_send_usdc_from_ethereum_to_dydx.md similarity index 100% rename from pages/deposits_and_withdrawals/how_to_send_usdc_from_ethereum_to_dydx.md rename to pages/api_integration-deposits_and_withdrawals/how_to_send_usdc_from_ethereum_to_dydx.md diff --git a/pages/deposits_and_withdrawals/rate_limits_and_gating.md b/pages/api_integration-deposits_and_withdrawals/rate_limits_and_gating.md similarity index 100% rename from pages/deposits_and_withdrawals/rate_limits_and_gating.md rename to pages/api_integration-deposits_and_withdrawals/rate_limits_and_gating.md diff --git a/pages/developers/_meta.json b/pages/api_integration-developers/_meta.json similarity index 100% rename from pages/developers/_meta.json rename to pages/api_integration-developers/_meta.json diff --git a/pages/developers/clients/_meta.json b/pages/api_integration-developers/clients/_meta.json similarity index 100% rename from pages/developers/clients/_meta.json rename to pages/api_integration-developers/clients/_meta.json diff --git a/pages/developers/clients/composite_client.mdx b/pages/api_integration-developers/clients/composite_client.mdx similarity index 100% rename from pages/developers/clients/composite_client.mdx rename to pages/api_integration-developers/clients/composite_client.mdx diff --git a/pages/developers/clients/indexer_client.mdx b/pages/api_integration-developers/clients/indexer_client.mdx similarity index 100% rename from pages/developers/clients/indexer_client.mdx rename to pages/api_integration-developers/clients/indexer_client.mdx diff --git a/pages/developers/clients/socket_client.mdx b/pages/api_integration-developers/clients/socket_client.mdx similarity index 100% rename from pages/developers/clients/socket_client.mdx rename to pages/api_integration-developers/clients/socket_client.mdx diff --git a/pages/developers/clients/validator_client.mdx b/pages/api_integration-developers/clients/validator_client.mdx similarity index 100% rename from pages/developers/clients/validator_client.mdx rename to pages/api_integration-developers/clients/validator_client.mdx diff --git a/pages/developers/constants.md b/pages/api_integration-developers/constants.md similarity index 100% rename from pages/developers/constants.md rename to pages/api_integration-developers/constants.md diff --git a/pages/developers/indexer/_meta.json b/pages/api_integration-developers/indexer/_meta.json similarity index 100% rename from pages/developers/indexer/_meta.json rename to pages/api_integration-developers/indexer/_meta.json diff --git a/pages/developers/indexer/indexer_api.mdx b/pages/api_integration-developers/indexer/indexer_api.mdx similarity index 100% rename from pages/developers/indexer/indexer_api.mdx rename to pages/api_integration-developers/indexer/indexer_api.mdx diff --git a/pages/developers/indexer/indexer_websocket.md b/pages/api_integration-developers/indexer/indexer_websocket.md similarity index 100% rename from pages/developers/indexer/indexer_websocket.md rename to pages/api_integration-developers/indexer/indexer_websocket.md diff --git a/pages/developers/open_source_repositories.md b/pages/api_integration-developers/open_source_repositories.md similarity index 100% rename from pages/developers/open_source_repositories.md rename to pages/api_integration-developers/open_source_repositories.md diff --git a/pages/guides/_meta.json b/pages/api_integration-guides/_meta.json similarity index 100% rename from pages/guides/_meta.json rename to pages/api_integration-guides/_meta.json diff --git a/pages/guides/cli_python_script.md b/pages/api_integration-guides/cli_python_script.md similarity index 100% rename from pages/guides/cli_python_script.md rename to pages/api_integration-guides/cli_python_script.md diff --git a/pages/guides/how_to_interpret_block_data_for_trades.md b/pages/api_integration-guides/how_to_interpret_block_data_for_trades.md similarity index 100% rename from pages/guides/how_to_interpret_block_data_for_trades.md rename to pages/api_integration-guides/how_to_interpret_block_data_for_trades.md diff --git a/pages/guides/how_to_uncross_orderbook.md b/pages/api_integration-guides/how_to_uncross_orderbook.md similarity index 100% rename from pages/guides/how_to_uncross_orderbook.md rename to pages/api_integration-guides/how_to_uncross_orderbook.md diff --git a/pages/guides/setting_up_raspberry_pi_for_api_trading.md b/pages/api_integration-guides/setting_up_raspberry_pi_for_api_trading.md similarity index 100% rename from pages/guides/setting_up_raspberry_pi_for_api_trading.md rename to pages/api_integration-guides/setting_up_raspberry_pi_for_api_trading.md diff --git a/pages/trading/_meta.json b/pages/api_integration-trading/_meta.json similarity index 100% rename from pages/trading/_meta.json rename to pages/api_integration-trading/_meta.json diff --git a/pages/trading/guides.json b/pages/api_integration-trading/guides.json similarity index 100% rename from pages/trading/guides.json rename to pages/api_integration-trading/guides.json diff --git a/pages/trading/order_types.md b/pages/api_integration-trading/order_types.md similarity index 100% rename from pages/trading/order_types.md rename to pages/api_integration-trading/order_types.md diff --git a/pages/trading/other_limits.md b/pages/api_integration-trading/other_limits.md similarity index 100% rename from pages/trading/other_limits.md rename to pages/api_integration-trading/other_limits.md diff --git a/pages/trading/rate_limits.md b/pages/api_integration-trading/rate_limits.md similarity index 100% rename from pages/trading/rate_limits.md rename to pages/api_integration-trading/rate_limits.md diff --git a/pages/trading/short_term_vs_stateful.mdx b/pages/api_integration-trading/short_term_vs_stateful.mdx similarity index 100% rename from pages/trading/short_term_vs_stateful.mdx rename to pages/api_integration-trading/short_term_vs_stateful.mdx diff --git a/pages/architecture/_meta.json b/pages/concepts-architecture/_meta.json similarity index 100% rename from pages/architecture/_meta.json rename to pages/concepts-architecture/_meta.json diff --git a/pages/architecture/architectural_overview.md b/pages/concepts-architecture/architectural_overview.md similarity index 100% rename from pages/architecture/architectural_overview.md rename to pages/concepts-architecture/architectural_overview.md diff --git a/pages/architecture/indexer.md b/pages/concepts-architecture/indexer.md similarity index 100% rename from pages/architecture/indexer.md rename to pages/concepts-architecture/indexer.md diff --git a/pages/getting_started/margin_calculations.md b/pages/concepts-trading/margin.md similarity index 100% rename from pages/getting_started/margin_calculations.md rename to pages/concepts-trading/margin.md diff --git a/pages/getting_started/rewards_fees_and_parameters.md b/pages/concepts-trading/rewards_fees_and_parameters.md similarity index 100% rename from pages/getting_started/rewards_fees_and_parameters.md rename to pages/concepts-trading/rewards_fees_and_parameters.md diff --git a/pages/getting_started/_meta.json b/pages/getting_started/_meta.json deleted file mode 100644 index c77b557a..00000000 --- a/pages/getting_started/_meta.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "depositing_and_user_journeys": "Depositing and User Journeys", - "onboarding_faqs": "Onboarding FAQs", - "rewards_fees_and_parameters": "Rewards, Fees and Parameters", - "margin_calculations": "Margin Calculations" -} diff --git a/pages/network/_meta.json b/pages/infrastructure_providers-network/_meta.json similarity index 100% rename from pages/network/_meta.json rename to pages/infrastructure_providers-network/_meta.json diff --git a/pages/network/faucet.mdx b/pages/infrastructure_providers-network/faucet.mdx similarity index 100% rename from pages/network/faucet.mdx rename to pages/infrastructure_providers-network/faucet.mdx diff --git a/pages/network/network_constants.mdx b/pages/infrastructure_providers-network/network_constants.mdx similarity index 100% rename from pages/network/network_constants.mdx rename to pages/infrastructure_providers-network/network_constants.mdx diff --git a/pages/network/resources.mdx b/pages/infrastructure_providers-network/resources.mdx similarity index 100% rename from pages/network/resources.mdx rename to pages/infrastructure_providers-network/resources.mdx diff --git a/pages/operators/_meta.json b/pages/infrastructure_providers-operators/_meta.json similarity index 100% rename from pages/operators/_meta.json rename to pages/infrastructure_providers-operators/_meta.json diff --git a/pages/operators/indexer_usage_estimates.md b/pages/infrastructure_providers-operators/indexer_usage_estimates.md similarity index 100% rename from pages/operators/indexer_usage_estimates.md rename to pages/infrastructure_providers-operators/indexer_usage_estimates.md diff --git a/pages/operators/software_checklist.md b/pages/infrastructure_providers-operators/software_checklist.md similarity index 100% rename from pages/operators/software_checklist.md rename to pages/infrastructure_providers-operators/software_checklist.md diff --git a/pages/validators/_meta.json b/pages/infrastructure_providers-validators/_meta.json similarity index 100% rename from pages/validators/_meta.json rename to pages/infrastructure_providers-validators/_meta.json diff --git a/pages/validators/full_node_streaming.md b/pages/infrastructure_providers-validators/full_node_streaming.md similarity index 100% rename from pages/validators/full_node_streaming.md rename to pages/infrastructure_providers-validators/full_node_streaming.md diff --git a/pages/validators/hardware_requirements.md b/pages/infrastructure_providers-validators/hardware_requirements.md similarity index 100% rename from pages/validators/hardware_requirements.md rename to pages/infrastructure_providers-validators/hardware_requirements.md diff --git a/pages/validators/how_to_set_up_full_node.md b/pages/infrastructure_providers-validators/how_to_set_up_full_node.md similarity index 100% rename from pages/validators/how_to_set_up_full_node.md rename to pages/infrastructure_providers-validators/how_to_set_up_full_node.md diff --git a/pages/validators/required_node_configs.md b/pages/infrastructure_providers-validators/required_node_configs.md similarity index 100% rename from pages/validators/required_node_configs.md rename to pages/infrastructure_providers-validators/required_node_configs.md diff --git a/pages/validators/running_a_validator.md b/pages/infrastructure_providers-validators/running_a_validator.md similarity index 100% rename from pages/validators/running_a_validator.md rename to pages/infrastructure_providers-validators/running_a_validator.md diff --git a/pages/validators/running_full_node.md b/pages/infrastructure_providers-validators/running_full_node.md similarity index 100% rename from pages/validators/running_full_node.md rename to pages/infrastructure_providers-validators/running_full_node.md diff --git a/pages/validators/snapshots.md b/pages/infrastructure_providers-validators/snapshots.md similarity index 100% rename from pages/validators/snapshots.md rename to pages/infrastructure_providers-validators/snapshots.md diff --git a/pages/validators/upgrades/_meta.json b/pages/infrastructure_providers-validators/upgrades/_meta.json similarity index 100% rename from pages/validators/upgrades/_meta.json rename to pages/infrastructure_providers-validators/upgrades/_meta.json diff --git a/pages/validators/upgrades/cosmovisor.md b/pages/infrastructure_providers-validators/upgrades/cosmovisor.md similarity index 100% rename from pages/validators/upgrades/cosmovisor.md rename to pages/infrastructure_providers-validators/upgrades/cosmovisor.md diff --git a/pages/validators/upgrades/performing_upgrades.md b/pages/infrastructure_providers-validators/upgrades/performing_upgrades.md similarity index 100% rename from pages/validators/upgrades/performing_upgrades.md rename to pages/infrastructure_providers-validators/upgrades/performing_upgrades.md diff --git a/pages/validators/upgrades/types_of_upgrades.md b/pages/infrastructure_providers-validators/upgrades/types_of_upgrades.md similarity index 100% rename from pages/validators/upgrades/types_of_upgrades.md rename to pages/infrastructure_providers-validators/upgrades/types_of_upgrades.md diff --git a/pages/validators/upgrades/upgrading_sidecar.md b/pages/infrastructure_providers-validators/upgrades/upgrading_sidecar.md similarity index 100% rename from pages/validators/upgrades/upgrading_sidecar.md rename to pages/infrastructure_providers-validators/upgrades/upgrading_sidecar.md diff --git a/pages/validators/upgrades/using_cosmovisor_to_stage_dYdX_Chain_binary_upgrade.md b/pages/infrastructure_providers-validators/upgrades/using_cosmovisor_to_stage_dYdX_Chain_binary_upgrade.md similarity index 100% rename from pages/validators/upgrades/using_cosmovisor_to_stage_dYdX_Chain_binary_upgrade.md rename to pages/infrastructure_providers-validators/upgrades/using_cosmovisor_to_stage_dYdX_Chain_binary_upgrade.md diff --git a/pages/getting_started/depositing_and_user_journeys.md b/pages/introduction-getting_started.md similarity index 100% rename from pages/getting_started/depositing_and_user_journeys.md rename to pages/introduction-getting_started.md diff --git a/pages/getting_started/onboarding_faqs.md b/pages/introduction-onboarding_faqs.md similarity index 100% rename from pages/getting_started/onboarding_faqs.md rename to pages/introduction-onboarding_faqs.md diff --git a/pages/security.md b/pages/other-security.md similarity index 100% rename from pages/security.md rename to pages/other-security.md diff --git a/pages/terms_of_use_and_privacy_policy.md b/pages/other-terms_of_use_and_privacy_policy.md similarity index 100% rename from pages/terms_of_use_and_privacy_policy.md rename to pages/other-terms_of_use_and_privacy_policy.md diff --git a/pages/FAQ.md b/pages/users-faqs.md similarity index 100% rename from pages/FAQ.md rename to pages/users-faqs.md diff --git a/pages/governance/_meta.json b/pages/users-governance/_meta.json similarity index 100% rename from pages/governance/_meta.json rename to pages/users-governance/_meta.json diff --git a/pages/governance/functionalities.md b/pages/users-governance/functionalities.md similarity index 100% rename from pages/governance/functionalities.md rename to pages/users-governance/functionalities.md diff --git a/pages/governance/proposing_a_new_market.md b/pages/users-governance/proposing_a_new_market.md similarity index 100% rename from pages/governance/proposing_a_new_market.md rename to pages/users-governance/proposing_a_new_market.md diff --git a/pages/governance/slashing_a_validator.md b/pages/users-governance/slashing_a_validator.md similarity index 100% rename from pages/governance/slashing_a_validator.md rename to pages/users-governance/slashing_a_validator.md diff --git a/pages/governance/submitting_a_proposal.md b/pages/users-governance/submitting_a_proposal.md similarity index 100% rename from pages/governance/submitting_a_proposal.md rename to pages/users-governance/submitting_a_proposal.md diff --git a/pages/governance/voting.md b/pages/users-governance/voting.md similarity index 100% rename from pages/governance/voting.md rename to pages/users-governance/voting.md diff --git a/pages/rewards/_meta.json b/pages/users-rewards/_meta.json similarity index 100% rename from pages/rewards/_meta.json rename to pages/users-rewards/_meta.json diff --git a/pages/rewards/overview.md b/pages/users-rewards/overview.md similarity index 100% rename from pages/rewards/overview.md rename to pages/users-rewards/overview.md diff --git a/pages/rewards/staking_rewards.md b/pages/users-rewards/staking_rewards.md similarity index 100% rename from pages/rewards/staking_rewards.md rename to pages/users-rewards/staking_rewards.md diff --git a/pages/rewards/trading_rewards.md b/pages/users-rewards/trading_rewards.md similarity index 100% rename from pages/rewards/trading_rewards.md rename to pages/users-rewards/trading_rewards.md From 633d46b0944e5773480a31caf49fc40ba8b7f0cb Mon Sep 17 00:00:00 2001 From: James Jia Date: Wed, 29 May 2024 19:32:08 -0400 Subject: [PATCH 06/18] Update onboarding files (#208) * Update some files * more changes * rename --- next.config.js | 4 + package-lock.json | 60 ----- pages/introduction-getting_started.md | 29 +- pages/introduction-onboarding_faqs.md | 207 -------------- pages/introduction-onboarding_faqs.mdx | 355 +++++++++++++++++++++++++ 5 files changed, 373 insertions(+), 282 deletions(-) delete mode 100644 pages/introduction-onboarding_faqs.md create mode 100644 pages/introduction-onboarding_faqs.mdx diff --git a/next.config.js b/next.config.js index ef283632..637d85a2 100644 --- a/next.config.js +++ b/next.config.js @@ -1,6 +1,10 @@ const withNextra = require('nextra')({ theme: 'nextra-theme-docs', themeConfig: './theme.config.tsx', + mdxOptions: { + remarkPlugins: [], + rehypePlugins: [], + }, }) module.exports = withNextra() diff --git a/package-lock.json b/package-lock.json index c7ff9592..28ffd20a 100644 --- a/package-lock.json +++ b/package-lock.json @@ -3564,66 +3564,6 @@ "type": "github", "url": "https://github.com/sponsors/wooorm" } - }, - "node_modules/@next/swc-android-arm-eabi": { - "version": "13.0.6", - "resolved": "https://registry.npmjs.org/@next/swc-android-arm-eabi/-/swc-android-arm-eabi-13.0.6.tgz", - "integrity": "sha512-FGFSj3v2Bluw8fD/X+1eXIEB0PhoJE0zfutsAauRhmNpjjZshLDgoXMWm1jTRL/04K/o9gwwO2+A8+sPVCH1uw==", - "cpu": [ - "arm" - ], - "optional": true, - "os": [ - "android" - ], - "engines": { - "node": ">= 10" - } - }, - "node_modules/@next/swc-android-arm64": { - "version": "13.0.6", - "resolved": "https://registry.npmjs.org/@next/swc-android-arm64/-/swc-android-arm64-13.0.6.tgz", - "integrity": "sha512-7MgbtU7kimxuovVsd7jSJWMkIHBDBUsNLmmlkrBRHTvgzx5nDBXogP0hzZm7EImdOPwVMPpUHRQMBP9mbsiJYQ==", - "cpu": [ - "arm64" - ], - "optional": true, - "os": [ - "android" - ], - "engines": { - "node": ">= 10" - } - }, - "node_modules/@next/swc-freebsd-x64": { - "version": "13.0.6", - "resolved": "https://registry.npmjs.org/@next/swc-freebsd-x64/-/swc-freebsd-x64-13.0.6.tgz", - "integrity": "sha512-6Lbxd9gAdXneTkwHyYW/qtX1Tdw7ND9UbiGsGz/SP43ZInNWnW6q0au4hEVPZ9bOWWRKzcVoeTBdoMpQk9Hx9w==", - "cpu": [ - "x64" - ], - "optional": true, - "os": [ - "freebsd" - ], - "engines": { - "node": ">= 10" - } - }, - "node_modules/@next/swc-linux-arm-gnueabihf": { - "version": "13.0.6", - "resolved": "https://registry.npmjs.org/@next/swc-linux-arm-gnueabihf/-/swc-linux-arm-gnueabihf-13.0.6.tgz", - "integrity": "sha512-wNdi5A519e1P+ozEuYOhWPzzE6m1y7mkO6NFwn6watUwO0X9nZs7fT9THmnekvmFQpaZ6U+xf2MQ9poQoCh6jQ==", - "cpu": [ - "arm" - ], - "optional": true, - "os": [ - "linux" - ], - "engines": { - "node": ">= 10" - } } } } diff --git a/pages/introduction-getting_started.md b/pages/introduction-getting_started.md index b74fbdbe..dc686d2c 100644 --- a/pages/introduction-getting_started.md +++ b/pages/introduction-getting_started.md @@ -9,27 +9,26 @@ **Trading via API** -Currently, dYdX natively hosts a TypeScript client. 3rd parties were also commissioned to build working Python and C++ clients. +Currently, dYdX natively hosts a TypeScript client. 3rd parties were also commissioned to build working Python and C++ clients. All clients are hosted in the [dydxprotocol/v4-clients](https://github.com/dydxprotocol/v4-clients) repo. -1. Links to the correct clients can be found in the chart below: - -| Client Type | Location | Built By | -| -------------- | ----------------- | ------------------------------- | -| TypeScript | [dYdX Repo](https://github.com/dydxprotocol/v4-clients/tree/main/v4-client-js) | dYdX Trading Inc. | -| Python | [3rd Party Repo](https://github.com/dydxprotocol/v4-chain/blob/main/README.md) | Raven DAO | -| C++ | [3rd Party Repo](https://github.com/asnefedovv/dydx-v4-client-cpp) | FastForward | - - -2. For the Python client please review this [setup guide](https://docs.dydx.exchange/guides/setting_up_raspberry_pi_for_api_trading) and this [user manual](https://docs.dydx.exchange/guides/cli_python_script). +| Client Type | Built By | +| ------------------------------------------------------------------------------- | ----------------- | +| [TypeScript](https://github.com/dydxprotocol/v4-clients/tree/main/v4-client-js) | dYdX Trading Inc. | +| [Python](https://github.com/dydxprotocol/v4-clients/tree/main/v4-client-py) | Raven DAO | +| [C++](https://github.com/dydxprotocol/v4-clients/tree/main/v4-client-cpp) | FastForward | **Trading via Web** -1. dYdX Operations Services Ltd. deployment of the dYdX web app at [dydx.trade](https://dydx.trade) +| Deployment | Web App Site | Deployed By | +| ---------- | ------------------------------------------------------------- | ----------------------------- | +| Mainnet | [dydx.trade](https://dydx.trade) | dYdX Operations Services Ltd. | +| Testnet | [v4.testnet.dydx.exchange](https://v4.testnet.dydx.exchange/) | dYdX Trading Inc. | **Trading via Mobile** -1. Download the mobile app for the dYdX Operations Services Ltd. deployment of dYdX Chain [iOS](https://apps.apple.com/bg/app/dydx/id6475599596) or for Android _(coming soon)_ - - +| Platform | Link | Deployed By | +| -------------- | -------------------------------------------------------------------- | ----------------------------- | +| iOS | https://apps.apple.com/bg/app/dydx/id6475599596 | dYdX Operations Services Ltd. | +| Android (Beta) | https://play.google.com/store/apps/details?id=trade.opsdao.dydxchain | dYdX Operations Services Ltd. | _dYdX Trading Inc. ("dYdX") does not control or operate any public deployments of dYdX Chain. Any use of the dYdX Chain documentation hub and dYdX Chain software is subject to dYdX's [Terms and Policies](https://docs.dydx.exchange/terms_and_policies/terms_of_use_and_privacy_policy)._ diff --git a/pages/introduction-onboarding_faqs.md b/pages/introduction-onboarding_faqs.md deleted file mode 100644 index e1944ea7..00000000 --- a/pages/introduction-onboarding_faqs.md +++ /dev/null @@ -1,207 +0,0 @@ -# Onboarding FAQs - -## Intro - -1. Can you give an overview of the structure of the network and the role full nodes/validators play in constructing the orderbook and participating in block building, and how trades are placed? - - dYdX Chain (or "v4") is composed of full nodes and each maintains an in-memory order book. Anyone can use the open source software to run a full node. Traders can submit order placements and cancellations to full nodes, which gossip the transactions amongst themselves. - - Full nodes with enough delegated layer 1 governance tokens participate in block building as validators. Validators on dYdX Chain take turns proposing blocks of trades every ~1 second. The validator whose turn it is to propose a block at a given height is called the proposer. The proposer uses its mempool orderbook to propose a block of matches, which validators either accept or reject according to CometBFT (Tendermint) consensus. - - All full nodes have visibility into the consensus process and the transactions in the mempool. Another component of dYdX Chain is the indexer software, an application that reads data from full nodes and exposes it via REST / WebSocket APIs for convenience. - -2. What is the difference between a full node and a validator? - - A full node does not participate in consensus. It receives data from other full nodes and validators in the network via the gossip protocol. A validator participates in consensus by broadcasting votes signed by each validator’s private keys. - -3. What are the benefits of running a full node as a market maker? - - Running a full node will eliminate the latency between placing an order and when the actual order is gossipped throughout the network. Without your own node, your order will need to first be relayed to the nearest geographic node, which will then propagate it throughout the network for you. With your own node, your order will directly be gossiped. - - Instructions on how to set up a full node can be found [here](https://docs.dydx.exchange/validators/how_to_set_up_full_node). - -4. What is the current block time? - - The current block time is ~1 second on average - -5. What is an indexer? - - The indexer is a read-only service that consumes real time data from dYdX Chain to a database for visibility to users. The indexer consumes data from dYdX Chain via a connection to a full node. The full node contains a copy of the blockchain and an in-memory order book. When the full node updates its copy of the blockchain and in-memory order book due to processing transactions, it will also stream these updates to the indexer. The indexer keeps the data in its database synced with the full-node using these updates. This data is made available to users querying through HTTPS REST APIs and streaming via websockets. More info can be found [here](https://docs.dydx.exchange/architecture/indexer). - -## Trading on an Exchange Run on dYdX Chain - -1. What are the different order types in dYdX Chain? - - There are two order types: Short-Term orders and stateful orders. - - Short-Term orders are meant for programmatic, low-latency traders that want to place orders with shorter expirations. - - Stateful orders are meant for retail that wants to place orders with longer expirations. These orders exist on chain. - -2. How does the orderbook work in dYdX Chain for short-term orders? - - Each validator runs their own in-memory orderbook (also known as mempool), and the set of orders each validator knows about is what order placement transactions are in their mempool. - - User places a trade on a decentralized front end (e.g., website) or via the typescript or python client that places orders directly to a full node or validatorAPI - - The consensus process picks one validator to be the block proposer. The selected validator will propose their view of the matches in the next proposed block. - - If the matches are valid (orders cross, subaccounts well-collateralized, etc.) and accepted by ⅔+ of validator stake weight (consensus), then the block is committed and those matches are written to state as valid matches. - - After the block is committed, the updated on-chain (and off-chain) data is streamed from full nodes to Indexers. The Indexer then makes this data available via API and websockets back to the front end and/or any other outside services querying for this data. - - Note: the block proposer’s matches are the canonical matches for the next block assuming their block is accepted by consensus. - - Other validators maintain a list of matches and those matches might differ from the block proposer’s matches, but if they’re not the block proposer those matches will not be proposed in the next block. - - Similarly, the indexer is not the block proposer so its list of matches might be different from the block proposer’s matches, until the network reaches finality. - -3. Why should market makers only use short-term orders? - - Short-Term orders are placed and can be immediately matched after they’re added to the mempool, while stateful orders can only be placed and matched after they’re added to a block. - - Short-Term orders should always have superior time priority to stateful orders. - - Stateful orders have worse time priority since they can only be matched after they are included on the block, short-term orders can be matched in the same block - - Short-Term orders have less restrictive rate limits than stateful order rate limits. See rate limits later on in this section - - Short-Term orders can be replaced, and stateful orders currently don’t support replacement. - - Short-Term orders can be canceled immediately after they’re placed, while stateful orders can only be canceled after they’ve been included in a block. - - Short-Term orders can be received by validators in any order, while stateful orders have an ordering requirement and will fail to be placed if they’re received out of order. - - This is because stateful orders use a “sequence number”, which is equivalent to a nonce on Ethereum. Short-Term orders don’t use this. - -4. How can I understand how finality works on dYdX Chain? - - When your order fills, a block proposer will propose a block containing the fill (visible to the whole network), and then the block will go through consensus. If the block is valid it will be finalized a couple seconds later (in Cosmos-speak this happens at the “commit” stage of consensus after all validators have voted). At that point, an indexer service will communicate the fill to you. - - It is recommended to post orders with a “Good-Til-Block” of the current block height, and adjusting prices once per block. If the block is published without a match to your order, you know that it is no longer active and did not fill. - -5. How can I place a short-term order? - - Please use the latest dYdX Chain [typescript client](https://www.npmjs.com/package/@dydxprotocol/v4-client-js) to place orders - - Please refer to the [order.proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/clob/order.proto) for parameter and field definitions - - For more advanced order placements, please refer to the validator client [v4-proto-js](https://github.com/dydxprotocol/v4-chain/tree/76ef1aefc1bc7ab393c20512e0940ea2be018cdc/v4-proto-js) or [v4-proto-py](https://github.com/dydxprotocol/v4-chain/tree/76ef1aefc1bc7ab393c20512e0940ea2be018cdc/v4-proto-py). - -6. How can I tell if the block proposer has placed my short-term order? - - The block proposer has proposed and filled the order in the block. - - The block proposer has the order in their mempool. - -7. How can I tell if my short-term order is canceled? - - Short-term order placements and cancellations are best-effort, and therefore their cancels and placement can't be considered actually canceled and unfillable until expiry - - A FOK or IOC order can also be seen as canceled if a fill does not occur after expiry - - The indexer does not send a websocket notification if a short-term order has been canceled - - However, since the goodTilBlock for the cancel needs to be set when placing the cancel, the block height can be checked to ensure that the cancel was successful - - This is lower latency than what a websocket notification could provide - -8. How can I replace an order? - - Replacing an order reuses the short-term order placement function with the [same order ID](https://github.com/dydxprotocol/v4-chain/blob/76ef1aefc1bc7ab393c20512e0940ea2be018cdc/proto/dydxprotocol/clob/order.proto#L10) and an equal-to-or-greater good til block - - Note: when replacing partially-filled orders, the previous fill amount is counted towards your current order. - - Example: Buy 1 BTC order @ $20k is filled for 0.5 BTC. After replacing that order with a Buy 2 BTC order @ $25k, that order can only be filled for a maximum of 1.5 BTC. This is because the previously replaced order was already filled for 0.5 BTC. - -9. Are fills computed/updates steamed only when a block is finalized? How about order placements? - - Fills are computed only when a block is finalized - - Short term order place / cancel (including IOC / FOK orders being canceled due to not filling / being on the book or POST-ONLY orders crossing) are streamed when the full node the Indexer deployment is listening to receives the order / cancel and not only when the block is finalized - - This is why the status “BEST_EFFORT_OPENED” or “BEST_EFFORT_CANCELED” since the Indexer only knows that a full-node received the order / cancel, and it’s not guaranteed to be true across the whole network - - For the orderbook updates, these are sent when the full-node the Indexer is listening to receives orders / cancels and not just when the block is finalized - - For example, when the full-node receives a short term order it will be approximate how much is filled and how much would go on the orderbook. This is what the Indexer uses to stream orderbook updates. However, there is no guarantee that the orderbook looks the same in other nodes in the network - - Note that you can now stream the orderbook directly through your full node for the orderbook. Read more about that [here](https://docs.dydx.exchange/guides/orderbook_stream). - -10. Do orders get matched and removed from the book in between blocks? - - For removal of short term orders, yes they can be removed in between blocks, however this is on a node-by-node basis and not across the whole network - - E.g. a short-term order could be removed on one node, but still be present on another - - When a short-term order expires (current block height > goodtilBlock), then it is guaranteed to be removed from all nodes - - For removal of stateful orders, they can be removed from the book in-between blocks. This is on a node-by-node basis - - If the node removing the stateful orders is the block proposer, these stateful order removals will also be propagated to all other nodes, an be entirely removed from the network - - For all orders, regarding matching - - For matching, each node on the network will attempt to match the orders as they are received in-between blocks - - Per block, only 1 node (the block proposer) will propagate the matches it’s done during the block to all other nodes in the network. Validator nodes take turns being the block proposer based on their stake weight - - If a set of validators with ⅔+ of the stake weight of the network see the matches propagated as valid, then those matches are included in the block when finalized - - The only matches that occur on the network are the ones in the block - -11. Do certain order types have priority? Are cancels prioritized? - - Short term orders when received by a node will be matched against it’s in-memory orderbook - - Cancels of short-term orders are also processed by a node when received - - Stateful orders (long-term / conditional) are matched at the end of the block when they are received - - E.g. Stateful orders have at least a 1 block-time delay (it’s possible the order does not get included in the block) between a node receiving the order, and it being matched - - Stateful order placement will be processed AFTER short-term order placements and cancellations for a block - - Stateful order cancellations are also done at the end of the block they are received - - The stateful order cancellations are also processed AFTER short-term placements and cancellations for a block - - As mentioned above, only the matches from the block proposer will be included in the block (if a set of validators with ⅔+ of the stake weight of the network see the matches as valid) - -12. How does the order cancellation mechanism work? Is it necessary for the cancel instruction and the original order to be on the same validator for a successful cancel? What's the best practice to ensure order cancellation succeeds? - - Short-term: - - When validators receive a cancellation, if they don't already see a match for the order, they will remove the order from their order book - - Only once every validator receives the cancellation is when the order will no longer be able to be matched - - The other way an order would no longer be matchable is if the block height is past the good til block - - Long-term: - - Once a stateful order cancellation is included into a block, the order will be canceled and no longer matchable. This could take 1s+ for a cancelation to be included in a block - -13. Why is it slower to cancel orders than place orders? - - An order placement only needs to be on a single validator to have a match happen, but the cancellation has to have arrived at the block proposer, but since the BP rotates, to be completely sure that the order wont be matched, it has to arrive at all the validators who will be block proposer before the order expires. This is why cancelations seem to be guaranteed slower than placing / matching orders. - -14. How do order statuses transition for the Indexer, for short-term and long-term orders? - - Short-term - - Once the order is placed and seen by the Indexer's full-node, the order has status BEST_EFFORT_OPENED - - If the order is matched and has a fill in a block, the order has status OPEN - - If the order is fully-filled, the order has status FILLED - - If the order is canceled by a cancel order message, the order will be status BEST_EFFORT_CANCELED , the order may still have fills if other validator nodes haven't received the cancel message yet - - If the order expires due to the block height exceeding the good til block of the order, the order status will be CANCELED, the order no longer can be filled - - Long-term - - Once the order is placed and included in a block, the order has status OPEN - - If the order is fully filled, the order has status FILLED - - If the cancelation of the order is included in a block, the order has status CANCELED the order can no longer be filled - -15. How do subaccounts work on dYdX Chain? - - Each address’s subaccounts all fall under a single address, but they are labeled subaccount0, subaccount1, etc. This is unlike v3, where each subaccount was a secondary address. - - To begin trading, you need to make sure your funds are in your subaccount. You can do this two ways: - - Frontend: Simply leave your frontend open and it will automatically sweep. - - Backend: Simply transfer USDC to it like in [this example](https://github.com/dydxprotocol/v4-clients/blob/main/v4-client-js/examples/transfer_example_subaccount_transfer.ts). - -16. When I transfer funds to create a new subaccount (the only way to create new subaccount btw), do I need gas? - - Yes, you will need gas. Fortunately, both USDC and cosmos native DYDX can be used to pay for gas fees. This USDC must be in the main wallet and not another subaccount to pay for fees. - - To ensure this, the frontend leaves a small amount of USDC in your wallet when sweeping into your subaccount, to ensure there's enough to pay for gas. - -17. What impact do subaccounts have on rate limits? - - Rate limits are per account, and not per subaccount. - -18. How do we compete for liquidation orders? - - If you run a full-node, there is a liquidations daemon that has metrics on what accounts are up for liquidation orders, and they could try and compete for liquidations that way. - - However, this is not at all documented so you'll have to work it out by reading code. - -## Trading as it Relates to Validators - -1. How much throughput and latency can be expected from a self-hosted full node? Would having multiple full nodes in different regions improve speed? - - Throughput of up to 1500 orders / second from our load-testing. Latency depends on which validator is the proposer. Having multiple full-nodes in different regions where there are validators (so maybe 1 in Europe + 1 in Tokyo) would lead to improved latency. - -2. 0 Do validators communicate through a public P2P network, or is there an internal network? - - It's a public P2P network. - -3. What is the expected order-to-trade latency under normal conditions? - - Expected order → trade latency would be: - - Time for order to get from the node it was submitted to, to the proposer, so location dependent. - - Order match -> trade, probably at least 1 block so ~1.1s, could be more than 1 block. - -4. Compared to a full node, is it faster to submit transactions directly to the validator, or is it faster to broadcast to the next validator with block-producing rights? - - It would be faster to submit a transaction directly to the block proposer, the difference between a full-node / validator is negligible unless that validator was the proposer. - -5. Do you have some faster validators that we can send orders to? - - Validators usually don't expose the RPC endpoints for orders to be submitted to, and we also don't have a list of validator IPs. - -6. How do other teams improve their speed? - - Some teams are trying to get data about the order book / order updates from a full-node they are running to improve the latency to receiving data, as there is additional latency to getting order updates due to the Indexer systems having additional latency. We currently do not have documentation around this, but are working on it. - -## Indexer - -1. How does the indexer reconstruct the orderbook when it started/initial snapshot of the book? - - A full node is run alongside the Indexer and sends messages to the indexer when it receives orders either from the RPC or gossiped from other nodes, as well as any updates from: - - node pruning the order when it expires - another order that matches an order that the node received earlier - node removing order due to receiving a cancel from RPC or gossip - - The indexer also updates the order book whenever it receives these order messages. - -2. How does the indexer know what orders are in the book on start up? - - On a cold-start, a full-node would still have all the stateful orders and would send them to the indexer. For short-term orders, the full-node would not know them, nor would the indexer. Since short-term orders only are valid for 20 blocks, within 20 blocks the indexer would have an accurate view of the order book, but for the first 20 blocks it would not. - -## MEV - -1. How will dYdX Chain handle MEV? - - Unlike general purpose smart contract environments, the Cosmos infrastructure enables unique MEV solutions to be built that align a validator’s incentives with a user’s incentives. dYdX Chain has a framework where MEV is measured via a [dashboard](https://dydx.exchange/blog/distinguishing-mev-from-expected-noise) created by Skip Protocol. The first step would be to punish validators with slashing. Further proposed solutions are still being considered, and will be announced once finalized. - -2. When do I have finality related to fills? - - When your order fills, a block proposer proposes a block containing the fill (visible to the whole network), and then the block undergoes consensus. If the block is valid, it finalizes shortly thereafter (in Cosmos-speak this happens at the “commit” stage of consensus, after all validators have voted). In Cosmos, every block is final (no reorgs or forks). - - If you’re connected via full node, you’ll see each step of this process. If you’re connected via the indexer service, you’ll see order updates over webSocket as soon as each block is confirmed. - -3. Would deliberately taking already-canceled orders be considered an attack against makers? How can such attacks be mitigated? - - Nodes should respect cancels as soon as they receive them, if they don't then we see that as MEV and the aforementioned dashboard / metrics tracking MEV will track that. - -## Pricing - -1. How is the oracle price is computed? - - The oracle price has five parts: - - Skip Protocol Sidecar: side car that pulls price data from external sources and caches them for the validator to use [link](https://docs.skip.money/slinky/integrations/dydx) - - Vote Extensions: Every block during the Precommit stage, all validators will submit vote extensions for what they believe the oracle price of all tracked assets should be. - - Consensus: The block after VE are submitted, Slinky deterministically aggregates all VE from the previous block and proposes a new updated price which is voted into consensus. - - Module: updates the state based on the new price, also has logic for validation and etc [link](https://github.com/dydxprotocol/v4-chain/tree/af8b6a46fdecc77ef154fd7b32377b4fea92b3f8/protocol/x/prices) - - Params: determines the external sources and sensitivity [link](https://github.com/dydxprotocol/v4-testnets/blob/aa1c7ac589d6699124942a66c2362acad2e6f50d/dydx-testnet-4/genesis.json#L6106), these are configured per network (testnet genesis example), but should query the network config for these `dydxprotocold query prices list-market-param` - -## Rewards - -1. How will trading rewards work on dYdX Chain? - - Trading rewards are not controlled by dYdX. dYdX recommends that trading rewards could be calculated primarily based on total taker fees paid, along with a few other variables. The full proposed formula can be found [here](https://docs.dydx.exchange/getting_started/fees_rewards_parameters). These rewards could be distributed on a block by block basis (1-2 seconds). - -2. Will liquidity provider rewards exist in v4? - - Liquidity provider rewards in v4 are not controlled by dYdX. dYdX recommends that liquidity provider rewards should cease to exist in v4. Makers could be rewarded with a maker rebate ranging from 0.5bps to 1.1bps, based on their nominal volume and volume share. The full proposed fee schedule can be found [here](https://docs.dydx.exchange/getting_started/fees_rewards_parameters). diff --git a/pages/introduction-onboarding_faqs.mdx b/pages/introduction-onboarding_faqs.mdx new file mode 100644 index 00000000..46327a6e --- /dev/null +++ b/pages/introduction-onboarding_faqs.mdx @@ -0,0 +1,355 @@ +# Onboarding FAQs + +## Intro + +
+1. Can you give an overview of the structure of the network and the role full nodes/validators play in constructing the orderbook and participating in block building, and how trades are placed? + +- dYdX Chain (or "v4") is composed of full nodes and each maintains an in-memory order book. Anyone can use the open source software to run a full node. Traders can submit order placements and cancellations to full nodes, which gossip the transactions amongst themselves. +- Full nodes with enough delegated layer 1 governance tokens participate in block building as validators. Validators on dYdX Chain take turns proposing blocks of trades every ~1 second. The validator whose turn it is to propose a block at a given height is called the proposer. The proposer uses its mempool orderbook to propose a block of matches, which validators either accept or reject according to CometBFT (Tendermint) consensus. +- All full nodes have visibility into the consensus process and the transactions in the mempool. Another component of dYdX Chain is the indexer software, an application that reads data from full nodes and exposes it via REST / WebSocket APIs for convenience. + +
+ +
+2. What is the difference between a full node and a validator? + +- A full node does not participate in consensus. It receives data from other full nodes and validators in the network via the gossip protocol. A validator participates in consensus by broadcasting votes signed by each validator’s private keys. + +
+ +
+3. What are the benefits of running a full node as a market maker? + +- Running a full node will eliminate the latency between placing an order and when the actual order is gossiped throughout the network. Without your own node, your order will need to first be relayed to the nearest geographic node, which will then propagate it throughout the network for you. With your own node, your order will directly be gossiped. +- Instructions on how to set up a full node can be found [here](https://docs.dydx.exchange/validators/how_to_set_up_full_node). + +
+ +
+4. What is the current block time? + +- The current block time is ~1 second on average. + +
+ +
+5. What is an indexer? + +- The indexer is a read-only service that consumes real-time data from dYdX Chain to a database for visibility to users. The indexer consumes data from dYdX Chain via a connection to a full node. The full node contains a copy of the blockchain and an in-memory order book. When the full node updates its copy of the blockchain and in-memory order book due to processing transactions, it will also stream these updates to the indexer. The indexer keeps the data in its database synced with the full-node using these updates. This data is made available to users querying through HTTPS REST APIs and streaming via websockets. More info can be found [here](https://docs.dydx.exchange/architecture/indexer). + +
+ +## Trading on an Exchange Run on dYdX Chain + +
+1. What are the different order types in dYdX Chain? + +- There are two order types: Short-Term orders and stateful orders. + - Short-Term orders are meant for programmatic, low-latency traders that want to place orders with shorter expirations. + - Stateful orders are meant for retail that wants to place orders with longer expirations. These orders exist on chain. + +
+ +
+2. How does the orderbook work in dYdX Chain for short-term orders? + +- Each validator runs their own in-memory orderbook (also known as mempool), and the set of orders each validator knows about is what order placement transactions are in their mempool. +- User places a trade on a decentralized front end (e.g., website) or via the typescript or python client that places orders directly to a full node or validator API. +- The consensus process picks one validator to be the block proposer. The selected validator will propose their view of the matches in the next proposed block. +- If the matches are valid (orders cross, subaccounts well-collateralized, etc.) and accepted by ⅔+ of validator stake weight (consensus), then the block is committed and those matches are written to state as valid matches. +- After the block is committed, the updated on-chain (and off-chain) data is streamed from full nodes to Indexers. The Indexer then makes this data available via API and websockets back to the front end and/or any other outside services querying for this data. +- Note: the block proposer’s matches are the canonical matches for the next block assuming their block is accepted by consensus. + - Other validators maintain a list of matches and those matches might differ from the block proposer’s matches, but if they’re not the block proposer those matches will not be proposed in the next block. + - Similarly, the indexer is not the block proposer so its list of matches might be different from the block proposer’s matches, until the network reaches finality. + +
+ +
+3. Why should market makers only use short-term orders? + +- Short-Term orders are placed and can be immediately matched after they’re added to the mempool, while stateful orders can only be placed and matched after they’re added to a block. + - Short-Term orders should always have superior time priority to stateful orders. + - Stateful orders have worse time priority since they can only be matched after they are included on the block, short-term orders can be matched in the same block. +- Short-Term orders have less restrictive rate limits than stateful order rate limits. See rate limits later on in this section. +- Short-Term orders can be replaced, and stateful orders currently don’t support replacement. +- Short-Term orders can be canceled immediately after they’re placed, while stateful orders can only be canceled after they’ve been included in a block. +- Short-Term orders can be received by validators in any order, while stateful orders have an ordering requirement and will fail to be placed if they’re received out of order. + - This is because stateful orders use a “sequence number”, which is equivalent to a nonce on Ethereum. Short-Term orders don’t use this. + +
+ +
+4. How can I understand how finality works on dYdX Chain? + +- When your order fills, a block proposer will propose a block containing the fill (visible to the whole network), and then the block will go through consensus. If the block is valid it will be finalized a couple seconds later (in Cosmos-speak this happens at the “commit” stage of consensus after all validators have voted). At that point, an indexer service will communicate the fill to you. +- It is recommended to post orders with a “Good-Til-Block” of the current block height, and adjusting prices once per block. If the block is published without a match to your order, you know that it is no longer active and did not fill. + +
+ +
+5. How can I place a short-term order? + +- Please use the latest dYdX Chain [typescript client](https://www.npmjs.com/package/@dydxprotocol/v4-client-js) to place orders. +- Please refer to the [order.proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/clob/order.proto) for parameter and field definitions. +- For more advanced order placements, please refer to the validator client [v4-proto-js](https://github.com/dydxprotocol/v4-chain/tree/76ef1aefc1bc7ab393c20512e0940ea2be018cdc/v4-proto-js) or [v4-proto-py](https://github.com/dydxprotocol/v4-chain/tree/76ef1aefc1bc7ab393c20512e0940ea2be018cdc/v4-proto-py). + +
+ +
+6. How can I tell if the block proposer has placed my short-term order? + +- The block proposer has proposed and filled the order in the block. +- The block proposer has the order in their mempool. + +
+ +
+7. How can I tell if my short-term order is canceled? + +- Short-term order placements and cancellations are best-effort, and therefore their cancels and placement can't be considered actually canceled and unfillable until expiry. +- A FOK or IOC order can also be seen as canceled if a fill does not occur after expiry. +- The indexer does not send a websocket notification if a short-term order has been canceled. +- However, since the goodTilBlock for the cancel needs to be set when placing the cancel, the block height can be checked to ensure that the cancel was successful. +- This is lower latency than what a websocket notification could provide. + +
+ +
+8. How can I replace an order? + +- Replacing an order reuses the short-term order placement function with the [same order ID](https://github.com/dydxprotocol/v4-chain/blob/76ef1aefc1bc7ab393c20512e0940ea2be018cdc/proto/dydxprotocol/clob/order.proto#L10) and an equal-to-or-greater good til block. +- Note: when replacing partially-filled orders, the previous fill amount is counted towards your current order. + - Example: Buy 1 BTC order @ $20k is filled for 0.5 BTC. After replacing that order with a Buy 2 BTC order @ $25k, that order can only be filled for a maximum of 1.5 BTC. This is because the previously replaced order was already filled for 0.5 BTC. + +
+ +
+9. Are fills computed/updates streamed only when a block is finalized? How about order placements? + +- Fills are computed only when a block is finalized. +- Short term order place / cancel (including IOC / FOK orders being canceled due to not filling / being on the book or POST-ONLY orders crossing) are streamed when the full node the Indexer deployment is listening to receives the order / cancel and not only when the block is finalized. + - This is why the status “BEST_EFFORT_OPENED” or “BEST_EFFORT_CANCELED” since the Indexer only knows that a full-node received the order / cancel, and it’s not guaranteed to be true across the whole network. +- For the orderbook updates, these are sent when the full-node the Indexer is listening to receives orders / cancels and not just when the block is finalized. + - For example, when the full-node receives a short term order it will be approximate how much is filled and how much would go on the orderbook. This is what the Indexer uses to stream orderbook updates. However, there is no guarantee that the orderbook looks the same in other nodes in the network. +- Note that you can now stream the orderbook directly through your full node for the orderbook. Read more about that [here](https://docs.dydx.exchange/guides/orderbook_stream). + +
+ +
+10. Do orders get matched and removed from the book in between blocks? + +- For removal of short term orders, yes they can be removed in between blocks, however this is on a node-by-node basis and not across the whole network. + - E.g. a short-term order could be removed on one node, but still be present on another. + - When a short-term order expires (current block height > goodtilBlock), then it is guaranteed to be removed from all nodes. +- For removal of stateful orders, they can be removed from the book in-between blocks. This is on a node-by-node basis. + - If the node removing the stateful orders is the block proposer, these stateful order removals will also be propagated to all other nodes, and be entirely removed from the network. +- For all orders, regarding matching: + - For matching, each node on the network will attempt to match the orders as they are received in-between blocks. + - Per block, only 1 node (the block proposer) will propagate the matches it’s done during the block to all other nodes in the network. Validator nodes take turns being the block proposer based on their stake weight. + - If a set of validators with ⅔+ of the stake weight of the network see the matches propagated as valid, then those matches are included in the block when finalized. + - The only matches that occur on the network are the ones in the block. + +
+ +
+11. Do certain order types have priority? Are cancels prioritized? + +- Short term orders when received by a node will be matched against its in-memory orderbook. + - Cancels of short-term orders are also processed by a node when received. +- Stateful orders (long-term / conditional) are matched at the end of the block when they are received. + - E.g. Stateful orders have at least a 1 block-time delay (it’s possible the order does not get included in the block) between a node receiving the order, and it being matched. + - Stateful order placement will be processed AFTER short-term order placements and cancellations for a block. +- Stateful order cancellations are also done at the end of the block they are received. + - The stateful order cancellations are also processed AFTER short-term placements and cancellations for a block. +- As mentioned above, only the matches from the block proposer will be included in the block (if a set of validators with ⅔+ of the stake weight of the network see the matches as valid). + +
+ +
+12. How does the order cancellation mechanism work? Is it necessary for the cancel instruction and the original order to be on the same validator for a successful cancel? What's the best practice to ensure order cancellation succeeds? + +- Short-term: + - When validators receive a cancellation, if they don't already see a match for the order, they will remove the order from their order book. + - Only once every validator receives the cancellation is when the order will no longer be able to be matched. + - The other way an order would no longer be matchable is if the block height is past the good til block. +- Long-term: + - Once a stateful order cancellation is included into a block, the order will be canceled and no longer matchable. This could take 1s+ for a cancelation to be included in a block. + +
+ +
+13. Why is it slower to cancel orders than place orders? + +- An order placement only needs to be on a single validator to have a match happen, but the cancellation has to have arrived at the block proposer. Since the BP rotates, to be completely sure that the order won't be matched, it has to arrive at all the validators who will be block proposer before the order expires. This is why cancelations seem to be guaranteed slower than placing/matching orders. + +
+ +
+14. How do order statuses transition for the Indexer, for short-term and long-term orders? + +- Short-term: + - Once the order is placed and seen by the Indexer's full-node, the order has status BEST_EFFORT_OPENED. + - If the order is matched and has a fill in a block, the order has status OPEN. + - If the order is fully-filled, the order has status FILLED. + - If the order is canceled by a cancel order message, the order will have status BEST_EFFORT_CANCELED. The order may still have fills if other validator nodes haven't received the cancel message yet. + - If the order expires due to the block height exceeding the good til block of the order, the order status will be CANCELED. The order can no longer be filled. +- Long-term: + - Once the order is placed and included in a block, the order has status OPEN. + - If the order is fully filled, the order has status FILLED. + - If the cancelation of the order is included in a block, the order has status CANCELED. The order can no longer be filled. + +
+ +
+15. How do subaccounts work on dYdX Chain? + +- Each address’s subaccounts all fall under a single address, but they are labeled subaccount0, subaccount1, etc. This is unlike v3, where each subaccount was a secondary address. +- To begin trading, you need to make sure your funds are in your subaccount. You can do this two ways: + - Frontend: Simply leave your frontend open and it will automatically sweep. + - Backend: Simply transfer USDC to it like in [this example](https://github.com/dydxprotocol/v4-clients/blob/main/v4-client-js/examples/transfer_example_subaccount_transfer.ts). + +
+ +
+16. When I transfer funds to create a new subaccount (the only way to create new subaccount btw), do I need gas? + +- Yes, you will need gas. Fortunately, both USDC and cosmos native DYDX can be used to pay for gas fees. This USDC must be in the main wallet and not another subaccount to pay for fees. +- To ensure this, the frontend leaves a small amount of USDC in your wallet when sweeping into your subaccount, to ensure there's enough to pay for gas. + +
+ +
+17. What impact do subaccounts have on rate limits? + +- Rate limits are per account, and not per subaccount. + +
+ +
+18. How do we compete for liquidation orders? + +- If you run a full-node, there is a liquidations daemon that has metrics on what accounts are up for liquidation orders, and they could try and compete for liquidations that way. +- However, this is not at all documented so you'll have to work it out by reading code. + +
+ +## Trading as it Relates to Validators + +
+1. How much throughput and latency can be expected from a self-hosted full node? Would having multiple full nodes in different regions improve speed? + +- Throughput of up to 1500 orders/second from our load-testing. Latency depends on which validator is the proposer. Having multiple full-nodes in different regions where there are validators (so maybe 1 in Europe + 1 in Tokyo) would lead to improved latency. + +
+ +
+2. Do validators communicate through a public P2P network, or is there an internal network? + +- It's a public P2P network. + +
+ +
+3. What is the expected order-to-trade latency under normal conditions? + +- Expected order → trade latency would be: + - Time for order to get from the node it was submitted to, to the proposer, so location dependent. + - Order match -> trade, probably at least 1 block so ~1.1s, could be more than 1 block. + +
+ +
+4. Compared to a full node, is it faster to submit transactions directly to the validator, or is it faster to broadcast to the next validator with block-producing rights? + +- It would be faster to submit a transaction directly to the block proposer, the difference between a full-node/validator is negligible unless that validator was the proposer. + +
+ +
+5. Do you have some faster validators that we can send orders to? + +- Validators usually don't expose the RPC endpoints for orders to be submitted to, and we also don't have a list of validator IPs. + +
+ +
+6. How do other teams improve their speed? + +- Some teams are trying to get data about the order book/order updates from a full-node they are running to improve the latency to receiving data, as there is additional latency to getting order updates due to the Indexer systems having additional latency. We currently do not have documentation around this, but are working on it. + +
+ +## Indexer + +
+1. How does the indexer reconstruct the orderbook when it started/initial snapshot of the book? + +- A full node is run alongside the Indexer and sends messages to the indexer when it receives orders either from the RPC or gossiped from other nodes, as well as any updates from: + - node pruning the order when it expires. + - another order that matches an order that the node received earlier. + - node removing order due to receiving a cancel from RPC or gossip. +- The indexer also updates the order book whenever it receives these order messages. + +
+ +
+2. How does the indexer know what orders are in the book on start up? + +- On a cold-start, a full-node would still have all the stateful orders and would send them to the indexer. For short-term orders, the full-node would not know them, nor would the indexer. Since short-term orders only are valid for 20 blocks, within 20 blocks the indexer would have an accurate view of the order book, but for the first 20 blocks it would not. + +
+ +## MEV + +
+1. How will dYdX Chain handle MEV? + +- Unlike general-purpose smart contract environments, the Cosmos infrastructure enables unique MEV solutions to be built that align a validator’s incentives with a user’s incentives. dYdX Chain has a framework where MEV is measured via a [dashboard](https://dydx.exchange/blog/distinguishing-mev-from-expected-noise) created by Skip Protocol. The first step would be to punish validators with slashing. Further proposed solutions are still being considered, and will be announced once finalized. + +
+ +
+2. When do I have finality related to fills? + +- When your order fills, a block proposer proposes a block containing the fill (visible to the whole network), and then the block undergoes consensus. If the block is valid, it finalizes shortly thereafter (in Cosmos-speak this happens at the “commit” stage of consensus, after all validators have voted). In Cosmos, every block is final (no reorgs or forks). +- If you’re connected via full node, you’ll see each step of this process. If you’re connected via the indexer service, you’ll see order updates over webSocket as soon as each block is confirmed. + +
+ +
+3. Would deliberately taking already-canceled orders be considered an attack against makers? How can such attacks be mitigated? + +- Nodes should respect cancels as soon as they receive them, if they don't then we see that as MEV and the aforementioned dashboard/metrics tracking MEV will track that. + +
+ +## Pricing + +
+1. How is the oracle price computed? + +- The oracle price has five parts: + - Skip Protocol Sidecar: side car that pulls price data from external sources and caches them for the validator to use [link](https://docs.skip.money/slinky/integrations/dydx). + - Vote Extensions: Every block during the Precommit stage, all validators will submit vote extensions for what they believe the oracle price of all tracked assets should be. + - Consensus: The block after VE are submitted, Slinky deterministically aggregates all VE from the previous block and proposes a new updated price which is voted into consensus. + - Module: updates the state based on the new price, also has logic for validation and etc. [link](https://github.com/dydxprotocol/v4-chain/tree/af8b6a46fdecc77ef154fd7b32377b4fea92b3f8/protocol/x/prices). + - Params: determines the external sources and sensitivity [link](https://github.com/dydxprotocol/v4-testnets/blob/aa1c7ac589d6699124942a66c2362acad2e6f50d/dydx-testnet-4/genesis.json#L6106), these are configured per network (testnet genesis example), but should query the network config for these `dydxprotocold query prices list-market-param`. + +
+ +## Rewards + +
+1. How will trading rewards work on dYdX Chain? + +- Trading rewards are not controlled by dYdX. dYdX recommends that trading rewards could be calculated primarily based on total taker fees paid, along with a few other variables. The full proposed formula can be found [here](https://docs.dydx.exchange/getting_started/fees_rewards_parameters). These rewards could be distributed on a block by block basis (1-2 seconds). + +
+ +
+2. Will liquidity provider rewards exist in v4? + +- Liquidity provider rewards in v4 are not controlled by dYdX. dYdX recommends that liquidity provider rewards should cease to exist in v4. Makers could be rewarded with a maker rebate ranging from 0.5bps to 1.1bps, based on their nominal volume and volume share. The full proposed fee schedule can be found [here](https://docs.dydx.exchange/getting_started/fees_rewards_parameters). + +
From d10b58f571aa9cf3bc9fab38c95d99b1e41e1f4f Mon Sep 17 00:00:00 2001 From: James Jia Date: Wed, 29 May 2024 19:49:54 -0400 Subject: [PATCH 07/18] Fix links, format files (#211) * Fix links, format files * more fixes --- .../cli_commands.md | 2 +- .../how_to_send_usdc_from_ethereum_to_dydx.md | 6 +- pages/api_integration-developers/constants.md | 36 +-- .../how_to_interpret_block_data_for_trades.md | 2 +- .../rewards_fees_and_parameters.md | 24 +- .../_meta.json | 2 +- .../how_to_set_up_full_node.md | 12 +- .../required_node_configs.md | 2 +- .../running_full_node.md | 8 +- .../snapshots.md | 2 +- .../upgrades/performing_upgrades.md | 3 +- pages/introduction-getting_started.md | 2 +- pages/introduction-onboarding_faqs.md | 207 ++++++++++++++++++ pages/introduction-onboarding_faqs.mdx | 16 +- .../proposing_a_new_market.md | 36 +-- .../users-governance/slashing_a_validator.md | 4 +- .../users-governance/submitting_a_proposal.md | 4 +- pages/users-governance/voting.md | 2 +- 18 files changed, 288 insertions(+), 82 deletions(-) create mode 100644 pages/introduction-onboarding_faqs.md diff --git a/pages/api_integration-deposits_and_withdrawals/cli_commands.md b/pages/api_integration-deposits_and_withdrawals/cli_commands.md index 72616cc8..88791ed8 100644 --- a/pages/api_integration-deposits_and_withdrawals/cli_commands.md +++ b/pages/api_integration-deposits_and_withdrawals/cli_commands.md @@ -1,6 +1,6 @@ ## CLI commands -Note: Native token denoms for transfer amounts and fees can be found [here](../network/network_constants.md#native-token-denom) +Note: Native token denoms for transfer amounts and fees can be found [here](../infrastructure_providers-network/network_constants.mdx#native-token-denom) ### Deposit to Subaccount diff --git a/pages/api_integration-deposits_and_withdrawals/how_to_send_usdc_from_ethereum_to_dydx.md b/pages/api_integration-deposits_and_withdrawals/how_to_send_usdc_from_ethereum_to_dydx.md index fbf20b4a..de277470 100644 --- a/pages/api_integration-deposits_and_withdrawals/how_to_send_usdc_from_ethereum_to_dydx.md +++ b/pages/api_integration-deposits_and_withdrawals/how_to_send_usdc_from_ethereum_to_dydx.md @@ -1,9 +1,9 @@ # How to send USDC from Ethereum to dYdX ## Deployments -| Deployment | USDC Native Chain | USDC_ERC20_ADDRESS | TOKEN_MESSENGER_CONTRACT_ADDRESS | -|--------------------|-------------------|--------------------|----------------------------------| -| DYDX token holders | Ethereum | [0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48](https://etherscan.io/address/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48) | [0xBd3fa81B58Ba92a82136038B25aDec7066af3155](https://etherscan.io/address/0xbd3fa81b58ba92a82136038b25adec7066af3155) | +| Deployment | USDC Native Chain | USDC_ERC20_ADDRESS | TOKEN_MESSENGER_CONTRACT_ADDRESS | +| ------------------ | ----------------- | ----------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | +| DYDX token holders | Ethereum | [0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48](https://etherscan.io/address/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48) | [0xBd3fa81B58Ba92a82136038B25aDec7066af3155](https://etherscan.io/address/0xbd3fa81b58ba92a82136038b25adec7066af3155) | | Testnet | Sepolia Testnet | [0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238](https://sepolia.etherscan.io/address/0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238) | [0x9f3B8679c73C2Fef8b59B4f3444d4e156fb70AA5](https://sepolia.etherscan.io/address/0x9f3B8679c73C2Fef8b59B4f3444d4e156fb70AA5) | > **Note:** the example values in the steps below align with the **deployment by DYDX token holders**. diff --git a/pages/api_integration-developers/constants.md b/pages/api_integration-developers/constants.md index 71ad4724..22697930 100644 --- a/pages/api_integration-developers/constants.md +++ b/pages/api_integration-developers/constants.md @@ -1,25 +1,25 @@ # Constants -Name | Value | Description --|-|- -`sdk.DefaultPowerReduction`|`1e18`|The staking power is equal the number of staked-token coins divided by this number (to prevent overflow). This number typically denotes how many of the staked-token denom are considered to be equal to one canonical token. +| Name | Value | Description | +| --------------------------- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `sdk.DefaultPowerReduction` | `1e18` | The staking power is equal the number of staked-token coins divided by this number (to prevent overflow). This number typically denotes how many of the staked-token denom are considered to be equal to one canonical token. | # Module Accounts In Cosmos-SDK, a module account is an account with address generated by hashing a string. The module account has no known private key and is therefore only controlled by the state-machine and governance. Here we list the module account addresses (assuming the default HRP of `dydx`) and the hashed string that results in the address. -Module | Name | Address | String --|-|-|- -`x/auth`|Fee Collector|`dydx17xpfvakm2amg962yls6f84z3kell8c5leqdyt2`|`"fee_collector"` -`x/bridge`|Bridge Module|`dydx1zlefkpe3g0vvm9a4h0jf9000lmqutlh9jwjnsv`|`"bridge"` -`x/distribution`|Distribution Module|`dydx1jv65s3grqf6v6jl3dp4t6c9t9rk99cd8wx2cfg`|`"distribution"` -`x/staking`|Bonded Pool|`dydx1fl48vsnmsdzcv85q5d2q4z5ajdha8yu3uz8teq`|`"bonded_tokens_pool"` -`x/staking`|Not-Bonded Pool|`dydx1tygms3xhhs3yv487phx3dw4a95jn7t7lgzm605`|`"not_bonded_tokens_pool"` -`x/gov`|Gov Module|`dydx10d07y265gmmuvt4z0w9aw880jnsr700jnmapky`|`"gov"` -`x/ibc`|IBC Module|`dydx1yl6hdjhmkf37639730gffanpzndzdpmh8xcdh5`|`"transfer"` -`x/subaccounts`|Subaccounts Module|`dydx1v88c3xv9xyv3eetdx0tvcmq7ung3dywp5upwc6`|`"subaccounts"` -`x/clob`|Insurance Fund|`dydx1c7ptc87hkd54e3r7zjy92q29xkq7t79w64slrq`|`"insurance_fund"` -`x/rewards`|Rewards Treasury|`dydx16wrau2x4tsg033xfrrdpae6kxfn9kyuerr5jjp`|`"rewards_treasury"` -`x/rewards`|Rewards Vester|`dydx1ltyc6y4skclzafvpznpt2qjwmfwgsndp458rmp`|`"rewards_vester"` -`x/vest`|Community Treasury|`dydx15ztc7xy42tn2ukkc0qjthkucw9ac63pgp70urn`|`"community_treasury"` -`x/vest`|Community Vester|`dydx1wxje320an3karyc6mjw4zghs300dmrjkwn7xtk`|`"community_vester"` +| Module | Name | Address | String | +| ---------------- | ------------------- | --------------------------------------------- | -------------------------- | +| `x/auth` | Fee Collector | `dydx17xpfvakm2amg962yls6f84z3kell8c5leqdyt2` | `"fee_collector"` | +| `x/bridge` | Bridge Module | `dydx1zlefkpe3g0vvm9a4h0jf9000lmqutlh9jwjnsv` | `"bridge"` | +| `x/distribution` | Distribution Module | `dydx1jv65s3grqf6v6jl3dp4t6c9t9rk99cd8wx2cfg` | `"distribution"` | +| `x/staking` | Bonded Pool | `dydx1fl48vsnmsdzcv85q5d2q4z5ajdha8yu3uz8teq` | `"bonded_tokens_pool"` | +| `x/staking` | Not-Bonded Pool | `dydx1tygms3xhhs3yv487phx3dw4a95jn7t7lgzm605` | `"not_bonded_tokens_pool"` | +| `x/gov` | Gov Module | `dydx10d07y265gmmuvt4z0w9aw880jnsr700jnmapky` | `"gov"` | +| `x/ibc` | IBC Module | `dydx1yl6hdjhmkf37639730gffanpzndzdpmh8xcdh5` | `"transfer"` | +| `x/subaccounts` | Subaccounts Module | `dydx1v88c3xv9xyv3eetdx0tvcmq7ung3dywp5upwc6` | `"subaccounts"` | +| `x/clob` | Insurance Fund | `dydx1c7ptc87hkd54e3r7zjy92q29xkq7t79w64slrq` | `"insurance_fund"` | +| `x/rewards` | Rewards Treasury | `dydx16wrau2x4tsg033xfrrdpae6kxfn9kyuerr5jjp` | `"rewards_treasury"` | +| `x/rewards` | Rewards Vester | `dydx1ltyc6y4skclzafvpznpt2qjwmfwgsndp458rmp` | `"rewards_vester"` | +| `x/vest` | Community Treasury | `dydx15ztc7xy42tn2ukkc0qjthkucw9ac63pgp70urn` | `"community_treasury"` | +| `x/vest` | Community Vester | `dydx1wxje320an3karyc6mjw4zghs300dmrjkwn7xtk` | `"community_vester"` | diff --git a/pages/api_integration-guides/how_to_interpret_block_data_for_trades.md b/pages/api_integration-guides/how_to_interpret_block_data_for_trades.md index 6b97b111..07d236b2 100644 --- a/pages/api_integration-guides/how_to_interpret_block_data_for_trades.md +++ b/pages/api_integration-guides/how_to_interpret_block_data_for_trades.md @@ -8,7 +8,7 @@ In dYdX Chain trading, quantities and prices are represented in quantums (for qu The smallest increment of position size. Determined from `atomicResolution`. -atomicResolution - Determines the size of a quantum. [For example](https://github.com/dydxprotocol/v4/blob/08069ba905753158b9f390ca52e3f9f0fb2cb3d5/config.yml#L101), an `atomicResolution` of 10 for `BTC`, means that 1 quantum is `1e-10` `BTC`. +atomicResolution - Determines the size of a quantum. [For example](https://github.com/dydxprotocol/v4-testnets/blob/main/dydx-testnet-4/genesis.json#L5776), an `atomicResolution` of 10 for `BTC`, means that 1 quantum is `1e-10` `BTC`. ### Subticks diff --git a/pages/concepts-trading/rewards_fees_and_parameters.md b/pages/concepts-trading/rewards_fees_and_parameters.md index 4f19f5ae..4e68a69c 100644 --- a/pages/concepts-trading/rewards_fees_and_parameters.md +++ b/pages/concepts-trading/rewards_fees_and_parameters.md @@ -90,9 +90,9 @@ The open source software will not pre-populate any bank-state on the network. Va These parameters establish punishments for detrimental behavior by validators. -| | Signed Blocks Window | Min Signed Per Window | Downtime Jail Duration | Slash Fraction Doublesign | Slash Fraction Downtime | -|------------------|-------- |------------|---------------|---------------|----------------| -| Slashing Params | 8192 (-3 hrs)| 20% | 7200s | 0% | 0% | +| | Signed Blocks Window | Min Signed Per Window | Downtime Jail Duration | Slash Fraction Doublesign | Slash Fraction Downtime | +| --------------- | -------------------- | --------------------- | ---------------------- | ------------------------- | ----------------------- | +| Slashing Params | 8192 (-3 hrs) | 20% | 7200s | 0% | 0% | _SignedBlocksWindow_: Together with MinSignedPerWindow, specifies the number of blocks a validator must sign within a sliding window. Failure to maintain MinSignedPerWindow leads to validator being jailed (removed from active validator set). @@ -106,9 +106,9 @@ Double-signing by a validator is considered a severe violation as it can cause i These parameters handle the distribution of gas and trading fees generated by the network to validators. -| | Community Tax | WithdrawAddrEnable | -|------------------|-------- |------------| -| Distribution Params | 0% | True | +| | Community Tax | WithdrawAddrEnable | +| ------------------- | ------------- | ------------------ | +| Distribution Params | 0% | True | _CommunityTax_: Fraction of fees that goes to the community treasury. The software will initially reflect a 0% community tax. @@ -120,9 +120,9 @@ These parameters define how staking works on the protocol and norms around staki *MaxValidators and UnbondingTime are particularly subject to change based on public testnet data and feedback. -| | BondDenom | MaxValidators | MinCommissionRate | Unbonding Time | -|------------------|-------- |------------|---------------|---------------| -| Slashing Params | Decided at Genesis, by validators | 60 | 5% | 30 days | +| | BondDenom | MaxValidators | MinCommissionRate | Unbonding Time | +| --------------- | --------------------------------- | ------------- | ----------------- | -------------- | +| Slashing Params | Decided at Genesis, by validators | 60 | 5% | 30 days | _MaxValidators_: Every block, the top MaxValidators validators by stake weight are included in the active validator set. @@ -134,8 +134,8 @@ _MinCommissionRate_: The chain-wide minimum commission rate that a validator can These parameters define how governance proposals can be submitted and executed. For more information on the governance module and its associated parameters, head to the official [Cosmos SDK docs](https://docs.cosmos.network/v0.47/modules/gov#parameters). -| | Min Deposit | MinInitialDepositRatio | Max Deposit Period | Voting Period | Quorum | Threshold | Veto | -|------------------|-------- |------------|---------------|---------------|----------------|--|--| -| Gov Params | 10,000 governance token | 20% | 1 Days | 4 Days | 33.4% | 50% | 33.4% | +| | Min Deposit | MinInitialDepositRatio | Max Deposit Period | Voting Period | Quorum | Threshold | Veto | +| ---------- | ----------------------- | ---------------------- | ------------------ | ------------- | ------ | --------- | ----- | +| Gov Params | 10,000 governance token | 20% | 1 Days | 4 Days | 33.4% | 50% | 33.4% | diff --git a/pages/infrastructure_providers-network/_meta.json b/pages/infrastructure_providers-network/_meta.json index 68dc533e..5b0d6514 100644 --- a/pages/infrastructure_providers-network/_meta.json +++ b/pages/infrastructure_providers-network/_meta.json @@ -1,5 +1,5 @@ { "network_constants": "Network Constants", "resources": "Resources", - "faucet": "Funds" + "faucet": "Faucet Funds (Testnet Only)" } diff --git a/pages/infrastructure_providers-validators/how_to_set_up_full_node.md b/pages/infrastructure_providers-validators/how_to_set_up_full_node.md index 62c67007..cb637b40 100644 --- a/pages/infrastructure_providers-validators/how_to_set_up_full_node.md +++ b/pages/infrastructure_providers-validators/how_to_set_up_full_node.md @@ -5,7 +5,7 @@ 2. 8-cpu (ARM or x86_64), 64 GB RAM, 500 GB SSD NVME Storage ## Get the dydxprotocold binary and initialize the data directory -> **Note:** the example values below align with the **deployment by DYDX token holders**. For alternatives, please visit the [Network Constants page](https://docs.dydx.exchange/network/network_constants). +> **Note:** the example values below align with the **deployment by DYDX token holders**. For alternatives, please visit the [Network Constants page](../infrastructure_providers-network/network_constants.mdx). 1. From https://github.com/dydxprotocol/v4-chain/releases/ | Look for the `protocol` assets. 2. For example, as of `10/19/2023`, this was the correct binary to use: @@ -20,7 +20,7 @@ dydxprotocold init --chain-id=$CHAIN_ID --home=$DYDX_HOME $NODE_NICKNAME ``` ## Get the latest applicable genesis.json file and install -> **Note:** the example values below align with the **deployment by DYDX token holders**. For alternatives, please visit the [Network Resources page](../network/resources.md). +> **Note:** the example values below align with the **deployment by DYDX token holders**. For alternatives, please visit the [Network Resources page](../infrastructure_providers-network/resources.mdx). 1. Use ```bash @@ -32,7 +32,7 @@ to get the applicable Genesis state of the network. 3. (Alternatives): If the RPC endpoint above does not work, there are these alternatives: - https://dydx-dao-rpc.polkachu.com/genesis - https://dydx-mainnet-full-rpc.public.blastapi.io/genesis - - Also check [Full node endpoints → RPC](../network/resources.md#full-node-endpoints) + - Also check [Full node endpoints → RPC](../infrastructure_providers-network/resources.mdx#full-node-endpoints) ## Install Bware’s snapshot (optional but saves days) > **Note:** the example values below align with the **deployment by DYDX token holders**. For alternatives, please visit the [Network Resources page](../network/resources.md). @@ -42,12 +42,12 @@ to get the applicable Genesis state of the network. 3. (Alternatives): If the above is not available, there are these alternatives: - https://polkachu.com/tendermint_snapshots/dydx - https://dydx-archive-snapshot.kingnodes.com/ - - Also check [Snapshot service](../network/resources.md#snapshot-service) + - Also check [Snapshot service](../infrastructure_providers-network/resources.mdx#snapshot-service) ## Start the full node -> **Note:** the example values below align with the **deployment by DYDX token holders**. For alternatives, please visit the [Network Resources page](../network/resources.md). +> **Note:** the example values below align with the **deployment by DYDX token holders**. For alternatives, please visit the [Network Resources page](../infrastructure_providers-network/resources.mdx). -1. Start the full node. Note that you may need to change the `--p2p.seeds` parameter depending on the applicable v4 software blockchain network – you can find an example on [Resources page under “Seed nodes”](../network/resources.md#seed-nodes) +1. Start the full node. Note that you may need to change the `--p2p.seeds` parameter depending on the applicable v4 software blockchain network – you can find an example on [Resources page under “Seed nodes”](../infrastructure_providers-network/resources.mdx#seed-nodes) ```bash DYDX_HOME=/home/vmware/.dydx-mainnet-1 diff --git a/pages/infrastructure_providers-validators/required_node_configs.md b/pages/infrastructure_providers-validators/required_node_configs.md index b2a89ff7..6d6f6e40 100644 --- a/pages/infrastructure_providers-validators/required_node_configs.md +++ b/pages/infrastructure_providers-validators/required_node_configs.md @@ -25,7 +25,7 @@ timeout_commit = "500ms" #### Base Configuration -For value of `$NATIVE_TOKEN_DENOM`, see [Network Constants](../network/network_constants.md#native-token-denom) +Replace `$NATIVE_TOKEN_DENOM` at the end of the field with the correct value from [Network Constants](../infrastructure_providers-network/network_constants.md#native-token-denom) ``` ### Gas Prices ### diff --git a/pages/infrastructure_providers-validators/running_full_node.md b/pages/infrastructure_providers-validators/running_full_node.md index 4c18d424..5a15ab4f 100644 --- a/pages/infrastructure_providers-validators/running_full_node.md +++ b/pages/infrastructure_providers-validators/running_full_node.md @@ -2,7 +2,7 @@ ### Save your Chain ID in `dydxprotocold` config -Save the [chain-id](../network/network_constants.md#chain-id). This will make it so you do not have to manually pass in the chain-id flag for every CLI command. +Save the [chain-id](../infrastructure_providers-network/network_constants.mdx#chain-id). This will make it so you do not have to manually pass in the chain-id flag for every CLI command. ```bash dydxprotocold config chain-id $CHAIN_ID @@ -10,11 +10,11 @@ dydxprotocold config chain-id $CHAIN_ID ### Getting a Snapshot -See [snapshot service](../network/resources.md#snapshot-service). +See [snapshot service](../infrastructure_providers-network/resources.mdx#snapshot-service). ### Starting a Full Node -Find the seed node's ID and the IP address from [Resources](../network/resources.md#seed-nodes). Then, run the following command to start a non-validating full node. +Find the seed node's ID and the IP address from [Resources](../infrastructure_providers-network/resources.mdx#seed-nodes). Then, run the following command to start a non-validating full node. For example, ```bash @@ -39,7 +39,7 @@ Update `persistent_peers` in the config.toml file to include a randomly selecte ### Snapshots -Snapshots contain a compressed copy of the chain data which allow the full node to bootstrap to a recent state in the blockchain. A list of snapshot services can be found here https://docs.dydx.exchange/network/resources#snapshot-service. +Snapshots contain a compressed copy of the chain data which allow the full node to bootstrap to a recent state in the blockchain. A list of snapshot services can be found [here](../infrastructure_providers-network/resources.mdx#snapshot-service). ### State sync (Alternative to snapshots) diff --git a/pages/infrastructure_providers-validators/snapshots.md b/pages/infrastructure_providers-validators/snapshots.md index 1e3621ee..66ad222d 100644 --- a/pages/infrastructure_providers-validators/snapshots.md +++ b/pages/infrastructure_providers-validators/snapshots.md @@ -1,4 +1,4 @@ # Snapshots -Snapshots for the network can be found [here](../network/resources.md#snapshot-service) . +Snapshots for the network can be found [here](../infrastructure_providers-network/resources.mdx#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. diff --git a/pages/infrastructure_providers-validators/upgrades/performing_upgrades.md b/pages/infrastructure_providers-validators/upgrades/performing_upgrades.md index 60ac52ea..9aac2658 100644 --- a/pages/infrastructure_providers-validators/upgrades/performing_upgrades.md +++ b/pages/infrastructure_providers-validators/upgrades/performing_upgrades.md @@ -9,13 +9,12 @@ Validators can choose how to run a validator and manage software upgrades accord ## Voting for Upgrade Proposals -See [Governance -> Voting](../../governance/voting.md) +See [Governance -> Voting](../../users-governance/voting.md) ## Upgrades Releases for the dYdX chain will use [semantic versioning](https://semver.org/). See [here](./types_of_upgrades.md) for details. - ### ⚒️ Cosmovisor Users #### Upgrading to a new Major/Minor Version (e.g. v0.1.0) diff --git a/pages/introduction-getting_started.md b/pages/introduction-getting_started.md index dc686d2c..64d9fd25 100644 --- a/pages/introduction-getting_started.md +++ b/pages/introduction-getting_started.md @@ -31,4 +31,4 @@ Currently, dYdX natively hosts a TypeScript client. 3rd parties were also commis | iOS | https://apps.apple.com/bg/app/dydx/id6475599596 | dYdX Operations Services Ltd. | | Android (Beta) | https://play.google.com/store/apps/details?id=trade.opsdao.dydxchain | dYdX Operations Services Ltd. | -_dYdX Trading Inc. ("dYdX") does not control or operate any public deployments of dYdX Chain. Any use of the dYdX Chain documentation hub and dYdX Chain software is subject to dYdX's [Terms and Policies](https://docs.dydx.exchange/terms_and_policies/terms_of_use_and_privacy_policy)._ +_dYdX Trading Inc. ("dYdX") does not control or operate any public deployments of dYdX Chain. Any use of the dYdX Chain documentation hub and dYdX Chain software is subject to dYdX's [Terms and Policies](./other-terms_of_use_and_privacy_policy.md#native-token-denom)._ diff --git a/pages/introduction-onboarding_faqs.md b/pages/introduction-onboarding_faqs.md new file mode 100644 index 00000000..3a2abe7e --- /dev/null +++ b/pages/introduction-onboarding_faqs.md @@ -0,0 +1,207 @@ +# Onboarding FAQs + +## Intro + +1. Can you give an overview of the structure of the network and the role full nodes/validators play in constructing the orderbook and participating in block building, and how trades are placed? + - dYdX Chain (or "v4") is composed of full nodes and each maintains an in-memory order book. Anyone can use the open source software to run a full node. Traders can submit order placements and cancellations to full nodes, which gossip the transactions amongst themselves. + - Full nodes with enough delegated layer 1 governance tokens participate in block building as validators. Validators on dYdX Chain take turns proposing blocks of trades every ~1 second. The validator whose turn it is to propose a block at a given height is called the proposer. The proposer uses its mempool orderbook to propose a block of matches, which validators either accept or reject according to CometBFT (Tendermint) consensus. + - All full nodes have visibility into the consensus process and the transactions in the mempool. Another component of dYdX Chain is the indexer software, an application that reads data from full nodes and exposes it via REST / WebSocket APIs for convenience. + +2. What is the difference between a full node and a validator? + - A full node does not participate in consensus. It receives data from other full nodes and validators in the network via the gossip protocol. A validator participates in consensus by broadcasting votes signed by each validator’s private keys. + +3. What are the benefits of running a full node as a market maker? + - Running a full node will eliminate the latency between placing an order and when the actual order is gossipped throughout the network. Without your own node, your order will need to first be relayed to the nearest geographic node, which will then propagate it throughout the network for you. With your own node, your order will directly be gossiped. + - Instructions on how to set up a full node can be found [here](./infrastructure_providers-validators/how_to_set_up_full_node.md). + +4. What is the current block time? + - The current block time is ~1 second on average + +5. What is an indexer? + - The indexer is a read-only service that consumes real time data from dYdX Chain to a database for visibility to users. The indexer consumes data from dYdX Chain via a connection to a full node. The full node contains a copy of the blockchain and an in-memory order book. When the full node updates its copy of the blockchain and in-memory order book due to processing transactions, it will also stream these updates to the indexer. The indexer keeps the data in its database synced with the full-node using these updates. This data is made available to users querying through HTTPS REST APIs and streaming via websockets. More info can be found [here](./concepts-architecture/indexer.md). + +## Trading on an Exchange Run on dYdX Chain + +1. What are the different order types in dYdX Chain? + - There are two order types: Short-Term orders and stateful orders. + - Short-Term orders are meant for programmatic, low-latency traders that want to place orders with shorter expirations. + - Stateful orders are meant for retail that wants to place orders with longer expirations. These orders exist on chain. + +2. How does the orderbook work in dYdX Chain for short-term orders? + - Each validator runs their own in-memory orderbook (also known as mempool), and the set of orders each validator knows about is what order placement transactions are in their mempool. + - User places a trade on a decentralized front end (e.g., website) or via the typescript or python client that places orders directly to a full node or validatorAPI + - The consensus process picks one validator to be the block proposer. The selected validator will propose their view of the matches in the next proposed block. + - If the matches are valid (orders cross, subaccounts well-collateralized, etc.) and accepted by ⅔+ of validator stake weight (consensus), then the block is committed and those matches are written to state as valid matches. + - After the block is committed, the updated on-chain (and off-chain) data is streamed from full nodes to Indexers. The Indexer then makes this data available via API and websockets back to the front end and/or any other outside services querying for this data. + - Note: the block proposer’s matches are the canonical matches for the next block assuming their block is accepted by consensus. + - Other validators maintain a list of matches and those matches might differ from the block proposer’s matches, but if they’re not the block proposer those matches will not be proposed in the next block. + - Similarly, the indexer is not the block proposer so its list of matches might be different from the block proposer’s matches, until the network reaches finality. + +3. Why should market makers only use short-term orders? + - Short-Term orders are placed and can be immediately matched after they’re added to the mempool, while stateful orders can only be placed and matched after they’re added to a block. + - Short-Term orders should always have superior time priority to stateful orders. + - Stateful orders have worse time priority since they can only be matched after they are included on the block, short-term orders can be matched in the same block + - Short-Term orders have less restrictive rate limits than stateful order rate limits. See rate limits later on in this section + - Short-Term orders can be replaced, and stateful orders currently don’t support replacement. + - Short-Term orders can be canceled immediately after they’re placed, while stateful orders can only be canceled after they’ve been included in a block. + - Short-Term orders can be received by validators in any order, while stateful orders have an ordering requirement and will fail to be placed if they’re received out of order. + - This is because stateful orders use a “sequence number”, which is equivalent to a nonce on Ethereum. Short-Term orders don’t use this. + +4. How can I understand how finality works on dYdX Chain? + - When your order fills, a block proposer will propose a block containing the fill (visible to the whole network), and then the block will go through consensus. If the block is valid it will be finalized a couple seconds later (in Cosmos-speak this happens at the “commit” stage of consensus after all validators have voted). At that point, an indexer service will communicate the fill to you. + - It is recommended to post orders with a “Good-Til-Block” of the current block height, and adjusting prices once per block. If the block is published without a match to your order, you know that it is no longer active and did not fill. + +5. How can I place a short-term order? + - Please use the latest dYdX Chain [typescript client](https://www.npmjs.com/package/@dydxprotocol/v4-client-js) to place orders + - Please refer to the [order.proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/clob/order.proto) for parameter and field definitions + - For more advanced order placements, please refer to the validator client [v4-proto-js](https://github.com/dydxprotocol/v4-chain/tree/main/v4-proto-js) or [v4-proto-py](https://github.com/dydxprotocol/v4-chain/tree/main/v4-proto-py). + +6. How can I tell if the block proposer has placed my short-term order? + - The block proposer has proposed and filled the order in the block. + - The block proposer has the order in their mempool. + +7. How can I tell if my short-term order is canceled? + - Short-term order placements and cancellations are best-effort, and therefore their cancels and placement can't be considered actually canceled and unfillable until expiry + - A FOK or IOC order can also be seen as canceled if a fill does not occur after expiry + - The indexer does not send a websocket notification if a short-term order has been canceled + - However, since the goodTilBlock for the cancel needs to be set when placing the cancel, the block height can be checked to ensure that the cancel was successful + - This is lower latency than what a websocket notification could provide + +8. How can I replace an order? + - Replacing an order reuses the short-term order placement function with the [same order ID](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/clob/order.proto#L10) and an equal-to-or-greater good til block + - Note: when replacing partially-filled orders, the previous fill amount is counted towards your current order. + - Example: Buy 1 BTC order @ $20k is filled for 0.5 BTC. After replacing that order with a Buy 2 BTC order @ $25k, that order can only be filled for a maximum of 1.5 BTC. This is because the previously replaced order was already filled for 0.5 BTC. + +9. Are fills computed/updates steamed only when a block is finalized? How about order placements? + - Fills are computed only when a block is finalized + - Short term order place / cancel (including IOC / FOK orders being canceled due to not filling / being on the book or POST-ONLY orders crossing) are streamed when the full node the Indexer deployment is listening to receives the order / cancel and not only when the block is finalized + - This is why the status “BEST_EFFORT_OPENED” or “BEST_EFFORT_CANCELED” since the Indexer only knows that a full-node received the order / cancel, and it’s not guaranteed to be true across the whole network + - For the orderbook updates, these are sent when the full-node the Indexer is listening to receives orders / cancels and not just when the block is finalized + - For example, when the full-node receives a short term order it will be approximate how much is filled and how much would go on the orderbook. This is what the Indexer uses to stream orderbook updates. However, there is no guarantee that the orderbook looks the same in other nodes in the network + - Note that you can now stream the orderbook directly through your full node for the orderbook. Read more about that [here](./infrastructure_providers-validators/full_node_streaming.md). + +10. Do orders get matched and removed from the book in between blocks? + - For removal of short term orders, yes they can be removed in between blocks, however this is on a node-by-node basis and not across the whole network + - E.g. a short-term order could be removed on one node, but still be present on another + - When a short-term order expires (current block height > goodtilBlock), then it is guaranteed to be removed from all nodes + - For removal of stateful orders, they can be removed from the book in-between blocks. This is on a node-by-node basis + - If the node removing the stateful orders is the block proposer, these stateful order removals will also be propagated to all other nodes, an be entirely removed from the network + - For all orders, regarding matching + - For matching, each node on the network will attempt to match the orders as they are received in-between blocks + - Per block, only 1 node (the block proposer) will propagate the matches it’s done during the block to all other nodes in the network. Validator nodes take turns being the block proposer based on their stake weight + - If a set of validators with ⅔+ of the stake weight of the network see the matches propagated as valid, then those matches are included in the block when finalized + - The only matches that occur on the network are the ones in the block + +11. Do certain order types have priority? Are cancels prioritized? + - Short term orders when received by a node will be matched against it’s in-memory orderbook + - Cancels of short-term orders are also processed by a node when received + - Stateful orders (long-term / conditional) are matched at the end of the block when they are received + - E.g. Stateful orders have at least a 1 block-time delay (it’s possible the order does not get included in the block) between a node receiving the order, and it being matched + - Stateful order placement will be processed AFTER short-term order placements and cancellations for a block + - Stateful order cancellations are also done at the end of the block they are received + - The stateful order cancellations are also processed AFTER short-term placements and cancellations for a block + - As mentioned above, only the matches from the block proposer will be included in the block (if a set of validators with ⅔+ of the stake weight of the network see the matches as valid) + +12. How does the order cancellation mechanism work? Is it necessary for the cancel instruction and the original order to be on the same validator for a successful cancel? What's the best practice to ensure order cancellation succeeds? + - Short-term: + - When validators receive a cancellation, if they don't already see a match for the order, they will remove the order from their order book + - Only once every validator receives the cancellation is when the order will no longer be able to be matched + - The other way an order would no longer be matchable is if the block height is past the good til block + - Long-term: + - Once a stateful order cancellation is included into a block, the order will be canceled and no longer matchable. This could take 1s+ for a cancelation to be included in a block + +13. Why is it slower to cancel orders than place orders? + - An order placement only needs to be on a single validator to have a match happen, but the cancellation has to have arrived at the block proposer, but since the BP rotates, to be completely sure that the order wont be matched, it has to arrive at all the validators who will be block proposer before the order expires. This is why cancelations seem to be guaranteed slower than placing / matching orders. + +14. How do order statuses transition for the Indexer, for short-term and long-term orders? + - Short-term + - Once the order is placed and seen by the Indexer's full-node, the order has status BEST_EFFORT_OPENED + - If the order is matched and has a fill in a block, the order has status OPEN + - If the order is fully-filled, the order has status FILLED + - If the order is canceled by a cancel order message, the order will be status BEST_EFFORT_CANCELED , the order may still have fills if other validator nodes haven't received the cancel message yet + - If the order expires due to the block height exceeding the good til block of the order, the order status will be CANCELED, the order no longer can be filled + - Long-term + - Once the order is placed and included in a block, the order has status OPEN + - If the order is fully filled, the order has status FILLED + - If the cancelation of the order is included in a block, the order has status CANCELED the order can no longer be filled + +15. How do subaccounts work on dYdX Chain? + - Each address’s subaccounts all fall under a single address, but they are labeled subaccount0, subaccount1, etc. This is unlike v3, where each subaccount was a secondary address. + - To begin trading, you need to make sure your funds are in your subaccount. You can do this two ways: + - Frontend: Simply leave your frontend open and it will automatically sweep. + - Backend: Simply transfer USDC to it like in [this example](https://github.com/dydxprotocol/v4-clients/blob/main/v4-client-js/examples/transfer_example_subaccount_transfer.ts). + +16. When I transfer funds to create a new subaccount (the only way to create new subaccount btw), do I need gas? + - Yes, you will need gas. Fortunately, both USDC and cosmos native DYDX can be used to pay for gas fees. This USDC must be in the main wallet and not another subaccount to pay for fees. + - To ensure this, the frontend leaves a small amount of USDC in your wallet when sweeping into your subaccount, to ensure there's enough to pay for gas. + +17. What impact do subaccounts have on rate limits? + - Rate limits are per account, and not per subaccount. + +18. How do we compete for liquidation orders? + - If you run a full-node, there is a liquidations daemon that has metrics on what accounts are up for liquidation orders, and they could try and compete for liquidations that way. + - However, this is not at all documented so you'll have to work it out by reading code. + +## Trading as it Relates to Validators + +1. How much throughput and latency can be expected from a self-hosted full node? Would having multiple full nodes in different regions improve speed? + - Throughput of up to 1500 orders / second from our load-testing. Latency depends on which validator is the proposer. Having multiple full-nodes in different regions where there are validators (so maybe 1 in Europe + 1 in Tokyo) would lead to improved latency. + +2. 0 Do validators communicate through a public P2P network, or is there an internal network? + - It's a public P2P network. + +3. What is the expected order-to-trade latency under normal conditions? + - Expected order → trade latency would be: + - Time for order to get from the node it was submitted to, to the proposer, so location dependent. + - Order match -> trade, probably at least 1 block so ~1.1s, could be more than 1 block. + +4. Compared to a full node, is it faster to submit transactions directly to the validator, or is it faster to broadcast to the next validator with block-producing rights? + - It would be faster to submit a transaction directly to the block proposer, the difference between a full-node / validator is negligible unless that validator was the proposer. + +5. Do you have some faster validators that we can send orders to? + - Validators usually don't expose the RPC endpoints for orders to be submitted to, and we also don't have a list of validator IPs. + +6. How do other teams improve their speed? + - Some teams are trying to get data about the order book / order updates from a full-node they are running to improve the latency to receiving data, as there is additional latency to getting order updates due to the Indexer systems having additional latency. We currently do not have documentation around this, but are working on it. + +## Indexer + +1. How does the indexer reconstruct the orderbook when it started/initial snapshot of the book? + - A full node is run alongside the Indexer and sends messages to the indexer when it receives orders either from the RPC or gossiped from other nodes, as well as any updates from: + - node pruning the order when it expires + another order that matches an order that the node received earlier + node removing order due to receiving a cancel from RPC or gossip + - The indexer also updates the order book whenever it receives these order messages. + +2. How does the indexer know what orders are in the book on start up? + - On a cold-start, a full-node would still have all the stateful orders and would send them to the indexer. For short-term orders, the full-node would not know them, nor would the indexer. Since short-term orders only are valid for 20 blocks, within 20 blocks the indexer would have an accurate view of the order book, but for the first 20 blocks it would not. + +## MEV + +1. How will dYdX Chain handle MEV? + - Unlike general purpose smart contract environments, the Cosmos infrastructure enables unique MEV solutions to be built that align a validator’s incentives with a user’s incentives. dYdX Chain has a framework where MEV is measured via a [dashboard](https://dydx.exchange/blog/distinguishing-mev-from-expected-noise) created by Skip Protocol. The first step would be to punish validators with slashing. Further proposed solutions are still being considered, and will be announced once finalized. + +2. When do I have finality related to fills? + - When your order fills, a block proposer proposes a block containing the fill (visible to the whole network), and then the block undergoes consensus. If the block is valid, it finalizes shortly thereafter (in Cosmos-speak this happens at the “commit” stage of consensus, after all validators have voted). In Cosmos, every block is final (no reorgs or forks). + - If you’re connected via full node, you’ll see each step of this process. If you’re connected via the indexer service, you’ll see order updates over webSocket as soon as each block is confirmed. + +3. Would deliberately taking already-canceled orders be considered an attack against makers? How can such attacks be mitigated? + - Nodes should respect cancels as soon as they receive them, if they don't then we see that as MEV and the aforementioned dashboard / metrics tracking MEV will track that. + +## Pricing + +1. How is the oracle price is computed? + - The oracle price has five parts: + - Skip Protocol Sidecar: side car that pulls price data from external sources and caches them for the validator to use [link](https://docs.skip.money/slinky/integrations/dydx) + - Vote Extensions: Every block during the Precommit stage, all validators will submit vote extensions for what they believe the oracle price of all tracked assets should be. + - Consensus: The block after VE are submitted, Slinky deterministically aggregates all VE from the previous block and proposes a new updated price which is voted into consensus. + - Module: updates the state based on the new price, also has logic for validation and etc [link](https://github.com/dydxprotocol/v4-chain/tree/main/protocol/x/prices) + - Params: determines the external sources and sensitivity [link](https://github.com/dydxprotocol/v4-testnets/blob/main/dydx-testnet-4/genesis.json#L6106), these are configured per network (testnet genesis example), but should query the network config for these `dydxprotocold query prices list-market-param` + +## Rewards + +1. How will trading rewards work on dYdX Chain? + - Trading rewards are not controlled by dYdX. dYdX recommends that trading rewards could be calculated primarily based on total taker fees paid, along with a few other variables. The full proposed formula can be found [here](./concepts-trading/rewards_fees_and_parameters.md). These rewards could be distributed on a block by block basis (1-2 seconds). + +2. Will liquidity provider rewards exist in v4? + - Liquidity provider rewards in v4 are not controlled by dYdX. dYdX recommends that liquidity provider rewards should cease to exist in v4. Makers could be rewarded with a maker rebate ranging from 0.5bps to 1.1bps, based on their nominal volume and volume share. The full proposed fee schedule can be found [here](./concepts-trading/rewards_fees_and_parameters.md). diff --git a/pages/introduction-onboarding_faqs.mdx b/pages/introduction-onboarding_faqs.mdx index 46327a6e..a40e3fe4 100644 --- a/pages/introduction-onboarding_faqs.mdx +++ b/pages/introduction-onboarding_faqs.mdx @@ -22,7 +22,7 @@ 3. What are the benefits of running a full node as a market maker? - Running a full node will eliminate the latency between placing an order and when the actual order is gossiped throughout the network. Without your own node, your order will need to first be relayed to the nearest geographic node, which will then propagate it throughout the network for you. With your own node, your order will directly be gossiped. -- Instructions on how to set up a full node can be found [here](https://docs.dydx.exchange/validators/how_to_set_up_full_node). +- Instructions on how to set up a full node can be found [here](./infrastructure_providers-validators/how_to_set_up_full_node.md). @@ -92,7 +92,7 @@ - Please use the latest dYdX Chain [typescript client](https://www.npmjs.com/package/@dydxprotocol/v4-client-js) to place orders. - Please refer to the [order.proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/clob/order.proto) for parameter and field definitions. -- For more advanced order placements, please refer to the validator client [v4-proto-js](https://github.com/dydxprotocol/v4-chain/tree/76ef1aefc1bc7ab393c20512e0940ea2be018cdc/v4-proto-js) or [v4-proto-py](https://github.com/dydxprotocol/v4-chain/tree/76ef1aefc1bc7ab393c20512e0940ea2be018cdc/v4-proto-py). +- For more advanced order placements, please refer to one of the [validator clients](./introduction-getting_started.md#Trading-Via-Api). @@ -118,7 +118,7 @@
8. How can I replace an order? -- Replacing an order reuses the short-term order placement function with the [same order ID](https://github.com/dydxprotocol/v4-chain/blob/76ef1aefc1bc7ab393c20512e0940ea2be018cdc/proto/dydxprotocol/clob/order.proto#L10) and an equal-to-or-greater good til block. +- Replacing an order reuses the short-term order placement function with the [same order ID](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/clob/order.proto#L10) and an equal-to-or-greater good til block. - Note: when replacing partially-filled orders, the previous fill amount is counted towards your current order. - Example: Buy 1 BTC order @ $20k is filled for 0.5 BTC. After replacing that order with a Buy 2 BTC order @ $25k, that order can only be filled for a maximum of 1.5 BTC. This is because the previously replaced order was already filled for 0.5 BTC. @@ -132,7 +132,7 @@ - This is why the status “BEST_EFFORT_OPENED” or “BEST_EFFORT_CANCELED” since the Indexer only knows that a full-node received the order / cancel, and it’s not guaranteed to be true across the whole network. - For the orderbook updates, these are sent when the full-node the Indexer is listening to receives orders / cancels and not just when the block is finalized. - For example, when the full-node receives a short term order it will be approximate how much is filled and how much would go on the orderbook. This is what the Indexer uses to stream orderbook updates. However, there is no guarantee that the orderbook looks the same in other nodes in the network. -- Note that you can now stream the orderbook directly through your full node for the orderbook. Read more about that [here](https://docs.dydx.exchange/guides/orderbook_stream). +- Note that you can now stream the orderbook directly through your full node for the orderbook. Read more about that [here](./infrastructure_providers-validators/full_node_streaming.md).
@@ -333,8 +333,8 @@ - Skip Protocol Sidecar: side car that pulls price data from external sources and caches them for the validator to use [link](https://docs.skip.money/slinky/integrations/dydx). - Vote Extensions: Every block during the Precommit stage, all validators will submit vote extensions for what they believe the oracle price of all tracked assets should be. - Consensus: The block after VE are submitted, Slinky deterministically aggregates all VE from the previous block and proposes a new updated price which is voted into consensus. - - Module: updates the state based on the new price, also has logic for validation and etc. [link](https://github.com/dydxprotocol/v4-chain/tree/af8b6a46fdecc77ef154fd7b32377b4fea92b3f8/protocol/x/prices). - - Params: determines the external sources and sensitivity [link](https://github.com/dydxprotocol/v4-testnets/blob/aa1c7ac589d6699124942a66c2362acad2e6f50d/dydx-testnet-4/genesis.json#L6106), these are configured per network (testnet genesis example), but should query the network config for these `dydxprotocold query prices list-market-param`. + - Module: updates the state based on the new price, also has logic for validation and etc. [link](https://github.com/dydxprotocol/v4-chain/tree/main/protocol/x/prices). + - Params: determines the external sources and sensitivity [link](https://github.com/dydxprotocol/v4-testnets/blob/main/dydx-testnet-4/genesis.json#L6106), these are configured per network (testnet genesis example), but should query the network config for these `dydxprotocold query prices list-market-param`. @@ -343,13 +343,13 @@
1. How will trading rewards work on dYdX Chain? -- Trading rewards are not controlled by dYdX. dYdX recommends that trading rewards could be calculated primarily based on total taker fees paid, along with a few other variables. The full proposed formula can be found [here](https://docs.dydx.exchange/getting_started/fees_rewards_parameters). These rewards could be distributed on a block by block basis (1-2 seconds). +- Trading rewards are not controlled by dYdX. dYdX recommends that trading rewards could be calculated primarily based on total taker fees paid, along with a few other variables. The full proposed formula can be found [here](./concepts-trading/rewards_fees_and_parameters.md). These rewards could be distributed on a block by block basis (1-2 seconds).
2. Will liquidity provider rewards exist in v4? -- Liquidity provider rewards in v4 are not controlled by dYdX. dYdX recommends that liquidity provider rewards should cease to exist in v4. Makers could be rewarded with a maker rebate ranging from 0.5bps to 1.1bps, based on their nominal volume and volume share. The full proposed fee schedule can be found [here](https://docs.dydx.exchange/getting_started/fees_rewards_parameters). +- Liquidity provider rewards in v4 are not controlled by dYdX. dYdX recommends that liquidity provider rewards should cease to exist in v4. Makers could be rewarded with a maker rebate ranging from 0.5bps to 1.1bps, based on their nominal volume and volume share. The full proposed fee schedule can be found [here](./concepts-trading/rewards_fees_and_parameters.md).
diff --git a/pages/users-governance/proposing_a_new_market.md b/pages/users-governance/proposing_a_new_market.md index 779cdcb0..f01e6851 100644 --- a/pages/users-governance/proposing_a_new_market.md +++ b/pages/users-governance/proposing_a_new_market.md @@ -6,12 +6,12 @@ The proposal should consist of 4 messages to be executed **atomically and in order** when the proposal passes onchain. -| Message Index | Message | Description | Params Documentation | -|---------------|---------|-------------|----------------------| -| 0 | [MsgCreateOracleMarket](https://github.com/dydxprotocol/v4-chain/blob/0a01da5ba17b6ca26cef6c0e183c6676a1a4e5dc/proto/dydxprotocol/prices/tx.proto#L28) | Sets the oracle list and other parameters in `x/prices`, used by the protocol to track an oracle price | [MarketParams](https://github.com/dydxprotocol/v4-chain/blob/0a01da5ba17b6ca26cef6c0e183c6676a1a4e5dc/proto/dydxprotocol/prices/market_param.proto#L10) | -| 1 | [MsgCreatePerpetual](https://github.com/dydxprotocol/v4-chain/blob/316473cf115ee901a1371151512a8e97987f66da/proto/dydxprotocol/perpetuals/tx.proto#L31) | Sets the perpetual parameters in `x/perpetuals`, used by the protocol to represent a perpetual market. | [Params](https://github.com/dydxprotocol/v4-chain/blob/316473cf115ee901a1371151512a8e97987f66da/proto/dydxprotocol/perpetuals/params.proto#L7) | -| 2 | [MsgCreateClobPair](https://github.com/dydxprotocol/v4-chain/blob/35b87db422b0ef4138101ba73b0f00d16780ba89/proto/dydxprotocol/clob/tx.proto#L50) | Sets the orderbook parameters in `x/clob`, used by protocol to set up the market orderbook (in `INITIALIZING` status). | [ClobPair](https://github.com/dydxprotocol/v4-chain/blob/35b87db422b0ef4138101ba73b0f00d16780ba89/proto/dydxprotocol/clob/clob_pair.proto#L25) | -| 3 | [MsgDelayMessage](https://github.com/dydxprotocol/v4-chain/blob/35b87db422b0ef4138101ba73b0f00d16780ba89/proto/dydxprotocol/delaymsg/tx.proto#L18) | Transitions the orderbook created by `MsgCreateClobPair` to `ACTIVE` status, after some amount of blocks| [delay_blocks](https://github.com/dydxprotocol/v4-chain/blob/35b87db422b0ef4138101ba73b0f00d16780ba89/proto/dydxprotocol/delaymsg/tx.proto#L27) | +| Message Index | Message | Description | Params Documentation | +| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 0 | [MsgCreateOracleMarket](https://github.com/dydxprotocol/v4-chain/blob/0a01da5ba17b6ca26cef6c0e183c6676a1a4e5dc/proto/dydxprotocol/prices/tx.proto#L28) | Sets the oracle list and other parameters in `x/prices`, used by the protocol to track an oracle price | [MarketParams](https://github.com/dydxprotocol/v4-chain/blob/0a01da5ba17b6ca26cef6c0e183c6676a1a4e5dc/proto/dydxprotocol/prices/market_param.proto#L10) | +| 1 | [MsgCreatePerpetual](https://github.com/dydxprotocol/v4-chain/blob/316473cf115ee901a1371151512a8e97987f66da/proto/dydxprotocol/perpetuals/tx.proto#L31) | Sets the perpetual parameters in `x/perpetuals`, used by the protocol to represent a perpetual market. | [Params](https://github.com/dydxprotocol/v4-chain/blob/316473cf115ee901a1371151512a8e97987f66da/proto/dydxprotocol/perpetuals/params.proto#L7) | +| 2 | [MsgCreateClobPair](https://github.com/dydxprotocol/v4-chain/blob/35b87db422b0ef4138101ba73b0f00d16780ba89/proto/dydxprotocol/clob/tx.proto#L50) | Sets the orderbook parameters in `x/clob`, used by protocol to set up the market orderbook (in `INITIALIZING` status). | [ClobPair](https://github.com/dydxprotocol/v4-chain/blob/35b87db422b0ef4138101ba73b0f00d16780ba89/proto/dydxprotocol/clob/clob_pair.proto#L25) | +| 3 | [MsgDelayMessage](https://github.com/dydxprotocol/v4-chain/blob/35b87db422b0ef4138101ba73b0f00d16780ba89/proto/dydxprotocol/delaymsg/tx.proto#L18) | Transitions the orderbook created by `MsgCreateClobPair` to `ACTIVE` status, after some amount of blocks | [delay_blocks](https://github.com/dydxprotocol/v4-chain/blob/35b87db422b0ef4138101ba73b0f00d16780ba89/proto/dydxprotocol/delaymsg/tx.proto#L27) | Notes: @@ -48,18 +48,18 @@ The following decribes how to set various parameters for a new market and assume - Tick size is in the range of `[1, 10] bps` of the `reference_price` for markets in liquidity tier 1 and 2 and `[0.1, 1] bps` for markets in liquidity tier 0. - Minimum order size is `>= $1` and position size increments by approximately `$1`. -| Message Type | Field | Description | Value | -|--------------|-------|-------------|-------| -| `MsgCreateOracleMarket` | `exponent` | Denotes the number of decimals a value should be shifted in the price daemon | `p-9` | -| `MsgCreateOracleMarket` | `min_exchanges` | Used for an index price to be valid. | `3` | -| `MsgCreateOracleMarket` | `min_price_change_ppm` | The minimum amount the index price has to change for an oracle price update to be valid. | Liquidity Tier 0: `1000`
Liquidity Tier 1: `2500`
Liquidity Tier 2: `4000` | -| `MsgCreateOracleMarket` | `exchange_config_json` | Spot exchange query configuration for the oracle price | See [below](./proposing_a_new_market.md#Choosing-oracle-sources) | -| `MsgCreatePerpetual` | `atomic_resolution` | L the exponent for converting an atomic amount (`size = 1`) to a full coin. | `-6 - p` | -| `MsgCreatePerpetual` | `default_funding_ppm` | The default funding payment if there is no price premium. In parts-per-million. | `0` | -| `Msg[Update/Create]ClobPair` | `quantum_conversion_exponent` | `10^quantum_conversion_exponent` gives the number of quote quantum traded per base quantum. | `-9` | -| `Msg[Update/Create]ClobPair` | `subticks_per_tick` | Defines the tick size of the orderbook by defining how many subticks are in one tick. | Liquidity Tier 0: `100000`
Liquidity Tier 1 and 2 : `1000000` | -| `Msg[Update/Create]ClobPair` | `step_base_quantums` | (aka step size): min increment in the size of orders (number of coins) on the CLOB in base quantums. | `1000000` | -| `MsgDelayMessage` | `delay_blocks` | number of blocks before which the `MsgUpdateClobPair` is executed and transitions the market to `ACTIVE` | `3600` (equal to an hour at `1 sec` blocktime) | +| Message Type | Field | Description | Value | +| ---------------------------- | ----------------------------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | +| `MsgCreateOracleMarket` | `exponent` | Denotes the number of decimals a value should be shifted in the price daemon | `p-9` | +| `MsgCreateOracleMarket` | `min_exchanges` | Used for an index price to be valid. | `3` | +| `MsgCreateOracleMarket` | `min_price_change_ppm` | The minimum amount the index price has to change for an oracle price update to be valid. | Liquidity Tier 0: `1000`
Liquidity Tier 1: `2500`
Liquidity Tier 2: `4000` | +| `MsgCreateOracleMarket` | `exchange_config_json` | Spot exchange query configuration for the oracle price | See [below](./proposing_a_new_market.md#Choosing-oracle-sources) | +| `MsgCreatePerpetual` | `atomic_resolution` | L the exponent for converting an atomic amount (`size = 1`) to a full coin. | `-6 - p` | +| `MsgCreatePerpetual` | `default_funding_ppm` | The default funding payment if there is no price premium. In parts-per-million. | `0` | +| `Msg[Update/Create]ClobPair` | `quantum_conversion_exponent` | `10^quantum_conversion_exponent` gives the number of quote quantum traded per base quantum. | `-9` | +| `Msg[Update/Create]ClobPair` | `subticks_per_tick` | Defines the tick size of the orderbook by defining how many subticks are in one tick. | Liquidity Tier 0: `100000`
Liquidity Tier 1 and 2 : `1000000` | +| `Msg[Update/Create]ClobPair` | `step_base_quantums` | (aka step size): min increment in the size of orders (number of coins) on the CLOB in base quantums. | `1000000` | +| `MsgDelayMessage` | `delay_blocks` | number of blocks before which the `MsgUpdateClobPair` is executed and transitions the market to `ACTIVE` | `3600` (equal to an hour at `1 sec` blocktime) | ## Choosing oracle sources diff --git a/pages/users-governance/slashing_a_validator.md b/pages/users-governance/slashing_a_validator.md index e1303635..3eeab902 100644 --- a/pages/users-governance/slashing_a_validator.md +++ b/pages/users-governance/slashing_a_validator.md @@ -4,14 +4,14 @@ The chain supports slashing of misbehaving validators through governance vote. ## Proposal Message -The proposal should contain a single [MsgSlashValidator](https://github.com/dydxprotocol/v4-chain/blob/protocol/v4.0.0/proto/dydxprotocol/govplus/tx.proto#L1A9) message for each validator that should be slashed. +The proposal should contain a single [MsgSlashValidator](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/govplus/tx.proto#L19) message for each validator that should be slashed. Notes: - The slashing will occur when the proposal is passed, not the `infraction_height`. - The `infraction_height` must be set so that `time(proposal pass height) - time(infraction_height) < unbonding period`. Typically a good choice for `infraction_height` is the current height unless there is a recent unbonding undelegation/redelegation that should be included in the slash. In that case the `infraction_height` should be set prior to the initiation of the undelegation/redelegation. - Both `tokens_at_infraction_height` and `slash_factor` must be set correctly, otherwise undelegations and redelegations might be slashed disproportionately to the rest of the validator's stake. `tokens_at_infraction_height * slash_factor` determines the total amount of tokens to be slashed. Unbonding delegations and redelegations are first slashed by `slash_factor`, and then the remaining amount is taken from the validator's stake. - The x/staking `HistoricalInfo` query endpoint can be used to find the correct value for `tokens_at_infraction_height`. -- See the [MsgSlashValidator](https://github.com/dydxprotocol/v4-chain/blob/protocol/v4.0.0/proto/dydxprotocol/govplus/tx.proto#L19) inline comments for further details on the above requirements. +- See the [MsgSlashValidator](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/govplus/tx.proto#L19) inline comments for further details on the above requirements. ### Example Proposal Json diff --git a/pages/users-governance/submitting_a_proposal.md b/pages/users-governance/submitting_a_proposal.md index 9793f07e..bdd03dbb 100644 --- a/pages/users-governance/submitting_a_proposal.md +++ b/pages/users-governance/submitting_a_proposal.md @@ -6,14 +6,14 @@ For instructions on compiling the `protocold` binary locally, refer to the dYdX Alternatively, if your platform is supported by the prebuilt binaries found in the [releases section](https://github.com/dydxprotocol/v4-chain/releases) of the repository, you can opt to download and use these binaries directly. ## Save your Chain ID in `dydxprotocold` config -Save the [chain-id](../network/network_constants.md#chain-id). This will make it so you do not have to manually pass in the chain-id flag for every CLI command. +Save the [chain-id](../infrastructure_providers-network/network_constants.mdx#chain-id). This will make it so you do not have to manually pass in the chain-id flag for every CLI command. ```bash dydxprotocold config chain-id [chain_id] ``` ## Confirming Connectivity -To ensure that you are successfully connecting, use any of the RPC endpoints listed in the [resources](../network/resources.md). Remember to append `:443` to the end of the RPC URI for proper access. Execute the following command, replacing `[RPC ENDPOINT]` with your chosen endpoint: +To ensure that you are successfully connecting, use any of the RPC endpoints listed in the [resources](../infrastructure_providers-network/resources.mdx/resources.md). Remember to append `:443` to the end of the RPC URI for proper access. Execute the following command, replacing `[RPC ENDPOINT]` with your chosen endpoint: ```bash dydxprotocold status --node https://[RPC ENDPOINT]:443 diff --git a/pages/users-governance/voting.md b/pages/users-governance/voting.md index 93409872..b497c658 100644 --- a/pages/users-governance/voting.md +++ b/pages/users-governance/voting.md @@ -2,7 +2,7 @@ ## Save your Chain ID in `dydxprotocold` config -Save the [chain-id](../network/network_constants.md#chain-id). This will make it so you do not have to manually pass in the chain-id flag for every CLI command. +Save the [chain-id](../infrastructure_providers-network/network_constants.mdx#chain-id). This will make it so you do not have to manually pass in the chain-id flag for every CLI command. ```bash dydxprotocold config chain-id [chain_id] From 024e1b35537ba619b79576d07464a8cb4eb2de66 Mon Sep 17 00:00:00 2001 From: James Jia Date: Thu, 30 May 2024 12:37:51 -0400 Subject: [PATCH 08/18] [CT-876] Github Actions - Check Markdown Links (#212) * Test markdownlink check * test more, should fail? * another test * fix * fix file-extension * add caching * alive status codes * fix some files * remove slate * remove caching, not needed * split out workflow * Use quiet mode * fix * some more fixes * fix state sync link * ignore indexer link * fix config file * ignore releases links, false positive * fix rest of links --- .github/workflows/build-slate.yml | 35 --- .github/workflows/deploy-slate.yml | 57 ---- .github/workflows/link-check.yml | 26 ++ README.md | 8 + mlc_config.json | 19 ++ ...setting_up_raspberry_pi_for_api_trading.md | 2 +- pages/api_integration-trading/order_types.md | 4 +- .../short_term_vs_stateful.mdx | 32 +-- .../resources.mdx | 271 +++++++++--------- .../how_to_set_up_full_node.md | 2 +- .../required_node_configs.md | 2 +- .../running_full_node.md | 2 +- pages/introduction-onboarding_faqs.md | 207 ------------- pages/introduction-onboarding_faqs.mdx | 2 +- pages/users-governance/functionalities.md | 2 +- .../proposing_a_new_market.md | 2 +- .../users-governance/submitting_a_proposal.md | 2 +- 17 files changed, 217 insertions(+), 458 deletions(-) delete mode 100644 .github/workflows/build-slate.yml delete mode 100644 .github/workflows/deploy-slate.yml create mode 100644 .github/workflows/link-check.yml create mode 100644 mlc_config.json delete mode 100644 pages/introduction-onboarding_faqs.md diff --git a/.github/workflows/build-slate.yml b/.github/workflows/build-slate.yml deleted file mode 100644 index 11e662ae..00000000 --- a/.github/workflows/build-slate.yml +++ /dev/null @@ -1,35 +0,0 @@ -name: Build Slate docs - -on: - push: - branches: [ '*' ] - pull_request: - branches: [ '*' ] - -jobs: - build-and-test-slate: - runs-on: ubuntu-latest - defaults: - run: - working-directory: ${{ github.workspace }}/slate-docs - strategy: - matrix: - ruby-version: [2.7.0] - - steps: - - uses: actions/checkout@v2 - - - name: Set up Ruby - uses: ruby/setup-ruby@v1 - with: - ruby-version: ${{ matrix.ruby-version }} - - - uses: actions/cache@v1 - with: - path: vendor/bundle - key: gems-${{ runner.os }}-${{ matrix.ruby-version }}-${{ hashFiles('**/Gemfile.lock') }} - - - run: bundle config set deployment 'true' - - run: bundle install - - - run: bundle exec middleman build diff --git a/.github/workflows/deploy-slate.yml b/.github/workflows/deploy-slate.yml deleted file mode 100644 index 78a75e2c..00000000 --- a/.github/workflows/deploy-slate.yml +++ /dev/null @@ -1,57 +0,0 @@ -name: Deploy Slate docs - -on: - push: - branches: [ 'main' ] - -permissions: - contents: write - pull-requests: write - -jobs: - deploy: - runs-on: ubuntu-latest - defaults: - run: - working-directory: ${{ github.workspace }}/slate-docs - env: - ruby-version: 2.7.0 - - steps: - - uses: actions/checkout@v2 - - name: Set up Ruby - uses: ruby/setup-ruby@v1 - with: - ruby-version: ${{ env.ruby-version }} - - - uses: actions/cache@v1 - with: - path: vendor/bundle - key: gems-${{ runner.os }}-${{ env.ruby-version }}-${{ hashFiles('**/Gemfile.lock') }} - - - name: Install - run: | - bundle config set deployment 'true' - bundle install - - - name: Build - run: bundle exec middleman build - - - name: Disable jekyll builds - run: touch build/.nojekyll - - - name: Install Push Dependencies - run: npm i -g --silent gh-pages@2.0.1 - - - name: Configure Git - run: | - git config --global user.name "github_actions" - git config --global user.email "ci@dydx.exchange" - - - name: Deploy - env: - GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} - run: | - git remote set-url origin https://git:${GITHUB_TOKEN}@github.com/${GITHUB_REPOSITORY}.git - gh-pages --dotfiles --message "[skip ci] Updates" --dist build -u "github_actions " - diff --git a/.github/workflows/link-check.yml b/.github/workflows/link-check.yml new file mode 100644 index 00000000..40d8e954 --- /dev/null +++ b/.github/workflows/link-check.yml @@ -0,0 +1,26 @@ +name: Check Markdown links + +on: push + +jobs: + markdown-link-check-md: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v3 + - uses: gaurav-nelson/github-action-markdown-link-check@v1 + with: + file-extension: '.md' + folder-path: 'pages' + base-branch: 'main' + use-quiet-mode: 'yes' + + markdown-link-check-mdx: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v3 + - uses: gaurav-nelson/github-action-markdown-link-check@v1 + with: + file-extension: '.mdx' + folder-path: 'pages' + base-branch: 'main' + use-quiet-mode: 'yes' diff --git a/README.md b/README.md index e519d038..f611da4d 100644 --- a/README.md +++ b/README.md @@ -21,3 +21,11 @@ Start development server on localhost:3000: ```bash pnpm dev ``` + +## Formatting +To format .mdx files, you can use the [Prettier](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode) extension in VSCode. + +## Github Actions +Upon push of a commit, the following checks are made: +* [markdown-link-check](https://github.com/gaurav-nelson/github-action-markdown-link-check) checks that all links work. + * If you are configuring a link that is erroring out, considering adding something to the [mlc_config.json](./mlc_config.json) using [these options](https://github.com/tcort/markdown-link-check#config-file-format). diff --git a/mlc_config.json b/mlc_config.json new file mode 100644 index 00000000..26e08e42 --- /dev/null +++ b/mlc_config.json @@ -0,0 +1,19 @@ +{ + "aliveStatusCodes": [200, 403, 429], + "httpHeaders": [ + { + "urls": ["https://github.com/", "https://guides.github.com/", "https://help.github.com/", "https://docs.github.com/"], + "headers": { + "Accept-Encoding": "zstd, br, gzip, deflate" + } + } + ], + "ignorePatterns": [ + { + "pattern": "^https://indexer.dydx.trade" + }, + { + "pattern": "^https://github.com/dydxprotocol/v4-chain/releases/" + } + ] +} diff --git a/pages/api_integration-guides/setting_up_raspberry_pi_for_api_trading.md b/pages/api_integration-guides/setting_up_raspberry_pi_for_api_trading.md index 753aa9d2..b5d34cc8 100644 --- a/pages/api_integration-guides/setting_up_raspberry_pi_for_api_trading.md +++ b/pages/api_integration-guides/setting_up_raspberry_pi_for_api_trading.md @@ -13,7 +13,7 @@ `sudo apt-get update` `sudo apt-get upgrade` 6. Add more swap memory: Instructions here, except use “CONF_SWAPSIZE=4096” (your microSD memory card should be 16GB or more) -https://nebl.io/neblio-university/enabling-increasing-raspberry-pi-swap/ +https://web.archive.org/web/20240228194730/https://nebl.io/neblio-university/enabling-increasing-raspberry-pi-swap/ 7. Reboot with: `sudo shutdown -r 0` 8. For the next part, you will need to know how to use the ‘vi’ text editor. Take the simple tutorial here: diff --git a/pages/api_integration-trading/order_types.md b/pages/api_integration-trading/order_types.md index c5a6d0f3..31c4b8b0 100644 --- a/pages/api_integration-trading/order_types.md +++ b/pages/api_integration-trading/order_types.md @@ -1,10 +1,10 @@ # Order Execution Options ## Fill or Kill Order (FOK) -A Fill or Kill order is an immediate execution order that will either be fulfilled in its entirety or completely cancelled. Fill or Kill can only be set on non-long term orders ([short-term or stateful](https://docs.dydx.exchange/trading/short_term_vs_stateful)). Fill or Kill orders cannot be maker orders. +A Fill or Kill order is an immediate execution order that will either be fulfilled in its entirety or completely cancelled. Fill or Kill can only be set on non-long term orders ([short-term or stateful](./short_term_vs_stateful.mdx)). Fill or Kill orders cannot be maker orders. ## Immediate or Cancel Order (IOC) -An Immediate or Cancel order is an immediate execution order that will be filled against the book. Any remaining size will be cancelled. Immediate or Cancel can only be set on non-long term orders ([short-term or stateful](https://docs.dydx.exchange/trading/short_term_vs_stateful)). Immediate or cancel orders cannot be maker orders. +An Immediate or Cancel order is an immediate execution order that will be filled against the book. Any remaining size will be cancelled. Immediate or Cancel can only be set on non-long term orders ([short-term or stateful](../api_integration-trading/short_term_vs_stateful.mdx)). Immediate or cancel orders cannot be maker orders. ## Reduce Only Order (RO) diff --git a/pages/api_integration-trading/short_term_vs_stateful.mdx b/pages/api_integration-trading/short_term_vs_stateful.mdx index e5b4ea40..bdc371b9 100644 --- a/pages/api_integration-trading/short_term_vs_stateful.mdx +++ b/pages/api_integration-trading/short_term_vs_stateful.mdx @@ -3,24 +3,24 @@ -*****************Note: “Placed” in this document refers to an order which has gone through taker order matching via memclob.PlaceOrder. An order can exist in state without having been placed yet.***************** +********\*********Note: “Placed” in this document refers to an order which has gone through taker order matching via memclob.PlaceOrder. An order can exist in state without having been placed yet.********\********* For more details on definitions, see the v4-chain repo [here](https://github.com/dydxprotocol/v4-chain). -| | Short-term | Stateful | -| --- | --- | --- | -| purpose | Short-lived orders which are meant to placed immediately (in the same block the order was received). These orders stay in-memory up to 20 blocks, with only their fill amount and expiry block height being committed to state. Intended for use by market makers with high throughput, or for market orders. IoC and FoK orders are also considered short-term orders. Short-term orders do not survive a network restart.
  • • User would send a short-term transaction to a validator
  • • The transaction needs to contain exactly one Cosmos msg, and that msg is a [MsgPlaceOrder](https://github.com/dydxprotocol/v4-proto/blob/4b721881fdfe99485336e221def03dc5b86eb0a1/dydxprotocol/clob/tx.proto#L37C1-L38C1)
  • • Each validator has a [MsgProposedOperations](https://github.com/dydxprotocol/v4-proto/blob/4b721881fdfe99485336e221def03dc5b86eb0a1/dydxprotocol/clob/tx.proto#L27C1-L28C1), which is one validator’s view of the operations queue
  • • In the context of short-term orders, the block proposer should eventually be gossiped the short-term order and have it in their MsgProposedOperations
  • • The block proposer would then optimistically place the short-term order in [CheckTx](https://docs.cosmos.network/main/basics/tx-lifecycle)
  • • Matches that short term orders were included in block during MsgProposedOperations would be included in block for all the validators in the network during [DeliverTx](https://docs.cosmos.network/main/basics/tx-lifecycle)
| Long-lived orders which may execute far in the future. These orders should not be lost during a validator restart (placed in the block after the order was received). In the event a validator restarts, all stateful orders are [placed back onto the in-memory orderbook](https://github.com/dydxprotocol/v4-chain/blob/95b59028af247c0a93ef72de9bfd09a645d30eb1/protocol/app/app.go#L1125). Likely to be used primarily by retail traders. The front end would be sending stateful orders for all order types other than market orders.

Two types of stateful orders:

1. Long-Term Orders
• meant to be added to the orderbook as soon as possible. Due to certain technical limitations, long-term orders are placed in the block after they are written to state. E.g. if `MsgPlaceOrder` is included in block N, taker order matching would occur for the long-term order in block N+1.
• Order types requiring immediate execution such as fill-or-kill / immediate-or-cancel are disallowed as these should be placed as short term orders; Long-term FoK/IoC orders would never be maker orders, so there is no benefit to writing them to state.

2. Conditional Orders
• execute when the oracle price becomes either LTE or GTE to specified trigger price, depending on the type of conditional order (e.g. stop loss sell = LTE, take profit buy = GTE)
• orders are placed in the block after their condition is met and they become triggered
• it is possible for a conditional order to become triggered in the same block they are initially written to state in. Conditional orders are placed in block ≥ N+1. | -| placement message | MsgPlaceOrder | `MsgPlaceOrder`, long term or conditional order flag enabled on `MsgPlaceOrder.Order.OrderId.OrderFlags`
• valid OrderFlags values are 32 (conditional) and 64 (long-term) for stateful orders | -| cancellation message | MsgCancelOrder

Short term cancellations are handled best-effort, meaning they are only gossiped and not included in MsgProposedOperations | `MsgCancelOrder`, long term or conditional order flag enabled on `MsgCancelOrder.OrderId.OrderFlags`| -| expirations | Good-Till-Block (GTB)

Short term orders have a maximum GTB of current block height + [ShortBlockWindow](https://github.com/dydxprotocol/v4/blob/c6b30514f19f458f5c2b31f46d47a2f1437d6472/x/clob/types/memclob.go#L13). Currently this value is 20 blocks, or about 30 seconds. Short term orders can only be GTB because in the interest of being resilient to chain halts or slowdowns. | Good-Till-Block-Time (GTBT)

Stateful orders have a maximum GTBT of current block time + [StatefulOrderTimeWindow](https://github.com/dydxprotocol/v4/blob/c6b30514f19f458f5c2b31f46d47a2f1437d6472/x/clob/types/memclob.go#L17). Currently this value is 95 days.

GTBT is used instead of GTB to give a more meaningful expiration time for stateful orders. | -| inclusion in block | `OperationRaw_ShortTermOrderPlacement` inside `MsgProposedOperations.OperationsQueue` which is an app-injected message in the proposal. Included if and only if the short term order is included in a match. | Normal cosmos transaction. The original Tx which included the `MsgPlaceOrder` or `MsgCancelOrder` would be included directly in the block. | -| signature verification | Short-term orders must undergo custom signature verification because they are included in an app-injected transaction.

The memclob stores each short term order placement’s raw transaction bytes in the memclob. When the order is included in a match, an `OperationRaw_ShortTermOrderPlacement` operation is included in `MsgProposedOperations` which contains these bytes.

During `DeliverTx`, we decode the raw transaction bytes into a transaction object and pass the transaction through the app’s antehandler which executes signature verification. If signature verification fails, the `MsgProposedOperations` execution returns an error and none of the operations are persisted to state. Operations for a given block is all-or-nothing, meaning all operations execute or none of them execute. | Normal cosmos transaction signature verification, executed by the app’s antehandler. | -| replay prevention | Keep orders in state until after Good-Till-Block aka expiry (even if fully-filled or cancelled) | Cosmos SDK sequence numbers, verified to be strictly increasing in the app’s antehandler.

Note that their use of sequence numbers requires stateful orders to be received in order otherwise they would fail. If placing multiple stateful orders they should be sent to the same validator to prevent issues. | -| time placed (matching logic) | `CheckTx`, immediately after placement transaction is received by the validator.

Short term orders are only included in a block when matched. See “time added to state” below. | long-term: Block N+1 in [PrepareCheckState](https://github.com/dydxprotocol/v4-chain/blob/c87b6072a76c4bc0cdcee16d5f4e032aa5c7548a/protocol/x/clob/abci.go#L110) where `MsgPlaceOrder` was included in block N
conditional: Block N+1 `PrepareCheckState` where the order was triggered in `EndBlocker` of block N | -| what is stored in state | `OrderAmountFilledKeyPrefix`:
• key = OrderId
• value = OrderFillAmount & PrunableBlockHeight

`BlockHeightToPotentiallyPrunableOrdersPrefix`:
• key = block height
• value = list of potentially prunable OrderIds

PrunableBlockHeight holds the block height at which we can safely remove this order from state. BlockHeightToPotentiallyPrunableOrders stores a list of order ids which we can prune for a certain block height. These are used in conjunction for replay prevention of short term orders | `StatefulOrderPlacementKeyPrefix`:

• key = OrderId
• value = Order

`StatefulOrdersTimeSlice`:
• key = time
• value = list of OrderIds expiring at this GTBT

`OrderAmountFilledKeyPrefix`:
• key = OrderId
• value = OrderFillAmount & PrunableBlockHeight (prunable block height unused for stateful orders) | -| time added to state | `DeliverTx` when part of a match included in `MsgProposedOperations` | `StatefulOrderPlacementKeyPrefix` and `StatefulOrdersTimeSlice`: `DeliverTx`, the [MsgPlaceOrder](https://github.com/dydxprotocol/v4-chain/blob/eb5895a445d72610854395e71d6c2e3c97ee20fd/protocol/x/clob/keeper/msg_server_place_order.go#L19) is executed for `MsgPlaceOrder` msgs included in the block. The handler performs stateful validation, a collateralization check, and writes the order to state. Stateful orders are also written to the checkState in CheckTx for spam mitigation purposes.

`OrderAmountFilledKeyPrefix`: DeliverTx, when part of a match included in `MsgProposedOperations` | -| time removed from state | Always in [EndBlocker](https://github.com/dydxprotocol/v4-chain/blob/95b59028af247c0a93ef72de9bfd09a645d30eb1/protocol/x/clob/abci.go#L42) based off of prunable block height | • cancelled by user: removed from state in `DeliverTx` for `MsgCancelOrder`
• forcefully-cancelled by protocol: removed from state in `DeliverTx` when processing `OperationRaw_OrderRemoval` operation. This operation type is included by the proposer in `MsgProposedOperations` when a stateful order is no longer valid. Removal reasons listed [here](https://github.com/dydxprotocol/v4-chain/blob/bd368df4a4ee9c15781d83fd2c9b91b50cd279e0/protocol/x/clob/types/order_removals.pb.go#L28)
• fully-filled: removed from state in `DeliverTx` in the block in which they become fully filled. The order is added to `RemovedStatefulOrderIds` of `processProposerMatchesEvents` to be used in `EndBlocker` to remove from the in-memory orderbook.
• expired: pruned during EndBlocker based off of GTBT

also removed from state in CheckTx for cancellations. This is for spam mitigation purposes. | -| time added to in-memory orderbook | When placed in `CheckTx`, if not fully-matched | When placed in `PrepareCheckState`, if not fully-matched | -| time removed from in-memory orderbook | • when fully-filled: removed in `PrepareCheckState` where invalid memclob state is purged via fully filled orders present in `OrderIdsFilledInLastBlock`
• when cancelled: (CheckTx)
• when expired: PrepareCheckState, removed using memclob.openOrders.blockExpirationsForOrders data structure which stores expiration times for short term orders based off of GTB | • when fully-filled: removed in `PrepareCheckState` where we purge invalid memclob state based off of `RemovedStatefulOrderIds`
• when cancelled: removed in `PrepareCheckState` based off of `PlacedStatefulCancellations`
• when expired: removed in `PrepareCheckState` by `PurgeInvalidMemclobState`, using the list of `ExpiredStatefulOrderIds` produced in `EndBlocker` | +| | Short-term | Stateful | +| ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| purpose | Short-lived orders which are meant to placed immediately (in the same block the order was received). These orders stay in-memory up to 20 blocks, with only their fill amount and expiry block height being committed to state. Intended for use by market makers with high throughput, or for market orders. IoC and FoK orders are also considered short-term orders. Short-term orders do not survive a network restart.
  • • User would send a short-term transaction to a validator
  • • The transaction needs to contain exactly one Cosmos msg, and that msg is a [MsgPlaceOrder](https://github.com/dydxprotocol/v4-chain/blob/c092bf0166d1a111dcd9c2e4153334865c8fe553/proto/dydxprotocol/clob/tx.proto#L78)
  • • Each validator has a [MsgProposedOperations](https://github.com/dydxprotocol/v4-chain/blob/c092bf0166d1a111dcd9c2e4153334865c8fe553/proto/dydxprotocol/clob/tx.proto#L68), which is one validator’s view of the operations queue
  • • In the context of short-term orders, the block proposer should eventually be gossiped the short-term order and have it in their MsgProposedOperations
  • • The block proposer would then optimistically place the short-term order in [CheckTx](https://docs.cosmos.network/main/basics/tx-lifecycle)
  • • Matches that short term orders were included in block during MsgProposedOperations would be included in block for all the validators in the network during [DeliverTx](https://docs.cosmos.network/main/basics/tx-lifecycle)
| Long-lived orders which may execute far in the future. These orders should not be lost during a validator restart (placed in the block after the order was received). In the event a validator restarts, all stateful orders are [placed back onto the in-memory orderbook](https://github.com/dydxprotocol/v4-chain/blob/95b59028af247c0a93ef72de9bfd09a645d30eb1/protocol/app/app.go#L1125). Likely to be used primarily by retail traders. The front end would be sending stateful orders for all order types other than market orders.

Two types of stateful orders:

1. Long-Term Orders
• meant to be added to the orderbook as soon as possible. Due to certain technical limitations, long-term orders are placed in the block after they are written to state. E.g. if `MsgPlaceOrder` is included in block N, taker order matching would occur for the long-term order in block N+1.
• Order types requiring immediate execution such as fill-or-kill / immediate-or-cancel are disallowed as these should be placed as short term orders; Long-term FoK/IoC orders would never be maker orders, so there is no benefit to writing them to state.

2. Conditional Orders
• execute when the oracle price becomes either LTE or GTE to specified trigger price, depending on the type of conditional order (e.g. stop loss sell = LTE, take profit buy = GTE)
• orders are placed in the block after their condition is met and they become triggered
• it is possible for a conditional order to become triggered in the same block they are initially written to state in. Conditional orders are placed in block ≥ N+1. | +| placement message | MsgPlaceOrder | `MsgPlaceOrder`, long term or conditional order flag enabled on `MsgPlaceOrder.Order.OrderId.OrderFlags`
• valid OrderFlags values are 32 (conditional) and 64 (long-term) for stateful orders | +| cancellation message | MsgCancelOrder

Short term cancellations are handled best-effort, meaning they are only gossiped and not included in MsgProposedOperations | `MsgCancelOrder`, long term or conditional order flag enabled on `MsgCancelOrder.OrderId.OrderFlags` | +| expirations | Good-Till-Block (GTB)

Short term orders have a maximum GTB of current block height + [ShortBlockWindow](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/protocol/x/clob/types/constants.go#L9). Currently this value is 20 blocks, or about 30 seconds. Short term orders can only be GTB because in the interest of being resilient to chain halts or slowdowns. | Good-Till-Block-Time (GTBT)

Stateful orders have a maximum GTBT of current block time + [StatefulOrderTimeWindow](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/protocol/x/clob/types/constants.go#L17). Currently this value is 95 days.

GTBT is used instead of GTB to give a more meaningful expiration time for stateful orders. | +| inclusion in block | `OperationRaw_ShortTermOrderPlacement` inside `MsgProposedOperations.OperationsQueue` which is an app-injected message in the proposal. Included if and only if the short term order is included in a match. | Normal cosmos transaction. The original Tx which included the `MsgPlaceOrder` or `MsgCancelOrder` would be included directly in the block. | +| signature verification | Short-term orders must undergo custom signature verification because they are included in an app-injected transaction.

The memclob stores each short term order placement’s raw transaction bytes in the memclob. When the order is included in a match, an `OperationRaw_ShortTermOrderPlacement` operation is included in `MsgProposedOperations` which contains these bytes.

During `DeliverTx`, we decode the raw transaction bytes into a transaction object and pass the transaction through the app’s antehandler which executes signature verification. If signature verification fails, the `MsgProposedOperations` execution returns an error and none of the operations are persisted to state. Operations for a given block is all-or-nothing, meaning all operations execute or none of them execute. | Normal cosmos transaction signature verification, executed by the app’s antehandler. | +| replay prevention | Keep orders in state until after Good-Till-Block aka expiry (even if fully-filled or cancelled) | Cosmos SDK sequence numbers, verified to be strictly increasing in the app’s antehandler.

Note that their use of sequence numbers requires stateful orders to be received in order otherwise they would fail. If placing multiple stateful orders they should be sent to the same validator to prevent issues. | +| time placed (matching logic) | `CheckTx`, immediately after placement transaction is received by the validator.

Short term orders are only included in a block when matched. See “time added to state” below. | long-term: Block N+1 in [PrepareCheckState](https://github.com/dydxprotocol/v4-chain/blob/main/protocol/x/clob/abci.go#L136) where `MsgPlaceOrder` was included in block N
conditional: Block N+1 `PrepareCheckState` where the order was triggered in `EndBlocker` of block N | +| what is stored in state | `OrderAmountFilledKeyPrefix`:
• key = OrderId
• value = OrderFillAmount & PrunableBlockHeight

`BlockHeightToPotentiallyPrunableOrdersPrefix`:
• key = block height
• value = list of potentially prunable OrderIds

PrunableBlockHeight holds the block height at which we can safely remove this order from state. BlockHeightToPotentiallyPrunableOrders stores a list of order ids which we can prune for a certain block height. These are used in conjunction for replay prevention of short term orders | `StatefulOrderPlacementKeyPrefix`:

• key = OrderId
• value = Order

`StatefulOrdersTimeSlice`:
• key = time
• value = list of OrderIds expiring at this GTBT

`OrderAmountFilledKeyPrefix`:
• key = OrderId
• value = OrderFillAmount & PrunableBlockHeight (prunable block height unused for stateful orders) | +| time added to state | `DeliverTx` when part of a match included in `MsgProposedOperations` | `StatefulOrderPlacementKeyPrefix` and `StatefulOrdersTimeSlice`: `DeliverTx`, the [MsgPlaceOrder](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/protocol/x/clob/keeper/msg_server_place_order.go#L22) is executed for `MsgPlaceOrder` msgs included in the block. The handler performs stateful validation, a collateralization check, and writes the order to state. Stateful orders are also written to the checkState in CheckTx for spam mitigation purposes.

`OrderAmountFilledKeyPrefix`: DeliverTx, when part of a match included in `MsgProposedOperations` | +| time removed from state | Always in [EndBlocker](https://github.com/dydxprotocol/v4-chain/blob/main/protocol/x/clob/abci.go#L60) based off of prunable block height | • cancelled by user: removed from state in `DeliverTx` for `MsgCancelOrder`
• forcefully-cancelled by protocol: removed from state in `DeliverTx` when processing `OperationRaw_OrderRemoval` operation. This operation type is included by the proposer in `MsgProposedOperations` when a stateful order is no longer valid. Removal reasons listed [here](https://github.com/dydxprotocol/v4-chain/blob/main/protocol/x/clob/types/order_removals.pb.go#L28)
• fully-filled: removed from state in `DeliverTx` in the block in which they become fully filled. The order is added to `RemovedStatefulOrderIds` of `processProposerMatchesEvents` to be used in `EndBlocker` to remove from the in-memory orderbook.
• expired: pruned during EndBlocker based off of GTBT

also removed from state in CheckTx for cancellations. This is for spam mitigation purposes. | +| time added to in-memory orderbook | When placed in `CheckTx`, if not fully-matched | When placed in `PrepareCheckState`, if not fully-matched | +| time removed from in-memory orderbook | • when fully-filled: removed in `PrepareCheckState` where invalid memclob state is purged via fully filled orders present in `OrderIdsFilledInLastBlock`
• when cancelled: (CheckTx)
• when expired: PrepareCheckState, removed using memclob.openOrders.blockExpirationsForOrders data structure which stores expiration times for short term orders based off of GTB | • when fully-filled: removed in `PrepareCheckState` where we purge invalid memclob state based off of `RemovedStatefulOrderIds`
• when cancelled: removed in `PrepareCheckState` based off of `PlacedStatefulCancellations`
• when expired: removed in `PrepareCheckState` by `PurgeInvalidMemclobState`, using the list of `ExpiredStatefulOrderIds` produced in `EndBlocker` | dYdX Chain is open source software. dYdX does not control or operate any protocol running the dYdX Chain software. All use of dYdX Chain software and documentation are subject to dYdX v4 terms of use and licensing requirements. dYdX products and services are not available to U.S., Canadian and other Restricted Persons, defined in the [v4 Terms of Use](https://dydx.exchange/v4-terms?). diff --git a/pages/infrastructure_providers-network/resources.mdx b/pages/infrastructure_providers-network/resources.mdx index 50fa36e7..3a8368a9 100644 --- a/pages/infrastructure_providers-network/resources.mdx +++ b/pages/infrastructure_providers-network/resources.mdx @@ -1,130 +1,136 @@ -import { Tab, Tabs } from "nextra-theme-docs"; +import { Tab, Tabs } from 'nextra-theme-docs'; # Resources ## `networks` repositories - - -`https://github.com/dydxprotocol/v4-testnets/tree/main/dydx-testnet-4` - - -`https://github.com/dydxopsdao/networks/tree/main/dydx-mainnet-1` - + + `https://github.com/dydxprotocol/v4-testnets/tree/main/dydx-testnet-4` + `https://github.com/dydxopsdao/networks/tree/main/dydx-mainnet-1` ## Upgrades History - - -For **Testnet**: -| Block Height | Compatible Versions | Comments | -|---------------|---------------------| -------- | -| 1 ~ 5,000,000 | [v2.0.1](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv2.0.1)
[v2.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv2.0.0)
[v1.0.1](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv1.0.1)
[v1.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv1.0.0) | The chain was never upgraded to `v2.0.0` | -| 5,000,001 ~ 6,880,000 | [v3.0.2](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv3.0.2)
[v3.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv3.0.0)
| | -| 6,880,001 ~ 10,450,000 | [v4.0.5](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv4.0.5) | | -| 10,450,001 ~ | [v4.1.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv4.1.0) | | - - -For **the deployment by DYDX token holders**: -| Block Height | Compatible Versions | Comments | -|---------------|---------------------| -------- | -| 1 ~ 1,805,000 | [v2.0.1](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv2.0.1)
[v1.0.1](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv1.0.1)
[v1.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv1.0.0) | `v1.0.1` was a rolling upgrade;
`v2.0.1` was backported to enable easier syncing from block 1 | -| 1,805,001 ~ 7,147,832 | [v2.0.1](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv2.0.1)
[v2.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv2.0.0) | `v2.0.0` was an emergency fix | -| 7,147,833 ~ 12,791,712 | [v3.0.2](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv3.0.2)
[v3.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv3.0.0) | | -| 12,791,713 ~ 14,404,200 | [v4.0.5](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv4.0.5) | | -| 14,404,201 ~ | [v4.1.2](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv4.1.2)
[v4.1.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv4.1.0) | | - + + + For **Testnet**: | Block Height | Compatible Versions | Comments | + |---------------|---------------------| -------- | | 1 ~ 5,000,000 | + [v2.0.1](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv2.0.1)
{' '} + [v2.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv2.0.0)
{' '} + [v1.0.1](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv1.0.1)
{' '} + [v1.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv1.0.0) | The chain + was never upgraded to `v2.0.0` | | 5,000,001 ~ 6,880,000 | + [v3.0.2](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv3.0.2)
{' '} + [v3.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv3.0.0)
| | | + 6,880,001 ~ 10,450,000 | + [v4.0.5](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv4.0.5) | | | + 10,450,001 ~ | [v4.1.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv4.1.0) + | | + + + For **the deployment by DYDX token holders**: | Block Height | Compatible Versions | Comments | + |---------------|---------------------| -------- | | 1 ~ 1,805,000 | + [v2.0.1](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv2.0.1)
{' '} + [v1.0.1](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv1.0.1)
{' '} + [v1.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv1.0.0) | `v1.0.1` was + a rolling upgrade;
`v2.0.1` was backported to enable easier syncing from block 1 | | + 1,805,001 ~ 7,147,832 | + [v2.0.1](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv2.0.1)
{' '} + [v2.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv2.0.0) | `v2.0.0` was + an emergency fix | | 7,147,833 ~ 12,791,712 | + [v3.0.2](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv3.0.2)
{' '} + [v3.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv3.0.0) | | | + 12,791,713 ~ 14,404,200 | + [v4.0.5](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv4.0.5) | | | + 14,404,201 ~ | [v4.1.2](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv4.1.2){' '} +
[v4.1.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv4.1.0) | | + - ## Seed Nodes - - -For **Testnet**: -| Team | URI | -| ------------- | --------------------------------------------------------------------------------------- | -| AllThatNode: | `19d38bb5cea1378db3e16615e63594dc26119a1a@dydx-testnet4-seednode.allthatnode.com:26656` | -| Crosnest: | `87ee8de5f0f82af6ee6740a30f8844bbe6434413@seed.dydx-testnet.cros-nest.com:26656` | -| CryptoCrew: | `38e5a5ec34c578dc323cbdd9b98330abb448d586@tenderseed.ccvalidators.com:29104` | -| KingNodes: | `80a1a6cd086634c34008c6457d3f7441cfc05c47@seeds.kingnodes.com:27056` | -| StakingCabin: | `182ab0015fb4b7d751b12a9c0162ac123445eac1@seed.dydx-testnet.stakingcabin.com:26656` | -| StakerSpace: | `76b472b107ccf20c3d6c110c4a2a217306d2dedb@dydx-seed.staker.space:26656` | - - -For **the deployment by DYDX token holders**: -| Team | URI | -| ------------- | -------------------------------------------------------------------------------------- | -| Polkachu | `ade4d8bc8cbe014af6ebdf3cb7b1e9ad36f412c0@seeds.polkachu.com:23856` | -| KingNodes | `65b740ee326c9260c30af1f044e9cda63c73f7c1@seeds.kingnodes.net:23856` | -| Bware Labs | `f04a77b92d0d86725cdb2d6b7a7eb0eda8c27089@dydx-mainnet-seed.bwarelabs.com:36656` | -| Lavender.Five | `20e1000e88125698264454a884812746c2eb4807@seeds.lavenderfive.com:23856` | -| CryptoCrew | `c2c2fcb5e6e4755e06b83b499aff93e97282f8e8@tenderseed.ccvalidators.com:26401` | -| DSRV | `a9cae4047d5c34772442322b10ef5600d8e54900@dydx-mainnet-seednode.allthatnode.com:26656` | -| Luganodes | `802607c6db8148b0c68c8a9ec1a86fd3ba606af6@64.227.38.88:26656` | -| AutoStake | `ebc272824924ea1a27ea3183dd0b9ba713494f83@dydx-mainnet-seed.autostake.com:27366` | - + + + For **Testnet**: | Team | URI | | ------------- | + --------------------------------------------------------------------------------------- | | + AllThatNode: | + `19d38bb5cea1378db3e16615e63594dc26119a1a@dydx-testnet4-seednode.allthatnode.com:26656` | | + Crosnest: | `87ee8de5f0f82af6ee6740a30f8844bbe6434413@seed.dydx-testnet.cros-nest.com:26656` | | + CryptoCrew: | `38e5a5ec34c578dc323cbdd9b98330abb448d586@tenderseed.ccvalidators.com:29104` | | + KingNodes: | `80a1a6cd086634c34008c6457d3f7441cfc05c47@seeds.kingnodes.com:27056` | | + StakingCabin: | + `182ab0015fb4b7d751b12a9c0162ac123445eac1@seed.dydx-testnet.stakingcabin.com:26656` | | + StakerSpace: | `76b472b107ccf20c3d6c110c4a2a217306d2dedb@dydx-seed.staker.space:26656` | + + + For **the deployment by DYDX token holders**: | Team | URI | | ------------- | + -------------------------------------------------------------------------------------- | | + Polkachu | `ade4d8bc8cbe014af6ebdf3cb7b1e9ad36f412c0@seeds.polkachu.com:23856` | | KingNodes | + `65b740ee326c9260c30af1f044e9cda63c73f7c1@seeds.kingnodes.net:23856` | | Bware Labs | + `f04a77b92d0d86725cdb2d6b7a7eb0eda8c27089@dydx-mainnet-seed.bwarelabs.com:36656` | | + Lavender.Five | `20e1000e88125698264454a884812746c2eb4807@seeds.lavenderfive.com:23856` | | + CryptoCrew | `c2c2fcb5e6e4755e06b83b499aff93e97282f8e8@tenderseed.ccvalidators.com:26401` | | + DSRV | `a9cae4047d5c34772442322b10ef5600d8e54900@dydx-mainnet-seednode.allthatnode.com:26656` | + | Luganodes | `802607c6db8148b0c68c8a9ec1a86fd3ba606af6@64.227.38.88:26656` | | AutoStake | + `ebc272824924ea1a27ea3183dd0b9ba713494f83@dydx-mainnet-seed.autostake.com:27366` | + ## Indexer endpoints - - -For **Testnet**: -| Type | URI | -| ---- | --------------------------------------------- | -| API | `https://indexer.v4testnet.dydx.exchange` | -| WS | `wss://indexer.v4testnet.dydx.exchange/v4/ws` | - - -For **the deployment by DYDX token holders**: -| Type | URI | -| ---- | -------------------------------- | -| API | `https://indexer.dydx.trade/v4` | -| WS | `wss://indexer.dydx.trade/v4/ws` | - + + + For **Testnet**: | Type | URI | | ---- | --------------------------------------------- | | API | + `https://indexer.v4testnet.dydx.exchange` | | WS | `wss://indexer.v4testnet.dydx.exchange/v4/ws` + | + + + For **the deployment by DYDX token holders**: | Type | URI | | ---- | + -------------------------------- | | API | `https://indexer.dydx.trade/v4` | | WS | + `wss://indexer.dydx.trade/v4/ws` | + - ## StateSync nodes - - -For **Testnet**: -| Team | StateSync Peers | -| -------- | -------------------------------------------------------------- | -| Polkachu | `0d17772cbba3b488ad895b17b9a48948e480b1fa@65.109.23.114:23856` | - - -For **the deployment by DYDX token holders**: -| Team | StateSync Peers | Region | -| - | - | - | -| KingNodes | `f94dcfbccb9019584d1790562a020507b050d9ba@51.77.56.23:23856`
`6bc1068d9a257931083ddc75ad3b1003a46e5b0d@15.235.160.127:23856` | `EU_West`
`Asia_SE` | -| Polkachu | `580ec248de1f41d4e50abe132b7838348db55b80@176.9.144.40:23856`
`90b0ee8e73d8237b06356b244ff9854d1991a1f8@65.109.115.228:23856`
`874b5ab53d8f5edae6674ad394f20e2b297cf73f@199.254.199.182:23856`
`e3aa07f6f97fcccdf57b64aa5f4f11761df3852a@15.235.160.15:23856`
`a879fe2926c2b8f0d86e8e973210c30b8634abb4@15.235.204.159:23856` | `Germany`
`Finland`
`Japan`
`Singapore`
`Singapore` | -| Bware Labs | `b0137ca9fec8d2990d804e20bc5b74e641bb45e8@dydx-mainnet-statesync-rpc.bwarelabs.com:443` | `Germany` | -| AutoStake | `ebc272824924ea1a27ea3183dd0b9ba713494f83@dydx-mainnet-peer.autostake.com:27366` | `EU,Poland` | - + + + For **Testnet**: | Team | StateSync Peers | | -------- | + -------------------------------------------------------------- | | Polkachu | + `0d17772cbba3b488ad895b17b9a48948e480b1fa@65.109.23.114:23856` | + + + For **the deployment by DYDX token holders**: | Team | StateSync Peers | Region | | - | - | - | + | KingNodes | `f94dcfbccb9019584d1790562a020507b050d9ba@51.77.56.23:23856`
{' '} + `6bc1068d9a257931083ddc75ad3b1003a46e5b0d@15.235.160.127:23856` | `EU_West`
`Asia_SE` | | + Polkachu | `580ec248de1f41d4e50abe132b7838348db55b80@176.9.144.40:23856`
{' '} + `90b0ee8e73d8237b06356b244ff9854d1991a1f8@65.109.115.228:23856`
{' '} + `874b5ab53d8f5edae6674ad394f20e2b297cf73f@199.254.199.182:23856`
{' '} + `e3aa07f6f97fcccdf57b64aa5f4f11761df3852a@15.235.160.15:23856`
{' '} + `a879fe2926c2b8f0d86e8e973210c30b8634abb4@15.235.204.159:23856` | `Germany`
`Finland`{' '} +
`Japan`
`Singapore`
`Singapore` | | Bware Labs | + `b0137ca9fec8d2990d804e20bc5b74e641bb45e8@dydx-mainnet-statesync-rpc.bwarelabs.com:443` | + `Germany` | | AutoStake | + `ebc272824924ea1a27ea3183dd0b9ba713494f83@dydx-mainnet-peer.autostake.com:27366` | `EU,Poland` | + ## Snapshot Service - - -For **Testnet**: -| Team | URI | Pruning | Index | -| ---------- | -------------------------------------- | ------- | ----- | -| Bware Labs | `https://bwarelabs.com/snapshots/dydx` | Yes | null | - - -For **the deployment by DYDX token holders**: -| Team | URI | Pruning | Index | -| ------------- | --------------------------------------------------------- | ------- | ----- | -| Bware Labs | `https://bwarelabs.com/snapshots/dydx` | Yes | null | -| Polkachu | `https://polkachu.com/tendermint_snapshots/dydx` | Yes | null | -| KingNodes | `https://dydx-archive-snapshot.kingnodes.com/` | No | kv | -| Lavender.Five | `https://services.lavenderfive.com/mainnet/dydx/snapshot` | Yes | | -| AutoStake | `https://autostake.com/networks/dydx/#services` | Yes | null | - + + + For **Testnet**: | Team | URI | Pruning | Index | | ---------- | + -------------------------------------- | ------- | ----- | | Bware Labs | + `https://bwarelabs.com/snapshots/dydx` | Yes | null | + + + For **the deployment by DYDX token holders**: | Team | URI | Pruning | Index | | ------------- | + --------------------------------------------------------- | ------- | ----- | | Bware Labs | + `https://bwarelabs.com/snapshots/dydx` | Yes | null | | Polkachu | + `https://polkachu.com/tendermint_snapshots/dydx` | Yes | null | | KingNodes | + `https://dydx-archive-snapshot.kingnodes.com/` | No | kv | | Lavender.Five | + `https://services.lavenderfive.com/mainnet/dydx/snapshot` | Yes | | | AutoStake | + `https://autostake.com/networks/dydx/#services` | Yes | null | + ## Full node endpoints @@ -155,6 +161,7 @@ For **Testnet**: | Lavender Five | `testnet-dydx-grpc.lavenderfive.com:443` | | King Nodes | `https://test-dydx-grpc.kingnodes.com`
`https://test-dydx-grpc-web.kingnodes.com` | | Polkachu | `dydx-testnet-grpc.polkachu.com:23890` | + For **the deployment by DYDX token holders**: @@ -191,6 +198,7 @@ For **the deployment by DYDX token holders**: | KingNodes | `https://dydx-ops-grpc.kingnodes.com:443` | 250 req/m | | Lavender.Five | `https://dydx-grpc.lavenderfive.com:443` | | | PublicNode | `https://dydx-grpc.publicnode.com:443` | | + @@ -201,6 +209,7 @@ For **the deployment by DYDX token holders**: For **Testnet**: No Archival nodes + For **the deployment by DYDX token holders**: @@ -225,39 +234,35 @@ For **the deployment by DYDX token holders**: | Polkachu | `http://dydx-dao-archive-grpc-1.polkachu.com:23890`
`http://dydx-dao-archive-grpc-2.polkachu.com:23890` | 300 req/m | | Bware Labs | `https://dydx-mainnet-archive-grpc.public.blastapi.io:443` | 20 req/s | | KingNodes | `https://dydx-ops-archive-grpc.kingnodes.com:443` | 50 req/m | + - - ## Other Links - - -For **Testnet**: -| Name | URI | -| -------------------------- | ----------------------------------------------------------------------------------------------------- | -| Public Testnet Front-end | `https://v4.testnet.dydx.exchange` | -| Status Page | `https://status.v4testnet.dydx.exchange` | -| Mintscan | `https://testnet.mintscan.io/dydx-testnet` | -| Keplr | `https://testnet.keplr.app/chains/dydx-testnet` | -| Validator Metrics | `https://p.datadoghq.com/sb/dc160ddf0-05a98d2dbe2a01d8caa5783eb616f826` | -| Discord Channel (Feedback) | `https://discord.com/channels/724804754382782534/1117897181886677012` | -| Google Form (Feedback) | `https://docs.google.com/forms/d/e/1FAIpQLSezLsWCKvAYDEb7L-2O4wOON1T56xxro9A2Azvl6IxXHP_15Q/viewform` | - - -For **the deployment by DYDX token holders**: -| Name | URI | -| --------------------------- | ------------------------------------------------------------------------------------------------------ | -| dYdX Chain Web Frontend | `https://dydx.trade/` | -| Status Page | `https://status.dydx.trade` | -| Mintscan | `https://www.mintscan.io/dydx` | -| Keplr | `https://wallet.keplr.app/chains/dydx` | -| Validator Metrics | `https://p.ap1.datadoghq.com/sb/610e1836-51dd-11ee-a995-da7ad0900009-78607847ff8632d8a96737ed3437f40c` | -| #validators Discord Channel | `https://discord.com/channels/724804754382782534/1029585380170805379` | -| FE Bug Report Form | `https://www.dydxopsdao.com/feedback` | - + + + For **Testnet**: | Name | URI | | -------------------------- | + ----------------------------------------------------------------------------------------------------- + | | Public Testnet Front-end | `https://v4.testnet.dydx.exchange` | | Status Page | + `https://status.v4testnet.dydx.exchange` | | Mintscan | + `https://testnet.mintscan.io/dydx-testnet` | | Keplr | + `https://testnet.keplr.app/chains/dydx-testnet` | | Validator Metrics | + `https://p.datadoghq.com/sb/dc160ddf0-05a98d2dbe2a01d8caa5783eb616f826` | | Discord Channel + (Feedback) | `https://discord.com/channels/724804754382782534/1117897181886677012` | | Google + Form (Feedback) | + `https://docs.google.com/forms/d/e/1FAIpQLSezLsWCKvAYDEb7L-2O4wOON1T56xxro9A2Azvl6IxXHP_15Q/viewform` + | + + + For **the deployment by DYDX token holders**: | Name | URI | | --------------------------- | + ------------------------------------------------------------------------------------------------------ + | | dYdX Chain Web Frontend | `https://dydx.trade/` | | Status Page | + `https://status.dydx.trade` | | Mintscan | `https://www.mintscan.io/dydx` | | Keplr | + `https://wallet.keplr.app/chains/dydx` | | Validator Metrics | + `https://p.ap1.datadoghq.com/sb/610e1836-51dd-11ee-a995-da7ad0900009-78607847ff8632d8a96737ed3437f40c` + | | #validators Discord Channel | + `https://discord.com/channels/724804754382782534/1029585380170805379` | | FE Bug Report Form | + `https://www.dydxopsdao.com/feedback` | + - - - diff --git a/pages/infrastructure_providers-validators/how_to_set_up_full_node.md b/pages/infrastructure_providers-validators/how_to_set_up_full_node.md index cb637b40..5ff26378 100644 --- a/pages/infrastructure_providers-validators/how_to_set_up_full_node.md +++ b/pages/infrastructure_providers-validators/how_to_set_up_full_node.md @@ -35,7 +35,7 @@ to get the applicable Genesis state of the network. - Also check [Full node endpoints → RPC](../infrastructure_providers-network/resources.mdx#full-node-endpoints) ## Install Bware’s snapshot (optional but saves days) -> **Note:** the example values below align with the **deployment by DYDX token holders**. For alternatives, please visit the [Network Resources page](../network/resources.md). +> **Note:** the example values below align with the **deployment by DYDX token holders**. For alternatives, please visit the [Network Resources page](../infrastructure_providers-network/resources.mdx). 1. From https://bwarelabs.com/snapshots/dydx 2. Download and extract (using `lz4 -dc < snapshotfile.tar.lz4 | tar xf -`) the snapshot contents in the data directory (make sure you are in the data directory before running the tar command). Important: The home directory (`$DYDX_HOME` or `/home/vmware/.dydx-mainnet-1` in our example) contains another `data/` directory. diff --git a/pages/infrastructure_providers-validators/required_node_configs.md b/pages/infrastructure_providers-validators/required_node_configs.md index 6d6f6e40..add5fa41 100644 --- a/pages/infrastructure_providers-validators/required_node_configs.md +++ b/pages/infrastructure_providers-validators/required_node_configs.md @@ -25,7 +25,7 @@ timeout_commit = "500ms" #### Base Configuration -Replace `$NATIVE_TOKEN_DENOM` at the end of the field with the correct value from [Network Constants](../infrastructure_providers-network/network_constants.md#native-token-denom) +Replace `$NATIVE_TOKEN_DENOM` at the end of the field with the correct value from [Network Constants](../infrastructure_providers-network/network_constants.mdx#native-token-denom) ``` ### Gas Prices ### diff --git a/pages/infrastructure_providers-validators/running_full_node.md b/pages/infrastructure_providers-validators/running_full_node.md index 5a15ab4f..e0da3f74 100644 --- a/pages/infrastructure_providers-validators/running_full_node.md +++ b/pages/infrastructure_providers-validators/running_full_node.md @@ -49,7 +49,7 @@ https://polkachu.com/state_sync/dydx https://services.lavenderfive.com/mainnet/dydx/statesync -https://autostake.com/networks/dydx/ca +https://autostake.com/networks/dydx/#state-sync ### Address Book diff --git a/pages/introduction-onboarding_faqs.md b/pages/introduction-onboarding_faqs.md deleted file mode 100644 index 3a2abe7e..00000000 --- a/pages/introduction-onboarding_faqs.md +++ /dev/null @@ -1,207 +0,0 @@ -# Onboarding FAQs - -## Intro - -1. Can you give an overview of the structure of the network and the role full nodes/validators play in constructing the orderbook and participating in block building, and how trades are placed? - - dYdX Chain (or "v4") is composed of full nodes and each maintains an in-memory order book. Anyone can use the open source software to run a full node. Traders can submit order placements and cancellations to full nodes, which gossip the transactions amongst themselves. - - Full nodes with enough delegated layer 1 governance tokens participate in block building as validators. Validators on dYdX Chain take turns proposing blocks of trades every ~1 second. The validator whose turn it is to propose a block at a given height is called the proposer. The proposer uses its mempool orderbook to propose a block of matches, which validators either accept or reject according to CometBFT (Tendermint) consensus. - - All full nodes have visibility into the consensus process and the transactions in the mempool. Another component of dYdX Chain is the indexer software, an application that reads data from full nodes and exposes it via REST / WebSocket APIs for convenience. - -2. What is the difference between a full node and a validator? - - A full node does not participate in consensus. It receives data from other full nodes and validators in the network via the gossip protocol. A validator participates in consensus by broadcasting votes signed by each validator’s private keys. - -3. What are the benefits of running a full node as a market maker? - - Running a full node will eliminate the latency between placing an order and when the actual order is gossipped throughout the network. Without your own node, your order will need to first be relayed to the nearest geographic node, which will then propagate it throughout the network for you. With your own node, your order will directly be gossiped. - - Instructions on how to set up a full node can be found [here](./infrastructure_providers-validators/how_to_set_up_full_node.md). - -4. What is the current block time? - - The current block time is ~1 second on average - -5. What is an indexer? - - The indexer is a read-only service that consumes real time data from dYdX Chain to a database for visibility to users. The indexer consumes data from dYdX Chain via a connection to a full node. The full node contains a copy of the blockchain and an in-memory order book. When the full node updates its copy of the blockchain and in-memory order book due to processing transactions, it will also stream these updates to the indexer. The indexer keeps the data in its database synced with the full-node using these updates. This data is made available to users querying through HTTPS REST APIs and streaming via websockets. More info can be found [here](./concepts-architecture/indexer.md). - -## Trading on an Exchange Run on dYdX Chain - -1. What are the different order types in dYdX Chain? - - There are two order types: Short-Term orders and stateful orders. - - Short-Term orders are meant for programmatic, low-latency traders that want to place orders with shorter expirations. - - Stateful orders are meant for retail that wants to place orders with longer expirations. These orders exist on chain. - -2. How does the orderbook work in dYdX Chain for short-term orders? - - Each validator runs their own in-memory orderbook (also known as mempool), and the set of orders each validator knows about is what order placement transactions are in their mempool. - - User places a trade on a decentralized front end (e.g., website) or via the typescript or python client that places orders directly to a full node or validatorAPI - - The consensus process picks one validator to be the block proposer. The selected validator will propose their view of the matches in the next proposed block. - - If the matches are valid (orders cross, subaccounts well-collateralized, etc.) and accepted by ⅔+ of validator stake weight (consensus), then the block is committed and those matches are written to state as valid matches. - - After the block is committed, the updated on-chain (and off-chain) data is streamed from full nodes to Indexers. The Indexer then makes this data available via API and websockets back to the front end and/or any other outside services querying for this data. - - Note: the block proposer’s matches are the canonical matches for the next block assuming their block is accepted by consensus. - - Other validators maintain a list of matches and those matches might differ from the block proposer’s matches, but if they’re not the block proposer those matches will not be proposed in the next block. - - Similarly, the indexer is not the block proposer so its list of matches might be different from the block proposer’s matches, until the network reaches finality. - -3. Why should market makers only use short-term orders? - - Short-Term orders are placed and can be immediately matched after they’re added to the mempool, while stateful orders can only be placed and matched after they’re added to a block. - - Short-Term orders should always have superior time priority to stateful orders. - - Stateful orders have worse time priority since they can only be matched after they are included on the block, short-term orders can be matched in the same block - - Short-Term orders have less restrictive rate limits than stateful order rate limits. See rate limits later on in this section - - Short-Term orders can be replaced, and stateful orders currently don’t support replacement. - - Short-Term orders can be canceled immediately after they’re placed, while stateful orders can only be canceled after they’ve been included in a block. - - Short-Term orders can be received by validators in any order, while stateful orders have an ordering requirement and will fail to be placed if they’re received out of order. - - This is because stateful orders use a “sequence number”, which is equivalent to a nonce on Ethereum. Short-Term orders don’t use this. - -4. How can I understand how finality works on dYdX Chain? - - When your order fills, a block proposer will propose a block containing the fill (visible to the whole network), and then the block will go through consensus. If the block is valid it will be finalized a couple seconds later (in Cosmos-speak this happens at the “commit” stage of consensus after all validators have voted). At that point, an indexer service will communicate the fill to you. - - It is recommended to post orders with a “Good-Til-Block” of the current block height, and adjusting prices once per block. If the block is published without a match to your order, you know that it is no longer active and did not fill. - -5. How can I place a short-term order? - - Please use the latest dYdX Chain [typescript client](https://www.npmjs.com/package/@dydxprotocol/v4-client-js) to place orders - - Please refer to the [order.proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/clob/order.proto) for parameter and field definitions - - For more advanced order placements, please refer to the validator client [v4-proto-js](https://github.com/dydxprotocol/v4-chain/tree/main/v4-proto-js) or [v4-proto-py](https://github.com/dydxprotocol/v4-chain/tree/main/v4-proto-py). - -6. How can I tell if the block proposer has placed my short-term order? - - The block proposer has proposed and filled the order in the block. - - The block proposer has the order in their mempool. - -7. How can I tell if my short-term order is canceled? - - Short-term order placements and cancellations are best-effort, and therefore their cancels and placement can't be considered actually canceled and unfillable until expiry - - A FOK or IOC order can also be seen as canceled if a fill does not occur after expiry - - The indexer does not send a websocket notification if a short-term order has been canceled - - However, since the goodTilBlock for the cancel needs to be set when placing the cancel, the block height can be checked to ensure that the cancel was successful - - This is lower latency than what a websocket notification could provide - -8. How can I replace an order? - - Replacing an order reuses the short-term order placement function with the [same order ID](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/clob/order.proto#L10) and an equal-to-or-greater good til block - - Note: when replacing partially-filled orders, the previous fill amount is counted towards your current order. - - Example: Buy 1 BTC order @ $20k is filled for 0.5 BTC. After replacing that order with a Buy 2 BTC order @ $25k, that order can only be filled for a maximum of 1.5 BTC. This is because the previously replaced order was already filled for 0.5 BTC. - -9. Are fills computed/updates steamed only when a block is finalized? How about order placements? - - Fills are computed only when a block is finalized - - Short term order place / cancel (including IOC / FOK orders being canceled due to not filling / being on the book or POST-ONLY orders crossing) are streamed when the full node the Indexer deployment is listening to receives the order / cancel and not only when the block is finalized - - This is why the status “BEST_EFFORT_OPENED” or “BEST_EFFORT_CANCELED” since the Indexer only knows that a full-node received the order / cancel, and it’s not guaranteed to be true across the whole network - - For the orderbook updates, these are sent when the full-node the Indexer is listening to receives orders / cancels and not just when the block is finalized - - For example, when the full-node receives a short term order it will be approximate how much is filled and how much would go on the orderbook. This is what the Indexer uses to stream orderbook updates. However, there is no guarantee that the orderbook looks the same in other nodes in the network - - Note that you can now stream the orderbook directly through your full node for the orderbook. Read more about that [here](./infrastructure_providers-validators/full_node_streaming.md). - -10. Do orders get matched and removed from the book in between blocks? - - For removal of short term orders, yes they can be removed in between blocks, however this is on a node-by-node basis and not across the whole network - - E.g. a short-term order could be removed on one node, but still be present on another - - When a short-term order expires (current block height > goodtilBlock), then it is guaranteed to be removed from all nodes - - For removal of stateful orders, they can be removed from the book in-between blocks. This is on a node-by-node basis - - If the node removing the stateful orders is the block proposer, these stateful order removals will also be propagated to all other nodes, an be entirely removed from the network - - For all orders, regarding matching - - For matching, each node on the network will attempt to match the orders as they are received in-between blocks - - Per block, only 1 node (the block proposer) will propagate the matches it’s done during the block to all other nodes in the network. Validator nodes take turns being the block proposer based on their stake weight - - If a set of validators with ⅔+ of the stake weight of the network see the matches propagated as valid, then those matches are included in the block when finalized - - The only matches that occur on the network are the ones in the block - -11. Do certain order types have priority? Are cancels prioritized? - - Short term orders when received by a node will be matched against it’s in-memory orderbook - - Cancels of short-term orders are also processed by a node when received - - Stateful orders (long-term / conditional) are matched at the end of the block when they are received - - E.g. Stateful orders have at least a 1 block-time delay (it’s possible the order does not get included in the block) between a node receiving the order, and it being matched - - Stateful order placement will be processed AFTER short-term order placements and cancellations for a block - - Stateful order cancellations are also done at the end of the block they are received - - The stateful order cancellations are also processed AFTER short-term placements and cancellations for a block - - As mentioned above, only the matches from the block proposer will be included in the block (if a set of validators with ⅔+ of the stake weight of the network see the matches as valid) - -12. How does the order cancellation mechanism work? Is it necessary for the cancel instruction and the original order to be on the same validator for a successful cancel? What's the best practice to ensure order cancellation succeeds? - - Short-term: - - When validators receive a cancellation, if they don't already see a match for the order, they will remove the order from their order book - - Only once every validator receives the cancellation is when the order will no longer be able to be matched - - The other way an order would no longer be matchable is if the block height is past the good til block - - Long-term: - - Once a stateful order cancellation is included into a block, the order will be canceled and no longer matchable. This could take 1s+ for a cancelation to be included in a block - -13. Why is it slower to cancel orders than place orders? - - An order placement only needs to be on a single validator to have a match happen, but the cancellation has to have arrived at the block proposer, but since the BP rotates, to be completely sure that the order wont be matched, it has to arrive at all the validators who will be block proposer before the order expires. This is why cancelations seem to be guaranteed slower than placing / matching orders. - -14. How do order statuses transition for the Indexer, for short-term and long-term orders? - - Short-term - - Once the order is placed and seen by the Indexer's full-node, the order has status BEST_EFFORT_OPENED - - If the order is matched and has a fill in a block, the order has status OPEN - - If the order is fully-filled, the order has status FILLED - - If the order is canceled by a cancel order message, the order will be status BEST_EFFORT_CANCELED , the order may still have fills if other validator nodes haven't received the cancel message yet - - If the order expires due to the block height exceeding the good til block of the order, the order status will be CANCELED, the order no longer can be filled - - Long-term - - Once the order is placed and included in a block, the order has status OPEN - - If the order is fully filled, the order has status FILLED - - If the cancelation of the order is included in a block, the order has status CANCELED the order can no longer be filled - -15. How do subaccounts work on dYdX Chain? - - Each address’s subaccounts all fall under a single address, but they are labeled subaccount0, subaccount1, etc. This is unlike v3, where each subaccount was a secondary address. - - To begin trading, you need to make sure your funds are in your subaccount. You can do this two ways: - - Frontend: Simply leave your frontend open and it will automatically sweep. - - Backend: Simply transfer USDC to it like in [this example](https://github.com/dydxprotocol/v4-clients/blob/main/v4-client-js/examples/transfer_example_subaccount_transfer.ts). - -16. When I transfer funds to create a new subaccount (the only way to create new subaccount btw), do I need gas? - - Yes, you will need gas. Fortunately, both USDC and cosmos native DYDX can be used to pay for gas fees. This USDC must be in the main wallet and not another subaccount to pay for fees. - - To ensure this, the frontend leaves a small amount of USDC in your wallet when sweeping into your subaccount, to ensure there's enough to pay for gas. - -17. What impact do subaccounts have on rate limits? - - Rate limits are per account, and not per subaccount. - -18. How do we compete for liquidation orders? - - If you run a full-node, there is a liquidations daemon that has metrics on what accounts are up for liquidation orders, and they could try and compete for liquidations that way. - - However, this is not at all documented so you'll have to work it out by reading code. - -## Trading as it Relates to Validators - -1. How much throughput and latency can be expected from a self-hosted full node? Would having multiple full nodes in different regions improve speed? - - Throughput of up to 1500 orders / second from our load-testing. Latency depends on which validator is the proposer. Having multiple full-nodes in different regions where there are validators (so maybe 1 in Europe + 1 in Tokyo) would lead to improved latency. - -2. 0 Do validators communicate through a public P2P network, or is there an internal network? - - It's a public P2P network. - -3. What is the expected order-to-trade latency under normal conditions? - - Expected order → trade latency would be: - - Time for order to get from the node it was submitted to, to the proposer, so location dependent. - - Order match -> trade, probably at least 1 block so ~1.1s, could be more than 1 block. - -4. Compared to a full node, is it faster to submit transactions directly to the validator, or is it faster to broadcast to the next validator with block-producing rights? - - It would be faster to submit a transaction directly to the block proposer, the difference between a full-node / validator is negligible unless that validator was the proposer. - -5. Do you have some faster validators that we can send orders to? - - Validators usually don't expose the RPC endpoints for orders to be submitted to, and we also don't have a list of validator IPs. - -6. How do other teams improve their speed? - - Some teams are trying to get data about the order book / order updates from a full-node they are running to improve the latency to receiving data, as there is additional latency to getting order updates due to the Indexer systems having additional latency. We currently do not have documentation around this, but are working on it. - -## Indexer - -1. How does the indexer reconstruct the orderbook when it started/initial snapshot of the book? - - A full node is run alongside the Indexer and sends messages to the indexer when it receives orders either from the RPC or gossiped from other nodes, as well as any updates from: - - node pruning the order when it expires - another order that matches an order that the node received earlier - node removing order due to receiving a cancel from RPC or gossip - - The indexer also updates the order book whenever it receives these order messages. - -2. How does the indexer know what orders are in the book on start up? - - On a cold-start, a full-node would still have all the stateful orders and would send them to the indexer. For short-term orders, the full-node would not know them, nor would the indexer. Since short-term orders only are valid for 20 blocks, within 20 blocks the indexer would have an accurate view of the order book, but for the first 20 blocks it would not. - -## MEV - -1. How will dYdX Chain handle MEV? - - Unlike general purpose smart contract environments, the Cosmos infrastructure enables unique MEV solutions to be built that align a validator’s incentives with a user’s incentives. dYdX Chain has a framework where MEV is measured via a [dashboard](https://dydx.exchange/blog/distinguishing-mev-from-expected-noise) created by Skip Protocol. The first step would be to punish validators with slashing. Further proposed solutions are still being considered, and will be announced once finalized. - -2. When do I have finality related to fills? - - When your order fills, a block proposer proposes a block containing the fill (visible to the whole network), and then the block undergoes consensus. If the block is valid, it finalizes shortly thereafter (in Cosmos-speak this happens at the “commit” stage of consensus, after all validators have voted). In Cosmos, every block is final (no reorgs or forks). - - If you’re connected via full node, you’ll see each step of this process. If you’re connected via the indexer service, you’ll see order updates over webSocket as soon as each block is confirmed. - -3. Would deliberately taking already-canceled orders be considered an attack against makers? How can such attacks be mitigated? - - Nodes should respect cancels as soon as they receive them, if they don't then we see that as MEV and the aforementioned dashboard / metrics tracking MEV will track that. - -## Pricing - -1. How is the oracle price is computed? - - The oracle price has five parts: - - Skip Protocol Sidecar: side car that pulls price data from external sources and caches them for the validator to use [link](https://docs.skip.money/slinky/integrations/dydx) - - Vote Extensions: Every block during the Precommit stage, all validators will submit vote extensions for what they believe the oracle price of all tracked assets should be. - - Consensus: The block after VE are submitted, Slinky deterministically aggregates all VE from the previous block and proposes a new updated price which is voted into consensus. - - Module: updates the state based on the new price, also has logic for validation and etc [link](https://github.com/dydxprotocol/v4-chain/tree/main/protocol/x/prices) - - Params: determines the external sources and sensitivity [link](https://github.com/dydxprotocol/v4-testnets/blob/main/dydx-testnet-4/genesis.json#L6106), these are configured per network (testnet genesis example), but should query the network config for these `dydxprotocold query prices list-market-param` - -## Rewards - -1. How will trading rewards work on dYdX Chain? - - Trading rewards are not controlled by dYdX. dYdX recommends that trading rewards could be calculated primarily based on total taker fees paid, along with a few other variables. The full proposed formula can be found [here](./concepts-trading/rewards_fees_and_parameters.md). These rewards could be distributed on a block by block basis (1-2 seconds). - -2. Will liquidity provider rewards exist in v4? - - Liquidity provider rewards in v4 are not controlled by dYdX. dYdX recommends that liquidity provider rewards should cease to exist in v4. Makers could be rewarded with a maker rebate ranging from 0.5bps to 1.1bps, based on their nominal volume and volume share. The full proposed fee schedule can be found [here](./concepts-trading/rewards_fees_and_parameters.md). diff --git a/pages/introduction-onboarding_faqs.mdx b/pages/introduction-onboarding_faqs.mdx index a40e3fe4..2fed411f 100644 --- a/pages/introduction-onboarding_faqs.mdx +++ b/pages/introduction-onboarding_faqs.mdx @@ -36,7 +36,7 @@
5. What is an indexer? -- The indexer is a read-only service that consumes real-time data from dYdX Chain to a database for visibility to users. The indexer consumes data from dYdX Chain via a connection to a full node. The full node contains a copy of the blockchain and an in-memory order book. When the full node updates its copy of the blockchain and in-memory order book due to processing transactions, it will also stream these updates to the indexer. The indexer keeps the data in its database synced with the full-node using these updates. This data is made available to users querying through HTTPS REST APIs and streaming via websockets. More info can be found [here](https://docs.dydx.exchange/architecture/indexer). +- The indexer is a read-only service that consumes real-time data from dYdX Chain to a database for visibility to users. The indexer consumes data from dYdX Chain via a connection to a full node. The full node contains a copy of the blockchain and an in-memory order book. When the full node updates its copy of the blockchain and in-memory order book due to processing transactions, it will also stream these updates to the indexer. The indexer keeps the data in its database synced with the full-node using these updates. This data is made available to users querying through HTTPS REST APIs and streaming via websockets. More info can be found [here](./concepts-architecture/indexer.md).
diff --git a/pages/users-governance/functionalities.md b/pages/users-governance/functionalities.md index 2e928930..f4d63891 100644 --- a/pages/users-governance/functionalities.md +++ b/pages/users-governance/functionalities.md @@ -100,7 +100,7 @@ Governance has the ability to create and modify Liquidity Tiers as well as updat This functionality allows the community to update parameters of a live market, which can be composed of 4 parts - Updating a liquidity tier -- Perpetual (`x/perpetuals`), governance-updatable through `MsgUpdatePerpetual` ([proto definition](https://www.notion.so/Governance-Parameter-Updates-ff8be9ebd380424d8fdd337e2bb1b355?pvs=21)) +- Perpetual (`x/perpetuals`), governance-updatable through `MsgUpdatePerpetualFeeParams` ([proto definition](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/feetiers/tx.proto#L19)) - Market (`x/prices`), governance-updatable through `MsgUpdateMarketParam` ([proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/prices/market_param.proto#L6-L34)) - Clob pair (`x/clob`), governance-updatable through `MsgUpdateClobPair` ([proto](https://github.com/dydxprotocol/v4-chain/blob/b2c6062b4e588b98a51454f50da9e8e712cfc2d9/proto/dydxprotocol/clob/tx.proto#L102)) diff --git a/pages/users-governance/proposing_a_new_market.md b/pages/users-governance/proposing_a_new_market.md index f01e6851..67f0e9af 100644 --- a/pages/users-governance/proposing_a_new_market.md +++ b/pages/users-governance/proposing_a_new_market.md @@ -16,7 +16,7 @@ The proposal should consist of 4 messages to be executed **atomically and in ord Notes: - For guideline on choosing values for individual params, see next [section](./proposing_a_new_market.md#choosing-market-parameters). -- Liquidity tiers are mentioned throughout this page. The liquidity tier documentation can be found [here](./functionalities#liquidity-tiers). +- Liquidity tiers are mentioned throughout this page. The liquidity tier documentation can be found [here](../users-governance/functionalities.md#liquidity-tiers). - The exact ordering of messages above is necessary for successful onchain execution. - Each of the 4 top-level messages should have `Authority = dydx10d07y265gmmuvt4z0w9aw880jnsr700jnmapky`, the [gov module](https://github.com/dydxprotocol/v4-chain/blob/5e72896719e2f8d2fe6e10fddbde18b363a6bbe3/protocol/app/module_accounts_test.go#L28). - The `MsgCreateClobPair` message wrapped in `messages[3]: MsgDelayMessage` should have `Authority = dydx1mkkvp26dngu6n8rmalaxyp3gwkjuzztq5zx6tr`, the [delaymsg module](https://github.com/dydxprotocol/v4-chain/blob/5e72896719e2f8d2fe6e10fddbde18b363a6bbe3/protocol/app/module_accounts_test.go#L36). diff --git a/pages/users-governance/submitting_a_proposal.md b/pages/users-governance/submitting_a_proposal.md index bdd03dbb..ad708ece 100644 --- a/pages/users-governance/submitting_a_proposal.md +++ b/pages/users-governance/submitting_a_proposal.md @@ -13,7 +13,7 @@ dydxprotocold config chain-id [chain_id] ``` ## Confirming Connectivity -To ensure that you are successfully connecting, use any of the RPC endpoints listed in the [resources](../infrastructure_providers-network/resources.mdx/resources.md). Remember to append `:443` to the end of the RPC URI for proper access. Execute the following command, replacing `[RPC ENDPOINT]` with your chosen endpoint: +To ensure that you are successfully connecting, use any of the RPC endpoints listed in the [resources](../infrastructure_providers-network/resources.mdx#full-node-endpoints). Remember to append `:443` to the end of the RPC URI for proper access. Execute the following command, replacing `[RPC ENDPOINT]` with your chosen endpoint: ```bash dydxprotocold status --node https://[RPC ENDPOINT]:443 From b59ba19ee08cbb62e36ae2b25b76319ad0938971 Mon Sep 17 00:00:00 2001 From: James Jia Date: Thu, 30 May 2024 12:54:17 -0400 Subject: [PATCH 09/18] use permalinks in documentation (#213) --- README.md | 2 +- .../how_to_interpret_block_data_for_trades.md | 2 +- .../short_term_vs_stateful.mdx | 4 +-- .../how_to_set_up_full_node.md | 2 +- .../upgrades/performing_upgrades.md | 6 ++-- pages/introduction-onboarding_faqs.mdx | 8 ++--- pages/users-governance/functionalities.md | 32 +++++++++---------- .../users-governance/slashing_a_validator.md | 4 +-- 8 files changed, 30 insertions(+), 30 deletions(-) diff --git a/README.md b/README.md index f611da4d..e00da246 100644 --- a/README.md +++ b/README.md @@ -3,7 +3,7 @@

dYdX Chain Documentation

diff --git a/pages/api_integration-guides/how_to_interpret_block_data_for_trades.md b/pages/api_integration-guides/how_to_interpret_block_data_for_trades.md index 07d236b2..79ef6fd7 100644 --- a/pages/api_integration-guides/how_to_interpret_block_data_for_trades.md +++ b/pages/api_integration-guides/how_to_interpret_block_data_for_trades.md @@ -8,7 +8,7 @@ In dYdX Chain trading, quantities and prices are represented in quantums (for qu The smallest increment of position size. Determined from `atomicResolution`. -atomicResolution - Determines the size of a quantum. [For example](https://github.com/dydxprotocol/v4-testnets/blob/main/dydx-testnet-4/genesis.json#L5776), an `atomicResolution` of 10 for `BTC`, means that 1 quantum is `1e-10` `BTC`. +atomicResolution - Determines the size of a quantum. [For example](https://github.com/dydxprotocol/v4-testnets/blob/aa1c7ac589d6699124942a66c2362acad2e6f50d/dydx-testnet-4/genesis.json#L5776), an `atomicResolution` of 10 for `BTC`, means that 1 quantum is `1e-10` `BTC`. ### Subticks diff --git a/pages/api_integration-trading/short_term_vs_stateful.mdx b/pages/api_integration-trading/short_term_vs_stateful.mdx index bdc371b9..2880a88e 100644 --- a/pages/api_integration-trading/short_term_vs_stateful.mdx +++ b/pages/api_integration-trading/short_term_vs_stateful.mdx @@ -16,10 +16,10 @@ For more details on definitions, see the v4-chain repo [here](https://github.com | inclusion in block | `OperationRaw_ShortTermOrderPlacement` inside `MsgProposedOperations.OperationsQueue` which is an app-injected message in the proposal. Included if and only if the short term order is included in a match. | Normal cosmos transaction. The original Tx which included the `MsgPlaceOrder` or `MsgCancelOrder` would be included directly in the block. | | signature verification | Short-term orders must undergo custom signature verification because they are included in an app-injected transaction.

The memclob stores each short term order placement’s raw transaction bytes in the memclob. When the order is included in a match, an `OperationRaw_ShortTermOrderPlacement` operation is included in `MsgProposedOperations` which contains these bytes.

During `DeliverTx`, we decode the raw transaction bytes into a transaction object and pass the transaction through the app’s antehandler which executes signature verification. If signature verification fails, the `MsgProposedOperations` execution returns an error and none of the operations are persisted to state. Operations for a given block is all-or-nothing, meaning all operations execute or none of them execute. | Normal cosmos transaction signature verification, executed by the app’s antehandler. | | replay prevention | Keep orders in state until after Good-Till-Block aka expiry (even if fully-filled or cancelled) | Cosmos SDK sequence numbers, verified to be strictly increasing in the app’s antehandler.

Note that their use of sequence numbers requires stateful orders to be received in order otherwise they would fail. If placing multiple stateful orders they should be sent to the same validator to prevent issues. | -| time placed (matching logic) | `CheckTx`, immediately after placement transaction is received by the validator.

Short term orders are only included in a block when matched. See “time added to state” below. | long-term: Block N+1 in [PrepareCheckState](https://github.com/dydxprotocol/v4-chain/blob/main/protocol/x/clob/abci.go#L136) where `MsgPlaceOrder` was included in block N
conditional: Block N+1 `PrepareCheckState` where the order was triggered in `EndBlocker` of block N | +| time placed (matching logic) | `CheckTx`, immediately after placement transaction is received by the validator.

Short term orders are only included in a block when matched. See “time added to state” below. | long-term: Block N+1 in [PrepareCheckState](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/protocol/x/clob/abci.go#L136) where `MsgPlaceOrder` was included in block N
conditional: Block N+1 `PrepareCheckState` where the order was triggered in `EndBlocker` of block N | | what is stored in state | `OrderAmountFilledKeyPrefix`:
• key = OrderId
• value = OrderFillAmount & PrunableBlockHeight

`BlockHeightToPotentiallyPrunableOrdersPrefix`:
• key = block height
• value = list of potentially prunable OrderIds

PrunableBlockHeight holds the block height at which we can safely remove this order from state. BlockHeightToPotentiallyPrunableOrders stores a list of order ids which we can prune for a certain block height. These are used in conjunction for replay prevention of short term orders | `StatefulOrderPlacementKeyPrefix`:

• key = OrderId
• value = Order

`StatefulOrdersTimeSlice`:
• key = time
• value = list of OrderIds expiring at this GTBT

`OrderAmountFilledKeyPrefix`:
• key = OrderId
• value = OrderFillAmount & PrunableBlockHeight (prunable block height unused for stateful orders) | | time added to state | `DeliverTx` when part of a match included in `MsgProposedOperations` | `StatefulOrderPlacementKeyPrefix` and `StatefulOrdersTimeSlice`: `DeliverTx`, the [MsgPlaceOrder](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/protocol/x/clob/keeper/msg_server_place_order.go#L22) is executed for `MsgPlaceOrder` msgs included in the block. The handler performs stateful validation, a collateralization check, and writes the order to state. Stateful orders are also written to the checkState in CheckTx for spam mitigation purposes.

`OrderAmountFilledKeyPrefix`: DeliverTx, when part of a match included in `MsgProposedOperations` | -| time removed from state | Always in [EndBlocker](https://github.com/dydxprotocol/v4-chain/blob/main/protocol/x/clob/abci.go#L60) based off of prunable block height | • cancelled by user: removed from state in `DeliverTx` for `MsgCancelOrder`
• forcefully-cancelled by protocol: removed from state in `DeliverTx` when processing `OperationRaw_OrderRemoval` operation. This operation type is included by the proposer in `MsgProposedOperations` when a stateful order is no longer valid. Removal reasons listed [here](https://github.com/dydxprotocol/v4-chain/blob/main/protocol/x/clob/types/order_removals.pb.go#L28)
• fully-filled: removed from state in `DeliverTx` in the block in which they become fully filled. The order is added to `RemovedStatefulOrderIds` of `processProposerMatchesEvents` to be used in `EndBlocker` to remove from the in-memory orderbook.
• expired: pruned during EndBlocker based off of GTBT

also removed from state in CheckTx for cancellations. This is for spam mitigation purposes. | +| time removed from state | Always in [EndBlocker](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/protocol/x/clob/abci.go#L60) based off of prunable block height | • cancelled by user: removed from state in `DeliverTx` for `MsgCancelOrder`
• forcefully-cancelled by protocol: removed from state in `DeliverTx` when processing `OperationRaw_OrderRemoval` operation. This operation type is included by the proposer in `MsgProposedOperations` when a stateful order is no longer valid. Removal reasons listed [here](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/protocol/x/clob/types/order_removals.pb.go#L28)
• fully-filled: removed from state in `DeliverTx` in the block in which they become fully filled. The order is added to `RemovedStatefulOrderIds` of `processProposerMatchesEvents` to be used in `EndBlocker` to remove from the in-memory orderbook.
• expired: pruned during EndBlocker based off of GTBT

also removed from state in CheckTx for cancellations. This is for spam mitigation purposes. | | time added to in-memory orderbook | When placed in `CheckTx`, if not fully-matched | When placed in `PrepareCheckState`, if not fully-matched | | time removed from in-memory orderbook | • when fully-filled: removed in `PrepareCheckState` where invalid memclob state is purged via fully filled orders present in `OrderIdsFilledInLastBlock`
• when cancelled: (CheckTx)
• when expired: PrepareCheckState, removed using memclob.openOrders.blockExpirationsForOrders data structure which stores expiration times for short term orders based off of GTB | • when fully-filled: removed in `PrepareCheckState` where we purge invalid memclob state based off of `RemovedStatefulOrderIds`
• when cancelled: removed in `PrepareCheckState` based off of `PlacedStatefulCancellations`
• when expired: removed in `PrepareCheckState` by `PurgeInvalidMemclobState`, using the list of `ExpiredStatefulOrderIds` produced in `EndBlocker` | diff --git a/pages/infrastructure_providers-validators/how_to_set_up_full_node.md b/pages/infrastructure_providers-validators/how_to_set_up_full_node.md index 5ff26378..e58ff772 100644 --- a/pages/infrastructure_providers-validators/how_to_set_up_full_node.md +++ b/pages/infrastructure_providers-validators/how_to_set_up_full_node.md @@ -60,7 +60,7 @@ tail -f /tmp/fullnode.log 3. The full node is now syncing. To determine whether the full node is caught up with the chain head, please check the applicable block explorer to determine when it reaches the current block – an example block explorer is shown on https://www.mintscan.io/dydx ## Things you can do with the full node -GET CURRENT BLOCK: You can get the current block with this program https://github.com/chiwalfrm/dydxexamples/blob/main/v4block_subscribe.py +GET CURRENT BLOCK: You can get the current block with this program https://github.com/chiwalfrm/dydxexamples/blob/1d46b7a75499205d9c1c1986ae4ae8f21b6c1385/v4block_subscribe.py Run it with the full node IP address and port `26657`: ```bash diff --git a/pages/infrastructure_providers-validators/upgrades/performing_upgrades.md b/pages/infrastructure_providers-validators/upgrades/performing_upgrades.md index 9aac2658..124a9218 100644 --- a/pages/infrastructure_providers-validators/upgrades/performing_upgrades.md +++ b/pages/infrastructure_providers-validators/upgrades/performing_upgrades.md @@ -62,7 +62,7 @@ cosmovisor/ #### Upgrading to a Patch Version (e.g. v0.0.2) -1. Download the [binary](https://github.com/dydxprotocol/v4-testnets/tree/main/dydx-testnet-1/binaries) for the new patch release, rename the binary to `dydxprotocold`. +1. Download the [binary](https://github.com/dydxprotocol/v4-chain/releases) for the new patch release, rename the binary to `dydxprotocold`. ```bash mv dydxprotocold.- dydxprotocold @@ -91,7 +91,7 @@ cosmovisor run start --p2p.seeds="[seed_node_id]@[seed_node_ip_addr]:26656" --br #### Upgrading to a Major/Minor Version (e.g. v0.1.0) -1. Download the [binary](https://github.com/dydxprotocol/v4-testnets/tree/main/dydx-testnet-1/binaries) for the new release. +1. Download the [binary](https://github.com/dydxprotocol/v4-chain/releases) for the new release. 1. Ideally also before the upgrade height to minimize downtime 2. Make sure that the new binary is executable. @@ -108,7 +108,7 @@ chmod 755 dydxprotocold #### Upgrading to a Patch Version (e.g. v0.0.2) -1. Download the [binary](https://github.com/dydxprotocol/v4-testnets/tree/main/dydx-testnet-1/binaries) for the new release. +1. Download the [binary](https://github.com/dydxprotocol/v4-chain/releases) for the new release. 2. Make sure that the new binary is executable. ```bash diff --git a/pages/introduction-onboarding_faqs.mdx b/pages/introduction-onboarding_faqs.mdx index 2fed411f..871550cd 100644 --- a/pages/introduction-onboarding_faqs.mdx +++ b/pages/introduction-onboarding_faqs.mdx @@ -91,7 +91,7 @@ 5. How can I place a short-term order? - Please use the latest dYdX Chain [typescript client](https://www.npmjs.com/package/@dydxprotocol/v4-client-js) to place orders. -- Please refer to the [order.proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/clob/order.proto) for parameter and field definitions. +- Please refer to the [order.proto](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/clob/order.proto) for parameter and field definitions. - For more advanced order placements, please refer to one of the [validator clients](./introduction-getting_started.md#Trading-Via-Api). @@ -118,7 +118,7 @@
8. How can I replace an order? -- Replacing an order reuses the short-term order placement function with the [same order ID](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/clob/order.proto#L10) and an equal-to-or-greater good til block. +- Replacing an order reuses the short-term order placement function with the [same order ID](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/clob/order.proto#L10) and an equal-to-or-greater good til block. - Note: when replacing partially-filled orders, the previous fill amount is counted towards your current order. - Example: Buy 1 BTC order @ $20k is filled for 0.5 BTC. After replacing that order with a Buy 2 BTC order @ $25k, that order can only be filled for a maximum of 1.5 BTC. This is because the previously replaced order was already filled for 0.5 BTC. @@ -207,7 +207,7 @@ - Each address’s subaccounts all fall under a single address, but they are labeled subaccount0, subaccount1, etc. This is unlike v3, where each subaccount was a secondary address. - To begin trading, you need to make sure your funds are in your subaccount. You can do this two ways: - Frontend: Simply leave your frontend open and it will automatically sweep. - - Backend: Simply transfer USDC to it like in [this example](https://github.com/dydxprotocol/v4-clients/blob/main/v4-client-js/examples/transfer_example_subaccount_transfer.ts). + - Backend: Simply transfer USDC to it like in [this example](https://github.com/dydxprotocol/v4-clients/blob/123cd819939fe47ff80dda04b1ac1144dffa4fda/v4-client-js/examples/transfer_example_subaccount_transfer.ts).
@@ -334,7 +334,7 @@ - Vote Extensions: Every block during the Precommit stage, all validators will submit vote extensions for what they believe the oracle price of all tracked assets should be. - Consensus: The block after VE are submitted, Slinky deterministically aggregates all VE from the previous block and proposes a new updated price which is voted into consensus. - Module: updates the state based on the new price, also has logic for validation and etc. [link](https://github.com/dydxprotocol/v4-chain/tree/main/protocol/x/prices). - - Params: determines the external sources and sensitivity [link](https://github.com/dydxprotocol/v4-testnets/blob/main/dydx-testnet-4/genesis.json#L6106), these are configured per network (testnet genesis example), but should query the network config for these `dydxprotocold query prices list-market-param`. + - Params: determines the external sources and sensitivity [link](https://github.com/dydxprotocol/v4-testnets/blob/aa1c7ac589d6699124942a66c2362acad2e6f50d/dydx-testnet-4/genesis.json#L6106), these are configured per network (testnet genesis example), but should query the network config for these `dydxprotocold query prices list-market-param`. diff --git a/pages/users-governance/functionalities.md b/pages/users-governance/functionalities.md index f4d63891..cdfb3401 100644 --- a/pages/users-governance/functionalities.md +++ b/pages/users-governance/functionalities.md @@ -8,11 +8,11 @@ Below is a current list of all module parameters that `x/gov` has the ability to The Stats Module tracks user maker and taker volumes over a period of time (aka look-back window). This is currently set to 30 days. The maker and taker volume info is used to place users in corresponding fee-tiers. -Governance has the ability to update the params of the Stats Module, which defines the look-back window (measured in seconds). [Proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/stats/params.proto#L10-L14) +Governance has the ability to update the params of the Stats Module, which defines the look-back window (measured in seconds). [Proto](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/stats/params.proto#L10-L14) ### FeeTiers Module -Governance has the ability to update fee tiers ([proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/feetiers/params.proto#L6-L10)). To read more about fee tiers head to [V4 Deep Dive: Rewards and Parameters](https://dydx.exchange/blog/v4-rewards-and-parameters). +Governance has the ability to update fee tiers ([proto](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/feetiers/params.proto#L6-L10)). To read more about fee tiers head to [V4 Deep Dive: Rewards and Parameters](https://dydx.exchange/blog/v4-rewards-and-parameters). ## Trading Core @@ -24,7 +24,7 @@ Note: any account has the ability to send assets to the Insurance Fund. ### Liquidations Config -Governance has the ability to adjust how liquidations are processed. [Proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/clob/liquidations_config.proto#L8-L34) +Governance has the ability to adjust how liquidations are processed. [Proto](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/clob/liquidations_config.proto#L8-L34) - Max Insurance Fund quantums for deleveraging: The maximum number of quote quantums (exclusive) that the insurance fund can have for deleverages to be enabled. - The maximum liquidation fee, in parts-per-million. 100% of this fee goes to the Insurance Fund @@ -36,9 +36,9 @@ Governance has the ability to adjust how liquidations are processed. [Proto](htt Governance has the ability to adjust Funding Rate parameters: -- Funding rate clamp factor, premium vote clamp factor, and min number of votes per premium sample. [Proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/perpetuals/params.proto#L6-L19) -- Epoch information, which defines the funding interval and premium sampling interval. [Proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/epochs/epoch_info.proto#L6-L43) -- Liquidity Tier, which defines the impact notional value. [Proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/perpetuals/perpetual.proto#L84-L113) +- Funding rate clamp factor, premium vote clamp factor, and min number of votes per premium sample. [Proto](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/perpetuals/params.proto#L6-L19) +- Epoch information, which defines the funding interval and premium sampling interval. [Proto](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/epochs/epoch_info.proto#L6-L43) +- Liquidity Tier, which defines the impact notional value. [Proto](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/perpetuals/perpetual.proto#L84-L113) ## Trading Rewards @@ -46,7 +46,7 @@ Governance has the ability to adjust Funding Rate parameters: The Vest Module is responsible for determining the rate of tokens that vest from Vester Accounts to other accounts such as a Community Treasury Account and a Rewards Treasury Account. The rate of token transfers is linear with respect to time. Thus, block timestamps are used to vest tokens. -Governance has the ability to create, update, or delete a `VestEntry` ([proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/vest/vest_entry.proto#L9-L30)), which defines: +Governance has the ability to create, update, or delete a `VestEntry` ([proto](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/vest/vest_entry.proto#L9-L30)), which defines: - The start and end time of vesting - The token that is vested @@ -55,7 +55,7 @@ Governance has the ability to create, update, or delete a `VestEntry` ([proto](h ### Rewards Module -The Rewards Module distributes trading rewards to traders (previously written about [V4 Deep Dive: Rewards and Parameters](https://dydx.exchange/blog/v4-rewards-and-parameters)). Governance has the ability to adjust the following ([proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/rewards/params.proto#L6-L26)): +The Rewards Module distributes trading rewards to traders (previously written about [V4 Deep Dive: Rewards and Parameters](https://dydx.exchange/blog/v4-rewards-and-parameters)). Governance has the ability to adjust the following ([proto](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/rewards/params.proto#L6-L26)): - Which account Trading Rewards are funded from - The token Trading Rewards are funded in @@ -66,7 +66,7 @@ The Rewards Module distributes trading rewards to traders (previously written ab ### Oracles -Governance has the ability to adjust the list of oracles used for each market. [Proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/prices/market_param.proto#L31-L33) +Governance has the ability to adjust the list of oracles used for each market. [Proto](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/prices/market_param.proto#L31-L33) Note that this functionality does not include creating / removing an exchange-source supported by the protocol as a whole, which will require a binary upgrade. @@ -93,7 +93,7 @@ Current Liquidity Tiers include: - Then a market’s `Effective IMF = Min(Base IMF + Max(IMF Increase, 0), 1.0)` - The effective IMF is the base IMF while the Open Notional < Lower Cap, and increases linearly until Open Notional = Upper Cap, at which point the IMF stays at 1.0 (requiring 1:1 collateral for trading) -Governance has the ability to create and modify Liquidity Tiers as well as update existing markets’ Liquidity Tier placements. ([proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/perpetuals/perpetual.proto#L84-L113)) +Governance has the ability to create and modify Liquidity Tiers as well as update existing markets’ Liquidity Tier placements. ([proto](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/perpetuals/perpetual.proto#L84-L113)) ### Updating a Live Market @@ -101,7 +101,7 @@ This functionality allows the community to update parameters of a live market, w - Updating a liquidity tier - Perpetual (`x/perpetuals`), governance-updatable through `MsgUpdatePerpetualFeeParams` ([proto definition](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/feetiers/tx.proto#L19)) -- Market (`x/prices`), governance-updatable through `MsgUpdateMarketParam` ([proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/prices/market_param.proto#L6-L34)) +- Market (`x/prices`), governance-updatable through `MsgUpdateMarketParam` ([proto](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/prices/market_param.proto#L6-L34)) - Clob pair (`x/clob`), governance-updatable through `MsgUpdateClobPair` ([proto](https://github.com/dydxprotocol/v4-chain/blob/b2c6062b4e588b98a51454f50da9e8e712cfc2d9/proto/dydxprotocol/clob/tx.proto#L102)) ### Adding New Markets @@ -121,8 +121,8 @@ MsgDelayMessage (schedule a MsgSetClobPairStatus to enable trading in x/clob) To prevent spam on the orderbook and prevent the blockchain state from getting too large, governance has the ability to adjust: -- How many open orders a subaccount can have based on its equity tier. [Proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/clob/equity_tier_limit_config.proto#L8-L19) -- Order placement rate limits. [Proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/clob/block_rate_limit_config.proto#L8-L35) +- How many open orders a subaccount can have based on its equity tier. [Proto](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/clob/equity_tier_limit_config.proto#L8-L19) +- Order placement rate limits. [Proto](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/clob/block_rate_limit_config.proto#L8-L35) ## Bridge @@ -132,9 +132,9 @@ The Bridge Module is responsible for receiving bridged tokens from the Ethereum Governance has the ability to update: -- Event Parameters: Specifies which events to recognize and which tokens to mint. [Proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/bridge/params.proto#L9-L20) -- Proposal Parameters: Determines how long a validator should wait until it proposes a bridge event to other validators, and how many or often to propose new bridge events. [Proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/bridge/params.proto#L22-L45) -- Safety Parameters: Determines if bridging is enabled/disabled and how many blocks mints are delayed after being accepted by consensus. [Proto](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/bridge/params.proto#L47-L55) +- Event Parameters: Specifies which events to recognize and which tokens to mint. [Proto](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/bridge/params.proto#L9-L20) +- Proposal Parameters: Determines how long a validator should wait until it proposes a bridge event to other validators, and how many or often to propose new bridge events. [Proto](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/bridge/params.proto#L22-L45) +- Safety Parameters: Determines if bridging is enabled/disabled and how many blocks mints are delayed after being accepted by consensus. [Proto](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/bridge/params.proto#L47-L55) ## Community Assets diff --git a/pages/users-governance/slashing_a_validator.md b/pages/users-governance/slashing_a_validator.md index 3eeab902..7b56eca7 100644 --- a/pages/users-governance/slashing_a_validator.md +++ b/pages/users-governance/slashing_a_validator.md @@ -4,14 +4,14 @@ The chain supports slashing of misbehaving validators through governance vote. ## Proposal Message -The proposal should contain a single [MsgSlashValidator](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/govplus/tx.proto#L19) message for each validator that should be slashed. +The proposal should contain a single [MsgSlashValidator](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/govplus/tx.proto#L19) message for each validator that should be slashed. Notes: - The slashing will occur when the proposal is passed, not the `infraction_height`. - The `infraction_height` must be set so that `time(proposal pass height) - time(infraction_height) < unbonding period`. Typically a good choice for `infraction_height` is the current height unless there is a recent unbonding undelegation/redelegation that should be included in the slash. In that case the `infraction_height` should be set prior to the initiation of the undelegation/redelegation. - Both `tokens_at_infraction_height` and `slash_factor` must be set correctly, otherwise undelegations and redelegations might be slashed disproportionately to the rest of the validator's stake. `tokens_at_infraction_height * slash_factor` determines the total amount of tokens to be slashed. Unbonding delegations and redelegations are first slashed by `slash_factor`, and then the remaining amount is taken from the validator's stake. - The x/staking `HistoricalInfo` query endpoint can be used to find the correct value for `tokens_at_infraction_height`. -- See the [MsgSlashValidator](https://github.com/dydxprotocol/v4-chain/blob/main/proto/dydxprotocol/govplus/tx.proto#L19) inline comments for further details on the above requirements. +- See the [MsgSlashValidator](https://github.com/dydxprotocol/v4-chain/blob/4eb219b1b726df9ba17c9939e8bb9296f5e98bb3/proto/dydxprotocol/govplus/tx.proto#L19) inline comments for further details on the above requirements. ### Example Proposal Json From 0982c0e78f11767cc7a5fcd213e6f06a03fa285d Mon Sep 17 00:00:00 2001 From: James Jia Date: Thu, 30 May 2024 13:21:36 -0400 Subject: [PATCH 10/18] Move api integration files (#214) --- pages/_meta.json | 5 ++++- .../clients => api_integration-clients}/_meta.json | 0 .../composite_client.mdx | 0 .../clients => api_integration-clients}/indexer_client.mdx | 0 .../clients => api_integration-clients}/socket_client.mdx | 0 .../validator_client.mdx | 0 .../constants.md => api_integration-constants.md} | 0 pages/api_integration-developers/_meta.json | 6 ------ .../indexer => api_integration-indexer}/_meta.json | 0 .../indexer => api_integration-indexer}/indexer_api.mdx | 0 .../indexer_websocket.md | 0 ...urce_repositories.md => api_integration-repositories.md} | 0 12 files changed, 4 insertions(+), 7 deletions(-) rename pages/{api_integration-developers/clients => api_integration-clients}/_meta.json (100%) rename pages/{api_integration-developers/clients => api_integration-clients}/composite_client.mdx (100%) rename pages/{api_integration-developers/clients => api_integration-clients}/indexer_client.mdx (100%) rename pages/{api_integration-developers/clients => api_integration-clients}/socket_client.mdx (100%) rename pages/{api_integration-developers/clients => api_integration-clients}/validator_client.mdx (100%) rename pages/{api_integration-developers/constants.md => api_integration-constants.md} (100%) delete mode 100644 pages/api_integration-developers/_meta.json rename pages/{api_integration-developers/indexer => api_integration-indexer}/_meta.json (100%) rename pages/{api_integration-developers/indexer => api_integration-indexer}/indexer_api.mdx (100%) rename pages/{api_integration-developers/indexer => api_integration-indexer}/indexer_websocket.md (100%) rename pages/{api_integration-developers/open_source_repositories.md => api_integration-repositories.md} (100%) diff --git a/pages/_meta.json b/pages/_meta.json index ee2979ec..e3353dd1 100644 --- a/pages/_meta.json +++ b/pages/_meta.json @@ -22,9 +22,12 @@ "type": "separator" }, + "api_integration-clients": "Client Documentation", + "api_integration-indexer": "Indexer Documentation", + "api_integration-repositories": "Repositories", "api_integration-trading": "Trading", "api_integration-deposits_and_withdrawals": "Deposits and Withdrawals", - "api_integration-developers": "Developers", + "api_integration-constants": "Constants", "api_integration-guides": "Guides", "----------USERS----------": { diff --git a/pages/api_integration-developers/clients/_meta.json b/pages/api_integration-clients/_meta.json similarity index 100% rename from pages/api_integration-developers/clients/_meta.json rename to pages/api_integration-clients/_meta.json diff --git a/pages/api_integration-developers/clients/composite_client.mdx b/pages/api_integration-clients/composite_client.mdx similarity index 100% rename from pages/api_integration-developers/clients/composite_client.mdx rename to pages/api_integration-clients/composite_client.mdx diff --git a/pages/api_integration-developers/clients/indexer_client.mdx b/pages/api_integration-clients/indexer_client.mdx similarity index 100% rename from pages/api_integration-developers/clients/indexer_client.mdx rename to pages/api_integration-clients/indexer_client.mdx diff --git a/pages/api_integration-developers/clients/socket_client.mdx b/pages/api_integration-clients/socket_client.mdx similarity index 100% rename from pages/api_integration-developers/clients/socket_client.mdx rename to pages/api_integration-clients/socket_client.mdx diff --git a/pages/api_integration-developers/clients/validator_client.mdx b/pages/api_integration-clients/validator_client.mdx similarity index 100% rename from pages/api_integration-developers/clients/validator_client.mdx rename to pages/api_integration-clients/validator_client.mdx diff --git a/pages/api_integration-developers/constants.md b/pages/api_integration-constants.md similarity index 100% rename from pages/api_integration-developers/constants.md rename to pages/api_integration-constants.md diff --git a/pages/api_integration-developers/_meta.json b/pages/api_integration-developers/_meta.json deleted file mode 100644 index 1c3922d6..00000000 --- a/pages/api_integration-developers/_meta.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "indexer": "Indexer", - "clients": "Clients", - "open_source_repositories": "Open-Source Repositories", - "constants": "Constants" -} diff --git a/pages/api_integration-developers/indexer/_meta.json b/pages/api_integration-indexer/_meta.json similarity index 100% rename from pages/api_integration-developers/indexer/_meta.json rename to pages/api_integration-indexer/_meta.json diff --git a/pages/api_integration-developers/indexer/indexer_api.mdx b/pages/api_integration-indexer/indexer_api.mdx similarity index 100% rename from pages/api_integration-developers/indexer/indexer_api.mdx rename to pages/api_integration-indexer/indexer_api.mdx diff --git a/pages/api_integration-developers/indexer/indexer_websocket.md b/pages/api_integration-indexer/indexer_websocket.md similarity index 100% rename from pages/api_integration-developers/indexer/indexer_websocket.md rename to pages/api_integration-indexer/indexer_websocket.md diff --git a/pages/api_integration-developers/open_source_repositories.md b/pages/api_integration-repositories.md similarity index 100% rename from pages/api_integration-developers/open_source_repositories.md rename to pages/api_integration-repositories.md From dcf321f46bb87833f7b3a35d61a1920d7192f538 Mon Sep 17 00:00:00 2001 From: James Jia Date: Fri, 31 May 2024 18:19:40 -0400 Subject: [PATCH 11/18] fixes (#216) --- pages/_error.tsx | 26 ++ .../resources.mdx | 339 ++++++++++-------- .../hardware_requirements.md | 4 +- 3 files changed, 211 insertions(+), 158 deletions(-) create mode 100644 pages/_error.tsx diff --git a/pages/_error.tsx b/pages/_error.tsx new file mode 100644 index 00000000..7c855dbd --- /dev/null +++ b/pages/_error.tsx @@ -0,0 +1,26 @@ +import React from 'react'; + +const CustomError: React.FC = () => { + return ( +
+

Page Not Found

+

The page you are looking for does not exist. Head back to the homepage here.

+
+ ); +}; + +export default CustomError; diff --git a/pages/infrastructure_providers-network/resources.mdx b/pages/infrastructure_providers-network/resources.mdx index 3a8368a9..98a6e59e 100644 --- a/pages/infrastructure_providers-network/resources.mdx +++ b/pages/infrastructure_providers-network/resources.mdx @@ -5,45 +5,35 @@ import { Tab, Tabs } from 'nextra-theme-docs'; ## `networks` repositories - `https://github.com/dydxprotocol/v4-testnets/tree/main/dydx-testnet-4` - `https://github.com/dydxopsdao/networks/tree/main/dydx-mainnet-1` + https://github.com/dydxprotocol/v4-testnets/tree/main/dydx-testnet-4 + https://github.com/dydxopsdao/networks/tree/main/dydx-mainnet-1 ## Upgrades History - For **Testnet**: | Block Height | Compatible Versions | Comments | - |---------------|---------------------| -------- | | 1 ~ 5,000,000 | - [v2.0.1](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv2.0.1)
{' '} - [v2.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv2.0.0)
{' '} - [v1.0.1](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv1.0.1)
{' '} - [v1.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv1.0.0) | The chain - was never upgraded to `v2.0.0` | | 5,000,001 ~ 6,880,000 | - [v3.0.2](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv3.0.2)
{' '} - [v3.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv3.0.0)
| | | - 6,880,001 ~ 10,450,000 | - [v4.0.5](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv4.0.5) | | | - 10,450,001 ~ | [v4.1.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv4.1.0) - | | +For **Testnet**: + +| Block Height | Compatible Versions | Comments | +| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------- | +| 1 ~ 5,000,000 | [v2.0.1](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv2.0.1)
[v2.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv2.0.0)
[v1.0.1](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv1.0.1)
[v1.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv1.0.0) | The chain was never upgraded to `v2.0.0` | +| 5,000,001 ~ 6,880,000 | [v3.0.2](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv3.0.2)
[v3.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv3.0.0)
| | +| 6,880,001 ~ 10,450,000 | [v4.0.5](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv4.0.5) | | +| 10,450,001 ~ | [v4.1.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv4.1.0) | | + - For **the deployment by DYDX token holders**: | Block Height | Compatible Versions | Comments | - |---------------|---------------------| -------- | | 1 ~ 1,805,000 | - [v2.0.1](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv2.0.1)
{' '} - [v1.0.1](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv1.0.1)
{' '} - [v1.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv1.0.0) | `v1.0.1` was - a rolling upgrade;
`v2.0.1` was backported to enable easier syncing from block 1 | | - 1,805,001 ~ 7,147,832 | - [v2.0.1](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv2.0.1)
{' '} - [v2.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv2.0.0) | `v2.0.0` was - an emergency fix | | 7,147,833 ~ 12,791,712 | - [v3.0.2](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv3.0.2)
{' '} - [v3.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv3.0.0) | | | - 12,791,713 ~ 14,404,200 | - [v4.0.5](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv4.0.5) | | | - 14,404,201 ~ | [v4.1.2](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv4.1.2){' '} -
[v4.1.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv4.1.0) | | +For **the deployment by DYDX token holders**: + +| Block Height | Compatible Versions | Comments | +| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | +| 1 ~ 1,805,000 | [v2.0.1](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv2.0.1)
[v1.0.1](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv1.0.1)
[v1.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv1.0.0) | `v1.0.1` was a rolling upgrade;
`v2.0.1` was backported to enable easier syncing from block 1 | +| 1,805,001 ~ 7,147,832 | [v2.0.1](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv2.0.1)
[v2.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv2.0.0) | `v2.0.0` was an emergency fix | +| 7,147,833 ~ 12,791,712 | [v3.0.2](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv3.0.2)
[v3.0.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv3.0.0) | | +| 12,791,713 ~ 14,404,200 | [v4.0.5](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv4.0.5) | | +| 14,404,201 ~ | [v4.1.2](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv4.1.2)
[v4.1.0](https://github.com/dydxprotocol/v4-chain/releases/tag/protocol%2Fv4.1.0) | | + @@ -51,28 +41,32 @@ import { Tab, Tabs } from 'nextra-theme-docs'; - For **Testnet**: | Team | URI | | ------------- | - --------------------------------------------------------------------------------------- | | - AllThatNode: | - `19d38bb5cea1378db3e16615e63594dc26119a1a@dydx-testnet4-seednode.allthatnode.com:26656` | | - Crosnest: | `87ee8de5f0f82af6ee6740a30f8844bbe6434413@seed.dydx-testnet.cros-nest.com:26656` | | - CryptoCrew: | `38e5a5ec34c578dc323cbdd9b98330abb448d586@tenderseed.ccvalidators.com:29104` | | - KingNodes: | `80a1a6cd086634c34008c6457d3f7441cfc05c47@seeds.kingnodes.com:27056` | | - StakingCabin: | - `182ab0015fb4b7d751b12a9c0162ac123445eac1@seed.dydx-testnet.stakingcabin.com:26656` | | - StakerSpace: | `76b472b107ccf20c3d6c110c4a2a217306d2dedb@dydx-seed.staker.space:26656` | +For **Testnet**: + +| Team | URI | +| ------------- | --------------------------------------------------------------------------------------- | +| AllThatNode | `19d38bb5cea1378db3e16615e63594dc26119a1a@dydx-testnet4-seednode.allthatnode.com:26656` | +| Crosnest: | `87ee8de5f0f82af6ee6740a30f8844bbe6434413@seed.dydx-testnet.cros-nest.com:26656` | +| CryptoCrew: | `38e5a5ec34c578dc323cbdd9b98330abb448d586@tenderseed.ccvalidators.com:29104` | +| KingNodes: | `80a1a6cd086634c34008c6457d3f7441cfc05c47@seeds.kingnodes.com:27056` | +| StakingCabin: | `182ab0015fb4b7d751b12a9c0162ac123445eac1@seed.dydx-testnet.stakingcabin.com:26656` | +| StakerSpace: | `76b472b107ccf20c3d6c110c4a2a217306d2dedb@dydx-seed.staker.space:26656` | + - For **the deployment by DYDX token holders**: | Team | URI | | ------------- | - -------------------------------------------------------------------------------------- | | - Polkachu | `ade4d8bc8cbe014af6ebdf3cb7b1e9ad36f412c0@seeds.polkachu.com:23856` | | KingNodes | - `65b740ee326c9260c30af1f044e9cda63c73f7c1@seeds.kingnodes.net:23856` | | Bware Labs | - `f04a77b92d0d86725cdb2d6b7a7eb0eda8c27089@dydx-mainnet-seed.bwarelabs.com:36656` | | - Lavender.Five | `20e1000e88125698264454a884812746c2eb4807@seeds.lavenderfive.com:23856` | | - CryptoCrew | `c2c2fcb5e6e4755e06b83b499aff93e97282f8e8@tenderseed.ccvalidators.com:26401` | | - DSRV | `a9cae4047d5c34772442322b10ef5600d8e54900@dydx-mainnet-seednode.allthatnode.com:26656` | - | Luganodes | `802607c6db8148b0c68c8a9ec1a86fd3ba606af6@64.227.38.88:26656` | | AutoStake | - `ebc272824924ea1a27ea3183dd0b9ba713494f83@dydx-mainnet-seed.autostake.com:27366` | +For **the deployment by DYDX token holders**: + +| Team | URI | +| ------------- | -------------------------------------------------------------------------------------- | +| Polkachu | `ade4d8bc8cbe014af6ebdf3cb7b1e9ad36f412c0@seeds.polkachu.com:23856` | +| KingNodes | `65b740ee326c9260c30af1f044e9cda63c73f7c1@seeds.kingnodes.net:23856` | +| Bware Labs | `f04a77b92d0d86725cdb2d6b7a7eb0eda8c27089@dydx-mainnet-seed.bwarelabs.com:36656` | +| Lavender.Five | `20e1000e88125698264454a884812746c2eb4807@seeds.lavenderfive.com:23856` | +| CryptoCrew | `c2c2fcb5e6e4755e06b83b499aff93e97282f8e8@tenderseed.ccvalidators.com:26401` | +| DSRV | `a9cae4047d5c34772442322b10ef5600d8e54900@dydx-mainnet-seednode.allthatnode.com:26656` | +| Luganodes | `802607c6db8148b0c68c8a9ec1a86fd3ba606af6@64.227.38.88:26656` | +| AutoStake | `ebc272824924ea1a27ea3183dd0b9ba713494f83@dydx-mainnet-seed.autostake.com:27366` | + @@ -80,14 +74,22 @@ import { Tab, Tabs } from 'nextra-theme-docs'; - For **Testnet**: | Type | URI | | ---- | --------------------------------------------- | | API | - `https://indexer.v4testnet.dydx.exchange` | | WS | `wss://indexer.v4testnet.dydx.exchange/v4/ws` - | +For **Testnet**: + +| Type | URI | +| ---- | --------------------------------------------- | +| API | `https://indexer.v4testnet.dydx.exchange` | +| WS | `wss://indexer.v4testnet.dydx.exchange/v4/ws` | + - For **the deployment by DYDX token holders**: | Type | URI | | ---- | - -------------------------------- | | API | `https://indexer.dydx.trade/v4` | | WS | - `wss://indexer.dydx.trade/v4/ws` | +For **the deployment by DYDX token holders**: + +| Type | URI | +| ---- | -------------------------------- | +| API | `https://indexer.dydx.trade/v4` | +| WS | `wss://indexer.dydx.trade/v4/ws` | + @@ -95,41 +97,52 @@ import { Tab, Tabs } from 'nextra-theme-docs'; - For **Testnet**: | Team | StateSync Peers | | -------- | - -------------------------------------------------------------- | | Polkachu | - `0d17772cbba3b488ad895b17b9a48948e480b1fa@65.109.23.114:23856` | +For **Testnet**: + +| Team | StateSync Peers | +| -------- | -------------------------------------------------------------- | +| Polkachu | `0d17772cbba3b488ad895b17b9a48948e480b1fa@65.109.23.114:23856` | + - For **the deployment by DYDX token holders**: | Team | StateSync Peers | Region | | - | - | - | - | KingNodes | `f94dcfbccb9019584d1790562a020507b050d9ba@51.77.56.23:23856`
{' '} - `6bc1068d9a257931083ddc75ad3b1003a46e5b0d@15.235.160.127:23856` | `EU_West`
`Asia_SE` | | - Polkachu | `580ec248de1f41d4e50abe132b7838348db55b80@176.9.144.40:23856`
{' '} - `90b0ee8e73d8237b06356b244ff9854d1991a1f8@65.109.115.228:23856`
{' '} - `874b5ab53d8f5edae6674ad394f20e2b297cf73f@199.254.199.182:23856`
{' '} - `e3aa07f6f97fcccdf57b64aa5f4f11761df3852a@15.235.160.15:23856`
{' '} - `a879fe2926c2b8f0d86e8e973210c30b8634abb4@15.235.204.159:23856` | `Germany`
`Finland`{' '} -
`Japan`
`Singapore`
`Singapore` | | Bware Labs | - `b0137ca9fec8d2990d804e20bc5b74e641bb45e8@dydx-mainnet-statesync-rpc.bwarelabs.com:443` | - `Germany` | | AutoStake | - `ebc272824924ea1a27ea3183dd0b9ba713494f83@dydx-mainnet-peer.autostake.com:27366` | `EU,Poland` | +For **the deployment by DYDX token holders**: + +| Team | StateSync Peers | Region | +| ---------- | --------------------------------------------------------------------------------------- | --------- | +| KingNodes | `f94dcfbccb9019584d1790562a020507b050d9ba@51.77.56.23:23856` | EU_West | +| KingNodes | `6bc1068d9a257931083ddc75ad3b1003a46e5b0d@15.235.160.127:23856` | Asia_SE | +| Polkachu | `580ec248de1f41d4e50abe132b7838348db55b80@176.9.144.40:23856`
| Germany | +| Polkachu | `90b0ee8e73d8237b06356b244ff9854d1991a1f8@65.109.115.228:23856`
| Finland | +| Polkachu | `874b5ab53d8f5edae6674ad394f20e2b297cf73f@199.254.199.182:23856`
| Japan | +| Polkachu | `e3aa07f6f97fcccdf57b64aa5f4f11761df3852a@15.235.160.15:23856`
| Singapore | +| Polkachu | `a879fe2926c2b8f0d86e8e973210c30b8634abb4@15.235.204.159:23856`
| Singapore | +| Bware Labs | `b0137ca9fec8d2990d804e20bc5b74e641bb45e8@dydx-mainnet-statesync-rpc.bwarelabs.com:443` | Germany | +| AutoStake | `ebc272824924ea1a27ea3183dd0b9ba713494f83@dydx-mainnet-peer.autostake.com:27366` | EU_Poland | + ## Snapshot Service - For **Testnet**: | Team | URI | Pruning | Index | | ---------- | - -------------------------------------- | ------- | ----- | | Bware Labs | - `https://bwarelabs.com/snapshots/dydx` | Yes | null | +For **Testnet**: + +| Team | URI | Pruning | Index | +| ---------- | -------------------------------------- | ------- | ----- | +| Bware Labs | `https://bwarelabs.com/snapshots/dydx` | Yes | null | + - For **the deployment by DYDX token holders**: | Team | URI | Pruning | Index | | ------------- | - --------------------------------------------------------- | ------- | ----- | | Bware Labs | - `https://bwarelabs.com/snapshots/dydx` | Yes | null | | Polkachu | - `https://polkachu.com/tendermint_snapshots/dydx` | Yes | null | | KingNodes | - `https://dydx-archive-snapshot.kingnodes.com/` | No | kv | | Lavender.Five | - `https://services.lavenderfive.com/mainnet/dydx/snapshot` | Yes | | | AutoStake | - `https://autostake.com/networks/dydx/#services` | Yes | null | +For **the deployment by DYDX token holders**: + +| Team | URI | Pruning | Index | +| ------------- | --------------------------------------------------------- | ------- | ----- | +| Bware Labs | `https://bwarelabs.com/snapshots/dydx` | Yes | null | +| Polkachu | `https://polkachu.com/tendermint_snapshots/dydx` | Yes | null | +| KingNodes | `https://dydx-archive-snapshot.kingnodes.com/` | No | kv | +| Lavender.Five | `https://services.lavenderfive.com/mainnet/dydx/snapshot` | Yes | | +| AutoStake | `https://autostake.com/networks/dydx/#services` | Yes | null | + @@ -140,64 +153,71 @@ import { Tab, Tabs } from 'nextra-theme-docs'; For **Testnet**: **RPC** -| Team | URI | + +| Team | URI | | ------------- | ----------------------------------------------- | -| Enigma | `https://dydx-rpc-testnet.enigma-validator.com` | -| Lavender Five | `https://testnet-dydx-rpc.lavenderfive.com` | -| King Nodes | `https://test-dydx-rpc.kingnodes.com` | -| Polkachu | `https://dydx-testnet-rpc.polkachu.com` | +| Enigma | `https://dydx-rpc-testnet.enigma-validator.com` | +| Lavender Five | `https://testnet-dydx-rpc.lavenderfive.com` | +| King Nodes | `https://test-dydx-rpc.kingnodes.com` | +| Polkachu | `https://dydx-testnet-rpc.polkachu.com` | **REST** -| Team | URI | -| ------------- | ------------------------------------------------ | -| Enigma | `https://dydx-lcd-testnet.enigma-validator.com` | -| Lavender Five | `https://testnet-dydx-api.lavenderfive.com` | -| King Nodes | `https://test-dydx-rest.kingnodes.com` | -| Polkachu | `https://dydx-testnet-api.polkachu.com` | + +| Team | URI | +| ------------- | ----------------------------------------------- | +| Enigma | `https://dydx-lcd-testnet.enigma-validator.com` | +| Lavender Five | `https://testnet-dydx-api.lavenderfive.com` | +| King Nodes | `https://test-dydx-rest.kingnodes.com` | +| Polkachu | `https://dydx-testnet-api.polkachu.com` | **gRPC** -| Team | URI | -| ------------- | ---------------------------------------- | -| Lavender Five | `testnet-dydx-grpc.lavenderfive.com:443` | -| King Nodes | `https://test-dydx-grpc.kingnodes.com`
`https://test-dydx-grpc-web.kingnodes.com` | -| Polkachu | `dydx-testnet-grpc.polkachu.com:23890` | + +| Team | URI | +| ------------- | ------------------------------------------ | +| Lavender Five | `testnet-dydx-grpc.lavenderfive.com:443` | +| King Nodes | `https://test-dydx-grpc.kingnodes.com` | +| King Nodes | `https://test-dydx-grpc-web.kingnodes.com` | +| Polkachu | `dydx-testnet-grpc.polkachu.com:23890` | For **the deployment by DYDX token holders**: **RPC** -| Team | URI | Rate limit | + +| Team | URI | Rate limit | | ------------- | ------------------------------------------------------ | ---------- | -| Polkachu | `https://dydx-dao-rpc.polkachu.com:443` | 300 req/m | -| Bware Labs | `https://dydx-mainnet-full-rpc.public.blastapi.io:443` | 20 req/s | -| KingNodes | `https://dydx-ops-rpc.kingnodes.com:443` | 250 req/m | -| Lavender.Five | `https://dydx-rpc.lavenderfive.com:443` | | -| AutoStake | `https://dydx-mainnet-rpc.autostake.com:443` | 4 req/s | -| EcoStake | `https://rpc-dydx.ecostake.com:443` | | -| PublicNode | `https://dydx-rpc.publicnode.com:443` | | -| Enigma | `https://dydx-rpc.enigma-validator.com:443` | | +| Polkachu | `https://dydx-dao-rpc.polkachu.com:443` | 300 req/m | +| Bware Labs | `https://dydx-mainnet-full-rpc.public.blastapi.io:443` | 20 req/s | +| KingNodes | `https://dydx-ops-rpc.kingnodes.com:443` | 250 req/m | +| Lavender.Five | `https://dydx-rpc.lavenderfive.com:443` | | +| AutoStake | `https://dydx-mainnet-rpc.autostake.com:443` | 4 req/s | +| EcoStake | `https://rpc-dydx.ecostake.com:443` | | +| PublicNode | `https://dydx-rpc.publicnode.com:443` | | +| Enigma | `https://dydx-rpc.enigma-validator.com:443` | | **REST** -| Team | URI | Rate limit | + +| Team | URI | Rate limit | | ------------- | ------------------------------------------------------ | ---------- | -| Polkachu | `https://dydx-dao-api.polkachu.com:443` | 300 req/m | -| Bware Labs | `https://dydx-mainnet-full-lcd.public.blastapi.io:443` | 20 req/s | -| KingNodes | `https://dydx-ops-rest.kingnodes.com:443` | 250 req/m | -| Lavender.Five | `https://dydx-api.lavenderfive.com:443` | | -| AutoStake | `https://dydx-mainnet-lcd.autostake.com:443` | 4 req/s | -| EcoStake | `https://rest-dydx.ecostake.com:443` | | -| PublicNode | `https://dydx-rest.publicnode.com:443` | | -| Enigma | `https://dydx-lcd.enigma-validator.com:443` | | +| Polkachu | `https://dydx-dao-api.polkachu.com:443` | 300 req/m | +| Bware Labs | `https://dydx-mainnet-full-lcd.public.blastapi.io:443` | 20 req/s | +| KingNodes | `https://dydx-ops-rest.kingnodes.com:443` | 250 req/m | +| Lavender.Five | `https://dydx-api.lavenderfive.com:443` | | +| AutoStake | `https://dydx-mainnet-lcd.autostake.com:443` | 4 req/s | +| EcoStake | `https://rest-dydx.ecostake.com:443` | | +| PublicNode | `https://dydx-rest.publicnode.com:443` | | +| Enigma | `https://dydx-lcd.enigma-validator.com:443` | | **gRPC** -| Team | URI | Rate limit | -| ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | -| Polkachu | `http://dydx-dao-grpc-1.polkachu.com:23890`
`http://dydx-dao-grpc-2.polkachu.com:23890`
`http://dydx-dao-grpc-3.polkachu.com:23890`
`http://dydx-dao-grpc-4.polkachu.com:23890`
`http://dydx-dao-grpc-5.polkachu.com:23890` | 300 req/m | -| Bware Labs | `https://dydx-mainnet-full-grpc.public.blastapi.io:443` | 20 req/s | -| KingNodes | `https://dydx-ops-grpc.kingnodes.com:443` | 250 req/m | -| Lavender.Five | `https://dydx-grpc.lavenderfive.com:443` | | -| PublicNode | `https://dydx-grpc.publicnode.com:443` | | + +| Team | URI | Rate limit | +| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | +| Polkachu | `http://dydx-dao-grpc-1.polkachu.com:23890`
`http://dydx-dao-grpc-2.polkachu.com:23890`
`http://dydx-dao-grpc-3.polkachu.com:23890`
`http://dydx-dao-grpc-4.polkachu.com:23890`
`http://dydx-dao-grpc-5.polkachu.com:23890` | 300 req/m | +| Bware Labs | `https://dydx-mainnet-full-grpc.public.blastapi.io:443` | 20 req/s | +| KingNodes | `https://dydx-ops-grpc.kingnodes.com:443` | 250 req/m | +| Lavender.Five | `https://dydx-grpc.lavenderfive.com:443` | | +| PublicNode | `https://dydx-grpc.publicnode.com:443` | | @@ -215,25 +235,28 @@ No Archival nodes For **the deployment by DYDX token holders**: **RPC** -| Team | URI | Rate limit | + +| Team | URI | Rate limit | | ---------- | --------------------------------------------------------- | ---------- | -| Polkachu | `https://dydx-dao-archive-rpc.polkachu.com:443` | 300 req/m | -| Bware Labs | `https://dydx-mainnet-archive-rpc.public.blastapi.io:443` | 20 req/s | -| KingNodes | `https://dydx-ops-archive-rpc.kingnodes.com:443` | 50 req/m | +| Polkachu | `https://dydx-dao-archive-rpc.polkachu.com:443` | 300 req/m | +| Bware Labs | `https://dydx-mainnet-archive-rpc.public.blastapi.io:443` | 20 req/s | +| KingNodes | `https://dydx-ops-archive-rpc.kingnodes.com:443` | 50 req/m | **REST** -| Team | URI | Rate limit | + +| Team | URI | Rate limit | | ---------- | --------------------------------------------------------- | ---------- | -| Polkachu | `https://dydx-dao-archive-api.polkachu.com:443` | 300 req/m | -| Bware Labs | `https://dydx-mainnet-archive-lcd.public.blastapi.io:443` | 20 req/s | -| KingNodes | `https://dydx-ops-archive-rest.kingnodes.com:443` | 50 req/m | +| Polkachu | `https://dydx-dao-archive-api.polkachu.com:443` | 300 req/m | +| Bware Labs | `https://dydx-mainnet-archive-lcd.public.blastapi.io:443` | 20 req/s | +| KingNodes | `https://dydx-ops-archive-rest.kingnodes.com:443` | 50 req/m | **gRPC** -| Team | URI | Rate limit | -| ---------- | ------------------------------------------------------------------------------------------------------------ | ---------- | -| Polkachu | `http://dydx-dao-archive-grpc-1.polkachu.com:23890`
`http://dydx-dao-archive-grpc-2.polkachu.com:23890` | 300 req/m | -| Bware Labs | `https://dydx-mainnet-archive-grpc.public.blastapi.io:443` | 20 req/s | -| KingNodes | `https://dydx-ops-archive-grpc.kingnodes.com:443` | 50 req/m | + +| Team | URI | Rate limit | +| ---------- | ------------------------------------------------------------------------------------------------------------- | ---------- | +| Polkachu | `http://dydx-dao-archive-grpc-1.polkachu.com:23890`
`http://dydx-dao-archive-grpc-2.polkachu.com:23890` | 300 req/m | +| Bware Labs | `https://dydx-mainnet-archive-grpc.public.blastapi.io:443` | 20 req/s | +| KingNodes | `https://dydx-ops-archive-grpc.kingnodes.com:443` | 50 req/m | @@ -242,27 +265,31 @@ For **the deployment by DYDX token holders**: - For **Testnet**: | Name | URI | | -------------------------- | - ----------------------------------------------------------------------------------------------------- - | | Public Testnet Front-end | `https://v4.testnet.dydx.exchange` | | Status Page | - `https://status.v4testnet.dydx.exchange` | | Mintscan | - `https://testnet.mintscan.io/dydx-testnet` | | Keplr | - `https://testnet.keplr.app/chains/dydx-testnet` | | Validator Metrics | - `https://p.datadoghq.com/sb/dc160ddf0-05a98d2dbe2a01d8caa5783eb616f826` | | Discord Channel - (Feedback) | `https://discord.com/channels/724804754382782534/1117897181886677012` | | Google - Form (Feedback) | - `https://docs.google.com/forms/d/e/1FAIpQLSezLsWCKvAYDEb7L-2O4wOON1T56xxro9A2Azvl6IxXHP_15Q/viewform` - | +For **Testnet**: + +| Name | URI | +| -------------------------- | ----------------------------------------------------------------------------------------------------- | +| Public Testnet Front-end | `https://v4.testnet.dydx.exchange` | +| Status Page | `https://status.v4testnet.dydx.exchange` | +| Mintscan | `https://testnet.mintscan.io/dydx-testnet` | +| Keplr | `https://testnet.keplr.app/chains/dydx-testnet` | +| Validator Metrics | `https://p.datadoghq.com/sb/dc160ddf0-05a98d2dbe2a01d8caa5783eb616f826` | +| Discord Channel (Feedback) | `https://discord.com/channels/724804754382782534/1117897181886677012` | +| Google Form (Feedback) | `https://docs.google.com/forms/d/e/1FAIpQLSezLsWCKvAYDEb7L-2O4wOON1T56xxro9A2Azvl6IxXHP_15Q/viewform` | + - For **the deployment by DYDX token holders**: | Name | URI | | --------------------------- | - ------------------------------------------------------------------------------------------------------ - | | dYdX Chain Web Frontend | `https://dydx.trade/` | | Status Page | - `https://status.dydx.trade` | | Mintscan | `https://www.mintscan.io/dydx` | | Keplr | - `https://wallet.keplr.app/chains/dydx` | | Validator Metrics | - `https://p.ap1.datadoghq.com/sb/610e1836-51dd-11ee-a995-da7ad0900009-78607847ff8632d8a96737ed3437f40c` - | | #validators Discord Channel | - `https://discord.com/channels/724804754382782534/1029585380170805379` | | FE Bug Report Form | - `https://www.dydxopsdao.com/feedback` | +For **the deployment by DYDX token holders**: + +| Name | URI | +| --------------------------- | ------------------------------------------------------------------------------------------------------ | +| dYdX Chain Web Frontend | `https://dydx.trade/` | +| Status Page | `https://status.dydx.trade` | +| Mintscan | `https://www.mintscan.io/dydx` | +| Keplr | `https://wallet.keplr.app/chains/dydx` | +| Validator Metrics | `https://p.ap1.datadoghq.com/sb/610e1836-51dd-11ee-a995-da7ad0900009-78607847ff8632d8a96737ed3437f40c` | +| #validators Discord Channel | `https://discord.com/channels/724804754382782534/1029585380170805379` | +| FE Bug Report Form | `https://www.dydxopsdao.com/feedback` | + diff --git a/pages/infrastructure_providers-validators/hardware_requirements.md b/pages/infrastructure_providers-validators/hardware_requirements.md index 4dc287ee..2d18f822 100644 --- a/pages/infrastructure_providers-validators/hardware_requirements.md +++ b/pages/infrastructure_providers-validators/hardware_requirements.md @@ -4,8 +4,8 @@ The minimum recommended specs for running a node is the following: -- 8-core, x86_64 architecture processor +- 16-core, x86_64 architecture processor - 64 GiB RAM - 500 GiB of locally attached SSD storage -For example, an AWS instance like the `r6id.2xlarge`, or equivalent. +For example, an AWS instance like the `r6id.4xlarge`, or equivalent. From 2a65d33f0e6834d4227ac5a8c1f133cf474ff88d Mon Sep 17 00:00:00 2001 From: James Jia Date: Mon, 3 Jun 2024 13:57:04 -0400 Subject: [PATCH 12/18] Add redirects (#217) * redirects * Add redirects --- next.config.js | 56 +++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 55 insertions(+), 1 deletion(-) diff --git a/next.config.js b/next.config.js index 637d85a2..dfe847d7 100644 --- a/next.config.js +++ b/next.config.js @@ -7,4 +7,58 @@ const withNextra = require('nextra')({ }, }) -module.exports = withNextra() +module.exports = withNextra({ + async redirects() { + return [ + // Original top-level + { source: '/security', destination: '/other-security', permanent: true }, + { source: '/terms_of_use_and_privacy_policy.md', destination: '/other-terms_of_use_and_privacy_policy.md', permanent: true }, + { source: '/FAQ', destination: '/user-faqs', permanent: true }, + + // Architecture + { source: '/architecture/architectural_overview', destination: '/concepts-architecture/architectural_overview', permanent: true }, + { source: '/architecture/indexer', destination: '/concepts-architecture/indexer', permanent: true }, + + // Deposits and Withdrawals + { source: '/deposits_and_withdrawals/:slug*', destination: '/api_integration-deposits_and_withdrawals/:slug*', permanent: true }, + + // Developers + { source: '/developers/constants', destination: '/api_integration-constants', permanent: true }, + { source: '/developers/open_source_repositories', destination: '/api_integration-repositories.md', permanent: true }, + + // Developers - Clients + { source: '/developers/clients/:slug*', destination: '/api_integration-clients/:slug*', permanent: true }, + + // Developers - Indexer + { source: '/developers/indexer/:slug*', destination: '/api_integration-indexer/:slug*', permanent: true }, + + // Getting started + { source: '/getting_started/depositing_and_user_journeys', destination: 'introduction-getting_started', permanent: true }, + { source: '/getting_started/margin_calculations', destination: 'concepts-trading/margin', permanent: true }, + { source: '/getting_started/onboarding_faqs', destination: 'introduction-onboarding_faqs', permanent: true }, + { source: '/getting_started/rewards_fees_and_parameters', destination: 'concepts-trading/rewards_fees_and_parameters', permanent: true }, + + // Governance + { source: '/governance/:slug*', destination: '/users-governance/:slug*', permanent: true }, + + // Guides + { source: '/guides/:slug*', destination: '/api_integration-guides/:slug*', permanent: true }, + + // Network + { source: '/network/:slug*', destination: '/infrastructure_providers-network/:slug*', permanent: true }, + + // Operators + { source: '/operators/:slug*', destination: '/infrastructure_providers-operators/:slug*', permanent: true }, + + // Rewards + { source: '/rewards/:slug*', destination: '/users-rewards/:slug*', permanent: true }, + + // Trading + { source: '/trading:slug*', destination: '/api_integration-trading/:slug*', permanent: true }, + + // Validators + { source: '/validators/:slug*', destination: '/infrastructure_providers-validators/:slug*', permanent: true }, + { source: '/validators/upgrades/:slug*', destination: '/infrastructure_providers-validators/upgrades/:slug*', permanent: true }, + ] + }, +}) From 898dd447316f58b9ded32e3e223d6994590d3e92 Mon Sep 17 00:00:00 2001 From: Christopher-Li Date: Wed, 5 Jun 2024 11:09:44 -0400 Subject: [PATCH 13/18] Sync API documentation with v4-chain (#218) --- pages/api_integration-indexer/indexer_api.mdx | 1842 ++++++++++++++--- 1 file changed, 1508 insertions(+), 334 deletions(-) diff --git a/pages/api_integration-indexer/indexer_api.mdx b/pages/api_integration-indexer/indexer_api.mdx index 8cd9080f..f2b11117 100644 --- a/pages/api_integration-indexer/indexer_api.mdx +++ b/pages/api_integration-indexer/indexer_api.mdx @@ -1,3 +1,4 @@ + # Indexer API v1.0.0 > Scroll down for code samples, example requests and responses. Select a language for code samples from the tabs above or the mobile navigation menu. @@ -42,10 +43,10 @@ const headers = { }; // For the deployment by DYDX token holders, use -// baseURL = 'https://indexer.dydx.trade/v4' -const baseURL = 'https://dydx-testnet.imperator.co/v4' +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; -fetch(`${baseURL}/addresses/${address}`, +fetch(`${baseURL}/addresses/{address}`, { method: 'GET', @@ -76,7 +77,7 @@ fetch(`${baseURL}/addresses/${address}`, "subaccounts": [ { "address": "string", - "subaccountNumber": 0, + "subaccountNumber": 0.1, "equity": "string", "freeCollateral": "string", "openPerpetualPositions": { @@ -95,7 +96,8 @@ fetch(`${baseURL}/addresses/${address}`, "netFunding": "string", "unrealizedPnl": "string", "closedAt": null, - "exitPrice": "string" + "exitPrice": "string", + "subaccountNumber": 0.1 }, "property2": { "market": "string", @@ -112,7 +114,8 @@ fetch(`${baseURL}/addresses/${address}`, "netFunding": "string", "unrealizedPnl": "string", "closedAt": null, - "exitPrice": "string" + "exitPrice": "string", + "subaccountNumber": 0.1 } }, "assetPositions": { @@ -120,16 +123,19 @@ fetch(`${baseURL}/addresses/${address}`, "symbol": "string", "side": "LONG", "size": "string", - "assetId": "string" + "assetId": "string", + "subaccountNumber": 0.1 }, "property2": { "symbol": "string", "side": "LONG", "size": "string", - "assetId": "string" + "assetId": "string", + "subaccountNumber": 0.1 } }, - "marginEnabled": true + "marginEnabled": true, + "updatedAtHeight": "string" } ], "totalTradingRewards": "string" @@ -175,10 +181,10 @@ const headers = { }; // For the deployment by DYDX token holders, use -// baseURL = 'https://indexer.dydx.trade/v4' -const baseURL = 'https://dydx-testnet.imperator.co/v4' +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; -fetch(`${baseURL}/addresses/${address}/subaccountNumber/${subaccountNumber}`, +fetch(`${baseURL}/addresses/{address}/subaccountNumber/{subaccountNumber}`, { method: 'GET', @@ -208,7 +214,7 @@ fetch(`${baseURL}/addresses/${address}/subaccountNumber/${subaccountNumber}`, ```json { "address": "string", - "subaccountNumber": 0, + "subaccountNumber": 0.1, "equity": "string", "freeCollateral": "string", "openPerpetualPositions": { @@ -227,7 +233,8 @@ fetch(`${baseURL}/addresses/${address}/subaccountNumber/${subaccountNumber}`, "netFunding": "string", "unrealizedPnl": "string", "closedAt": "string", - "exitPrice": "string" + "exitPrice": "string", + "subaccountNumber": 0.1 }, "property2": { "market": "string", @@ -244,7 +251,8 @@ fetch(`${baseURL}/addresses/${address}/subaccountNumber/${subaccountNumber}`, "netFunding": "string", "unrealizedPnl": "string", "closedAt": "string", - "exitPrice": "string" + "exitPrice": "string", + "subaccountNumber": 0.1 } }, "assetPositions": { @@ -252,16 +260,19 @@ fetch(`${baseURL}/addresses/${address}/subaccountNumber/${subaccountNumber}`, "symbol": "string", "side": "LONG", "size": "string", - "assetId": "string" + "assetId": "string", + "subaccountNumber": 0.1 }, "property2": { "symbol": "string", "side": "LONG", "size": "string", - "assetId": "string" + "assetId": "string", + "subaccountNumber": 0.1 } }, - "marginEnabled": true + "marginEnabled": true, + "updatedAtHeight": "string" } ``` @@ -275,9 +286,9 @@ fetch(`${baseURL}/addresses/${address}/subaccountNumber/${subaccountNumber}`, This operation does not require authentication -## GetAssetPositions +## GetParentSubaccount - + > Code samples @@ -291,9 +302,7 @@ headers = { # baseURL = 'https://indexer.dydx.trade/v4' baseURL = 'https://dydx-testnet.imperator.co/v4' -r = requests.get(f'{baseURL}/assetPositions', params={ - 'address': 'string', 'subaccountNumber': '0' -}, headers = headers) +r = requests.get(f'{baseURL}/addresses/{address}/parentSubaccountNumber/{parentSubaccountNumber}', headers = headers) print(r.json()) @@ -306,10 +315,10 @@ const headers = { }; // For the deployment by DYDX token holders, use -// baseURL = 'https://indexer.dydx.trade/v4' -const baseURL = 'https://dydx-testnet.imperator.co/v4' +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; -fetch(`${baseURL}/assetPositions?address=${address}&subaccountNumber=${subaccountNumber}`, +fetch(`${baseURL}/addresses/{address}/parentSubaccountNumber/{parentSubaccountNumber}`, { method: 'GET', @@ -323,14 +332,14 @@ fetch(`${baseURL}/assetPositions?address=${address}&subaccountNumber=${subaccoun ``` -`GET /assetPositions` +`GET /addresses/{address}/parentSubaccountNumber/{parentSubaccountNumber}` ### Parameters |Name|In|Type|Required|Description| |---|---|---|---|---| -|address|query|string|true|none| -|subaccountNumber|query|number(double)|true|none| +|address|path|string|true|none| +|parentSubaccountNumber|path|number(double)|true|none| > Example responses @@ -338,12 +347,72 @@ fetch(`${baseURL}/assetPositions?address=${address}&subaccountNumber=${subaccoun ```json { - "positions": [ + "address": "string", + "parentSubaccountNumber": 0.1, + "equity": "string", + "freeCollateral": "string", + "childSubaccounts": [ { - "symbol": "string", - "side": "LONG", - "size": "string", - "assetId": "string" + "address": "string", + "subaccountNumber": 0.1, + "equity": "string", + "freeCollateral": "string", + "openPerpetualPositions": { + "property1": { + "market": "string", + "status": "OPEN", + "side": "LONG", + "size": "string", + "maxSize": "string", + "entryPrice": "string", + "realizedPnl": "string", + "createdAt": "string", + "createdAtHeight": "string", + "sumOpen": "string", + "sumClose": "string", + "netFunding": "string", + "unrealizedPnl": "string", + "closedAt": null, + "exitPrice": "string", + "subaccountNumber": 0.1 + }, + "property2": { + "market": "string", + "status": "OPEN", + "side": "LONG", + "size": "string", + "maxSize": "string", + "entryPrice": "string", + "realizedPnl": "string", + "createdAt": "string", + "createdAtHeight": "string", + "sumOpen": "string", + "sumClose": "string", + "netFunding": "string", + "unrealizedPnl": "string", + "closedAt": null, + "exitPrice": "string", + "subaccountNumber": 0.1 + } + }, + "assetPositions": { + "property1": { + "symbol": "string", + "side": "LONG", + "size": "string", + "assetId": "string", + "subaccountNumber": 0.1 + }, + "property2": { + "symbol": "string", + "side": "LONG", + "size": "string", + "assetId": "string", + "subaccountNumber": 0.1 + } + }, + "marginEnabled": true, + "updatedAtHeight": "string" } ] } @@ -353,15 +422,15 @@ fetch(`${baseURL}/assetPositions?address=${address}&subaccountNumber=${subaccoun |Status|Meaning|Description|Schema| |---|---|---|---| -|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[AssetPositionResponse](#schemaassetpositionresponse)| +|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[ParentSubaccountResponse](#schemaparentsubaccountresponse)| -## GetCandles +## GetAssetPositions - + > Code samples @@ -375,8 +444,8 @@ headers = { # baseURL = 'https://indexer.dydx.trade/v4' baseURL = 'https://dydx-testnet.imperator.co/v4' -r = requests.get(f'{baseURL}/candles/perpetualMarkets/{ticker}', params={ - 'resolution': '1MIN', 'limit': '0' +r = requests.get(f'{baseURL}/assetPositions', params={ + 'address': 'string', 'subaccountNumber': '0.1' }, headers = headers) print(r.json()) @@ -390,10 +459,10 @@ const headers = { }; // For the deployment by DYDX token holders, use -// baseURL = 'https://indexer.dydx.trade/v4' -const baseURL = 'https://dydx-testnet.imperator.co/v4' +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; -fetch(`${baseURL}/candles/perpetualMarkets/{ticker}?resolution=1MIN&limit=0`, +fetch(`${baseURL}/assetPositions?address=string&subaccountNumber=0.1`, { method: 'GET', @@ -407,29 +476,14 @@ fetch(`${baseURL}/candles/perpetualMarkets/{ticker}?resolution=1MIN&limit=0`, ``` -`GET /candles/perpetualMarkets/{ticker}` +`GET /assetPositions` ### Parameters |Name|In|Type|Required|Description| |---|---|---|---|---| -|ticker|path|string|true|none| -|resolution|query|[CandleResolution](#schemacandleresolution)|true|none| -|limit|query|number(double)|true|none| -|fromISO|query|string|false|none| -|toISO|query|string|false|none| - -#### Enumerated Values - -|Parameter|Value| -|---|---| -|resolution|1MIN| -|resolution|5MINS| -|resolution|15MINS| -|resolution|30MINS| -|resolution|1HOUR| -|resolution|4HOURS| -|resolution|1DAY| +|address|query|string|true|none| +|subaccountNumber|query|number(double)|true|none| > Example responses @@ -437,20 +491,13 @@ fetch(`${baseURL}/candles/perpetualMarkets/{ticker}?resolution=1MIN&limit=0`, ```json { - "candles": [ + "positions": [ { - "startedAt": "string", - "ticker": "string", - "resolution": "1MIN", - "low": "string", - "high": "string", - "open": "string", - "close": "string", - "baseTokenVolume": "string", - "usdVolume": "string", - "trades": 0, - "startingOpenInterest": "string", - "id": "string" + "symbol": "string", + "side": "LONG", + "size": "string", + "assetId": "string", + "subaccountNumber": 0.1 } ] } @@ -460,15 +507,15 @@ fetch(`${baseURL}/candles/perpetualMarkets/{ticker}?resolution=1MIN&limit=0`, |Status|Meaning|Description|Schema| |---|---|---|---| -|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[CandleResponse](#schemacandleresponse)| +|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[AssetPositionResponse](#schemaassetpositionresponse)| -## Screen +## GetAssetPositionsForParentSubaccount - + > Code samples @@ -482,8 +529,8 @@ headers = { # baseURL = 'https://indexer.dydx.trade/v4' baseURL = 'https://dydx-testnet.imperator.co/v4' -r = requests.get(f'{baseURL}/screen', params={ - 'address': 'string' +r = requests.get(f'{baseURL}/assetPositions/parentSubaccountNumber', params={ + 'address': 'string', 'parentSubaccountNumber': '0.1' }, headers = headers) print(r.json()) @@ -497,10 +544,10 @@ const headers = { }; // For the deployment by DYDX token holders, use -// baseURL = 'https://indexer.dydx.trade/v4' -const baseURL = 'https://dydx-testnet.imperator.co/v4' +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; -fetch(`${baseURL}/screen?address=string`, +fetch(`${baseURL}/assetPositions/parentSubaccountNumber?address=string&parentSubaccountNumber=0.1`, { method: 'GET', @@ -514,13 +561,14 @@ fetch(`${baseURL}/screen?address=string`, ``` -`GET /screen` +`GET /assetPositions/parentSubaccountNumber` ### Parameters |Name|In|Type|Required|Description| |---|---|---|---|---| |address|query|string|true|none| +|parentSubaccountNumber|query|number(double)|true|none| > Example responses @@ -528,8 +576,15 @@ fetch(`${baseURL}/screen?address=string`, ```json { - "restricted": true, - "reason": "string" + "positions": [ + { + "symbol": "string", + "side": "LONG", + "size": "string", + "assetId": "string", + "subaccountNumber": 0.1 + } + ] } ``` @@ -537,15 +592,15 @@ fetch(`${baseURL}/screen?address=string`, |Status|Meaning|Description|Schema| |---|---|---|---| -|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[ComplianceResponse](#schemacomplianceresponse)| +|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[AssetPositionResponse](#schemaassetpositionresponse)| -## GetFills +## GetCandles - + > Code samples @@ -559,8 +614,8 @@ headers = { # baseURL = 'https://indexer.dydx.trade/v4' baseURL = 'https://dydx-testnet.imperator.co/v4' -r = requests.get(f'{baseURL}/fills', params={ - 'address': 'string', 'subaccountNumber': '0', 'market': 'string', 'marketType': 'PERPETUAL', 'limit': '0' +r = requests.get(f'{baseURL}/candles/perpetualMarkets/{ticker}', params={ + 'resolution': '1MIN' }, headers = headers) print(r.json()) @@ -574,10 +629,10 @@ const headers = { }; // For the deployment by DYDX token holders, use -// baseURL = 'https://indexer.dydx.trade/v4' -const baseURL = 'https://dydx-testnet.imperator.co/v4' +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; -fetch(`${baseURL}/fills?address=string&subaccountNumber=0&market=string&marketType=PERPETUAL&limit=0`, +fetch(`${baseURL}/candles/perpetualMarkets/{ticker}?resolution=1MIN`, { method: 'GET', @@ -591,26 +646,29 @@ fetch(`${baseURL}/fills?address=string&subaccountNumber=0&market=string&marketTy ``` -`GET /fills` +`GET /candles/perpetualMarkets/{ticker}` ### Parameters |Name|In|Type|Required|Description| |---|---|---|---|---| -|address|query|string|true|none| -|subaccountNumber|query|number(double)|true|none| -|market|query|string|false|none| -|marketType|query|[MarketType](#schemamarkettype)|false|none| +|ticker|path|string|true|none| +|resolution|query|[CandleResolution](#schemacandleresolution)|true|none| |limit|query|number(double)|false|none| -|createdBeforeOrAtHeight|query|number(double)|false|none| -|createdBeforeOrAt|query|[IsoString](#schemaisostring)|false|none| +|fromISO|query|string|false|none| +|toISO|query|string|false|none| #### Enumerated Values |Parameter|Value| |---|---| -|marketType|PERPETUAL| -|marketType|SPOT| +|resolution|1MIN| +|resolution|5MINS| +|resolution|15MINS| +|resolution|30MINS| +|resolution|1HOUR| +|resolution|4HOURS| +|resolution|1DAY| > Example responses @@ -618,21 +676,20 @@ fetch(`${baseURL}/fills?address=string&subaccountNumber=0&market=string&marketTy ```json { - "fills": [ + "candles": [ { - "id": "string", - "side": "BUY", - "liquidity": "TAKER", - "type": "LIMIT", - "market": "string", - "marketType": "PERPETUAL", - "price": "string", - "size": "string", - "fee": "string", - "createdAt": "string", - "createdAtHeight": "string", - "orderId": "string", - "clientMetadata": "string" + "startedAt": "string", + "ticker": "string", + "resolution": "1MIN", + "low": "string", + "high": "string", + "open": "string", + "close": "string", + "baseTokenVolume": "string", + "usdVolume": "string", + "trades": 0.1, + "startingOpenInterest": "string", + "id": "string" } ] } @@ -642,15 +699,15 @@ fetch(`${baseURL}/fills?address=string&subaccountNumber=0&market=string&marketTy |Status|Meaning|Description|Schema| |---|---|---|---| -|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[FillResponse](#schemafillresponse)| +|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[CandleResponse](#schemacandleresponse)| -## GetHeight +## Screen - + > Code samples @@ -664,7 +721,7 @@ headers = { # baseURL = 'https://indexer.dydx.trade/v4' baseURL = 'https://dydx-testnet.imperator.co/v4' -r = requests.get(f'{baseURL}/height', headers = headers) +r = requests.get(f'{baseURL}/compliance/screen/{address}', headers = headers) print(r.json()) @@ -677,10 +734,10 @@ const headers = { }; // For the deployment by DYDX token holders, use -// baseURL = 'https://indexer.dydx.trade/v4' -const baseURL = 'https://dydx-testnet.imperator.co/v4' +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; -fetch(`${baseURL}/height`, +fetch(`${baseURL}/compliance/screen/{address}`, { method: 'GET', @@ -694,7 +751,13 @@ fetch(`${baseURL}/height`, ``` -`GET /height` +`GET /compliance/screen/{address}` + +### Parameters + +|Name|In|Type|Required|Description| +|---|---|---|---|---| +|address|path|string|true|none| > Example responses @@ -702,8 +765,9 @@ fetch(`${baseURL}/height`, ```json { - "height": "string", - "time": "string" + "status": "COMPLIANT", + "reason": "MANUAL", + "updatedAt": "string" } ``` @@ -711,15 +775,15 @@ fetch(`${baseURL}/height`, |Status|Meaning|Description|Schema| |---|---|---|---| -|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[HeightResponse](#schemaheightresponse)| +|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[ComplianceV2Response](#schemacompliancev2response)| -## GetTradingRewards +## GetFills - + > Code samples @@ -733,8 +797,8 @@ headers = { # baseURL = 'https://indexer.dydx.trade/v4' baseURL = 'https://dydx-testnet.imperator.co/v4' -r = requests.get(f'{baseURL}/historicalBlockTradingRewards/{address}', params={ - 'limit': '0' +r = requests.get(f'{baseURL}/fills', params={ + 'address': 'string', 'subaccountNumber': '0.1' }, headers = headers) print(r.json()) @@ -748,10 +812,10 @@ const headers = { }; // For the deployment by DYDX token holders, use -// baseURL = 'https://indexer.dydx.trade/v4' -const baseURL = 'https://dydx-testnet.imperator.co/v4' +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; -fetch(`${baseURL}/historicalBlockTradingRewards/{address}?limit=0`, +fetch(`${baseURL}/fills?address=string&subaccountNumber=0.1`, { method: 'GET', @@ -765,16 +829,27 @@ fetch(`${baseURL}/historicalBlockTradingRewards/{address}?limit=0`, ``` -`GET /historicalBlockTradingRewards/{address}` +`GET /fills` ### Parameters |Name|In|Type|Required|Description| |---|---|---|---|---| -|address|path|string|true|none| -|limit|query|number(double)|true|none| -|startingBeforeOrAt|query|[IsoString](#schemaisostring)|false|none| -|startingBeforeOrAtHeight|query|string|false|none| +|address|query|string|true|none| +|subaccountNumber|query|number(double)|true|none| +|market|query|string|false|none| +|marketType|query|[MarketType](#schemamarkettype)|false|none| +|limit|query|number(double)|false|none| +|createdBeforeOrAtHeight|query|number(double)|false|none| +|createdBeforeOrAt|query|[IsoString](#schemaisostring)|false|none| +|page|query|number(double)|false|none| + +#### Enumerated Values + +|Parameter|Value| +|---|---| +|marketType|PERPETUAL| +|marketType|SPOT| > Example responses @@ -782,11 +857,25 @@ fetch(`${baseURL}/historicalBlockTradingRewards/{address}?limit=0`, ```json { - "rewards": [ + "pageSize": 0.1, + "totalResults": 0.1, + "offset": 0.1, + "fills": [ { - "tradingReward": "string", + "id": "string", + "side": "BUY", + "liquidity": "TAKER", + "type": "LIMIT", + "market": "string", + "marketType": "PERPETUAL", + "price": "string", + "size": "string", + "fee": "string", "createdAt": "string", - "createdAtHeight": "string" + "createdAtHeight": "string", + "orderId": "string", + "clientMetadata": "string", + "subaccountNumber": 0.1 } ] } @@ -796,15 +885,15 @@ fetch(`${baseURL}/historicalBlockTradingRewards/{address}?limit=0`, |Status|Meaning|Description|Schema| |---|---|---|---| -|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[HistoricalBlockTradingRewardsResponse](#schemahistoricalblocktradingrewardsresponse)| +|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[FillResponse](#schemafillresponse)| -## GetHistoricalFunding +## GetFillsForParentSubaccount - + > Code samples @@ -818,8 +907,8 @@ headers = { # baseURL = 'https://indexer.dydx.trade/v4' baseURL = 'https://dydx-testnet.imperator.co/v4' -r = requests.get(f'{baseURL}/historicalFunding/{ticker}', params={ - 'limit': '0' +r = requests.get(f'{baseURL}/fills/parentSubaccount', params={ + 'address': 'string', 'parentSubaccountNumber': '0.1' }, headers = headers) print(r.json()) @@ -833,10 +922,10 @@ const headers = { }; // For the deployment by DYDX token holders, use -// baseURL = 'https://indexer.dydx.trade/v4' -const baseURL = 'https://dydx-testnet.imperator.co/v4' +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; -fetch(`${baseURL}/historicalFunding/{ticker}?limit=0`, +fetch(`${baseURL}/fills/parentSubaccount?address=string&parentSubaccountNumber=0.1`, { method: 'GET', @@ -850,16 +939,27 @@ fetch(`${baseURL}/historicalFunding/{ticker}?limit=0`, ``` -`GET /historicalFunding/{ticker}` +`GET /fills/parentSubaccount` ### Parameters |Name|In|Type|Required|Description| |---|---|---|---|---| -|ticker|path|string|true|none| -|limit|query|number(double)|true|none| -|effectiveBeforeOrAtHeight|query|number(double)|false|none| -|effectiveBeforeOrAt|query|[IsoString](#schemaisostring)|false|none| +|address|query|string|true|none| +|parentSubaccountNumber|query|number(double)|true|none| +|market|query|string|false|none| +|marketType|query|[MarketType](#schemamarkettype)|false|none| +|limit|query|number(double)|false|none| +|createdBeforeOrAtHeight|query|number(double)|false|none| +|createdBeforeOrAt|query|[IsoString](#schemaisostring)|false|none| +|page|query|number(double)|false|none| + +#### Enumerated Values + +|Parameter|Value| +|---|---| +|marketType|PERPETUAL| +|marketType|SPOT| > Example responses @@ -867,9 +967,258 @@ fetch(`${baseURL}/historicalFunding/{ticker}?limit=0`, ```json { - "historicalFunding": [ + "pageSize": 0.1, + "totalResults": 0.1, + "offset": 0.1, + "fills": [ { - "ticker": "string", + "id": "string", + "side": "BUY", + "liquidity": "TAKER", + "type": "LIMIT", + "market": "string", + "marketType": "PERPETUAL", + "price": "string", + "size": "string", + "fee": "string", + "createdAt": "string", + "createdAtHeight": "string", + "orderId": "string", + "clientMetadata": "string", + "subaccountNumber": 0.1 + } + ] +} +``` + +### Responses + +|Status|Meaning|Description|Schema| +|---|---|---|---| +|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[FillResponse](#schemafillresponse)| + + + +## GetHeight + + + +> Code samples + +```python +import requests +headers = { + 'Accept': 'application/json' +} + +# For the deployment by DYDX token holders, use +# baseURL = 'https://indexer.dydx.trade/v4' +baseURL = 'https://dydx-testnet.imperator.co/v4' + +r = requests.get(f'{baseURL}/height', headers = headers) + +print(r.json()) + +``` + +```javascript + +const headers = { + 'Accept':'application/json' +}; + +// For the deployment by DYDX token holders, use +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; + +fetch(`${baseURL}/height`, +{ + method: 'GET', + + headers: headers +}) +.then(function(res) { + return res.json(); +}).then(function(body) { + console.log(body); +}); + +``` + +`GET /height` + +> Example responses + +> 200 Response + +```json +{ + "height": "string", + "time": "string" +} +``` + +### Responses + +|Status|Meaning|Description|Schema| +|---|---|---|---| +|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[HeightResponse](#schemaheightresponse)| + + + +## GetTradingRewards + + + +> Code samples + +```python +import requests +headers = { + 'Accept': 'application/json' +} + +# For the deployment by DYDX token holders, use +# baseURL = 'https://indexer.dydx.trade/v4' +baseURL = 'https://dydx-testnet.imperator.co/v4' + +r = requests.get(f'{baseURL}/historicalBlockTradingRewards/{address}', headers = headers) + +print(r.json()) + +``` + +```javascript + +const headers = { + 'Accept':'application/json' +}; + +// For the deployment by DYDX token holders, use +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; + +fetch(`${baseURL}/historicalBlockTradingRewards/{address}`, +{ + method: 'GET', + + headers: headers +}) +.then(function(res) { + return res.json(); +}).then(function(body) { + console.log(body); +}); + +``` + +`GET /historicalBlockTradingRewards/{address}` + +### Parameters + +|Name|In|Type|Required|Description| +|---|---|---|---|---| +|address|path|string|true|none| +|limit|query|number(double)|false|none| +|startingBeforeOrAt|query|[IsoString](#schemaisostring)|false|none| +|startingBeforeOrAtHeight|query|string|false|none| + +> Example responses + +> 200 Response + +```json +{ + "rewards": [ + { + "tradingReward": "string", + "createdAt": "string", + "createdAtHeight": "string" + } + ] +} +``` + +### Responses + +|Status|Meaning|Description|Schema| +|---|---|---|---| +|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[HistoricalBlockTradingRewardsResponse](#schemahistoricalblocktradingrewardsresponse)| + + + +## GetHistoricalFunding + + + +> Code samples + +```python +import requests +headers = { + 'Accept': 'application/json' +} + +# For the deployment by DYDX token holders, use +# baseURL = 'https://indexer.dydx.trade/v4' +baseURL = 'https://dydx-testnet.imperator.co/v4' + +r = requests.get(f'{baseURL}/historicalFunding/{ticker}', headers = headers) + +print(r.json()) + +``` + +```javascript + +const headers = { + 'Accept':'application/json' +}; + +// For the deployment by DYDX token holders, use +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; + +fetch(`${baseURL}/historicalFunding/{ticker}`, +{ + method: 'GET', + + headers: headers +}) +.then(function(res) { + return res.json(); +}).then(function(body) { + console.log(body); +}); + +``` + +`GET /historicalFunding/{ticker}` + +### Parameters + +|Name|In|Type|Required|Description| +|---|---|---|---|---| +|ticker|path|string|true|none| +|limit|query|number(double)|false|none| +|effectiveBeforeOrAtHeight|query|number(double)|false|none| +|effectiveBeforeOrAt|query|[IsoString](#schemaisostring)|false|none| + +> Example responses + +> 200 Response + +```json +{ + "historicalFunding": [ + { + "ticker": "string", "rate": "string", "price": "string", "effectiveAt": "string", @@ -906,7 +1255,7 @@ headers = { baseURL = 'https://dydx-testnet.imperator.co/v4' r = requests.get(f'{baseURL}/historical-pnl', params={ - 'address': 'string', 'subaccountNumber': '0', 'limit': '0' + 'address': 'string', 'subaccountNumber': '0.1' }, headers = headers) print(r.json()) @@ -920,10 +1269,10 @@ const headers = { }; // For the deployment by DYDX token holders, use -// baseURL = 'https://indexer.dydx.trade/v4' -const baseURL = 'https://dydx-testnet.imperator.co/v4' +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; -fetch(`${baseURL}/historical-pnl?address=string&subaccountNumber=0&limit=0`, +fetch(`${baseURL}/historical-pnl?address=string&subaccountNumber=0.1`, { method: 'GET', @@ -945,11 +1294,109 @@ fetch(`${baseURL}/historical-pnl?address=string&subaccountNumber=0&limit=0`, |---|---|---|---|---| |address|query|string|true|none| |subaccountNumber|query|number(double)|true|none| -|limit|query|number(double)|true|none| +|limit|query|number(double)|false|none| +|createdBeforeOrAtHeight|query|number(double)|false|none| +|createdBeforeOrAt|query|[IsoString](#schemaisostring)|false|none| +|createdOnOrAfterHeight|query|number(double)|false|none| +|createdOnOrAfter|query|[IsoString](#schemaisostring)|false|none| +|page|query|number(double)|false|none| + +> Example responses + +> 200 Response + +```json +{ + "pageSize": 0.1, + "totalResults": 0.1, + "offset": 0.1, + "historicalPnl": [ + { + "id": "string", + "subaccountId": "string", + "equity": "string", + "totalPnl": "string", + "netTransfers": "string", + "createdAt": "string", + "blockHeight": "string", + "blockTime": "string" + } + ] +} +``` + +### Responses + +|Status|Meaning|Description|Schema| +|---|---|---|---| +|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[HistoricalPnlResponse](#schemahistoricalpnlresponse)| + + + +## GetHistoricalPnlForParentSubaccount + + + +> Code samples + +```python +import requests +headers = { + 'Accept': 'application/json' +} + +# For the deployment by DYDX token holders, use +# baseURL = 'https://indexer.dydx.trade/v4' +baseURL = 'https://dydx-testnet.imperator.co/v4' + +r = requests.get(f'{baseURL}/historical-pnl/parentSubaccount', params={ + 'address': 'string', 'parentSubaccountNumber': '0.1' +}, headers = headers) + +print(r.json()) + +``` + +```javascript + +const headers = { + 'Accept':'application/json' +}; + +// For the deployment by DYDX token holders, use +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; + +fetch(`${baseURL}/historical-pnl/parentSubaccount?address=string&parentSubaccountNumber=0.1`, +{ + method: 'GET', + + headers: headers +}) +.then(function(res) { + return res.json(); +}).then(function(body) { + console.log(body); +}); + +``` + +`GET /historical-pnl/parentSubaccount` + +### Parameters + +|Name|In|Type|Required|Description| +|---|---|---|---|---| +|address|query|string|true|none| +|parentSubaccountNumber|query|number(double)|true|none| +|limit|query|number(double)|false|none| |createdBeforeOrAtHeight|query|number(double)|false|none| |createdBeforeOrAt|query|[IsoString](#schemaisostring)|false|none| |createdOnOrAfterHeight|query|number(double)|false|none| |createdOnOrAfter|query|[IsoString](#schemaisostring)|false|none| +|page|query|number(double)|false|none| > Example responses @@ -957,6 +1404,9 @@ fetch(`${baseURL}/historical-pnl?address=string&subaccountNumber=0&limit=0`, ```json { + "pageSize": 0.1, + "totalResults": 0.1, + "offset": 0.1, "historicalPnl": [ { "id": "string", @@ -999,7 +1449,7 @@ headers = { baseURL = 'https://dydx-testnet.imperator.co/v4' r = requests.get(f'{baseURL}/historicalTradingRewardAggregations/{address}', params={ - 'period': 'DAILY', 'limit': '0' + 'period': 'DAILY' }, headers = headers) print(r.json()) @@ -1013,10 +1463,10 @@ const headers = { }; // For the deployment by DYDX token holders, use -// baseURL = 'https://indexer.dydx.trade/v4' -const baseURL = 'https://dydx-testnet.imperator.co/v4' +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; -fetch(`${baseURL}/historicalTradingRewardAggregations/{address}?period=DAILY&limit=0`, +fetch(`${baseURL}/historicalTradingRewardAggregations/{address}?period=DAILY`, { method: 'GET', @@ -1038,7 +1488,7 @@ fetch(`${baseURL}/historicalTradingRewardAggregations/{address}?period=DAILY&lim |---|---|---|---|---| |address|path|string|true|none| |period|query|[TradingRewardAggregationPeriod](#schematradingrewardaggregationperiod)|true|none| -|limit|query|number(double)|true|none| +|limit|query|number(double)|false|none| |startingBeforeOrAt|query|[IsoString](#schemaisostring)|false|none| |startingBeforeOrAtHeight|query|string|false|none| @@ -1108,8 +1558,8 @@ const headers = { }; // For the deployment by DYDX token holders, use -// baseURL = 'https://indexer.dydx.trade/v4' -const baseURL = 'https://dydx-testnet.imperator.co/v4' +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; fetch(`${baseURL}/orderbooks/perpetualMarket/{ticker}`, { @@ -1123,50 +1573,244 @@ fetch(`${baseURL}/orderbooks/perpetualMarket/{ticker}`, console.log(body); }); -``` +``` + +`GET /orderbooks/perpetualMarket/{ticker}` + +### Parameters + +|Name|In|Type|Required|Description| +|---|---|---|---|---| +|ticker|path|string|true|none| + +> Example responses + +> 200 Response + +```json +{ + "bids": [ + { + "price": "string", + "size": "string" + } + ], + "asks": [ + { + "price": "string", + "size": "string" + } + ] +} +``` + +### Responses + +|Status|Meaning|Description|Schema| +|---|---|---|---| +|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[OrderbookResponseObject](#schemaorderbookresponseobject)| + + + +## ListOrders + + + +> Code samples + +```python +import requests +headers = { + 'Accept': 'application/json' +} + +# For the deployment by DYDX token holders, use +# baseURL = 'https://indexer.dydx.trade/v4' +baseURL = 'https://dydx-testnet.imperator.co/v4' + +r = requests.get(f'{baseURL}/orders', params={ + 'address': 'string', 'subaccountNumber': '0.1' +}, headers = headers) + +print(r.json()) + +``` + +```javascript + +const headers = { + 'Accept':'application/json' +}; + +// For the deployment by DYDX token holders, use +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; + +fetch(`${baseURL}/orders?address=string&subaccountNumber=0.1`, +{ + method: 'GET', + + headers: headers +}) +.then(function(res) { + return res.json(); +}).then(function(body) { + console.log(body); +}); + +``` + +`GET /orders` + +### Parameters + +|Name|In|Type|Required|Description| +|---|---|---|---|---| +|address|query|string|true|none| +|subaccountNumber|query|number(double)|true|none| +|limit|query|number(double)|false|none| +|ticker|query|string|false|none| +|side|query|[OrderSide](#schemaorderside)|false|none| +|type|query|[OrderType](#schemaordertype)|false|none| +|status|query|array[any]|false|none| +|goodTilBlockBeforeOrAt|query|number(double)|false|none| +|goodTilBlockTimeBeforeOrAt|query|[IsoString](#schemaisostring)|false|none| +|returnLatestOrders|query|boolean|false|none| + +#### Enumerated Values + +|Parameter|Value| +|---|---| +|side|BUY| +|side|SELL| +|type|LIMIT| +|type|MARKET| +|type|STOP_LIMIT| +|type|STOP_MARKET| +|type|TRAILING_STOP| +|type|TAKE_PROFIT| +|type|TAKE_PROFIT_MARKET| + +> Example responses + +> 200 Response + +```json +[ + { + "id": "string", + "subaccountId": "string", + "clientId": "string", + "clobPairId": "string", + "side": "BUY", + "size": "string", + "totalFilled": "string", + "price": "string", + "type": "LIMIT", + "reduceOnly": true, + "orderFlags": "string", + "goodTilBlock": "string", + "goodTilBlockTime": "string", + "createdAtHeight": "string", + "clientMetadata": "string", + "triggerPrice": "string", + "timeInForce": "GTT", + "status": "OPEN", + "postOnly": true, + "ticker": "string", + "updatedAt": "string", + "updatedAtHeight": "string", + "subaccountNumber": 0.1 + } +] +``` + +### Responses + +|Status|Meaning|Description|Schema| +|---|---|---|---| +|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|Inline| + +### Response Schema + +Status Code **200** + +|Name|Type|Required|Restrictions|Description| +|---|---|---|---|---| +|*anonymous*|[[OrderResponseObject](#schemaorderresponseobject)]|false|none|none| +|» id|string|true|none|none| +|» subaccountId|string|true|none|none| +|» clientId|string|true|none|none| +|» clobPairId|string|true|none|none| +|» side|[OrderSide](#schemaorderside)|true|none|none| +|» size|string|true|none|none| +|» totalFilled|string|true|none|none| +|» price|string|true|none|none| +|» type|[OrderType](#schemaordertype)|true|none|none| +|» reduceOnly|boolean|true|none|none| +|» orderFlags|string|true|none|none| +|» goodTilBlock|string|false|none|none| +|» goodTilBlockTime|string|false|none|none| +|» createdAtHeight|string|false|none|none| +|» clientMetadata|string|true|none|none| +|» triggerPrice|string|false|none|none| +|» timeInForce|[APITimeInForce](#schemaapitimeinforce)|true|none|none| +|» status|any|true|none|none| + +*anyOf* -`GET /orderbooks/perpetualMarket/{ticker}` +|Name|Type|Required|Restrictions|Description| +|---|---|---|---|---| +|»» *anonymous*|[OrderStatus](#schemaorderstatus)|false|none|none| -### Parameters +*or* -|Name|In|Type|Required|Description| +|Name|Type|Required|Restrictions|Description| |---|---|---|---|---| -|ticker|path|string|true|none| - -> Example responses +|»» *anonymous*|[BestEffortOpenedStatus](#schemabesteffortopenedstatus)|false|none|none| -> 200 Response +*continued* -```json -{ - "bids": [ - { - "price": "string", - "size": "string" - } - ], - "asks": [ - { - "price": "string", - "size": "string" - } - ] -} -``` +|Name|Type|Required|Restrictions|Description| +|---|---|---|---|---| +|» postOnly|boolean|true|none|none| +|» ticker|string|true|none|none| +|» updatedAt|[IsoString](#schemaisostring)|false|none|none| +|» updatedAtHeight|string|false|none|none| +|» subaccountNumber|number(double)|true|none|none| -### Responses +#### Enumerated Values -|Status|Meaning|Description|Schema| -|---|---|---|---| -|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[OrderbookResponseObject](#schemaorderbookresponseobject)| +|Property|Value| +|---|---| +|side|BUY| +|side|SELL| +|type|LIMIT| +|type|MARKET| +|type|STOP_LIMIT| +|type|STOP_MARKET| +|type|TRAILING_STOP| +|type|TAKE_PROFIT| +|type|TAKE_PROFIT_MARKET| +|timeInForce|GTT| +|timeInForce|FOK| +|timeInForce|IOC| +|*anonymous*|OPEN| +|*anonymous*|FILLED| +|*anonymous*|CANCELED| +|*anonymous*|BEST_EFFORT_CANCELED| +|*anonymous*|UNTRIGGERED| +|*anonymous*|BEST_EFFORT_OPENED| -## ListOrders +## ListOrdersForParentSubaccount - + > Code samples @@ -1180,8 +1824,8 @@ headers = { # baseURL = 'https://indexer.dydx.trade/v4' baseURL = 'https://dydx-testnet.imperator.co/v4' -r = requests.get(f'{baseURL}/orders', params={ - 'address': 'string', 'subaccountNumber': '0', 'limit': '0' +r = requests.get(f'{baseURL}/orders/parentSubaccountNumber', params={ + 'address': 'string', 'parentSubaccountNumber': '0.1' }, headers = headers) print(r.json()) @@ -1195,10 +1839,10 @@ const headers = { }; // For the deployment by DYDX token holders, use -// baseURL = 'https://indexer.dydx.trade/v4' -const baseURL = 'https://dydx-testnet.imperator.co/v4' +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; -fetch(`${baseURL}/orders?address=string&subaccountNumber=0&limit=0`, +fetch(`${baseURL}/orders/parentSubaccountNumber?address=string&parentSubaccountNumber=0.1`, { method: 'GET', @@ -1212,15 +1856,15 @@ fetch(`${baseURL}/orders?address=string&subaccountNumber=0&limit=0`, ``` -`GET /orders` +`GET /orders/parentSubaccountNumber` ### Parameters |Name|In|Type|Required|Description| |---|---|---|---|---| |address|query|string|true|none| -|subaccountNumber|query|number(double)|true|none| -|limit|query|number(double)|true|none| +|parentSubaccountNumber|query|number(double)|true|none| +|limit|query|number(double)|false|none| |ticker|query|string|false|none| |side|query|[OrderSide](#schemaorderside)|false|none| |type|query|[OrderType](#schemaordertype)|false|none| @@ -1271,7 +1915,8 @@ fetch(`${baseURL}/orders?address=string&subaccountNumber=0&limit=0`, "postOnly": true, "ticker": "string", "updatedAt": "string", - "updatedAtHeight": "string" + "updatedAtHeight": "string", + "subaccountNumber": 0.1 } ] ``` @@ -1328,6 +1973,7 @@ Status Code **200** |» ticker|string|true|none|none| |» updatedAt|[IsoString](#schemaisostring)|false|none|none| |» updatedAtHeight|string|false|none|none| +|» subaccountNumber|number(double)|true|none|none| #### Enumerated Values @@ -1385,8 +2031,8 @@ const headers = { }; // For the deployment by DYDX token holders, use -// baseURL = 'https://indexer.dydx.trade/v4' -const baseURL = 'https://dydx-testnet.imperator.co/v4' +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; fetch(`${baseURL}/orders/{orderId}`, { @@ -1437,7 +2083,8 @@ fetch(`${baseURL}/orders/{orderId}`, "postOnly": true, "ticker": "string", "updatedAt": "string", - "updatedAtHeight": "string" + "updatedAtHeight": "string", + "subaccountNumber": 0.1 } ``` @@ -1467,9 +2114,7 @@ headers = { # baseURL = 'https://indexer.dydx.trade/v4' baseURL = 'https://dydx-testnet.imperator.co/v4' -r = requests.get(f'{baseURL}/perpetualMarkets', params={ - 'limit': '0' -}, headers = headers) +r = requests.get(f'{baseURL}/perpetualMarkets', headers = headers) print(r.json()) @@ -1482,10 +2127,10 @@ const headers = { }; // For the deployment by DYDX token holders, use -// baseURL = 'https://indexer.dydx.trade/v4' -const baseURL = 'https://dydx-testnet.imperator.co/v4' +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; -fetch(`${baseURL}/perpetualMarkets?limit=0`, +fetch(`${baseURL}/perpetualMarkets`, { method: 'GET', @@ -1505,7 +2150,7 @@ fetch(`${baseURL}/perpetualMarkets?limit=0`, |Name|In|Type|Required|Description| |---|---|---|---|---| -|limit|query|number(double)|true|none| +|limit|query|number(double)|false|none| |ticker|query|string|false|none| > Example responses @@ -1522,17 +2167,21 @@ fetch(`${baseURL}/perpetualMarkets?limit=0`, "oraclePrice": "string", "priceChange24H": "string", "volume24H": "string", - "trades24H": 0, + "trades24H": 0.1, "nextFundingRate": "string", "initialMarginFraction": "string", "maintenanceMarginFraction": "string", "openInterest": "string", - "atomicResolution": 0, - "quantumConversionExponent": 0, + "atomicResolution": 0.1, + "quantumConversionExponent": 0.1, "tickSize": "string", "stepSize": "string", - "stepBaseQuantums": 0, - "subticksPerTick": 0 + "stepBaseQuantums": 0.1, + "subticksPerTick": 0.1, + "marketType": "CROSS", + "openInterestLowerCap": "string", + "openInterestUpperCap": "string", + "baseOpenInterest": "string" }, "property2": { "clobPairId": "string", @@ -1541,17 +2190,21 @@ fetch(`${baseURL}/perpetualMarkets?limit=0`, "oraclePrice": "string", "priceChange24H": "string", "volume24H": "string", - "trades24H": 0, + "trades24H": 0.1, "nextFundingRate": "string", "initialMarginFraction": "string", "maintenanceMarginFraction": "string", "openInterest": "string", - "atomicResolution": 0, - "quantumConversionExponent": 0, + "atomicResolution": 0.1, + "quantumConversionExponent": 0.1, "tickSize": "string", "stepSize": "string", - "stepBaseQuantums": 0, - "subticksPerTick": 0 + "stepBaseQuantums": 0.1, + "subticksPerTick": 0.1, + "marketType": "CROSS", + "openInterestLowerCap": "string", + "openInterestUpperCap": "string", + "baseOpenInterest": "string" } } } @@ -1584,9 +2237,7 @@ headers = { baseURL = 'https://dydx-testnet.imperator.co/v4' r = requests.get(f'{baseURL}/perpetualPositions', params={ - 'address': 'string', 'subaccountNumber': '0', 'status': [ - "OPEN" -], 'limit': '0' + 'address': 'string', 'subaccountNumber': '0.1' }, headers = headers) print(r.json()) @@ -1600,10 +2251,10 @@ const headers = { }; // For the deployment by DYDX token holders, use -// baseURL = 'https://indexer.dydx.trade/v4' -const baseURL = 'https://dydx-testnet.imperator.co/v4' +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; -fetch(`${baseURL}/perpetualPositions?address=string&subaccountNumber=0&status=OPEN&limit=0`, +fetch(`${baseURL}/perpetualPositions?address=string&subaccountNumber=0.1`, { method: 'GET', @@ -1625,8 +2276,116 @@ fetch(`${baseURL}/perpetualPositions?address=string&subaccountNumber=0&status=OP |---|---|---|---|---| |address|query|string|true|none| |subaccountNumber|query|number(double)|true|none| -|status|query|array[string]|true|none| -|limit|query|number(double)|true|none| +|status|query|array[string]|false|none| +|limit|query|number(double)|false|none| +|createdBeforeOrAtHeight|query|number(double)|false|none| +|createdBeforeOrAt|query|[IsoString](#schemaisostring)|false|none| + +#### Enumerated Values + +|Parameter|Value| +|---|---| +|status|OPEN| +|status|CLOSED| +|status|LIQUIDATED| + +> Example responses + +> 200 Response + +```json +{ + "positions": [ + { + "market": "string", + "status": "OPEN", + "side": "LONG", + "size": "string", + "maxSize": "string", + "entryPrice": "string", + "realizedPnl": "string", + "createdAt": "string", + "createdAtHeight": "string", + "sumOpen": "string", + "sumClose": "string", + "netFunding": "string", + "unrealizedPnl": "string", + "closedAt": "string", + "exitPrice": "string", + "subaccountNumber": 0.1 + } + ] +} +``` + +### Responses + +|Status|Meaning|Description|Schema| +|---|---|---|---| +|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[PerpetualPositionResponse](#schemaperpetualpositionresponse)| + + + +## ListPositionsForParentSubaccount + + + +> Code samples + +```python +import requests +headers = { + 'Accept': 'application/json' +} + +# For the deployment by DYDX token holders, use +# baseURL = 'https://indexer.dydx.trade/v4' +baseURL = 'https://dydx-testnet.imperator.co/v4' + +r = requests.get(f'{baseURL}/perpetualPositions/parentSubaccountNumber', params={ + 'address': 'string', 'parentSubaccountNumber': '0.1' +}, headers = headers) + +print(r.json()) + +``` + +```javascript + +const headers = { + 'Accept':'application/json' +}; + +// For the deployment by DYDX token holders, use +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; + +fetch(`${baseURL}/perpetualPositions/parentSubaccountNumber?address=string&parentSubaccountNumber=0.1`, +{ + method: 'GET', + + headers: headers +}) +.then(function(res) { + return res.json(); +}).then(function(body) { + console.log(body); +}); + +``` + +`GET /perpetualPositions/parentSubaccountNumber` + +### Parameters + +|Name|In|Type|Required|Description| +|---|---|---|---|---| +|address|query|string|true|none| +|parentSubaccountNumber|query|number(double)|true|none| +|status|query|array[string]|false|none| +|limit|query|number(double)|false|none| |createdBeforeOrAtHeight|query|number(double)|false|none| |createdBeforeOrAt|query|[IsoString](#schemaisostring)|false|none| @@ -1660,7 +2419,8 @@ fetch(`${baseURL}/perpetualPositions?address=string&subaccountNumber=0&status=OP "netFunding": "string", "unrealizedPnl": "string", "closedAt": "string", - "exitPrice": "string" + "exitPrice": "string", + "subaccountNumber": 0.1 } ] } @@ -1707,8 +2467,8 @@ const headers = { }; // For the deployment by DYDX token holders, use -// baseURL = 'https://indexer.dydx.trade/v4' -const baseURL = 'https://dydx-testnet.imperator.co/v4' +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; fetch(`${baseURL}/sparklines?timePeriod=ONE_DAY`, { @@ -1732,12 +2492,85 @@ fetch(`${baseURL}/sparklines?timePeriod=ONE_DAY`, |---|---|---|---|---| |timePeriod|query|[SparklineTimePeriod](#schemasparklinetimeperiod)|true|none| -#### Enumerated Values +#### Enumerated Values + +|Parameter|Value| +|---|---| +|timePeriod|ONE_DAY| +|timePeriod|SEVEN_DAYS| + +> Example responses + +> 200 Response + +```json +{ + "property1": [ + "string" + ], + "property2": [ + "string" + ] +} +``` + +### Responses + +|Status|Meaning|Description|Schema| +|---|---|---|---| +|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[SparklineResponseObject](#schemasparklineresponseobject)| + + + +## GetTime + + + +> Code samples + +```python +import requests +headers = { + 'Accept': 'application/json' +} + +# For the deployment by DYDX token holders, use +# baseURL = 'https://indexer.dydx.trade/v4' +baseURL = 'https://dydx-testnet.imperator.co/v4' + +r = requests.get(f'{baseURL}/time', headers = headers) + +print(r.json()) + +``` + +```javascript + +const headers = { + 'Accept':'application/json' +}; + +// For the deployment by DYDX token holders, use +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; + +fetch(`${baseURL}/time`, +{ + method: 'GET', + + headers: headers +}) +.then(function(res) { + return res.json(); +}).then(function(body) { + console.log(body); +}); + +``` -|Parameter|Value| -|---|---| -|timePeriod|ONE_DAY| -|timePeriod|SEVEN_DAYS| +`GET /time` > Example responses @@ -1745,12 +2578,8 @@ fetch(`${baseURL}/sparklines?timePeriod=ONE_DAY`, ```json { - "property1": [ - "string" - ], - "property2": [ - "string" - ] + "iso": "string", + "epoch": 0.1 } ``` @@ -1758,15 +2587,15 @@ fetch(`${baseURL}/sparklines?timePeriod=ONE_DAY`, |Status|Meaning|Description|Schema| |---|---|---|---| -|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[SparklineResponseObject](#schemasparklineresponseobject)| +|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[TimeResponse](#schematimeresponse)| -## GetTime +## GetTrades - + > Code samples @@ -1780,7 +2609,7 @@ headers = { # baseURL = 'https://indexer.dydx.trade/v4' baseURL = 'https://dydx-testnet.imperator.co/v4' -r = requests.get(f'{baseURL}/time', headers = headers) +r = requests.get(f'{baseURL}/trades/perpetualMarket/{ticker}', headers = headers) print(r.json()) @@ -1793,10 +2622,10 @@ const headers = { }; // For the deployment by DYDX token holders, use -// baseURL = 'https://indexer.dydx.trade/v4' -const baseURL = 'https://dydx-testnet.imperator.co/v4' +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; -fetch(`${baseURL}/time`, +fetch(`${baseURL}/trades/perpetualMarket/{ticker}`, { method: 'GET', @@ -1810,7 +2639,17 @@ fetch(`${baseURL}/time`, ``` -`GET /time` +`GET /trades/perpetualMarket/{ticker}` + +### Parameters + +|Name|In|Type|Required|Description| +|---|---|---|---|---| +|ticker|path|string|true|none| +|limit|query|number(double)|false|none| +|createdBeforeOrAtHeight|query|number(double)|false|none| +|createdBeforeOrAt|query|[IsoString](#schemaisostring)|false|none| +|page|query|number(double)|false|none| > Example responses @@ -1818,8 +2657,20 @@ fetch(`${baseURL}/time`, ```json { - "iso": "string", - "epoch": 0 + "pageSize": 0.1, + "totalResults": 0.1, + "offset": 0.1, + "trades": [ + { + "id": "string", + "side": "BUY", + "size": "string", + "price": "string", + "type": "LIMIT", + "createdAt": "string", + "createdAtHeight": "string" + } + ] } ``` @@ -1827,15 +2678,15 @@ fetch(`${baseURL}/time`, |Status|Meaning|Description|Schema| |---|---|---|---| -|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[TimeResponse](#schematimeresponse)| +|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[TradeResponse](#schematraderesponse)| -## GetTrades +## GetTransfers - + > Code samples @@ -1849,8 +2700,8 @@ headers = { # baseURL = 'https://indexer.dydx.trade/v4' baseURL = 'https://dydx-testnet.imperator.co/v4' -r = requests.get(f'{baseURL}/trades/perpetualMarket/{ticker}', params={ - 'limit': '0' +r = requests.get(f'{baseURL}/transfers', params={ + 'address': 'string', 'subaccountNumber': '0.1' }, headers = headers) print(r.json()) @@ -1864,10 +2715,10 @@ const headers = { }; // For the deployment by DYDX token holders, use -// baseURL = 'https://indexer.dydx.trade/v4' -const baseURL = 'https://dydx-testnet.imperator.co/v4' +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; -fetch(`${baseURL}/trades/perpetualMarket/{ticker}?limit=0`, +fetch(`${baseURL}/transfers?address=string&subaccountNumber=0.1`, { method: 'GET', @@ -1881,16 +2732,18 @@ fetch(`${baseURL}/trades/perpetualMarket/{ticker}?limit=0`, ``` -`GET /trades/perpetualMarket/{ticker}` +`GET /transfers` ### Parameters |Name|In|Type|Required|Description| |---|---|---|---|---| -|ticker|path|string|true|none| -|limit|query|number(double)|true|none| +|address|query|string|true|none| +|subaccountNumber|query|number(double)|true|none| +|limit|query|number(double)|false|none| |createdBeforeOrAtHeight|query|number(double)|false|none| |createdBeforeOrAt|query|[IsoString](#schemaisostring)|false|none| +|page|query|number(double)|false|none| > Example responses @@ -1898,15 +2751,26 @@ fetch(`${baseURL}/trades/perpetualMarket/{ticker}?limit=0`, ```json { - "trades": [ + "pageSize": 0.1, + "totalResults": 0.1, + "offset": 0.1, + "transfers": [ { "id": "string", - "side": "BUY", + "sender": { + "subaccountNumber": 0.1, + "address": "string" + }, + "recipient": { + "subaccountNumber": 0.1, + "address": "string" + }, "size": "string", - "price": "string", - "type": "LIMIT", "createdAt": "string", - "createdAtHeight": "string" + "createdAtHeight": "string", + "symbol": "string", + "type": "TRANSFER_IN", + "transactionHash": "string" } ] } @@ -1916,15 +2780,15 @@ fetch(`${baseURL}/trades/perpetualMarket/{ticker}?limit=0`, |Status|Meaning|Description|Schema| |---|---|---|---| -|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[TradeResponse](#schematraderesponse)| +|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[TransferResponse](#schematransferresponse)| -## GetTransfers +## GetTransfersForParentSubaccount - + > Code samples @@ -1938,8 +2802,8 @@ headers = { # baseURL = 'https://indexer.dydx.trade/v4' baseURL = 'https://dydx-testnet.imperator.co/v4' -r = requests.get(f'{baseURL}/transfers', params={ - 'address': 'string', 'subaccountNumber': '0', 'limit': '0' +r = requests.get(f'{baseURL}/transfers/parentSubaccountNumber', params={ + 'address': 'string', 'parentSubaccountNumber': '0.1' }, headers = headers) print(r.json()) @@ -1953,10 +2817,10 @@ const headers = { }; // For the deployment by DYDX token holders, use -// baseURL = 'https://indexer.dydx.trade/v4' -const baseURL = 'https://dydx-testnet.imperator.co/v4' +// const baseURL = 'https://indexer.dydx.trade/v4'; +const baseURL = 'https://dydx-testnet.imperator.co/v4'; -fetch(`${baseURL}/transfers?address=string&subaccountNumber=0&limit=0`, +fetch(`${baseURL}/transfers/parentSubaccountNumber?address=string&parentSubaccountNumber=0.1`, { method: 'GET', @@ -1970,17 +2834,18 @@ fetch(`${baseURL}/transfers?address=string&subaccountNumber=0&limit=0`, ``` -`GET /transfers` +`GET /transfers/parentSubaccountNumber` ### Parameters |Name|In|Type|Required|Description| |---|---|---|---|---| |address|query|string|true|none| -|subaccountNumber|query|number(double)|true|none| -|limit|query|number(double)|true|none| +|parentSubaccountNumber|query|number(double)|true|none| +|limit|query|number(double)|false|none| |createdBeforeOrAtHeight|query|number(double)|false|none| |createdBeforeOrAt|query|[IsoString](#schemaisostring)|false|none| +|page|query|number(double)|false|none| > Example responses @@ -1988,15 +2853,18 @@ fetch(`${baseURL}/transfers?address=string&subaccountNumber=0&limit=0`, ```json { + "pageSize": 0.1, + "totalResults": 0.1, + "offset": 0.1, "transfers": [ { "id": "string", "sender": { - "subaccountNumber": 0, + "subaccountNumber": 0.1, "address": "string" }, "recipient": { - "subaccountNumber": 0, + "subaccountNumber": 0.1, "address": "string" }, "size": "string", @@ -2014,7 +2882,7 @@ fetch(`${baseURL}/transfers?address=string&subaccountNumber=0&limit=0`, |Status|Meaning|Description|Schema| |---|---|---|---| -|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[TransferResponse](#schematransferresponse)| +|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Ok|[ParentSubaccountTransferResponse](#schemaparentsubaccounttransferresponse)|