Is BitVault Signal (BV7X) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low1 Info

High

Centralized Control of Metadata and Admin Role

H-01The `_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.

IssueThe `_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.

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

StatusUnresolved

Medium

Critical Reliance on External Superchain Token Bridge for Supply Management

M-01The `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.

IssueThe `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.

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

StatusUnresolved

Low

Misleading `maxSupply_` Parameter in Constructor

L-01The `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.

IssueThe `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.

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

StatusUnresolved

Info

Single-Use `verify()` Function

I-01The `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.

IssueThe `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.

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

StatusUnresolved

Category Ratings

TechnicalLow9/10

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

GovernanceMedium5/10

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.

UpgradesLow9/10

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.

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

77.7% in top 10

11.2% in wallets66.4% in contracts

Effective Concentration37.8%

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

$199.5K across 2 pairs

Uniswap v4WETHanalysed$199.1K Uniswap v3WETH$434

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.

LP Distribution

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

3 addresses

Deployer

0xfc42…5736

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.

What Raised This Score

7 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

Is BitVault Signal Safe?

Security Findings

Centralized Control of Metadata and Admin Role

Critical Reliance on External Superchain Token Bridge for Supply Management

Misleading `maxSupply_` Parameter in Constructor

Single-Use `verify()` Function

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of BitVault Signal?