Demystify the Access Control Mechanism in Puffer Protocol
Feb 8 2024

“Puffer is a decentralized native liquid restaking protocol (nLRP) built on Eigenlayer”. It has attracted more than 600 million USD in TVL (Total Value Locked) in just a few days. Access control is an important security consideration to prevent malicious operations on the protocol.

In this blog, we review the entire architecture of the access control mechanism and its current configuration in the Puffer protocol. This can help the community better understand the protocol. Note that the analysis result is based on the current status (Block 19177155, Feb 07, 2024, 03:17:35 PM +UTC) on Ethereum.

Contract addresses

The following table lists the smart contracts used in this blog.

Address Implementation
PufferDepositor 0x4aa799c5dfc01ee7d79 0e3bf1a7c2257ce1dceff 0x7276925e42f9c4054af a2fad80fa79520c453d6a
PufferVault 0xD9A442856C234a39a81 a089C06451EBAa4306a72 0x39ca0a6438b6050ea2a c909ba65920c7451305c1
AccessManager 0x8c1686069474410E624 3425f4a10177a94EBEE11 -
TimeLock 0x3c28b7c7ba1a1f55c9c e66b263b33b204f2126ea -
Operation SafeWallet 0xC0896ab1A8cae8c2C1d 27d011eb955Cca955580d 0xd9db270c1b5e3bd161e 8c8503c55ceabee709552
Community SafeWallet 0x446d4d6b26815f9bA78 B5D454E303315D586Cb2a 0xd9db270c1b5e3bd161e 8c8503c55ceabee709552
Pausing SafeWallet 0x1ba8e3aA853F73ae809 3E26B7B8F2520c3620Df4 0xd9db270c1b5e3bd161e 8c8503c55ceabee709552

Architecture

The whole protocol mainly includes two smart contracts related to users’ assets. The first one is PufferDepositor, and the second one is PufferVault.

The main functionality of PufferDepositor is to accept users’ assets and then deposit them into PufferVault. If the users' deposit assets are not stETH, the swap into a DEX is automatically performed by the protocol.

PufferVault is the main contract that holds users' assets. It’s also the entry point for deposits into EigenLayer. The main access control of the entire protocol is implemented in this smart contract."

Access Control Mechanism

The whole access control is implemented by leveraging OpenZeppelin’s AccessManager module. The AccessManager smart contract manages the authority of the PufferDepositor and PufferVault contracts.

The AccessManager defines different Roles, which contain different addresses. Each Role can be assigned to invoke different functions inside the AccessManaged contracts (i.e., PufferDepositor and PufferVault). The AccessManager supports the delayed execution of a particular function. That’s when granting a Role to an address, it can specify whether the operations issued from this address in this Role are executed immediately or executed with a time delay.

Current Access Control Configurations

Nevertheless, the effectiveness of the access control depends on its configuration. We have observed numerous instances where a flawed configuration of ACL (Access Control List) rules has led to security vulnerabilities.

To address this, we have reviewed the current configuration of the Puffer protocol and present the results below. Please note that these results only reflect the status as of Block 19177155 (Feb 07, 2024, 03:17:35 PM +UTC).

Roles

Below is a table outlining the current roles within the system and their associated addresses.

Role ID Addresses with this Role Delayed Execution Note
0 TimeLock 0x3c28b7c7ba1a1f55c9ce66b263b33b204f2126ea No ADMIN Role
1 Operation SafeWallet 0xc0896ab1a8cae8c2c1d27d011eb955cca955580d Yes with 604800 seconds (7 days) Upgrade the target contracts (PufferDepositor and PufferVault)
1 Community SafeWallet 0x446d4d6b26815f9ba78b5d454e303315d586cb2a No Upgrade the target contracts (PufferDepositor and PufferVault)
22 Operation SafeWallet 0xc0896ab1a8cae8c2c1d27d011eb955cca955580d No Move assets to EigenLayer and initiate withdrawal request from EigenLayer

There are different execution paths to execute functions inside the PufferValut contract. One path involves the TimeLock contract (with the ADMIN Role – as shown in Path 1 in the figure), and the other path allows direct invocation of functions inside the Vault, with the role assigned to the caller. In both cases, the invocation must go through the AccessManager.

Type I: Invocation from TimeLock Contract

Note that when invoking a function from the TimeLock contract, the assigned Role is ADMIN. This designation arises because, from the Vault's perspective, the caller is the TimeLock contract, which possesses the ADMIN Role. Consequently, the TimeLock contract incorporates an additional layer of delayed execution mechanism.

  • Operation SafeWallet: This component can invoke functions within the target contract after a delay of 604,800 seconds (approximately 7 days).
  • Community SafeWallet: This component has the capability to immediately invoke functions within the target contract. It also possesses the authority to cancel any pending execution in the queue submitted by the Operation SafeWallet.
  • Pausing SafeWallet: This component is restricted to pausing the target contract and is not authorized to execute any other functions.

Type II: Direct Invocation of the Vault Contract

The subsequent method involves directly invoking functions within the Vault contract. It's important to note that the AccessManager dictates which functions can be invoked by the addresses associated with each Role.

