Small updates to indexing

pages/en/network/indexing.mdx

@@ -22,7 +22,7 @@ The minimum stake for an Indexer is currently set to 100K GRT.
 
 **Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
 
-### How are rewards distributed?
+### How are indexing rewards distributed?
 
 Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
 
@@ -36,7 +36,7 @@ POIs are used in the network to verify that an Indexer is indexing the subgraphs
 
 Allocations are continuously accruing rewards while they're active and allocated within 28 epochs. Rewards are collected by the Indexers, and distributed whenever their allocations are closed. That happens either manually, whenever the Indexer wants to force close them, or after 28 epochs a Delegator can close the allocation for the Indexer, but this results in no rewards. 28 epochs is the max allocation lifetime (right now, one epoch lasts for ~24h).
 
-### Can pending Indexer rewards be monitored?
+### Can pending indexing rewards be monitored?
 
 The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/master/contracts/rewards/RewardsManager.sol#L317) function that can be used to check the pending rewards for a specific allocation.
 
@@ -543,7 +543,7 @@ The **Indexer CLI** connects to the Indexer agent, typically through port-forwar
 
 - `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
 
-- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additonal argument `--status` can be used to print out all actions of a certain status. 
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additonal argument `--status` can be used to print out all actions of a certain status.
 
 - `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
 
@@ -555,7 +555,7 @@ The **Indexer CLI** connects to the Indexer agent, typically through port-forwar
 
 - `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
 
-- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately 
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
 
 All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
 
@@ -600,6 +600,7 @@ IndexingDecisionBasis {
 ```
 
 Example usage of indexing rule:
+
 ```
 graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
@@ -615,11 +616,12 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
 
 The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed on-chain. The general flow will look like:
+
 - Action added to the queue by the 3rd party optimizer tool or indexer-cli user
 - Indexer can use the `indexer-cli` to view all queued actions
-- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`.  The approve and cancel commands take an array of action ids as input.
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
 - The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
-- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.  
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
 - The indexer can monitor the action queue to see a history of action execution and if needed re-approve and update action items if they failed execution. The action queue provides a history of all actions queued and taken.
 
 Data model:
@@ -672,29 +674,33 @@ indexer indexer actions cancel
 
 indexer indexer actions approve 1 3 5
 
-indexer indexer actions execute approve 
+indexer indexer actions execute approve
 ```
 
 Note that supported action types for allocation management have different input requirements:
-`Allocate` - allocate stake to a specific subgraph deployment
-- required action params:
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - required action params:
     - deploymentID
     - amount
 
-`Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
-- required action params:
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - required action params:
     - allocationID
     - deploymentID
-- optional action params:
+  - optional action params:
     - poi
     - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
 
-`Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
-- required action params:
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - required action params:
     - allocationID
     - deploymentID
     - amount
-- optional action params:
+  - optional action params:
     - poi
     - force (forces using the provided POI even if it doesn’t match what the graph-node provides)