Is o1.exchange (O) 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

1 audit on record

Jul 2325

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

Audit Summary

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.

Final Recommendation: Ensure all constructor parameters (name, symbol, totalSupply, recipient) are thoroughly verified before deployment, as they are immutable. Given the contract's simplicity and reliance on OpenZeppelin, the primary security considerations revolve around correct deployment and the security of the recipient address. Consider the implications of non-upgradeability for long-term project needs.

Category Ratings

TechnicalLow

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

GovernanceHigh

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

UpgradesMedium

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

LP Distribution

Top-1 Unlocked Holder99.9%

Top-3 Unlocked100.0%

What Raised This Score

6 factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 30% (96.3% total → 38.9% effective; 0.6% in EOAs, 95.7% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 99.9% (independent LP — depth risk, pool = 96% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 96% 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 Deployment Parameters

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

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

I-01InformationalUnresolved

Immutability of Contract Logic

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

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

I-02InformationalUnresolved

Fixed Supply and Initial Distribution

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

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

Is o1.exchange Safe? O