Is ViciCoin (VCNT) Safe? Smart Contract Security Analysis

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyFail

Audit History

2 audits on record

Jul 2270Jul 2351

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

Audit Summary

This audit covers a TransparentUpgradeableProxy contract, a standard OpenZeppelin implementation. While the proxy contract itself is well-audited and robust, the security posture is significantly impacted by the unverified implementation contract it points to and the unknown security setup of its administrative control. These factors introduce substantial risks related to potential malicious upgrades and lack of transparency.

Final Recommendation: Prioritize verifying the source code of the current implementation contract to enable a full security assessment. Implement robust security measures for the admin key, such as a multi-signature wallet or a dedicated `ProxyAdmin` contract, to mitigate the risk of a single point of failure. Establish a clear and secure upgrade process, including thorough testing and auditing of all new implementation versions before deployment to the production proxy.

Category Ratings

TechnicalLow

7/10

The TransparentUpgradeableProxy contract itself is a robust and well-audited OpenZeppelin component (7.2 Code Security). It correctly implements the transparent proxy pattern, preventing selector clashes. However, the primary technical risk stems from the unverified implementation contract (7.6 Exte

GovernanceHigh

1/10

The contract's economic and governance security is heavily dependent on the administrative control (7.3 Access Control, 7.5 Governance). The proxy allows a single admin address to initiate upgrades and change the admin itself. The prefill data indicates the admin address is not clearly identifi

UpgradesHigh

2/10

The contract utilizes the Transparent Proxy pattern for upgradeability (7.7 Upgrades), allowing the implementation logic to be changed. While the mechanism itself is standard, the unverified nature of the current implementation contract (7.6 External) and the centralized control over upgrades (7.3 A

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent

AdminOZ ProxyAdmin

ImplementationVerified source

Upgrades (30d)0 · stable

LP Distribution

Top-1 Unlocked Holder61.3%

Top-3 Unlocked84.1%

What Raised This Score

10 factors

Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
Proxy contract (upgradeable — admin can replace logic)
OZ ProxyAdmin -> Admin is unclassified contract
Top-10 concentration > 50% (82.2% total → 65.4% effective; 54.2% in EOAs, 28.0% in contracts — heavy)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 61.3% (independent LP — depth risk, pool = 40% of DEX liquidity)
LP top3 unlocked holders = 84.1% (independent LP — depth risk, pool = 40% of DEX liquidity)
2 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

2 High 1 Medium 1 Low

H-01HighUnresolved

Unverified Implementation Contract

The implementation contract at address `0xa0f7218896821b5d87e15dd8c554e9f01fa31296` is not verified on Etherscan. This prevents any security analysis of the actual business logic that the proxy delegates to. Without verified source code, it is impossible to ascertain the contract's functionality, identify vulnerabilities, or confirm its intended behavior, posing a critical trust and security risk.

Recommendation: Immediately verify the source code of the implementation contract on Etherscan. This is crucial for transparency, allowing users and auditors to understand and trust the underlying logic. Conduct a thorough audit of the implementation contract once its source code is available.

H-02HighUnresolved

Centralized Upgrade Authority and Unknown Admin Setup

The proxy's upgradeability and administrative functions are controlled by a single admin address. The prefill data indicates that the `admin_address` and `admin_kind` are null, suggesting the admin's security setup is not clearly identified or is not a standard `ProxyAdmin` contract. If this admin key is an Externally Owned Account (EOA) and is compromised, an attacker could upgrade the contract to a malicious implementation, leading to a complete loss of funds or control over the protocol.

Recommendation: Secure the admin key using a robust mechanism such as a multi-signature wallet (e.g., Gnosis Safe) or deploy a dedicated `ProxyAdmin` contract to manage the proxy. Ensure the admin address is publicly known and its security setup is transparent. Implement strict operational procedures for managing the admin key and executing upgrades.

M-01MediumUnresolved

Potential for Malicious or Buggy Upgrades

The upgradeability feature allows the contract's logic to be changed at any time by the admin. While this offers flexibility, it also introduces the risk that a new implementation could contain critical bugs, introduce backdoors, or deviate from expected functionality. This risk is exacerbated by the current unverified implementation, making it impossible to assess the baseline security.

Recommendation: Establish a rigorous upgrade process that includes comprehensive testing, independent security audits, and a public review period for all new implementation versions before they are deployed. Consider implementing a timelock for upgrades to provide users with a window to react to potentially malicious changes. Ensure all new implementations are thoroughly verified on Etherscan.

L-01LowUnresolved

Admin Cannot Directly Call Implementation Functions

The Transparent Proxy pattern explicitly prevents the admin address from directly calling functions on the implementation contract via the proxy's fallback function. This is a security feature to prevent selector clashes with proxy admin functions. However, it can lead to unexpected errors or confusion if the admin attempts to interact with the implementation directly through the proxy, requiring them to use a non-admin account or a `ProxyAdmin` contract.

Recommendation: Ensure all administrators are fully aware of the Transparent Proxy pattern's behavior, specifically that they cannot call implementation functions directly through the proxy. If direct interaction with the implementation is required for administrative tasks, it should be done via a non-admin account or through a dedicated `ProxyAdmin` contract, which is designed to manage the proxy.

Is ViciCoin Safe? VCNT