Quantum Audit Logo

Is OpenGradient Safe?

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

OpenGradient OPG
0xfbc2…f5eb
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

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.

1 Low2 Informational
Volume 24h
$10.7K
Liquidity
$381.9K
Price
$0.1022
Token Age
2mo
Top 10 Holders
94.1%

Security Findings

1 Low2 Info
Low

Irreversible Burn Function

L-01The 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.
IssueThe 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.
FixEducate 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.
StatusUnresolved
Info

Immutability and Lack of Upgradeability

I-01The 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.
IssueThe 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.
FixAcknowledge 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.
StatusUnresolved
Info

Fixed Supply and Absence of Administrative Control

I-02The 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).
IssueThe 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).
FixEnsure 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.
StatusUnresolved

Category Ratings

TechnicalLow8/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 judiciously where safety is guaranteed, mitigating arithmetic risks. The custom `burn` function is a straightforward wrapper around `_burn`, maintaining security standards. No significant technical vulnerabilities were identified in the custom logic.

GovernanceHigh2/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 potential governance attacks. This design ensures predictable tokenomics and prevents arbitrary supply changes. The immutable nature and lack of administrative control mean no on-chain mechanisms exist for future tokenomics adjustments or emergency interventions, which could limit long-term adaptability.

UpgradesMedium6/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 lifetime. The immutability means that no bug fixes, feature enhancements, or adjustments can be made to the contract logic post-deployment, requiring a new deployment and migration if changes are ever needed.

Security Checklist

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

Holder Composition

94.1% in top 10
10.6% in wallets83.5% in contracts
Effective Concentration44.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

$401.7K across 3 pairs
PancakeswapVIRTUALanalysed$381.9K95.1%AerodromeUSDC$19.0K4.7%Uniswap v3USDC$8140.2%

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

Key Addresses

4 addresses
Deployer
0x4905…d2dc
Unlocked LP Held By
0xb68c…e8900x4a4c…9cc70x1bf0…d424

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% (94.1% total → 44.0% effective; 10.6% in EOAs, 83.5% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 56.2% (independent LP — depth risk, pool = 95% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 95% 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
ZoraMedium RisknoiceMedium RiskChainLink Token (LINK)Medium Riskthe sleeping giant (TSG)Medium RiskAave Token (AAVE)Medium RiskPlayMedium Risk

Would You Like a More Detailed Audit of OpenGradient?

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

Get Detailed Audit