Quantum Audit Logo
Launch App

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

Is Goldfish Safe?

GGBREthereum
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 4, 2026 · 1 audit on record
Chart
Critical RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades1/10Checks passed3 of 7Findings1 Critical · 1 High · 1 Medium · 2 Low5
SummaryAI Copilot

The GoldfishToken contract, an upgradeable ERC-20, exhibits a high degree of centralization, particularly concerning the DEFAULT_ADMIN_ROLE.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply, nominal cap 3900%/year — effectively unbounded
  • Proxy contract
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 96.0%
  • LP top3 unlocked holders = 98.8%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 2 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply, nominal cap 3900%/year — effectively unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 70% (97.5% total → 92.5% effective; 89.2% in EOAs, 8.3% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 96.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 98.8% (independent LP — depth risk)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 2 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 43 of 7 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
8.3%89.2%Wallets2.5%
8.3%89.2%Wallets
ContractsWalletsEveryone elseBubble area = share of supply
97.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking8.3%
  • Walletsanonymous holders, free to sell89.2%
  • Everyone elsethe rest of the supply2.5%
Effective concentrationwhat the score reads92.5%
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 4, 2026

Liquidity

as of audit · Sep 4$181.2K

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$181.2KShare of depth100.0%
Top-1 Unlocked Holder96.0%
Top-3 Unlocked98.8%
Unlocked LP held by
0x946e…58b40x4236…aba80xb7f9…27880xd5d1…69e80x2c93…d23b0xbef7…9ea30xe30a…7c2d0x804f…deb10xda56…23f40xf41b…2919

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

Security Findings

1 Critical1 High1 Medium2 Low
Critical

Extreme Centralization and Backdoor Functionality (forceTransfer)

The DEFAULT_ADMIN_ROLE possesses extensive control, including the ability to upgrade the contract, blacklist accounts, set the minter, and crucially, execute forceTransfer. The forceTransfer function allows the admin to transfer any amount of tokens from any address to any other address without the token holder's consent. This represents a severe centralization risk and a direct backdoor, enabling arbitrary seizure or redistribution of user funds.C-01

Issue

The DEFAULT_ADMIN_ROLE possesses extensive control, including the ability to upgrade the contract, blacklist accounts, set the minter, and crucially, execute forceTransfer. The forceTransfer function allows the admin to transfer any amount of tokens from any address to any other address without the token holder's consent. This represents a severe centralization risk and a direct backdoor, enabling arbitrary seizure or redistribution of user funds.

Fix

Remove or significantly restrict the forceTransfer function. If such a function is deemed absolutely necessary for emergency scenarios, it should be protected by a multi-signature wallet with a time-lock, require a governance vote, or be limited to specific, predefined emergency conditions.

Status

Unresolved

High

Lack of Multi-signature / Time-lock for Critical Operations

All critical administrative roles (DEFAULT_ADMIN_ROLE, PAUSER_ROLE, FREEZER_ROLE, SUPPLY_MANAGER_ROLE) are initially granted to the deployer (msg.sender) and can be managed by the DEFAULT_ADMIN_ROLE. There are no multi-signature wallet requirements or time-locks implemented for sensitive operations such as contract upgrades, setting the minter, blacklisting, freezing, or using forceTransfer. This creates a single point of failure, making the protocol highly vulnerable to compromise of a single private key or malicious insider actions.H-01

Issue

All critical administrative roles (DEFAULT_ADMIN_ROLE, PAUSER_ROLE, FREEZER_ROLE, SUPPLY_MANAGER_ROLE) are initially granted to the deployer (msg.sender) and can be managed by the DEFAULT_ADMIN_ROLE. There are no multi-signature wallet requirements or time-locks implemented for sensitive operations such as contract upgrades, setting the minter, blacklisting, freezing, or using forceTransfer. This creates a single point of failure, making the protocol highly vulnerable to compromise of a single private key or malicious insider actions.

Fix

Implement a robust access control mechanism for critical roles, preferably using a multi-signature wallet (e.g., Gnosis Safe) for DEFAULT_ADMIN_ROLE and other sensitive roles. Consider adding time-locks for highly impactful operations like contract upgrades or forceTransfer to provide a window for users to react to potentially malicious actions.

Status

Unresolved

Medium

Arbitrary maxSupply Increase

The setMaxSupply function, callable by the SUPPLY_MANAGER_ROLE, allows increasing the maxSupply to an arbitrarily high value. While it prevents reducing the supply below the current totalSupply(), there is no upper bound or governance mechanism to limit how much the maxSupply can be increased. This could lead to unexpected and significant token inflation if the SUPPLY_MANAGER_ROLE is compromised or acts maliciously, devaluing existing token holdings.M-01

Issue

The setMaxSupply function, callable by the SUPPLY_MANAGER_ROLE, allows increasing the maxSupply to an arbitrarily high value. While it prevents reducing the supply below the current totalSupply(), there is no upper bound or governance mechanism to limit how much the maxSupply can be increased. This could lead to unexpected and significant token inflation if the SUPPLY_MANAGER_ROLE is compromised or acts maliciously, devaluing existing token holdings.

Fix

Implement a more constrained mechanism for maxSupply adjustments. Consider adding a maximum allowable increase percentage per operation, a time-lock for changes, or requiring a governance vote for significant increases. Alternatively, define a hard-coded, immutable maximum supply if the token is intended to be deflationary or have a fixed cap.

Status

Unresolved

Low

Disabled burnFrom Functionality

The burnFrom function, a standard part of the ERC20Burnable extension, has been explicitly disabled by reverting all calls. This design choice removes a common functionality that allows approved third parties (e.g., DeFi protocols) to burn tokens on behalf of a user. While a design decision, it limits the composability and utility of the token within the broader DeFi ecosystem.L-01

Issue

The burnFrom function, a standard part of the ERC20Burnable extension, has been explicitly disabled by reverting all calls. This design choice removes a common functionality that allows approved third parties (e.g., DeFi protocols) to burn tokens on behalf of a user. While a design decision, it limits the composability and utility of the token within the broader DeFi ecosystem.

Fix

Review the necessity of disabling burnFrom. If the intention is to prevent specific types of interactions, consider if alternative mechanisms or more granular controls could achieve the same security goals without completely removing standard functionality. If the decision is final, ensure clear documentation for users and integrators.

Status

Unresolved

Low

batchTransfer Self-Transfer Restriction

The batchTransfer function explicitly disallows self-transfers within the batch by including the check require(_recipients[i] != msg.sender, "Self-transfer not allowed");. While not a security vulnerability, this is an unusual restriction for a batch transfer function. Users might expect to be able to include their own address in a batch for various reasons (e.g., consolidating funds, rebalancing).L-02

Issue

The batchTransfer function explicitly disallows self-transfers within the batch by including the check require(_recipients[i] != msg.sender, "Self-transfer not allowed");. While not a security vulnerability, this is an unusual restriction for a batch transfer function. Users might expect to be able to include their own address in a batch for various reasons (e.g., consolidating funds, rebalancing).

Fix

Re-evaluate the necessity of preventing self-transfers in batchTransfer. If there's no specific security rationale, removing this restriction would improve user experience and align with common token transfer patterns. If it's a deliberate design choice, ensure it's clearly documented.

Status

Unresolved

Analysis

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

The GoldfishToken contract, an upgradeable ERC-20, exhibits a high degree of centralization, particularly concerning the DEFAULT_ADMIN_ROLE. A critical finding highlights the forceTransfer function, which acts as a backdoor allowing the admin to move any user's tokens. The absence of multi-signature protection or time-locks for critical operations further exacerbates these risks. While the contract leverages well-audited OpenZeppelin libraries for core functionalities and implements granular access control for specific actions, the overarching administrative power presents significant security and economic concerns.

Technical4/10Medium risk

The contract is built upon battle-tested OpenZeppelin libraries (ERC20Burnable, Pausable, AccessControl, UUPS), providing a solid foundation for its core ERC-20 functionalities (7.2 Code Security). Custom transfer logic in _update correctly implements checks for frozen and blacklisted accounts for sender, recipient, and spender. However, a critical technical risk is the forceTransfer function, which allows the DEFAULT_ADMIN_ROLE to arbitrarily move tokens from any address (7.3 Access Control). This function, combined with the lack of multi-signature protection, represents a severe centralization vulnerability.

Governance1/10High risk

The contract implements granular roles (PAUSER_ROLE, FREEZER_ROLE, SUPPLY_MANAGER_ROLE) which is a positive for delegated responsibilities (7.5 Governance). However, the DEFAULT_ADMIN_ROLE holds excessive power, including the ability to blacklist accounts, set the minter, and execute forceTransfer (7.3 Access Control). The SUPPLY_MANAGER_ROLE can arbitrarily increase maxSupply without upper limits, posing a significant economic risk for potential inflation (7.4 Economic). The absence of multi-signature wallets or time-locks for critical administrative actions creates a single point of failure and high governance risk (7.5 Governance).

Upgrades1/10High risk

The contract correctly implements the UUPS upgrade pattern using OpenZeppelin's UUPSUpgradeable module (7.7 Upgrades). The _authorizeUpgrade function is appropriately restricted to the DEFAULT_ADMIN_ROLE, ensuring that only authorized entities can initiate upgrades. The initializer is correctly disabled in the constructor, preventing re-initialization attacks. The primary upgrade risk stems from the immense power of the DEFAULT_ADMIN_ROLE, which, if compromised, could deploy malicious upgrades.

Final RecommendationWhat to do about this score

It is strongly recommended to implement a robust multi-signature wallet (e.g., Gnosis Safe) for the DEFAULT_ADMIN_ROLE and other critical roles to mitigate the single point of failure risk.

The forceTransfer function should be removed or protected by a multi-signature wallet with a time-lock and potentially a governance vote. Additionally, consider implementing stricter controls or governance for maxSupply adjustments to prevent arbitrary inflation.

Contract & Record

1 audit on record
TypeERC1967Proxy
NetworkEthereum
Token age10mo
Contract0x7e2a…b71a
Deployer0xd22d…c2f4
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Goldfish 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 1, 2026100Critical

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

Related Audits

6 more on the recordAll audits
SpaceX xStockSPCXX · Ethereum100CriticalBananaEthereum100CriticalPonsEthereum100CriticalAUSDEthereum100CriticalNVIDIA (Ondo Tokenized)NVDAON · Ethereum100CriticalRollbit CoinRLB · Ethereum100Critical

Would You Like a More Detailed Audit of Goldfish?

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