Quantum Audit Logo
Launch App

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

Is priceless Safe?

PRICELESSBNB Chain
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 6, 2026 · 1 audit on record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance8/10Upgrades10/10Checks passed7 of 7Findings2 High · 1 Low · 1 Info4
SummaryAI Copilot

This audit report covers the FourERC20 token contract, an ERC-20 implementation.

Read the full analysis
What raised the score
  • Top-10 concentration > 20%
  • 2 High finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 20% (40.9% total → 25.0% effective; 14.4% in EOAs, 26.5% in contracts — mild)
  • 2 High 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 67 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 6, 2026
26.5%Contracts14.4%Wallets59.1%Everyone else
26.5%Contracts14.4%59.1%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
40.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking26.5%
  • Walletsanonymous holders, free to sell14.4%
  • Everyone elsethe rest of the supply59.1%
Effective concentrationwhat the score reads25.0%
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 6, 2026

Liquidity

as of audit · Sep 6$126.3K across 7 pairs
Show 1 more pair

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$126.1KShare of depth99.8%
LP Burned99.9% · ≈ permanent lock
LP Locked99.9%
Unlocked LP held by
0x7ccb…34d90x27e8…1d4b0x816c…b8750x66b4…01c80xcca3…c28c0x6b1f…be800xd5ae…4b4a0x34dc…e3250xb924…1456

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

Security Findings

2 High1 Low1 Info
High

Incomplete Token Functionality (Missing Supply Mechanism)

The FourERC20 contract, as provided, lacks public functions to mint or burn tokens. The _mint and _burn functions are internal, meaning a derived contract is required to implement the supply mechanism. Without such a derived contract, the token's _totalSupply remains zero, and no tokens can be created or distributed, rendering the token non-functional for its intended purpose. This is a critical design oversight if deployed as a standalone token.H-01

Issue

The FourERC20 contract, as provided, lacks public functions to mint or burn tokens. The _mint and _burn functions are internal, meaning a derived contract is required to implement the supply mechanism. Without such a derived contract, the token's _totalSupply remains zero, and no tokens can be created or distributed, rendering the token non-functional for its intended purpose. This is a critical design oversight if deployed as a standalone token.

Fix

If this contract is intended to be a deployable token, implement public mint and burn functions in a derived contract. These functions should include robust access control (e.g., onlyOwner or role-based access) to prevent unauthorized supply manipulation. If it's purely a base contract for inheritance, ensure documentation clearly states this requirement.

Status

Unresolved

High

Uninitialized Token Metadata and State

The _init function, which is responsible for setting the token's _name and _symbol, is internal and not called within the FourERC20 contract's constructor. If this contract is deployed directly, the token's name and symbol will remain uninitialized (empty strings). Furthermore, if this contract is intended to be an implementation for a proxy, the _init function must be explicitly called as an initializer to properly set up the token's state. Failure to do so will result in a non-functional token with missing metadata.H-02

Issue

The _init function, which is responsible for setting the token's _name and _symbol, is internal and not called within the FourERC20 contract's constructor. If this contract is deployed directly, the token's name and symbol will remain uninitialized (empty strings). Furthermore, if this contract is intended to be an implementation for a proxy, the _init function must be explicitly called as an initializer to properly set up the token's state. Failure to do so will result in a non-functional token with missing metadata.

Fix

Ensure that the _init function is called during contract deployment. If deploying FourERC20 directly, add a constructor that calls _init(name_, symbol_). If using a proxy pattern, ensure the proxy's initializer function calls _init with the desired name and symbol.

Status

Unresolved

Low

Absence of Emergency Controls

The contract does not include common emergency control mechanisms such as pausing transfers or blacklisting malicious addresses. While not strictly required by ERC-20, these features are often implemented in production tokens to mitigate risks during critical events or security incidents (e.g., major exploits, regulatory demands). The lack of such controls means that in an emergency, the only recourse would be a contract upgrade (if upgradeable) or a complete redeployment.L-01

Issue

The contract does not include common emergency control mechanisms such as pausing transfers or blacklisting malicious addresses. While not strictly required by ERC-20, these features are often implemented in production tokens to mitigate risks during critical events or security incidents (e.g., major exploits, regulatory demands). The lack of such controls means that in an emergency, the only recourse would be a contract upgrade (if upgradeable) or a complete redeployment.

