Quantum Audit Logo

Is Wrapped Gonka Safe?

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

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

Wrapped Gonka WGNK
0x972a…2f68
Ethereum
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.Own this token? Put it under verification →
Last checked 7d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

This audit reviewed a standard ERC20 token implementation. The contract adheres largely to the ERC20 specification, providing core token functionalities like transfer, approval, minting, and burning. Key strengths include the use of Solidity 0.8.19, which provides default overflow/underflow checks, and the modular design with virtual functions for extensibility. However, the explicit use of `unchecked` blocks for additions in `_mint` and `_transfer` introduces a potential integer overflow risk for `_totalSupply` and individual balances. Other findings are informational, related to standard ERC20 behaviors and architectural considerations for derived contracts. Note that the provided `Address` library code was truncated, but it is not directly utilized by the `ERC20` contract under review.

1 Medium4 Informational
Volume 24h
$178.6K
Liquidity
$907.0K
Price
$0.2136
Token Age
3mo
Top 10 Holders
79.7%

Security Findings

1 Med4 Info
Medium

Potential Integer Overflow in `_mint` and `_transfer` Additions

M-01The `_mint` function increments `_totalSupply` and `_balances[account]` within an `unchecked` block. Similarly, `_transfer` increments `_balances[to]` within an `unchecked` block. While Solidity 0.8+ generally provides overflow protection, explicit `unchecked` blocks disable this. If `_totalSupply` or a specific `_balances[account]` or `_balances[to]` is near `type(uint256).max` and a sufficiently large `amount` is added, an overflow could occur. This would lead to incorrect token supply, incorrect user balances, and could potentially be exploited to create 'phantom' tokens or disrupt token economics (7.2 Code Security).
IssueThe `_mint` function increments `_totalSupply` and `_balances[account]` within an `unchecked` block. Similarly, `_transfer` increments `_balances[to]` within an `unchecked` block. While Solidity 0.8+ generally provides overflow protection, explicit `unchecked` blocks disable this. If `_totalSupply` or a specific `_balances[account]` or `_balances[to]` is near `type(uint256).max` and a sufficiently large `amount` is added, an overflow could occur. This would lead to incorrect token supply, incorrect user balances, and could potentially be exploited to create 'phantom' tokens or disrupt token economics (7.2 Code Security).
FixEnsure that `_totalSupply` and individual `_balances` cannot overflow during addition. This can be achieved by either removing the `unchecked` blocks for additions (relying on default Solidity 0.8+ checks) or by adding explicit `require` statements to check for potential overflows before the addition, especially in `_mint` where `amount` is arbitrary. For `_transfer`, `_balances[to]` is bounded by `_totalSupply`, so if `_totalSupply` is handled correctly, `_balances[to]` overflow is less likely…
StatusUnresolved
Info

Potential `increaseAllowance` Overflow

