Discovery Trending Launches KYC Verified Watchlist Risk Alerts
Token Minter AI Threat Detection Token Burner
Blog & News Docs Visit SolidProof.io

ViWo Info

www.viwoapp.org

ViWo — a revolutionary digital platform proudly created and owned by SmarTech LLC, a USA-verified technology innovator with over 17 years of excellence. ViWo fuses social media, decentralized marketplaces, and blockchain technology into one seamless ecosystem. Powered by V-Coin, ViWo lets users monetize content, trade digital and physical products, and grow their wealth — all with zero transaction fees. With eco-friendly initiatives and immersive Augmented Reality (AR) integration, ViWo is built for the future.

ViWo Logo
Onboarded date 14/03/2025

Team and KYC Verification

The team has securely submitted their personal information to SolidProof.io for verification.

In the event of any fraudulent activities, this information will be promptly reported to the relevant authorities to ensure accountability and compliance.

TrustNet Score

The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.

99.90
Poor Excellent

Real-Time Threat Detection

Real-time threat detection, powered by Cyvers.io, is currently not activated for this project.

This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks. For more information, click here.

Security Assessments

Select the audit
"Static Analysis Dynamic Analysis Symbolic Execution SWC Check Manual Review"
Contract address
N/A
Network N/A
License N/A
Compiler N/A
Type N/A
Language Rust / Solana
Onboard date 2025/03/26
Revision date In progress

Summary and Final Words

No crucial issues found

The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.

Contract owner cannot mint

It is not possible to mint new tokens.

Contract owner cannot blacklist addresses.

It is not possible to lock user funds by blacklisting addresses.

Contract owner cannot set high fees

The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.

Contract cannot be locked

Owner cannot lock any user funds.

Token cannot be burned

There is no burning within the contract without any allowances

Ownership is not renounced

Contract can be manipulated by owner functions.

Contract is upgradeable

The contract uses a proxy pattern or similar mechanism, enabling future upgrades. This can introduce risks if the upgrade mechanism is not securely managed.

Scope of Work

This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.

The auditing process consists of the following systematic steps:

  1. Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
  2. Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
  3. Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
  4. Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
  5. Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
  6. Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
  7. Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.

A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.

Final Words

The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.

Contract Analysis

The VCoin token contract implements a Solana Program using the Token-2022 standard with additional features for presale management, vesting, and autonomous supply control. Our comprehensive review has confirmed that the contract has addressed all critical vulnerabilities identified in previous audits and now follows best practices for Solana program development.

  • Oracle data validation has been significantly enhanced with proper verification of data sources, account ownership, and freshness checks.
  • Token burning operations now include proper authorization controls with verification of account ownership and secure PDA derivation.
  • Presale account management has been redesigned with dynamic allocation and safe expansion capabilities.
  • Integer operations throughout the codebase now use checked arithmetic to prevent overflow/underflow vulnerabilities.
  • The contract correctly reads and utilizes the actual decimals from the mint account for all calculations.
  • Presale features include robust refund mechanisms with appropriate time-bounded withdrawal periods.
  • Reentrancy protection has been implemented to prevent potential attack vectors.
  • Transfer fee validation ensures fees cannot exceed safe thresholds, protecting users.
Ownership Privileges

The authority of the contract retains necessary privileged functions with appropriate controls:

  • Initializing the token with custom name, symbol, and initial supply with proper validation.
  • Setting and modifying transfer fees with strict caps to protect users.
  • Creating and managing presale parameters including start/end times and pricing with validation.
  • Managing presale lifecycles with safeguards for participants.
  • Initializing vesting schedules and adding beneficiaries with duplicate detection.
  • Releasing tokens according to vesting schedules with proper verification.
  • Updating token metadata including name, symbol, and URI.
  • Initializing the autonomous controller with transparent economic parameters.
  • Access to oracle price update functionality with thorough validation protections.
Additional Recommendations

While the contract has achieved a high security standard, we recommend considering these further enhancements:

  • Consider implementing transaction ordering protection using sequence numbers or nonces.
  • Evaluate adding an emergency circuit breaker for critical operations during anomalies.
  • Consider transitioning to a multi-signature governance model for administrative functions.
  • Explore more robust price validation through time-weighted averages and multi-oracle consensus.

