Stake/withdraw docs + other modifications (#89)

* prettier and trailing spaces

* Updated data and wording

* Updated structure

* Removed secure signer and uppdated when puffer launched

* Updated info and references to season 2

* Removed secure signer from glossary

* removed all references to secure signer, updated wording and fixed links

* Updated images and removed unused ones

* Documented stake proccess

* Documented withdrawal process

* Applied changes based on PR comments

* Updated validator ticket info

* Revert "Updated validator ticket info"

This reverts commit c6b1ac4.

* Added WETH staking to the docs

Author: eladiosch

docs/burst-threshold.md

@@ -7,11 +7,10 @@ slug: /protocol/burst-threshold
 The Burst Threshold is Puffer's commitment to Ethereum's Ethos.
 :::
 
-
 ### Burst Threshold
 
-Puffer is [committed to self-capping](https://x.com/puffer_finance/status/1697817894900711700?s=20) its validator marketshare to 22% of Ethereum’s validator set, which we refer to as the protocol's *Burst Threshold*. Instead of abruptly pausing staking and NoOp registration once the burst threshold is reached, Puffer introduces a mechanism to organically reduce staker demand as the protocol reaches the threshold.
+Puffer is [committed to self-capping](https://x.com/puffer_finance/status/1697817894900711700?s=20) its validator marketshare to 22% of Ethereum’s validator set, which we refer to as the protocol's _Burst Threshold_. Instead of abruptly pausing staking and NoOp registration once the burst threshold is reached, Puffer introduces a mechanism to organically reduce staker demand as the protocol reaches the threshold.
 
-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. 
+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 protocol never breaches the [dangerous consensus threshold of 33%](https://x.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://x.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/campaigns-season-2.md

@@ -15,14 +15,12 @@ Season 2 represents a major evolution in our reward distribution mechanism, with
 
 Season 2 transitions Puffer Points to on-chain incentives, leveraging CARROT as the token that powers our ecosystem. CARROT tokens are distributed weekly to protocol participants based on vePUFFER votes. The token is designed to enhance transparency, fairness, and efficiency in rewards allocation.
 
+When claiming the CARROT rewards, users will receive them as mtwCARROT that will be locked for 30 days before being able to unwrap them.
+
 ### Empowering Decentralized Governance
 
 Season 2 enables $PUFFER holders to lock their tokens to receive vePUFFER, granting voting power in the governance process. vePUFFER holders decide how CARROT incentives are allocated, creating a community-driven ecosystem that reflects the collective will of the community.
 
 ### Permissionless Proposals
 
 Protocol projects, liquidity providers, and contributors can now submit proposals to participate in Puffer’s incentive campaigns. With incentive gauges, projects can compete for CARROT allocations, further decentralizing and diversifying Puffer’s ecosystem.
-
-## Stay tuned!
-
-More information will follow soon.

docs/deployed-contracts.md

@@ -3,21 +3,27 @@ title: Contract Addresses
 slug: /deployments/deployed-contracts
 ---
 
-
 # Contract Addresses and Docs
+
 ## Puffer Protocol Contracts
+
 Puffer's smart contracts are located in two repos:
+
 ### [PufferFinance/pufETH](https://github.com/PufferFinance/pufETH)
+
 > This repo contains the `PufferVault` contract which is where the protocol's assets (ETH, wETH, stETH) are held and the `pufETH` LRT is minted.
 
 > Visit the [technical documentation](https://github.com/PufferFinance/pufETH/tree/main/docs) for more information.
 
 ### [PufferFinance/PufferPool](https://github.com/PufferFinance/PufferPool)
+
 > This repo contains the core contracts for Puffer's protocol. The core functionality is to:
+
 - allow for users to permissionlessly run Ethereum validators
 - interface with EigenLayer's contracts to enable native restaking and delegation
 
 > Visit the [technical documentation](https://github.com/PufferFinance/PufferPool/tree/master/docs) for more information.
 
 ## Deployment Addresses
-Please check [Deployments and Access Control](https://github.com/PufferFinance/Deployments-and-ACL/tree/main/docs/deployments) Github repository for the definitive addresses of all deployed contracts on mainnet and Holesky and the associated ABIs. 
+
+Please check [Deployments and Access Control](https://github.com/PufferFinance/Deployments-and-ACL/tree/main/docs/deployments) Github repository for the definitive addresses of all deployed contracts on all chains.

docs/ejection-scenarios.md

@@ -30,6 +30,7 @@ Node operators can initiate a controlled exit through their validator client whe
 :::
 
 The process involves:
+
 - Generating exit message
 - Signing with validator keys
 - Broadcasting to the network
@@ -42,6 +43,7 @@ Serious protocol violations result in immediate ejection and possible slashing p
 :::
 
 Common violations include:
+
 - Double signing blocks
 - Proposing multiple blocks for the same slot
 - Attesting to conflicting blocks
@@ -50,6 +52,7 @@ Common violations include:
 ### 4. Guardian-Initiated Ejection
 
 Puffer Guardians may trigger ejection under these circumstances:
+
 - Consistent failure to meet performance metrics
 - Detection of malicious behavior
 - Violation of protocol rules or terms of service
@@ -85,12 +88,13 @@ Puffer Guardians may trigger ejection under these circumstances:
 ## Prevention Best Practices
 
 :::tip Best Practices
+
 1. Regular system maintenance and updates
 2. Continuous monitoring of validator performance
 3. Proper security measures implementation
 4. Maintaining stable network connectivity
 5. Following all protocol guidelines
-:::
+   :::
 
 ## Additional Resources
 

docs/faq.md

@@ -6,11 +6,11 @@ slug: /reference/faq
 ### 🐙 What is Puffer's Mission?
 
 > Puffer's mission is to define a new industry standard for secure validator operations, with the primary objective of preserving the decentralization of Ethereum.
-
+>
 > Through our anti-slashing technology, we are reducing the risk of correlated slashing events across Ethereum while simultaneously promoting decentralization by lowering the barrier to entry for at-home validators and allowing for a more diverse node operator set.
-
-> However, reducing barriers to entry is one thing, but creating a more profitable platform for validators is crucial and is why Puffer has been pioneering in native restaking. 
-
+>
+> However, reducing barriers to entry is one thing, but creating a more profitable platform for validators is crucial and is why Puffer has been pioneering in native restaking.
+>
 > Ultimately, through Puffer's protocol, we hope to extend Ethereum's decentralization runway while its roadmap is being implemented.
 
 ### 🐡 Explain ETH Liquid staking to me like I'm five?
@@ -30,10 +30,10 @@ slug: /reference/faq
 > Although decentralized liquid staking sounds great in theory, the market will always favor centralized services in practice. This is because centralized staking providers can attract more liquidity by offering stakers higher yields than their decentralized competitors.
 >
 > This dilemma results from centralized services running a small and permissioned node operator set that allows them to scale much faster and operate more cost-effectively. For example, a node operator with 1024 ETH can operate 32x more validators than a node operator with 32 ETH when solo staking while paying the same hardware costs.
-
+>
 > In the context of liquid staking, centralized protocols with permissioned validators do not require their operators to put down collateral. Rather, they rely on reputation to ensure they behave honestly. In practice, some operators run tens of thousands of validators each. For a decentralized liquid staking protocol, running this many validators requires operators to have tens of thousands of ETH.
 >
-> Puffer's goal is to break this cycle by empowering decentralized validators with higher rewards while lowering their barrier to entry. 
+> Puffer's goal is to break this cycle by empowering decentralized validators with higher rewards while lowering their barrier to entry.
 
 ### 🦈 How does Puffer help address some of these pain points?
 
@@ -43,54 +43,24 @@ slug: /reference/faq
 >
 > Over the coming months, we will be providing more information on our plans for generating additional yield for Puffer node operators.
 
-### 🦑 How does Puffer protect validators from being slashed?
-
-> Secure-Signer is an open-source public good built by the Puffer team to increase decentralization across Ethereum while protecting validators from being slashed.
->
-> As an independent implementation of Consensys' Web3Signer remote-signing tool, Secure-Signer moves key management and signing logic out of the consensus client and into a secure enclave.
->
-> Validator keys are generated and stored within SGX's encrypted enclave memory.
->
-> If a compromised host or consensus client bug attempts to sign a slashable message, Secure-Signer's isolated SGX environment won't produce a signature, providing a strict security enhancement that prevents the validator from committing a slashable offense.
-
 ### 🧜‍♀️ How much ETH do I need to run a Puffer node?
 
-> As preserving decentralization is our top priority, the minimum collateral requirement will start at 2 ETH for Puffer node operators. This lowers the barrier to entry for solo stakers, allowing for a robust and scalable permissionless node operator set. If the validator is using Puffer's anti-slasher, they can reduce this collateral requirement to 1 ETH. 
+> As preserving decentralization is our top priority, the minimum collateral requirement will start at 2 ETH for Puffer node operators. This lowers the barrier to entry for solo stakers, allowing for a robust and scalable permissionless node operator set.
 
-### 🐢 When will Puffer launch?
+### 🐢 When did Puffer launch?
 
-> Puffer is coming soon™️! 
-
-### 🦞 Who runs Secure-Signer?
-
-> Nodes run Secure-Signer alongside their consensus client. Nodes could be anyone with compatible hardware and at least 1 ETH.
+> Puffer deployed on mainnet on 31st January 2024.
 
 ### 🦐 Can I get slashed if I go offline?
 
 > No, inactivity is not considered a slashable offense. Refer to [Slashing on Ethereum PoS](slash.md).
 
 ### 🪼 How many validators have been slashed? Should we even care about slashable offenses?
 
-> At the time of writing, there have been [262 slashing events](https://beaconcha.in/validators/slashings). While this number may seem low, slashing poses an existential threat to all Ethereum validators and LST holders.
-
+> At the time of writing, there have been [472 slashing events](https://beaconcha.in/validators/slashings). While this number may seem low, slashing poses an existential threat to all Ethereum validators and LST holders.
+>
 > For example, assume there is a bug in one of the five consensus clients that causes a slashing rule to be broken (for simplicity, assume each consensus client is used by 20% of the validators). The anti-correlation penalty causes the slashing amount to increase as the number of offenders increases, in this case to $1 + 3*20\%*32 = 20.2$ ETH. Unfortunately, 20% of the validators using this consensus client would face a 20.2 ETH slashing penalty. This would wipe out years of staking revenue for the nodes and LST holders.
 
-> Fortunately, if this were to happen, the Secure-Signer nodes on Puffer would be protected!
-
-### 🐳 How are validator keys being managed in your system?
-
-> The node generates and stores all validator keys in the [Secure-Signer enclave](secure-signer.md#where-is-it-run).
-
-### 🐠 Wasn't SGX hacked before? Why would you use it?
-
-> 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 protocol.
-
-### 🐊 Why don't other permissionless pools reduce their bond requirement to 1 ETH?
-
-> Reducing the bond requirement [increases node and staker risk](slash.md#liquid-staking-protocol-considerations) which Puffer mitigates through [Secure-Signer](secure-signer.md#what-is-it) and [Guardian support](./guardians.md). Also as the bond requirement decreases, the threat of "rug-pooling" increases, which Puffer's [Validator Tickets](/protocol/validator-tickets#why--noop-incentives) address.
-
-### 🪸 How hard is it to get access to SGX?
+### 🐊 Why don't other permissionless pools reduce their bond requirement to 2 ETH?
 
-> Running Secure-Signer doesn't require anything expensive or technical, like purchasing and running an ASIC. Instead, Secure-Signer is software that runs on compatible Intel CPUs that support SGX. Many cloud providers (e.g., Microsoft Azure) readily supply SGX-enabled servers for cheap that are compatible with Secure-Signer. Additionally, Intel SGX-enabled XEON servers with the specs to run a validator can be purchased to be run at home. Community members have even had [success running Secure-Signer on Intel NUCs](https://mirror.xyz/ladislaus.eth/joTqwZ1sBLxlJayV4pIYxCkwl4RWheM_xipU_OCp9MM)!
+> Reducing the bond requirement [increases node and staker risk](slash.md#liquid-staking-protocol-considerations) which Puffer mitigates through [Guardian support](./guardians.md). Also as the bond requirement decreases, the threat of "rug-pooling" increases, which Puffer's [Validator Tickets](/protocol/validator-tickets#why--noop-incentives) address.

docs/glossary.md

@@ -4,80 +4,102 @@ slug: /reference/glossary
 ---
 
 ### Glossary
+
 ### `Eigenlayer`
+
 An Ethereum-based protocol that enables restaking
 
 ### `AVS`
+
 Actively Validated Service ~ the term for a service on Eigenlayer
 
 ### `Restaking`
+
 Where people reuse collateral to operate ≥ 1 AVS. If this collateral is beacon chain ETH, they are a called a `native restaker`
 
 ### `LSP`
+
 Liquid Staking Protocol
 
 ### `nLRP`
+
 Native Liquid Restaking Protocol. The Puffer protocol offers native ETH liquid restaking on Eigenlayer
 
 ### `pufETH`
+
 The yield bearing token that represents staked ETH in Puffer’s LSP
 
 ### `Stakers`
+
 The users who “stake” ETH to the vault to receive pufETH
 
 ### `NoOps`
+
 The Puffer nodes that operate an Ethereum validator (and optionally additional AVSs)
 
 ### `Guardians`
+
 A committee of Ethereum aligned community members and organizations to assist the protocol as it matures
 
 ### `Enclave`
+
 A secure-computing environment capable of running Puffer’s anti-slashing technology
 
 ### `Burst Threshold`
+
 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
 
 ### `Beacon Chain Deposit Contract`
+
 The smart contract to which a NoOp must deposit 32 ETH to initiate running a validator node
 
 ### `VEM`
+
 Voluntary Exit Message ~ a validator-signed message that will exit the signer when broadcasted to the beacon chain
 
 ### `Withdrawal Credentials`
+
 A validator parameter that sets where their consensus rewards and full withdrawal eth are sent. For 0x01 (post-Shapella) withdrawals, the credentials are formatted as `0x01000000000000` ++ `20 byte ethereum address`
 
 ### `Consensus Rewards`
+
 AKA partial withdrawals or skimmed rewards. These rewards are generated by Ethereum validators performing their PoS duties
 
 ### `Execution Rewards`
+
 The rewards earned by a validator when proposing a block. The rewards are composed of priority fees and MEV: Maximal Extractable Value". This refers to the maximum value that can be extracted from block production in excess of the standard block reward and gas fees by including, excluding, and changing the order of transactions in a block. [source](https://ethereum.org/en/developers/docs/mev/)
 
 ### `Full Withdrawal`
+
 The validator’s entire balance that is withdrawn from the beacon chain to the Ethereum address set by the withdrawal credentials
 
 ### `Slashing`
+
 Slashing may refer to a loss of funds triggered by either of the following:
-1. Misbehavior of validator nodes, such as signing two different blocks for the same beacon slot (AKA double-signing). See [secure-signer](../technology/secure-signer) for more info on this kind of slashing
+
+1. Misbehavior of validator nodes, such as signing two different blocks for the same beacon slot (AKA double-signing).
 2. A Restaking Operator (ReOp) not fulfilling obligations defined by an AVS
 
 ### `Validator Ticket`
-An ERC20 token. Each Validator Ticket allows operating a validator on the Puffer Protocol for one day.  
 
+An ERC20 token. Each Validator Ticket allows operating a validator on the Puffer Protocol for one day.
 
 ### `Bond`
+
 An amount of pufETH a NoOp must lend to the protocol during the time of running their validator node. They may lose some or all of this bond if they misbehave or are slashed. NoOps may retrieve this bond after proving they have exited their validator node from the beacon chain
 
 ### `Puffer Module`
+
 A contract that defines a set of AVSs which NoOps opting into the module will delegate their ETH funds to running. These NoOps will receive corresponding rewards in return by participating in this Puffer Module
 
 ### `Restaking Operator`
-AKA ReOp: A NoOp that is delegated funds to operate an AVS on behalf of other NoOps, as part of a Puffer Module
 
-### `Secure Signer`
-A software developed by Puffer that helps prevent validators from being slashed. It utilizes Trusted Execution Environments (TEEs) such as Intel SGX
+AKA ReOp: A NoOp that is delegated funds to operate an AVS on behalf of other NoOps, as part of a Puffer Module
 
 ### `Proof of Rewards`
+
 This refers to the process by which NoOps prove and receive the rewards generated as a result of running their validator node