Audit name:
[SCA] Krea8te | KR8-Token | May2024
Date:
Jul 12, 2024
Table of Content
Introduction
We express our gratitude to the Krea8te team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Krea8te is transforming the art market with NFTs, fractional ownership, and DeFi.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Krea8te |
| Audited By | Kornel Światłowski |
| Approved By | Przemyslaw Swiatowiec |
| Website | https://www.krea8te.io/→ |
| Changelog | 17/06/2024 - Preliminary Report; 12/07/2024 - Final Report |
| Platform | Polygon |
| Language | Solidity |
| Tags | ERC20, Vesting |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Krea8te
- Audited By
- Kornel Światłowski
- Approved By
- Przemyslaw Swiatowiec
- Website
- https://www.krea8te.io/→
- Changelog
- 17/06/2024 - Preliminary Report; 12/07/2024 - Final Report
- Platform
- Polygon
- Language
- Solidity
- Tags
- ERC20, Vesting
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/sastanaqqam-s/BLOO-token→ |
| Initial Review Commit | 6c711b4f09728947225468b0a6897f1350551997 |
| Secondary Review Commit | 845b289c381370ab4ae07f345f5c7b7e482595c4 |
Review Scope
- Initial Review Commit
- 6c711b4f09728947225468b0a6897f1350551997
- Secondary Review Commit
- 845b289c381370ab4ae07f345f5c7b7e482595c4
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are present, but only at a high-level.
Technical description have some gaps.
Code quality
The development environment is configured.
Insufficient Gas modeling.
Test coverage
Code coverage of the project is 100% (branch coverage).
Deployment and basic user interactions are covered with tests.
System Overview
The KR8 contract is a simple ERC-20 token without initial supply. Minting is only allowed to address stored inside vestingContract variable. It has the following attributes:
Name: KR8
Symbol: KR8
Decimals: 18
Total supply: 5000000_000 tokens.
The Inventory contract manages token distribution across multiple categories with distinct vesting and locking periods. It tracks the distribution schedule, and enforces whitelisting addresses for certain actions.
The Vesting contract, inheriting from Inventory and ReentrancyGuard, manages the distribution of tokens through a vesting schedule. It ensures tokens are released in stages according to predefined categories and locking periods, with functionality to whitelist addresses and initiate token transfers.
Privileged roles
The BLUEToken contract uses a custom implementation of the owner mechanism. Owner address can transfer ownership of contract and change address of vesting contract.
The Vesting contract contains a custom implementation of a whitelist mechanism assigned during contract deployment. Whitelisted addresses can start the tokenization process and release newly minted tokens to a given address.
Risks
Centralized Minting to a Single Address: The project concentrates minting tokens in a single address, raising the risk of fund mismanagement or theft, especially if key storage security is compromised.
Absence of a Token Burn Mechanism: The project lacks a mechanism to burn tokens, facing challenges in managing supply dynamically, affecting the token's value stability and inflation control.
Centralized Control of Minting Process: The token contract’s design allows for centralized control over the minting process, posing a risk of unauthorized token issuance, potentially diluting the token value and undermining trust in the project's economic governance.
Control Risks from Whitelist Users: Granting significant control to whitelist users without adequate checks leads to unpredictable operational disruptions, impacting user confidence and system stability.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-3904 | Tokens Vesting Period Shortened Due to Incorrect Base Unit Calculation | fixed | High | |
| F-2024-3917 | Contract Owner Can Modify Vesting Schedules and Mint Unlimited Tokens | fixed | Medium | |
| F-2024-3903 | Missing Case in _checkVestedPeriod() Calculation Can Lead to Unreleasable KR8 Tokens | fixed | Medium | |
| F-2024-3905 | Missing Input Validation in Vesting Constructor | fixed | Low | |
| F-2024-3901 | Inconsistent Initialization and Update of releasedToken Field in Category Struct | accepted | Low | |
| F-2024-4204 | Inaccurate Comments on Whitelisted Access for Token Release Functions | fixed | Observation | |
| F-2024-3939 | Redundant Fields in Category Struct Increase Deployment Costs | accepted | Observation | |
| F-2024-3918 | Critical Functions Lack Emitting Events | fixed | Observation | |
| F-2024-3914 | State Variables Set Only in the Constructor Should Be Declared Immutable | accepted | Observation | |
| F-2024-3908 | Redundant Data Storage in Vesting::_mintTokens() | accepted | Observation |
Appendix 1. Severity Definitions
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity | Description |
|---|---|
Critical | Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation. |
High | High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation. |
Medium | Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category. |
Low | Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score. |
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/sastanaqqam-s/BLOO-token→ |
| Initial Review Commit | 6c711b4f09728947225468b0a6897f1350551997 |
| Secondary Review Commit | 845b289c381370ab4ae07f345f5c7b7e482595c4 |
| Whitepaper | https://sastanaqqam.gitbook.io/sastanaqqam→ |
| Requirements | https://sastanaqqam.gitbook.io/sastanaqqam/tokenomics/bloo→ |
| Technical Requirements | https://sastanaqqam.gitbook.io/sastanaqqam/tokenomics/bloo→ |
Scope Details
- Initial Review Commit
- 6c711b4f09728947225468b0a6897f1350551997
- Secondary Review Commit
- 845b289c381370ab4ae07f345f5c7b7e482595c4
- Technical Requirements
- https://sastanaqqam.gitbook.io/sastanaqqam/tokenomics/bloo→