BlazeSwapRewardManager Static Analysis Findings

BRM-01S: Data Location Optimization

Type	Severity	Location
Gas Optimization		BlazeSwapRewardManager.sol:L21

Description:

The linked input argument is set as memory in an external function.

Example:

Copy
21function changeProviders(address[2] memory providers) external onlyParent {

Recommendation:

We advise it to be set as calldata optimizing its read-access gas cost.

Alleviation:

The calldata optimization has been applied as advised.

BRM-02S: Inexistent Sanitization of Input Address

Type	Severity	Location
Input Sanitization		BlazeSwapRewardManager.sol:L15-L17

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
15constructor(IWNat _wNat) {
16    wNat = _wNat;
17}

Recommendation:

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

Alleviation:

The BlazeSwapRewardManager contract is created by the BlazeSwapDelegation contract which in turn retrieves the wNat address from the BlazeSwapManager that ultimately acquires the address from a native Flare Protocol module thus guaranteeing that it is non-zero. As a result, the check is not required and the exhibit can be nullified.

BRM-03S: Potential Lock of Native Assets

Type	Severity	Location
Language Specific		BlazeSwapRewardManager.sol:L19

Description:

The linked receive / fallback function performs no sanitization as to its caller and no function within the contract makes use of native balance at rest.

Impact:

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

Example:

Copy
19receive() 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 the function should be removed in its entirety.

Alleviation:

The BlazeSwap team stated that accidentally sent funds are meant to be consumed by the wrapRewards function and as such the current implementation is the desired one. As a result, we consider this exhibit as nullified.

BRM-04S: Improper Invocation of EIP-20 transfer

Type	Severity	Location
Standard Conformity		BlazeSwapRewardManager.sol:L47

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
47wNat.transfer(to, 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 BlazeSwap team stated that the invocation of transfer 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.