Docs: Fix linkcheck errors (#9743)

automerge

docs/src/implemented-proposals/ed_overview/ed_storage_rent_economics.md

@@ -1,6 +1,6 @@
 ## Storage Rent Economics
 
-Each transaction that is submitted to the Solana ledger imposes costs. Transaction fees paid by the submitter, and collected by a validator, in theory, account for the acute, transactional, costs of validating and adding that data to the ledger. At the same time, our compensation design for archivers (see [Replication-client Economics](ed_replication_client_economics.md)), in theory, accounts for the long term storage of the historical ledger. Unaccounted in this process is the mid-term storage of active ledger state, necessarily maintained by the rotating validator set. This type of storage imposes costs not only to validators but also to the broader network as active state grows so does data transmission and validation overhead. To account for these costs, we describe here our preliminary design and implementation of storage rent.
+Each transaction that is submitted to the Solana ledger imposes costs. Transaction fees paid by the submitter, and collected by a validator, in theory, account for the acute, transactional, costs of validating and adding that data to the ledger. At the same time, our compensation design for archivers (see [Replication-client Economics](ed_replication_client_economics/README.md)), in theory, accounts for the long term storage of the historical ledger. Unaccounted in this process is the mid-term storage of active ledger state, necessarily maintained by the rotating validator set. This type of storage imposes costs not only to validators but also to the broader network as active state grows so does data transmission and validation overhead. To account for these costs, we describe here our preliminary design and implementation of storage rent.
 
 Storage rent can be paid via one of two methods:
 
@@ -12,7 +12,7 @@ Method 2: Pay per byte
 
 If an account has less than two-years worth of deposited rent the network charges rent on a per-epoch basis, in credit for the next epoch (but in arrears when necessary). This rent is deducted at a rate specified in genesis, in lamports per kilobyte-year.
 
-For information on the technical implementation details of this design, see the [Rent](rent.md) section. 
+For information on the technical implementation details of this design, see the [Rent](../rent.md) section.
 
 
 

docs/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md

@@ -11,7 +11,7 @@ Validator-client rewards for these services are to be distributed at the end of
 
 The effective protocol-based annual interest rate \(%\) per epoch received by validation-clients is to be a function of:
 
-* the current global inflation rate, derived from the pre-determined dis-inflationary issuance schedule \(see [Validation-client Economics](.)\)
+* the current global inflation rate, derived from the pre-determined dis-inflationary issuance schedule \(see [Validation-client Economics](README.md)\)
 * the fraction of staked SOLs out of the current total circulating supply,
 * the up-time/participation \[% of available slots that validator had opportunity to vote on\] of a given validator over the previous epoch.
 

docs/src/proposals/block-confirmation.md

@@ -4,7 +4,7 @@ A validator votes on a PoH hash for two purposes. First, the vote indicates it
 believes the ledger is valid up until that point in time. Second, since many
 valid forks may exist at a given height, the vote also indicates exclusive
 support for the fork. This document describes only the former. The latter is
-described in [Tower BFT](tower-bft.md).
+described in [Tower BFT](../implemented-proposals/tower-bft.md).
 
 ## Current Design
 
@@ -50,7 +50,7 @@ log the time since the NewBlock transaction was submitted.
 
 ### Finality and Payouts
 
-[Tower BFT](tower-bft.md) is the proposed fork selection algorithm.  It proposes
+[Tower BFT](../implemented-proposals/tower-bft.md) is the proposed fork selection algorithm.  It proposes
 that payment to miners be postponed until the *stack* of validator votes reaches
 a certain depth, at which point rollback is not economically feasible. The vote
 program may therefore implement Tower BFT. Vote instructions would need to