Is Injective (INJ) Safe? Smart Contract Security Analysis

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedUnknown

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Audit History

2 audits on record

Jul 2326

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

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.

Final Recommendation: It is strongly recommended to provide the full source code for the `InjectiveToken` contract to enable a comprehensive security audit. This would allow for a thorough review of its specific logic, access control mechanisms, and economic parameters, which are critical for a complete risk assessment. For the existing ERC-20 implementation, users should be educated on the `approve` race condition and advised to use the 'set to zero then set new value' pattern for allowances to mitigate potential front-running risks.

Category Ratings

TechnicalLow

10/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

GovernanceHigh

2/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

UpgradesMedium

6/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 wou

LP Distribution

Top-1 Unlocked Holder75.1%

Top-3 Unlocked86.6%

What Raised This Score

6 factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 30% (96.1% total → 39.1% effective; 1.1% in EOAs, 95.0% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 75.1% (independent LP — depth risk, pool = 45% of DEX liquidity)
LP top3 unlocked holders = 86.6% (independent LP — depth risk, pool = 45% 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

Security Findings

3 total

1 Low 2 Info

L-01LowUnresolved

ERC-20 `approve` Race Condition

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

Recommendation: While 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.

I-01InformationalUnresolved

Use of Older Solidity Compiler Version

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

Recommendation: Consider 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.

I-02InformationalUnresolved

Incomplete Contract Code Provided for Audit

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

Recommendation: For 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.

Is Injective Safe? INJ