I-01The `increaseAllowance` function directly adds `addedValue` to the current allowance without an explicit overflow check. While Solidity 0.8+ provides default overflow protection, if `allowance(owner, spender)` is already extremely high (e.g., near `type(uint256).max`) and `addedValue` is non-zero, an overflow could occur, resetting the allowance to a small value. This is an edge case for allowance manipulation (7.2 Code Security).
IssueThe `increaseAllowance` function directly adds `addedValue` to the current allowance without an explicit overflow check. While Solidity 0.8+ provides default overflow protection, if `allowance(owner, spender)` is already extremely high (e.g., near `type(uint256).max`) and `addedValue` is non-zero, an overflow could occur, resetting the allowance to a small value. This is an edge case for allowance manipulation (7.2 Code Security).
FixWhile highly improbable for practical use cases, consider adding an explicit overflow check for the addition in `increaseAllowance` if extreme allowance values are a concern, or rely on Solidity 0.8+ default checks by removing the `unchecked` block if it were present (though it's not in this specific function).
StatusUnresolved
Info

Standard ERC20 `approve` Race Condition

I-02The `approve` function is susceptible to a known front-running attack (7.4 Economic). If a user approves an amount, then approves a different amount for the same spender before the first transaction is mined, a malicious spender could front-run the second approval, causing the spender to be able to spend both the original and the new approved amounts. While `increaseAllowance` and `decreaseAllowance` mitigate some aspects of this, the core `approve` function still carries this risk.
IssueThe `approve` function is susceptible to a known front-running attack (7.4 Economic). If a user approves an amount, then approves a different amount for the same spender before the first transaction is mined, a malicious spender could front-run the second approval, causing the spender to be able to spend both the original and the new approved amounts. While `increaseAllowance` and `decreaseAllowance` mitigate some aspects of this, the core `approve` function still carries this risk.
FixEducate users about the `approve` race condition and recommend using `increaseAllowance` and `decreaseAllowance` functions when modifying an existing allowance, as these functions are less susceptible to this specific front-running vector. For new approvals, users should be aware of the risk.
StatusUnresolved
Info

Internal `_mint` and `_burn` Require Careful Access Control in Derived Contracts

I-03The `_mint` and `_burn` functions are declared as `internal virtual`. This is appropriate for a base ERC20 contract, as it prevents direct external calls. However, any contract inheriting from this `ERC20` implementation that exposes these functionalities externally (e.g., via a public `mint` or `burn` function) *must* implement robust access control mechanisms (e.g., `onlyOwner`, `onlyMinter`) to prevent unauthorized token creation or destruction (7.3 Access Control, 7.1 Architecture).
IssueThe `_mint` and `_burn` functions are declared as `internal virtual`. This is appropriate for a base ERC20 contract, as it prevents direct external calls. However, any contract inheriting from this `ERC20` implementation that exposes these functionalities externally (e.g., via a public `mint` or `burn` function) *must* implement robust access control mechanisms (e.g., `onlyOwner`, `onlyMinter`) to prevent unauthorized token creation or destruction (7.3 Access Control, 7.1 Architecture).
FixWhen extending this `ERC20` contract, ensure that any external functions that call `_mint` or `_burn` are protected by appropriate and secure access control modifiers to restrict who can perform these sensitive operations.
StatusUnresolved
Info

Empty `_beforeTokenTransfer` and `_afterTokenTransfer` Hooks

I-04The `_beforeTokenTransfer` and `_afterTokenTransfer` hook functions are implemented as empty virtual functions. While this is standard for a base ERC20 contract, it means no custom logic or security checks are enforced at the token transfer level by default (7.1 Architecture).
IssueThe `_beforeTokenTransfer` and `_afterTokenTransfer` hook functions are implemented as empty virtual functions. While this is standard for a base ERC20 contract, it means no custom logic or security checks are enforced at the token transfer level by default (7.1 Architecture).
FixDerived contracts should consider implementing these hooks to add custom logic, such as pausing transfers, blacklisting addresses, enforcing KYC/AML, or integrating with other protocol-specific functionalities, if required for the project's specific use case.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract implements a standard ERC20 token, demonstrating good adherence to the specification (7.1 Architecture). It utilizes Solidity 0.8.19, benefiting from default arithmetic safety, though `unchecked` blocks are used for additions in `_mint` and `_transfer`, which could lead to integer overflows if `_totalSupply` or balances approach `type(uint256).max` (7.2 Code Security). Access control for core ERC20 functions is standard (7.3 Access Control), and internal `_mint` and `_burn` functions correctly require external wrappers with proper access control in derived contracts.

GovernanceMedium4/10

The contract represents a basic ERC20 token without inherent governance or complex economic mechanisms (7.4 Economic, 7.5 Governance). Its economic model is straightforward, relying on standard token transfer and supply management. The `approve` function exhibits the standard ERC20 race condition, which is an inherent characteristic rather than an implementation flaw (7.4 Economic). No external dependencies or oracle integrations are present (7.6 External).

UpgradesLow7/10

The provided contract is a standalone ERC20 implementation and does not incorporate any explicit upgrade mechanisms or proxy patterns (7.7 Upgrades). This simplifies the deployment and reduces the attack surface associated with upgradeability. If future upgradeability is desired, a proxy pattern would need to be implemented, which would introduce new architectural considerations.

Security Checklist

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

Holder Composition

79.7% in top 10
17.9% in wallets61.8% in contracts
Effective Concentration42.6%

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

$908.8K across 3 pairs
Uniswap v3USDTanalysed$907.0K99.8%Uniswap v3USDT$1.8K0.2%Uniswap v4ETH$30.0%

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.7%
Top-3 Unlocked99.9%

Key Addresses

7 addresses
Deployer
0xc0ef…52bf
Unlocked LP Held By
0x2441…0b100x94f5…fbfb0xb284…0ff20x780e…17e50xef62…c7aa0x8e14…fe1e

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

What Raised This Score

6 factors
  • Ownership NOT renounced — Multisig (2-of-3)
  • Top-10 concentration > 30% (79.7% total → 42.6% effective; 17.9% in EOAs, 61.8% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 96.7% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • LP top3 unlocked holders = 99.9% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • 1 Medium 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
Artificial Superintelligence Alliance (FET)Medium RiskOndoMedium RiskRequest Token (REQ)Medium RiskIdentity.md (IMD)Medium RiskHighstreet token (HIGH)Medium RiskOutBurnMedium Risk

Would You Like a More Detailed Audit of Wrapped Gonka?

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

Get Detailed Audit