Is Nockchain (NOCK) Safe? Smart Contract Security Analysis

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Audit History

2 audits on record

Jul 2352

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

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.

Final Recommendation: 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.

Category Ratings

TechnicalLow

7/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

GovernanceMedium

4/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 t

UpgradesMedium

4/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 upg

LP Distribution

Top-1 Unlocked Holder51.5%

Top-3 Unlocked100.0%

What Raised This Score

9 factors

Ownership NOT renounced — strong Multisig (3-of-5)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 20% (23.5% total → 20.3% effective; 18.2% in EOAs, 5.3% in contracts — mild)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 51.5% (independent LP — depth risk, pool = 69% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 69% 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 Findings

5 total

1 High 2 Medium 1 Low 1 Info

H-01HighUnresolved

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.

Recommendation: 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.

M-01MediumUnresolved

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.

Recommendation: 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.

M-02MediumUnresolved

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.

Recommendation: 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.

L-01LowUnresolved

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.

Recommendation: 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.

I-01InformationalUnresolved

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

Recommendation: 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.

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.

Is Nockchain Safe? NOCK