MetavisorBaseVault Static Analysis Findings

MBV-01S: Potential Lock of Native Assets

Type	Severity	Location
Language Specific		MetavisorBaseVault.sol:L101, L104

Description:

The linked receive / fallback functions perform no sanitization as to their caller and no function within the contract expects funds to have been received directly by the contract.

Impact:

Any native funds accidentally sent to the contract may be forever locked.

Example:

Copy
101receive() external payable {}

Recommendation:

We advise the code to properly prohibit accidental native assets from being permanently locked in the contract by introducing a require check restricting the msg.sender to the contract(s) expected to transfer assets to the system (i.e. in case of a wrapped native version of an asset, only the WXXX contract address should be allowed). Alternatively, if the contract is not expected to receive native assets directly the function should be removed in its entirety.

Alleviation:

The code was updated to omit the fallback code definition and to include an explicit check for the sender in the receive declaration, preventing funds from being accidentally locked within the contract.

MBV-02S: Improper Invocations of EIP-20 transfer

Type	Severity	Location
Standard Conformity		MetavisorBaseVault.sol:L92, L95

Description:

The linked statement do not properly validate the returned bool of the EIP-20 standard transfer function. As the standard dictates, callers must not assume that false is never returned.

Impact:

If the code mandates that the returned bool is true, this will cause incompatibility with tokens such as USDT / Tether as no such bool is returned to be evaluated causing the check to fail at all times. On the other hand, if the token utilized can return a false value under certain conditions but the code does not validate it, the contract itself can be compromised as having received / sent funds that it never did.

Example:

Copy
92token0.transfer(feeReceiver, (fees0 * feeNumerator) / DENOMINATOR);

Recommendation:

Since not all standardized tokens are EIP-20 compliant (such as Tether / USDT), we advise a safe wrapper library to be utilized instead such as SafeERC20 by OpenZeppelin to opportunistically validate the returned bool only if it exists in each instance.

Alleviation:

Both transfer instances have been replaced by their safe-prefixed counterparts, alleviating this exhibit.