Note - This Audit report consists of a security analysis of the VCoin Solana Program. This analysis did not include functional testing (or unit testing) of the program's logic. Moreover, we only audited the main token contract for the VCoin team. Other programs associated with the project were not audited by our team. We recommend investors do their own research before investing.

Files and details

Functions
public

/

State variables
public

/

Total lines
of code

/

Capabilities
Hover on items

/

Functions
public

/

State variables
public

/

Total lines
of code

/

Capabilities
Hover on items

/

Functions
public

/

State variables
public

/

Total lines
of code

/

Capabilities
Hover on items

/

Functions
public

/

State variables
public

/

Total lines
of code

/

Capabilities
Hover on items

/

Functions
public

/

State variables
public

/

Total lines
of code

/

Capabilities
Hover on items

/

Functions
public

/

State variables
public

/

Total lines
of code

/

Capabilities
Hover on items

/

Findings and Audit result

Critical
High
Medium
Low
Optimization
Informational
critical Issues | 3 findings

Resolved

#1 critical Issue
Uncapped Transfer Fee
processor.rs
L874-914
Description

The process_set_transfer_fee function allows setting transfer fees without upper limits

Comments

Implement maximum fee cap (e.g., 25%)

Resolved

#2 critical Issue
Insufficient Oracle Data Validation
processor.rs
L1223-1299
Description

The process_update_oracle_price() function reads 8 raw bytes directly from the oracle account's data without verifying the oracle account's program owner, data structure, or format. While the controller account ownership is verified, the oracle account itself lacks comprehensive validation. The code also assumes the data is at least 8 bytes without checking, potentially causing out-of-bounds access.

Comments

Enhance oracle security by verifying account ownership against trusted providers (Pyth/Switchboard), using proper data structure parsing, validating confidence metrics, implementing data size checks, and utilizing specialized oracle client libraries for robust integration.

Resolved

#3 critical Issue
Unrestricted Token Burning
processor.rs
L1420-1538
Description

The process_execute_autonomous_burn() function can burn tokens from any provided account as long as the controller's conditions for burning are met. There's no verification that the burn source account is owned by the program or has consented to having its tokens burned, allowing potential unauthorized burning of user tokens.

Comments

For burn authorization, establish strict controls through designated program-controlled treasury accounts, opt-in burn pools, verification of burn sources via PDA derivation, and mandatory owner signatures for any token burning that affects user accounts.

high Issues | 4 findings

Resolved

#1 high Issue
Hardcoded Initial Transfer Fee
processor.rs
L240
Description

5% (500 basis points) transfer fee is hardcoded during token initialization

Comments

Make initial fee configurable or set to zero by default

Resolved

#2 high Issue
Fixed Buyer Allocation Limit
state.rs
L53
Description

The PresaleState struct allocates fixed space for exactly 100 buyers in the buyer_pubkeys vector, with no mechanism to handle more participants. If the presale becomes popular and exceeds 100 buyers, subsequent purchases will fail or potentially corrupt memory, as the code continues to push to the vector without checking its capacity.

Comments

Either implement a dynamic allocation system with chunked storage, use pagination for buyer records, or add explicit capacity checking that prevents new buyers when the limit is reached. If maintaining a fixed limit, add a clear check before adding new buyers and return a specific error (e.g., BuyerLimitReached) when the limit is approached.

Resolved

#3 high Issue
Potential Integer Overflow
state.rs
L187
Description

Several critical calculations in the autonomous supply controller don't consistently use checked arithmetic operations. For example, price growth calculation and certain supply adjustments use direct multiplication and division that could overflow or underflow, leading to incorrect algorithmic decisions about token supply changes.

Comments

Replace all unchecked arithmetic with the Rust checked_* operations (checked_mul, checked_div, checked_add, checked_sub) consistently throughout the codebase. Propagate errors properly when operations would overflow instead of producing incorrect results. Consider adding guard clauses for mathematical edge cases, particularly division by zero possibilities.

Resolved

#4 high Issue
Assumed Token Decimals
processor.rs
L607
Description

