Quantum Audit Logo
Launch App

On-chain security analysis — is it a scam or legit?

Is BitVault Signal Safe?

BV7XBase
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 record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical9/10Governance5/10Upgrades9/10Checks passed4 of 5Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The ClankerToken contract implements an ERC20 token with extensions for burning, permits, and voting, leveraging battle-tested OpenZeppelin libraries.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 30% (77.7% total → 37.8% effective; 11.2% in EOAs, 66.4% 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 = 100% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • 1 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

Security Checklist

as of audit · Sep 44 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
66.4%Contracts11.2%Wallets22.3%Everyone else
66.4%Contracts11.2%22.3%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
77.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking66.4%
  • Walletsanonymous holders, free to sell11.2%
  • Everyone elsethe rest of the supply22.3%
Effective concentrationwhat the score reads37.8%
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$199.5K across 2 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$199.1KShare of depth99.8%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x63d2…34960x8f63…ff41

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

Security Findings

1 High1 Medium1 Low1 Info
High

Centralized Control of Metadata and Admin Role

The _admin address has significant control over the token's mutable properties. It can update the _image, _metadata, and _context strings, which are critical for how the token is represented in interfaces and external systems. Furthermore, the _admin can transfer its own role to any other address via updateAdmin(). A compromise of this single _admin address could lead to unauthorized changes to the token's public representation and a complete loss of administrative control.H-01

Issue

The _admin address has significant control over the token's mutable properties. It can update the _image, _metadata, and _context strings, which are critical for how the token is represented in interfaces and external systems. Furthermore, the _admin can transfer its own role to any other address via updateAdmin(). A compromise of this single _admin address could lead to unauthorized changes to the token's public representation and a complete loss of administrative control.

Fix

Consider implementing a multi-signature wallet for the _admin role to require multiple approvals for sensitive operations like updateAdmin(), updateImage(), and updateMetadata(). Alternatively, introduce a time-lock mechanism for such critical changes to provide a window for detection and intervention.

Status

Unresolved

Medium

Critical Reliance on External Superchain Token Bridge for Supply Management

The crosschainMint() and crosschainBurn() functions are essential for managing the token's supply across different chains. These functions are exclusively callable by the Predeploys.SUPERCHAIN_TOKEN_BRIDGE address. The security and integrity of the token's total supply are therefore entirely dependent on the security, correct configuration, and operational robustness of this external bridge contract. Any vulnerability or compromise within the SUPERCHAIN_TOKEN_BRIDGE could directly lead to unauthorized minting or burning of ClankerToken, severely impacting its economic stability.M-01

Issue

The crosschainMint() and crosschainBurn() functions are essential for managing the token's supply across different chains. These functions are exclusively callable by the Predeploys.SUPERCHAIN_TOKEN_BRIDGE address. The security and integrity of the token's total supply are therefore entirely dependent on the security, correct configuration, and operational robustness of this external bridge contract. Any vulnerability or compromise within the SUPERCHAIN_TOKEN_BRIDGE could directly lead to unauthorized minting or burning of ClankerToken, severely impacting its economic stability.

Fix

Ensure that the SUPERCHAIN_TOKEN_BRIDGE contract is subject to rigorous security audits, continuous monitoring, and robust operational security practices. Document the critical dependency on this bridge and its implications for the token's supply model. Consider establishing clear emergency procedures in case of a bridge compromise.

Status

Unresolved

Low

Misleading maxSupply_ Parameter in Constructor

The maxSupply_ parameter in the constructor is used to mint the initial supply only if block.chainid == initialSupplyChainId_. However, the crosschainMint() function allows the SUPERCHAIN_TOKEN_BRIDGE to mint additional tokens at any time. This means that maxSupply_ does not represent a global maximum supply for the token across all chains, but rather the initial supply on a specific chain. This could be misleading to users, exchanges, or protocols that might interpret maxSupply_ as a hard cap on the total token supply.L-01

Issue

The maxSupply_ parameter in the constructor is used to mint the initial supply only if block.chainid == initialSupplyChainId_. However, the crosschainMint() function allows the SUPERCHAIN_TOKEN_BRIDGE to mint additional tokens at any time. This means that maxSupply_ does not represent a global maximum supply for the token across all chains, but rather the initial supply on a specific chain. This could be misleading to users, exchanges, or protocols that might interpret maxSupply_ as a hard cap on the total token supply.

Fix

Clarify in the contract's NatSpec documentation and external project documentation that maxSupply_ refers specifically to the initial supply minted on the designated chain, and that the total supply can increase through cross-chain minting operations. Consider renaming the parameter to initialChainSupply_ or similar for better clarity.

Status

Unresolved

Info

Single-Use verify() Function

The verify() function can only be called once by the _originalAdmin to set the _verified flag to true. Once set, it cannot be changed. While this is the intended design, the specific purpose and implications of this _verified flag for the token's functionality, ecosystem integration, or future operations are not explicitly detailed within the contract's code comments.I-01

Issue

The verify() function can only be called once by the _originalAdmin to set the _verified flag to true. Once set, it cannot be changed. While this is the intended design, the specific purpose and implications of this _verified flag for the token's functionality, ecosystem integration, or future operations are not explicitly detailed within the contract's code comments.

Fix

Add comprehensive NatSpec documentation to the verify() function and the _verified state variable, explaining its purpose, what 'verified' status signifies, and any external systems or processes that rely on this flag. This will improve clarity for future developers and integrators.

Status

Unresolved

Analysis

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

The ClankerToken contract implements an ERC20 token with extensions for burning, permits, and voting, leveraging battle-tested OpenZeppelin libraries. It includes custom logic for cross-chain minting/burning via a Superchain Token Bridge and administrative control over metadata. Key findings include centralized administrative control, a critical dependency on the external Superchain Token Bridge for supply management, and a potentially misleading maxSupply_ parameter.

Technical9/10Low risk

The contract demonstrates strong technical foundations by inheriting from well-audited OpenZeppelin ERC20 extensions (ERC20Burnable, ERC20Permit, ERC20Votes), which minimizes common code-level vulnerabilities (7.2 Code Security). Cross-chain minting and burning functions are correctly restricted to the Predeploys.SUPERCHAIN_TOKEN_BRIDGE, ensuring controlled supply management (7.3 Access Control). However, the overall technical security is heavily reliant on the external SUPERCHAIN_TOKEN_BRIDGE contract, introducing a significant external dependency risk (7.6 External).

Governance5/10Medium risk

The contract's economic model relies on a fixed initial supply on a specific chain, with subsequent supply adjustments managed by the SUPERCHAIN_TOKEN_BRIDGE for cross-chain transfers (7.4 Economic). Governance is centralized, with an _admin role capable of updating token metadata and transferring administrative control (7.5 Governance). This centralization presents a single point of failure; compromise of the _admin could lead to unauthorized changes or loss of control. The maxSupply_ parameter in the constructor is specific to the initial chain and does not represent a global supply cap, which could be misleading.

Upgrades9/10Low risk

The ClankerToken contract is implemented as a standard, non-upgradeable ERC20 token (7.7 Upgrades). It does not utilize any proxy patterns, meaning its logic cannot be modified post-deployment. This eliminates risks associated with upgradeability, such as proxy misconfigurations or upgrade path vulnerabilities.

Final RecommendationWhat to do about this score

It is recommended to implement robust security measures for the _admin address, such as a multi-signature wallet, to mitigate the risks associated with centralized control.

Thoroughly audit and monitor the SUPERCHAIN_TOKEN_BRIDGE contract, as its security is paramount to the integrity of the token's cross-chain supply. Additionally, enhance documentation to clearly articulate the role of maxSupply_ and the overall token supply mechanism across chains, ensuring transparency for users and integrators.

Contract & Record

1 audit on record
TypeClankerToken
NetworkBase
Token age3mo
Contract0xd88f…d8dc
Deployer0xfc42…5736
Badge for your website
BitVault Signal 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, 202632Low

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

Frequently Asked Questions

What is the BV7X contract address?

The BitVault Signal (BV7X) contract on Base is 0xd88fd4a11255e51f64f78b4a7d74456325c2d8dc. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is BitVault Signal a scam?

Quantum Audit's risk score for BitVault Signal is 32/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is BV7X liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $199.5K.

Who holds BV7X?

As of Sep 4, 2026, the 10 largest holders own 77.7% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
OpenAIBase32LowGoogle T-REXTREX · Base32LowOWBBase33LowFlowerBase33LowJerry the goatJERRY · Base31LowHunter Biden's LaptopLAPTOP · Base31Low

Would You Like a More Detailed Audit of BitVault Signal?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page