BlazeSwapRouter Static Analysis Findings

BSR-01S: Inexistent Sanitization of Input Addresses

Type	Severity	Location
Input Sanitization		BlazeSwapRouter.sol:L24, L25

Description:

The linked function(s) accept address arguments yet do not properly sanitize them.

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
23constructor(
24    address _factory,
25    address _wNat,
26    bool _splitFee
27) {
28    factory = _factory;
29    wNat = _wNat;
30    splitFee = _splitFee;
31}

Recommendation:

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

Alleviation:

The BlazeSwap team considered this exhibit but opted not to apply a remediation for it as they have stated they will not remediate any issues of minor severity and below.

BSR-02S: Improper Invocation of EIP-20 transfer

Type	Severity	Location
Standard Conformity		BlazeSwapRouter.sol:L141

Description:

The linked statement does 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
141IBlazeSwapPair(pair).transferFrom(msg.sender, pair, liquidity); // send liquidity to pair

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 BlazeSwap team stated that the invocation of transferFrom is performed on a known contract implementation and as a result the safety logic described by the exhibit would incur an unnecessary increase in the cost of the function. As a result, we consider this exhibit nullified.