The contract designates a single address as the minter, with the power to mint new tokens at will, creating a significant centralization risk. If the minter address is compromised, lost, or behaves maliciously, the following risks arise:

• Unlimited Token Creation: A compromised minter could mint an infinite number of tokens, causing severe inflation and undermining the token’s value and integrity.

  
  

• Single Point of Failure: If the minter private key is lost, the contract loses its minting capability, potentially halting crucial operations.

It is recommended to decentralize the minting authority by:

• Implementing a Multisig Wallet: Use a multisignature wallet (e.g., Gnosis Safe) as the minter, requiring multiple approvals for each minting action. This approach minimizes the impact of a compromised private key, as no single entity can unilaterally mint tokens.

  
  

• Adopting Governance Mechanisms: Incorporate a decentralized governance model (e.g., DAO voting) to control the minter role, ensuring community involvement and reducing the risk of centralized abuse.

ACKNOWLEDGED: The Mintify team has acknowledged this finding.

The contract lacks a Pausable implementation, which means it cannot be temporarily halted in case of emergencies, such as security breaches, exploits, or unexpected behavior.

Without this safeguard, the contract remains fully operational even if a critical vulnerability is discovered, increasing the risk of further damage, unauthorized minting, or fund loss

It is recommended to implement OpenZeppelin's Pausable module to provide a flexible and secure mechanism for temporarily suspending contract functionality in case of emergency.

ACKNOWLEDGED: The Mintify team has acknowledged this finding.

The Mintify contract uses a floating pragma version, which allows compilation with multiple versions of the Solidity compiler.

This approach can introduce unexpected behaviors if new compiler versions are released, potentially introducing changes or bugs that impact the contract.

Code Location

Snippet of code from Mintify contract:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

It is recommended to use a fixed Solidity version in the pragma, such as pragma solidity 0.8.20, to ensure the contract is always compiled with a known version. This minimizes the risk of unexpected behaviors due to compiler changes.

ACKNOWLEDGED: The Mintify team has acknowledged this finding.

The contract uses the 10**18 value directly as a magic number to represent the token’s decimals, which can lead to higher gas costs and decrease readability.

Additionally, using hardcoded values can make it difficult to adjust the decimal precision if necessary.

Code Location

Snippet of code from StarOFToken contract:

contract Mintify is ERC20, ERC20Permit, ERC20Burnable, Ownable2Step {
    uint256 public constant MAX_SUPPLY = 10_000_000_000 * 10 ** 18;
    address public minter;

It is recommended to replace the hardcoded decimal value with decimals() or define a constant, such as DECIMALS to optimize gas usage and improve the contract’s readability. This will make the code more adaptable to future changes.

ACKNOWLEDGED: The Mintify team has acknowledged this finding.

The contract fails to verify that the amount to be minted is strictly greater than zero.

Even though _mint ensures a non-zero recipient address, zero-token minting remains possible, creating unnecessary transactions with no meaningful effect.

Code Location

Code of mint function:

function mint(address account, uint256 amount) external onlyMinter {
    _mint(account, amount);
}

It is recommended to include a check within the mint function:

require(amount > 0, "Mint zero tokens");

This ensures all mint operations involve a positive token amount, improving clarity and saving gas.

ACKNOWLEDGED: The Mintify team has acknowledged this finding.

The contract relies solely on the standard Transfer event emitted by _mint.

Although this indicates the creation of new tokens, it lacks explicit clarity. Off-chain services, explorers, and auditors may find it challenging to differentiate between minting and regular transfers from the zero address.

It is recommended to create and emit a custom Mint event, for example:

event Mint(address indexed to, uint256 amount); 

function mint(address account, uint256 amount) external onlyMinter { 
    _mint(account, amount); 
    emit Mint(account, amount); 
}

This ensures clear tracking of newly minted tokens.

ACKNOWLEDGED: The Mintify team has acknowledged this finding.