-
Notifications
You must be signed in to change notification settings - Fork 81
Share prices can be inflated #83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Assuming 8 decimals for WBTC:
So I'm getting Maybe I misunderstood the example though. Anyway it's good to check this part because I did not have the time to make sure that it's correct |
Usually to do this kind of attacks you need to inflate the price per share (typically by a donation to the contract). To me here it's only doable through very high interests (which should not happen if the IRM is not crazy). Nice point of attention though. |
But @pakim249CAL 's point still stands with The point is that you can always end up with 1 share = 1 wei of asset. |
I can't say, it is a bit vague for me so I tried this example. I think it would be easier to understand with a counter-example with all the details, including the assets decimals, and an approximate expected price (this is why I took actual WBTC data) The idea for the In the counterexample, 1e10 shares are worth 1 WEI of WBTC, which seems ok. For ETH, 1 share is worth 1 WEI of ETH, which also seems ok |
Ah yes, there's no issue with having 1 share = 1 wei of asset a priori (and it's also the default edge case of OZ's ERC4626, with virtual shares offset being set at |
The shares offset being zero in OZ actually means that the offset is 1, since the offset is defined as 10**offset. |
Simply setting WAD to be the initial number of shares is vulnerable to the following:
Supply 1.000_000 WBTC for WAD shares.
Withdraw 0.999_999 WBTC for WAD - 1 shares, leaving 1 share left and 0.000_001 WBTC.
Now the intended precision in shares is lost.
The text was updated successfully, but these errors were encountered: