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:

Copy
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:

Copy
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:

Copy
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 _treasury
94) 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:

Copy
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.