Is Chip Safe? Smart Contract Security Analysis

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedUnknown

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyFail

Audit History

2 audits on record

Jul 2276Jul 2373

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

Audit Summary

This audit covers an OpenZeppelin TransparentUpgradeableProxy contract. The primary and most critical finding is that the associated implementation contract (0x13ae0c66dd063fbd6ba12ec1a1d5d07343daa03f) is unverified on Etherscan. Without access to the implementation's source code, a comprehensive security assessment of the system's core logic is impossible, rendering the entire system's security posture unknown and highly risky. The proxy itself is a standard, well-audited OpenZeppelin component, but its security is entirely dependent on the unverified implementation.

Final Recommendation: The most critical recommendation is to immediately verify the source code of the implementation contract (0x13ae0c66dd063fbd6ba12ec1a1d5d07343daa03f) on Etherscan. Without this, a proper security assessment is impossible, and the system remains at severe risk. Once verified, a full audit of the implementation logic should be conducted to identify and mitigate any vulnerabilities. Additionally, consider implementing a robust governance mechanism for the `ProxyAdmin` owner, such as a multi-signature wallet with a timelock, to introduce a delay for critical operations like upgrades, enhancing security and transparency.

Category Ratings

TechnicalMedium

6/10

The proxy contract (7.1 Architecture) is a standard OpenZeppelin TransparentUpgradeableProxy, which is a well-vetted and secure component. It correctly implements the transparent proxy pattern, preventing selector clashes and ensuring proper admin-only upgrade functionality (7.2 Code Security). The

GovernanceHigh

1/10

The system relies on a `ProxyAdmin` contract for upgrade management (7.5 Governance). The `initialOwner` of this `ProxyAdmin` determines the centralization level of upgrade authority. If this owner is a single EOA, it represents a single point of failure and a high centralization risk (7.3 Access Co

UpgradesHigh

3/10

The contract utilizes the Transparent Proxy pattern for upgradeability (7.7 Upgrades), allowing the implementation logic to be updated. This flexibility is a strength, enabling bug fixes and feature enhancements. However, the unverified nature of the current implementation contract means that any fu

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent

AdminOZ ProxyAdmin

ImplementationVerified source

Upgrades (30d)0 · stable

LP Distribution

Top-1 Unlocked Holder88.4%

Top-3 Unlocked98.9%

What Raised This Score

9 factors

Ownership status UNKNOWN (owner could not be resolved)
Proxy contract (upgradeable — admin can replace logic)
Top-10 concentration > 70% (75.6% total → 70.8% effective; 67.5% in EOAs, 8.1% in contracts — extreme)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 88.4% (independent LP — depth risk, pool = 97% of DEX liquidity)
LP top3 unlocked holders = 98.9% (independent LP — depth risk, pool = 97% of DEX liquidity)
1 Critical finding(s) from audit
1 High finding(s) from audit
1 Medium 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

4 total

1 Critical 1 High 1 Medium 1 Info

C-01CriticalUnresolved

Unverified Implementation Contract

The proxy contract (0x0c1c1c109fe34733fca54b82d7b46b75cfb71f6e) points to an implementation contract (0x13ae0c66dd063fbd6ba12ec1a1d5d07343daa03f) whose source code is not verified on Etherscan. This prevents any security analysis of the actual business logic and state management, making it impossible to ascertain the system's safety, functionality, or adherence to security best practices. The entire system's security is unknown.

Recommendation: Immediately verify the source code of the implementation contract on Etherscan. Once verified, a comprehensive security audit of the implementation contract must be performed to identify and address any vulnerabilities before further operations.

H-01HighUnresolved

Centralized Upgrade Authority

The `TransparentUpgradeableProxy` deploys a `ProxyAdmin` contract, whose `initialOwner` has sole control over upgrading the proxy's implementation. If this `initialOwner` is a single Externally Owned Account (EOA), it represents a single point of failure. A compromise of this EOA would allow an attacker to deploy arbitrary malicious code as the new implementation, potentially leading to a complete loss of funds or control over the protocol.

Recommendation: It is strongly recommended that the `initialOwner` of the `ProxyAdmin` be a robust, multi-signature wallet (e.g., Gnosis Safe) or a decentralized autonomous organization (DAO) controlled by multiple parties. This distributes control and reduces the risk associated with a single point of failure.

M-01MediumUnresolved

Lack of Timelock for Critical Operations

The current setup allows the `ProxyAdmin` owner to execute upgrades immediately without any time delay. This means that if the admin key is compromised or if a malicious upgrade is pushed, there is no window for users or monitoring systems to react or exit before the changes take effect. This lack of a timelock increases the risk of rapid, unrecoverable damage.

Recommendation: Implement a timelock mechanism for the `ProxyAdmin` owner. This could involve making the `ProxyAdmin` owner a TimelockController contract, which introduces a mandatory delay between proposing an upgrade and its execution. This provides a crucial window for review and reaction, enhancing overall system security and user confidence.

I-01InformationalUnresolved

Immutable Admin Address Design

The `_admin` variable in `TransparentUpgradeableProxy` is declared as `immutable`. This is a design choice in OpenZeppelin Contracts v5.x to optimize gas costs by avoiding storage reads for the admin address. It means the specific `ProxyAdmin` instance deployed by the proxy cannot be changed; only its ownership can be transferred. While this prevents accidental overwrites of the admin slot by the implementation, it also means the proxy is permanently tied to that specific `ProxyAdmin` contract instance.

Recommendation: This is an intentional design choice by OpenZeppelin and generally considered a security improvement. No direct action is required for the proxy itself, but it's important to understand that the security of the upgrade mechanism relies entirely on the `ProxyAdmin` contract's ownership and its own security practices.

Is Chip Safe? CHIP