Vault Updates

The functions in the VaultDepositooorV2 contract such as getMinimumDepositForTick, validateAmountForTick, and the validation performed in the _applyTickRounding function do not account for the minimum deposit nor the maximum deposit cap that is carried out in the lighter deposit contract.

For each asset, lighter configures an assetConfig.minDepositTicks and assetConfig.depositCapTicks. For example, the min deposit ticks is 100_000 for ETH, meaning that in fact the minimum deposit is 1e14 (100,000 gwei).

Any deposit that is below the minimum or would put the asset above it's cap is not allowed. This may be misleading for consumers of the view functions within the VaultDepositooorV2 contract and may lead to unexpected failure of bridging & depositing actions.

Consider if the minimum and cap should be factored into any of these view functions or even the validation in the _applyTickRounding function.

The depositBatch function on the AdditionalZkLighter deposit contract is not compatible with Fun’s just-in-time amount splicing since it includes several dynamic types in the function signature, with the _amount parameter itself being a dynamic type.

Only whitelist the deposit function and not the depositBatch function for invocation on the lighter deposit contract through the wrapper.

The lighter deposit contract has a cap per asset for the amount that can be deposited into the contract. If a deposit through the Fun system would put the lighter contract at or slightly below such a cap, a malicious actor could frontrun this deposit while the cross-chain deposit is in-flight and cause the deposit to instead put the system over the cap causing it to revert.

Simply be aware of this risk as it is unlikely and serves no straightforward benefit to the malicious actor, though it may happen benignly in practice.