Is Cap a Scam? New Token Security Check

Critical Security Flags

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyFail

Audit History

2 audits on record

Jul 2348

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

Audit Summary

This audit covers an ERC1967Proxy contract, which is a standard upgradeable proxy implementation from OpenZeppelin. The proxy itself is well-tested and robust. However, the overall security and functionality of the system are critically dependent on the associated implementation contract, which was not provided for review. Key risks include the security of the implementation's logic, its upgrade authorization mechanism, and proper initialization handling.

Final Recommendation: Prioritize a comprehensive security audit of the implementation contract, focusing on its access control mechanisms, especially the `_authorizeUpgrade` function, to ensure only authorized entities can initiate upgrades. Thoroughly review the implementation's initialization logic to prevent re-initialization attacks and ensure proper handling of `msg.value` if sent during deployment or upgrades. Implement robust testing, including unit, integration, and fuzz testing, for the entire system (proxy + implementation) to cover all possible execution paths and edge cases.

Category Ratings

TechnicalLow

8/10

The audited code consists of standard OpenZeppelin ERC1967Proxy contracts, which are widely used and have undergone extensive community review and formal verification. The proxy correctly implements the `delegatecall` mechanism and ERC-1967 storage slots for implementation and admin addresses (7.1 A

GovernanceHigh

2/10

The ERC1967Proxy contract itself does not contain any direct governance or economic logic (7.4 Economic, 7.5 Governance). Its role is purely to delegate calls. Therefore, there are no inherent economic or governance risks within this specific contract. Any economic or governance risks would reside e

UpgradesHigh

2/10

The contract implements the UUPS (Universal Upgradeable Proxy Standard) pattern, which is a robust and widely adopted upgrade mechanism (7.7 Upgrades). The proxy delegates upgrade authorization to the implementation contract, allowing for flexible and secure upgrade paths. However, the security of t

Proxy Upgrade Controls

Proxy TypeEip1967 Uups

ImplementationVerified source

Upgrades (30d)0 · stable

What Raised This Score

7 factors

Ownership NOT renounced — Timelock 720h delay (exit window)
Proxy contract (upgradeable — admin can replace logic)
Top-10 concentration > 30% (100.0% total → 40.0% effective; 0.0% in EOAs, 100.0% in contracts — moderate)
Liquidity NOT locked (owner can withdraw — rug-pull risk)
Liquidity < $50k ($21,423 across 3 pairs — thin market)
Token age < 7 days (early, volatile)
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

5 total

1 Low 4 Info

L-01LowUnresolved

Potential for Stuck Funds with `msg.value` in Initializer

The `ERC1967Utils.upgradeToAndCall` function, when called with `data` (e.g., for initialization), allows `msg.value` to be forwarded to the implementation via `Address.functionDelegateCall`. If the target function in the implementation is not `payable` or does not properly handle received `msg.value`, any Ether sent during deployment or upgrade with initialization data could become permanently stuck in the implementation contract. While `_checkNonPayable()` prevents `msg.value` if `data` is empty, the case with `data` requires developer vigilance. (Coverage: 7.2 Code Security, 7.4 Economic)

Recommendation: Ensure that any function in the implementation contract intended to be called via `upgradeToAndCall` with `data` is explicitly marked `payable` if it is expected to receive Ether. If no Ether is expected, ensure the function is not `payable` or that any received Ether is handled (e.g., forwarded or reverted) to prevent funds from being stuck.

I-01InformationalUnresolved

Core Logic Resides in Unaudited Implementation

The `ERC1967Proxy` contract acts as a transparent proxy, delegating all calls to an external implementation contract. The security, functionality, and economic integrity of the system are entirely dependent on the implementation contract, which was not provided for this audit. Without auditing the implementation, no definitive statement can be made about the overall system's security. (Coverage: 7.1 Architecture, 7.2 Code Security, 7.4 Economic)

Recommendation: Conduct a full security audit of the implementation contract to identify and mitigate any vulnerabilities. Ensure the implementation adheres to best practices for smart contract security, including reentrancy guards, access control, and secure arithmetic operations.

I-02InformationalUnresolved

Upgrade Authorization Logic External to Proxy

This is a UUPS proxy, meaning the logic for authorizing upgrades resides within the implementation contract (e.g., via an `_authorizeUpgrade` function). The security of future upgrades, including who can initiate them and under what conditions, is solely determined by the implementation's access control and upgrade logic, which is outside the scope of this review. An insecure `_authorizeUpgrade` function in the implementation could lead to unauthorized upgrades. (Coverage: 7.3 Access Control, 7.7 Upgrades)

Recommendation: Ensure the implementation contract's `_authorizeUpgrade` function (or equivalent upgrade authorization logic) is robustly secured, ideally using a multi-signature wallet or a time-locked governance mechanism. Thoroughly test the upgrade path to prevent unauthorized or malicious upgrades.

I-03InformationalUnresolved

Criticality of Initializer Function in Implementation

The proxy's constructor calls `ERC1967Utils.upgradeToAndCall` which can execute an initialization function on the implementation if `_data` is provided. It is crucial that the implementation's initializer is correctly implemented, callable only once, and secured against re-initialization attacks to prevent critical vulnerabilities that could lead to ownership hijacking or state corruption. (Coverage: 7.2 Code Security, 7.8 Operations)

Recommendation: Implement a robust `initializer` function in the implementation contract, ensuring it uses the `_disableInitializers` modifier from OpenZeppelin's `Initializable` contract to prevent multiple invocations. Carefully review the logic within the initializer to ensure it correctly sets up the contract's initial state.

I-04InformationalUnresolved

Storage Collision Risk with Implementation

While OpenZeppelin's ERC-1967 proxy uses well-defined storage slots for its internal variables (e.g., `IMPLEMENTATION_SLOT`), any implementation contract must be carefully designed to avoid storage collisions with these proxy-specific slots. Improper storage layout in the implementation, especially if not using `UUPSUpgradeable` or `TransparentUpgradeableProxy` correctly, could lead to critical state corruption or unexpected behavior. (Coverage: 7.1 Architecture, 7.2 Code Security)

Recommendation: Ensure the implementation contract inherits from `UUPSUpgradeable` (or `TransparentUpgradeableProxy` if using that pattern) and follows its storage layout guidelines. Avoid declaring state variables at storage slot 0 or other slots reserved by the proxy. Use tools like `solidity-storage-layout` to verify storage compatibility between the proxy and implementation.

Frequently Asked Questions

Is Cap a scam?

Based on available data, labeling Cap definitively as a scam is complex. The contract is verified and ownership is renounced, providing some transparency and immutability. However, the extreme token centralization, where the top 10 holders own 100% of the supply, and the absence of locked liquidity introduce significant rug-pull and manipulation risks. These substantial red flags contribute to its high-risk score, warranting extreme caution.

Is Cap safe to buy?

Given the current security profile, Cap is not considered safe for investment. The primary concerns stem from the top 10 holders controlling 100% of the supply, creating extreme centralization risk and potential for price manipulation. Additionally, the lack of locked liquidity means funds can be withdrawn, exposing investors to a "rug pull." These critical factors contribute to its high risk score of 57/100.

Has Cap been audited?

The Cap contract has been verified on Ethereum, meaning its code is publicly available and matches what's deployed on-chain. This enhances transparency. However, contract verification is distinct from a comprehensive security audit, which involves an in-depth review by security experts for vulnerabilities. The provided data does not indicate that Cap has undergone such an audit.

Is Cap a Scam? CAP