Update docs (#9)

* update docs

* fix broken links

docs/guiding-principles.md

@@ -30,8 +30,8 @@ The protocol strives to improve Ethereum validator diversity. In this spirit, th
 ### Permissionless
 > *The protocol must allow anyone to run a validator.*
 
-- Puffer allows anyone with [enclave-compatible](/reference/glossary#enclave) hardware and 1 ETH to run an Ethereum validator. Learn more 👉 [NoOp Requirements](/nodes/requirements).
-- Puffer allows anyone with a 2 ETH bond (any hardware) to run an Ethereum validator. Learn more 👉 [NoOp Requirements](/nodes/requirements).
+- Puffer allows anyone with [enclave-compatible](/reference/glossary#enclave) hardware and 1 ETH to run an Ethereum validator. Learn more 👉 [NoOp Requirements](/reference/faq#%EF%B8%8F-how-many-eth-do-i-need-to-run-a-puffer-node).
+- Puffer allows anyone with a 2 ETH bond (any hardware) to run an Ethereum validator. Learn more 👉 [NoOp Requirements](/reference/faq#%EF%B8%8F-how-many-eth-do-i-need-to-run-a-puffer-node).
 
 ### Low barriers
 > *The protocol must be capital efficient to attract NoOps.*
@@ -48,7 +48,7 @@ The protocol strives to improve Ethereum validator diversity. In this spirit, th
 ### Scalable
 > *The protocol must be scalable to compete with centralized liquid staking protocols.*
 
-- Puffer helps the protocol grow by allowing stakers to bring any amount of ETH. Learn more 👉 [minting pufETH](/stakers/minting-pufETH).
+- Puffer helps the protocol grow by allowing stakers to bring any amount of ETH. Learn more 👉 [minting pufETH](/protocol/nlrt).
 - Puffer supercharges rewards for pufETH holders through restaking exposure. Learn more 👉 [nLRTs](/protocol/nlrt).
 - Puffer is designed so that pufETH can grow in value even if validator queues are very long. Learn more 👉 [validator tickets](/protocol/validator-tickets#pros-and-cons).
 - Puffer stakers earn rewards even if the protocol's validators underperform. Learn more 👉 [NoOp incentives](/protocol/validator-tickets#why--noop-incentives).

docs/overview.md

@@ -48,7 +48,7 @@ The provisioning step will create a new validator within the EigenPod whose ETH
 
 ---
 ### 4️⃣ PoS Rewards 
-Once their validator activates, the NoOp is eligible to validate for as many days as validator tickets they have deposited. Throughout this duration, the NoOp keeps 100% of the generated PoS rewards. Their [execution rewards](/reference/glossary#execution-rewards) are immediately deposited to their wallets, while their [consensus rewards](/reference/glossary#consensus-rewards) accrue in the module's EigenPod and can be withdrawn following the [NoOp withdrawal process](/nodes/rewards).
+Once their validator activates, the NoOp is eligible to validate for as many days as validator tickets they have deposited. Throughout this duration, the NoOp keeps 100% of the generated PoS rewards. Their [execution rewards](/reference/glossary#execution-rewards) are immediately deposited to their wallets, while their [consensus rewards](/reference/glossary#consensus-rewards) accrue in the module's EigenPod and can be withdrawn following the NoOp withdrawal process.
 
 Since NoOps receive 100% of the PoS rewards they generate, they are [incentivized](/protocol/validator-tickets#why--noop-incentives) to maximize their validator performance, helping protect staker ETH. 
 

docs/rewards.md

@@ -29,7 +29,7 @@ The protocol receives rewards from the [validator tickets](/protocol/validator-t
 
 ### Rewards Breakdown
 #### Consensus Rewards
-Due to validator tickets, **NoOps receive 100% of consensus rewards**. These consensus rewards are directed to the [withdrawal credentials](/reference/glossary#withdrawal-credentials) which will, in this case, be the [module's EigenPod](/protocol/restaking-modules#restaking-modules-). However, these rewards are not immediately accessible for withdrawal. After a delay, NoOps can withdraw their consensus rewards using a [merkle rewards tree](/nodes/rewards).
+Due to validator tickets, **NoOps receive 100% of consensus rewards**. These consensus rewards are directed to the [withdrawal credentials](/reference/glossary#withdrawal-credentials) which will, in this case, be the [module's EigenPod](/protocol/restaking-modules#restaking-modules-). However, these rewards are not immediately accessible for withdrawal. After a delay, NoOps can withdraw their consensus rewards using a merkle rewards tree.
 
 #### Execution Rewards
 Thanks to validator tickets, **NoOps also receive 100% of execution rewards**. This arrangement grants NoOps full control over their MEV (Maximal Extractable Value) strategy, without any mandatory software constraints such as [MEV-Boost](https://github.com/flashbots/mev-boost), allowing for potentially more censorship resistance. Execution rewards are immediately liquid as they are routed automatically to the NoOps' specified wallet using their own `fee_recipient` address.