Quantum Audit Logo
Launch App

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

Is Graph Token Safe?

GRTEthereum
Not verified This 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 Sep 4, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance2/10Upgrades3/10Checks passed2 of 5Findings1 High · 2 Low · 1 Info4
SummaryAI Copilot

The GraphToken contract implements a standard ERC20 token with burnable functionality and utilizes SafeMath for arithmetic safety.

Read the full analysis
What raised the score
  • Ownership not renounced
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 55.6%
  • 1 High finding(s) from audit
  • 2 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced (admin/mint authority retained)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (55.2% total → 34.0% effective; 19.9% in EOAs, 35.3% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 55.6% (independent LP — depth risk, pool = 70% of DEX liquidity)
  • 1 High 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
35.3%Contracts19.9%Wallets44.8%Everyone else
35.3%Contracts19.9%Wallets44.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
55.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking35.3%
  • Walletsanonymous holders, free to sell19.9%
  • Everyone elsethe rest of the supply44.8%
Effective concentrationwhat the score reads34.0%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$186.0K across 10 pairs
Show 4 more pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$130.8KShare of depth70.3%
Top-1 Unlocked Holder55.6%
Top-3 Unlocked76.6%
Unlocked LP held by
0x0037…48880x26fc…65b50x2291…2b3c0x9e41…86500xa375…89520x9431…bf1a0xcaa7…ebdd0xcdae…186f0xed89…ebca0x10e5…19e4

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

Security Findings

1 High2 Low1 Info
High

Centralized Control over Token Supply (Potential)

The _mint function is internal virtual, implying that a derived contract (such as GraphToken itself) could expose a public mint function. If such a function exists and is controlled by the governor (as suggested by the Governed contract), it introduces a significant centralization risk. The governor would have the ability to arbitrarily inflate the token supply, potentially devaluing existing tokens and impacting the token's economic model.H-01

Issue

The _mint function is internal virtual, implying that a derived contract (such as GraphToken itself) could expose a public mint function. If such a function exists and is controlled by the governor (as suggested by the Governed contract), it introduces a significant centralization risk. The governor would have the ability to arbitrarily inflate the token supply, potentially devaluing existing tokens and impacting the token's economic model.

Fix

If the token is intended to have a fixed supply, ensure no public mint function is exposed, or remove the _mint functionality entirely after initial deployment. If minting is required, implement strict access controls, ideally through a multi-signature wallet or a decentralized governance mechanism, and define clear limits or conditions for minting.

Status

Unresolved

Low

Older Solidity Compiler Version

The contract uses Solidity ^0.7.0 and ^0.7.3, with the compiler version specified as 0.7.4. While functional, these versions are older. Newer compiler versions (e.g., 0.8.x) offer additional security features, such as default overflow/underflow checks (removing the need for SafeMath in many cases), and gas optimizations.L-01

Issue

The contract uses Solidity ^0.7.0 and ^0.7.3, with the compiler version specified as 0.7.4. While functional, these versions are older. Newer compiler versions (e.g., 0.8.x) offer additional security features, such as default overflow/underflow checks (removing the need for SafeMath in many cases), and gas optimizations.

Fix

Consider upgrading the Solidity compiler version to 0.8.x or higher. This would allow the contract to benefit from the latest security enhancements and gas efficiencies. Thorough testing would be required after such an upgrade.

Status

Unresolved

Low

Lack of Pausability Mechanism

The contract lacks a mechanism to pause token transfers or other critical functions. In the event of an emergency, such as a critical bug discovery, an exploit, or severe market manipulation, there is no way for the administrators to temporarily halt operations to prevent further damage or mitigate ongoing attacks.L-02

Issue

The contract lacks a mechanism to pause token transfers or other critical functions. In the event of an emergency, such as a critical bug discovery, an exploit, or severe market manipulation, there is no way for the administrators to temporarily halt operations to prevent further damage or mitigate ongoing attacks.

Fix

Implement a pausability mechanism (e.g., using OpenZeppelin's Pausable contract) controlled by the governor or a multi-signature wallet. This would provide an essential emergency stop-gap, allowing time to address critical issues without immediate, irreversible harm to users or the protocol.

Status

Unresolved

Info

ERC20 approve Race Condition

The standard approve function in ERC20 tokens is susceptible to a known front-running vulnerability. If a user approves an amount, then attempts to change that approved amount to a different non-zero value, a malicious actor could front-run the second transaction, execute the first approved amount, and then the second approved amount, potentially draining more funds than intended. While increaseAllowance and decreaseAllowance are provided, users might still directly use approve(spender, amount).I-01

Issue

The standard approve function in ERC20 tokens is susceptible to a known front-running vulnerability. If a user approves an amount, then attempts to change that approved amount to a different non-zero value, a malicious actor could front-run the second transaction, execute the first approved amount, and then the second approved amount, potentially draining more funds than intended. While increaseAllowance and decreaseAllowance are provided, users might still directly use approve(spender, amount).

Fix

Educate users to always set their allowance to zero before approving a new non-zero amount, or to exclusively use the increaseAllowance and decreaseAllowance functions to modify existing allowances. This is a user-side best practice rather than a contract-side fix.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The GraphToken contract implements a standard ERC20 token with burnable functionality and utilizes SafeMath for arithmetic safety. It includes a Governed contract for administrative ownership transfer. Key strengths include robust arithmetic handling and a secure two-step ownership transfer process. However, potential centralization risks related to token supply management and the use of an older Solidity compiler version are noted. The contract also lacks a pausability mechanism, which could hinder emergency response.

Technical7/10Low risk

The contract utilizes SafeMath for all arithmetic operations, effectively mitigating integer overflow/underflow vulnerabilities (7.2 Code Security). The implementation adheres to the ERC20 standard, including increaseAllowance and decreaseAllowance to help mitigate common approve race conditions (7.2 Code Security). However, the use of an older Solidity compiler version (0.7.4) means the contract does not benefit from newer security features and optimizations available in later versions (7.2 Code Security). Additionally, the _setupDecimals function, while internal, allows modification of decimals post-construction, which could be problematic if exposed (7.2 Code Security).

Governance2/10High risk

The Governed contract implements a two-step ownership transfer process (transferOwnership and acceptOwnership), which is a good practice for securing administrative control (7.5 Governance). However, the potential for the governor to control token minting (if a public mint function is exposed by GraphToken) introduces a significant centralization risk, allowing arbitrary supply inflation (7.4 Economic). The lack of a pause mechanism also limits emergency response capabilities in critical situations (7.8 Operations).

Upgrades3/10High risk

The contract is not identified as a proxy, meaning its core logic is immutable once deployed, providing certainty for users (7.7 Upgrades). As a non-upgradeable contract, any discovered critical vulnerabilities would necessitate a new deployment and migration, which can be complex and costly for the ecosystem (7.7 Upgrades). The Governed contract manages ownership transfer, but this only applies to administrative roles, not the core contract logic (7.7 Upgrades).

Final RecommendationWhat to do about this score

It is recommended to consider migrating to a newer Solidity compiler version (e.g., 0.8.x) to leverage enhanced security features and gas efficiencies.

Implement a robust access control mechanism for any functions that modify token supply, ensuring that such power is either decentralized or protected by multi-signature governance. Additionally, evaluate the necessity of a pausability feature to enable emergency responses in unforeseen circumstances.

Contract & Record

1 audit on record
TypeGraphToken
NetworkEthereum
Token age5y
Contract0xc944…44a7
Deployer0x0659…16da
Badge for your website
Graph Token security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Aug 16, 202661Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
HarryPotterObamaSonic10InuBITCOIN · Ethereum61MediumLego PepeLEPE · Ethereum61MediumGnosis TokenGNO · Ethereum61MediumInterfoldFOLD · Ethereum61MediumTokenFiTOKEN · Ethereum61MediumANyONe ProtocolANYONE · Ethereum61Medium

Would You Like a More Detailed Audit of Graph Token?

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

Get Detailed Audit Is this your token? Publish your own audit on this page