Quantum Audit Logo
Launch App

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

Is Cap a Scam?

CAPEthereum
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on recordNew Launch · 2d old
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance3/10Upgrades3/10Checks passed2 of 5Findings1 Low · 4 Info5
SummaryAI Copilot

This audit covers an ERC1967Proxy contract, which is a standard upgradeable proxy implementation from OpenZeppelin.

Read the full analysis
What raised the score
  • Ownership not renounced — Timelock 720h delay
  • Proxy contract
  • Top-10 concentration > 30%
  • LP lock status UNKNOWN — the pool's LP could not be read
  • Liquidity < $50k
  • Token age < 7 days
  • 1 Low finding(s) from audit
Exact 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)
  • LP lock status UNKNOWN — the pool's LP could not be read
  • 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

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.

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockUnknown
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
100.0%Contracts
100.0%Contracts
ContractsBubble area = share of supply
100.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking100.0%
Effective concentrationwhat the score reads40.0%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$28.7K across 2 pairs

The risk score reads depth across every pair.

LP tokensUnknown

Whether the LP tokens are locked could not be determined.

Analysed pool$28.4KShare of depth99.0%

Security Findings

1 Low4 Info
Low

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)L-01

Issue

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)

Fix

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.

Status

Unresolved

Info

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)I-01

Issue

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)

Fix

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.

Status

Unresolved

Info

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)I-02

Issue

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)

Fix

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.

Status

Unresolved

Info

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)I-03

Issue

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)

Fix

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.

Status

Unresolved

Info

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)I-04

Issue

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)

Fix

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.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical8/10Low risk

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.

Governance3/10High risk

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.

Upgrades3/10High risk

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).

Final RecommendationWhat to do about this score

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.

Contract & Record

1 audit on record
TypeERC1967Proxy
NetworkEthereum
Token age2d
Contract0x9999…9999
Deployer0xc1ab…6b52
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Cap security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Jul 23, 202646Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

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 recordAll audits
AsentumASE · Ethereum46MediumTornadoCashTORN · Ethereum46MediumTreasureMAGIC · Ethereum46MediumProtonXPR · Ethereum46MediumSafe TokenSAFE · Ethereum47MediumLQTYEthereum47Medium

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 Is this your token? Publish your own audit on this page