Blueberry Update #2 contest details

Join Sherlock Discord
Submit findings using the issue page in your private contest repo (label issues as med or high)
Read for more details

Quick Note

There was a scoping mistake in Blueberry Update #1 (too many new contracts in scope for the short contest length), so Blueberry Update #2 (this contest) is meant to be a continuation of Blueberry Update #1 (same scope, except CurveSpell.sol is removed), and the issues expected to be valid in Blueberry Update #1 (using a snapshot taken of the Lead Judge's judgments for Blueberry Update #1 on May 3, 2023) are not valid to submit in Blueberry Update #2. Please see the two tables under "Please list any known issues/acceptable risks that should not result in a valid finding" for a complete list of the 39 issues that are out-of-scope for this contest.

Q&A

Q: On what chains are the smart contracts going to be deployed?

Mainnet, Arbitrum

Q: Which ERC20 tokens do you expect will interact with the smart contracts?

Whitelisted

Q: Which ERC721 tokens do you expect will interact with the smart contracts?

Uni-v3 LP tokens & Whitelisted ERC721

Q: Which ERC777 tokens do you expect will interact with the smart contracts?

none

Q: Are there any FEE-ON-TRANSFER tokens interacting with the smart contracts?

none

Q: Are there any REBASING tokens interacting with the smart contracts?

none

Q: Are the admins of the protocols your contracts integrate with (if any) TRUSTED or RESTRICTED?

Trusted

Q: Is the admin/owner of the protocol/contracts TRUSTED or RESTRICTED?

Trusted - Multisig wallet with multiple members

Q: Are there any additional protocol roles? If yes, please explain in detail:

none

Q: Is the code/contract expected to comply with any EIPs? Are there specific assumptions around adhering to those EIPs that Watsons should be aware of?

none

Q: Please list any known issues/acceptable risks that should not result in a valid finding.

Rebasing tokens, tokens that change balance on transfer, with token burns, etc, are not compatible with the system and should not be whitelisted.
Centralization risk is known: the DAO multi-sig for the protocol is able to set the various configurations for the protocol.

Please note: There are 2 lists of out-of-scope issues for this contest (39 out-of-scope issues in total):

The first list of 6 issues were labeled "Won't Fix" in the first Blueberry contest:

Issue description	GitHub Issue
ChainlinkAdapterOracle use BTC/USD chainlink oracle to price WBTC which is problematic if WBTC depegs	Link
ChainlinkAdapterOracle will return the wrong price for asset if underlying aggregator hits minAnswer	Link
LP tokens cannot be valued because ICHI cannot be priced by oracle, causing all new open positions to revert	Link
Complete debt size is not paid off for fee on transfer tokens, but users aren't warned	Link
If a token's oracle goes down or price falls to zero, liquidations will be frozen	Link
The maximum size of an `ICHI` vault spell position can be arbitrarily surpassed	Link

The second list of 33 issues are those expected to be rewarded from Blueberry Update #1:

Issue description	GitHub Issue
Borrower can't repay but can be liquidated as token whitelist can prevent existing positions from repaying	Link
Accrue function is not called before executing some functions	Link
Transaction will revert when using USDT tokens (or other non-compliant ERC20 tokens)	Link
IchiVaultOracle getPrice will fail during price crashes	Link
auraPools.deposit and auraPools.withdraw boolean return value not handled in WAuraPools.sol	Link
AuraSpell openPositionFarm does not join pool	Link
The protocol will not be able to add liquidity on the curve with another token with a balance.	Link
Dos attack to openPositionFarm()	Link
Users can fail to closePositionFarm and lose their funds	Link
Potential DOS / lack of acccess to oracle price due to unhandled chainlink revert	Link
`getPositionRisk()` will return a wrong value of risk	Link
BlueBerryBank#getPositionValue causes DOS if reward token is added that doens't have an oracle	Link
Issue 290 from previous contest has not been fully addressed by fixes	Link
Issue 94 from previous contest has not been fixed	Link
AuraSpell#openPositionFarm uses incorrect join type for balancer	Link
Users are forced to swap all reward tokens with no slippage protection	Link
AuraSpell#closePositionFarm requires users to swap all reward tokens through same router	Link
Potential flash loan attack vulnerability in `getPrice` function of CurveOracle	Link
ConvexSpell#closePositionFarm removes liquidity without any slippage protection	Link
Issue 327 from previous contest has not been fixed	Link
ShortLongSpell#_withdraw checks slippage limit but never applies it making it useless	Link
WAuraPools will irreversibly break if reward tokens are added to pool after deposit	Link
rewardTokens removed from WAuraPool/WConvexPools will be lost forever	Link
UserData for balancer pool exits is malformed and will permanently trap users	Link
IchiSpell applies slippage to sqrtPrice which is wrong and leads to unpredictable slippage	Link
UniswapV3 sqrtRatioLimit doesn't provide slippage protection and will result in partial swaps	Link
Balance check for swapToken in ShortLongSpell#_deposit is incorrect and will result in nonfunctional contract	Link
ShortLongSpell#openPosition can cause user unexpected liquidation when increasing position size	Link
Pending CRV rewards are not accounted for and can cause unfair liquidations	Link
WIchiFarm#pendingRewards suffers from significant precision loss causing loss of rewards	Link
`BalancerPairOracle` can be manipulated using read-only reentrancy	Link
Missing checks for whether Arbitrum Sequencer is active	Link
Deadline check is not effective, allowing outdated slippage and allow pending transaction to be unexpected executed	Link

