Quantum Audit Logo

Is NEAR Protocol Safe?

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

Is this your token? Publish your own audit on this page →

NEAR Protocol NEAR
0x1fa4…5d63
BNB Chain
Not verifiedThis 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 today 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The BEP20 Token implementation contract exhibits a high overall risk level primarily due to centralized minting capabilities controlled by the owner and a critical code integrity issue with a truncated internal function. While the contract correctly implements the upgradeable proxy pattern and uses SafeMath for arithmetic operations, the owner's ability to mint tokens poses a significant economic risk. Additionally, the `_burnFrom` function is incomplete, indicating a potential flaw in the deployed code's completeness or quality. The owner also has the ability to irreversibly renounce ownership, which could lead to a loss of administrative control.

2 High1 Medium1 Low1 Informational
Volume 24h
$362.7K
Liquidity
$198.4K
Price
$5.1100
Token Age
3y
Top 10 Holders
40.9%

Security Findings

2 High1 Med1 Low1 Info
High

Truncated `_burnFrom` Function

H-01The `_burnFrom` internal function is incomplete in the provided source code, ending abruptly. While this function is not currently called by any other function within the contract, its truncation represents a significant code integrity flaw. If a future function or an upgrade were to rely on `_burnFrom`, it would lead to runtime errors or unexpected behavior. This indicates a potential issue with the deployed code's completeness or quality.
IssueThe `_burnFrom` internal function is incomplete in the provided source code, ending abruptly. While this function is not currently called by any other function within the contract, its truncation represents a significant code integrity flaw. If a future function or an upgrade were to rely on `_burnFrom`, it would lead to runtime errors or unexpected behavior. This indicates a potential issue with the deployed code's completeness or quality.
FixReview the original source code for the `_burnFrom` function. If it is intended to be part of the contract, ensure its full and correct implementation. If it is not intended for use, consider removing the incomplete function to avoid confusion and potential future issues.
StatusUnresolved
High

Centralized Minting Capability

H-02The `mint` function allows the contract owner to create an arbitrary amount of new tokens, provided the `_mintable` flag is set to `true` during initialization. This centralized control over token supply introduces significant economic risk, as the owner can dilute the value of existing tokens at will, potentially harming token holders.
IssueThe `mint` function allows the contract owner to create an arbitrary amount of new tokens, provided the `_mintable` flag is set to `true` during initialization. This centralized control over token supply introduces significant economic risk, as the owner can dilute the value of existing tokens at will, potentially harming token holders.
FixEvaluate if centralized minting is a necessary feature for the token's economic model. If not, consider removing the `mint` function and setting `_mintable` to `false` permanently. If minting is required, implement a more decentralized or time-locked mechanism, such as a governance-controlled minting schedule or a multi-signature approval process, to reduce the risk of arbitrary supply inflation.
StatusUnresolved
Medium

Irreversible Renouncement of Ownership

M-01The `renounceOwnership` function allows the current owner to transfer ownership to the zero address (`address(0)`). If executed, this action is irreversible and would leave the contract without an owner. Consequently, all `onlyOwner` functions, including `mint` (if `_mintable` is true) and `transferOwnership`, would become permanently inaccessible, potentially hindering future administrative actions or upgrades.
IssueThe `renounceOwnership` function allows the current owner to transfer ownership to the zero address (`address(0)`). If executed, this action is irreversible and would leave the contract without an owner. Consequently, all `onlyOwner` functions, including `mint` (if `_mintable` is true) and `transferOwnership`, would become permanently inaccessible, potentially hindering future administrative actions or upgrades.
FixOwners should exercise extreme caution when using `renounceOwnership`. It is recommended to transfer ownership to a secure, multi-signature wallet or a robust governance contract instead of renouncing it to the zero address, unless the intention is to permanently decentralize control over all owner-restricted functions.
StatusUnresolved
Low

Immutability of `_mintable` Flag

