Quantum Audit Logo

Is Injective Safe?

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

Is this your token? Publish your own audit on this page →

Injective INJ
0xe28b…ca30
Ethereum
Not verifiedThis 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 18d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

This audit report covers the provided Solidity source code, which includes standard OpenZeppelin libraries and interfaces for an ERC-20 token. A comprehensive security assessment of the core InjectiveToken contract was not possible as its implementation details were not included in the provided text. The analysis focuses on the security of the available components and general ERC-20 considerations.

1 Low2 Informational
Volume 24h
$38.9K
Liquidity
$396.9K
Price
$4.9800
Token Age
2mo
Top 10 Holders
96.3%

Security Findings

1 Low2 Info
Low

ERC-20 `approve` Race Condition

L-01The ERC-20 standard's `approve` function is susceptible to a known race condition. If a user approves an amount for a spender, and then attempts to change that allowance to a different value, a malicious actor could front-run the second transaction. This allows the attacker to spend the original allowance, and then also spend the new allowance after the second transaction confirms, effectively spending more than the intended total. This is explicitly mentioned in the `IERC20` interface comments.
IssueThe ERC-20 standard's `approve` function is susceptible to a known race condition. If a user approves an amount for a spender, and then attempts to change that allowance to a different value, a malicious actor could front-run the second transaction. This allows the attacker to spend the original allowance, and then also spend the new allowance after the second transaction confirms, effectively spending more than the intended total. This is explicitly mentioned in the `IERC20` interface comments.
FixWhile this is an inherent design characteristic of the ERC-20 standard, users should be advised to mitigate this risk by first setting the allowance to zero with one transaction, and then setting the desired new allowance in a subsequent transaction. Alternatively, consider using `increaseAllowance` and `decreaseAllowance` functions if available in the full token contract, as these functions are designed to prevent this specific race condition.
StatusUnresolved
Info

Use of Older Solidity Compiler Version

I-01The contract is compiled with Solidity version 0.6.12. While `SafeMath` is used to prevent arithmetic overflows and underflows, newer Solidity versions (e.g., 0.8.0 and above) include native overflow/underflow checks by default, which can simplify code and potentially reduce gas costs by removing explicit `SafeMath` calls. Using an older compiler version might also mean missing out on newer language features, optimizations, and security improvements.
IssueThe contract is compiled with Solidity version 0.6.12. While `SafeMath` is used to prevent arithmetic overflows and underflows, newer Solidity versions (e.g., 0.8.0 and above) include native overflow/underflow checks by default, which can simplify code and potentially reduce gas costs by removing explicit `SafeMath` calls. Using an older compiler version might also mean missing out on newer language features, optimizations, and security improvements.
FixConsider upgrading to a more recent Solidity compiler version (e.g., 0.8.x) for future deployments or major upgrades. This would allow for native overflow checks and access to the latest language features and optimizations. Ensure thorough testing if upgrading, as syntax and behavior changes may require adjustments.
StatusUnresolved
Info

Incomplete Contract Code Provided for Audit

I-02The provided source code only includes standard OpenZeppelin libraries (`Context`, `SafeMath`, `Address`) and the `IERC20` interface. The core implementation of the `InjectiveToken` contract, which would inherit from these components and define its specific logic (e.g., constructor, minting/burning functions, custom modifiers, state variables), was not included. This significantly limits the scope of the audit, preventing a full assessment of the token's security posture, access control, and economic model.
IssueThe provided source code only includes standard OpenZeppelin libraries (`Context`, `SafeMath`, `Address`) and the `IERC20` interface. The core implementation of the `InjectiveToken` contract, which would inherit from these components and define its specific logic (e.g., constructor, minting/burning functions, custom modifiers, state variables), was not included. This significantly limits the scope of the audit, preventing a full assessment of the token's security posture, access control, and economic model.
FixFor a comprehensive and accurate security assessment, the complete and unabridged source code for the `InjectiveToken` contract must be provided. This includes all inherited contracts and any custom logic specific to the token.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The provided code utilizes battle-tested OpenZeppelin libraries such as `Context`, `IERC20`, `SafeMath`, and `Address`, which are known for their robust and secure implementations (7.1 Architecture, 7.2 Code Security). The inclusion of `SafeMath` effectively mitigates integer overflow and underflow vulnerabilities, a common risk in Solidity 0.6.x. A known issue with the ERC-20 `approve` function is a potential race condition (7.2 Code Security), which is an inherent design characteristic of the standard rather than an implementation flaw in these libraries. The use of Solidity 0.6.12 is an older version, though `SafeMath` addresses its primary arithmetic safety concerns.

GovernanceHigh2/10

No specific governance mechanisms or complex economic models are visible within the provided library code. Therefore, a full assessment of economic and governance risks (7.4 Economic, 7.5 Governance) is not possible without the complete `InjectiveToken` contract implementation. Potential risks such as centralized minting/burning capabilities, privileged roles, or tokenomics design cannot be evaluated. Without this information, the overall economic and governance risk remains undetermined.

UpgradesMedium6/10

The contract is not designed as an upgradeable proxy (7.7 Upgrades), simplifying its architecture and eliminating risks associated with proxy patterns like storage collisions or improper initialization. As a non-upgradeable contract, any discovered vulnerabilities or desired feature enhancements would necessitate a new deployment and a potentially complex token migration process. This design choice prioritizes immutability over flexibility.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

96.3% in top 10
0.9% in wallets95.4% in contracts
Effective Concentration39.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

$627.6K across 6 pairs
Uniswap v4USDCanalysed$396.9K63.2%Uniswap v4ETH$147.5K23.5%Uniswap v3WETH$58.0K9.2%Uniswap v2WETH$11.8K1.9%SushiswapWETH$7.6K1.2%Uniswap v3RNDR$5.7K0.9%

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 Holder82.2%
Top-3 Unlocked89.8%

Key Addresses

11 addresses
Deployer
0x03e3…b4ad
Unlocked LP Held By
0xb57f…37a10xc871…67aa0x49e7…b0cb0x1866…59db0x4a10…ed7b0xfc8a…ea450xebf5…7cda0xa9ee…f50a0xc1c7…96250x20ee…cbf7

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

What Raised This Score

6 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 30% (96.3% total → 39.0% effective; 0.9% in EOAs, 95.4% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 82.2% (independent LP — depth risk, pool = 63% of DEX liquidity)
  • LP top3 unlocked holders = 89.8% (independent LP — depth risk, pool = 63% of DEX liquidity)
  • 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
Lighter (LIT)Medium RiskAaveMedium RiskPepeMedium RiskShiro Neko (SHIRO)Medium RiskBeefy (BIFI)Medium RiskADIMedium Risk

Would You Like a More Detailed Audit of Injective?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit