Quick fixes to docs: terminology, grammar, and casing

pages/api_integration-guides/how_to_isolated.md

@@ -1,34 +1,34 @@
 # How to integrate APIs with FE isolated positions
 
 ## Overview
-This document covers how to use the API to query data on / trade with isolated positions that are managed with the dYdX V4 front-end.
+This document covers how to use the API to query data on / trade with isolated positions that are managed with the dYdX V4 front end.
 
-## Isolated Positions on dYdX V4 front-end
-Isolated positions on the dYdX V4 front-end are perpetual positions held in subaccounts with a subaccount number greater than 127, up to the limit of 128,000. Each isolated position is held in a separate subaccount.
+## Isolated positions on dYdX V4 front end
+Isolated positions on the dYdX V4 front end are perpetual positions held in subaccounts with a subaccount number greater than 127, up to the limit of 128,000. Each isolated position is held in a separate subaccount.
 
 ### Mapping of isolated positions to subaccounts
-The dYdX V4 front-end implementation separates subaccounts (0 - 128,000) into 2 separate types:
+The dYdX V4 front end implementation separates subaccounts (0 - 128,000) into 2 separate types:
 
 **Parent subaccounts**
 
 Subaccounts 0 to 127 are parent subaccounts. Parent subaccounts can have multiple positions opened and all positions are cross-margined.
 
 **Child subaccounts**
 
-Subaccounts 128 to 128,000 are child subaccounts. Child subaccounts will only ever have up to 1 position open. Each open isolated position on the front-end is held by a separate child subaccount.
-Once an isolated position is closed in the front-end, the subaccount associated with isolated position can be re-used for the next isolated position.
+Subaccounts 128 to 128,000 are child subaccounts. Child subaccounts will only ever have up to 1 position open. Each open isolated position on the front end is held by a separate child subaccount.
+Once an isolated position is closed in the front end, the subaccount associated with isolated position can be re-used for the next isolated position.
 Child subaccounts are mapped to parent subaccounts using the formula:
 ```
 parent_subaccount_number = child_subaccount_number % 128
 ```
 
-> Note that currently only parent subaccount 0 is exposed via the front-end and so isolated positions will be held in subaccounts number 128, 256, ...
+> Note that currently only parent subaccount 0 is exposed via the front end and so isolated positions will be held in subaccounts number 128, 256, ...
 
-> Note that the above "types" of subaccounts are not enforced at a protocol level, and only on the front-end. Any subaccount can hold any number of positions in cross-marginable markets which all will cross-margined at the protocol level.
+> Note that the above "types" of subaccounts are not enforced at a protocol level, and only on the front end. Any subaccount can hold any number of positions in cross-marginable markets which all will cross-margined at the protocol level.
 
 ### Getting data for parent subaccount
 API endpoints exist to get data for a parent subaccount and all it's child subaccounts on the Indexer.
 
-> Currently all data for an account viewable on the front-end can be fetched by using the parent subaccount APIs to fetch data for parent subaccount number 0.
+> Currently all data for an account viewable on the front end can be fetched by using the parent subaccount APIs to fetch data for parent subaccount number 0.
 
 See the <a href="/developers/indexer/indexer_api">Indexer API</a> page for more details of the parent subaccount APIs.

pages/api_integration-trading/isolated_markets.md

@@ -2,7 +2,7 @@
 
 In v5.0.0 the Isolated Markets feature was added to the V4 chain software. The below is an overview of how trading will work on Isolated Markets on the V4 chain software.
 