Fix

Consider integrating emergency control mechanisms, such as OpenZeppelin's Pausable or AccessControl contracts, to allow a designated administrator to temporarily halt transfers or restrict specific addresses in critical situations. This enhances operational security and provides a safety net.

Status

Unresolved

Info

Strong Foundation with OpenZeppelin

The contract heavily relies on well-audited OpenZeppelin Contracts (Context, IERC20, IERC20Metadata). This is a significant strength, as it leverages battle-tested code for core ERC-20 functionality. This approach inherently reduces the likelihood of common vulnerabilities like integer overflows/underflows or reentrancy in the standard functions, contributing to a higher overall code security posture.I-01

Issue

The contract heavily relies on well-audited OpenZeppelin Contracts (Context, IERC20, IERC20Metadata). This is a significant strength, as it leverages battle-tested code for core ERC-20 functionality. This approach inherently reduces the likelihood of common vulnerabilities like integer overflows/underflows or reentrancy in the standard functions, contributing to a higher overall code security posture.

Fix

Continue to leverage and stay updated with reputable, audited libraries like OpenZeppelin. Regularly review their updates and security advisories to ensure the project benefits from ongoing improvements and vulnerability fixes.

Status

Resolved

Analysis

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

This audit report covers the FourERC20 token contract, an ERC-20 implementation. The analysis is based solely on the provided Solidity source code and prefilled metadata. The contract leverages OpenZeppelin's battle-tested libraries for core ERC-20 functionality, which is a significant strength. However, the contract as provided is incomplete, lacking a public mechanism for token minting or burning, and its metadata requires explicit initialization. These design choices lead to a Medium overall risk level, primarily due to functional limitations if deployed as a standalone token.

Technical8/10Low risk

The technical architecture (7.1 Architecture) of the FourERC20 contract is based on standard OpenZeppelin ERC-20 implementations, which provides a robust and secure foundation for core token operations. Code security (7.2 Code Security) benefits significantly from this, mitigating common vulnerabilities like integer overflows/underflows and reentrancy. However, a major technical issue (H-01) is the absence of a public supply mechanism (minting/burning), rendering the token non-functional as a standalone contract. Additionally, the token's metadata (name, symbol) is not initialized by default (H-02), requiring explicit calls to an internal _init function, which is a critical deployment consideration.

Governance8/10Low risk

The contract does not implement any specific governance (7.5 Governance) or complex economic (7.4 Economic) models beyond standard ERC-20 token transfers. This simplicity reduces the attack surface related to these areas. However, the absence of emergency controls (L-01), such as pausing mechanisms or blacklisting capabilities, means that in the event of a critical security incident or market manipulation, there are no built-in operational (7.8 Operations) levers to mitigate ongoing damage.

Upgrades10/10Low risk

The FourERC20 contract is not designed as an upgradeable proxy (7.7 Upgrades) itself. If intended to be used as an implementation contract for an upgradeable proxy, the internal _init function would need to be called by the proxy's initializer to ensure proper state setup. Without a proxy pattern, the contract is immutable once deployed, meaning any functional changes would require a new deployment and migration of assets, which is a standard approach for non-upgradeable tokens.

Final RecommendationWhat to do about this score

It is strongly recommended to implement a public supply mechanism (e.g., minting and burning functions with appropriate access control) in a derived contract if this token is intended for practical use.

Ensure that the _init function is properly called during deployment, either via the constructor of a derived contract or as an initializer in an upgradeable proxy setup, to correctly set the token's name and symbol. Consider adding emergency control mechanisms like pausing functionality to enhance operational security and provide recourse during unforeseen events.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age12mo
Contract0x7d03…4444
Deployer0x72f3…c390
Badge for your website
priceless 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 6, 20261Low

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

Related Audits

6 more on the recordAll audits
REAL WORLD APPARELJACKET · BNB Chain1Low富贵BNB Chain1LowDORABNB Chain1LowWangChai旺柴 · BNB Chain1LowCZ's DogBROWNIE · BNB Chain1LowBellwether领头羊 · BNB Chain1Low

Would You Like a More Detailed Audit of priceless?

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