Is UNICURVE Safe? Smart Contract Security Analysis

Security Findings

2 High1 Med1 Low2 Info

High

Centralized Control by `curve` Address

H-01The `curve` address, set during initialization, is the sole recipient of the entire token supply (1 billion tokens) and the only entity capable of calling `enableTransfers()`. This grants the `curve` address complete control over token distribution and transferability, representing a single point of failure (7.3 Access Control, 7.5 Governance).

IssueThe `curve` address, set during initialization, is the sole recipient of the entire token supply (1 billion tokens) and the only entity capable of calling `enableTransfers()`. This grants the `curve` address complete control over token distribution and transferability, representing a single point of failure (7.3 Access Control, 7.5 Governance).

FixAcknowledge and clearly communicate this high degree of centralization to all users and potential investors. If future decentralization is desired, consider implementing a multi-signature wallet or a time-locked contract for the `curve` address to manage critical functions.

StatusUnresolved

High

Potential for Rug Pull / Malicious `curve` Behavior

H-02With 100% of the token supply minted to the `curve` address and its exclusive control over enabling transfers, there is a significant risk of a 'rug pull' (7.4 Economic). If the `curve` address is controlled by a malicious actor, they could unilaterally dump all tokens onto the market, causing a severe price crash.

IssueWith 100% of the token supply minted to the `curve` address and its exclusive control over enabling transfers, there is a significant risk of a 'rug pull' (7.4 Economic). If the `curve` address is controlled by a malicious actor, they could unilaterally dump all tokens onto the market, causing a severe price crash.

FixTransparency is crucial. Clearly communicate the token distribution model and the power of the `curve` address to potential investors. Implement mechanisms (e.g., liquidity locks, vesting schedules for the `curve` address's holdings) in the `curve` contract itself to build trust, if applicable to the project's design.

StatusUnresolved

Medium

Permanent Transfer Lock Risk

M-01The `enableTransfers()` function, which sets `transfersEnabled = true`, can only be called by the `curve` address. If the `curve` address is compromised, lost, or becomes inaccessible, the tokens could remain permanently untransferable (except for transfers involving the `curve` itself), leading to a denial of service for token holders (7.3 Access Control, 7.8 Operations).

IssueThe `enableTransfers()` function, which sets `transfersEnabled = true`, can only be called by the `curve` address. If the `curve` address is compromised, lost, or becomes inaccessible, the tokens could remain permanently untransferable (except for transfers involving the `curve` itself), leading to a denial of service for token holders (7.3 Access Control, 7.8 Operations).

FixEnsure robust security and operational procedures for the `curve` address. Consider a mechanism to transfer `curve` ownership or a time-locked release of transfer control if the original `curve` becomes unresponsive, though this adds complexity and new risks.

StatusUnresolved

Low

EIP-1167 Clone Initialization Race Condition (Theoretical)

L-01The `initialize` function lacks explicit access control beyond the `AlreadyInitialized` check. In an EIP-1167 factory deployment scenario, if the factory's deployment and initialization logic is not atomic or properly secured, a malicious actor could theoretically front-run the `initialize` call on a newly deployed clone, setting an attacker-controlled `curve` address (7.2 Code Security, 7.3 Access Control).

IssueThe `initialize` function lacks explicit access control beyond the `AlreadyInitialized` check. In an EIP-1167 factory deployment scenario, if the factory's deployment and initialization logic is not atomic or properly secured, a malicious actor could theoretically front-run the `initialize` call on a newly deployed clone, setting an attacker-controlled `curve` address (7.2 Code Security, 7.3 Access Control).

FixEnsure the factory contract responsible for deploying and initializing `UnicurveToken` clones implements robust access control (e.g., `onlyFactory` or `onlyOwner` for initialization calls) and/or atomic deployment-initialization patterns to prevent front-running.

StatusUnresolved

Info

Missing Event for `enableTransfers`

I-01The `enableTransfers()` function modifies a critical state variable (`transfersEnabled`) but does not emit an event. Emitting an event would improve transparency and allow off-chain monitoring of this crucial state change (7.2 Code Security, 7.8 Operations).

IssueThe `enableTransfers()` function modifies a critical state variable (`transfersEnabled`) but does not emit an event. Emitting an event would improve transparency and allow off-chain monitoring of this crucial state change (7.2 Code Security, 7.8 Operations).

FixEmit an event (e.g., `event TransfersEnabled(address indexed caller, uint256 timestamp);`) when `transfersEnabled` is set to `true` to provide better traceability and off-chain monitoring capabilities.

StatusUnresolved

Info

Hardcoded `SUPPLY` Constant

I-02The `SUPPLY` variable is declared as a `public constant`, fixing the total token supply at 1,000,000,000e18. This design choice means the token's total supply cannot be altered in the future without deploying a new contract (7.1 Architecture, 7.4 Economic).

IssueThe `SUPPLY` variable is declared as a `public constant`, fixing the total token supply at 1,000,000,000e18. This design choice means the token's total supply cannot be altered in the future without deploying a new contract (7.1 Architecture, 7.4 Economic).

FixThis is a design decision for a fixed-supply token. No action is required if this immutability is intended. If flexibility in total supply was ever desired, a different token architecture (e.g., mintable/burnable) would be necessary.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract leverages battle-tested OpenZeppelin ERC20 for core token functionality, enhancing code security (7.2 Code Security). The logic is straightforward, primarily managing a `transfersEnabled` flag and a `curve` address. However, the `curve` address holds significant technical control, including the ability to enable/disable all transfers (7.3 Access Control), representing a single point of failure.

GovernanceHigh1/10

The economic model is highly centralized, with the entire token supply minted to the `curve` address upon initialization (7.4 Economic). This grants the `curve` address complete control over token distribution and market dynamics, posing a high risk of a 'rug pull' if misused (7.4 Economic). There is no on-chain governance, concentrating all decision-making power with the `curve` controller (7.5 Governance).

UpgradesHigh1/10

The `UnicurveToken` contract is designed as an EIP-1167 clone, meaning it is not directly upgradeable (7.7 Upgrades). This eliminates risks associated with upgrade mechanisms, such as proxy misconfigurations or logic bugs introduced during upgrades. Any future changes to token logic would require deploying a new token contract.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom

ImplementationVerified source

Upgrades (30d)0 · stable

Holder Composition

61.8% in top 10

23.9% in wallets37.9% in contracts

Effective Concentration39.1%

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

$62.9K across 5 pairs

Analysed pair$51.6K

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 Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

3 addresses

Deployer

0xf942…1458

Unlocked LP Held By

0x1ac4…062c0x632b…189a

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

What Raised This Score

10 factors

Ownership status UNKNOWN (owner could not be resolved)
Proxy contract (upgradeable — admin can replace logic)
Non-standard proxy storage (Etherscan-confirmed)
Top-10 concentration > 30% (61.8% total → 39.1% effective; 23.9% in EOAs, 37.9% 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 = 82% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 82% of DEX liquidity)
2 High finding(s) from audit
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 UNICURVE Safe?

Security Findings

Centralized Control by `curve` Address

Potential for Rug Pull / Malicious `curve` Behavior

Permanent Transfer Lock Risk

EIP-1167 Clone Initialization Race Condition (Theoretical)

Missing Event for `enableTransfers`

Hardcoded `SUPPLY` Constant

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of UNICURVE?