Quantum Audit Logo

Is Gains Network Safe?

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

Gains Network GNS
0x18c1…a122
Arbitrum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 High1 Medium1 Low1 Informational
Volume 24h
$6.5K
Liquidity
$252.3K
Price
$0.5257
Token Age
1y
Top 10 Holders
60.2%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Control Over Token Supply

H-01The `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).
IssueThe `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).
FixImplement 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.
StatusUnresolved
Medium

Single Point of Failure for Default Admin Role

M-01The `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).
IssueThe `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).
FixTransition 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.
StatusUnresolved
Low

Critical Initialization Function `setupRoles`

L-01The `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).
IssueThe `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).
FixEnsure 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.
StatusUnresolved
Info

Use of AccessControlEnumerable

I-01The 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).
IssueThe 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).
FixReview 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.
StatusUnresolved

Category Ratings

TechnicalLow7/10

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.

GovernanceHigh1/10

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.

UpgradesHigh3/10

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.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

60.2% in top 10
18.7% in wallets41.5% in contracts
Effective Concentration35.3%

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

$372.9K across 8 pairs
Camelot v3WETHanalysed$252.3K67.7%UniswapUSD₮0$52.1K14.0%UniswapWETH$49.3K13.2%Camelot v3USDC$9.3K2.5%UniswapDAI$6.4K1.7%Camelot v3DAI$1.8K0.5%
Show 2 more pairsShow less
TraderjoeWETH$1.4K0.4%UniswapUSDC$3620.1%

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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0xec95…a8ac
Unlocked LP Held By
0x8f7b…fa76

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

What Raised This Score

9 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

Related Audits

6 more on the record
NolaHigh RiskWINRHigh RiskNOXCAT (NOX)High RiskMAGICHigh RiskWrapped BTC (WBTC)High RiskEspresso (ESP)High Risk

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