noun vs adjective frontend

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

@@ -26,14 +26,14 @@ Indexers use Postgres databases to store onchain data, Redis for offchain data,
 ### 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 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. 
+- **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. 

pages/infrastructure_providers-network/resources.mdx

@@ -342,7 +342,7 @@ For **Testnet**:
 
 | Name                       | URI                                                                                                   |
 | -------------------------- | ----------------------------------------------------------------------------------------------------- |
-| Public Testnet Front-end   | `https://v4.testnet.dydx.exchange`                                                                    |
+| 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`                                                       |

pages/user-guides/how_to_troubleshoot_withdrawals_and_deposits.md

@@ -58,7 +58,7 @@ For more info on this flow, see: [https://dydx.exchange/blog/cctp](https://dydx.
     You should see a "deposit to subaccount" transaction there.
 
     - If not, you can confirm whether USDC has arrived on Noble, by checking [https://www.mintscan.io/noble](https://www.mintscan.io/noble) or [https://ibc.range.org](https://ibc.range.org).
-    - You need to make sure you have the dYdX front-end opened and wallet connected. The dYdX front end will detect your funds on Noble and auto-sweep it to your dYdX address. For this to happen, you need to actively open the front end and connect your wallet.
+    - You need to make sure you have the dYdX front end opened and wallet connected. The dYdX front end will detect your funds on Noble and auto-sweep it to your dYdX address. For this to happen, you need to actively open the front end and connect your wallet.
       ​
 
 4.  **Manual process stuck funds**