Is OpenGradient (OPG) 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 2336

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

Audit Summary

The OpenGradientToken contract is a standard ERC20 token with a fixed supply, built upon battle-tested OpenZeppelin libraries. It explicitly lacks administrative functions and is immutable, ensuring a high degree of decentralization and predictability. The custom `burn` function is correctly implemented. The audit identified no critical or high-severity vulnerabilities. Informational findings relate to the inherent trade-offs of its immutable and decentralized design.

Final Recommendation: The OpenGradientToken contract is robust and secure due to its simplicity and reliance on OpenZeppelin's audited libraries. Users should be aware of the token's immutable nature and the absence of administrative control, which means no future changes or emergency interventions are possible. Projects integrating with this token should account for its fixed supply and decentralized design in their long-term planning.

Category Ratings

TechnicalLow

8/10

The contract leverages battle-tested OpenZeppelin ERC20 and ERC20Permit implementations, ensuring robust and standard token functionality (7.2 Code Security). Solidity 0.8.26 provides default overflow/underflow checks, and OpenZeppelin's internal `_update` function uses `unchecked` blocks judic

GovernanceHigh

2/10

The contract is designed for complete decentralization, with a fixed total supply of 1 billion tokens minted at deployment (7.4 Economic, 7.5 Governance). There are no administrative functions, owner privileges, or upgradeability, which eliminates risks associated with centralized control and potent

UpgradesMedium

6/10

The OpenGradientToken contract is explicitly designed as an immutable, non-upgradeable token, eliminating all risks associated with proxy patterns, upgradeability bugs, or malicious upgrade paths (7.7 Upgrades). This provides certainty regarding the contract's code and behavior over its lifetim

LP Distribution

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

What Raised This Score

6 factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 30% (92.9% total → 42.8% effective; 9.5% in EOAs, 83.4% 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 = 91% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 91% 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

Irreversible Burn Function

The contract includes a `burn` function that allows any token holder to permanently destroy their own tokens. While this function is correctly implemented using OpenZeppelin's `_burn` and adheres to ERC20 standards, the action is irreversible. If a user accidentally burns tokens, there is no mechanism to recover them.

Recommendation: Educate users about the irreversible nature of the `burn` function. Implement clear UI/UX warnings in any front-end interfaces that interact with this function to prevent accidental token loss. Consider adding a multi-step confirmation process for burning tokens.

I-01InformationalUnresolved

Immutability and Lack of Upgradeability

The OpenGradientToken contract is designed to be immutable and non-upgradeable. This design choice eliminates risks associated with proxy patterns and malicious upgrades, providing certainty about the contract's behavior over time (7.7 Upgrades). However, it also means that no bug fixes, feature enhancements, or adjustments can be made to the contract logic post-deployment. Any future changes would require deploying a new token contract and migrating users.

Recommendation: Acknowledge this design choice and its implications. Ensure all initial requirements are thoroughly met, as no on-chain modifications are possible. Communicate clearly to the community that the token contract is immutable.

I-02InformationalUnresolved

Fixed Supply and Absence of Administrative Control

The contract is designed with a fixed total supply of 1 billion tokens, all minted to a recipient during deployment, and explicitly states 'No centralized admin functions - completely decentralized' (7.4 Economic, 7.5 Governance). This design choice ensures decentralization and prevents arbitrary supply manipulation or centralized control. However, it also means there are no on-chain mechanisms for future tokenomics adjustments (e.g., adding staking rewards, adjusting supply for ecosystem growth) or emergency actions (e.g., pausing transfers in case of a critical vulnerability in an integrated protocol).

Recommendation: Ensure that the project's long-term vision and tokenomics are fully compatible with a fixed supply and lack of administrative control. If future flexibility is desired, consider off-chain governance mechanisms or separate contracts for ecosystem incentives that interact with this token.

Is OpenGradient Safe? OPG