Quantum Audit Logo

Is GULD Safe?

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

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

GULD GULD
0x14d6…47a1
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

This report details the security audit of the Custom Token contract. The audit identified a high-severity issue related to potential integer overflow in balance updates within unchecked blocks, two medium-severity issues concerning ERC-20 non-compliance and centralized control, and other minor findings. The contract implements a basic ERC-20-like token with minting capabilities up to a maximum supply.

1 High2 Medium1 Low1 Informational
Volume 24h
$306.3K
Liquidity
$2.13M
Price
$0.02188
Token Age
1mo
Top 10 Holders
40.1%

Security Findings

1 High2 Med1 Low1 Info
High

Potential Integer Overflow in `balanceOf` Addition (unchecked block)

H-01The `mint` and `_updateBalance` functions use `unchecked` blocks for `balanceOf[to] += value;`. While `totalSupply` is capped by `maxSupply`, individual `balanceOf` values are not explicitly checked against `type(uint256).max` before addition within these `unchecked` blocks. If `maxSupply` is sufficiently large (e.g., close to `type(uint256).max`) and a large `value` is minted or transferred to an address already holding a large balance, the `balanceOf[to]` could wrap around, leading to an incorrect, lower balance for the recipient.
IssueThe `mint` and `_updateBalance` functions use `unchecked` blocks for `balanceOf[to] += value;`. While `totalSupply` is capped by `maxSupply`, individual `balanceOf` values are not explicitly checked against `type(uint256).max` before addition within these `unchecked` blocks. If `maxSupply` is sufficiently large (e.g., close to `type(uint256).max`) and a large `value` is minted or transferred to an address already holding a large balance, the `balanceOf[to]` could wrap around, leading to an incorrect, lower balance for the recipient.
FixRemove the `unchecked` block around `balanceOf[to] += value;` in both `mint` and `_updateBalance` functions. Solidity 0.8+ provides default overflow/underflow checks, which should be leveraged here to ensure `balanceOf` values do not wrap around.
StatusUnresolved
Medium

ERC-20 Non-Compliance for `totalSupply`

M-01The contract declares `totalSupply` as a public state variable (`uint256 public totalSupply;`) instead of implementing it as a public view function (`function totalSupply() external view returns (uint)`), as required by the ERC-20 standard. This deviation can cause compatibility issues with wallets, exchanges, and other DeFi protocols that expect the `totalSupply()` function to exist.
IssueThe contract declares `totalSupply` as a public state variable (`uint256 public totalSupply;`) instead of implementing it as a public view function (`function totalSupply() external view returns (uint)`), as required by the ERC-20 standard. This deviation can cause compatibility issues with wallets, exchanges, and other DeFi protocols that expect the `totalSupply()` function to exist.
FixChange `uint256 public totalSupply;` to `uint256 internal _totalSupply;` and implement the `totalSupply()` function as `function totalSupply() external view override returns (uint) { return _totalSupply; }`. Update all internal references to `totalSupply` to `_totalSupply`.
StatusUnresolved
Medium

Centralized Control Over Token Supply and Ownership

M-02The contract design grants significant power to the `owner` and `issuer` roles. The `owner` can transfer ownership (via a two-step process) and change the `issuer`. The `issuer` has the sole ability to `mint` new tokens up to the `maxSupply`. This centralization introduces a single point of failure and trust, as a compromised `owner` or `issuer` account could lead to unauthorized minting or control transfer.
IssueThe contract design grants significant power to the `owner` and `issuer` roles. The `owner` can transfer ownership (via a two-step process) and change the `issuer`. The `issuer` has the sole ability to `mint` new tokens up to the `maxSupply`. This centralization introduces a single point of failure and trust, as a compromised `owner` or `issuer` account could lead to unauthorized minting or control transfer.
FixAcknowledge this centralization as part of the token's design. If decentralization is desired in the future, consider implementing a multi-signature wallet for the `owner` and `issuer` roles, or integrating a governance mechanism to manage these critical functions.
StatusUnresolved
Low

Standard `approve` Function Front-Running Vulnerability

