diff --git a/documentation/specifications/consensus/README.md b/documentation/specifications/consensus/README.md
index 8d5d5167c4195..b9bb7f7adf422 100644
--- a/documentation/specifications/consensus/README.md
+++ b/documentation/specifications/consensus/README.md
@@ -258,7 +258,7 @@ Verification
 
 ### SyncInfo
 
-This structure provides verifiable certificates that can allow a validator to catch up to another validator. The max round _r_ of the `highest_quorum_cert` and `highest_timeout_cert` have already completed according to > 2f validators and convince any validator join round _r+1_ immediately if they are currently on a round < _r+1_. A correct implementation ensures that `highest_commit_cert` and `highest_quorum_cert` are on the same chain id. If a validator learns about more recent state upon receiving `SyncInfo`, then it should catch up through [BlockRetrievalRequest](#BlockRetrievalRequest), [EpochRetrievalRequest](#EpochRetrievalRequest) or [state synchronization](../state_sync/README.md).
+This structure provides verifiable certificates that can allow a validator to catch up to another validator. The max round _r_ of the `highest_quorum_cert` and `highest_timeout_cert` have already completed according to > 2f validators and convince any validator join round _r+1_ immediately if they are currently on a round < _r+1_. A correct implementation ensures that `highest_commit_cert` and `highest_quorum_cert` are on the same chain id. If a validator learns about more recent state upon receiving `SyncInfo`, then it should catch up through [BlockRetrievalRequest](#BlockRetrievalRequest), [EpochRetrievalRequest](#EpochRetrievalRequest) or [state synchronization](../../../state-sync/README.md).
 
 ```rust
 pub struct SyncInfo {
@@ -394,7 +394,7 @@ Verification
 
 * ensure `status` == Succeeded
 
-  * TODO: Consider whether `status` == NotEnoughBlocks is also correct behavior. If the number of blocks to catch up exceeds a limit, a validator should rely on [state synchronization](../state_sync/README.md) to catch up.
+  * TODO: Consider whether `status` == NotEnoughBlocks is also correct behavior. If the number of blocks to catch up exceeds a limit, a validator should rely on [state synchronization](../../../state-sync/README.md) to catch up.
 
 * verify each blocks independently
 * verify the blocks form a chain where the first one's id == the `block_id` in BlockRetrievalRequest. `[blocks[i].block_data.quorum_cert.certified_block.id == blocks[i+1].id for i in 0..blocks.len()-1]`
@@ -460,7 +460,7 @@ Verification
 
 Verification
 
-* Same as specified in [SyncInfo](#sync_info_data)
+* Same as specified in [SyncInfo](#syncinfo)
 
 ## Abstracted modules
 
diff --git a/documentation/specifications/network/README.md b/documentation/specifications/network/README.md
index b32e5f60363ba..73691ed436619 100644
--- a/documentation/specifications/network/README.md
+++ b/documentation/specifications/network/README.md
@@ -36,8 +36,8 @@ While AptosNet does not assume a specific network topology, we will frame the sp
 
 ### Networks
 
-* **Validator Network (VN)**: The validator network is a fully-connected, mutually authenticated network consisting only of validator nodes. Non-validators (i.e., any peer without a keypair in the current epoch's validator set) are explicitly not allowed to join the validator network and other validators will reject any unauthenticated inbound connections. Validators in the Validator Network [synchronize mempools](../mempool/README.md) of transactions, order and execute transactions with [consensus](../consensus/README.md), and synchronize ledger states with [state sync](../state_sync/README.md).
-* **Validator-internal Full Node Network (VFNN)**: Each validator operates a logically private network consisting of only a validator and its operated VFNs. For operational simplicity, the v1 version of each VFNN operates in a server-only authentication mode, with the Validator as the server and the VFNs as the clients. VFNs will typically forward transactions to their upstream validator via [mempool](../mempool/README.md) and synchronize their ledger state with their upstream validator via [state sync](../state_sync/README.md).
+* **Validator Network (VN)**: The validator network is a fully-connected, mutually authenticated network consisting only of validator nodes. Non-validators (i.e., any peer without a keypair in the current epoch's validator set) are explicitly not allowed to join the validator network and other validators will reject any unauthenticated inbound connections. Validators in the Validator Network [synchronize mempools](../mempool/README.md) of transactions, order and execute transactions with [consensus](../consensus/README.md), and synchronize ledger states with [state sync](../../../state-sync/README.md).
+* **Validator-internal Full Node Network (VFNN)**: Each validator operates a logically private network consisting of only a validator and its operated VFNs. For operational simplicity, the v1 version of each VFNN operates in a server-only authentication mode, with the Validator as the server and the VFNs as the clients. VFNs will typically forward transactions to their upstream validator via [mempool](../mempool/README.md) and synchronize their ledger state with their upstream validator via [state sync](../../../state-sync/README.md).
 * **Public Validator Full Node Network (PVFNN)**: A publicly accessible network of VFNs that services transaction submission and state queries for all node types. For instance, public clients may submit transactions to the Aptos Network and synchronize their ledger states over the PVFNN.
 * **Public Full Node Network (PFNN)**: A publicly accessible network of PFNs where participation is open to non-validators. In contrast, PFNN primarily interfaces with Aptos through PVFNN and can only serve PFNs and other public clients.