Quantum Audit Logo

Is Nockchain Safe?

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

Nockchain NOCK
0x9b5e…1722
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive 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. 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.

1 High2 Medium1 Low1 Informational
Volume 24h
$1.05M
Liquidity
$1.06M
Price
$0.01789
Token Age
5mo
Top 10 Holders
21.8%

Security Findings

1 High2 Med1 Low1 Info
High

Reliance on External `IMessageInbox` Security

H-01The `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.
IssueThe `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.
FixConduct 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.
StatusUnresolved
Medium

Centralized Minting and Lack of Supply Cap

M-01The `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.
IssueThe `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.
FixEvaluate 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.
StatusUnresolved
Medium

Potential Reentrancy in `burn` via External Call

M-02The `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.
IssueThe `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.
FixWhile 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.
StatusUnresolved
Low

Owner's Ability to Change `inbox` Address

L-01The `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.
IssueThe `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.
FixConsider 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.
StatusUnresolved
Info

Non-Standard Decimals Value

I-01The `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).
IssueThe `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).
FixEnsure 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.
StatusUnresolved

Category Ratings

TechnicalLow7/10

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.

GovernanceMedium4/10

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).

UpgradesMedium4/10

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.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

21.8% in top 10
16.8% in wallets4.9% in contracts
Effective Concentration18.8%

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

$1.44M across 12 pairs
AerodromeUSDCanalysed$1.06M74.0%Uniswap v4USDC$161.1K11.2%Uniswap v4USDC$73.4K5.1%Uniswap v4USDC$48.3K3.4%Uniswap v3WETH$44.1K3.1%Uniswap v4ETH$43.3K3.0%
Show 4 more pairsShow less
AerodromeWETH$2.5K0.2%Uniswap v4USDC$1.1K0.1%Hydrex CLAMMWETH$4620.0%Uniswap v4USDC$280.0%

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

Top-1 Unlocked Holder96.8%
Top-3 Unlocked100.0%

Key Addresses

3 addresses
Deployer
0x4356…8555
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.

What Raised This Score

8 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

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 record
Solana (Universal) (USOL)Medium RiskElsaMedium RiskLil Finder Guy (LFG)Medium RiskAerodrome Finance (AERO)Medium RiskaeonHigh RiskSapienMedium Risk

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