L-01The `approve` function, as implemented in the ERC-20 standard, is susceptible to a known front-running attack. If a user approves an amount `X` for a spender, and then decides to change the approved amount to `Y` (where `Y < X`), a malicious front-runner could observe the transaction to change the allowance, quickly execute the original allowance `X`, and then the user's transaction would set the allowance to `Y`, effectively allowing the front-runner to spend `X + Y`.
IssueThe `approve` function, as implemented in the ERC-20 standard, is susceptible to a known front-running attack. If a user approves an amount `X` for a spender, and then decides to change the approved amount to `Y` (where `Y < X`), a malicious front-runner could observe the transaction to change the allowance, quickly execute the original allowance `X`, and then the user's transaction would set the allowance to `Y`, effectively allowing the front-runner to spend `X + Y`.
FixAdvise users to always set the allowance to zero before setting a new non-zero allowance, i.e., call `approve(spender, 0)` then `approve(spender, newAmount)`. Alternatively, consider implementing an `increaseAllowance` and `decreaseAllowance` pattern to mitigate this user-side risk.
StatusUnresolved
Info

Lack of Token Burn Mechanism

I-01The contract does not include a function to burn tokens, which means tokens can only be transferred or minted (up to `maxSupply`). There is no mechanism to permanently remove tokens from circulation, which might be desired for certain economic models or to recover tokens sent to unrecoverable addresses.
IssueThe contract does not include a function to burn tokens, which means tokens can only be transferred or minted (up to `maxSupply`). There is no mechanism to permanently remove tokens from circulation, which might be desired for certain economic models or to recover tokens sent to unrecoverable addresses.
FixIf a token burn mechanism is desired, consider adding a `burn` function that allows token holders to destroy their own tokens, or an `ownerBurn` function for administrative burning, ensuring appropriate access controls are in place.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract exhibits a clear structure and generally follows common Solidity patterns. Strengths include the use of `immutable` for critical parameters like `decimals` and `maxSupply`, and a two-step ownership transfer mechanism (7.3 Access Control). However, a significant concern is the use of `unchecked` blocks for `balanceOf` additions in `mint` and `_updateBalance`, which could lead to integer overflow and balance corruption (7.2 Code Security). Additionally, the `totalSupply` is implemented as a public state variable instead of a function, causing ERC-20 non-compliance (7.1 Architecture).

GovernanceHigh2/10

The token's economic model is straightforward, with a fixed `maxSupply` and a centralized `issuer` role responsible for minting (7.4 Economic). The `owner` role holds significant power, including the ability to change the `issuer` and transfer ownership (7.5 Governance). This centralization introduces a single point of failure, requiring strong operational security for the controlling addresses (7.8 Operations). The `maxSupply` is immutable, providing a predictable supply cap.

UpgradesHigh3/10

This contract is not designed to be upgradeable. Its logic is immutable once deployed, which eliminates upgrade-related risks such as proxy misconfigurations or malicious upgrade implementations (7.7 Upgrades). Any changes to the token's core logic would require a new deployment.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

40.1% in top 10
15.7% in wallets24.3% in contracts
Effective Concentration25.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

$8.10M across 11 pairs
Uniswap v4GIVEanalysed$2.13M26.3%Uniswap v4ELEVATE$1.96M24.2%Uniswap v4CDXR$1.89M23.3%Uniswap v4ELEVATE$1.86M22.9%Uniswap v4USDT$98.2K1.2%Uniswap v4SWITCH$57.1K0.7%
Show 4 more pairsShow less
Uniswap v4WIN$54.1K0.7%Uniswap v4GROW$46.7K0.6%Uniswap v4RALLY$3.4K0.0%Uniswap v4USDC$7430.0%

One more pair holds $108 and is 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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

3 addresses
Deployer
0xf746…993b
Unlocked LP Held By
0x9210…7e7e0x8173…9596

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

What Raised This Score

9 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 20% (40.1% total → 25.5% effective; 15.7% in EOAs, 24.3% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 26% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 26% of DEX liquidity)
  • 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
Token Prometeus Network (PROM)High RiskFake World Assets (FWA)High RiskPrismHigh RiskStaked USDe (SUSDE)High RiskDeXeHigh RiskTether Gold (XAUT)High Risk

Would You Like a More Detailed Audit of GULD?

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

Get Detailed Audit