Is 01 Safe? Smart Contract Security Analysis

Security Findings

1 Med1 Low2 Info

Medium

Centralized Mint/Burn Control

M-01The `curve` address has exclusive control over minting new tokens up to `MAX_SUPPLY` and burning existing tokens. This grants significant power over the token's supply, making the security of the `curve` address paramount. While a common design for protocol-controlled tokens, a compromise of this address could lead to arbitrary token minting (up to cap) or burning, severely impacting token value and user trust.

IssueThe `curve` address has exclusive control over minting new tokens up to `MAX_SUPPLY` and burning existing tokens. This grants significant power over the token's supply, making the security of the `curve` address paramount. While a common design for protocol-controlled tokens, a compromise of this address could lead to arbitrary token minting (up to cap) or burning, severely impacting token value and user trust.

FixImplement robust security measures for the `curve` address, such as a multi-signature wallet, a time-locked contract, or a well-audited governance mechanism. Ensure that the operational security surrounding the `curve` address is of the highest standard to prevent unauthorized access or malicious actions.

StatusUnresolved

Low

Immutability of `curve` Address

L-01The `curve` address is set in the constructor and declared `immutable`. This design choice means the `curve` controller cannot be updated or replaced without deploying a new token contract. While preventing unauthorized changes, it introduces inflexibility and a single point of failure if the `curve` contract itself needs upgrades or if its private keys are compromised, requiring a full token migration.

IssueThe `curve` address is set in the constructor and declared `immutable`. This design choice means the `curve` controller cannot be updated or replaced without deploying a new token contract. While preventing unauthorized changes, it introduces inflexibility and a single point of failure if the `curve` contract itself needs upgrades or if its private keys are compromised, requiring a full token migration.

FixAcknowledge this design constraint. If future flexibility is desired for the `curve` controller, consider a design pattern where the controller address can be updated by a trusted entity (e.g., a governance contract or a multi-sig) through a controlled mechanism. For the current design, ensure the `curve` address is extremely stable and secure.

StatusUnresolved

Info

Dependency on OpenZeppelin Contracts

I-01The contract relies heavily on OpenZeppelin's ERC20 implementation (v5.5.0). While OpenZeppelin contracts are well-audited and a standard for secure development, any future vulnerabilities discovered in the specific version used could indirectly affect this contract.

IssueThe contract relies heavily on OpenZeppelin's ERC20 implementation (v5.5.0). While OpenZeppelin contracts are well-audited and a standard for secure development, any future vulnerabilities discovered in the specific version used could indirectly affect this contract.

FixRegularly monitor OpenZeppelin's security advisories and updates. While direct action on this contract may not be possible if it's not upgradeable, awareness is key for future deployments or if a token migration becomes necessary due to a critical vulnerability in the underlying library.

StatusUnresolved

Info

Lack of Emergency Pause Mechanism

I-02The contract does not include a mechanism to pause token transfers or minting/burning operations in an emergency. In scenarios like critical vulnerabilities in integrated protocols or market manipulation, the absence of a pause function limits the ability to react and mitigate potential damage.

IssueThe contract does not include a mechanism to pause token transfers or minting/burning operations in an emergency. In scenarios like critical vulnerabilities in integrated protocols or market manipulation, the absence of a pause function limits the ability to react and mitigate potential damage.

FixFor tokens intended for complex DeFi ecosystems, consider adding a pause mechanism (e.g., using OpenZeppelin's `Pausable` module) controlled by a trusted entity (e.g., governance or multi-sig). This provides a crucial failsafe for unforeseen circumstances.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture of Coin01 is straightforward, implementing a standard ERC20 token (7.1 Architecture). It utilizes OpenZeppelin's battle-tested ERC20 library, which significantly enhances code security and reduces the likelihood of common vulnerabilities like reentrancy or integer overflows (7.2 Code Security). Access control for minting and burning is strictly enforced via an `onlyCurve` modifier, ensuring only the designated `curve` address can perform these operations (7.3 Access Control). The contract's simplicity and reliance on audited components contribute to a low technical risk profile.

GovernanceMedium5/10

The economic model of Coin01 features a hard-capped maximum supply, preventing inflationary attacks beyond the defined limit (7.4 Economic). However, the `curve` address holds exclusive power to mint tokens up to this cap and burn tokens, representing a significant centralization of control over the token's supply dynamics (7.5 Governance). The security and governance of this `curve` address are paramount, as its compromise could lead to severe economic consequences for the token. There are no external dependencies that introduce oracle manipulation risks (7.6 External).

UpgradesHigh3/10

The Coin01 contract is not designed to be upgradeable (7.7 Upgrades). The `curve` address, which controls minting and burning, is set as `immutable` in the constructor. This design choice eliminates upgrade-related risks for the token contract itself but introduces inflexibility, as the `curve` controller cannot be changed without deploying an entirely new token. There are no specific operational risks identified beyond the general security of the `curve` address (7.8 Operations).

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Holder Composition

19.7% in top 10

5.7% in wallets14.0% in contracts

Effective Concentration11.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

$1.72M across 2 pairs

Uniswap v4ETHanalysed$1.72M Uniswap v4USDC$39

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 Holder24.3%

Top-3 Unlocked32.4%

Key Addresses

11 addresses

Deployer

0x9ef1…9c9e

Unlocked LP Held By

0xedcd…102d0x946e…c48e0xbb15…56670x7a52…459a0x29de…147f0x6bf8…ddc30x73e1…50bf0x8651…9a9c0x9bbb…006d0x6794…980f

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

What Raised This Score

5 factors

Ownership status UNKNOWN (owner could not be resolved)
Mintable supply — no cap found, dilution unbounded
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
1 Medium finding(s) from audit
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

Is 01 Safe?

Security Findings

Centralized Mint/Burn Control

Immutability of `curve` Address

Dependency on OpenZeppelin Contracts

Lack of Emergency Pause Mechanism

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of 01?