pufferfinance / pufeth Goto Github PK

• Operations multisig needs to go through a timelock
• Community multisig can do things instantly

Refactor the codebase so that we can have unit tests because right now everything is hardcoded for the mainnet fork tests

stETH rebasing creates arbitrage opportunities

Severity: Low
Difficulty: Medium
Type: Timing
Target: src/PufferVaultV2.sol

Description

The PufferVaultV2 accepts deposits of stETH, wETH, and regular ETH. When computing the total assets deposited in the vault, the totalAssets function is used. It computes the total deposited amount of stETH, wETH, and ETH, including any amounts deposited in Eigenlayer and Lido. However the function computes the deposited amount of stETH using stETH.balanceOf(). Because stETH is a rebasing token, this creates an arbitrage opportunity. By depositing right before an stETH rebase and withdrawing right after, an opportunistic actor can get extra wETH.

Exploit Scenario

Before the Lido oracle updates the price of stETH, Eve, a malicious user, deposits wETH into the PufferV2Vault. After the oracle update, Eve burns her shares to receive even more wETH than she deposited.

Recommendations

Short term, store the total shares of the Puffer vault rather than the balance directly. Alternatively consider using wstETH instead.

Long term, keep up to date with the documentation regarding any external dependencies.

• Upgradeable smart contract
• Interacts with Sushiswap's backend to find the best swap route from token X to stETH
• It should allow users to swap any ERC20 to stETH
• Depending on the amount of stETH received from the swap, we will mint user pufETH
• Contract must support Permit / normal approval

Swap on front end using sushiswap endpoint to query best path

• Add an integration test with the latest USDC code https://www.circle.com/blog/announcing-usdc-v2.2
• Add an integration test when depositing wstETH with Permit and without the Permit

• Unit tests

• separate the erc20 logic from the EigenLayer / Lido / PufferPool logic
• make upgradeable
• add docs for running tests
• adds docs for what is being tested

At the end of Chapter 1, we will:

1. withdraw ETH from Lido
2. deposit ETH into PufferPool

During this transition, the reserve currency of pufETH will switch from stETH to rPufETH. However, the circulating pufETH will not change. We need to track the conversion rate between pufETH to rPufETH for future deposits into the PufETH contract.

Should be a 2-step process of queueing and claiming after a 7 day delay

setWithdrawalLimit does not reset assetsWithdrawnToday

Severity: Medium
Difficulty: Medium
Type: Data Validation
Target: src/PufferVaultV2.sol

Description

The PufferVaultV2 has a withdrawal limit that can be configured by the DAO. This withdrawal limit is designed to ensure that there are at most a maximum number of outflows per day from the vault. When updating the withdrawal limit, the setWithdrawalLimit function is used. Crucially, however, this function does not reset the assetsWithdrawnToday state variable. As a result, if the withdrawal limit is set to be lower than assetsWithdrawnToday, the getRemainingAssetsDailyWithdrawalLimit function will always return 0 instead of dailyAssetsWithdrawalLimit. As a result, the withdraw and redeem functions will revert unless called with an amount of 0.

Exploit Scenario

The current amount of withdrawn assets is 90 ether. Alice, the admin of the PufferVaultV2, changes the withdrawal limit to 80 ether. Bob, a staker, is unable to call redeem and get back his wETH in exchange for his shares.

Recommendations

Short term, make sure to reset the assetsWithdrawnToday variable when changing the withdrawal limit.

Long term, improve unit testing to uncover edge cases and ensure intended behavior throughout the system.

https://portal.1inch.dev/documentation/swap/swagger?method=get&path=%2Fv5.2%2F1%2Fswap

Validator ticket purchase can revert due to strict equality

Severity: Informational
Difficulty: Medium
Type: Data Validation
Target: src/ValidatorTicket.sol

Description

Validator tickets are used by participants in the Puffer Protocol as collateral in order to become validators. When buying a validator ticket, the following strict comparison is used:

https://github.com/PufferFinance/PufferPool/blob/3684282e45e0e777e7fe6e9e2c005560a6579eda/src/ValidatorTicket.sol#L82-L90
In the event of a misestimation or user error, validator ticket purchases can revert, causing a user to have to waste gas.

