Skip to content

sherlock-audit/2025-04-burve

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

10 Commits
 
 
 
 
 
 

Repository files navigation

Burve contest details

Q&A

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

Berachain, Monad, Base, Avalanche, HyperLiquid L1 BSC, Arbitrum


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?

We handle some weird tokens. Weird tokens not handled:

  • Fee on Transfer
  • Revert on zero value approvals.

We allow for:

  • rebasing tokens
  • missing return values
  • flash mintable
  • approval race protected
  • decimals >=6 and <=18

Tokens without a decimal field are carefully selected by whether or not they imply a decimal of 18.


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

Owners and vetoers are trusted individuals (that will be decentralized over time). Owners are expected to set values appropriately. This means:

  • fee parameters all represent less than 100%.
  • Vertex vaults have acceptable risk tolerances and are expected to not lose token amounts. Currently they can only be ERC4626s.
  • The adjustors are properly configured.
  • The bgtExchanges are properly configured and are almost always funded with BGT.
  • New bgtExchange configurations use the previous one as a backup.
  • The station proxy properly collects bgt earnings and allows users to collect it from there.
  • The deMinimus in searchParams is smaller than 1e6.
  • esX128 for any token is less than 2^24 << 128.

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

Integrated tokens do not change their decimal value. Integrated vaults properly behave as ERC4626s.


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

We conform to ERC-2535.


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.

Off-chain systems will monitor any moving pegs and update the adjustor accordingly if that information is not available on-chain.


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

No closure can send out more tokens than its recorded balance. The "value" of the closure (according to the formulas) can never be more than deMinimus * (number of tokens in the closure) from the target value of the pool times number of tokens in the closure.


Q: Please list any relevant protocol resources.

docs.burve.fi burve.fi


Q: Additional audit information.

Primarily concerned if there is any potential for loss-of-funds and unfair earning distribution. Whether that be through exploits in logical errors in administration, balance management, or the accounting math.

Audit scope

Burve @ 945f30bfae8afc41af21305ff8c2271ca0ffe6c3

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Contributors 2

  •  
  •