->Note: This document covers how the feature works from the protocol point of view and not the front-end or the indexer. For more details on what isolated markets are see the [blog post](https://dydx.exchange/blog/introducing-isolated-markets-and-isolated-margin).
+>Note: This document covers how the feature works from the protocol point of view and not the front end or the indexer. For more details on what isolated markets are see the [blog post](https://dydx.exchange/blog/introducing-isolated-markets-and-isolated-margin).
 
 # Trading Isolated Markets
 

pages/concepts-architecture/architectural_overview.md

@@ -12,31 +12,31 @@ The open-source protocol is an L1 blockchain built on top of [CometBFT](https://
 
 The protocol is supported by a network of nodes. There are two types of nodes:
 
-- **Validators**: Validators are responsible for storing orders in an in-memory orderbook (i.e. off chain and not committed to consensus), gossipping transactions to other validators, and producing new blocks for the dYdX Chain through the consensus process. The consensus process will have validators take turns as the proposer of new blocks in a weighted-round-robin fashion (weighted by the number of tokens staked to their node). The proposer is responsible for proposing the contents of the next block. When an order gets matched, the proposer adds it to their proposed block and initiates a consensus round. If ⅔ or more of the validators (by stake weight) approve of a block, then the block is considered committed and added to the blockchain. Users will submit transactions directly to validators.
+- **Validators**: Validators are responsible for storing orders in an in-memory orderbook (i.e. off chain and not committed to consensus), gossipping transactions to other validators, and producing new blocks for dYdX Chain through the consensus process. The consensus process will have validators take turns as the proposer of new blocks in a weighted-round-robin fashion (weighted by the number of tokens staked to their node). The proposer is responsible for proposing the contents of the next block. When an order gets matched, the proposer adds it to their proposed block and initiates a consensus round. If ⅔ or more of the validators (by stake weight) approve of a block, then the block is considered committed and added to the blockchain. Users will submit transactions directly to validators.
 
-- **Full Nodes**: A Full Node represents a process running the dYdX Chain open-source application that does not participate in consensus. It is a node with 0 stake weight and it does not submit proposals or vote on them. However, full nodes are connected to the network of validators, participate in the gossiping of transactions, and also process each new committed block. Full nodes have a complete view of the dYdX Chain and its history, and are intended to support the Indexer. Some parties may decide (either for performance or cost reasons) to run their own full node and/or Indexer.
+- **Full Nodes**: A Full Node represents a process running the dYdX Chain open-source application that does not participate in consensus. It is a node with 0 stake weight and it does not submit proposals or vote on them. However, full nodes are connected to the network of validators, participate in the gossiping of transactions, and also process each new committed block. Full nodes have a complete view of a dYdX Chain and its history, and are intended to support the Indexer. Some parties may decide (either for performance or cost reasons) to run their own full node and/or Indexer.
 
 ### Indexer
 The Indexer is a read-only collection of services whose purpose is to index and serve blockchain data to end users in a more efficient and web2-friendly way. This is done by consuming real time data from a dYdX Chain full node, storing it in a database, and serving that data through a websocket and REST requests to end-users.
 
-While the dYdX Chain open-source protocol itself is capable of exposing endpoints to service queries about some basic on-chain data, those queries tend to be slow as validators and full nodes are not optimized to efficiently handle them. Additionally, an excess of queries to a validator can impair its ability to participate in consensus. For this reason, many Cosmos validators tend to disable these APIs in production. This is why it is important to build and maintain Indexer and full-node software separate from validator software.
+While the dYdX Chain open-source protocol itself is capable of exposing endpoints to service queries about some basic onchain data, those queries tend to be slow as validators and full nodes are not optimized to efficiently handle them. Additionally, an excess of queries to a validator can impair its ability to participate in consensus. For this reason, many Cosmos validators tend to disable these APIs in production. This is why it is important to build and maintain Indexer and full-node software separate from validator software.
 
-Indexers use Postgres databases to store on-chain data, Redis for off-chain data, and Kafka for consuming and streaming on/off-chain data to the various Indexer services.
+Indexers use Postgres databases to store onchain data, Redis for offchain data, and Kafka for consuming and streaming on/offchain data to the various Indexer services.
 
 ### Front-ends
 In service of building an end-to-end decentralized experience, dYdX has built three open-source front ends: a web app, an iOS app, and an Android app.  
 
-- **Web application**: The website was built using Javascript and React. The website interacts with the Indexer through an API to get off-chain orderbook information and will send trades directly to the chain. dYdX has open sourced the front end codebase and associated deployment scripts. This allows anyone to easily deploy and access the dYdX front end to/from their own domain/hosting solution via IPFS/Cloudflare gateway. 
+- **Web application**: The website was built using Javascript and React. The website interacts with the Indexer through an API to get offchain orderbook information and will send trades directly to the chain. dYdX has open sourced the front-end codebase and associated deployment scripts. This allows anyone to easily deploy and access the dYdX front end to/from their own domain/hosting solution via IPFS/Cloudflare gateway. 
 
 - **Mobile**: The iOS and Android apps are built in native Swift and Kotlin, respectively. The mobile apps interact with the Indexer in the same way the web application does, and will send trades directly to the chain. The mobile apps have been open sourced as well, allowing anyone to deploy the mobile app to the App Store or Play store. Specifically for the App store, the deployer needs to have a developer account as well as a Bitrise account to go through the app submission process.
 
 ### Lifecycle of an Order
 Now that we have a better understanding of each of the components of dYdX Chain, let’s take a look at how it all comes together when placing an order. When an order is placed on dYdX Chain, it follows the flow below:
 
-1. User places a trade on a decentralized front-end (e.g., website) or via API
+1. User places a trade on a decentralized front end (e.g., website) or via API
 2. The order is routed to a validator. That validator gossips that transaction to other validators and full nodes to update their orderbooks with the new order.
 3. The consensus process picks one validator to be the proposer. The selected validator matches the order and adds it to its next proposed block.
 4. The proposed block continues through the consensus process. 
-    1. If ⅔ of validator nodes vote to confirm the block, then the block is committed and saved to the on-chain databases of all validators and full nodes.
+    1. If ⅔ of validator nodes vote to confirm the block, then the block is committed and saved to the onchain databases of all validators and full nodes.
     2. If the proposed block does not successfully hit the ⅔ threshold, then the block is rejected.
-5. 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.
+5. After the block is committed, the updated onchain (and offchain) 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.