FlashLoan Static Analysis Findings

FLN-01S: Illegible Numeric Value Representations

Type	Severity	Location
Code Style		FlashLoan.sol:L36, L207

Description:

The linked representations of numeric literals are sub-optimally represented decreasing the legibility of the codebase.

Example:

Copy
36uint256 public constant FEE_DENOMINATOR = 1000;

Recommendation:

To properly illustrate each 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 (f6f1ad0b8f24a96ade345db1dd05a1878eb0f761):

The Tren Finance team evaluated this exhibit but opted to acknowledge it in the current iteration of the codebase.

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

Type	Severity	Location
Standard Conformity		FlashLoan.sol:L90, L174, L221

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
90IDebtToken(debtToken).transfer(msg.sender, _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 in each instance.

Alleviation (f6f1ad0b8f24a96ade345db1dd05a1878eb0f761):

The Tren Finance team evaluated this exhibit and opted to utilize the SafeERC20 library for the collateral token implementation as the debtToken implementation involved in the first two transfers referenced by the exhibit is known.

As such, we consider this exhibit addressed based on the fact that all transfers will behave as expected in the latest implementation.