The contract assumes tokens have 9 decimals in several calculations, particularly in the process_buy_tokens() function, without ever verifying the actual decimals configuration of the mint. If a mint with different decimals is used, all price calculations, supply adjustments, and token distribution will be mathematically incorrect.

Comments

Remove hardcoded decimal assumptions and instead read the actual decimals from the mint account in all relevant functions. Cache this value where appropriate to avoid repeated reads. Update all calculations to dynamically use the correct power of 10 based on the actual mint decimals. Add validation to ensure only mints with supported decimal configurations can be used with the contract.

medium Issues | 6 findings

Resolved

#1 medium Issue
Inaccurate Buyer Count
processor.rs
L555
Description

num_buyers always increments regardless if buyer has previously participated

Comments

Track unique buyers

Resolved

#2 medium Issue
No Duplicate Beneficiary Protection
processor.rs
L634-692
Description

process_add_vesting_beneficiary doesn't check for existing beneficiaries

Comments

Add duplicate checks

Resolved

#3 medium Issue
Non-functional Account Existence Check
processor.rs
L695-967
Description

The function always returns false

Comments

Implement proper check using AccountInfo::try_borrow_data

Alleviation

The non-functional account existence check is a current workaround that always creates new token accounts instead of properly checking for existing ones. While this approach prevents errors by ensuring accounts exist, it's inefficient and potentially wastes resources. This implementation must be replaced with proper account existence verification using Solana's Account::try_from or similar runtime checks before mainnet deployment. The current implementation is acceptable for testing but not production-ready.

Resolved

#4 medium Issue
Hardcoded Soft Cap Override
processor.rs
L458
Description

In process_initialize_presale(), the user-provided soft_cap parameter is completely disregarded and replaced with a hardcoded value of 1,000,000,000,000 (1M USD with 6 decimals). This undermines parameter validation and creates inconsistent behavior where the function appears to accept a parameter but actually ignores it.

Comments

Remove the hardcoded override and use the user-provided parameter directly after proper validation. If there's a minimum acceptable soft cap, implement explicit validation checks and return an error if the user-provided value is below this threshold rather than silently overriding it.

Resolved

#5 medium Issue
Lenient Oracle Staleness Check
processor.rs
L1347-1350
L1465-1468
Description

The program considers oracle price data fresh as long as it's less than 7 days old (604800 seconds). This extended window is dangerous for price-sensitive operations like minting and burning, which should rely on recent market data to make accurate decisions. During volatile market conditions, using week-old price data could lead to significant economic distortions.

Comments

Reduce the maximum staleness threshold to a more appropriate timeframe based on market volatility - no more than 24 hours for normal operations and potentially even shorter (1-4 hours) for high-value operations. Implement tiered freshness requirements where critical price-dependent operations require more recent data than informational queries. Consider adding a price confidence interval check as well.

Resolved

#6 medium Issue
Silent Arithmetic Saturation in Critical Calculations
processor.rs
LMultiple
Description

In price change calculations, the code uses saturating_* operations which silently cap at maximum values rather than reporting errors. This could hide extreme price movements and lead to incorrect economic decisions.

Comments

For critical price calculations, replace saturating operations with explicit overflow/underflow checks that return errors in extreme cases. Use checked_* operations followed by explicit error handling for price calculations.

low Issues | 1 findings

Resolved

#1 low Issue
Incomplete Presale Parameter Validation
processor.rs
L347-418
Description

No validation that soft_cap > 0

Comments

Add validation

informational Issues | 1 findings

Resolved

#1 informational Issue
No Presale Refund Mechanism
processor.rs
-
Description

The presale implementation lacks a refund mechanism for participants if the presale fails to meet its soft cap. Once users send funds to the treasury, there's no programmatic way to return those funds if the presale is unsuccessful, potentially leading to permanent fund loss for early participants.

Comments

Our recommendation would be either: Implement a two-phase presale with: 1) A collection phase where funds are held in an escrow account, 2) A finalization phase that either releases tokens and transfers funds to the treasury (if successful) or enables refunds (if unsuccessful). Additionally, provide a time-bound refund function that participants can call to recover their funds if the soft cap isn't met.