fix: remove use of magic numbers in __ProvisionManager_init_unchained function (OZ N-11)

[MoonBoi9001]

Motivation:

• This PR addresses the following N-11 OZ audit issue, applying the recommended fixes.

Title:

N-11 Use Constants for Default Values

Details:

In the ProvisionManager contract, the __ProvisionManager_init_unchained function initializes multiple default values such as type(uint256).min, type(uint256).max, type(uint32).min, type(uint32).max, type(uint64).min, and type(uint64).max directly within the function body.

This approach introduces magic numbers, reducing code readability and maintainability. Moreover, it could potentially introduce errors since the same literal values are used in another part of the codebase as well. In addition, the verifierCutRange is set between 0 and uint32.max but the maximum should be set to MAX_PPM.

Consider revising all uses of literal values, defining constants for them where applicable, and setting a more sensible maximum value for verifierCutRange.

Key changes

• Removed the use of magic numbers inside the __ProvisionManager_init_unchained function, now using constants for default values.

[openzeppelin-code]

fix: remove use of magic numbers in __ProvisionManager_init_unchained function (OZ N-11)

Generated at commit: ffd1f79c1ec9b397de64be6ef8e7d3714b575ae0

🚨 Report Summary

	Severity Level	Results
Contracts	Critical High Medium Low Note Total	2 4 0 15 40 61
Dependencies	Critical High Medium Low Note Total	0 0 0 0 0 0

---

For more details view the full report in OpenZeppelin Code Inspector

[tmigone]

We also need to use these variables in SubgraphService.sol in the following functions:

• setMinimumProvisionTokens
• _getThawingPeriodRange
• _getVerifierCutRange

That contract inherits from ProvisionManager.sol so the variables should be available.

[tmigone]

I think better names for these would be tied to the range they are describing. For example, instead of DEFAULT_MIN_UINT256 and DEFAULT_MAX_UINT256 you would have DEFAULT_MIN_PROVISION_TOKENS and DEFAULT_MAX_PROVISION_TOKENS and so forth.

[tmigone]

Here I would use DEFAULT_MAX_VERIFIER_CUT

[tmigone]

We also need to use these variables in SubgraphService.sol in the following functions:

• setMinimumProvisionTokens
• _getThawingPeriodRange
• _getVerifierCutRange

[MoonBoi9001]

I made a few of these internal so they can be inherited.

    // Constants
    uint32 private constant DEFAULT_MIN_VERIFIER_CUT = type(uint32).min;
    uint32 internal constant DEFAULT_MAX_VERIFIER_CUT = uint32(PPMMath.MAX_PPM);
    uint64 private constant DEFAULT_MIN_THAWING_PERIOD = type(uint64).min;
    uint64 internal constant DEFAULT_MAX_THAWING_PERIOD = type(uint64).max;
    uint256 private constant DEFAULT_MIN_PROVISION_TOKENS = type(uint256).min;
    uint256 internal constant DEFAULT_MAX_PROVISION_TOKENS = type(uint256).max;

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.51%. Comparing base (374f57d) to head (f8e39df).
Report is 18 commits behind head on horizon.

Additional details and impacted files

@@           Coverage Diff            @@
##           horizon    #1041   +/-   ##
========================================
  Coverage    92.51%   92.51%           
========================================
  Files           46       46           
  Lines         2392     2392           
  Branches       428      428           
========================================
  Hits          2213     2213           
  Misses         179      179           

Flag	Coverage Δ
unittests	92.51% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tmigone]

Couple nits!

[tmigone]

💎