Skip to content
This repository has been archived by the owner on Jan 22, 2025. It is now read-only.

sherlock-audit/2025-01-peapods-finance

BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

36 Commits
.github/ISSUE_TEMPLATE
.github/ISSUE_TEMPLATE
 
 
contracts
contracts
 
 
fraxlend
fraxlend
 
 
.gitmodules
.gitmodules
 
 
README.md
README.md
 
 

Repository files navigation

Peapods contest details

Q&A

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

Ethereum, Arbitrum One, Base, Mode, Berachain

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?

The main consideration we have with respect to whitelisting tokens is for pod LP rewards in the system driven by a RewardsWhitelist.sol contract we deploy, so we do have a case of requiring whitelisting of tokens but we drive and control this functionality. We do not formally work with weird tokens.

Q: Are there any limitations on values set by admins (or other roles) in the codebase, including restrictions on array lengths?

For all access-controlled functions we have validations on restricting values at the beginning of the setters, so refer to those.

Q: Are there any limitations on values set by admins (or other roles) in protocols you integrate with, including restrictions on array lengths?

No

Q: Is the codebase expected to comply with any specific EIPs?

Many of our contracts implement ERC20 and ERC4626 which we attempt to comply with in the entirety of those standards for contracts that implement them.

Q: Are there any off-chain mechanisms involved in the protocol (e.g., keeper bots, arbitrage bots, etc.)? We assume these mechanisms will not misbehave, delay, or go offline unless otherwise specified.

Our protocol and its value proposition assumes the existence of arbitrage bots across markets. We have some partners we work with for them to implement their arbitrage bots to keep market prices across assets in sync (and drive the protocol flywheel ultimately).

We will also have liquidations for our fraxlend fork implementation, which can be executed by either bots we create or third parties (liquidations are not restricted to anyone in particular).

Q: What properties/invariants do you want to hold even if breaking them has a low/unknown impact?

For all vaults (ERC4626) we have in the system, the best case scenario is the collateral backing ratio (CBR, i.e. ratio of convertToAssets(shares) / shares) of the vault will always increase and never decrease. the scenario where this isn't necessarily the case is if bad debt is accrued on a lending pair. Otherwise outside of the case of bad debt we expect this CBR to only go upwards over time.

Q: Please discuss any design choices you made.

The main consideration for a design choice we made is in a few places we implement unlimited (100%) slippage for dex swaps. Our expectation is wherever we implement this behavior that almost any swap from token0 to token1 will be of small enough value that it would rarely, if ever, be profitable to sandwich for profit by a bot.

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

We have 3 audit reports by yAudit, Guardian, and Pashov:

Q: Please list any relevant protocol resources.

https://docs.peapods.finance/

https://peapods.finance/

Q: Additional audit information.

Our codebases have a lot of intertwined protocols and integrations, however the most critical are going to be ensuring

  1. WeightedIndex.sol, which is our core pod contract, is very secure as it will custody the most funds in the protocol
  2. StakingPoolToken.sol and AutoCompoundingPodLp.sol also custody a lot of funds so ensuring there are no exploit vectors is critical
  3. LeverageManager.sol contains the entry points addLeverage and removeLeverage where users will lever up and down their podded tokens and ultimately interact with the fraxlend fork to borrow funds among other things. There is a lot of underlying and somewhat complicated logic here but we want to make sure these two entry points are very secure and no vectors exist to drain funds.

Audit scope

contracts @ 964a6b30c8b3fab408b289ebb26835932086073f

fraxlend @ 5e8ac1c1341527b8eed24a21e9a77cee2ab6e892

About

No description, website, or topics provided.

Resources

Readme
Activity
Custom properties

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

No releases published

Packages

No packages published

Contributors 2

  •  
  •  

Languages