fix: no need to escape ()

docs/build/avalanchego-apis/README.md

@@ -4,14 +4,14 @@ sidebar_position: 1
 
 # Overview
 
-Clients interact with Avalanche through APIs calls to nodes. Numeric parameters in API calls may be given as strings \(e.g., `"5"` or `5` are both ok for an integer argument\). Numeric return values are always given as strings \(e.g., `"5"` rather than `5`\). In examples, API calls are made to a node listening for HTTP traffic on `127.0.0.1:9650`.
+Clients interact with Avalanche through APIs calls to nodes. Numeric parameters in API calls may be given as strings (e.g., `"5"` or `5` are both ok for an integer argument). Numeric return values are always given as strings (e.g., `"5"` rather than `5`). In examples, API calls are made to a node listening for HTTP traffic on `127.0.0.1:9650`.
 
 | Title | Description |
 | :--- | :--- |
 | [**Issuing API Calls**](issuing-api-calls.md) | This guide explains how to make calls to APIs exposed by Avalanche nodes. |
-| The [**Platform Chain \(P-Chain\) API**](platform-chain-p-chain-api.md) | Allows clients to interact with the P-Chain \(Platform Chain\), which maintains Avalanche’s validator set and handles blockchain and subnet creation. |
-| The [**Contract Chain \(C-Chain\) API**](contract-chain-c-chain-api.md) | Allows clients to interact with the C-Chain, Avalanche’s main EVM instance, as well as other EVM instances. |
-| The [**Exchange Chain \(X-Chain\) API**](exchange-chain-x-chain-api.mdx) | Allows clients to create and trade assets, including AVAX, on the X-Chain as well as other instances of the AVM. |
+| The [**Platform Chain (P-Chain) API**](platform-chain-p-chain-api.md) | Allows clients to interact with the P-Chain (Platform Chain), which maintains Avalanche’s validator set and handles blockchain and subnet creation. |
+| The [**Contract Chain (C-Chain) API**](contract-chain-c-chain-api.md) | Allows clients to interact with the C-Chain, Avalanche’s main EVM instance, as well as other EVM instances. |
+| The [**Exchange Chain (X-Chain) API**](exchange-chain-x-chain-api.mdx) | Allows clients to create and trade assets, including AVAX, on the X-Chain as well as other instances of the AVM. |
 | The [**Admin API**](admin-api.md) | Allows clients to examine a node’s internal state, set of connections, and similar internal protocol data. |
 | The [**Auth API**](auth-api.md) | Allows clients to manage the creation and revocation of authorization tokens. |
 | The [**Health API**](health-api.md) | Allows clients to check a node’s health. |

docs/build/avalanchego-apis/admin-api.md

