Quantum Audit Logo

Is Goldfish Safe?

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

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

Goldfish GGBR
0x7e2a…b71a
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

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.

1 Critical1 High1 Medium2 Low
Volume 24h
$1.5K
Liquidity
$181.2K
Price
$4.1700
Token Age
10mo
Top 10 Holders
97.5%

Security Findings

1 Crit1 High1 Med2 Low
Critical

Extreme Centralization and Backdoor Functionality (`forceTransfer`)

C-01The `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.
IssueThe `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.
FixRemove 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.
StatusUnresolved
High

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

H-01All 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.
IssueAll 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.
FixImplement 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.
StatusUnresolved
Medium

Arbitrary `maxSupply` Increase

M-01The `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.
IssueThe `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.
FixImplement 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.
StatusUnresolved
Low

Disabled `burnFrom` Functionality

L-01The `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.
IssueThe `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.
FixReview 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.
StatusUnresolved
Low

`batchTransfer` Self-Transfer Restriction

L-02The `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).
IssueThe `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).
FixRe-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.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

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.

GovernanceHigh1/10

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

UpgradesHigh1/10

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.

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 Uups
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

97.5% in top 10
89.2% in wallets8.3% in contracts
Effective Concentration92.5%

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

$181.2K

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 Holder96.0%
Top-3 Unlocked98.8%

Key Addresses

11 addresses
Deployer
0xd22d…c2f4
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.

What Raised This Score

11 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

Related Audits

6 more on the record
SpaceX xStock (SPCXX)Critical RiskBananaCritical RiskPonsCritical RiskAUSDCritical RiskHumanity (H)Critical RiskVision (VSN)Critical Risk

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