Pool Static Analysis Findings

PLO-01S: Data Location Optimizations

Type	Severity	Location
Gas Optimization		Pool.sol:L254

Description:

The linked input arguments are set as memory in external function(s).

Example:

Copy
254function updatePairs(uint256[] memory _fees, address[] memory _tokenAs, address[] memory _tokenBs, uint256[] memory _pricingModelIds) public {

Recommendation:

We advise them to be set as calldata optimizing their read-access gas cost.

Alleviation:

All referenced data location specifiers have been properly adjusted from memory to calldata, optimizing each variable's read-access gas cost.

PLO-02S: Inexistent Visibility Specifiers

Type	Severity	Location
Code Style		Pool.sol:L54, L57

Description:

The linked variables have no visibility specifier explicitly set.

Example:

Copy
54mapping(address => mapping(address => Pair)) pairs;

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:

A visibility specifier was introduced for the first referenced line of the exhibit, however, none was introduced for the second isPairAdded variable.

PLO-03S: Literal Equality of bool Variables

Type	Severity	Location
Gas Optimization		Pool.sol:L150, L236, L243

Description:

The linked bool comparisons are performed between variables and bool literals.

Example:

Copy
150require(verifySignature(_order, signature) == true, "Signature is invalid");

Recommendation:

We advise each bool variable to be utilized directly either in its negated (!) or original form.

Alleviation:

The literal equality of the first referenced bool variable has been properly omitted, however, no change was performed on the other two referenced lines.

PLO-04S: Inexistent Sanitization of Input Addresses

Type	Severity	Location
Input Sanitization		Pool.sol:L65-L82, L94-L97

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
65constructor(
66    address _treasury,
67    address _treasuryOwner,
68    address _signer,
69    address _pricingModelRegistry,
70    uint256[] memory _fees,
71    address[] memory _tokenAs,
72    address[] memory _tokenBs, 
73    uint256[] memory _pricingModelIds
74) EIP712("native pool", "1") {
75    treasury = _treasury;
76    treasuryOwner = _treasuryOwner;
77    isSigner[_signer] = true;
78    pricingModelRegistry = _pricingModelRegistry;
79    isPairAdded = false;
80    pairCount = 0;
81    executeUpdatePairs(_fees, _tokenAs, _tokenBs, _pricingModelIds);
82}

Recommendation:

We advise some basic sanitization to be put in place by ensuring that each address specified is non-zero.

Alleviation:

Input sanitization is now adequately performed for the four arguments in the first referenced code segment, however, the setRouter function referenced in the second code segment continues to not validate its input _router value.

PLO-05S: Potential Lock of Native Assets

Type	Severity	Location
Language Specific		Pool.sol:L92

Description:

The linked receive / fallback function performs no sanitization as to its caller and no function within the contract makes use of native balance at rest.

Impact:

Any native funds accidentally sent to the contract may be forever locked.

Example:

Copy
92receive() 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 the function should be removed in its entirety.

Alleviation:

The receive function has been safely omitted from the codebase as advised.