RoleID Target Contract Target Function
1 PufferValut upgradeToAndCall(address,bytes)

0x4f1ef286

22 PufferValut depositToEigenLayer (0x008e0590)

initiateETHWithdrawalsFromLido (0x593961de)

initiateStETHWithdrawalFromEigenLayer (0x402064a7)

Both the Operation and Community SafeWallets have the capability to directly invoke the upgradeToAndCall function to upgrade the target contract. The key distinction lies in the timing: the Community SafeWallet executes this action without any delay, whereas the Operation SafeWallet is subject to a delay.

Moreover, the Operation SafeWallet is equipped to immediately execute functions that transfer assets into EigenLayer and initiate withdrawal requests.

Updated on [Feb-08-2024 10:02:59 AM +UTC]

An operation aiming to remove the Operation SafeWallet from Role 1 has been scheduled. This operation is slated for execution after block 1707940908, which corresponds to an estimated delay of approximately 7 days. The simulation of these queued transactions was conducted using Phalcon Block.

See all transactions in this Fork.

Updated on [Feb-16-2024 20:10:23 AM +UTC]:

Safe Wallet Configurations

The configuration of a safe wallet also affects the protocol’s security.

Wallet Owners Threshold
0xC0896ab1A8cae8c2C1d 27d011eb955Cca955580d [0xb7d83623906AC3fa577F45B7D2b9D4BD26BC5d76] [0xD6475ce37d964d4816715FdafFEeAAf2958948bE] [0xD70aa9d7280E6FEe89B86f53c0B2A363478D5e94] [0xa5F84b556d5FD8959165Eff0324DCFEa164fA089] [0xf061f1FceFa32b3bbD5d18c5A623DB64bfBc107D] [0x206846dE1F372A9a603e672ba97A5238cC89aeAA] 3
0x446d4d6b26815f9bA78 B5D454E303315D586Cb2a [0xb7d83623906AC3fa577F45B7D2b9D4BD26BC5d76] [0x3B16821A5dBBFF86E4a88eA0621EC6be016cd79A] [0x648aA14e4424e0825A5cE739C8C68610e143FB79] [0x27c7CEd729280060577A68A54A94075D18614D19] [0xa9aE3B8FC1CBaAed74fE5889260f7cD743c50363] [0x161f479021044cB1C9e3DEF98aF945A8D972D3B2] 3
0x1ba8e3aA853F73ae809 3E26B7B8F2520c3620Df4 [0xb7d83623906AC3fa577F45B7D2b9D4BD26BC5d76] [0x3B16821A5dBBFF86E4a88eA0621EC6be016cd79A] [0x648aA14e4424e0825A5cE739C8C68610e143FB79] [0x27c7CEd729280060577A68A54A94075D18614D19] [0xa9aE3B8FC1CBaAed74fE5889260f7cD743c50363] [0x161f479021044cB1C9e3DEF98aF945A8D972D3B2] [0xD6475ce37d964d4816715FdafFEeAAf2958948bE] [0xD70aa9d7280E6FEe89B86f53c0B2A363478D5e94] [0xa5F84b556d5FD8959165Eff0324DCFEa164fA089] [0xf061f1FceFa32b3bbD5d18c5A623DB64bfBc107D] [0x206846dE1F372A9a603e672ba97A5238cC89aeAA] [0xaACA1eDbb656206Ce2a82Da7d7BD3e1Bb8138F22] 1

Updated on [Feb-08-2024 10:02:59 AM +UTC]:

Summary

In this blog post, we have reviewed the security mechanisms utilized by the Puffer protocol. Overall, the design of the entire permission system is comprehensive.

The community should actively monitor for potential risks:

  • The security of the private keys of the Community SafeWallet owners is paramount. If three private keys are compromised, it could allow an attacker to upgrade the vault.
  • The security of dependent protocols, such as EigenLayer, should also be actively monitored.
Sign up for the latest updates
#10: ThirdWeb Incident: Incompatibility Between Trusted Modules Exposes Vulnerability
Security Insights

#10: ThirdWeb Incident: Incompatibility Between Trusted Modules Exposes Vulnerability

This blog shows the vulnerability and attack caused by Incompatibility of commonly used modules.

#9: MEV Bot 0xd61492: From Predator to Prey in an Ingenious Exploit
Security Insights

#9: MEV Bot 0xd61492: From Predator to Prey in an Ingenious Exploit

On August 3, 2023, an MEV Bot on Arbitrum was attacked, resulting in $800K in loss. The root cause of this attack was **Insufficient User Input Verification**.

#8: SushiSwap Incident: A Clumsy Rescue Attempt Leads to a Series of Copycat Attacks
Case Studies

#8: SushiSwap Incident: A Clumsy Rescue Attempt Leads to a Series of Copycat Attacks

On April 9, 2023, SushiSwap became the target of an exploit due to an Unverified External Parameter. The total loss is about $3.3 million.

BlockSec uses cookies and other identifiers to analyze our traffic in accordance. We also share information about your use of our site with our analytics partners. By remaining on this website, you consent to our use of cookies and the Privacy Policy.