Is Velvet Safe? Smart Contract Security Analysis

Security Checklist

1/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyFail

Audit History

2 audits on record

Jul 2363

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

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.

Final Recommendation: To ensure the overall security of the `BridgeToken` system, it is crucial to conduct a full audit of the implementation contract and the Beacon contract. Special attention should be paid to the access control mechanisms governing the Beacon's ability to update the implementation address. Implement robust security measures, such as multi-signature wallets or time-locks, for any administrative roles with upgrade privileges to mitigate centralized control risks.

Category Ratings

TechnicalMedium

6/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, s

GovernanceHigh

3/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 central

UpgradesHigh

1/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 r

Proxy Upgrade Controls

Proxy TypeBeacon

ImplementationVerified source

Upgrades (30d)0 · stable

LP Distribution

Top-1 Unlocked Holder94.9%

Top-3 Unlocked100.0%

What Raised This Score

11 factors

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% (74.9% total → 33.7% effective; 6.2% in EOAs, 68.7% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 94.9% (independent LP — depth risk, pool = 99% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 99% 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 Findings

4 total

1 High 1 Medium 1 Low 1 Info

H-01HighUnresolved

Incomplete Audit Scope - Missing Implementation Code

The 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 (0x5537857664b0f9efe38c9f320f75fef23234d904) 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.

Recommendation: Provide the full source code for the implementation contract and the Beacon contract to enable a complete security audit of the entire system.

M-01MediumUnresolved

Centralized Upgrade Control via Beacon

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

Recommendation: Implement 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.

L-01LowUnresolved

Reliance on External Beacon Contract Security

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

Recommendation: Conduct 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.

I-01InformationalUnresolved

Standard OpenZeppelin BeaconProxy Usage

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

Recommendation: Continue 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.

Is Velvet Safe? VELVET