fix: bild

specs/BlockchainLayer/EpochAndStaking/EpochManager.md

@@ -81,8 +81,8 @@ the following way:
   then its reward for epoch `T` is automatically added to the proposal.
 
 The adjusted set of proposals is used to compute the seat price, and determine `validators`,`block_producers_settlement`,
-`chunk_producers_settlement`sets. This algorithm is described in [Economics](../../Economics/Economic.md#validator-selection).
+`chunk_producers_settlement`sets. This algorithm is described in [Economics](/Economics/Economic#validator-selection).
 
 ### Validator reward
 
-Rewards calculation is described in the [Economics](../../Economics/Economic.md#rewards-calculation) section.
+Rewards calculation is described in the [Economics](/Economics/Economic#validator-rewards-calculation) section.

specs/DataStructures/AccessKey.md

@@ -15,7 +15,7 @@ pub struct AccessKey {
 }
 ```
 
-There are 2 types of `AccessKeyPermission` in NEAR currently: `FullAccess` and `FunctionCall`. `FullAccess` grants permissions to issue any action on the account. This includes [DeployContract](../RuntimeSpec/Actions.md#DeployContractAction), [Transfer](../RuntimeSpec/Actions.md#TransferAction) tokens, call functions [FunctionCall](../RuntimeSpec/Actions.md#FunctionCallAction), [Stake](../RuntimeSpec/Actions.md#StakeAction) and even permission to delete the account [DeleteAccountAction](../RuntimeSpec/Actions.md#DeleteAccountAction). `FunctionCall` on the other hand, **only** grants permission to call any or a specific set of methods on one given contract. It has an allowance of $NEAR that can be spent on **GAS and transaction fees only**. Function call access keys **cannot** be used to transfer $NEAR.
+There are 2 types of `AccessKeyPermission` in NEAR currently: `FullAccess` and `FunctionCall`. `FullAccess` grants permissions to issue any action on the account. This includes [DeployContract](../RuntimeSpec/Actions#deploycontractaction), [Transfer](../RuntimeSpec/Actions#transferaction) tokens, call functions [FunctionCall](../RuntimeSpec/Actions#functioncallaction), [Stake](../RuntimeSpec/Actions#stakeaction) and even permission to delete the account [DeleteAccountAction](../RuntimeSpec/Actions#deleteaccountaction). `FunctionCall` on the other hand, **only** grants permission to call any or a specific set of methods on one given contract. It has an allowance of $NEAR that can be spent on **GAS and transaction fees only**. Function call access keys **cannot** be used to transfer $NEAR.
 
 ```rust
 pub enum AccessKeyPermission {
@@ -26,7 +26,7 @@ pub enum AccessKeyPermission {
 
 ## AccessKeyPermission::FunctionCall
 
-Grants limited permission to make [FunctionCall](../RuntimeSpec/Actions.md#FunctionCall) to a specified `receiver_id` and methods of a particular contract with a limit of allowed balance to spend.
+Grants limited permission to make [FunctionCall](../RuntimeSpec/Actions#functioncallaction) to a specified `receiver_id` and methods of a particular contract with a limit of allowed balance to spend.
 
 ```rust
 pub struct FunctionCallPermission {

specs/NetworkSpec/NetworkSpec.md

@@ -16,9 +16,9 @@ It is expected that a node periodically requests a list of peers from its neighb
 
 ### Handshakes
 
-To establish a new connections between pair of nodes, they will follow the following protocol. Node A open a connection with node B and sends a [Handshake](Messages.md#Handshake) to it. If handshake is valid (see reasons to [decline the handshake](#Decline-handshake)) then node B will proceed to send [Handshake](Messages.md#Handshake) to node A. After each node accept a handshake it will mark the other node as an active connection, until one of them stop the connection.
+To establish a new connections between pair of nodes, they will follow the following protocol. Node A open a connection with node B and sends a [Handshake](Messages.md#handshake) to it. If handshake is valid (see reasons to [decline the handshake](#decline-handshake)) then node B will proceed to send [Handshake](Messages.md#handshake) to node A. After each node accept a handshake it will mark the other node as an active connection, until one of them stop the connection.
 
-[Handshake](Messages.md#Handshake) contains relevant information about the node, the current chain and information to create a new edge between both nodes.
+[Handshake](Messages.md#handshake) contains relevant information about the node, the current chain and information to create a new edge between both nodes.
 
 #### Decline handshake
 
@@ -29,7 +29,7 @@ When a node receives a handshake from other node it will decline this connection
 
 #### Edge
 
-Edges are used to let other nodes in the network know that there is currently an active connection between a pair of nodes. See the definition of [this data structure](Messages.md#Edge).
+Edges are used to let other nodes in the network know that there is currently an active connection between a pair of nodes. See the definition of [this data structure](Messages.md#edge).
 
 If the nonce of the edge is odd, it denotes an `Added` edge, otherwise it denotes a `Removed` edge. Each node should keep track of the nonce used for edges between every pair of nodes. Peer C believes that the peers A and B are currently connected if and only if the edge with the highest nonce known to C for them has an odd nonce.
 

specs/NetworkSpec/RoutingTableExchangeAlgorithm.md

@@ -24,8 +24,8 @@ An overview of different `Routing Graph Reconciliation` algorithms can be a foun
 
 The process of exchanging `routing tables` involves exchanging edges between a pair of nodes.
 For given nodes `A`, `B`, that involves adding edges which `A` has, but `B` doesn't and vice-versa.
-For each connection we create a data structure [IbfSet](#IbfSet).
-It stores `Inverse Bloom Filters` [Ibf](#Ibf) of powers of `2^k` for `k` in range `10..17`.
+For each connection we create a data structure [IbfSet](#ibfset).
+It stores `Inverse Bloom Filters` [Ibf](#ibf) of powers of `2^k` for `k` in range `10..17`.
 This allows us to recover around `2^17 / 1.3` edges with `99%` probability according to [Efficient Set Reconciliation without Prior Context](https://www.ics.uci.edu/~eppstein/pubs/EppGooUye-SIGCOMM-11.pdf).
 Otherwise, we do full routing table exchange.
 
@@ -95,8 +95,8 @@ pub struct RoutingSyncV2 {
 - `requested_edges` - list of hashes of edges peer want to get
 - `done` - true if it's the last message in synchronization
 
+## IbfSet
 
-# IbfSet
 Structure used to represent set of `Inverse Bloom Filters` for given peer.
 ```rust
 pub struct IbfSet<T: Hash + Clone> {
@@ -113,7 +113,7 @@ pub struct IbfSet<T: Hash + Clone> {
   copies of given edge.
 - `hasher` - hashing function
 
-# Ibf
+## Ibf
 Structure representing Reverse Bloom Filter.
 ```rust
 pub struct Ibf {
@@ -128,7 +128,8 @@ pub struct Ibf {
 - `seed` - seed of each inverse bloom filter
 - `hasher` - hashing function
 
-# IbfElem
+## IbfElem
+
 Element of bloom filter
 ```rust
 pub struct IbfElem {
@@ -139,7 +140,7 @@ pub struct IbfElem {
 - `xor_element` - xor of hashes of edges stored in given box
 - `xor_hash` - xor of hashes of hashes of edges stored in give n box
 
-# Routing table exchange
+## Routing table exchange
 
 The process of exchanging routing tables involves multiple steps.
 It could be reduced if needed by adding an estimator of how many edges differ, but it's not implemented for sake of simplicity.

specs/Proposals/0005-access-keys.md

@@ -252,7 +252,7 @@ The suggestion from @nearmax:
 We need to spec out here how transactions from different access keys are going to be ordered with respect to each other. For example:
 3 access keys (A,B,C) issue 3 transactions each:
 A1, A2, A3; B1,B2,B3; C1, C2, C3;
-All these transactions operate on the same state so they need to have an order. First transaction to execute is one of {A1,B1,C1} that has lowest hash, let's say it is B1. Second transaction to execute is one of {A1,B2,C1} with lowest hash, etc.
+All these transactions operate on the same state so they need to have an order. First transaction to execute is one of \{A1,B1,C1} that has lowest hash, let's say it is B1. Second transaction to execute is one of \{A1,B2,C1} with lowest hash, etc.
 "
 
 We should also restrict the nonce of the next transaction to be exactly the previous nonce incremented by 1.

specs/RuntimeSpec/AccountStorage.md

@@ -7,7 +7,7 @@ There is a definition of all the keys and values we store in the Account Storage
 *key = `receiver_id: String`,`data_id: CryptoHash`*
 *value = `Option<Vec<u8>>`*
 
-Runtime saves incoming data from [DataReceipt](Receipts.md#data) until every [input_data_ids](Receipts.md#input_data_ids) in [postponed receipt](#Postponed-receipts) [ActionReceipt](Receipts.md#ActionReceipt) for `receiver_id` account is satisfied.
+Runtime saves incoming data from [DataReceipt](Receipts.md#data) until every [input_data_ids](Receipts.md#input_data_ids) in [postponed receipt](#postponed-receipts) [ActionReceipt](Receipts.md#actionreceipt) for `receiver_id` account is satisfied.
 
 ## Postponed receipts
 
@@ -16,4 +16,4 @@ For each awaited `DataReceipt` we store
 *key = `receiver_id`,`data_id`*
 *value = `receipt_id`*
 
-Runtime saves incoming [ActionReceipt](Receipts.md#ActionReceipt) until all ``
+Runtime saves incoming [ActionReceipt](Receipts.md#actionreceipt) until all ``

specs/RuntimeSpec/ApplyingChunk.md

@@ -38,4 +38,4 @@ Please note that local receipts are receipts generated by transaction where rece
 
 ## Delayed receipts
 
-In each block we have maximal amount of Gas we can use to process receipts and migrations, currently 1000 TGas. If any incoming or local receipts are not processed due to lack of remaining Gas, they are stored in state with key <pre>TrieKey::DelayedReceipt { id }</pre> where id is unique index for each shard, assigned consecutively. Currently sender does not need to stake any tokens to store delayed receipts. State also contains special key <pre>TrieKey::DelayedReceiptIndices</pre> where first and last ids of delayed receipts not yet processed are stored.
+In each block we have maximal amount of Gas we can use to process receipts and migrations, currently 1000 TGas. If any incoming or local receipts are not processed due to lack of remaining Gas, they are stored in state with key <pre>TrieKey::DelayedReceipt \{ id }</pre> where id is unique index for each shard, assigned consecutively. Currently sender does not need to stake any tokens to store delayed receipts. State also contains special key <pre>TrieKey::DelayedReceiptIndices</pre> where first and last ids of delayed receipts not yet processed are stored.

specs/RuntimeSpec/Fees/Fees.md

@@ -32,7 +32,7 @@ the newly created receipt is executed on the receiver's account.
 
 ## Fees for actions
 
-Every [`Action`](/RuntimeSpec/Actions.md#actions) has a corresponding Fee(s) described in the config [`action_creation_config`](/GenesisConfig/RuntimeFeeConfig/ActionCreationConfig.md).
+Every [`Action`](/RuntimeSpec/Actions) has a corresponding Fee(s) described in the config [`action_creation_config`](/GenesisConfig/RuntimeFeeConfig/ActionCreationConfig.md).
 Similar to a receipt creation costs, the `send` gas is burned when an action is added to a receipt to be sent, and the `execution` gas is only charged, but not burned.
 
 Fees are either a base fee or a fee per byte of some data within the action.
@@ -49,16 +49,16 @@ Here is the list of actions and their corresponding fees:
     - the fee per byte of method name string and per byte of arguments with the fee [`function_call_cost_per_byte`](/GenesisConfig/RuntimeFeeConfig/ActionCreationConfig.md#function_call_cost_per_byte).
     To compute the number of bytes for a function call action `function_call_action` use `function_call_action.method_name.as_bytes().len() + function_call_action.args.len()`
 - [Transfer](/RuntimeSpec/Actions.md#transferaction) uses one of the following fees:
-    - if the `receiver_id` is an [Implicit Account ID](/DataStructures/Account.md#implicit-account-ids), then a sum of base fees is used:
+    - if the `receiver_id` is an [Implicit Account ID](/DataStructures/Account#near-implicit-account-id), then a sum of base fees is used:
         - the create account base fee [`create_account_cost`](/GenesisConfig/RuntimeFeeConfig/ActionCreationConfig.md#create_account_cost)
         - the transfer base fee [`transfer_cost`](/GenesisConfig/RuntimeFeeConfig/ActionCreationConfig.md#transfer_cost)
         - the add full access key base fee [`add_key_cost.full_access_cost`](/GenesisConfig/RuntimeFeeConfig/AccessKeyCreationConfig.md#full_access_cost)
-    - if the `receiver_id` is NOT an [Implicit Account ID](/DataStructures/Account.md#implicit-account-ids), then only the base fee is used:
+    - if the `receiver_id` is NOT an [Implicit Account ID](/DataStructures/Account.md#near-implicit-account-id), then only the base fee is used:
         - the transfer base fee [`transfer_cost`](/GenesisConfig/RuntimeFeeConfig/ActionCreationConfig.md#transfer_cost)
 - [Stake](/RuntimeSpec/Actions.md#stakeaction) uses
     - the base fee [`stake_cost`](/GenesisConfig/RuntimeFeeConfig/ActionCreationConfig.md#stake_cost)
 - [AddKey](/RuntimeSpec/Actions.md#addkeyaction) uses one of the following fees:
-    - if the access key is [`AccessKeyPermission::FullAccess`](/DataStructures/AccessKey.md#access-keys) the base fee is used
+    - if the access key is [`AccessKeyPermission::FullAccess`](/DataStructures/AccessKey) the base fee is used
         - the add full access key base fee [`add_key_cost.full_access_cost`](/GenesisConfig/RuntimeFeeConfig/AccessKeyCreationConfig.md#full_access_cost)
     - if the access key is [`AccessKeyPermission::FunctionCall`](/DataStructures/AccessKey.md#accesskeypermissionfunctioncall) the sum of the fees is used
         - the add function call permission access key base fee [`add_key_cost.function_call_cost`](/GenesisConfig/RuntimeFeeConfig/AccessKeyCreationConfig.md#full_access_cost)

specs/RuntimeSpec/FunctionCall.md

@@ -19,15 +19,15 @@ ActionReceipt {
 ### `input_data_ids` to `PromiseResult`s
 
 `ActionReceipt.input_data_ids` must be satisfied before execution (see
-[Receipt Matching](#receipt-matching)). Each of `ActionReceipt.input_data_ids` will be converted to
+[Receipt Matching](/RuntimeSpec/Receipts#receipt-matching)). Each of `ActionReceipt.input_data_ids` will be converted to
 the `PromiseResult::Successful(Vec<u8>)` if `data_id.data` is `Some(Vec<u8>)` otherwise if
 `data_id.data` is `None` promise will be `PromiseResult::Failed`.
 
 ## Input
 
 The `FunctionCall` executes in the `receiver_id` account environment.
 
-- a vector of [Promise Results](#promise-results) which can be accessed by a `promise_result`
+- a vector of [Promise Results](#input_data_ids-to-promiseresults) which can be accessed by a `promise_result`
   import [PromisesAPI](Components/BindingsSpec/PromisesAPI.md) `promise_result`)
 - the original Transaction `signer_id`, `signer_public_key` data from the ActionReceipt (e.g.
   `method_name`, `args`, `predecessor_id`, `deposit`, `prepaid_gas` (which is `gas` in
@@ -43,7 +43,7 @@ API](Components/BindingsSpec/ContextAPI.md) and [Trie](Components/BindingsSpec/T
 
 In order to implement this action, the runtime will:
 
-- load the contract code from the `receiver_id` [account](../DataStructures/Account.md#account)’s
+- load the contract code from the `receiver_id` [account](../DataStructures/Account#account)’s
   storage;
 - parse, validate and instrument the contract code (see [Preparation](./Preparation.md));
 - optionally, convert the contract code to a different executable format;
@@ -53,7 +53,7 @@ In order to implement this action, the runtime will:
   that specified in the `FunctionCall.method_name` field.
 
 Note that some of these steps may be executed during the
-[`DeployContractAction`](./Actions.md#DeployContractAction) instead. This is largely an
+[`DeployContractAction`](./Actions.md#deploycontractaction) instead. This is largely an
 optimization of the `FunctionCall` gas fee, and must not result in an observable behavioral
 difference of the `FunctionCall` action.
 
@@ -78,7 +78,7 @@ The output of the `FunctionCall`:
 - `logs` - during contract execution, utf8/16 string log records could be created. Logs are not
   persistent currently.
 - `new_receipts` - new `ActionReceipts` created during the execution. These receipts are going to
-  be sent to the respective `receiver_id`s (see [Receipt Matching explanation](#receipt-matching))
+  be sent to the respective `receiver_id`s (see [Receipt Matching explanation](/RuntimeSpec/Receipts#receipt-matching))
 - result could be either [`ReturnData::Value(Vec<u8>)`](#value-result) or
   [`ReturnData::ReceiptIndex(u64)`](#receiptindex-result)`
 

specs/RuntimeSpec/Preparation.md

@@ -14,8 +14,8 @@ portions of this book is maintained. The non-normative portions of this document
 as such.
 
 [function calls]: ./FunctionCall.md
-[`DeployContractAction`]: ./Actions.md#DeployContractAction
-[`FunctionCallAction`]: ./Actions.md#FunctionCallAction
+[`DeployContractAction`]: ./Actions.md#deploycontractaction
+[`FunctionCallAction`]: ./Actions.md#functioncallaction
 
 ## High level overview