Regarding inflation attacks

Please see GitHub issue #3706↗ in the openzeppelin-contract repository for discussion about how to mitigate this attack.

In short, the first deposit to a new vault could be made by a trusted admin during vault construction to ensure that totalSupply remains greater than zero. However, this remediation has the drawback that this deposit is essentially locked, and it needs to be high enough relative to the first few legitimate deposits so that front-running them is unprofitable. However, even if this prevents the attack from being profitable, an attacker can still grief legitimate deposits with donations, making the user gain less shares than they should have gained.

Also, the ERC4626Upgradeable OpenZeppelin contract↗ explains their proposed solution to this type of attack:

The _decimalsOffset() corresponds to an offset in the decimal representation between the underlying asset's decimals and the vault decimals. This offset also determines the rate of virtual shares to virtual assets in the vault, which itself determines the initial exchange rate.

While not fully preventing the attack, analysis shows that the default offset (0) makes it non-profitable, as a result of the value being captured by the virtual shares (out of the attacker's donation) matching the attacker's expected gains. With a larger offset, the attack becomes orders of magnitude more expensive than it is profitable.

We do not expect it to be an issue, but in general we recommend atomically deploying vaults and depositing some initial amount.