Multiswap Static Analysis Findings

MPA-01S: Illegible Numeric Value Representation

Type	Severity	Location
Code Style		Multiswap.sol:L42, L45, L54, L86

Description:

The linked representation of a numeric literal is sub-optimally represented decreasing the legibility of the codebase.

Example:

Copy
42require(msg.value > 0 && msg.value > 10000, "no ETH sent");

Recommendation:

To properly illustrate the value's purpose, we advise the following guidelines to be followed. For values meant to depict fractions with a base of 1e18, we advise fractions to be utilized directly (i.e. 1e17 becomes 0.1e18) as they are supported. For values meant to represent a percentage base, we advise each value to utilize the underscore (_) separator to discern the percentage decimal (i.e. 10000 becomes 100_00, 300 becomes 3_00 and so on). Finally, for large numeric values we simply advise the underscore character to be utilized again to represent them (i.e. 1000000 becomes 1_000_000).

Alleviation:

The Xcaliswap team has partially fixed this issue by removing the illegible representations from two instances (L42 & L54).

MPA-02S: Inexistent Sanitization of Input Address

Type	Severity	Location
Input Sanitization		Multiswap.sol:L11-L13

Description:

The linked function accepts an address argument yet does not properly sanitize it.

Impact:

The presence of zero-value addresses, especially in constructor implementations, can cause the contract to be permanently inoperable. These checks are advised as zero-value inputs are a common side-effect of off-chain software related bugs.

Example:

Copy
11constructor(address _router) {
12    router = _router;
13}

Recommendation:

We advise some basic sanitization to be put in place by ensuring that the address specified is non-zero.

Alleviation:

The Xcaliswap team has introduced a require check ensuring that the address specified is non-zero.

MPA-03S: Improper Invocation of EIP-20 transferFrom

Type	Severity	Location
Standard Conformity		Multiswap.sol:L56

Description:

The linked statement does not properly validate the returned bool of the EIP-20 standard transferFrom 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
56IERC20(_token).transferFrom(msg.sender, address(this), _amount);

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.

Alleviation:

The Xcaliswap team has introduced a require check ensuring that the returned boolean value is true but this new check will fail in the case of ERC20 tokens which do not return any boolean value.