Is Non-Playable Coin (NPC) Safe? Smart Contract Security Analysis

Security Findings

1 Low3 Info

Low

Incomplete Code Provided for Audit

L-01The provided source code for the `_burn` function within the ERC20 contract is truncated. This prevents a comprehensive security analysis of the entire contract logic, specifically the token burning mechanism. While the visible parts of the ERC20 contract follow OpenZeppelin standards, the incomplete `_burn` function could potentially hide vulnerabilities or unexpected behavior.

IssueThe provided source code for the `_burn` function within the ERC20 contract is truncated. This prevents a comprehensive security analysis of the entire contract logic, specifically the token burning mechanism. While the visible parts of the ERC20 contract follow OpenZeppelin standards, the incomplete `_burn` function could potentially hide vulnerabilities or unexpected behavior.

FixAlways provide the complete and final source code for all contracts intended for audit. Ensure that no functions or code blocks are truncated, allowing for a thorough and accurate security review.

StatusUnresolved

Info

Standard Library Usage

I-01The contract extensively utilizes well-audited and widely adopted OpenZeppelin contracts for core functionalities such as ERC-20 token standards, Ownable access control, ERC-165 interface detection, and ERC-1155Receiver implementation. This practice significantly reduces the risk of common vulnerabilities and enhances the overall reliability and security of the codebase (7.2 Code Security).

IssueThe contract extensively utilizes well-audited and widely adopted OpenZeppelin contracts for core functionalities such as ERC-20 token standards, Ownable access control, ERC-165 interface detection, and ERC-1155Receiver implementation. This practice significantly reduces the risk of common vulnerabilities and enhances the overall reliability and security of the codebase (7.2 Code Security).

FixContinue to leverage battle-tested libraries like OpenZeppelin. Regularly check for updates to these libraries to benefit from ongoing security improvements and bug fixes.

StatusUnresolved

Info

Ownership Renounced

I-02According to the provided prefill data, the ownership of the contract has been renounced. This means the `owner` address is set to the zero address, making it impossible to call `onlyOwner` functions. This action decentralizes control, removes a single point of failure, and prevents potential malicious actions by a compromised owner key (7.3 Access Control, 7.5 Governance).

IssueAccording to the provided prefill data, the ownership of the contract has been renounced. This means the `owner` address is set to the zero address, making it impossible to call `onlyOwner` functions. This action decentralizes control, removes a single point of failure, and prevents potential malicious actions by a compromised owner key (7.3 Access Control, 7.5 Governance).

FixEnsure that the renunciation of ownership was an intentional and irreversible decision, as it removes the ability to perform any owner-restricted administrative tasks. Communicate this status clearly to the community.

StatusUnresolved

Info

Fixed Token Supply (No Public Mint/Burn)

I-03The ERC20 contract includes internal `_mint` and `_burn` functions but does not expose any public or external functions to call them. This design choice, especially when combined with renounced ownership, implies that the token's total supply is fixed after its initial deployment and constructor-based minting (if any). There is no mechanism for the owner or any other entity to alter the supply post-deployment (7.4 Economic).

IssueThe ERC20 contract includes internal `_mint` and `_burn` functions but does not expose any public or external functions to call them. This design choice, especially when combined with renounced ownership, implies that the token's total supply is fixed after its initial deployment and constructor-based minting (if any). There is no mechanism for the owner or any other entity to alter the supply post-deployment (7.4 Economic).

FixClearly document this fixed supply characteristic for users and stakeholders. If future supply adjustments are ever desired, a new contract or a more complex governance mechanism would be required.

StatusUnresolved

Category Ratings

TechnicalLow10/10

The codebase primarily consists of well-audited OpenZeppelin contracts for ERC-20, ERC-165, ERC-1155Receiver, and Ownable functionalities (7.1 Architecture, 7.2 Code Security). Safe arithmetic operations are ensured through `require` checks preceding `unchecked` blocks in `_transfer` and `decreaseAllowance`. The `ERC1155Holder` contract correctly implements the `IERC1155Receiver` interface. A limitation is the truncation of the `_burn` function, preventing a full review of its implementation details.

GovernanceLow9/10

The contract utilizes the Ownable pattern for administrative control. However, the prefill indicates that ownership has been renounced, which significantly reduces governance risk by removing a central point of control (7.5 Governance). The token's economic model is a standard ERC-20, with no complex mechanisms beyond transfers and allowances (7.4 Economic). The absence of public mint/burn functions, coupled with renounced ownership, ensures a fixed token supply, promoting predictability.

UpgradesLow10/10

The contract is not designed with upgradeability features, as indicated by `is_proxy: false` in the prefill (7.7 Upgrades). This means the contract's logic is immutable once deployed, eliminating risks associated with upgrade mechanisms like proxy vulnerabilities or malicious upgrade paths.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

40.6% in top 10

27.0% in wallets13.6% in contracts

Effective Concentration32.4%

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

$4.74M across 4 pairs

Uniswap v2WETHanalysed$4.71M Uniswap v4rust$25.1K Uniswap v3WETH$5.3K SupernovaWETH$119

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 Locked100.0% · Null Address, TeamFinance

Key Addresses

4 addresses

Deployer

0xa05d…9fcc

Unlocked LP Held By

0xb3ac…68a00x0000…8a900x1f2f…f387

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

2 factors

Top-10 concentration > 30% (40.6% total → 32.4% effective; 27.0% in EOAs, 13.6% in contracts — moderate)
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 Non-Playable Coin Safe?

Security Findings

Incomplete Code Provided for Audit

Standard Library Usage

Ownership Renounced

Fixed Token Supply (No Public Mint/Burn)

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Non-Playable Coin?