Quantum Audit Logo
Launch App

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

Is Gnosis Token Safe?

GNOEthereum
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
Technical8/10Governance1/10Upgrades6/10Checks passed3 of 5Findings2 High · 2 Medium · 2 Info6
SummaryAI Copilot

The GnosisToken contract, an ERC-20 compliant token, was audited for security vulnerabilities.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Top-10 concentration > 50%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 55.6%
  • LP top3 unlocked holders = 98.6%
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 50% (96.0% total → 57.9% effective; 32.6% in EOAs, 63.4% in contracts — heavy)
  • 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 = 84% of DEX liquidity)
  • LP top3 unlocked holders = 98.6% (independent LP — depth risk, pool = 84% of DEX liquidity)
  • 2 High finding(s) from audit
  • 2 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

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
63.4%Contracts32.6%Wallets4.0%
63.4%Contracts32.6%Wallets4.0%
ContractsWalletsEveryone elseBubble area = share of supply
96.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking63.4%
  • Walletsanonymous holders, free to sell32.6%
  • Everyone elsethe rest of the supply4.0%
Effective concentrationwhat the score reads57.9%
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$111.8K across 6 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$93.7KShare of depth83.8%
Top-1 Unlocked Holder55.6%
Top-3 Unlocked98.6%
Unlocked LP held by
0x2b23…e60d0xee31…a3ed0x75c6…1cfb0x9823…d98e0xd2da…418d0x40d3…ef600x25f8…91ba

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

Security Findings

2 High2 Medium2 Info
High

Deprecated throw Keyword for Error Handling

The contract uses the throw keyword for error handling, which is deprecated since Solidity 0.4.22. throw consumes all remaining gas, making it less gas-efficient than revert() or require(), which were introduced later and allow for more precise error messages and gas refunds. This can lead to higher transaction costs for failed operations.H-01

Issue

The contract uses the throw keyword for error handling, which is deprecated since Solidity 0.4.22. throw consumes all remaining gas, making it less gas-efficient than revert() or require(), which were introduced later and allow for more precise error messages and gas refunds. This can lead to higher transaction costs for failed operations.

Fix

Update the contract to use require() or revert() statements for error handling. This improves gas efficiency and allows for clearer error messages, aligning with modern Solidity best practices.

Status

Unresolved

High

ERC-20 approve Race Condition Vulnerability

The approve function is susceptible to a known ERC-20 race condition. If a user calls approve(spender, newAmount) while the spender is simultaneously trying to spend the oldAmount, the spender might be able to spend both oldAmount and newAmount, effectively doubling the allowance. This can lead to unintended token transfers.H-02

Issue

The approve function is susceptible to a known ERC-20 race condition. If a user calls approve(spender, newAmount) while the spender is simultaneously trying to spend the oldAmount, the spender might be able to spend both oldAmount and newAmount, effectively doubling the allowance. This can lead to unintended token transfers.

Fix

Implement the increaseAllowance and decreaseAllowance pattern, as recommended by OpenZeppelin, to safely modify allowances. This pattern prevents the race condition by requiring explicit increments or decrements, ensuring atomic updates.

Status

Unresolved

Medium

Outdated Solidity Compiler Version

The contract is compiled with Solidity version 0.4.10. This version is significantly outdated and lacks numerous security features, bug fixes, and optimizations introduced in later versions (e.g., 0.5.x, 0.6.x, 0.8.x). Using an old compiler increases the risk of undiscovered compiler bugs or missing modern security patterns.M-01

Issue

The contract is compiled with Solidity version 0.4.10. This version is significantly outdated and lacks numerous security features, bug fixes, and optimizations introduced in later versions (e.g., 0.5.x, 0.6.x, 0.8.x). Using an old compiler increases the risk of undiscovered compiler bugs or missing modern security patterns.

Fix

Upgrade the contract to a recent and stable Solidity compiler version (e.g., 0.8.x). This would allow leveraging modern language features, improved security checks (like built-in overflow/underflow checks for uint types), and better gas optimization.

Status

Unresolved

Medium

Potential Integer Overflow on Addition

The contract performs addition operations (e.g., balances[_to] += _value in transfer and transferFrom, assignedTokens += tokens[i] in the constructor) without explicit overflow checks. While uint256 provides a large range, a malicious or accidental input exceeding type(uint256).max could lead to an overflow, resulting in incorrect balance calculations.M-02

Issue

The contract performs addition operations (e.g., balances[_to] += _value in transfer and transferFrom, assignedTokens += tokens[i] in the constructor) without explicit overflow checks. While uint256 provides a large range, a malicious or accidental input exceeding type(uint256).max could lead to an overflow, resulting in incorrect balance calculations.

Fix

