Vault fixes

[corddry]

No description provided.

[alcueca]

The first fix that modified maxMint and maxDeposit to pass on the receiver parameter to the underlying vault was the right one, if we follow the standard.

Note that the ethereum.org description of the standard has an error for maxWithdraw and maxRedeem. It's not "by the receiver":

It's "for the receiver":

The idea is to allow enabling blocklists at the vault level. If you are going to restrict holding vault shares by certain addresses, you would stop it both at transfer and deposit/mint. The maxDeposit/maxMint should reflect that.

It is a bit arbitrary, because blocklists could also be implemented on the function caller, and not just the token receiver, but that's what it is.

On limiting the return of maxRedeem/maxWithdraw to the minimum of the wrapped vault or wrapped vault holder is something I don't understand. The wrapped vault holder doesn't hold any shares of the underlying vault, so how would that work?

[kmbarry1]

Re this:

On limiting the return of maxRedeem/maxWithdraw to the minimum of the wrapped vault or wrapped vault holder is something I don't understand. The wrapped vault holder doesn't hold any shares of the underlying vault, so how would that work?

My understanding is that since shares in the wrapped vault are assigned 1:1 with the shares created in the underlying vault when a deposit occurs, the user's balanceOf is the maximum number of underlying vault shares they are entitled to redeem.

[kmbarry1]

However, it's only correct in the case of maxRedeem as previewWithdraw expects an argument that is assets, not shares.

[kmbarry1]

maxWithdraw needs to do something like VAULT.previewWithdraw(VAULT.convertToAssets(balanceOf[owner])) for the first arg to the min instead.

EDIT: in fact maybe just min(balanceOf[owner], VAULT.maxWithdraw(address(this))) is sufficient or even superior (should be the same up to rounding error).