Quantum Audit Logo
Launch App

On-chain security analysis — is it a scam or legit?

Is Nockchain Safe?

NOCKBase
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance4/10Upgrades4/10Checks passed2 of 5Findings1 High · 2 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The Nock contract is an ERC-20 token designed for Nockchain integration, featuring minting by a designated 'inbox' contract and burning for withdrawals.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Mintable supply — no cap found, dilution unbounded
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 96.8%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Mintable supply — no cap found, dilution unbounded
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 96.8% (independent LP — depth risk, pool = 74% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 74% of DEX liquidity)
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
4.9%Contracts16.8%Wallets78.2%Everyone else
4.9%16.8%78.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
21.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking4.9%
  • Walletsanonymous holders, free to sell16.8%
  • Everyone elsethe rest of the supply78.2%
Effective concentrationwhat the score reads18.8%
How holder types affect the score

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

Liquidity

as of audit · Sep 4$1.44M across 12 pairs
Show 4 more pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$1.06MShare of depth74.0%
Top-1 Unlocked Holder96.8%
Top-3 Unlocked100.0%
Unlocked LP held by
0x575e…fe980x344e…9815

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

Security Findings

1 High2 Medium1 Low1 Info
High

Reliance on External IMessageInbox Security

The Nock token contract heavily relies on the security and correct behavior of the external IMessageInbox contract (7.6). The inbox address is the sole minter of Nock tokens and is called during every burn operation via notifyBurn(). A compromise or malfunction of IMessageInbox could lead to unauthorized token minting, denial of service for withdrawals, or other adverse effects, directly impacting the token's integrity and value.H-01

Issue

The Nock token contract heavily relies on the security and correct behavior of the external IMessageInbox contract (7.6). The inbox address is the sole minter of Nock tokens and is called during every burn operation via notifyBurn(). A compromise or malfunction of IMessageInbox could lead to unauthorized token minting, denial of service for withdrawals, or other adverse effects, directly impacting the token's integrity and value.

Fix

Conduct a comprehensive security audit of the IMessageInbox contract and its associated off-chain logic. Ensure robust access control, input validation, and reentrancy protection within IMessageInbox, especially for functions interacting with Nock. Implement strong governance and operational security for the IMessageInbox contract's ownership and deployment.

Status

Unresolved

Medium

Centralized Minting and Lack of Supply Cap

The Nock token has no explicit supply cap (the cap() function returns 0), and all minting is exclusively controlled by the inbox address (7.4). While this design centralizes control for specific operational reasons, it introduces a significant centralization risk. If the inbox contract or its controlling entity is compromised, an arbitrary amount of tokens could be minted, leading to severe token dilution and loss of value for existing holders.M-01

Issue

The Nock token has no explicit supply cap (the cap() function returns 0), and all minting is exclusively controlled by the inbox address (7.4). While this design centralizes control for specific operational reasons, it introduces a significant centralization risk. If the inbox contract or its controlling entity is compromised, an arbitrary amount of tokens could be minted, leading to severe token dilution and loss of value for existing holders.

Fix

Evaluate the necessity of an uncapped supply. If a cap is not feasible, implement robust security measures for the IMessageInbox contract and its owner, such as a multi-signature wallet, time-locks for critical operations, or a transparent governance mechanism. Consider adding a configurable supply cap if the protocol design allows for it.

Status

Unresolved

Medium

Potential Reentrancy in burn via External Call

The burn function makes an external call to IMessageInbox(inbox).notifyBurn() after performing the token burn (7.2). Although the _burn operation occurs before the external call, which mitigates direct reentrancy on the balanceOf check for the burning user, an untrusted or malicious IMessageInbox contract could potentially re-enter the Nock contract in other ways or execute unexpected logic that affects the overall system state or other users. This violates the Checks-Effects-Interactions pattern.M-02

Issue

The burn function makes an external call to IMessageInbox(inbox).notifyBurn() after performing the token burn (7.2). Although the _burn operation occurs before the external call, which mitigates direct reentrancy on the balanceOf check for the burning user, an untrusted or malicious IMessageInbox contract could potentially re-enter the Nock contract in other ways or execute unexpected logic that affects the overall system state or other users. This violates the Checks-Effects-Interactions pattern.

Fix

While the direct reentrancy on the burn amount is mitigated, it is best practice to strictly follow the Checks-Effects-Interactions pattern. If notifyBurn is not intended to modify state or call back into Nock, consider adding a reentrancy guard to the burn function or ensuring IMessageInbox is non-reentrant. Alternatively, move the external call before state changes if possible, or use a pull-based mechanism.

Status

Unresolved

Low

Owner's Ability to Change inbox Address

The Ownable contract pattern grants the contract owner the ability to update the inbox address via the updateInbox function (7.3, 7.5). Since the inbox address is the sole minter of Nock tokens, a malicious or compromised owner could transfer minting control to an attacker-controlled address, leading to unauthorized token issuance. This represents a single point of failure for a critical function.L-01

Issue