Implement SafeMath or similar libraries for all arithmetic operations to prevent integer overflows. Modern Solidity versions (0.8.0+) include built-in overflow/underflow checks for uint types, which would mitigate this risk if the compiler is updated.

Status

Unresolved

Info

Constructor Gas Limit Risk for Large Arrays

The GnosisToken constructor iterates through owners and tokens arrays to assign initial balances. If these arrays are excessively large, the constructor's gas consumption could exceed the block gas limit, preventing the contract from being deployed successfully.I-01

Issue

The GnosisToken constructor iterates through owners and tokens arrays to assign initial balances. If these arrays are excessively large, the constructor's gas consumption could exceed the block gas limit, preventing the contract from being deployed successfully.

Fix

For very large initial distributions, consider an alternative mechanism such as a separate function for claiming tokens or a batched distribution function that can be called multiple times post-deployment to avoid hitting block gas limits.

Status

Unresolved

Info

totalSupply() Signature Mismatch in Interface

The Token interface declares totalSupply() constant returns (uint256 supply) {} with an empty body and constant keyword. While StandardToken correctly implements totalSupply as a public state variable, the interface definition is slightly inconsistent with modern ERC-20 interfaces which typically declare function totalSupply() external view returns (uint256);. The constant keyword for functions was deprecated in 0.5.0.I-02

Issue

The Token interface declares totalSupply() constant returns (uint256 supply) {} with an empty body and constant keyword. While StandardToken correctly implements totalSupply as a public state variable, the interface definition is slightly inconsistent with modern ERC-20 interfaces which typically declare function totalSupply() external view returns (uint256);. The constant keyword for functions was deprecated in 0.5.0.

Fix

While not a functional bug in StandardToken, for future compatibility and clarity, the Token interface could be updated to reflect modern ERC-20 standards, using view instead of constant and removing the empty function body.

Status

Unresolved

Analysis

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

The GnosisToken contract, an ERC-20 compliant token, was audited for security vulnerabilities. The contract exhibits several issues related to its use of an older Solidity compiler version (0.4.10), including the throw keyword for error handling and susceptibility to the ERC-20 approve race condition. While core token functionalities are present, adherence to modern security practices is lacking, contributing to a Medium overall risk level.

Technical8/10Low risk

The GnosisToken contract implements a standard ERC-20 token with a fixed supply and initial distribution logic (7.1 Architecture). The core transfer and transferFrom functions include checks to prevent underflow, demonstrating basic security considerations (7.2 Code Security). However, the contract uses Solidity 0.4.10, which lacks modern security features like revert() and require(), instead relying on throw for error handling, which is less gas-efficient. Furthermore, the approve function is vulnerable to the known ERC-20 race condition (7.3 Access Control).

Governance1/10High risk

The token's economic model is straightforward, with a fixed total supply and initial distribution defined in the constructor (7.4 Economic). There are no complex governance mechanisms or external dependencies that introduce economic risk (7.5 Governance). The initial distribution logic includes checks to ensure the total supply is correctly assigned, mitigating some deployment risks.

Upgrades6/10Medium risk

The contract is not designed with an upgrade mechanism, meaning its logic is immutable once deployed (7.7 Upgrades). This eliminates upgrade-related risks but also prevents future bug fixes or feature enhancements without a full redeployment and migration.

Final RecommendationWhat to do about this score

It is strongly recommended to migrate to a newer Solidity compiler version (0.8.x) and adopt modern best practices, including the use of require()/revert() for error handling and SafeMath for all arithmetic operations to prevent potential overflows.

Implement a robust solution for the ERC-20 approve race condition, such as the increaseAllowance/decreaseAllowance pattern, to enhance security and user experience.

Contract & Record

1 audit on record
TypeGnosisToken
NetworkEthereum
Token age5y
Contract0x6810…6b96
Deployer0xbe4e…f901
Badge for your website
Gnosis 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. Sep 4, 202661Medium
  2. Aug 16, 202655Medium

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

Frequently Asked Questions

What is the GNO contract address?

The Gnosis Token (GNO) contract on Ethereum is 0x6810e776880c02933d47db1b9fc05908e5386b96. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Gnosis Token a scam?

Quantum Audit's risk score for Gnosis Token is 61/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is GNO liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $111.8K.

Who holds GNO?

As of Sep 4, 2026, the 10 largest holders own 96.0% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
HarryPotterObamaSonic10InuBITCOIN · Ethereum61MediumLego PepeLEPE · Ethereum61MediumGraph TokenGRT · Ethereum61MediumInterfoldFOLD · Ethereum61MediumTokenFiTOKEN · Ethereum61MediumANyONe ProtocolANYONE · Ethereum61Medium

Would You Like a More Detailed Audit of Gnosis 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