sherlock-audit / 2024-05-beefy-cowcentrated-liquidity-manager

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Beefy Cowcentrated Liquidity Manager contest details

Q&A

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

any EVM-compatible network


Q: If you are integrating tokens, are you allowing only whitelisted tokens to work with the codebase or any complying with the standard? Are they assumed to have certain properties, e.g. be non-reentrant? Are there any types of weird tokens you want to integrate?

Standard ERC-20 tokens and USDC/USDT. We will not vault tokens that have a transfer tax.


Q: Are the admins of the protocols your contracts integrate with (if any) TRUSTED or RESTRICTED? If these integrations are trusted, should auditors also assume they are always responsive, for example, are oracles trusted to provide non-stale information, or VRF providers to respond within a designated timeframe?

We do our own safety review before building on top of underlying protocols. So you can assume them as TRUSTED.


Q: Are there any protocol roles? Please list them and provide whether they are TRUSTED or RESTRICTED, or provide a more comprehensive description of what a role can and can't do/impact.

The "rebalancer" role will be either gelato, which is TRUSTED, or a TRUSTED dev team rebalancer eoa.


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

The is rebalancer that will keep moving the ticks at a certain cadence. Harvesting is permissionless, but Beefy will also run a bot to harvest.


Q: Are there any hardcoded values that you intend to change before (some) deployments?

No


Q: If the codebase is to be deployed on an L2, what should be the behavior of the protocol in case of sequencer issues (if applicable)? Should Sherlock assume that the Sequencer won't misbehave, including going offline?

Can assume the sequencer will not misbehave.


Q: Should potential issues, like broken assumptions about function behavior, be reported if they could pose risks in future integrations, even if they might not be an issue in the context of the scope? If yes, can you elaborate on properties/invariants that should hold?

Yes


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

We know that swapping our fees via the router can cause loss due to lack of slippage/priceProtection, it is a known issue. We have mitigation in place via frequent harvest, harvesting via private rpcs, and a swapper oracle which will be implemented in the future.


Q: We will report issues where the core protocol functionality is inaccessible for at least 7 days. Would you like to override this value?

No


Q: Please list any relevant protocol resources.

https://docs.beefy.finance/beefy-products/clm


Audit scope

cowcentrated-contracts @ e1e5bc81c830700501624d6b2643b2e8ad5ecb91

About


Languages

Language:Solidity 91.9%Language:JavaScript 8.1%