Fix fixable

cli/test/tutorial/docs/tutorial-basics/markdown-features.mdx

@@ -152,4 +152,4 @@ This is <Highlight color="#1877F2">Facebook blue</Highlight> !
 
 ## AddToMetaMaskButton
 
-<AddToMetaMaskButton />
+<AddToMetaMaskButton />

iota/develop/network-token-migration.md

@@ -5,7 +5,7 @@ description:
   into the new Chrysalis network
 ---
 
-# Network Token migration:
+# Network Token migration
 
 ## Why does IOTA migrate tokens?
 

iota/docs/blueprints/data-marketplace/deployment-and-testing.md

@@ -100,7 +100,7 @@ Instead of deploying your own data marketplace, you can test our demo app by add
 5. Extract the content of the archive, and open the folder in a code editor such as [Visual Studio Code](https://code.visualstudio.com/Download) to start working with the script
 
    :::info:
-   Read the` README.md` file before you start using the script.
+   Read the `README.md` file before you start using the script.
    :::
 
    The script is pre-configured to publish data for the selected device. You’ll find the sensor ID and its secret key in the `config.json` file.

iota/docs/chronicle/docs/getting_started.md

@@ -68,7 +68,7 @@ Chronicle uses a [RON](https://github.com/ron-rs/ron) file to store configuratio
 
 ### Running Chronicle
 
-See [Building Chronicle](#Building-Chronicle).
+See [Building Chronicle](#building-chronicle).
 
 ```bash
 cd target/release && cp /path/to/your/config.ron ./

iota/docs/goshimmer/docs/apis/communication.md

@@ -52,7 +52,7 @@ where `:blockID` is the base58 encoded block ID, e.g. 4MSkwAPzGwnjCJmTfbpW4z4GRC
 
 #### Client lib - `GetBlock`
 
-Blocks can be retrieved via `GetBlock(base58EncodedID string) (*jsonmodels.Block, error) `
+Blocks can be retrieved via `GetBlock(base58EncodedID string) (*jsonmodels.Block, error)`
 
 ```go
 block, err := goshimAPI.GetBlock(base58EncodedBlockID)

iota/docs/goshimmer/docs/apis/ledgerstate.md

@@ -14,7 +14,7 @@ keywords:
 
 # Ledgerstate API Methods
 
-## HTTP APIs:
+## HTTP APIs
 
 - [/ledgerstate/addresses/:address](#ledgerstateaddressesaddress)
 - [/ledgerstate/addresses/:address/unspentOutputs](#ledgerstateaddressesaddressunspentoutputs)
@@ -31,7 +31,7 @@ keywords:
 - [/ledgerstate/transactions](#ledgerstatetransactions)
 - [/ledgerstate/addresses/unspentOutputs](#ledgerstateaddressesunspentoutputs)
 
-## Client Lib APIs:
+## Client Lib APIs
 
 - [GetAddressOutputs()](#client-lib---getaddressoutputs)
 - [GetAddressUnspentOutputs()](#client-lib---getaddressunspentoutputs)
@@ -851,7 +851,7 @@ fmt.Println("consensus mana pledgeID:", resp.ConsensusPledgeID)
 | `unlockBlocks`      | []UnlockBlock | The unlock block containing signatures unlocking the inputs or references to previous unlock blocks. |
 | `dataPayload`       | []byte        | The raw data payload that can be attached to the transaction.                                        |
 
-#### Type `Input `
+#### Type `Input`
 
 | Field                | Type               | Description                                                 |
 | :------------------- | :----------------- | :---------------------------------------------------------- |

iota/docs/goshimmer/docs/implementation_design/object_storage.md

@@ -189,6 +189,7 @@ we can start using it for its sole purpose, to actually store and read the parti
 
 - `ForEach` - allows to apply a `Consumer` function for every object residing within the cache and the underlying persistence layer.
   For example, this is how we can count the number of blocks.
+
   ```Go
   blockCount := 0
   blockStorage.ForEach(func(key []byte, cachedObject generic.CachedObject) bool {
@@ -197,9 +198,11 @@ we can start using it for its sole purpose, to actually store and read the parti
         })
   }
   ```
+
 - `Store` - storing an object in the objectStorage. An extended version is method `StoreIfAbsent`
   that stores an object only if it was not stored before and returns boolean indication if the object was stored.
   `ComputeIfAbsent` works similarly but does not access the value log.
+
   ```Go
   cachedBlock := blockStorage.Store(newBlock)
   cachedBlock, stored := blockStorage.StoreIfAbsent(newBlock)

iota/docs/goshimmer/docs/protocol_specification/components/autopeering.md

@@ -159,9 +159,9 @@ The maximum number of neighbors is a parameter of the gossip protocol. This sect
 
 The operations involved during neighbor selection are listed in the following:
 
-1.  Get an up-to-date list of verified and known peers from the _Peer Discovery_ protocol.
-2.  Use [mana rank](#Mana_rank) to filter the previous list to obtain a list of peers to be potential neighbors.
-3.  Use the score function to request/accept neighbors.
+1. Get an up-to-date list of verified and known peers from the _Peer Discovery_ protocol.
+2. Use [mana rank](#Mana_rank) to filter the previous list to obtain a list of peers to be potential neighbors.
+3. Use the score function to request/accept neighbors.
 
 The score between two nodes is measured through the score function _s_, defined by:
 

iota/docs/goshimmer/docs/protocol_specification/components/consensus_mechanism.md

@@ -15,18 +15,18 @@ keywords:
 
 The consensus mechanism is necessary to achieve agreement among the nodes of the network. In case of a double spend, one way to decide which transaction should be considered valid would be to order them and pick the oldest one. However, the Tangle is only partially ordered. To tackle this problem in the context of the Tangle, we have designed an open and leaderless consensus mechanism that utilizes the Tangle as a medium to exchange votes. Any node can add a block to the Tangle, and each block added to the Tangle represents a virtual vote (i.e. there is no additional overhead to communicate votes) to its entire past.
 
-The consensus mechanism can broadly be devided into consensus on two separate entities. On the one hand, we need to resolve any conflicts on the underlying UTXO ledger to prevent double spends. On the other hand, we need to make sure that blocks within the Tangle are not orphaned. Both are simply derived by observing the Tangle and objectively keeping track of [Approval Weight (AW)](#Approval-Weight-AW) with cMana (more specifically [active cMana](#Active-cMana)) as a Sibyl protection. Once a [conflict](ledgerstate.md#conflicts) (or block) reaches a certain AW threshold, an application can consider it as _confirmed_. To simplify this notion we introduce [Grades of Finality (GoF)](#Grades-of-Finality-GoF) where a higher GoF represents a higher confidence.
+The consensus mechanism can broadly be devided into consensus on two separate entities. On the one hand, we need to resolve any conflicts on the underlying UTXO ledger to prevent double spends. On the other hand, we need to make sure that blocks within the Tangle are not orphaned. Both are simply derived by observing the Tangle and objectively keeping track of [Approval Weight (AW)](#approval-weight-aw) with cMana (more specifically [active cMana](#active-cmana)) as a Sibyl protection. Once a [conflict](ledgerstate.md#conflicts) (or block) reaches a certain AW threshold, an application can consider it as _confirmed_. To simplify this notion we introduce [Grades of Finality (GoF)](#grades-of-finality-gof) where a higher GoF represents a higher confidence.
 
 | Name                | Component   | Initial/local opinion             | Consensus      | Comparable blockchain mechanism for voting/finality |
 | ------------------- | ----------- | --------------------------------- | -------------- | --------------------------------------------------- |
 | voting on conflicts | UTXO ledger | OTV/FPCS                          | conflict/tx AW | longest chain rule                                  |
 | finality of blocks  | Tangle      | inclusion score via tip selection | block AW       | x block rule                                        |
 
-On an abstract level, a node can be seen as a replicated state machine, just following whatever it receives through the Tangle, and, in case of blocks containing transactions, modifying the UTXO ledger. Only when a node wants to issue a block (read as: _cast a vote_) it needs to evaluate its own local opinion via [modular conflict selection function](#Modular-Conflict-Selection-Function). This decoupling of coming to consensus and setting the initial opinion allows for great flexibility and separation of concerns.
+On an abstract level, a node can be seen as a replicated state machine, just following whatever it receives through the Tangle, and, in case of blocks containing transactions, modifying the UTXO ledger. Only when a node wants to issue a block (read as: _cast a vote_) it needs to evaluate its own local opinion via [modular conflict selection function](#modular-conflict-selection-function). This decoupling of coming to consensus and setting the initial opinion allows for great flexibility and separation of concerns.
 
 ## Approval Weight (AW)
 
-Approval weight represents the [weight](#active-consensus-mana) of conflicts (and blocks), similar to the longest chain rule in Nakamoto consensus. However, instead of selecting a leader based on a puzzle (PoW) or stake (PoS), it allows every node to express its opinion by simply issuing any block and attaching it in a part of the Tangle it _likes_ (based on its initial opinion on blocks and possibly utilizing the [like switch](#Like-Switch) to express its opinion on conflicts).
+Approval weight represents the [weight](#active-consensus-mana) of conflicts (and blocks), similar to the longest chain rule in Nakamoto consensus. However, instead of selecting a leader based on a puzzle (PoW) or stake (PoS), it allows every node to express its opinion by simply issuing any block and attaching it in a part of the Tangle it _likes_ (based on its initial opinion on blocks and possibly utilizing the [like switch](#like-switch) to express its opinion on conflicts).
 
 It is important to note that tracking of AW for conflicts and markers/blocks is orthogonal. Thus, a block can reach a high AW whereas its contained payload, e.g., a transaction being a double spend, does not reach any AW on conflict/UTXO level.
 
@@ -42,7 +42,7 @@ Approval weight AW increases because of voters (nodes) that cast votes for confl
 
 #### Conflicts
 
-Tracking voters of [conflicts](ledgerstate.md#conflicts) is an effective way of objective virtual voting. It allows nodes to express their opinion simply by attaching a statement to a conflict they like (see [like switch](#Like-Switch)). This statement needs to propagate down the conflict DAG, adding support to each of the conflict's parents. In case a voter changes their opinion, support needs to be revoked from all conflicting conflicts and their children. Thus, a node can only support one conflict of a conflict set.
+Tracking voters of [conflicts](ledgerstate.md#conflicts) is an effective way of objective virtual voting. It allows nodes to express their opinion simply by attaching a statement to a conflict they like (see [like switch](#like-switch)). This statement needs to propagate down the conflict DAG, adding support to each of the conflict's parents. In case a voter changes their opinion, support needs to be revoked from all conflicting conflicts and their children. Thus, a node can only support one conflict of a conflict set.
 
 To make this more clear consider the following example:
 
@@ -123,7 +123,7 @@ GoF | AW
 2 | >= 0.45
 3 | >= 0.67
 
-These thresholds play a curcial role in the safety vs. liveness of the protocol, together with the exact workings of [active cMana](#Active-cMana). We are currently investigating them with in-depth simulations.
+These thresholds play a curcial role in the safety vs. liveness of the protocol, together with the exact workings of [active cMana](#active-cmana). We are currently investigating them with in-depth simulations.
 
 - The higher the AW threshold the more voters a conflict or block will need to reach a certain GoF -> more secure but higher confirmation time.
 - As a consequence of the above point, TangleTime will be tougher to advance; making the cMana window more likely to get stuck and confirmations to halt forever.

iota/docs/goshimmer/docs/protocol_specification/components/mana.md

@@ -49,10 +49,10 @@ From the pledged mana of a transaction, a node can calculate locally the `Base M
 A `Base Mana Vector` consists of Base Mana 1 and Base Mana 2 and their respective `Effective Base Mana`.
 Given a value transaction, Base Mana 1 and Base Mana 2 are determined as follows:
 
-1.  Base Mana 1 is revoked from the node that created the output(s) used as input(s) in the transaction, and is pledged to
+1. Base Mana 1 is revoked from the node that created the output(s) used as input(s) in the transaction, and is pledged to
     the node creating the new output(s). The amount of `Base Mana 1` revoked and pledged is equal to the balance of the
     input.
-2.  Base Mana 2 is freshly created at the issuance time of the transaction, awarded to the node, but decays with time.
+2. Base Mana 2 is freshly created at the issuance time of the transaction, awarded to the node, but decays with time.
     The amount of `Base Mana 2` pledged is determined with `Pending Mana` concept: funds sitting at an address generate
     `pending mana` that grows over time, but bounded.
     - `Mana_pending = (alpha*S)/gamma*(1-e^(-gamma*t))`, where `alpha` and `gamma` are chosen parameters, `S` is the amount
@@ -121,17 +121,17 @@ The first implementation of mana in GoShimmer will:
 In this section, detailed GoShimmer implementation design considerations will be outlined about the mana module.
 In short, changes can be classified into 3 categories:
 
-1.  Transaction related changes,
-2.  Mana module functionality,
-3.  and related tools/utilities, such as API, visualization, analytics.
+1. Transaction related changes,
+2. Mana module functionality,
+3. and related tools/utilities, such as API, visualization, analytics.
 
 ### Transaction
 
 As described above, 3 new fields will be added to the transaction layout:
 
-1.  `Timestamp` time.time
-2.  `AccessManaNodeID` []bytes
-3.  `ConsensusManaNodeID` []bytes
+1. `Timestamp` time.time
+2. `AccessManaNodeID` []bytes
+3. `ConsensusManaNodeID` []bytes
 
 By adding these fields to the signed transaction, `valuetransfers/packages/transaction` should be modified.
 
@@ -153,13 +153,13 @@ Node owners are free to choose to whom they pledge mana to with the transaction,
 lets the client know, what `AccessManaNodeID` and `ConsensusManaNodeID` are allowed. This could be a new API endpoint
 that works like this:
 
-1.  Client asks node what nodeIDs can be included for pledging a certain type (access, consensus) mana.
-2.  Node answers with either:
+1. Client asks node what nodeIDs can be included for pledging a certain type (access, consensus) mana.
+2. Node answers with either:
 
 - Don't care. Any node IDs are valid.
 - List of nodeIDs that are allowed for each type.
 
-3.  If a client sends back the transaction with invalid or empty mana fields, the transaction is considered invalid.
+3. If a client sends back the transaction with invalid or empty mana fields, the transaction is considered invalid.
 
 This way node owners can decide who their transactions are pledging mana to. It could be only their node, or they could
 provide mana pledging as a service. They could delegate access mana to others, but hold own to consensus mana, or the
@@ -222,7 +222,7 @@ type BaseManaVector struct {
 
 - `BookMana(transaction)`: Book mana of a transaction. Trigger `ManaBooked` event. Note, that this method updates
   `BaseMana` with respect to time and to new `Base Mana 1` and `Base Mana 2` values.
-- `GetWeightedMana(nodeID, weight) mana`: Return `weight` \*` Effective Base Mana 1` + (1-`weight`)+`Effective Base Mana 2`.
+- `GetWeightedMana(nodeID, weight) mana`: Return `weight` \* `Effective Base Mana 1` + (1-`weight`)+`Effective Base Mana 2`.
   `weight` is a number in [0,1] interval. Notice, that `weight` = 1 results in only returning `Effective Base Mana 1`,
   and the other way around. Note, that this method also updates `BaseMana` of the node with respect to time.
 - `GetMana(nodeID) mana`: Return 0.5*`Effective Base Mana 1` + 0.5*`Effective Base Mana 2` of a particular node. Note, that
@@ -243,8 +243,8 @@ type BaseManaVector struct {
 
 There are two cases when the values within `Base Mana Vector` are updated:
 
-1.  A confirmed transaction pledges mana.
-2.  Any module accesses the `Base Mana Vector`, and hence its values are updated with respect to `access time`.
+1. A confirmed transaction pledges mana.
+2. Any module accesses the `Base Mana Vector`, and hence its values are updated with respect to `access time`.
 
 First, let's explore the former.
 
@@ -587,8 +587,8 @@ is visualized for a node:
 
 There are two ways to visualize mana in GoShimmer:
 
-1.  Node Local Dashboard
-2.  Grafana Dashboard
+1. Node Local Dashboard
+2. Grafana Dashboard
 
 While `Local Dashboard` gives flexibility in what and how to visualize, `Grafana Dashboard` is better at storing historic
 data but can only visualize time series. Therefore, both of these ways will be utilized, depending on which suits the best.

iota/docs/goshimmer/docs/protocol_specification/components/overview.md

@@ -103,8 +103,8 @@ After the objective checks, the following subjective checks are done:
 
 At this point, the missing steps are the most computationally expensive:
 
-7.  Inputs' conflicting conflicts check: it checks if the conflicts of the inputs are conflicting. As in the last step, if the block does not pass this check, the block is marked as `invalid` and not booked. If it passes the check, it goes to the next step.
-8.  Conflict check: it checks if the inputs are conflicting with an unconfirmed transaction. In this step, the conflict to which the block belongs is computed. In both cases (passing the check or not), the transaction is booked into the ledger state and the block is booked into the Tangle, but its conflict ID will be different depending on the outcome of the check.
+7. Inputs' conflicting conflicts check: it checks if the conflicts of the inputs are conflicting. As in the last step, if the block does not pass this check, the block is marked as `invalid` and not booked. If it passes the check, it goes to the next step.
+8. Conflict check: it checks if the inputs are conflicting with an unconfirmed transaction. In this step, the conflict to which the block belongs is computed. In both cases (passing the check or not), the transaction is booked into the ledger state and the block is booked into the Tangle, but its conflict ID will be different depending on the outcome of the check.
 
 [![Booker](/img/protocol_specification/booker.png 'Booker')](/img/protocol_specification/booker.png)
 

iota/docs/goshimmer/docs/tooling/evil_spammer.md

@@ -65,7 +65,7 @@ Example usage:
 go run . quick --urls http://localhost:8080,http://localhost:8090 --rate 50 --duration 1m --tu 1s --dbc 100ms
 ```
 
-### Go interactive!
+### Go interactive
 
 Simply run
 
@@ -265,7 +265,7 @@ clients := evilwallet.GetClients(1)
 clients[0].PostTransaction(txC)
 ```
 
-### Compose your own scenario!
+### Compose your own scenario
 
 The most exciting part of evil wallet is to create whatever scenario easily!