ERC20VestableInTimestamp Code Style Findings

ERC-01C: Declaration Simplification

Description:

The TEN_YEARS_SECONDS can be declared by using the SECONDS_PER_DAY variable and multiplying it by the corresponding literals.

Example:

Copy
13uint256 private constant TEN_YEARS_SECONDS = 60 * 60 * 24 * 365 * 10; /* Seconds in ten years */
14uint256 private constant SECONDS_PER_DAY = 24 * 60 * 60; /* 86400 seconds in a day */

Recommendation:

We advise it to be done so to increase the verbosity of the system at no cost.

Alleviation:

The verbosity we recommended was applied to the codebase correctly.

ERC-02C: Misleading Variable Naming Convention

Description:

The linked variables' naming convention indicates that they are meant to represent a "day" whilst they are actually representing a second-based timestamp.

Example:

Copy
18/**
19 * Vesting Schedule
20 */
21struct VestingSchedule {
22    string scheduleName;    // Name of vesting schedule.
23    bool isActive;          // Status of available.
24    uint256 startDay;       // Timestamp of vesting schedule beginning.
25    uint256 cliffDuration;  // A period of time which token be locked.
26    uint256 duration;       // A period of time which token be released from 0 to max vesting amount.
27}
28
29/**
30 * User's vesting information in a schedule
31 */
32struct VestingForAccount {
33    string scheduleName;
34    uint256 amountVested;
35    uint256 amountNotVested;
36    uint256 amountOfGrant;
37    uint256 vestStartDay;
38    uint256 cliffDuration;
39    uint256 vestDuration;
40    bool isActive;
41}

Recommendation:

We advise them to be renamed across the codebase as "timestamps" instead of "days" to increase the legibility of the codebase.

Alleviation:

The variable was properly renamed to represent time as startTimestamp.

ERC-03C: Redundant Visibility Specifier

Description:

The linked variable is meant to act as a project constant but is instead declared as public.

Example:

Copy
9bytes32 public constant GRANTOR_ROLE = keccak256("GRANTOR_ROLE");

Recommendation:

We advise it to be set as internal or private to avoid redundant bytecode generation.

Alleviation:

The GRANTOR_ROLE is now properly declared as an internal variable.