On-chain security analysis — is it a scam or legit?
EthereumThe NPC Token contract is a standard ERC-20 implementation, leveraging well-audited OpenZeppelin libraries.
Read the full analysisEach 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
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.
Holder balances as recorded by the audit of Sep 4, 2026
The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0xb3ac…68a00x0000…8a900x1f2f…f387No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
_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.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.
Always 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.
Unresolved
The 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).
Continue to leverage battle-tested libraries like OpenZeppelin. Regularly check for updates to these libraries to benefit from ongoing security improvements and bug fixes.
Unresolved
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).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).
Ensure 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.
Unresolved
_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).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).
Clearly 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.
Unresolved
The NPC Token contract is a standard ERC-20 implementation, leveraging well-audited OpenZeppelin libraries. The provided code also includes an ERC1155Holder contract for receiving ERC-1155 tokens. Key security features include the use of safe arithmetic and the renunciation of ownership, which enhances decentralization. A full audit is limited by the truncation of the _burn function in the provided source code.
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.
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.
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.
It is recommended to ensure that the full, untruncated source code is available for any future audits or public verification to confirm the integrity of all functions, especially _burn.
While the current implementation appears robust due to its reliance on OpenZeppelin standards and renounced ownership, thorough verification of the complete codebase is always a best practice. Users should be aware of the fixed token supply model due to the absence of public minting or burning capabilities.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
The Non-Playable Coin (NPC) contract on Ethereum is 0x8ed97a637a790be1feff5e888d43629dc05408f6. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for Non-Playable Coin is 0/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $4.74M.
As of Sep 4, 2026, the 10 largest holders own 40.6% of the supply. The Holders section on this page shows who they are by holder type.
Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.
Get Detailed Audit Is this your token? Publish your own audit on this page
