Burve
Burve is a 16-token multi-swap for pegged assets launching on Berachain with rehypothecation yields, moving peg handling, an analytic stableswap solution, depeg-protection, and subset-LPing so users can limit themselves to tokens they feel safest in.
Details
Scope
On what chains are the smart contracts going to be deployed?
Berachain,
Monad,
Base,
Avalanche,
HyperLiquid L1
BSC,
Arbitrum
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.
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.
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.
Is the codebase expected to comply with any specific EIPs?
We conform to ERC-2535.
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.
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.
Please discuss any design choices you made.
Please provide links to previous audits (if any).
Please list any relevant protocol resources.
docs.burve.fi
burve.fi
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.
Total Rewards
Contest Pool
Lead Senior Watson
Judging Pool
Lead Judge
50,600 USDC
22,400 USDC
2,200 USDC
5,300 USDC
Status
Scope
Start Time
End Time
Judging Rules
