Merge pull request #274 from VaultaFoundation/vaulta

fix for broken links

Author: nsjames

evm/20_smart-contracts/20_migrate-your-smart-contract.md

@@ -100,7 +100,7 @@ into the search field.
 You have successfully deployed your first smart contract to the Vaulta EVM! 🎉
 
 If you already have a front-end application that interacts with your smart contract, you can now point it at the 
-[Vaulta EVM Endpoints](/evm/999_miscellaneous/10_endpoints.md), and it will work as expected.
+[Vaulta EVM Endpoints](../quick-start/endpoints), and it will work as expected.
 
 Make sure you visit the [**Compatibility**](/evm/999_miscellaneous/20_evm-compatibility.md) section to learn about the differences between
 the Vaulta EVM and Ethereum, and how to make sure your web3 application works on the Vaulta EVM as expected.

native/07_node-operation/100_migration-guides/04_upgrade-guide-spring-1-0.md

@@ -3,7 +3,7 @@ title: Spring 1.0 Upgrade Guide
 ---
 
 ## Purpose
-This upgrade guide covers the steps for upgrading a node to Spring v1 from prior Leap versions. The Node Operator's guide [Switching Over To Savanna Consensus Algorithm](https://docs.vaulta.com/docs/latest/node-operation/migration-guides/switch-to-savanna) covers the steps needed to upgrade the consensus algorithm. Node Producers will be interested in [Guide to Managing Finalizer Keys](https://docs.vaulta.com/docs/latest/advanced-topics/managing-finalizer-keys)
+This upgrade guide covers the steps for upgrading a node to Spring v1 from prior Leap versions. The Node Operator's guide [Switching Over To Savanna Consensus Algorithm](https://docs.vaulta.com/docs/latest/node-operation/migration-guides/switch-to-savanna) covers the steps needed to upgrade the consensus algorithm. Node Producers will be interested in [Guide to Managing Finalizer Keys](../../advanced-topics/managing-finalizer-keys)
 
 ### Summary of Changes
 - [Exceeding number of in flight requests or Mb in flight now returns HTTP 503](#updated-error-codes)
@@ -144,5 +144,5 @@ Scripts that move or delete the ‘data’ directory need to protect the finaliz
 - `finalizers-dir` - Specifies the directory path for storing voting history. Node Operators may want to specify a directory outside of their nodeos' data directory, and manage this as distinct file. More information in [Guide to Managing Finalizer Keys](../../../advanced-topics/managing-finalizer-keys).
 
 ### New `vote-threads` Option
-Where there is a block producing node that connects to its peers through an intermediate nodeos, the intermediate nodeos will need to have an integer value greater than 0 for `vote-threads`. The default value for `vote-threads` is 4. When `vote-threads` is not an integer greater than 0, votes are not propagated. See [Voting and Peering](../../../advanced-topics/introduction-finalizers-voting/#voting-and-peering) for more background and recomendations on configuring `vote-threads`.
+Where there is a block producing node that connects to its peers through an intermediate nodeos, the intermediate nodeos will need to have an integer value greater than 0 for `vote-threads`. The default value for `vote-threads` is 4. When `vote-threads` is not an integer greater than 0, votes are not propagated. See [Voting and Peering](../../advanced-topics/introduction-finalizers-voting/#voting-and-peering) for more background and recomendations on configuring `vote-threads`.
 - `vote-threads` - Sets the number of threads to handle voting. The default is sufficient for all known production setups, and the recommendation is to leave this value unchanged.

native/07_node-operation/10_getting-started/30_plugins/chain-api-plugin.md

@@ -7,7 +7,7 @@ See [Chain API Reference](https://docs.vaulta.com/apis/leap/latest/chain.api/).
 
 ## Overview
 
-The `chain_api_plugin` exposes functionality from the [`chain_plugin`](./chain-plugin.md) to the RPC API interface managed by the [`http_plugin`](./http-plugin/index.md).
+The `chain_api_plugin` exposes functionality from the [`chain_plugin`](./chain-plugin.md) to the RPC API interface managed by the [`http_plugin`](./http-plugin).
 
 ## Usage
 

native/07_node-operation/10_getting-started/30_plugins/state-history-plugin.md

@@ -51,9 +51,9 @@ Option (=default) | Description
 
 ## Examples
 
-* [How to replay or resync with full history](../../snapshots#replay--resync-with-full-state-history)
-* [How to create a portable snapshot with full state history](../../snapshots#creating-a-snapshot-with-full-state-history)
-* [How to restore a portable snapshot with full state history](../../snapshots#restoring-a-snapshot-with-full-state-history)
+* [How to replay or resync with full history](../snapshots#replay--resync-with-full-state-history)
+* [How to create a portable snapshot with full state history](../snapshots#creating-a-snapshot-with-full-state-history)
+* [How to restore a portable snapshot with full state history](../snapshots#restoring-a-snapshot-with-full-state-history)
 
 ## Dependencies
 

native/07_node-operation/10_getting-started/40_peering.md

@@ -11,7 +11,7 @@ Vaulta blockchains may consist of one or many nodes. Although a single node can
 Peering allows Vaulta nodes to propagate and synchronize the distributed blockchain state by receiving and relaying blocks and/or transactions to other nodes. Any node that is configured to send and receive data in a peer-to-peer fashion is considered a "peer". This adds redundancy and allows for faster response times to client queries and node requests. Therefore, peering is key to the decentralized operation and incremental growth of the Vaulta blockchain.
 
 > ℹ️ Vaulta Network Protocol  
-Peering is enabled through the Vaulta peer-to-peer (p2p) network protocol and it is what allows the decentralized operation of the blockchain. For more information, check the [Vaulta Network Protocol](../../60_advanced-topics/03_network-peer-protocol.md).
+Peering is enabled through the Vaulta peer-to-peer (p2p) network protocol and it is what allows the decentralized operation of the blockchain.
 
 ## Why you need nodes/peers?
 

native/60_advanced-topics/02_transactions-protocol.md

@@ -168,7 +168,7 @@ To execute the transaction, a chain database session is started and a snapshot i
 
 #### 3.5.1. Apply Context
 
-To prepare for action execution, an apply context instance is created locally for each action. The apply context, as its name implies, contains references to the necessary resources to apply the action, such as an instance to the chain controller (see [Network Peer Protocol: 2.2. Chain Controller](03_network-peer-protocol.md#22-chain-controller)), the chain database where state is kept, the transaction context where the transaction is running, the actual action instance, and the receiver account to whom the action is intended.
+To prepare for action execution, an apply context instance is created locally for each action. The apply context, as its name implies, contains references to the necessary resources to apply the action, such as an instance to the chain controller, the chain database where state is kept, the transaction context where the transaction is running, the actual action instance, and the receiver account to whom the action is intended.
 
 
 #### 3.5.2. Action Trace
@@ -231,4 +231,4 @@ A transaction is verified and validated at various stages during its lifecycle:
 
 #### 3.7.1. Validation Process
 
-When validating a transaction as part of a block, multiple validations occur at various levels. In full block validation, all transactions recorded in the block are replayed and the locally calculated merkle tree root hashes (generated from the transaction receipt data and the action receipt data, respectively) are compared against the `transaction_mroot` and `action_mroot` fields in the block header. Therefore, if a recorded transaction is tampered within a block, not only the merkle tree root hashes would cause a mismatch, but also the transaction signature(s) would fail to validate. If the tampering was not performed by a bona-fide block producer, the block signature would fail to validate as well (see [Consensus Protocol: 5.3. Block Validation](01_consensus-protocol.md#53-block-validation)).
+When validating a transaction as part of a block, multiple validations occur at various levels. In full block validation, all transactions recorded in the block are replayed and the locally calculated merkle tree root hashes (generated from the transaction receipt data and the action receipt data, respectively) are compared against the `transaction_mroot` and `action_mroot` fields in the block header. Therefore, if a recorded transaction is tampered within a block, not only the merkle tree root hashes would cause a mismatch, but also the transaction signature(s) would fail to validate. If the tampering was not performed by a bona-fide block producer, the block signature would fail to validate as well.

native/60_advanced-topics/20_introduction-finalizers-voting.md

@@ -42,7 +42,7 @@ Please take care when managing the `safety.dat` file. Please do not share BLS ke
 ### Continuous Voting
 Unlike block publishing, for the top 21 block producers, voting is continuous. Taking a producer offline would prevent that producer from voting to advance finality. To support continuous voting and manage various support scenarios the Vaulta blockchain provides on chain actions to register, activate, and delete BLS Keys. Using these actions, a producer can quickly rotate to a new BLS Key.
 
-For this reason it is recommended that each producer instance uses its own unique BLS Key, and activates the BLS Key when going online. There are many strategies for [managing BLS Keys](../managing-finalizer-keys).
+For this reason it is recommended that each producer instance uses its own unique BLS Key, and activates the BLS Key when going online. There are many strategies for [managing BLS Keys](./managing-finalizer-keys).
 
 ### Voting and Peering
 All the nodeos instance from the source of the votes, to the receiver of the votes, along with any intermediate nodes must be configured to send, receive, and propagate votes. This is accomplished by enabling the vote-threading pools, configuring `vote-threads` to a value greater than zero. By default `vote-threads` is greater than zero on all block production nodes. Therefore, when two finalizers are directly peered, votes are sent and received with no additional configuration changes needed.

native/60_advanced-topics/21_managing-finalizer-keys.md

@@ -2,7 +2,7 @@
 title: Managing Finalizer Keys
 ---
 
-Review [Introduction to Finalizers and Voting](../introduction-finalizers-voting) for additional background. See How To [Rotate BLS Finalizer Keys](../../node-operation/tutorials/Rotate-BLS-Finalizer-Keys) for specific instructions on moving to new finalizer keys. The Savanna Consensus algorithm utilized by Spring v1 separates the roles of publishing blocks from signing and finalizing blocks. Finalizer Keys are needed to sign and finalize blocks. In Spring v1, all block producers are expected to be finalizers.
+Review [Introduction to Finalizers and Voting](../introduction-finalizers-voting) for additional background. See How To [Rotate BLS Finalizer Keys](../node-operation/tutorials/Rotate-BLS-Finalizer-Keys) for specific instructions on moving to new finalizer keys. The Savanna Consensus algorithm utilized by Spring v1 separates the roles of publishing blocks from signing and finalizing blocks. Finalizer Keys are needed to sign and finalize blocks. In Spring v1, all block producers are expected to be finalizers.
 
 ## Recommended Setup
 The recommendation is to generate, and register several finalizer keys. It is recommended to have one finalizer key for each instance of a producer node. A producer may have only one active finalizer key. When the keys are generated ahead of time, and included in the configuration, only an on-chain action is needed to use a new finalizer key.
@@ -50,7 +50,7 @@ A full recovery is more involved and it included using a different finalizer key
 ## Generating and Registering Finalizer Keys
 
 ### Importance of Finalizer Safety
-Savanna consensus introduces a new file that captures the history of finalizer voting. See [Introduction to Finalizers and Voting](../introduction-finalizers-voting) for more background on voting history and the role of the `finalizers/safety.dat` file. By default the file `finalizers/safety.dat` is found under the data directory. `finalizers/safety.dat` must have the full voting history for the BLS finalizer key that is in use. If `finalizers/safety.dat` is corrupted, removed, or lacks the full voting history for the BLS finalizer key in use, a new BLS finalizer key must be used.
+Savanna consensus introduces a new file that captures the history of finalizer voting. See [Introduction to Finalizers and Voting](./introduction-finalizers-voting) for more background on voting history and the role of the `finalizers/safety.dat` file. By default the file `finalizers/safety.dat` is found under the data directory. `finalizers/safety.dat` must have the full voting history for the BLS finalizer key that is in use. If `finalizers/safety.dat` is corrupted, removed, or lacks the full voting history for the BLS finalizer key in use, a new BLS finalizer key must be used.
 
 Spring v1 introduces a new configuration option `finalizers-dir` that can change the location of the `safety.dat` file. A node operator may want to change the location of `safety.dat`, if they want to move this important file out of the nodeos default data directory.
 

native/60_advanced-topics/30_staking/10_contracts.md

@@ -194,7 +194,7 @@ aimed at rewarding the Vaulta community.
 It allows the Vaulta blockchain to define a [set of receivers](https://unicove.com/contract/eosio.reward/tables/strategies) 
 that will receive rewards, and a weight for each receiver.
 
-See the [inflows](./inflows) document for more information on how the reward contract is funded.
+See the [inflows](./20_token-flows) document for more information on how the reward contract is funded.
 
 > **Note**   
 > Modifying strategies is controlled by the block producers and requires a 15/21 multisig to change.

native/60_advanced-topics/index.md

@@ -10,9 +10,7 @@ The `Vaulta Core` provides the basic building blocks for the `system` layer. How
 
 The core protocols are:
 
-1. [Consensus Protocol](01_consensus-protocol.md)
-2. [Transactions Protocol](02_transactions-protocol.md)
-3. [Network or Peer to Peer Protocol](03_network-peer-protocol.md)
+1. [Transactions Protocol](02_transactions-protocol.md)
 
 ## System