Omniscia Steadefi Audit
GMXPerpetualDEXLongVault Static Analysis Findings
GMXPerpetualDEXLongVault Static Analysis Findings
GMX-01S: Inexistent Event Emissions
Type | Severity | Location |
---|---|---|
Language Specific | GMXPerpetualDEXLongVault.sol:L345-L347, L353-L355, L363-L364, L370-L372 |
Description:
The linked functions adjust sensitive contract variables yet do not emit an event for it.
Example:
345function updateReader(IGMXPerpetualDEXLongReader _reader) external onlyOwner {346 reader = _reader;347}
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 (4325253d6de0ea91c1e9fb9e01d2e7e98f3d83a9):
All referenced assignment statements are now accompanied by an event
that properly signals their adjustment to off-chain observers, alleviating this exhibit.
GMX-02S: Literal Equality of bool
Variable
Type | Severity | Location |
---|---|---|
Gas Optimization | GMXPerpetualDEXLongVault.sol:L69 |
Description:
The linked bool
comparison is performed between a variable and a bool
literal.
Example:
69require(keepers[msg.sender] == true, "Keeper not approved");
Recommendation:
We advise the bool
variable to be utilized directly either in its negated (!
) or original form.
Alleviation (4325253d6de0ea91c1e9fb9e01d2e7e98f3d83a9):
The value of keepers[msg.sender]
is directly utilized in the referenced statement over a boolean comparison as advised.
GMX-03S: Inexistent Sanitization of Input Addresses
Type | Severity | Location |
---|---|---|
Input Sanitization | GMXPerpetualDEXLongVault.sol:L84-L94, L345-L347, L353-L355, L363-L364 |
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:
83*/84constructor (85 string memory _name,86 string memory _symbol,87 IERC20 _token,88 IChainLinkOracle _priceOracle,89 VaultConfig memory _vaultConfig,90 uint256 _capacityValue,91 uint256 _mgmtFeePerSecond,92 uint256 _perfFee,93 address _treasury94) ERC20(_name, _symbol) {95 token = _token;96 priceOracle = _priceOracle;97 vaultConfig = _vaultConfig;98 capacityValue = _capacityValue;99 mgmtFeePerSecond = _mgmtFeePerSecond;100 perfFee = _perfFee;101 treasury = _treasury;102 lastFeeCollected = block.timestamp;103}
Recommendation:
We advise some basic sanitization to be put in place by ensuring that each address
specified is non-zero.
Alleviation (4325253d6de0ea91c1e9fb9e01d2e7e98f3d83a9):
All input address
arguments referenced are adequately sanitized by each function's body by a corresponding require
check, preventing the contract's misconfiguration.
GMX-04S: Potential Lock of Native Assets
Type | Severity | Location |
---|---|---|
Language Specific | GMXPerpetualDEXLongVault.sol:L425 |
Description:
The linked receive
/ fallback
function performs no sanitization as to its caller and no function within the contract expects funds to have been received directly by the contract.
Impact:
Any native funds accidentally sent to the contract may be forever locked.
Example:
425receive() 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 directly the function should be removed in its entirety.
Alleviation (4325253d6de0ea91c1e9fb9e01d2e7e98f3d83a9):
The unused receive
fallback function has been safely removed from the codebase.