Enhancement/recent updates (#10)

* changes as per docs-dev update

* remove mention of pool

* clean up

---------

Co-authored-by: JasonVranek <jvranek@ucsc.edu>

docs/burst-threshold.md

@@ -14,4 +14,4 @@ Puffer is [committed to self-capping](https://twitter.com/puffer_finance/status/
 
 As the protocol reaches 22%, the number of mintable validator tickets will be reduced such that it can only sustain existing validators but not new ones. 
 
-This pledge is critical to ensure that the Puffer Pool never breaches the [dangerous consensus threshold of 33%](https://twitter.com/dannyryan/status/1688644951230267392?s=46&t=bsdBaPIHlTHEWDDdVUJW4g), which threatens the stability of Ethereum. We firmly believe that the burst threshold must be included from day one rather than after the protocol is profitable.
+This pledge is critical to ensure that the Puffer protocol never breaches the [dangerous consensus threshold of 33%](https://twitter.com/dannyryan/status/1688644951230267392?s=46&t=bsdBaPIHlTHEWDDdVUJW4g), which threatens the stability of Ethereum. We firmly believe that the burst threshold must be included from day one rather than after the protocol is profitable.

docs/faq.md

@@ -85,7 +85,7 @@ slug: /reference/faq
 
 > Since breaking SGX is of great interest in academia, there is a back-and-forth between white hat hackers finding exploits and Intel patches.
 
-> It is essential that Puffer relies on SGX as a **strict security enhancement**. Honest nodes are completely protected against all slashable offenses. However, should a nefarious node manage to break SGX, all that they would learn is knowledge of their validator private key. Knowledge of one's validator private key is the status quo for _all_ existing staking operations and does not provide the node with any way to steal from the pool.
+> It is essential that Puffer relies on SGX as a **strict security enhancement**. Honest nodes are completely protected against all slashable offenses. However, should a nefarious node manage to break SGX, all that they would learn is knowledge of their validator private key. Knowledge of one's validator private key is the status quo for _all_ existing staking operations and does not provide the node with any way to steal from the protocol.
 
 ### 🐊 Why don't other permissionless pools reduce their bond requirement to 1 ETH?
 

docs/glossary.md

@@ -23,7 +23,7 @@ Native Liquid Restaking Protocol. The Puffer protocol offers native ETH liquid r
 The yield bearing token that represents staked ETH in Puffer’s LSP
 
 ### `Stakers`
-The users who “stake” ETH to the pool to receive pufETH
+The users who “stake” ETH to the vault to receive pufETH
 
 ### `NoOps`
 The Puffer nodes that operate an Ethereum validator (and optionally additional AVSs)
@@ -35,7 +35,7 @@ A committee of Ethereum aligned community members and organizations to assist th
 A secure-computing environment capable of running Puffer’s anti-slashing technology
 
 ### `Burst Threshold`
-Code in our smart contracts that self-caps the pool at 22% marketshare
+Code in our smart contracts that self-caps the vault at 22% marketshare
 
 ### `Beacon Chain`
 The main component of the Ethereum blockchain responsible for Proof of Stake consensus

docs/guardians.md

@@ -32,4 +32,4 @@ Achieving full protocol-level decentralization is the end goal for Puffer. This
 - **EIP-7002**: Once implemented, it will render the Guardian's role in overseeing validator ejections obsolete as they can be triggered from a smart contract.
 - **EIP-4788**: Allows for trustless trustless proof of reserves, removing the dependency on any trusted entity to report how much ETH is backing the pufETH Liquid Staking Token (LST).
 
-Until these EIPs are fully adopted, the Guardians serve as an interim measure. They allow the Puffer Protocol to grow and decentralize Ethereum safely, ensuring pooled stakers remain shielded from risks and uncertainties in the interim. The Guardians' role, although crucial now, is a temporary measure designed to safeguard staker assets and ensure protocol growth in Ethereum's constantly evolving landscape.
+Until these EIPs are fully adopted, the Guardians serve as an interim measure. They allow the Puffer Protocol to grow and decentralize Ethereum safely, ensuring stakers remain shielded from risks and uncertainties in the interim. The Guardians' role, although crucial now, is a temporary measure designed to safeguard staker assets and ensure protocol growth in Ethereum's constantly evolving landscape.

docs/guiding-principles.md

@@ -22,16 +22,16 @@ The protocol strives to improve Ethereum validator diversity. In this spirit, th
 ### Ethos-aligned
 > *The protocol must be aligned with Ethereum's ethos.*
 
-- Puffer is preemptively self-capping it's pool size to 22% to protect Ethereum's credible neutrality. Learn more 👉 [burst threshold to self-cap](/protocol/burst-threshold).
+- Puffer is preemptively self-capping it's protocol size to 22% to protect Ethereum's credible neutrality. Learn more 👉 [burst threshold to self-cap](/protocol/burst-threshold).
 - Puffer is designed with a roadmap to complete decentralization. Learn more 👉 [decentralizing the Guardians](/protocol/guardians#roadmap-to-decentralization).
 - Puffer helps increase Ethereum's Proof of Stake stability since NoOps have long-term commitments. Learn more 👉 [validator tickets](/protocol/validator-tickets#pros-and-cons).
 - Puffer received an Ethereum Foundation grant for our anti-slashing technology. Learn more 👉 [Secure-Signer](https://blog.ethereum.org/2023/02/22/allocation-update-q4-22).
 
 ### 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](/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).
+- 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-much-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-much-eth-do-i-need-to-run-a-puffer-node).
 
 ### Low barriers
 > *The protocol must be capital efficient to attract NoOps.*

docs/intro.md

@@ -86,6 +86,6 @@ Traditional liquid staking tokens (LSTs) only accrue PoS rewards. As a nLRT, puf
 
 Puffer prioritizes the safety of stakers' ETH. To ensure staked ETH is safe, the protocol requires:
 - NoOps to lock 1 ETH of collateral and run [Puffer’s anti-slashing technology](/technology/secure-signer) for defense-in-depth or lock 2 ETH of collateral without the anti-slasher
-- [Eject validators](/protocol/guardians#what-are-their-duties) whose balance falls too low
+- [Ejecting validators](/protocol/guardians#what-are-their-duties) whose balance falls too low
 - Guardrails around [which AVSs are allowed](/protocol/restaking-modules#restricting-avss)
 - Guardrails around who can become a [restaking operator](/protocol/restaking-modules#restricting-reops)

docs/nlrt.md

@@ -48,7 +48,7 @@ Within the burgeoning LSDeFi ecosystem, the adaptability of staking mechanisms t
 Unlike the two-step process of holding an LST and then restaking it into an LRP to earn restaking rewards, with pufETH, users achieve this with a single step. By merely holding onto pufETH, they inherently tap into restaking rewards. This streamlining ensures that stakers can maximize the utility and rewards of their staked assets without compromising on the flexibility and opportunities traditional LSTs offer in DeFi.
 
 ### How pufETH Works
-Stakers deposit ETH at the PufferPool contract to the mint pufETH nLRT. At the protocol's inception, pufETH's conversion rate is one-to-one, but is updated daily when the protocol performs [proof of reserves](/protocol/guardians#what-are-their-duties). Assuming the protocol performs well, i.e., accrues more rewards than penalties, the amount of ETH reedamable for pufETH will increase between growth spurts. 
+Stakers deposit ETH to the PufferVault contract to mint the pufETH nLRT. At the protocol's inception, pufETH's conversion rate is one-to-one, but is updated daily when the protocol performs [proof of reserves](/protocol/guardians#what-are-their-duties). Assuming the protocol performs well, i.e., accrues more rewards than penalties, the amount of ETH reedamable for pufETH will increase. 
 
 #### Calculating the Conversion Rate
 The conversion rate can be calculated simply as:

docs/overview.md

@@ -26,7 +26,7 @@ For example, adding a new module to the PufferProtocol contract requires governa
 
 ---
 ### 1️⃣ Staking ETH  
-Stakers can deposit ETH and mint the [pufETH nLRT](/protocol/nlrt#pufeth) via the PufferPool contract, which serves as a redeemable receipt for their restaked ETH. If sufficient exit liquidity is available, stakers can reclaim their ETH from the PufferVault. Over time, the redeemable amount is expected to increase from [validator tickets](/protocol/validator-tickets) and restaking rewards.
+Stakers can deposit ETH and mint the [pufETH nLRT](/protocol/nlrt#pufeth) via the PufferVault contract, which serves as a redeemable receipt for their restaked ETH. If sufficient exit liquidity is available, stakers can reclaim their ETH from the PufferVault. Over time, the redeemable amount is expected to increase from [validator tickets](/protocol/validator-tickets) and restaking rewards.
 
 In [contrast with conventional liquid staking tokens (LSTs)](/protocol/nlrt#what-is-an-lst), pufETH can provide strictly more rewards for its holders. Not only does pufETH encompass PoS rewards **and** restaking rewards, but its value can accelerate quickly due to validator ticket sales. Furthermore, the PoS rewards for stakers are decoupled from the protocol validators' performance.
 
@@ -41,7 +41,7 @@ To ensure the safety of stakers, NoOps must distribute their encrypted validator
 
 ---
 ### 3️⃣ Provisioning ETH
-Each RestakingModule contract will contain a queue of pending NoOp registrations. As the PufferPool accrues 32 ETH chunks from deposits and rewards, the Guardians will provision the chunks to the NoOps' pending validators, following a round-robin schedule to ensure all of the protocol's modules are serviced.
+Each RestakingModule contract will contain a queue of pending NoOp registrations. As the PufferVault accrues 32 ETH chunks from deposits and rewards, the Guardians will provision the chunks to the NoOps' pending validators, following a round-robin schedule to ensure all of the protocol's modules are serviced.
 
 The provisioning step will create a new validator within the EigenPod whose ETH can be natively restaked on Eigenlayer to serve as collateral for its registered AVS. For this reason, the NoOp's validator's [withdrawal credential](/reference/glossary#withdrawal-credentials) is required to the module's EigenPod contract. After provisioning, the NoOp's validator will have deposited 32 ETH to the [BeaconDepositContract](https://etherscan.io/address/0x00000000219ab540356cBB839Cbe05303d7705Fa) and will await activation.
 

docs/rave.md

@@ -2,7 +2,7 @@
 title: RAVe
 slug: /technology/RAVe
 ---
-RAVe is the second component of Puffer's Ethereum Foundation grant and stands for `Remote Attestation Verification`. This essential set of smart contracts allows enclaves to interface with blockchains securely and helps let the Puffer Pool be permissionless. RAVe enables entirely [new use cases](https://ethresear.ch/t/2fa-zk-rollups-using-sgx/14462) that weren't previously possible that we are excited to explore at Puffer.
+RAVe is the second component of Puffer's Ethereum Foundation grant and stands for `Remote Attestation Verification`. This essential set of smart contracts allows enclaves to interface with blockchains securely and helps let the Puffer protocol be permissionless. RAVe enables entirely [new use cases](https://ethresear.ch/t/2fa-zk-rollups-using-sgx/14462) that weren't previously possible that we are excited to explore at Puffer.
 
 ## Remote Attestation
 The remote attestation (RA) process allows an untrusted party to prove they are running a specific SGX enclave. Since each enclave only allows the execution of the code it was initialized with, RA effectively allows one to prove to another that they can only run a specific program. In the context of messenger apps using SGX (e.g., [Signal](https://signal.org/blog/building-faster-oram/)), RA allows them to prove to their users' devices that they are running privacy-preserving software. 
@@ -14,8 +14,8 @@ RAVe v1 uses [EPID-based](https://api.portal.trustedservices.intel.com/EPID-atte
 
 The IAS will return RA evidence to the attesting SGX device upon successful RA. Included in the RA evidence is a RA report, the IAS-signed RA report, the IAS [root CA certificate](https://certificates.trustedservices.intel.com/Intel_SGX_Attestation_RootCA.pem), and the x.509 signing certificate used to sign the report. RAVe smart contracts verify these reports' provenance and validity of various report fields and then extract the 64-byte payload. 
 
-### RAVe in the Puffer Pool
-In Puffer, RA is how a node proves that they are running Secure-Signer and RAVe smart contracts verify RA evidence to allow entrance into the pool. When generating a validator key, the Secure-Signer enclave commits to its validator public key inside the RA report in the USERDATA field. RAVe verifies the node's RA evidence, extracts their validator public key, and registers it on-chain. This allows the node to prove to the pool that they were running a Secure-Signer enclave and generated a new validator key within it. Viewing the source code lets anyone verify that the Secure-Signer program never leaks the key.
+### RAVe in the Puffer Protocol
+In Puffer, RA is how a node proves that they are running Secure-Signer and RAVe smart contracts verify RA evidence to allow entrance into the protocol. When generating a validator key, the Secure-Signer enclave commits to its validator public key inside the RA report in the USERDATA field. RAVe verifies the node's RA evidence, extracts their validator public key, and registers it on-chain. This allows the node to prove to the protocol that they were running a Secure-Signer enclave and generated a new validator key within it. Viewing the source code lets anyone verify that the Secure-Signer program never leaks the key.
 
 ### RAVe in restaking
 ZKPs can be used to prove that a program was executed correctly, but an enclave prevents a user from running anything except the correct execution of the program. This is extremely attractive in the context of middlewares on Eigenlayer, especially when considering the negligent overhead of enclaves compared to ZKPs. Importantly, the issue of "stealth restaking" can be addressed through enclaves and RAVe.

docs/secure-signer.md

@@ -35,7 +35,7 @@ Beyond safeguarding the validator key, Secure-Signer prevents slashing by mainta
 The enclave enforces these assertions even if the node's operating system
 is compromised. If a catastrophic consensus client bug (e.g., one that overrides the EIP-3076 protection), nodes using Secure-Signer would be protected as the enclave runs in an isolated environment and maintains its integrity-protected slash protection database.
 
-By removing the possibility of slashing due to accidents or consensus client bugs, Secure-Signer significantly reduces node risk and allows the Puffer Pool to lower the bond requirement safely.
+By removing the possibility of slashing due to accidents or consensus client bugs, Secure-Signer significantly reduces node risk and allows the Puffer protocol to lower the bond requirement safely.
 
 ## Why use it?
 Distributed Validator Technology (DVT) can be considered the "MPC approach" to reduce slashing risk but requires paying in efficiency. Secure-Signer provides a cheaper alternative for validators to increase slash resistance. It is worth noting that Secure-Signer is complimentary with DVT, where each of the N key shares is stored in Secure-Signer enclaves.