fix: lint/links

specs/BlockchainLayer/EpochAndStaking/EpochManager.md

@@ -1,11 +1,12 @@
-<!-- # EpochManager -->
+# EpochManager
 
 ## Finalizing an epoch
 
 At the last block of epoch `T`, `EpochManager` computes `EpochInfo` for epoch `T+2`, which
 is defined by `EpochInfo` for `T+1` and the information aggregated from blocks of epoch `T`.
 
 `EpochInfo` is all the information that `EpochManager` stores for the epoch, which is:
+
 - `epoch_height`: epoch height (`T+2`)
 - `validators`: the list of validators selected for epoch `T+2`
 - `validator_to_index`: Mapping from account id to index in `validators`
@@ -21,51 +22,58 @@ is defined by `EpochInfo` for `T+1` and the information aggregated from blocks o
 - `protocol_version`: TODO
 
 Aggregating blocks of the epoch computes the following sets:
+
 - `block_stats`/`chunk_stats`: uptime statistics in the form of `produced` and `expected` blocks/chunks for each validator of `T`
 - `proposals`: stake proposals made in epoch `T`. If an account made multiple proposals, the last one is used.
 - `slashes`: see [Slash set](#slash-set)
 
 ### Slash set
+
 NOTE: slashing is currently disabled. The following is the current design, which can change.
 
 Slash sets are maintained on block basis. If a validator gets slashed in epoch `T`, subsequent blocks of epochs `T` and 
 `T+1` keep it in their slash sets. At the end of epoch `T`, the slashed validator is also added to `kickout[T+2]`.
 Proposals from blocks in slash sets are ignored.
 
 It's kept in the slash set (and kickout sets) for two or three epochs depending on whether it was going to be a validator in `T+1`:
+
 - Common case: `v` is in `validators[T]` and in `validators[T+1]`
-   - proposals from `v` in `T`, `T+1` and `T+2` are ignored
-   - `v` is added to `kickout[T+2]`, `kickout[T+3]` and `kickout[T+4]`  as slashed
-   - `v` can stake again starting with the first block of `T+3`.
+  - proposals from `v` in `T`, `T+1` and `T+2` are ignored
+  - `v` is added to `kickout[T+2]`, `kickout[T+3]` and `kickout[T+4]`  as slashed
+  - `v` can stake again starting with the first block of `T+3`.
 - If `v` is in `validators[T]` but not in `validators[T+1]` (e.g. if it unstaked in `T-1`)
-   - proposals from `v` in `T` and `T+1` are ignored
-   - `v` is added to `kickout[T+2]` and `kickout[T+3]` as slashed
-   - `v` can make a proposal in `T+2` to become a validator in `T+4`
+  - proposals from `v` in `T` and `T+1` are ignored
+  - `v` is added to `kickout[T+2]` and `kickout[T+3]` as slashed
+  - `v` can make a proposal in `T+2` to become a validator in `T+4`
 - If `v` is in `validators[T-1]` but not in `validators[T]` (e.g. did slashable behavior right before rotating out)
-    - proposals from `v` in `T` and `T+1` are ignored
-    - `v` is added to `kickout[T+2]` and `kickout[T+3]` as slashed
-    - `v` can make a proposal in `T+2` to become a validator in `T+4`
+  - proposals from `v` in `T` and `T+1` are ignored
+  - `v` is added to `kickout[T+2]` and `kickout[T+3]` as slashed
+  - `v` can make a proposal in `T+2` to become a validator in `T+4`
 
 ## Computing EpochInfo
 
 ### Kickout set
+
 `kickout[T+2]` contains validators of epoch `T+1` that stop being validators in `T+2`, and also accounts that are not
 necessarily validators of `T+1`, but are kept in slashing sets due to the rule described [above](#slash-set).
 
 `kickout[T+2]` is computed the following way:
+
 1. `Slashed`: accounts in the slash set of the last block in `T`
 2. `Unstaked`: accounts that remove their stake in epoch `T`, if their stake is non-zero for epoch `T+1`
 3. `NotEnoughBlocks/NotEnoughChunks`: For each validator compute the ratio of blocks produced to expected blocks produced (same with chunks produced/expected).
-   If the percentage is below `block_producer_kickout_threshold` (`chunk_producer_kickout_threshold`), the validator is kicked out.
-    - Exception: If all validators of `T` are either in `kickout[T+1]` or to be kicked out, we don't kick out the
-      validator with the maximum number of blocks produced. If there are multiple, we choose the one with
-      lowest validator id in the epoch.
+  If the percentage is below `block_producer_kickout_threshold` (`chunk_producer_kickout_threshold`), the validator is kicked out.
+  - Exception: If all validators of `T` are either in `kickout[T+1]` or to be kicked out, we don't kick out the
+    validator with the maximum number of blocks produced. If there are multiple, we choose the one with
+    lowest validator id in the epoch.
 4. `NotEnoughStake`: computed after validator selection. Accounts who have stake in epoch `T+1`, but don't meet stake threshold for epoch `T+2`.
 5. `DidNotGetASeat`: computed after validator selection. Accounts who have stake in epoch `T+1`, meet stake threshold for epoch `T+2`, but didn't get any seats.
 
 ### Processing proposals
+
 The set of proposals is processed by the validator selection algorithm, but before that, the set of proposals is adjusted
 the following way:
+
 1. If an account is in the slash set as of the end of `T`, or gets kicked out for `NotEnoughBlocks/NotEnoughChunks` in epoch `T`,
   its proposal is ignored.
 3. If a validator is in `validators[T+1]`, and didn't make a proposal, add an implicit proposal with its stake in `T+1`.
@@ -76,4 +84,5 @@ The adjusted set of proposals is used to compute the seat price, and determine `
 `chunk_producers_settlement`sets. This algorithm is described in [Economics](../../Economics/Economic.md#validator-selection).
 
 ### Validator reward
+
 Rewards calculation is described in the [Economics](../../Economics/Economic.md#rewards-calculation) section.

specs/BlockchainLayer/EpochAndStaking/README.md

@@ -1,4 +1,5 @@
-# Epochs and staking
+# Epochs and Staking
+
 - [Epoch](Epoch.md)
 - [EpochManager](EpochManager.md)
 - [Staking](Staking.md)

specs/BlockchainLayer/EpochAndStaking/Staking.md

@@ -1,6 +1,7 @@
 # Staking and slashing
 
 ## Stake invariant
+
 `Account` has two fields representing its tokens: `amount` and `locked`. `amount + locked` is the total number of
 tokens an account has: locking/unlocking actions involve transferring balance between the two fields, and slashing
 is done by subtracting from the `locked` value.
@@ -14,6 +15,7 @@ equal to the maximum of the last three stakes and the highest proposal in the cu
 
 
 ### Returning stake
+
 `locked` is the number of tokens locked for staking, it's computed the following way:
 - initially it's the value in genesis or `0` for new accounts
 - on a staking proposal with a value higher than `locked`, it increases to that value
@@ -24,5 +26,6 @@ equal to the maximum of the last three stakes and the highest proposal in the cu
     4. change `locked` to the resulting value (and update `amount` so that `amount + locked` stays the same)
 
 ### Slashing
+
 TODO.
 

specs/DataStructures/Account.md

@@ -162,7 +162,7 @@ Total account balance consists of unlocked balance and locked balance.
 Unlocked balance is tokens that the account can use for transaction fees, transfers staking and other operations.
 
 Locked balance is the tokens that are currently in use for staking to be a validator or to become a validator.
-Locked balance may become unlocked at the beginning of an epoch. See [Staking](../BlockchainLayer/EpochManager/Staking.md) for details.
+Locked balance may become unlocked at the beginning of an epoch. See [Staking](../BlockchainLayer/EpochAndStaking/Staking.md) for details.
 
 #### Contracts
 

specs/Standards/StorageManagement.md

@@ -274,12 +274,12 @@ Note that applications will probably want to avoid this situation in the first p
 
 Assumption: Alice has more deposited than she is using.
 
-#### High-level explanation
+##### High-level explanation
 
 1. Alice views her storage balance and sees that she has extra.
 2. Alice withdraws her excess deposit.
 
-#### Technical calls
+##### Technical calls
 
 1. Alice queries `social::storage_balance_of({ "account_id": "alice" })`. With NEAR CLI:
 
@@ -307,14 +307,14 @@ Assumption: Alice has more deposited than she is using.
 
 ## Reference-level explanation
 
-#### NOTES:
+#### NOTES
 
 - All amounts, balances and allowance are limited by `U128` (max value 2<sup>128</sup> - 1).
 - This storage standard uses JSON for serialization of arguments and results.
 - Amounts in arguments and results are serialized as Base-10 strings, e.g. `"100"`. This is done to avoid JSON limitation of max integer value of 2<sup>53</sup>.
 - To prevent the deployed contract from being modified or deleted, it should not have any access keys on its account.
 
-#### Interface:
+##### Interface
 
 ```ts
 // The structure that will be returned for the methods: