Quantum Audit Logo

Is Cap a Scam?

Early-stage security check — honeypot & rug-pull analysis

Is this your token? Publish your own audit on this page →

Cap CAP
0x9999…9999
Ethereum Not verifiedLast checked 3d ago 1 audit on record New Launch · 2d old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 Low4 Informational
! Early-stage analysis. This token has limited on-chain history (2d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$9.2800
Liquidity
$28.4K
Price
$0.07056
Token Age
2d
Top 10 Holders
100.0%

Security Findings

1 Low4 Info
Low

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

L-01The `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)
IssueThe `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)
FixEnsure 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.
StatusUnresolved
Info

Core Logic Resides in Unaudited Implementation

I-01The `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)
IssueThe `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)
FixConduct 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.
StatusUnresolved
Info

Upgrade Authorization Logic External to Proxy

I-02This 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)
IssueThis 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)
FixEnsure 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.
StatusUnresolved
Info

Criticality of Initializer Function in Implementation

I-03The 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)
IssueThe 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)
FixImplement 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.
StatusUnresolved
Info

Storage Collision Risk with Implementation

I-04While 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)
IssueWhile 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)
FixEnsure 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.
StatusUnresolved

Category Ratings

TechnicalLow8/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 Architecture). The use of inline assembly for `delegatecall` is standard and correctly handled (7.2 Code Security). However, the overall technical security is heavily reliant on the unverified implementation contract, which could introduce vulnerabilities if not properly secured.

GovernanceHigh2/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 entirely within the implementation contract, which is not part of this audit.

UpgradesHigh2/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 the upgrade process is entirely dependent on the implementation's `_authorizeUpgrade` function and its access control, which was not available for review. The proxy's constructor correctly uses `upgradeToAndCall` for initial setup, but careful handling of `msg.value` and initialization data is crucial (7.8 Operations).

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

100.0% in top 10
0.0% in wallets100.0% in contracts
Effective Concentration40.0%

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

$28.7K across 2 pairs
Uniswap v4USDCanalysed$28.4K99.0%Uniswap v4USDC$2771.0%

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.

Key Addresses

1 addresses
Deployer
0xc1ab…6b52

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 ($28,690 across 2 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

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.

Related Audits

6 more on the record
c8ntinuum (CTM)High RiskSafe Token (SAFE)High RiskLQTYHigh RiskCurve DAO (CRV)High RiskVestra DAO (VSTR)High RiskMOMOHigh Risk

Would You Like a More Detailed Audit of Cap?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit