Is Gnosis Token (GNO) Safe? Smart Contract Security Analysis

Security Findings

2 High2 Med2 Info

High

Deprecated `throw` Keyword for Error Handling

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

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

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

StatusUnresolved

High

ERC-20 `approve` Race Condition Vulnerability

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

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

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

StatusUnresolved

Medium

Outdated Solidity Compiler Version

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

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

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

StatusUnresolved

Medium

Potential Integer Overflow on Addition

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

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

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

StatusUnresolved

Info

Constructor Gas Limit Risk for Large Arrays

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

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

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

StatusUnresolved

Info

`totalSupply()` Signature Mismatch in Interface

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

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

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

StatusUnresolved

Category Ratings

TechnicalLow8/10

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

GovernanceHigh1/10

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.

UpgradesMedium6/10

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.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

96.0% in top 10

32.6% in wallets63.4% in contracts

Effective Concentration57.9%

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

$111.8K across 6 pairs

Uniswap v3WETHanalysed$93.7K Uniswap v3USDT$11.9K Uniswap v2WETH$3.5K BalancerWETH$1.6K Uniswap v4ETH$1.2K

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

Key Addresses

8 addresses

Deployer

0xbe4e…f901

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.

What Raised This Score

7 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

Is Gnosis Token Safe?

Security Findings

Deprecated `throw` Keyword for Error Handling

ERC-20 `approve` Race Condition Vulnerability

Outdated Solidity Compiler Version

Potential Integer Overflow on Addition

Constructor Gas Limit Risk for Large Arrays

`totalSupply()` Signature Mismatch in Interface

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 Gnosis Token?