Quantum Audit Logo

Is GUBERTO Safe?

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

GUBERTO GUBERTO
0x4727…9b40
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
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 for its economic model. Key features include dynamic supply management, fee distribution, and automated LP seeding. The audit identified a high-severity reentrancy risk in ETH transfers, medium-severity issues related to fee configuration and LP seeding mechanics, and a low-severity concern regarding unaccounted ETH. The contract's reliance on external contracts also introduces dependency risks.

1 High2 Medium1 Low1 Informational
Volume 24h
$114.6K
Liquidity
$30.1K
Price
$0.0003106
Token Age
1y
Top 10 Holders
89.8%

Security Findings

1 High2 Med1 Low1 Info
High

Reentrancy Risk in `burnCurve` ETH Transfer

H-01The `burnCurve` function performs an external call `bondingCurve.call{value: amountETH}("")` after modifying `accETH` and burning tokens. While `_validateBondingCurve()` restricts calls to the `bondingCurve` contract, if the `bondingCurve` contract is malicious or compromised, it could re-enter the `GuCoin` contract and potentially drain funds or manipulate state before the transaction completes. This violates the Checks-Effects-Interactions pattern.
IssueThe `burnCurve` function performs an external call `bondingCurve.call{value: amountETH}("")` after modifying `accETH` and burning tokens. While `_validateBondingCurve()` restricts calls to the `bondingCurve` contract, if the `bondingCurve` contract is malicious or compromised, it could re-enter the `GuCoin` contract and potentially drain funds or manipulate state before the transaction completes. This violates the Checks-Effects-Interactions pattern.
FixImplement a reentrancy guard (e.g., OpenZeppelin's `ReentrancyGuard`) on the `burnCurve` function. Alternatively, consider using `transfer` instead of `call` for fixed gas stipend, or ensure that all state changes are completed before any external calls are made.
StatusUnresolved
Medium

Fee Distribution Vulnerability in `_seedLP`

M-01The `_seedLP` function distributes WETH to `creator`, `owner()`, and `caller` based on `PROTOCOL_FEE` and `CREATOR_FEE`. Specifically, `creator` receives `CREATOR_FEE / 10_000`, `owner()` receives `PROTOCOL_FEE / 10_000`, and `caller` receives `CREATOR_FEE / 20_000`. If the sum of these percentages (i.e., `1.5 * CREATOR_FEE + PROTOCOL_FEE`) exceeds `10_000` (representing 100%), the contract will attempt to transfer more WETH than it holds, causing a revert and preventing LP seeding. This is a configuration risk.
IssueThe `_seedLP` function distributes WETH to `creator`, `owner()`, and `caller` based on `PROTOCOL_FEE` and `CREATOR_FEE`. Specifically, `creator` receives `CREATOR_FEE / 10_000`, `owner()` receives `PROTOCOL_FEE / 10_000`, and `caller` receives `CREATOR_FEE / 20_000`. If the sum of these percentages (i.e., `1.5 * CREATOR_FEE + PROTOCOL_FEE`) exceeds `10_000` (representing 100%), the contract will attempt to transfer more WETH than it holds, causing a revert and preventing LP seeding. This is a configuration risk.
FixEnsure that the sum of `1.5 * CREATOR_FEE + PROTOCOL_FEE` is always less than or equal to `10_000`. Implement a check in the constructor or a setter function (if fees were mutable) to enforce this invariant. Thoroughly test fee calculations with various valid and edge-case values.
StatusUnresolved
Medium

`_seedLP` Triggered by Last Buyer

M-02The `_seedLP` function, which seeds the liquidity pool and distributes a portion of the `CREATOR_FEE` to the `caller`, is triggered when `totalSupply()` reaches `MAX_SUPPLY` during a `mint` operation. This design means the last buyer to mint tokens could potentially be front-run by another user to become the `caller` and receive the `CREATOR_FEE / 20_000` portion. This introduces an element of unpredictability and potential for gas wars or unfair distribution.
IssueThe `_seedLP` function, which seeds the liquidity pool and distributes a portion of the `CREATOR_FEE` to the `caller`, is triggered when `totalSupply()` reaches `MAX_SUPPLY` during a `mint` operation. This design means the last buyer to mint tokens could potentially be front-run by another user to become the `caller` and receive the `CREATOR_FEE / 20_000` portion. This introduces an element of unpredictability and potential for gas wars or unfair distribution.
FixConsider alternative mechanisms for triggering `_seedLP` and distributing the `caller`'s fee. Options include: (1) having a dedicated, permissioned function for LP seeding, (2) distributing the `caller`'s fee to a more deterministic address (e.g., the `creator` or `owner`), or (3) implementing a mechanism to prevent front-running for this specific transaction.
StatusUnresolved
Low

Unaccounted ETH in `_seedLP`

L-01The `_seedLP` function wraps `address(this).balance` into WETH for distribution. If ETH is sent directly to the `GuCoin` contract (e.g., via `selfdestruct` from another contract, or a direct `send`/`transfer` from an EOA) *after* the constructor but *before* `_seedLP` is called, this unaccounted ETH would be included in the LP seeding and fee distribution. This could lead to unintended beneficiaries receiving a portion of this extra ETH or an inflated LP.
IssueThe `_seedLP` function wraps `address(this).balance` into WETH for distribution. If ETH is sent directly to the `GuCoin` contract (e.g., via `selfdestruct` from another contract, or a direct `send`/`transfer` from an EOA) *after* the constructor but *before* `_seedLP` is called, this unaccounted ETH would be included in the LP seeding and fee distribution. This could lead to unintended beneficiaries receiving a portion of this extra ETH or an inflated LP.
FixEnsure that the `GuCoin` contract does not receive ETH directly outside of its intended `mint` function (which is restricted to the `bondingCurve`). If direct ETH transfers are not intended, consider adding a `receive()` or `fallback()` function that reverts to prevent accidental or malicious ETH deposits. If ETH is expected, ensure it's accounted for in the economic model.
StatusUnresolved
Info

Centralization Risk via External Contracts

I-01The `GuCoin` contract heavily relies on the security and correct functioning of several external contracts, including `IGuBondingCurve`, `IGuLiquidityManager`, and `IGuFactory`. These contracts are immutable addresses set in the constructor. A compromise, malfunction, or malicious upgrade in any of these external dependencies could directly impact the `GuCoin`'s operations, economic model, and overall integrity. (7.6 External)
IssueThe `GuCoin` contract heavily relies on the security and correct functioning of several external contracts, including `IGuBondingCurve`, `IGuLiquidityManager`, and `IGuFactory`. These contracts are immutable addresses set in the constructor. A compromise, malfunction, or malicious upgrade in any of these external dependencies could directly impact the `GuCoin`'s operations, economic model, and overall integrity. (7.6 External)
FixEnsure that all external contracts integrated with `GuCoin` undergo rigorous security audits and are managed by trusted entities. Implement robust monitoring for these external dependencies to detect any unusual behavior promptly. While the addresses are immutable, the logic within those contracts is critical.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The GuCoin contract demonstrates a well-structured architecture, leveraging immutable state variables for critical addresses and parameters (7.1 Architecture). It inherits from LayerZero's OFT for cross-chain functionality and OpenZeppelin's Ownable for basic access control. However, a reentrancy vulnerability exists in the `burnCurve` function's ETH transfer (7.2 Code Security), and potential misconfigurations in fee distribution could lead to reverts during LP seeding (7.4 Economic). The contract also relies heavily on external contracts, introducing dependency risks (7.6 External).

GovernanceHigh1/10

The economic model centers around a bonding curve, with `VIRTUAL_BALANCE`, `INITIAL_SUPPLY`, and `MAX_SUPPLY` defining token dynamics (7.4 Economic). Fees are distributed to the creator, protocol owner, and the caller who triggers LP seeding. A design choice allows the last buyer to trigger LP seeding and receive a portion of the creator fee, which could be subject to front-running (7.4 Economic). Access control for core functions like `mint` and `burnCurve` is appropriately restricted to the `bondingCurve` contract (7.3 Access Control).

UpgradesHigh3/10

The GuCoin contract is not designed with upgradeability in mind (7.7 Upgrades). All critical addresses and parameters are set as `immutable` in the constructor, ensuring their immutability post-deployment. This design choice eliminates upgrade-related risks such as proxy misconfigurations or logic contract vulnerabilities.

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

89.8% in top 10
12.0% in wallets77.8% in contracts
Effective Concentration43.1%

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

$30.1K

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

3 addresses
Deployer
0xd476…38b1
Unlocked LP Held By
0xe819…0dd20xca93…9643

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

What Raised This Score

10 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (89.8% total → 43.1% effective; 12.0% in EOAs, 77.8% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($30,099 across 1 pairs — thin market)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 High finding(s) from audit
  • 2 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
Vangrid (VAN)Critical RiskMORCritical RiskDGrid AI (DGAI)Critical RiskAxelar Wrapped LAVA (LAVA)Critical RiskNinja Squad Token (NST)Critical RiskUnicity Labs (UNYLA)Critical Risk

Would You Like a More Detailed Audit of GUBERTO?

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

Get Detailed Audit