Exploit Scenario

Bob, a user, wants to purchase validator tickets but mistakenly sends a bit more ether than the price of 1 validator ticket. His transaction reverts and he wastes some gas.

Recommendations

Short term, try to accept a range of deposits and refund users the remaining value unused to purchase validator tickets.

Long term, improve unit testing to uncover ways in which transactions can revert, and determine their impact.

updateDailyWithdrawals does not emit an event

Severity: Low
Difficulty: Low
Type: Auditing and Logging
Target: src/PufferVaultV2.sol

Description

The Puffer Vault V2's updateDailyWithdrawals function does not emit an event despite making a state changing operation. As a result of this, components that handle events offchain may not react to any updates of the daily withdrawal limit.

Recommendations

Short term, make the updateDailyWithdrawals function emit an event.

Long term, ensure all state-changing operations emit events appropriately.

Should be a 2-step process

The user should be able to deposit wstETH via Permit.
We redeem stETH by unwrappin wstETH, and deposit stETH to our pool minting pufETH to our user.

Hey! My username on puffer is korol_pryanikov, I wanted to point out an issue with points.

Basically, you can earn free points by swapping puffeth for steth , deposit steth again and cycle up the process to get more points and eth number on the dashboard.

I think it is worth fixing to erase the unfairness .

Sincerely yours,
M

Seth mining

Vault withdrawals and redemptions can revert

Severity: Medium
Difficulty: Low
Type: Timing
Target: src/PufferVaultV2.sol

Description

Because collateral from the vault is used to provision validators, there can be periods where there is a shortage of collateral in the vault. As a result, withdrawals and redemptions will revert.

The PufferVaultV2 contract's withdrawal and redemption functions both call the _wrapETH() function. This function calculates the wETH balance of the contract, and attempts to call wETH.deposit(). However, there may not be enough ether in the contract due to the transferETH() function. This function transfers ether out of the vault to fund validators, and is expected to be called frequently. As a result, unless the vault has sufficient wETH or ETH deposits, the _wrapETH() function will revert and so will withdrawals/redemptions.

Exploit Scenario

Bob, a user, deposits stETH into the Vault and receives shares in return. After a while, the Vault has been rapidly funding validators and as a result does not have enough ether or wETH to allow Bob to withdraw his stETH. As a result the call to wETH.deposit() will fail and Bob's tokens are stuck in the contract.

Recommendations

Short term, try to wrap stETH to ETH to always ensure that the Vault will have enough wETH to service withdrawals and redemptions.

Long term, improve unit testing to uncover edge cases and ensure intended behavior in the system. Try to have tests replicate on-chain conditions as much as possible.

In the current version we are doing lido withdrawal atomically (mainnet integration test), but in real-world scenario we need to account for the withdrawals that are pending.
The code currently doesn't care about that

An attacker can DOS withdrawals

Severity: High
Difficulty: Medium
Type:Denial of Service
Target: src/PufferVaultV2.sol

Description

The Puffer Vault is a 4626 compliant vault implementation that allows users to deposit ETH, wETH, and stETH in exchange for rewards. Currently, the vault has a daily withdrawal limit that restricts the amount that can be withdrawn from the vault.
However, an attacker can take a flashloan, deposit their flashloaned tokens into the protocol, and then immediately withdraw their deposit. This exhausts the withdrawal limit and as a result users will be unable to withdraw their tokens.

Exploit Scenario

Bob, a user of the Puffer Protocol, wants to burn some of his vault shares and reclaim his wETH. Eve, an attacker, sees his transaction in the mempool. She then proceeds to flashloan 100 ether and immediately deposit and withdraw in the same transaction. Bob's withdrawal transaction reverts because the withdrawal limit is exhausted.

Recommendations

Short term, validate that users have held their deposits for a minimum amount of time in order to prevent an attacker from exhausting the withdrawal limit with a flashloan.

Long term, ensure that the protocol is robust against transaction reordering or atomic deposits/withdrawals.

Good