Quantum Audit Logo

Is o1.exchange Safe?

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

o1.exchange O
0x182f…20b2
Base
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.
Last checked 18d ago 1 audit on record
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The audited contract is a straightforward ERC-20 token implementation, inheriting from OpenZeppelin's battle-tested ERC20 library. The contract's simplicity and reliance on well-vetted external components contribute to a low overall risk profile. The token's supply is fixed and minted entirely during deployment, with no further minting or burning capabilities. The contract is not upgradeable, providing immutability but limiting future flexibility.

1 Low2 Informational
Volume 24h
$1.99M
Liquidity
$1.97M
Price
$0.5608
Token Age
1y
Top 10 Holders
95.6%

Security Findings

Low

Irreversible Deployment Parameters

L-01The `Token` contract's constructor sets critical parameters such as `name_`, `symbol_`, `totalSupply_`, and `recipient_` immutably upon deployment. Any errors in these parameters, such as an incorrect total supply or a wrong recipient address, cannot be corrected after the contract is deployed. This falls under 7.8 Operations risk.
IssueThe `Token` contract's constructor sets critical parameters such as `name_`, `symbol_`, `totalSupply_`, and `recipient_` immutably upon deployment. Any errors in these parameters, such as an incorrect total supply or a wrong recipient address, cannot be corrected after the contract is deployed. This falls under 7.8 Operations risk.
FixImplement a rigorous deployment checklist and perform multiple verifications of all constructor arguments before deploying the contract to a production environment. Consider deploying to a testnet first to confirm all parameters are as expected.
StatusUnresolved
Info

Immutability of Contract Logic

I-01The `Token` contract is not designed with any upgradeability mechanism (7.7 Upgrades). This means that once deployed, its code cannot be modified or updated. While this provides strong guarantees of immutability and reduces upgrade-related risks, it also means that any discovered vulnerabilities or desired feature enhancements cannot be implemented without deploying a new contract and migrating assets.
IssueThe `Token` contract is not designed with any upgradeability mechanism (7.7 Upgrades). This means that once deployed, its code cannot be modified or updated. While this provides strong guarantees of immutability and reduces upgrade-related risks, it also means that any discovered vulnerabilities or desired feature enhancements cannot be implemented without deploying a new contract and migrating assets.
FixAcknowledge the trade-off between immutability and flexibility. For a simple token, this design is often acceptable. If future changes or bug fixes are anticipated, a proxy pattern (e.g., UUPS) would be necessary, but would also introduce additional complexity and upgrade-specific risks.
StatusUnresolved
Info

Fixed Supply and Initial Distribution

I-02The contract implements a fixed supply model where the entire `totalSupply_` is minted to a single `recipient_` during the constructor call (7.4 Economic). There are no functions for further minting, burning (beyond standard ERC20 transfers to `address(0)`), or adjusting the supply post-deployment. This design ensures a predictable token economy.
IssueThe contract implements a fixed supply model where the entire `totalSupply_` is minted to a single `recipient_` during the constructor call (7.4 Economic). There are no functions for further minting, burning (beyond standard ERC20 transfers to `address(0)`), or adjusting the supply post-deployment. This design ensures a predictable token economy.
FixEnsure the chosen fixed supply and initial distribution model aligns with the project's long-term economic strategy. Communicate this fixed supply nature clearly to token holders and the community to manage expectations regarding tokenomics.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1 Architecture) is minimal, consisting of a single ERC-20 token contract inheriting from OpenZeppelin's robust `ERC20` implementation. Code security (7.2 Code Security) is high due to the use of Solidity 0.8.28, which includes built-in overflow/underflow protection, and the reliance on OpenZeppelin's audited codebase. Access control (7.3 Access Control) is limited to the constructor, where the initial supply is minted to a specified recipient, with no further administrative functions post-deployment.

GovernanceHigh2/10

The economic model (7.4 Economic) is straightforward: a fixed total supply is minted once at deployment to a single recipient, with no mechanisms for inflation, deflation, or fees. This design offers predictability and reduces economic complexity. There are no governance mechanisms (7.5 Governance) implemented within this contract, as it functions purely as a standard token.

UpgradesMedium6/10

The contract is not designed to be upgradeable (7.7 Upgrades). This means its logic is immutable once deployed, providing certainty but removing any flexibility for future modifications or bug fixes. This design choice eliminates upgrade-specific risks, such as proxy misconfigurations or implementation vulnerabilities during an upgrade.

Security Checklist

Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

0.0% in wallets95.6% in contracts
Effective Concentration38.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

Show 4 more pairsShow less

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 Holder91.7%
Top-3 Unlocked99.8%

Key Addresses

Deployer
0x719b…9108
Unlocked LP Held By
0x73e3…93d50x1690…1c150xe6b0…45890xcbbb…58350xaca1…fdf7

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

What Raised This Score

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

BankrCoin (BNKR)Medium RiskSurplus Intelligence (SURPLUS)Medium RiskRAWRMedium RiskArcadia (AAA)Medium RiskCLAWNCHMedium RiskKittehCoin (MEOW)Medium Risk

Would You Like a More Detailed Audit of o1.exchange?

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

Get Detailed Audit