Omniscia Tangible Audit
Basket Static Analysis Findings
Basket Static Analysis Findings
BTE-01S: Inexistent Event Emissions
| Type | Severity | Location |
|---|---|---|
| Language Specific |  | Basket.sol:L371-L373, L381-L383, L390-L392 |
Description:
The linked functions adjust sensitive contract variables yet do not emit an event for it.
Example:
371function updateRebaseIndexManager(address _rebaseIndexManager) external onlyFactoryOwner {372 rebaseIndexManager = _rebaseIndexManager;373}Recommendation:
We advise an event to be declared and correspondingly emitted for each function to ensure off-chain processes can properly react to this system adjustment.
Alleviation (106fc61dcd38fe29a81d1984ccde9171f5f231af):
The Tangible team evaluated this exhibit but opted to acknowledge it in the current iteration of the codebase
BTE-02S: Improper Invocations of EIP-20 transfer
| Type | Severity | Location |
|---|---|---|
| Standard Conformity |  | Basket.sol:L737, L896 |
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:
737assert(primaryRentToken.transfer(address(_depositor), receivedRent));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 (106fc61dcd38fe29a81d1984ccde9171f5f231af):
The SafeERC20 library of the OpenZeppelin dependency is now properly imported to the codebase and its SafeERC20::safeTransfer function is correctly invoked in place of all potentially unhandled EIP-20 ERC20::transfer invocations, addressing this exhibit.