L-01The `_mintable` flag, which controls whether new tokens can be minted, is set only during the `initialize` function and cannot be modified thereafter. This design choice means that the minting capability is permanently enabled or disabled based on the initial deployment configuration. While a clear design, it lacks flexibility for future adjustments to the token's economic policy.
IssueThe `_mintable` flag, which controls whether new tokens can be minted, is set only during the `initialize` function and cannot be modified thereafter. This design choice means that the minting capability is permanently enabled or disabled based on the initial deployment configuration. While a clear design, it lacks flexibility for future adjustments to the token's economic policy.
FixIf future flexibility is desired, consider implementing a function (restricted to the owner or governance) to toggle the `_mintable` flag. This would allow for dynamic adjustments to the token's minting policy without requiring a full contract upgrade.
StatusUnresolved
Info

Standard Proxy Implementation Pattern

I-01The contract correctly implements the `Initializable` pattern and has an empty `constructor`, which is standard practice for upgradeable contracts designed to be used as an implementation behind a proxy. This ensures proper initialization through the `initialize` function and avoids issues with proxy storage collisions.
IssueThe contract correctly implements the `Initializable` pattern and has an empty `constructor`, which is standard practice for upgradeable contracts designed to be used as an implementation behind a proxy. This ensures proper initialization through the `initialize` function and avoids issues with proxy storage collisions.
FixNo specific recommendation. This is a best practice for upgradeable contracts.
StatusResolved

Category Ratings

TechnicalMedium5/10

The contract utilizes SafeMath for robust arithmetic operations, mitigating common integer overflow/underflow vulnerabilities. However, a significant technical flaw exists with the truncated `_burnFrom` internal function (H-01), which, if ever called, would lead to runtime errors. Additionally, the `renounceOwnership` function allows for an irreversible loss of administrative control (M-01), potentially hindering future operational capabilities.

GovernanceHigh1/10

The contract's economic model presents a high risk due to the centralized minting capability (H-02), allowing the owner to arbitrarily increase token supply and dilute value. While the `_mintable` flag provides a clear initial configuration, its immutability (L-01) prevents future adjustments to the token's economic policy. The owner's control over minting and ownership transfer highlights a centralized governance structure.

UpgradesHigh1/10

The contract correctly implements the `Initializable` pattern and features an empty constructor (I-01), adhering to best practices for upgradeable proxy implementations. This design minimizes the risk of storage collisions and ensures proper initialization through the `initialize` function, contributing to a low risk profile for upgrades.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminEOA (single key controls upgrades)
ImplementationVerified source

Holder Composition

40.9% in top 10
35.4% in wallets5.5% in contracts
Effective Concentration37.6%

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

$710.8K across 26 pairs
Pancakeswap v3WBNBanalysed$198.4K27.9%Pancakeswap v2WBNB$187.9K26.4%UniswapWBNB$184.6K26.0%BiswapWBNB$46.1K6.5%Pancakeswap v3USDT$21.0K2.9%UniswapUSDT$18.4K2.6%
Show 4 more pairsShow less
Pancakeswap v3ETH$17.9K2.5%BabyswapUSDT$12.7K1.8%ApeswapWBNB$8.8K1.2%BabyswapWBNB$3.9K0.5%

The 16 remaining pairs hold $11.3K between them and are not listed.

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 Holder66.5%
Top-3 Unlocked74.0%

Key Addresses

11 addresses
Deployer
0xfc19…367a
Unlocked LP Held By
0x7fbf…16ae0xd17c…d82c0x84fe…d2270x3b18…03980x4b9d…fccd0x0cba…024c0x67ec…8b470x06a1…d1090x592c…90c50x781e…f2cb

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

What Raised This Score

10 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Admin is EOA (single key controls upgrades)
  • Top-10 concentration > 30% (40.9% total → 37.6% effective; 35.4% in EOAs, 5.5% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 66.5% (independent LP — depth risk, pool = 28% of DEX liquidity)
  • 2 High finding(s) from audit
  • 1 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

Related Audits

6 more on the record
United Stables (U)Critical RiskCATCritical RiskVortexPad (VPAD)Critical RiskAIOZ Network (AIOZ)Critical RiskNVIDIA Corp (NVDAB)Critical RiskGiggle Tom (TOM)Critical Risk

Would You Like a More Detailed Audit of NEAR Protocol?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit