Prime Number Staking Contract

QuillAudits7 Apr 2025Files named in the report

Audit · firm’s term: audit report

QuillAudits reviewed Prime Numbers Labs (Prime Number Staking Contract) on 7 Apr 2025: 7 findings, 0 critical; 5 marked fixed, 2 open.

No open critical findings

Open the report Open Prime Numbers Labs’s security record

Report hosted on quillaudits.com.

Trustblock does not review code.

Findings7

Statuses are the security firm’s own, from its report.

Severity	Open	Fixed
Critical	0	0
High	0	0
Medium	0	2
Low	2	3

LowIncorrect Use of Custom Errors with require StatementsOpen

The contract defines custom errors like ZeroStakeAmount(), RewardApyTooHigh(), and others. These are intended to be used as a clearer and more efficient alternative to revert strings. However, in multiple places, these errors are incorrectly passed as arguments to require(): require(amount > 0, ZeroStakeAmount()); // incorrect This is not the correct pattern for using custom errors. According to Solidity documentation, custom errors should be used with an if statement followed by a revert: if (amount == 0) revert ZeroStakeAmount(); // correct Using require(..., CustomError()) still compiles because custom errors are interpreted as expressions, but this pattern is invalid as it leads to inconsistent error handling and poor readability.

LowMissing Checks for Math Operation Failures in Reward LogicOpen

Throughout the reward calculation logic in the contract, the code uses Solidity’s tryAdd, trySub, and tryMul functions from the Math library to perform arithmetic operations. These functions return a (bool success, uint256 result) and in the current implementation, the success flag is ignored in most cases. (bool success, uint256 result) = rewardPerToken().trySub(s.userRewardPerTokenPaid[account]); (success, result) = result.tryMul(balanceOf(account)); (success, result) = result.tryDiv(WHOLE); (success, result) = result.tryAdd(_rewards[account]);