Is Graph Token (GRT) Safe? Smart Contract Security Analysis

Security Findings

1 High2 Low1 Info

High

Centralized Control over Token Supply (Potential)

H-01The `_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.

IssueThe `_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.

FixIf 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.

StatusUnresolved

Low

Older Solidity Compiler Version

L-01The 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.

IssueThe 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.

FixConsider 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.

StatusUnresolved

Low

Lack of Pausability Mechanism

L-02The 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.

IssueThe 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.

FixImplement 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.

StatusUnresolved

Info

ERC20 `approve` Race Condition

I-01The 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)`.

IssueThe 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)`.

FixEducate 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.

StatusUnresolved

Category Ratings

TechnicalLow7/10

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).

GovernanceHigh2/10

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).

UpgradesHigh3/10

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).

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Holder Composition

55.2% in top 10

19.9% in wallets35.3% in contracts

Effective Concentration34.0%

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

$186.0K across 10 pairs

Uniswap v2WETHanalysed$130.8K SushiswapWETH$20.7K Uniswap v3WETH$13.1K Uniswap v4ETH$11.7K Uniswap v3USDC$6.2K ShibaswapWETH$1.9K

Show 4 more pairsShow less

Uniswap v4ETH$1.3K BalancerUSDC$257 Uniswap v2USDC$92 BalancerWETH$4

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 Holder55.6%

Top-3 Unlocked76.6%

Key Addresses

11 addresses

Deployer

0x0659…16da

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.

What Raised This Score

7 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

Is Graph Token Safe?

Security Findings

Centralized Control over Token Supply (Potential)

Older Solidity Compiler Version

Lack of Pausability Mechanism

ERC20 `approve` Race Condition

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Graph Token?