Quantum Audit Logo

Is Velvet Safe?

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

Velvet VELVET
0xbf92…7cdd
Base Not verifiedLast checked 3d ago 1 audit on record
Executive SummaryAI Copilot

This audit covers the `BridgeToken` proxy contract, which utilizes the OpenZeppelin BeaconProxy pattern. The core logic resides in an unprovided implementation contract (0x5537857664b0f9efe38c9f320f75fef23234d904), making this a partial audit. The primary risks identified relate to the centralized control over upgrades via the associated Beacon contract, whose governance and security mechanisms are unknown.

1 High1 Medium1 Low1 Informational
Volume 24h
$992.2K
Liquidity
$1.25M
Price
$0.09206
Token Age
1mo
Top 10 Holders
70.9%

Security Findings

High

Incomplete Audit Scope - Missing Implementation Code

H-01The provided source code only includes the `BridgeToken` proxy contract, which delegates its logic to an implementation contract via a Beacon. The source code for the actual implementation contract (0x5537…d904) was not provided for review. This prevents a comprehensive security assessment of the core business logic, state management, and potential vulnerabilities such as reentrancy, access control flaws, or economic exploits within the token's functionality.
IssueThe provided source code only includes the `BridgeToken` proxy contract, which delegates its logic to an implementation contract via a Beacon. The source code for the actual implementation contract () was not provided for review. This prevents a comprehensive security assessment of the core business logic, state management, and potential vulnerabilities such as reentrancy, access control flaws, or economic exploits within the token's functionality.
FixProvide the full source code for the implementation contract and the Beacon contract to enable a complete security audit of the entire system.
StatusUnresolved
Medium

Centralized Upgrade Control via Beacon

M-01The `BridgeToken` contract is a `BeaconProxy`, meaning its logic is entirely controlled by the implementation address set in an external `Beacon` contract. The administrative control over this `Beacon` contract determines who can upgrade the `BridgeToken`'s logic. If the `Beacon` contract is controlled by a single entity or an inadequately secured address, it introduces a significant centralization risk, allowing unilateral changes to the token's behavior without community oversight.
IssueThe `BridgeToken` contract is a `BeaconProxy`, meaning its logic is entirely controlled by the implementation address set in an external `Beacon` contract. The administrative control over this `Beacon` contract determines who can upgrade the `BridgeToken`'s logic. If the `Beacon` contract is controlled by a single entity or an inadequately secured address, it introduces a significant centralization risk, allowing unilateral changes to the token's behavior without community oversight.
FixImplement robust access control mechanisms for the `Beacon` contract, such as a multi-signature wallet with a high threshold or a time-locked governance contract, to manage implementation upgrades. This decentralizes control and introduces a delay for critical changes.
StatusUnresolved
Low

Reliance on External Beacon Contract Security

L-01The security and integrity of the `BridgeToken` system are directly dependent on the security of the external `Beacon` contract. Any vulnerability or compromise in the `Beacon` contract could directly impact all `BeaconProxy` instances, including `BridgeToken`, by allowing unauthorized or malicious upgrades to the implementation.
IssueThe security and integrity of the `BridgeToken` system are directly dependent on the security of the external `Beacon` contract. Any vulnerability or compromise in the `Beacon` contract could directly impact all `BeaconProxy` instances, including `BridgeToken`, by allowing unauthorized or malicious upgrades to the implementation.
FixConduct a thorough security audit of the `Beacon` contract itself, focusing on its access control, upgrade logic, and potential attack vectors. Ensure the `Beacon` contract is immutable or upgradeable only through secure, transparent, and decentralized governance processes.
StatusUnresolved
Info

Standard OpenZeppelin BeaconProxy Usage

I-01The `BridgeToken` contract correctly utilizes the `BeaconProxy` pattern from OpenZeppelin contracts. This pattern is a well-established and audited solution for upgradeable contracts, allowing multiple proxy instances to share the same implementation logic via a central `Beacon` contract. This approach saves gas and simplifies management for a set of identical upgradeable contracts.
IssueThe `BridgeToken` contract correctly utilizes the `BeaconProxy` pattern from OpenZeppelin contracts. This pattern is a well-established and audited solution for upgradeable contracts, allowing multiple proxy instances to share the same implementation logic via a central `Beacon` contract. This approach saves gas and simplifies management for a set of identical upgradeable contracts.
FixContinue to follow best practices for upgradeable contracts, including careful management of storage slots in the implementation to prevent storage collisions and thorough testing of all upgrade paths.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The `BridgeToken` contract is a minimal proxy leveraging OpenZeppelin's `BeaconProxy` (7.1 Architecture). This pattern delegates all calls to an implementation contract specified by a `Beacon` contract. The proxy contract itself is simple and correctly imports standard OpenZeppelin libraries, suggesting good code quality (7.2 Code Security). However, the actual business logic and state management reside in the implementation contract, which was not provided for review. Therefore, a comprehensive technical security assessment (including 7.3 Access Control) cannot be completed.

GovernanceHigh3/10

The economic model (7.4 Economic) and governance mechanisms (7.5 Governance) of the `BridgeToken` system are primarily determined by the implementation contract and the `Beacon` contract. Without access to the source code or details of these components, a full assessment is not possible. The centralized control over the `Beacon` contract, which dictates the implementation, represents a significant governance risk as a single entity can unilaterally change the token's logic.

UpgradesHigh1/10

The `BridgeToken` contract uses the `BeaconProxy` pattern, meaning its implementation can be upgraded by changing the address stored in the associated `Beacon` contract (7.7 Upgrades). This provides flexibility but introduces a high upgrade risk if the `Beacon`'s administrative control is not robustly secured, for example, by a multi-signature wallet or a time-locked governance mechanism. The current audit cannot assess the security of the `Beacon` contract or its upgrade permissions, leaving a critical gap in the overall upgrade safety analysis.

Security Checklist

Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeBeacon
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

17.6% in wallets53.3% in contracts
Effective Concentration38.9%

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

Show 4 more pairsShow less

The 3 remaining pairs hold $2 between them and are not listed.

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

Deployer
0xe8b8…4ba3
Unlocked LP Held By
0x17a3…4463

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

What Raised This Score

  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 30% (70.9% total → 38.9% effective; 17.6% in EOAs, 53.3% 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 = 98% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 98% 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

Related Audits

DiemHigh RiskjesseHigh RiskRipe DAO Governance Token (RIPE)High RiskUmiaHigh RiskJito Staked SOL (JITOSOL)High RiskDolphin (POD)High Risk

Would You Like a More Detailed Audit of Velvet?

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

Get Detailed Audit