The Puffer protocol integrates a generic ERC4626 vault with specialized native restaking logic, ensuring a robust framework for Ethereum staking and EigenLayer restaking. Upon depositing ETH into the vault, users receive an LRT (pufETH), which accrues rewards over time through the sale of Validator Tickets and revenue from running EigenLayer AVSs.
This implementation is designed to foster decentralization by incorporating several safeguards that support permissionless validators, thereby keeping the system both open and secure.
PufferProtocol: Serves as the core contract for managing the validator lifecycle and ETH routing between the PufferVault and EigenLayer.PufferVault: Handles ETH deposits, withdrawals, and rewards accumulation via the pufETH LRT.GuardianModule: Manages the Guardians, ensuring they operate within their roles, especially in validator provisioning, skipping, and ejecting validators.EnclaveVerifier: Verifies that the Guardians are operating with valid Intel SGX enclaves, thus ensuring the security of key operations.PufferOracleV2: Provides data for the PufferVault and ValidatorTicket contracts, particularly for calculating the pufETH conversion rate, enforcing the burst threshold, and pricing Validator Tickets.PufferModuleManager: Facilitates the creation and management of PufferModule and RestakingOperator contracts, which are critical for the resktaing operations.PufferModule: Acts as a container for an EigenPod which hosts multiple validators, responsible for validator rewards and restaking delegations.RestakingOperator: A DAO-controllable EigenLayer operator that receives delegations from PufferModules.ValidatorTicket: An ERC20 contract that mints tokens that are needed to run validators on Puffer. When they are minted the revenue pays pufETH holders a proxy for Ethereum PoS rewards.
- Stakers and Node Operators (NoOps) deposit ETH into the PufferVault and receive pufETH, representing their stake and entitlement to future rewards.
- ETH is paid to mint Validator Tickets (VTs), which are necessary for NoOps to register validators.
- The ETH from VTs is paid directly as rewards to pufETH holders, serving as a proxy for Ethereum Proof of Stake rewards.
- NoOps lock a pufETH bond and a minimum amount of VTs (≥ 28) to register their validators with the PufferProtocol.
- Upon successful registration, the PufferProtocol allocates 32 ETH from the PufferVault to fund a validator.
- The PufferModule then delegates the restaked ETH to a RestakingOperator contract chosen by the Puffer DAO.
- The restaked ETH is allocated a DAO-chosen Restaking Node Operator (RNO).
- The RNO services various Actively Validated Services (AVSs), enhancing the security of their protocols while earning rewards for the Puffer protocol.
- AVS rewards are distributed back to pufETH holders and RNOs, incentivizing participation in the protocol.
- NoOps keep 100% of their generated staking rewards from running validators and earn a portion of the AVS rewards to increase profitability.
Before registering, a NoOp must make two important decisions:
- Validator Tickets (VTs): Determine the quantity of VTs to purchase or transfer from their own wallet for the new validator. This amount must exceed the minimum VT requirement for registration of 28 days.
- Validator Setup: Decide on the validator configuration. Using an SGX enclave requires a bond deposit of 1 ETH, while a NO-SGX setup requires 2 ETH. The former requires specific hardware while the latter is compatible with any existing validator setup.
The registration process involves creating a validator key and depositing of the required bond and VTs. See the PufferProtocol docs for more details.
To keep the validator operational, NoOps must regularly top up their VTs. Each active validator consumes one VT per day, and failing to maintain an adequate VT balance will lead to the validator being ejected from the Beacon chain.
All validators registered with a PufferModule have their consensus rewards directed to the module’s EigenPod. To facilitate the claiming process, Guardians transfer these rewards from the EigenPod to the PufferModule and then publish the rewards Merkle roots. However, NoOps cannot currently claim these rewards due to limitations in gas efficiency. An upcoming EigenLayer upgrade aims to improve this aspect, after which NoOps will be able to submit valid Merkle proofs to the PufferModule contract to claim their rewards. This upgrade is essential for enabling a more gas-efficient and streamlined rewards claiming process.
Execution rewards, e.g., from MEV-Boost, are directly paid to the NoOp's specified wallet as the fee recipient. This setup ensures that NoOp has full MEV-autonomy and receive liquid rewards immediately upon proposing a block.
NoOps are eligible to earn restaking rewards due to Puffer's integration with EigenLayer. These rewards will accumulated within PufferModules and become claimble by NoOps as EigenLayer introduces their payment features.
To exit, a NoOp simply broadcasts a voluntary exit message to the Beacon Chain. Subsequently, the Guardians manage the full withdrawal process. If the validator did not incur losses, the bond is returned to the NoOp. Remaining VTs can only be withdrawn if the NoOp has no active or pending validators. This ensures a clean and straightforward exit from the system.
Restaking Node Operators (RNOs) are permissioned operators selected based on their technical reliability and reputation. They play a crucial role in operating Actively Validated Services (AVSs) on behalf of the Puffer protocol.
RNOs must first register their operator keys. This involves generating two types of keys:
- ECDSA Key: Used for standard Ethereum transactions and interactions within the protocol.
- BLS Key: Required for signing off on tasks for AVSs
Next, the RNO must register the key with the Puffer DAO who will assign the RNO to a RestakingOperator contract (ReOp). This contract serves as the operational interface for the RNO, allowing the DAO to oversee and manage the AVSs each RNO is responsible for.
RNOs are expected to maintain exemplary operational standards, including high security, maximal uptime, and robust performance. Their responsibilities include:
- Ensuring AVS Uptime: Maintaining continuous operation of AVSs to avoid penalties and maximize performance.
- Security Oversight: Implementing stringent security measures to protect the network and its staked assets from threats.
As EigenLayer evolves to include mechanisms like slashing, RNOs are required to be compliant and safeguard their operations against.
The compensation for RNOs involves a percentage of the rewards from AVSs, as determined by the DAO. Currently, the EigenLayer protocol does not support direct payments; however, provisions for these payments will be integrated into the Puffer protocol in future updates.
Guardians are selected from among the most reputable members and organizations within the Ethereum community. Each Guardian is required to operate an Intel SGX machine. This setup provides a robust defense-in-depth strategy, crucial for securely managing sensitive protocol operations.
Upon becoming a Guardian, each member registers an Externally Owned Account (EOA) key for signing various protocol functions. Additionally, Guardians generate an Ethereum key within their SGX enclave and commit the public key during the remote attestation process. This attestation proves to the GuardianModule that they are operating the approved enclave, enhancing security and trust in their actions.
The GuardianModule restricts the actions that can be taken with enclave keys. Specifically, it allows the enclave to produce a signature for validator registration only if the registration is valid (e.g., the deposit signature checks out) and the enclave successfully decrypts a validator's BLS key share. Besides this, the enclave can decrypt the key share solely to sign a voluntary exit message. Importantly, it cannot decrypt the key share for any other type of signature, such as signing a slashable message.
Guardians provision queued validators with 32 ETH from the PufferVault, assuming sufficient liquidity. This process involves verifying each registration through the Guardian's enclave as previously described. Any registrations found invalid are skipped, refunding the operators' bonds but penalizing their VTs to disincentivize protocol griefing.
Guardians also have the responsibility to eject validators under certain circumstances, such as a drop in the validator's balance below a set threshold or failure to maintain sufficient VTs. This action helps maintain the health and security of the network.
After a validator exits, the process of managing the withdrawal of their staked ETH involves several critical steps facilitated by the Guardians.
Once a validator has exited, their ETH is redirected to the PufferModule's EigenPod. The EigenLayer withdrawal process, overseen by the guardians, utilizes Merkle proofs and a queuing system to ensure the ETH is accurately transferred back to the PufferModule.
The Guardians then invoke the batchHandleWithdrawals() function on the PufferProtocol. This function is responsible for returning pufETH bonds to NoOps adjusted for penalties and burning any VTs that have been consumed during the validator's operation. This process is essential for protocol accounting.
The burst threshold is a critical safety mechanism designed to prevent the Puffer protocol from exceeding 22% of the total Ethereum validator set, safeguarding the network against centralization risks. Guardians monitor and report the total number of active validators on the Beacon Chain to ensure the protocol remains below this threshold.
| File | Type | Upgradeable | Inherited | Deployed |
|---|---|---|---|---|
IPufferProtocol.sol |
Interface | / | YES | / |
PufferProtocolStorage.sol |
Singleton | UUPS Proxy | YES | / |
PufferProtocol.sol |
Singleton | UUPS Proxy | NO | / |
| File | Type | Upgradeable | Inherited | Deployed |
|---|---|---|---|---|
IGuardianModule.sol |
Interface | / | YES | / |
IEnclaveVerifier.sol |
Interface | / | YES | / |
EnclaveVerifier.sol |
Singleton | NO | YES | / |
GuardianModule.sol |
Singleton | NO | NO | / |
| File | Type | Upgradeable | Inherited | Deployed |
|---|---|---|---|---|
IValidatorTicket.sol |
Interface | / | YES | / |
ValidatorTicket.sol |
Singleton | UUPS Proxy | NO | / |
| File | Type | Upgradeable | Inherited | Deployed |
|---|---|---|---|---|
IPufferOracleV2.sol |
Interface | / | YES | / |
PufferOracleV2.sol |
Singleton | / | NO | / |
| File | Type | Upgradeable | Inherited | Deployed |
|---|---|---|---|---|
IPufferModuleManager.sol |
Interface | / | YES | / |
PufferModuleManager.sol |
Singleton | UUPS Proxy | NO | / |
| File | Type | Upgradeable | Inherited | Deployed |
|---|---|---|---|---|
IPufferModule.sol |
Interface | / | YES | / |
PufferModule.sol |
Beacon Proxy | YES | NO | / |
| File | Type | Upgradeable | Inherited | Deployed |
|---|---|---|---|---|
IPufferModule.sol |
Interface | / | YES | / |
PufferModule.sol |
Beacon Proxy | YES | NO | / |
All of our smart contract inherit from AccessManaged | AccessManagedUpgradeable
- Openzeppelin smart contracts
- AccessManager
- AccessManaged
- ERC20
- ERC20Permit
- ERC1967Proxy
- UpgradeableBeacon
- ECDSA
- MerkleProof
- MessageHashUtils
- Strings
- Address
- SafeCast
- Openzeppelin upgradeable smart contracts
- AccessManagedUpgradeable
- UUPSUpgradeable
- Initializable
- EigenLayer