Quantum Audit Logo

Is Fetch Safe?

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

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

Fetch FET
0x031b…fa7f
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
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

This audit covers a partial Solidity code snippet, primarily consisting of OpenZeppelin standard libraries (EnumerableSet, Address, SafeMath, Context, AccessControl) and the beginning of an ERC20 token implementation. The visible code demonstrates high adherence to established security patterns and best practices. Due to the incomplete nature of the provided source, a comprehensive security assessment of the full ERC20 token logic and its interactions cannot be performed.

1 Low3 Informational
Volume 24h
$217.1K
Liquidity
$95.2K
Price
$0.2082
Token Age
3y
Top 10 Holders
94.5%

Security Findings

Low

Centralized Control via AccessControl Roles

L-01The `AccessControl` contract centralizes significant power in the hands of accounts holding administrative roles, particularly the `DEFAULT_ADMIN_ROLE`. Members of this role can grant and revoke other roles, effectively controlling who can perform privileged operations within the system. While this is the intended design of role-based access control, it introduces a single point of failure if the administrative keys are compromised or misused (7.3 Access Control).
IssueThe `AccessControl` contract centralizes significant power in the hands of accounts holding administrative roles, particularly the `DEFAULT_ADMIN_ROLE`. Members of this role can grant and revoke other roles, effectively controlling who can perform privileged operations within the system. While this is the intended design of role-based access control, it introduces a single point of failure if the administrative keys are compromised or misused (7.3 Access Control).
FixImplement robust security measures for accounts holding administrative roles. This typically includes using multi-signature wallets (e.g., Gnosis Safe) for all administrative roles, strong key management practices, and clear operational procedures for role management. Regularly review and audit role assignments.
StatusUnresolved
Info

Incomplete Code Snippet Provided

I-01The provided Solidity code is a partial snippet, primarily consisting of OpenZeppelin libraries (EnumerableSet, Address, SafeMath, Context, AccessControl) and the beginning of an ERC20 token contract. Critical functions of the ERC20 standard (e.g., `_transfer`, `_mint`, `_burn`, `approve` logic) are truncated or missing. This prevents a comprehensive security analysis of the full contract's functionality and potential interactions.
IssueThe provided Solidity code is a partial snippet, primarily consisting of OpenZeppelin libraries (EnumerableSet, Address, SafeMath, Context, AccessControl) and the beginning of an ERC20 token contract. Critical functions of the ERC20 standard (e.g., `_transfer`, `_mint`, `_burn`, `approve` logic) are truncated or missing. This prevents a comprehensive security analysis of the full contract's functionality and potential interactions.
FixProvide the complete and final source code for all contracts intended for deployment to enable a thorough and accurate security audit. A full audit would cover all functions, state transitions, and external interactions.
StatusUnresolved
Info

Older Solidity Compiler Version Used

I-02The contract uses Solidity compiler version 0.6.2. While this version is functional, newer versions (e.g., 0.8.x) offer significant improvements in terms of security features, gas optimizations, and developer experience, such as default overflow/underflow checks, custom errors, and more efficient Yul optimizations. Using an older compiler might miss out on these benefits.
IssueThe contract uses Solidity compiler version 0.6.2. While this version is functional, newer versions (e.g., 0.8.x) offer significant improvements in terms of security features, gas optimizations, and developer experience, such as default overflow/underflow checks, custom errors, and more efficient Yul optimizations. Using an older compiler might miss out on these benefits.
FixConsider upgrading the Solidity compiler to a more recent stable version (e.g., 0.8.x). This would allow the contract to benefit from the latest security features, bug fixes, and optimizations. Thorough testing should be performed after any compiler upgrade.
StatusUnresolved
Info

Limitations of `Address.isContract`

I-03The `Address.isContract` function relies on `extcodehash` to determine if an address is a contract. While standard, `extcodehash` has known limitations: it returns 0 for contracts during their constructor execution, and it can be 0 for addresses that have self-destructed. This means it might not always accurately reflect the contract status in all edge cases, potentially leading to unexpected behavior if critical logic depends on it (7.2 Code Security).
IssueThe `Address.isContract` function relies on `extcodehash` to determine if an address is a contract. While standard, `extcodehash` has known limitations: it returns 0 for contracts during their constructor execution, and it can be 0 for addresses that have self-destructed. This means it might not always accurately reflect the contract status in all edge cases, potentially leading to unexpected behavior if critical logic depends on it (7.2 Code Security).
FixBe aware of the limitations of `Address.isContract`. If the contract logic requires absolute certainty about an address being a contract, especially during deployment or after potential self-destruction, consider alternative or supplementary checks, or ensure that the context of its usage does not expose the system to these edge cases. For most standard uses, the current implementation is acceptable.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture leverages well-vetted OpenZeppelin libraries (7.1 Architecture), including EnumerableSet, Address, SafeMath, and AccessControl. Code security (7.2 Code Security) is enhanced by the consistent use of SafeMath for arithmetic operations, mitigating integer overflow/underflow risks. The Address library's `sendValue` function correctly handles external calls with success checks. However, the Solidity compiler version 0.6.2 is older, and the provided ERC20 implementation is incomplete, limiting a full assessment of its specific logic.

GovernanceMedium4/10

The contract implements a robust role-based access control system using OpenZeppelin's AccessControl (7.3 Access Control). This allows for granular permission management, with a `DEFAULT_ADMIN_ROLE` responsible for granting and revoking other roles. While this pattern centralizes administrative power, it is a standard and secure approach for managing permissions. Economic aspects (7.4 Economic) related to the token's specific functionalities (e.g., minting, burning, fees) cannot be fully assessed due to the truncated code, but the foundation for secure access control is present (7.5 Governance).

UpgradesHigh3/10

Based on the provided information and code snippet, the contract is not designed as an upgradeable proxy (7.7 Upgrades). This means the contract's logic is immutable once deployed, eliminating upgrade-related risks such as proxy misconfigurations or logic contract vulnerabilities introduced during upgrades. Any future changes would require a new deployment.

Security Checklist

Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

13.0% in wallets81.5% in contracts
Effective Concentration45.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

Show 4 more pairsShow less

The 3 remaining pairs hold $10 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 Holder23.3%
Top-3 Unlocked51.8%

Key Addresses

Deployer
0xa47c…7ac5
Unlocked LP Held By
0x6bce…3f220x2322…a3e80xd28b…ab270x234b…f3b70xd17c…d82c0xe7cf…6d1b0xfbbd…db7d0xdf59…67490x32b1…30f00x67ec…8b47

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

What Raised This Score

  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (94.5% total → 45.6% effective; 13.0% in EOAs, 81.5% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 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

Bitway Token (BTW)Medium RiskMarsCoinMedium RiskCZ'S DOG (BROCCOLI)Medium RiskCharacterX (CAI)Medium Risk永生果蝇 (果蝇)Medium RiskMame Inu (MAME)Medium Risk

Would You Like a More Detailed Audit of Fetch?

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

Get Detailed Audit