Quantum Audit Logo
Launch App

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

Is Gains Network Safe?

GNSArbitrum
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/10Governance1/10Upgrades3/10Checks passed4 of 7Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The GainsNetworkToken contract is an ERC20Capped token utilizing OpenZeppelin's AccessControlEnumerable for role-based permissions.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply, nominal cap 499%/year — effectively 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 = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply, nominal cap 499%/year — effectively unbounded
  • Top-10 concentration > 30% (60.2% total → 35.3% effective; 18.7% in EOAs, 41.5% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 68% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 68% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 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 44 of 7 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
41.5%Contracts18.7%Wallets39.8%Everyone else
41.5%Contracts18.7%Wallets39.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
60.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking41.5%
  • Walletsanonymous holders, free to sell18.7%
  • Everyone elsethe rest of the supply39.8%
Effective concentrationwhat the score reads35.3%
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$372.9K across 8 pairs
Show 2 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$252.3KShare of depth67.7%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x8f7b…fa76

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

Security Findings

1 High1 Medium1 Low1 Info
High

Centralized Control Over Token Supply

The DEFAULT_ADMIN_ROLE has the power to grant and revoke MINTER_ROLE and BURNER_ROLE. Additionally, multiple external addresses are assigned MINTER_ROLE in the setupRoles function. A compromise of the DEFAULT_ADMIN_ROLE or any address holding MINTER_ROLE could lead to unauthorized token minting up to the cap (100,000,000 GNS), significantly devaluing existing tokens and impacting the protocol's economic stability. This represents a critical risk to the token's integrity and value (7.3 Access Control, 7.4 Economic).H-01

Issue

The DEFAULT_ADMIN_ROLE has the power to grant and revoke MINTER_ROLE and BURNER_ROLE. Additionally, multiple external addresses are assigned MINTER_ROLE in the setupRoles function. A compromise of the DEFAULT_ADMIN_ROLE or any address holding MINTER_ROLE could lead to unauthorized token minting up to the cap (100,000,000 GNS), significantly devaluing existing tokens and impacting the protocol's economic stability. This represents a critical risk to the token's integrity and value (7.3 Access Control, 7.4 Economic).

Fix

Implement a multi-signature wallet for the DEFAULT_ADMIN_ROLE to require multiple approvals for critical actions like granting/revoking roles. Carefully evaluate the necessity of each address holding MINTER_ROLE and consider reducing the number of such privileged entities. Implement robust security measures for all addresses with minting or burning capabilities.

Status

Unresolved

Medium

Single Point of Failure for Default Admin Role

The DEFAULT_ADMIN_ROLE is initially assigned to a single admin address in the constructor. This creates a single point of failure (7.8 Operations). If this admin address's private key is compromised, an attacker would gain full control over all roles within the contract, including the ability to assign themselves MINTER_ROLE or BURNER_ROLE, leading to potential token manipulation (7.3 Access Control).M-01

Issue

The DEFAULT_ADMIN_ROLE is initially assigned to a single admin address in the constructor. This creates a single point of failure (7.8 Operations). If this admin address's private key is compromised, an attacker would gain full control over all roles within the contract, including the ability to assign themselves MINTER_ROLE or BURNER_ROLE, leading to potential token manipulation (7.3 Access Control).

Fix

Transition the DEFAULT_ADMIN_ROLE to a multi-signature wallet or a robust governance contract as soon as possible after deployment. This distributes control and significantly reduces the risk associated with a single compromised key.

Status

Unresolved

Low

Critical Initialization Function setupRoles

The setupRoles function is a critical, one-time initialization function that assigns MINTER_ROLE and BURNER_ROLE to several external addresses. While protected by an initialized flag and onlyRole(DEFAULT_ADMIN_ROLE), any error in the initial setup (e.g., incorrect addresses) or a compromise of the DEFAULT_ADMIN_ROLE before this call could lead to incorrect or malicious role assignments that are difficult to rectify (7.3 Access Control, 7.8 Operations).L-01

Issue

The setupRoles function is a critical, one-time initialization function that assigns MINTER_ROLE and BURNER_ROLE to several external addresses. While protected by an initialized flag and onlyRole(DEFAULT_ADMIN_ROLE), any error in the initial setup (e.g., incorrect addresses) or a compromise of the DEFAULT_ADMIN_ROLE before this call could lead to incorrect or malicious role assignments that are difficult to rectify (7.3 Access Control, 7.8 Operations).

Fix

Ensure thorough testing and verification of all addresses passed to setupRoles before deployment. Consider a timelock for the DEFAULT_ADMIN_ROLE to introduce a delay for critical operations, allowing time to react to potential errors or malicious actions during initialization.

Status

Unresolved

Info

Use of AccessControlEnumerable

The contract inherits AccessControlEnumerable, which provides functionality to enumerate role members (e.g., getRoleMember, getRoleMemberCount). If the protocol does not actively utilize these enumeration features, inheriting directly from AccessControl would be sufficient. AccessControlEnumerable adds a slight increase in contract size and gas costs due to the additional storage and logic for EnumerableSet (7.2 Code Security).I-01

Issue

The contract inherits AccessControlEnumerable, which provides functionality to enumerate role members (e.g., getRoleMember, getRoleMemberCount). If the protocol does not actively utilize these enumeration features, inheriting directly from AccessControl would be sufficient. AccessControlEnumerable adds a slight increase in contract size and gas costs due to the additional storage and logic for EnumerableSet (7.2 Code Security).

Fix

Review if the enumeration features of AccessControlEnumerable are strictly necessary for the protocol's operations. If not, consider using AccessControl to slightly optimize contract size and gas usage. This is a minor optimization and does not pose a security risk.

Status

Unresolved

Analysis

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

The GainsNetworkToken contract is an ERC20Capped token utilizing OpenZeppelin's AccessControlEnumerable for role-based permissions. The contract implements minting and burning functionalities controlled by specific roles. The primary risks identified relate to the centralized control over token supply via the DEFAULT_ADMIN_ROLE and the multiple MINTER_ROLE addresses, which could lead to significant economic impact if compromised. The contract is not upgradeable, simplifying its security profile in that regard.

Technical7/10Low risk

The contract exhibits strong technical security (7.2 Code Security). It leverages well-audited OpenZeppelin libraries for ERC20Capped and AccessControlEnumerable, minimizing common vulnerabilities like reentrancy or integer overflows. The setupRoles function includes an initialized flag and address(0) checks, preventing re-initialization and invalid address assignments. The architecture (7.1 Architecture) is straightforward for a token contract, with clear separation of concerns.

Governance1/10High risk

The economic model (7.4 Economic) and governance structure (7.5 Governance) present the highest risks. The DEFAULT_ADMIN_ROLE holds significant power, able to grant and revoke all other roles, including MINTER_ROLE and BURNER_ROLE. Multiple external addresses are assigned MINTER_ROLE, increasing the attack surface. A compromise of the DEFAULT_ADMIN_ROLE or any MINTER_ROLE address could lead to unauthorized token minting up to the cap, directly impacting token value and stability.

Upgrades3/10High risk

The GainsNetworkToken contract is not designed as an upgradeable proxy (7.7 Upgrades). It is a standard implementation contract, meaning its logic cannot be changed post-deployment. This eliminates risks associated with upgradeability patterns, such as proxy storage collisions or incorrect upgrade paths.

Final RecommendationWhat to do about this score

To mitigate the identified risks, it is strongly recommended to secure the DEFAULT_ADMIN_ROLE with a robust multi-signature wallet or a decentralized autonomous organization (DAO) governance mechanism.

Implement strict operational security procedures for all addresses holding MINTER_ROLE and BURNER_ROLE, ensuring they are not single points of failure. Regularly review and audit the security posture of all privileged addresses and associated infrastructure.

Contract & Record

1 audit on record
TypeGainsNetworkToken
NetworkArbitrum
Token age1y
Contract0x18c1…a122
Deployer0xec95…a8ac
Badge for your website
Gains Network 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 1, 202660Medium

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

Related Audits

6 more on the recordAll audits
NolaArbitrum60MediumWINRArbitrum60MediumNOXCATNOX · Arbitrum58MediumMAGICArbitrum58Mediumether.fi governance tokenETHFI · Arbitrum58MediumUniswapUNI · Arbitrum62Medium

Would You Like a More Detailed Audit of Gains Network?

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