Maybe more intro on Kiba?
- really bad at math
- Really bad at planning/organizing/documenting but really good at thinking so if you have a question I’ve probs thought about it already and have an answer but just havent written it down anywhere
- See Halborn as extension of our team. Pool arent completely finalized and frozen yet but still want your security expertise before we start moving into the more complex side of the pool contracts (e.g. taking on debt, snitch auctions) but only if you guys deem them as not the security risk to begin with.
- We’re also using a pretty bleeding edge stack. Vyper + Titanoboa are both fairly beta so also want to go over the custom code/tooling we’re using and get u guys familiar with it
Where we’re at with pools
- all basic static stuff tested (setting fees, updating owner, events emitted, etc.)
- Mostly dealing with known unknowns and unknown unknown problems now
- was this the right design decision to make
- complex multi-step attack patterns
- Are we incorrectly implementing ERCs
- what are we missing tests for?
- Main areas for testing:
- Share price
- Only real dynamic part of system. Everything depends on it
- ensure 4626 spec implemented properly (e.g. withdraw issue i found)
- General system invariants and game theory
- should we assume all lines/vaults are valid or add extra guardrails for pool delegates?
- More pool depositor protections from delegate
- share price manipulation attacks (exploiting fees/minflation, rounding errors, permissionless withdrawals from lines/vaults with
Yearn vault v2 audit is very relevant. We stole a lot of their vyper code and have a similar architecture, trust assumptions, etc.
Known Outstanding Issues
share price - Currently at 0 decimals but this means if vault price goes below 1:1 backing then price is automatically 0. This shouldnt be the case but i havent found any actual bugs caused by it yet, all expected behavior given price is 0. Potential fix: thinking about adding an arbitrary PRICE_DECIMALS padding to the price uint so we get more granularity
- Share prices
- issues with rounding at very small numbers (<1,000 a.k.a < 0.01 DAI) Could just document the edge case and hope pool never gets there or can ensure pool never reaches state by assert total_assets and total_supply must be > some minimum bounds.
- Consequences allowing price to be 0?
- Letting it be 0 fucks with code a lot bc it leads to
division by 0errors but also its technically accurate.
- currently setting vault floor price to 1 (.00000001 w/ decimals) but i could see that being an exploit vector to drain assets when price is below that point (but at that point the vault has basically lost all its assets so maybe an edge case we dont need to worry about)
- still getting rounding errors of
PRICE_DECIMALSsize (even before the variable existed). Not sure if its a disconnect between python and EVM math, an actual issue in the smart contract logic, or maybe something with boa.
- might be a bug in impair + divest_vault where no shares get burned but it says the assets do get burned bc of rounding errors or something. only noticed it on very small numbers but def something to investigate
divest_vaultwe are reducing
locked_profitas well as reducing
total_assets. They are separate vars that track different things but i wonder if we are double negating or what the consequences of not reducing locked_profits and only total_assets when we take a loss would be.
- Vyper + Titanoboa
- Running custom version of Titanoboa with Kiba’s personal mods for our testing framework
- No custom errors in Vyper
- Planning on using an unstable version of vyper that includes custom errors but pretty sure thats not worth the tradeoff for using string revert messages.
- Inherited from Yearn Vault
- Yearn #07 Strategy owner can reduce or bypass loss reporting
- same concept could be applicable for us although its mitigated by the separate
self.accrued_feeswhich is notional instead of a ratio.
- Could still be used to manipulate share price in some way by *anyone* since
collect_interest, and other share price changing functions are permissionless.
- Yearn #18 Locked-profit calculations
- we copied their fixed code already but worth a read nonetheless
- Exploit scenario might still be valid on our pools but a different attack vector than yearn bc we have different variables and flows
- Audit fix review by auditors says there is still a division by zero possibility
- ERC4626 Spec
- Issue with withdrawal logic that breaks 4626 standard. Dont burn accurate amount of shares
- thinks min_deposit will be an issue
- share price
- investing in other vaults probs an issue. seen a issues with other vault/4626 platforms
- Research Vyper lang based vulnerabilities
- Security of last stable version
- Any changes introduced between last stable version and current
masterbranch of vyper
- Vyper code commit @ 2023_03_05 - https://github.com/vyperlang/vyper/tree/8ebabc5ce277942ee470845e2d04df5f8a2e6ad6
raw_revert()is what we need for custom errors - code + tests
- (kiba) update our cost based on # engs that attended