The Ownable contract pattern grants the contract owner the ability to update the inbox address via the updateInbox function (7.3, 7.5). Since the inbox address is the sole minter of Nock tokens, a malicious or compromised owner could transfer minting control to an attacker-controlled address, leading to unauthorized token issuance. This represents a single point of failure for a critical function.

Fix

Consider implementing a multi-signature wallet for the contract owner to reduce the risk of a single point of compromise. Additionally, a time-lock mechanism could be introduced for the updateInbox function, allowing users to react to a potentially malicious change before it takes effect.

Status

Unresolved

Info

Non-Standard Decimals Value

The Nock token overrides the standard ERC20 decimals() function to return 16 instead of the typical 18. While explicitly stated as 'Nockchain alignment,' this non-standard value can lead to integration issues, display errors in wallets or exchanges, and potential user confusion if not handled correctly by all interacting systems (7.4).I-01

Issue

The Nock token overrides the standard ERC20 decimals() function to return 16 instead of the typical 18. While explicitly stated as 'Nockchain alignment,' this non-standard value can lead to integration issues, display errors in wallets or exchanges, and potential user confusion if not handled correctly by all interacting systems (7.4).

Fix

Ensure all front-end applications, exchanges, and integrated protocols are fully aware of and correctly handle the 16-decimal precision for Nock tokens. Clear and prominent documentation should be provided to prevent misinterpretation and ensure consistent display across platforms.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The Nock contract is an ERC-20 token designed for Nockchain integration, featuring minting by a designated 'inbox' contract and burning for withdrawals. It utilizes OpenZeppelin's Ownable and ERC20 implementations, contributing to a solid foundation. Key findings include a high reliance on the security of the external IMessageInbox contract, centralized minting without a supply cap, and potential reentrancy concerns with external calls during burn operations. The contract is explicitly non-upgradeable, which eliminates upgrade-related risks but also prevents future modifications.

Technical7/10Low risk

The Nock contract leverages battle-tested OpenZeppelin libraries (ERC20, Ownable), providing a strong base for code security (7.2). The logic for minting and burning is straightforward, with appropriate access controls and input validations. However, a significant technical risk lies in the contract's reliance on the external IMessageInbox contract, which controls minting and is called during burn operations (7.6). There is also a potential reentrancy concern in the burn function due to an external call to notifyBurn() after state changes (7.2). The architecture (7.1) is clear, but the external dependency introduces a critical trust assumption.

Governance4/10Medium risk

The contract establishes clear access control (7.3) with an Ownable pattern, allowing the owner to update the critical inbox address. This provides a single point of control for managing the minting authority. Economically (7.4), the token has no supply cap, and minting is solely controlled by the inbox contract. While this design might be intentional for Nockchain integration, it introduces a centralization risk where a compromised inbox could lead to unlimited token issuance and dilution. The owner's ability to change the inbox address without a time-lock or multi-sig mechanism also presents a governance risk (7.5).

Upgrades4/10Medium risk

The Nock contract is explicitly designed to be non-upgradeable, as stated in its documentation: "This contract is NOT upgradeable to ensure immutability of the token." This design choice eliminates all risks associated with upgrade mechanisms (7.7), such as proxy implementation bugs or upgrade path vulnerabilities. The immutability ensures that the token's logic remains constant post-deployment.

Final RecommendationWhat to do about this score

Prioritize a comprehensive security audit of the IMessageInbox contract, as its integrity is paramount to the Nock token's security.

Implement robust security measures for the IMessageInbox and its owner, such as multi-signature wallets and time-locks, especially given the lack of a token supply cap. Review the necessity of the external call within the burn function and consider reentrancy guards if the IMessageInbox contract is not fully trusted or could have reentrant behavior. Ensure all integrations are fully aware of and correctly handle the 16-decimal precision of the Nock token.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age5mo
Contract0x9b5e…1722
Deployer0x4356…8555
Badge for your website
Nockchain security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202645Medium
  2. Jul 23, 202652Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

Is Nockchain a scam?

Based on available data, labeling Nockchain definitively as a scam is not possible without further context. However, critical vulnerabilities exist. The owner retains control, and liquidity is not locked, which are common characteristics seen in projects that later prove malicious. While the contract is verified, these factors contribute to its high-risk score and warrant extreme investor caution regarding potential malicious actions.

Is Nockchain safe to buy?

Nockchain (NOCK) carries a high-risk score of 51/100, indicating it is not inherently safe for investment. Key risk factors include the contract owner retaining control, which could lead to unexpected changes or manipulation. Additionally, the liquidity is not locked, exposing investors to potential rug pulls where funds supporting the token's value are withdrawn. These significant risks should be carefully considered.

Has Nockchain been audited?

The Nockchain contract is verified, meaning its code is publicly available for review on the blockchain. This enhances transparency. However, verification is not the same as a formal security audit by an independent firm. An audit rigorously assesses code for deeper vulnerabilities and adherence to best practices, which is not indicated by verification alone.

Related Audits

6 more on the recordAll audits
Solana (Universal)USOL · Base45MediumElsaBase45MediumLil Finder GuyLFG · Base45MediumAerodrome FinanceAERO · Base44MediumaeonBase46MediumSapienBase44Medium

Would You Like a More Detailed Audit of Nockchain?

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