@@ -75,7 +75,7 @@ admin.aliasChain(
 ```
 
 * `chain` is the blockchain’s ID.
-* `alias` can now be used in place of the blockchain’s ID \(in API endpoints, for example.\)
+* `alias` can now be used in place of the blockchain’s ID (in API endpoints, for example.)
 
 #### **Example Call**
 

docs/build/avalanchego-apis/auth-api.md

@@ -7,7 +7,7 @@ When you run a node, you can require that API calls have an authorization token
 
 An authorization token provides access to one or more API endpoints. This is is useful for delegating access to a node’s APIs. Tokens expire after 12 hours.
 
-An authorization token is provided in the header of an API call. Specifically, the header `Authorization` should have value `Bearer TOKEN.GOES.HERE` \(where `TOKEN.GOES.HERE` is replaced with the token\).
+An authorization token is provided in the header of an API call. Specifically, the header `Authorization` should have value `Bearer TOKEN.GOES.HERE` (where `TOKEN.GOES.HERE` is replaced with the token).
 
 This API is only reachable if the node is started with [command line argument ](../references/command-line-interface.md)`--api-auth-required`. If the node is started without this CLI, API calls do not require authorization tokens, so this API is not reachable. This API never requires an authorization token to be reached.
 
@@ -60,7 +60,7 @@ curl -X POST --data '{
 }' -H 'content-type:application/json;' 127.0.0.1:9650/ext/auth
 ```
 
-This call will generate an authorization token that allows access to API endpoints `/ext/bc/X` \(ie the X-Chain\) and `/ext/info` \(ie the [info API](info-api.md).\)
+This call will generate an authorization token that allows access to API endpoints `/ext/bc/X` (ie the X-Chain) and `/ext/info` (ie the [info API](info-api.md).)
 
 #### **Example Response**
 

docs/build/avalanchego-apis/contract-chain-c-chain-api.md

@@ -72,7 +72,7 @@ You can interact with these services the same exact way you’d interact with Ge
 
 #### eth\_getAssetBalance
 
-In addition to the standard Ethereum APIs, Avalanche offers `eth_getAssetBalance` to retrieve the balance of first class Avalanche Native Tokens on the C-Chain \(excluding AVAX, which must be fetched with `eth_getBalance`\).
+In addition to the standard Ethereum APIs, Avalanche offers `eth_getAssetBalance` to retrieve the balance of first class Avalanche Native Tokens on the C-Chain (excluding AVAX, which must be fetched with `eth_getBalance`).
 
 **Signature**
 
@@ -451,7 +451,7 @@ avax.getUTXOs(
 * At most `limit` UTXOs are returned. If `limit` is omitted or greater than 1024, it is set to 1024.
 * This method supports pagination. `endIndex` denotes the last UTXO returned. To get the next set of UTXOs, use the value of `endIndex` as `startIndex` in the next call.
 * If `startIndex` is omitted, will fetch all UTXOs up to `limit`.
-* When using pagination \(ie when `startIndex` is provided\), UTXOs are not guaranteed to be unique across multiple calls. That is, a UTXO may appear in the result of the first call, and then again in the second call.
+* When using pagination (ie when `startIndex` is provided), UTXOs are not guaranteed to be unique across multiple calls. That is, a UTXO may appear in the result of the first call, and then again in the second call.
 * When using pagination, consistency is not guaranteed across multiple calls. That is, the UTXO set of the addresses may have changed between calls.
 * `encoding` sets the format for the returned UTXOs. Can be either "cb58" or "hex". Defaults to "cb58".
 
@@ -717,7 +717,7 @@ avax.getAtomicTxStatus({txID: string}) -> {
 
 `status` is one of:
 
-* `Accepted`: The transaction is \(or will be\) accepted by every node. Check the `blockHeight` property
+* `Accepted`: The transaction is (or will be) accepted by every node. Check the `blockHeight` property
 * `Processing`: The transaction is being voted on by this node
 * `Dropped`: The transaction was dropped by this node because it thought the transaction invalid
 * `Unknown`: The transaction hasn’t been seen by this node

docs/build/avalanchego-apis/exchange-chain-x-chain-api.mdx

@@ -6,7 +6,7 @@ import Iframe from 'react-iframe'
 
 # Exchange Chain (X-Chain) API
 
-The [X-Chain](../../learn/platform-overview/README.md#exchange-chain-x-chain), Avalanche’s native platform for creating and trading assets, is an instance of the Avalanche Virtual Machine \(AVM\). This API allows clients to create and trade assets on the X-Chain and other instances of the AVM.
+The [X-Chain](../../learn/platform-overview/README.md#exchange-chain-x-chain), Avalanche’s native platform for creating and trading assets, is an instance of the Avalanche Virtual Machine (AVM). This API allows clients to create and trade assets on the X-Chain and other instances of the AVM.
 
 <Iframe url="https://www.youtube.com/embed/rD-IOd1nvFo"
         width="100%"
@@ -41,7 +41,7 @@ This call is made to the AVM’s static API endpoint:
 
 `/ext/vm/avm`
 
-Note: addresses should not include a chain prefix \(ie. X-\) in calls to the static API endpoint because these prefixes refer to a specific chain.
+Note: addresses should not include a chain prefix (ie. X-) in calls to the static API endpoint because these prefixes refer to a specific chain.
 
 #### **Signature**
 
@@ -844,7 +844,7 @@ Returns all transactions that change the balance of the given address. A transac
 * A UTXO that the transaction consumes was at least partially owned by the address.
 * A UTXO that the transaction produces is at least partially owned by the address.
 
-Note: Indexing \(`index-transactions`\) must be enabled in the X-chain config.
+Note: Indexing (`index-transactions`) must be enabled in the X-chain config.
 
 #### **Signature**
 
@@ -1042,7 +1042,7 @@ avm.getTxStatus({txID: string}) -> {status: string}
 
 `status` is one of:
 
-* `Accepted`: The transaction is \(or will be\) accepted by every node
+* `Accepted`: The transaction is (or will be) accepted by every node
 * `Processing`: The transaction is being voted on by this node
 * `Rejected`: The transaction will never be accepted by any node in the network
 * `Unknown`: The transaction hasn’t been seen by this node
@@ -1104,7 +1104,7 @@ avm.getUTXOs({
 * At most `limit` UTXOs are returned. If `limit` is omitted or greater than 1024, it is set to 1024.
 * This method supports pagination. `endIndex` denotes the last UTXO returned. To get the next set of UTXOs, use the value of `endIndex` as `startIndex` in the next call.
 * If `startIndex` is omitted, will fetch all UTXOs up to `limit`.
-* When using pagination \(when `startIndex` is provided\), UTXOs are not guaranteed to be unique across multiple calls. That is, a UTXO may appear in the result of the first call, and then again in the second call.
+* When using pagination (when `startIndex` is provided), UTXOs are not guaranteed to be unique across multiple calls. That is, a UTXO may appear in the result of the first call, and then again in the second call.
 * When using pagination, consistency is not guaranteed across multiple calls. That is, the UTXO set of the addresses may have changed between calls.
 * `encoding` sets the format for the returned UTXOs. Can be either "cb58" or "hex". Defaults to "cb58".
 
@@ -1419,12 +1419,12 @@ avm.send({
 }) -> {txID: string, changeAddr: string}
 ```
 
-* Sends `amount` units of asset with ID `assetID` to address `to`. `amount` is denominated in the smallest increment of the asset. For AVAX this is 1 nAVAX \(one billionth of 1 AVAX.\)
+* Sends `amount` units of asset with ID `assetID` to address `to`. `amount` is denominated in the smallest increment of the asset. For AVAX this is 1 nAVAX (one billionth of 1 AVAX.)
 * `to` is the X-Chain address the asset is sent to.
 * `from` are the addresses that you want to use for this operation. If omitted, uses any of your addresses as needed.
 * `changeAddr` is the address any change will be sent to. If omitted, change is sent to one of the addresses controlled by the user.
 * You can attach a `memo`, whose length can be up to 256 bytes.
-* The asset is sent from addresses controlled by user `username`. \(Of course, that user will need to hold at least the balance of the asset being sent.\)
+* The asset is sent from addresses controlled by user `username`. (Of course, that user will need to hold at least the balance of the asset being sent.)
 
 #### **Example Call**
 
@@ -1484,7 +1484,7 @@ avm.sendMultiple({
 * `memo` is an optional message, whose length can be up to 256 bytes.
 * `from` are the addresses that you want to use for this operation. If omitted, uses any of your addresses as needed.
 * `changeAddr` is the address any change will be sent to. If omitted, change is sent to one of the addresses controlled by the user.
-* The asset is sent from addresses controlled by user `username`. \(Of course, that user will need to hold at least the balance of the asset being sent.\)
+* The asset is sent from addresses controlled by user `username`. (Of course, that user will need to hold at least the balance of the asset being sent.)
 
 #### **Example Call**
 
@@ -1550,7 +1550,7 @@ avm.sendNFT({
 * `groupID` is the NFT group from which to send the NFT. NFT creation allows multiple groups under each NFT ID. You can issue multiple NFTs to each group.
 * `to` is the X-Chain address the NFT is sent to.
 * `from` are the addresses that you want to use for this operation. If omitted, uses any of your addresses as needed. `changeAddr` is the address any change will be sent to. If omitted, change is sent to one of the addresses controlled by the user.
-* The asset is sent from addresses controlled by user `username`. \(Of course, that user will need to hold at least the balance of the NFT being sent.\)
+* The asset is sent from addresses controlled by user `username`. (Of course, that user will need to hold at least the balance of the NFT being sent.)
 
 #### **Example Call**
 
@@ -1652,12 +1652,12 @@ wallet.send({
 }) -> {txID: string, changeAddr: string}
 ```
 
-* Sends `amount` units of asset with ID `assetID` to address `to`. `amount` is denominated in the smallest increment of the asset. For AVAX this is 1 nAVAX \(one billionth of 1 AVAX.\)
+* Sends `amount` units of asset with ID `assetID` to address `to`. `amount` is denominated in the smallest increment of the asset. For AVAX this is 1 nAVAX (one billionth of 1 AVAX.)
 * `to` is the X-Chain address the asset is sent to.
 * `from` are the addresses that you want to use for this operation. If omitted, uses any of your addresses as needed.
 * `changeAddr` is the address any change will be sent to. If omitted, change is sent to one of the addresses controlled by the user.
 * You can attach a `memo`, whose length can be up to 256 bytes.
-* The asset is sent from addresses controlled by user `username`. \(Of course, that user will need to hold at least the balance of the asset being sent.\)
+* The asset is sent from addresses controlled by user `username`. (Of course, that user will need to hold at least the balance of the asset being sent.)
 
 #### **Example Call**
 
@@ -1721,7 +1721,7 @@ wallet.sendMultiple({
 * `from` are the addresses that you want to use for this operation. If omitted, uses any of your addresses as needed.
 * `changeAddr` is the address any change will be sent to. If omitted, change is sent to one of the addresses controlled by the user.
 * You can attach a `memo`, whose length can be up to 256 bytes.
-* The asset is sent from addresses controlled by user `username`. \(Of course, that user will need to hold at least the balance of the asset being sent.\)
+* The asset is sent from addresses controlled by user `username`. (Of course, that user will need to hold at least the balance of the asset being sent.)
 
 #### **Example Call**
 

docs/build/avalanchego-apis/index-api.md

@@ -3,11 +3,11 @@ sidebar_position: 10
 ---
 # Index API
 
-AvalancheGo can be configured to run with an indexer. That is, it saves \(indexes\) every container \(a block, vertex or transaction\) it accepts on the X-Chain, P-Chain and C-Chain. To run AvalancheGo with indexing enabled, set command line flag [--index-enabled](../references/command-line-interface.md#apis) to true. **AvalancheGo will only index containers that are accepted when running with `--index-enabled` set to true.** To ensure your node has a complete index, run a node with a fresh database and `--index-enabled` set to true. The node will accept every block, vertex and transaction in the network history during bootstrapping, ensuring your index is complete. It is OK to turn off your node if it is running with indexing enabled. If it restarts with indexing still enabled, it will accept all containers that were accepted while it was offline. The indexer should never fail to index an accepted block, vertex or transaction.
+AvalancheGo can be configured to run with an indexer. That is, it saves (indexes) every container (a block, vertex or transaction) it accepts on the X-Chain, P-Chain and C-Chain. To run AvalancheGo with indexing enabled, set command line flag [--index-enabled](../references/command-line-interface.md#apis) to true. **AvalancheGo will only index containers that are accepted when running with `--index-enabled` set to true.** To ensure your node has a complete index, run a node with a fresh database and `--index-enabled` set to true. The node will accept every block, vertex and transaction in the network history during bootstrapping, ensuring your index is complete. It is OK to turn off your node if it is running with indexing enabled. If it restarts with indexing still enabled, it will accept all containers that were accepted while it was offline. The indexer should never fail to index an accepted block, vertex or transaction.
 
-Indexed containers \(that is, accepted blocks, vertices and transactions\) are timestamped with the time at which the node accepted that container. Note that if the container was indexed during bootstrapping, other nodes may have accepted the container much earlier. Every container indexed during bootstrapping will be timestamped with the time at which the node bootstrapped, not when it was first accepted by the network.
+Indexed containers (that is, accepted blocks, vertices and transactions) are timestamped with the time at which the node accepted that container. Note that if the container was indexed during bootstrapping, other nodes may have accepted the container much earlier. Every container indexed during bootstrapping will be timestamped with the time at which the node bootstrapped, not when it was first accepted by the network.
 
-Note that for DAGs \(including the X-Chain\), nodes may accept vertices and transactions in a different order from one another.
+Note that for DAGs (including the X-Chain), nodes may accept vertices and transactions in a different order from one another.
 
 This document shows how to query data from AvalancheGo's Index API. The Index API is only available when running with `--index-enabled`.
 

docs/build/avalanchego-apis/info-api.md

@@ -20,7 +20,7 @@ This API uses the `json 2.0` RPC format. For more information on making JSON RPC
 
 ### info.getBlockchainID
 
-Given a blockchain’s alias, get its ID. \(See [`admin.aliasChain`](admin-api.md#admin-aliaschain).\)
+Given a blockchain’s alias, get its ID. (See [`admin.aliasChain`](admin-api.md#admin-aliaschain).)
 
 #### **Signature**
 

docs/build/avalanchego-apis/issuing-api-calls.md

@@ -14,7 +14,7 @@ An API call is made to an endpoint, which is a URL. The base of the URL is alway
 where
 
 * `node-ip` is the IP address of the node the call is to.
-* `http-port` is the port the node listens on for HTTP calls. This is specified by [command-line argument](../references/command-line-interface.md#http-server) `http-port` \(default value `9650`\).
+* `http-port` is the port the node listens on for HTTP calls. This is specified by [command-line argument](../references/command-line-interface.md#http-server) `http-port` (default value `9650`).
 
 For example, the base URL might look like this: `127.0.0.1:9650`.
 
@@ -54,8 +54,8 @@ curl -X POST --data '{
 }' -H 'content-type:application/json;' 127.0.0.1:9650/ext/bc/X
 ```
 
-* `jsonrpc` specifies the version of the JSON RPC protocol. \(In practice is always 2.0\)
-* `method` specifies the service \(`avm`\) and method \(`getTxStatus`\) that we want to invoke.
+* `jsonrpc` specifies the version of the JSON RPC protocol. (In practice is always 2.0)
+* `method` specifies the service (`avm`) and method (`getTxStatus`) that we want to invoke.
 * `params` specifies the arguments to the method.
 * `id` is the ID of this request. Request IDs should be unique.