Is Post-Quantum Coin (PQC) Safe? Smart Contract Security Analysis

Security Findings

1 Low1 Info

Low

Potential for Uninitialized Token Metadata

L-01The `FourERC20` contract includes an internal `_init` function intended to set the token's `_name` and `_symbol`. However, this function is not called within the `FourERC20` contract itself. If a derived contract fails to call `_init` in its constructor, the `name()` and `symbol()` functions will return empty strings, leading to a poor user experience and potential integration issues with platforms expecting valid metadata.

IssueThe `FourERC20` contract includes an internal `_init` function intended to set the token's `_name` and `_symbol`. However, this function is not called within the `FourERC20` contract itself. If a derived contract fails to call `_init` in its constructor, the `name()` and `symbol()` functions will return empty strings, leading to a poor user experience and potential integration issues with platforms expecting valid metadata.

FixEnsure that any contract inheriting from `FourERC20` explicitly calls the `_init(string memory name_, string memory symbol_)` function within its constructor to properly initialize the token's metadata.

StatusUnresolved

Info

Absence of Public Supply Control

I-01The `FourERC20` contract provides internal `_mint` and `_burn` functions, but it does not expose any public functions for minting or burning tokens. This means that the total supply of the token is fixed at deployment unless a derived contract explicitly implements and exposes these functionalities. This is a design choice for a base ERC-20 contract but should be noted for deployment planning (7.8 Operations).

IssueThe `FourERC20` contract provides internal `_mint` and `_burn` functions, but it does not expose any public functions for minting or burning tokens. This means that the total supply of the token is fixed at deployment unless a derived contract explicitly implements and exposes these functionalities. This is a design choice for a base ERC-20 contract but should be noted for deployment planning (7.8 Operations).

FixIf dynamic supply management (minting or burning) is required, a new contract inheriting from `FourERC20` must be created to implement and secure these functionalities with appropriate access control. Otherwise, the token's supply will be immutable after initial deployment.

StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture is robust, leveraging well-audited OpenZeppelin ERC-20 implementations, ensuring a strong foundation (7.1 Architecture). Code security is high, with no apparent reentrancy, integer overflow/underflow, or other common Solidity vulnerabilities due to Solidity 0.8+ checked arithmetic and careful use of `unchecked` blocks (7.2 Code Security). Access control is standard for ERC-20, relying on `msg.sender` for transfers and approvals (7.3 Access Control). A minor technical consideration is the internal `_init` function, which requires a derived contract to properly set token metadata.

GovernanceMedium6/10

The contract implements a basic ERC-20 token with no inherent governance mechanisms or complex economic models (7.5 Governance, 7.4 Economic). Its economic stability relies solely on its utility and adoption, as it lacks features like fees, staking, or dynamic supply adjustments. The absence of public minting/burning functions means the total supply is fixed unless a derived contract introduces such mechanisms, which simplifies the economic model but limits flexibility.

UpgradesLow10/10

The contract is not designed to be upgradable, as indicated by the absence of proxy patterns or upgrade-specific logic (7.7 Upgrades). This design choice eliminates risks associated with upgradeability, such as proxy storage collisions, faulty upgrade logic, or administrative key compromise. Any changes to the token's logic would necessitate a new contract deployment.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

91.2% in top 10

10.4% in wallets80.8% in contracts

Effective Concentration42.7%

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Liquidity Depth

$9.4K

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Key Addresses

1 addresses

Deployer

0x796c…b456

What Raised This Score

3 factors

Top-10 concentration > 30% (91.2% total → 42.7% effective; 10.4% in EOAs, 80.8% in contracts — moderate)
Liquidity < $10k ($9,415 across 1 pairs — easily drained)
1 Low finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Is Post-Quantum Coin Safe?