Omniscia Avant Protocol Audit
AvUSDSilo Static Analysis Findings
AvUSDSilo Static Analysis Findings
AUD-01S: Inexistent Sanitization of Input Addresses
| Type | Severity | Location |
|---|---|---|
| Input Sanitization |  | AvUSDSilo.sol:L17-L20 |
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:
17constructor(address stakingVault, address avusd) {18 _STAKING_VAULT = stakingVault;19 _AVUSD = IERC20(avusd);20}Recommendation:
We advise some basic sanitization to be put in place by ensuring that each address specified is non-zero.
Alleviation:
All input arguments of the AvUSDSilo::constructor function are adequately sanitized as non-zero in the latest in-scope revision of the codebase, addressing this exhibit.
AUD-02S: Inexistent Visibility Specifiers
| Type | Severity | Location |
|---|---|---|
| Code Style | | AvUSDSilo.sol:L14, L15 |
Description:
The linked variables have no visibility specifier explicitly set.
Example:
14address immutable _STAKING_VAULT;Recommendation:
We advise them to be set so to avoid potential compilation discrepancies in the future as the current behaviour is for the compiler to assign one automatically which may deviate between pragma versions.
Alleviation:
The public visibility specifier has been introduced to all referenced variables, preventing potential compilation discrepancies and addressing this exhibit.
AUD-03S: Improper Invocation of EIP-20 transfer
| Type | Severity | Location |
|---|---|---|
| Standard Conformity |  | AvUSDSilo.sol:L28 |
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:
28_AVUSD.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 SafeERC20 library of the OpenZeppelin dependency is now properly imported to the codebase and its SafeERC20::safeTransfer function is correctly invoked in place of the potentially unhandled EIP-20 ERC20::transfer invocation, addressing this exhibit.