Note: Why so many out-of-scope issues? There was a mistake in scoping for Blueberry Update #1 (too many new contracts in scope for the short contest length), so Blueberry Update #2 (this contest) is really just a continuation of Blueberry Update #1 (same scope, except CurveSpell.sol is removed), except the issues expected to be valid in Blueberry Update #1 (using a snapshot taken of the Lead Judge's judgments on May 3, 2023) are not valid to submit in Blueberry Update #2.

Q: Please provide links to previous audits (if any).

Sherlock audit - https://github.com/sherlock-audit/2023-02-blueberry-judging/issues

Update 1 - https://github.com/sherlock-audit/2023-04-blueberry-judging

Q: Are there any off-chain mechanisms or off-chain procedures for the protocol (keeper bots, input validation expectations, etc)?

none

Q: In case of external protocol integrations, are the risks of external contracts pausing or executing an emergency withdrawal acceptable? If not, Watsons will submit issues related to these situations that can harm your protocol's functionality.

We utilize chainlink price feeds as the primary source, if they are paused it may result in stale pricing or reverting transactions. But the system utilizes an aggregated oracle approach to avoid those issues.

Additionally, the external protocol integrations are all the of the spells as that is how we handle deployments/strategies to those external protocols. This is why that all Spells are whitelisted and added through the DAO multi-sig and not permissionless as they have to go through an on-boarding process.

Audit scope

blueberry-core @ 25cf493e536e7c5d895bb7c712ce6ba0f3cb03c9

tsueti / 2023-05-blueberry Goto Github PK

2023-05-blueberry's Introduction

Blueberry Update #2 contest details

Quick Note

Q&A

Q: On what chains are the smart contracts going to be deployed?

Q: Which ERC20 tokens do you expect will interact with the smart contracts?

Q: Which ERC721 tokens do you expect will interact with the smart contracts?

Q: Which ERC777 tokens do you expect will interact with the smart contracts?

Q: Are there any FEE-ON-TRANSFER tokens interacting with the smart contracts?

Q: Are there any REBASING tokens interacting with the smart contracts?

Q: Are the admins of the protocols your contracts integrate with (if any) TRUSTED or RESTRICTED?

Q: Is the admin/owner of the protocol/contracts TRUSTED or RESTRICTED?

Q: Are there any additional protocol roles? If yes, please explain in detail:

Q: Is the code/contract expected to comply with any EIPs? Are there specific assumptions around adhering to those EIPs that Watsons should be aware of?

Q: Please list any known issues/acceptable risks that should not result in a valid finding.

Q: Please provide links to previous audits (if any).

Q: Are there any off-chain mechanisms or off-chain procedures for the protocol (keeper bots, input validation expectations, etc)?

Q: In case of external protocol integrations, are the risks of external contracts pausing or executing an emergency withdrawal acceptable? If not, Watsons will submit issues related to these situations that can harm your protocol's functionality.

Audit scope

Recommend Projects

Recommend Topics

Recommend Org