Voter Static Analysis Findings

VRE-01S: Illegible Numeric Value Representation

Type	Severity	Location
Code Style		Voter.sol:L87

Description:

The linked representation of a numeric literal is sub-optimally represented decreasing the legibility of the codebase.

Example:

Copy
87return (IERC20(base).totalSupply() - IERC20(_ve).totalSupply()) / 10000;

Recommendation:

To properly illustrate the value's purpose, we advise the following guidelines to be followed. For values meant to depict fractions with a base of 1e18, we advise fractions to be utilized directly (i.e. 1e17 becomes 0.1e18) as they are supported. For values meant to represent a percentage base, we advise each value to utilize the underscore (_) separator to discern the percentage decimal (i.e. 10000 becomes 100_00, 300 becomes 3_00 and so on). Finally, for large numeric values we simply advise the underscore character to be utilized again to represent them (i.e. 1000000 becomes 1_000_000).

Alleviation:

The Xcaliswap team has NOT made any changes in the source code for this issue.

VRE-02S: Inexistent Sanitization of Input Addresses

Type	Severity	Location
Input Sanitization		Voter.sol:L55-L62

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
55constructor(address __ve, address _factory, address  _gauges, address _bribes) {
56    _ve = __ve;
57    factory = _factory;
58    base = IVotingEscrow(__ve).token();
59    gaugeFactory = _gauges;
60    bribeFactory = _bribes;
61    minter = msg.sender;
62}

Recommendation:

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

Alleviation:

The Xcaliswap team has introduced a require check ensuring that each address specified is non-zero.