Vault Deployment

[junkim012]

Notable Changes

VaultFactory msg.sender protection and VaultBytecode Separation

• Adds msg.sender protection to the CREATE2 salt.
• Separated out the VaultBytecode from VaultFactory due to codesize limit with the embedded Vault bytecode.

Vault _supplyToIonPool Early Exit (See Issue Below)

• In the _supplyToIonPool iteration, if the toSupply amount is small enoough to normalize to zero and this toSupply is the last remaining bit of the user's requested deposit amount, we skip the supply to avoid the revert. This has the effect of depositing to the IDLE pool and not the IonPool specified in the loop.
• In practice, the maximum amount that toSupply can be to truncate to zero when normalized is determined by:
  • maxBound = ceil(supplyFactor/ RAY) - 1
    • This means that if supplyFactor is between 1e27 + 1 and 2e27 - 1, then toSupply needs to be exactly 1. And in the next range 2e27 to 3e27 - 1, the toSupply needs to be exactly 2.
    • In practice, since supplyFactor will most likely never be above 2e27, the user will have to deposit an exact amount that ends up depositing exactly 1 wei as its last supply into the IonPool.
• Unrelated, but also prevents the feeRecipient from being set to the zero address.

Issue

• Reference issue here
• In the _supplyToIonPool iteration, if the toSupply amount is small enoough to normalize to zero, then it throws the IonPool.InvalidMintAmount error.
  • This meant that in some cases, if the user's requested deposit assets are being supplied through the loop, and if the last remaining bit to supply led to the InvalidMintAmount error, then the loop exited without being able to decrement assets down to zero, which reverts the transaction.
  • In this rare case, the user's deposit would have reverted despite having enough available room to deposit.
• This is not a problem in withdraw because the toWithdraw will never be zero when calling IonPool.withdraw which means the IonPool will round up and not throw InvalidBurnAmount.

[openzeppelin-code]

Vault Deployment

Generated at commit: 70c0db5ea39b3d0b11d9ca3145905b2d9aa8e7db

🚨 Report Summary

	Severity Level	Results
Contracts	Critical High Medium Low Note Total	2 2 0 12 39 55
Dependencies	Critical High Medium Low Note Total	0 0 0 0 0 0

---

For more details view the full report in OpenZeppelin Code Inspector