Context

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 impair()/ divest_vault(), etc)

Yearn vault v2 audit is very relevant. We stole a lot of their vyper code and have a similar architecture, trust assumptions, etc.

https://github.com/yearn/yearn-security/blob/master/audits/20210719_ToB_yearn_vaultsv2/ToB_-_Yearn_Vault_v_2_Smart_Contracts_Audit_Report.pdf

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 0 errors 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_DECIMALS size (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
• on impair + divest_vault we are reducing locked_profit as 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_fees which is notional instead of a ratio.
• Could still be used to manipulate share price in some way by *anyone* since impair ,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

Questions

1. thinks min_deposit will be an issue
2. share price
3. investing in other vaults probs an issue. seen a issues with other vault/4626 platforms

Next Steps

Halborn

1. Research Vyper lang based vulnerabilities
1. Security of last stable version
2. Any changes introduced between last stable version and current master branch of vyper
1. Vyper code commit @ 2023_03_05 - https://github.com/vyperlang/vyper/tree/8ebabc5ce277942ee470845e2d04df5f8a2e6ad6
2. raw_revert() is what we need for custom errors - code + tests

Debt DAO

1. (kiba) update our cost based on # engs that attended