Is priceless Safe? Smart Contract Security Analysis

Security Findings

2 High1 Low1 Info

High

Incomplete Token Functionality (Missing Supply Mechanism)

H-01The `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.

IssueThe `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.

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

StatusUnresolved

High

Uninitialized Token Metadata and State

H-02The `_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.

IssueThe `_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.

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

StatusUnresolved

Low

Absence of Emergency Controls

L-01The 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.

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

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

StatusUnresolved

Info

Strong Foundation with OpenZeppelin

I-01The 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.

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

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

StatusResolved

Category Ratings

TechnicalLow8/10

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.

GovernanceLow8/10

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.

UpgradesLow10/10

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.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

40.9% in top 10

14.4% in wallets26.5% in contracts

Effective Concentration25.0%

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

$126.3K across 7 pairs

Pancakeswap v2WBNBanalysed$126.1K UniswapUSDT$213 Pancakeswap v3BabyDoge$5 Pancakeswap v2SHIB$1 Pancakeswap v3XRP$1 Pancakeswap v2BabyDoge$0

Show 1 more pairShow less

Pancakeswap v3SHIB$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

LP Burned99.9% · ≈ permanent lock

LP Locked99.9%

Key Addresses

10 addresses

Deployer

0x72f3…c390

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.

What Raised This Score

3 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

Is priceless Safe?

Security Findings

Incomplete Token Functionality (Missing Supply Mechanism)

Uninitialized Token Metadata and State

Absence of Emergency Controls

Strong Foundation with OpenZeppelin

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of priceless?