CoinFabrik was asked to audit the contracts for the PulseINU project. The audited files are from the git repository. The audit is based on the commit
Fixes were checked on commit
During this audit we found one critical issue, one minor issue and no medium issues. Also, an enhancement was proposed. All issues were fixed.
The scope for this audit includes and is limited to the following files:
contracts/PulseInu.sol: Main token contract.
contracts/interfaces/IPulseInu.sol: Token interface.
scripts/deploy.js: Deployment script.
No other files in this repository were audited. Its dependencies are assumed to work according to their documentation. Also, no tests were reviewed for this audit.
CoinFabrik was provided with the source code. Our auditors spent one week auditing the source code provided, which includes understanding the context of use, analyzing the boundaries of the expected behavior of each contract and function, understanding the implementation by the development team (including dependencies beyond the scope to be audited) and identifying possible situations in which the code allows the caller to reach a state that exposes some vulnerability. Without being limited to them, the audit process included the following analyses:
- Arithmetic errors
- Outdated version of Solidity compiler
- Race conditions
- Reentrancy attacks
- Misuse of block timestamps
- Denial of service attacks
- Excessive gas usage
- Missing or misused function qualifiers
- Needlessly complex code and contract interactions
- Poor or nonexistent error handling
- Insufficient validation of the input parameters
- Incorrect handling of cryptographic signatures
- Centralization and upgradeability
After delivering a report with our findings, the development team had the opportunity to comment on every finding and fix the issues they considered convenient. Once fixed and/or commented, our team ran a second review process to verify that the changes to the code effectively solve the issues found and do not unintentionally add new ones. This report includes the final status after the second review.
In the following table we summarize the security issues we found in this audit. The severity classification criteria and the status meaning are explained below. This table does not include the enhancements we suggest to implement, which are described in a specific section after the security issues.
|CR-01||Incorrect Calculation Of INITIAL_SUPPLY||Critical||Resolved|
|MI-01||Loss Of Precision Due To Multiplication After Division||Minor||Resolved|
Security risks are classified as follows:
- Critical: These are issues that we manage to exploit. They compromise the system seriously. They must be fixed immediately.
- Medium: These are potentially exploitable issues. Even though we did not manage to exploit them or their impact is not clear, they might represent a security risk in the near future. We suggest fixing them as soon as possible.
- Minor: These issues represent problems that are relatively small or difficult to take advantage of, but might be exploited in combination with other issues. These kinds of issues do not block deployments in production environments. They should be taken into account and be fixed when possible.
An issue detected by this audit has one of the following statuses:
- Unresolved: The issue has not been resolved.
- Acknowledged: The issue remains in the code, but is a result of an intentional decision.
- Resolved: Adjusted program implementation to eliminate the risk.
- Partially resolved: Adjusted program implementation to eliminate part of the risk. The other part remains in the code, but is a result of an intentional decision.
- Mitigated: Implemented actions to minimize the impact or likelihood of the risk.
Critical Severity Issues
CR-01 Incorrect Calculation Of INITIAL_SUPPLY
INITIAL_SUPPLY variable stores PINU tokens. In the function
claimFreeClaimer(), the variable airdropAmount is added to it. This variable airdropAmount is then multiplied by the decimals, so the correct value can be minted.
But in the contract math operations, it’s expected that
INITIAL_SUPPLY must be the full token value, including decimals, so the function
claimFreeCliamer() is calculating
Multiply the airdropAmount value by the decimals before adding it to
INITIAL_SUPPLY variable is now correctly calculated.
Medium Severity Issues
No issues found.
Minor Severity Issues
MI-01 Loss Of Precision Due To Multiplication After Division
ClaimReferrer() function, the variable _referrerAmount contains the result of several divisions and multiplications. Due to the nature of integer arithmetic, a division will produce a loss of precision in the final result, that is then amplified by the subsequent multiplication.
Refactor the calculation so all multiplications are done first, and then all divisions.
Resolved. The calculation is now done in the correct order.
These items do not represent a security risk. They are best practices that we suggest implementing.
|EN-01||Reentrancy Guards Not Needed||Not implemented|
EN-01 Reentrancy Guards Not Needed
As the contract does not call any external functions, nor has any callback functionality, reentrancy guards are not needed.
The considerations stated in this section are not right or wrong. We do not suggest any action to fix them. But we consider that they may be of interest to other stakeholders of the project, including users of the audited contracts, token holders or project investors.
After the minting period is over, the address at
OWNER_ADDRESS can always withdraw all funds from the contract using the function withdraw().
No mechanism for upgrade is provided by the audited contract.
These are the privileged roles that we identified on each of the audited contracts.
This address can withdraw all funds from the contract, after the minting period is over. This address is hardcoded and cannot be changed.
- 2022-11-11 – Initial report based on commit ebd2172b07c104235a8f23fda73fdbe989d53f71.
- 2022-11-15 – Checked fixes based on commit 487b56f08f19b23a684107b2461b8cd893b5f708.