Quantum Audit Logo

Is GU Factory a Scam?

Early-stage security check — honeypot & rug-pull analysis

GU Factory GU
0xff3e…533f
Arbitrum
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.
Last checked 7d ago 1 audit on record New Launch · 2d old
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The GuCoin contract implements an ERC-20 token with LayerZero OFT capabilities, integrating with a bonding curve and liquidity manager. It features an automatic LP seeding mechanism and a fee distribution model. The contract exhibits a high degree of centralization, relying heavily on external contracts and privileged roles for critical operations like token minting, burning, and initial liquidity provisioning. Several potential economic and technical risks have been identified, primarily stemming from centralized control, reliance on external contract integrity, and specific implementation details that could lead to operational issues or front-running opportunities.

1 High3 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (2d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$211.9K
Liquidity
$39.0K
Price
$0.004421
Token Age
2d
Top 10 Holders
75.7%

Security Findings

1 High3 Med1 Low1 Info
High

Centralized Control over Critical Functions

H-01The `mint` and `burnCurve` functions are exclusively callable by the `bondingCurve` contract, granting it significant control over the GuCoin token supply. If the `bondingCurve` contract is compromised or contains vulnerabilities, it could lead to unauthorized minting or burning, impacting the token's economic stability. Additionally, the `_seedLP` function, which initializes liquidity and distributes a substantial portion of the reserve token balance, automatically transfers funds to the `creator` and `owner()` (protocol owner). This centralizes control over initial liquidity distribution and involves large value transfers to privileged addresses, posing a single point of failure risk (7.3…
IssueThe `mint` and `burnCurve` functions are exclusively callable by the `bondingCurve` contract, granting it significant control over the GuCoin token supply. If the `bondingCurve` contract is compromised or contains vulnerabilities, it could lead to unauthorized minting or burning, impacting the token's economic stability. Additionally, the `_seedLP` function, which initializes liquidity and distributes a substantial portion of the reserve token balance, automatically transfers funds to the `creator` and `owner()` (protocol owner). This centralizes control over initial liquidity distribution and involves large value transfers to privileged addresses, posing a single point of failure risk (7.3…
FixImplement a multi-signature wallet or a timelock for the `owner()` address to manage protocol fees and for any administrative functions within the `bondingCurve` contract. This would introduce a delay or require multiple approvals for critical operations, reducing the risk of a single point of compromise. Ensure the `bondingCurve` contract itself undergoes rigorous security audits.
StatusUnresolved
Medium

Potential for Front-Running in _seedLP Trigger

M-01The `_seedLP` function is triggered internally when `totalSupply()` reaches `MAX_SUPPLY` after a `mint` operation. The address that performs the final `mint` to push the supply over `MAX_SUPPLY` becomes the `caller` in `_seedLP` and receives a portion of the `CREATOR_FEE` (`reserveTokenBalance * CREATOR_FEE / 20_000`). An attacker could monitor the `totalSupply()` and front-run the transaction that would trigger `_seedLP`, ensuring they are the `caller` and thus receiving a fee. While the amount might be small, it represents an unnecessary incentive for front-running and potential for unfair distribution (7.4 Economic).
IssueThe `_seedLP` function is triggered internally when `totalSupply()` reaches `MAX_SUPPLY` after a `mint` operation. The address that performs the final `mint` to push the supply over `MAX_SUPPLY` becomes the `caller` in `_seedLP` and receives a portion of the `CREATOR_FEE` (`reserveTokenBalance * CREATOR_FEE / 20_000`). An attacker could monitor the `totalSupply()` and front-run the transaction that would trigger `_seedLP`, ensuring they are the `caller` and thus receiving a fee. While the amount might be small, it represents an unnecessary incentive for front-running and potential for unfair distribution (7.4 Economic).
FixRe-evaluate the mechanism for distributing the `CREATOR_FEE` portion to the `caller` in `_seedLP`. Consider distributing this portion to a neutral address (e.g., the `creator` or `owner`) or removing this specific incentive to prevent front-running. Alternatively, ensure the `_seedLP` function is only callable by a trusted entity after `MAX_SUPPLY` is reached, rather than being automatically triggered by any `mint`.
StatusUnresolved
Medium

Incompatibility with Fee-on-Transfer Reserve Tokens

M-02The `_transferReserveExact` function, used for distributing fees and seeding LP, includes a strict check: `if (reserveToken.balanceOf(to) != recipientBalance + amount) { revert InvalidReserveBalance(); }`. If the `RESERVE_TOKEN` is a fee-on-transfer token (which deducts a percentage from the transferred amount), the recipient will receive slightly less than `amount`. Consequently, this check will always fail, causing the transaction to revert. This would prevent the `_seedLP` function from completing successfully, effectively blocking the token's launch and liquidity provisioning, and also preventing any subsequent fee distributions that rely on this function (7.2 Code Security, 7.4 Economi…
IssueThe `_transferReserveExact` function, used for distributing fees and seeding LP, includes a strict check: `if (reserveToken.balanceOf(to) != recipientBalance + amount) { revert InvalidReserveBalance(); }`. If the `RESERVE_TOKEN` is a fee-on-transfer token (which deducts a percentage from the transferred amount), the recipient will receive slightly less than `amount`. Consequently, this check will always fail, causing the transaction to revert. This would prevent the `_seedLP` function from completing successfully, effectively blocking the token's launch and liquidity provisioning, and also preventing any subsequent fee distributions that rely on this function (7.2 Code Security, 7.4 Economi…
FixClarify in the documentation that the `RESERVE_TOKEN` must not be a fee-on-transfer token. If fee-on-transfer tokens are intended to be supported, modify the `_transferReserveExact` function to account for potential transfer fees, for example, by checking `reserveToken.balanceOf(to) >= recipientBalance + amount - tolerance` or by simply removing the strict equality check if the exact amount received is not critical for protocol logic.
StatusUnresolved
Medium

High Reliance on External Contracts

M-03The `GuCoin` contract heavily relies on the correct and secure functioning of several external contracts, including `IGuBondingCurve`, `IGuLiquidityManager`, and `IGuFactory`. For instance, `price()` depends on `IGuBondingCurve.getAmountOutSell`, and initial liquidity provisioning is handled by `IGuLiquidityManager.createAndInitializePool` and `seedLP`. The `FACTORY` contract determines critical addresses like `LIQUIDITY_MANAGER` and `harvester`. Any vulnerability, misconfiguration, or malicious upgrade in these external contracts could directly impact the `GuCoin` token's functionality, value, and overall system integrity (7.1 Architecture, 7.6 External).
IssueThe `GuCoin` contract heavily relies on the correct and secure functioning of several external contracts, including `IGuBondingCurve`, `IGuLiquidityManager`, and `IGuFactory`. For instance, `price()` depends on `IGuBondingCurve.getAmountOutSell`, and initial liquidity provisioning is handled by `IGuLiquidityManager.createAndInitializePool` and `seedLP`. The `FACTORY` contract determines critical addresses like `LIQUIDITY_MANAGER` and `harvester`. Any vulnerability, misconfiguration, or malicious upgrade in these external contracts could directly impact the `GuCoin` token's functionality, value, and overall system integrity (7.1 Architecture, 7.6 External).
FixEnsure all external contracts (`IGuBondingCurve`, `IGuLiquidityManager`, `IGuFactory`) undergo comprehensive security audits. Implement robust monitoring for these external contracts, especially if they are upgradeable, to detect any suspicious activity or changes. Clearly document the expected behavior and security assumptions regarding these dependencies.
StatusUnresolved
Low

Potential `accReserve` Desynchronization

L-01The `accReserve` variable is an internal accounting mechanism for the reserve, incremented during `mint` and decremented during `burnCurve`. While `mint` includes a check against the actual `RESERVE_TOKEN` balance, `accReserve` could become desynchronized from the actual `RESERVE_TOKEN` balance held by the `GuCoin` contract if `RESERVE_TOKEN` is transferred to or from the `GuCoin` contract outside of the `mint` or `burnCurve` functions (e.g., accidental transfers). This desynchronization could lead to `TVL()` misrepresenting the actual backing of the token (7.2 Code Security, 7.4 Economic).
IssueThe `accReserve` variable is an internal accounting mechanism for the reserve, incremented during `mint` and decremented during `burnCurve`. While `mint` includes a check against the actual `RESERVE_TOKEN` balance, `accReserve` could become desynchronized from the actual `RESERVE_TOKEN` balance held by the `GuCoin` contract if `RESERVE_TOKEN` is transferred to or from the `GuCoin` contract outside of the `mint` or `burnCurve` functions (e.g., accidental transfers). This desynchronization could lead to `TVL()` misrepresenting the actual backing of the token (7.2 Code Security, 7.4 Economic).
FixConsider adding a mechanism for a privileged role (e.g., `owner()`) to reconcile `accReserve` with the actual `RESERVE_TOKEN` balance, or to recover accidentally sent `RESERVE_TOKEN`s. Alternatively, ensure that the contract's design strictly prevents any external transfers of `RESERVE_TOKEN` to or from the `GuCoin` contract outside of its intended functions.
StatusUnresolved
Info

Immutability of Key Parameters

I-01Many critical parameters such as `FACTORY`, `POSITION_MANAGER`, `LIQUIDITY_MANAGER`, `RESERVE_TOKEN`, `VIRTUAL_BALANCE`, `INITIAL_SUPPLY`, `MAX_SUPPLY`, `PROTOCOL_FEE`, `CREATOR_FEE`, `COMMUNITY_FEE_RATIO`, `creator`, `bondingCurve`, and `lp` are declared as `immutable`. This design choice provides strong guarantees about the system's core configuration, preventing malicious changes post-deployment (7.1 Architecture). However, it also means that if any of these parameters are set incorrectly during deployment, they cannot be changed, potentially leading to a permanent malfunction or loss of funds.
IssueMany critical parameters such as `FACTORY`, `POSITION_MANAGER`, `LIQUIDITY_MANAGER`, `RESERVE_TOKEN`, `VIRTUAL_BALANCE`, `INITIAL_SUPPLY`, `MAX_SUPPLY`, `PROTOCOL_FEE`, `CREATOR_FEE`, `COMMUNITY_FEE_RATIO`, `creator`, `bondingCurve`, and `lp` are declared as `immutable`. This design choice provides strong guarantees about the system's core configuration, preventing malicious changes post-deployment (7.1 Architecture). However, it also means that if any of these parameters are set incorrectly during deployment, they cannot be changed, potentially leading to a permanent malfunction or loss of funds.
FixEnsure extremely thorough testing and verification of all constructor parameters before deployment to production environments. Consider a multi-stage deployment or a 'dry run' on a testnet to confirm all immutable parameters are set correctly according to the protocol's specifications.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The GuCoin contract demonstrates a well-structured design, inheriting from OFT and Ownable, and utilizing SafeERC20 for secure token interactions. The implementation includes robust checks like `_validateBondingCurve` and `_transferReserveExact` to prevent unauthorized actions and ensure correct reserve transfers (7.2 Code Security). However, the contract's reliance on external contracts for core functionalities like bonding curve logic and liquidity management introduces significant technical risk (7.6 External). Furthermore, the centralized control over `mint` and `burnCurve` functions by the `bondingCurve` contract (7.3 Access Control) means that vulnerabilities in that external contract could directly compromise GuCoin's supply.

GovernanceHigh1/10

The economic model incorporates virtual reserves, initial supply, and a maximum supply, alongside protocol and creator fees, demonstrating a structured approach to tokenomics (7.4 Economic). The automatic LP seeding mechanism aims to ensure initial liquidity. However, the distribution of significant portions of the reserve token balance to the `creator` and `owner()` during LP seeding introduces a high degree of centralization and potential for large value transfers (7.4 Economic). The `bondingCurve` contract's exclusive control over `mint` and `burnCurve` functions also centralizes economic power, making the system vulnerable to issues within that external component (7.5 Governance).

UpgradesHigh3/10

The GuCoin contract itself is not designed for upgradeability, as indicated by `is_proxy: false` and the absence of proxy patterns. This reduces the risk of upgrade-related vulnerabilities for this specific contract. However, the contract relies heavily on immutable addresses for external components like `bondingCurve`, `liquidityManager`, and `factory`. If any of these external contracts are upgradeable, their upgradeability could introduce risks to the GuCoin system, requiring careful monitoring of those dependencies (7.7 Upgrades).

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

75.7% in top 10
7.5% in wallets68.2% in contracts
Effective Concentration34.8%

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

$69.2K across 2 pairs
UniswapWETHanalysed$39.0K56.4%UniswapARB$30.2K43.6%

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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0xb01c…9c2e
Unlocked LP Held By
0x700a…1232

A privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.

What Raised This Score

10 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (75.7% total → 34.8% effective; 7.5% in EOAs, 68.2% in contracts — moderate)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • LP top1 unlocked holder = 100.0% (exit-liquidity risk, pool = 56% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (exit-liquidity risk, pool = 56% of DEX liquidity)
  • Token age < 7 days (early, volatile)
  • 1 High finding(s) from audit
  • 3 Medium 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

Related Audits

6 more on the record
Ninja Squad Token (NST)Critical RiskAxelar Wrapped LAVA (LAVA)Critical RiskGUBERTOCritical RiskVangrid (VAN)Critical RiskMORCritical RiskDGrid AI (DGAI)Critical Risk

Would You Like a More Detailed Audit of GU Factory?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit