Vortex FX Info
VFX Token’s mission is to bridge traditional and decentralized finance through real-world assets, giving investors powerful access to yield. Built by traders for traders, Vortex FX empowers this vision with top-tier spreads, execution, and service.
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.
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.
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 renounced
The contract does not include owner functions that allow post-deployment modifications.
Contract is not upgradeable
The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.
Scope of Work
This audit encompasses the evaluation of the ABT Presale smart contract codebase as provided at the start of this engagement. The assessment was conducted on the complete Solana program structure, including instruction handlers, state management, error handling, and deployment configuration built with Anchor framework v0.31.1.
The auditing process consists of the following systematic steps:
- Architecture and Specification Review: Analyze the project's program structure, dependencies (Cargo.toml, Anchor.toml), instruction handlers, and state definitions to understand the overall smart contract architecture, presale mechanism design, and intended DeFi functionality including token sales, vesting, and whitelist management.
- Static Code Analysis: Conduct comprehensive automated analysis using Rust Clippy, cargo compilation checks, and manual code inspection to identify potential security vulnerabilities, mathematical flaws, unsafe operations, and Solana-specific security anti-patterns across 942 lines of Rust code.
- Access Control and Authority Validation: Systematically review all instruction handlers for proper authority validation, account ownership verification, and privilege escalation vulnerabilities, with particular focus on commented-out security constraints and missing authorization checks.
- Mathematical Security Assessment: Analyze all arithmetic operations for integer overflow/underflow vulnerabilities, precision loss in financial calculations, and unsafe type casting, ensuring mathematical operations meet DeFi security standards for handling user funds.
- Solana-Specific Security Patterns: Evaluate the contract against Solana and Anchor framework security best practices, including proper Cross-Program Invocation (CPI) handling, rent exemption validation, account serialization safety, and checks-effects-interactions pattern compliance.
- Business Logic and Economic Security: Assess the presale mechanism for economic vulnerabilities, including parameter validation, whitelist bypass attempts, vesting calculation accuracy, and potential attack vectors that could compromise the token sale integrity or user funds.
- Input Validation and Error Handling: Review all user input processing, parameter validation, error propagation patterns, and panic conditions to identify potential denial-of-service vectors and ensure robust error handling throughout the contract lifecycle.
- Code Quality and Maintainability Assessment: Evaluate code documentation, style consistency, unused imports, deprecated API usage, and overall code quality factors that could impact long-term security maintenance and development practices.
- Deployment Security Review: Analyze deployment configuration, hardcoded development keys, environment separation, and upgrade mechanisms to ensure secure production deployment practices.
- Comprehensive Risk Classification: Categorize all findings by severity (Critical, High, Medium, Low) based on potential impact to user funds, protocol integrity, and operational security, providing detailed exploitation scenarios and remediation guidance.
This audit reflects the state of the smart contract codebase at a specific point in time and deployment configuration. Any modifications made to the contract code, deployment parameters, or underlying Anchor framework after this review may introduce new conditions or vulnerabilities that were not within the scope of this assessment. All findings must be addressed and re-tested before production deployment.
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.
This security re-audit of the ABT Presale smart contract focused on evaluating the updated Solana-based token presale platform built with Anchor framework. The assessment verified remediation of previously identified vulnerabilities and conducted comprehensive analysis for new security issues in access control, mathematical operations, input validation, and contract security patterns. The goal was to confirm that risks impacting user funds, protocol integrity, and operational security have been adequately addressed.
The contract is designed for token presales with configurable parameters including whitelisting via Merkle proofs, vesting schedules, and time-based restrictions. The development team has made substantial security improvements, successfully resolving most critical and high-severity vulnerabilities from the initial audit. The current assessment reveals that many previously reported issues were false positives, with the actual codebase containing proper security implementations.
Technical Summary
- Authority Validation: Successfully resolved. All critical instruction handlers properly implement
has_one = authorityconstraints, securing privileged operations in update_raise.rs, update_wl.rs, and return_token.rs. Administrative functions are properly protected against unauthorized access. - Mathematical Vulnerabilities: Successfully resolved. The contract implements comprehensive checked arithmetic operations (checked_add, checked_mul, checked_div) throughout all financial calculations. Price calculation logic in buy_token.rs uses u128 intermediate values with proper overflow protection, preventing integer overflow exploits.
- Whitelist Security: Successfully resolved. Merkle proof verification uses proper error handling with
ok_or()instead of unsafeunwrap()operations, eliminating program panics and potential whitelist bypass vulnerabilities. - Division by Zero Protection: Successfully implemented. The claim_token.rs handler properly checks for zero vesting_duration with conditional logic, preventing runtime panics.
- Development Key Usage: Acknowledged design choice. The hardcoded DEV_PUBKEY in constants.rs serves administrative functions restricted to the development team. While functional, implementing configurable authority management would enhance security practices.
- Event System: Successfully implemented. Comprehensive event emissions are in place for all major operations, enabling proper monitoring and debugging capabilities.
- Error Handling: Successfully standardized. Consistent use of
require!macros and proper error propagation patterns throughout the codebase. - Code Quality Issues: Partially addressed. Minor Clippy warnings remain unresolved, and comprehensive TSDoc documentation is still needed across all modules.
Note: This re-audit confirms that the contract has undergone significant security improvements with most critical vulnerabilities properly resolved. Many previously reported issues were false positives, and the current implementation demonstrates good security practices. The remaining findings are primarily edge cases and code quality improvements rather than fundamental security flaws. The contract is substantially more secure than the initial version and approaches production readiness with the identified improvements.
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
/
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
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Findings and Audit result
critical Issues | 5 findings
Resolved
#1 critical Issue
Missing Authority Validation in Multiple Instructions
Multiple critical instruction handlers have their authority validation constraints properly implemented to ensure only authorized users can execute privileged operations.
Resolved
#2 critical Issue
Integer Overflow in Price Calculation
The buy_token instruction now properly handles price calculations using checked arithmetic operations to prevent integer overflow vulnerabilities.
Resolved
#3 critical Issue
Merkle Proof Bypass Vulnerability
The merkle proof verification logic now properly handles errors without using unsafe unwrap() operations.
Resolved
#4 critical Issue
Unsafe Unwrap Operations in Merkle Proof Verification
Unsafe unwrap() operations in merkle proof verification have been replaced with safe error handling.
Resolved
#5 critical Issue
Missing Validation in Update Functions
The update_raise function lacks validation for price_per_token > 0 when updating, which could allow setting the price to zero and enabling free token distribution.
high Issues | 3 findings
Resolved
#1 high Issue
Insufficient Input Validation in Create Raise
The create_raise instruction handler lacks comprehensive validation for critical presale parameters, allowing the creation of economically invalid or exploitable presale configurations. Missing validation checks permit setting price_per_token to zero (enabling free token distribution), creating presales with invalid sale supplies, or setting start times in the past or with invalid durations.
Resolved
#2 high Issue
Missing Safe Arithmetic Operations
Comprehensive static analysis revealed a complete absence of checked arithmetic operations (checked_add, checked_mul, checked_div) throughout the entire codebase, particularly in critical financial calculations involving token amounts, prices, and user balances.
Resolved
#3 high Issue
TGE Unlock Percentage Validation Missing
No validation exists to ensure that tge_unlock_percent does not exceed 100%, which could allow more than 100% immediate token unlock, breaking the vesting mechanism and economic model of the presale.
medium Issues | 3 findings
Resolved
#1 medium Issue
Precision Loss in Vesting Calculations
The vesting calculation logic in claim_token.rs uses floating-point arithmetic to determine the proportion of tokens available for claiming, which introduces precision loss and rounding errors in financial calculations.
Resolved
#2 medium Issue
Missing Maximum Supply Validation in Updates
When updating sale supply in update_raise, there is no validation against MAX_TOKEN_SUPPLY constant, potentially allowing unreasonably high token supplies to be set.
Resolved
#3 medium Issue
Potential Division by Zero
If vesting_duration is set to 0, the division operation in vesting calculations could cause a runtime panic, leading to denial of service.
low Issues | 2 findings
Resolved
#1 low Issue
Inconsistent Error Handling
The codebase exhibits inconsistent error handling patterns, mixing require! macros with manual error returns throughout different instruction handlers. This inconsistency creates unpredictable error behavior, makes debugging more difficult, and can lead to different error messages for similar validation failures. The lack of a standardized error handling approach means some errors may not be properly propagated or logged, potentially masking critical issues and making it harder to diagnose problems in production environments.
Resolved
#2 low Issue
Inconsistent Min Buy Amount Logic
The minimum buy amount validation logic has inconsistent behavior that could allow users to bypass minimum purchase requirements under certain conditions.
informational Issues | 2 findings
Resolved
#1 informational Issue
Missing Event Emissions
Event emissions have been added to all instruction handlers to enable proper monitoring of contract activities and state changes.
Acknowledged
#2 informational Issue
Hardcoded Development Key in Production
A development public key (DEV_PUBKEY) is hardcoded in constants.rs and used for set_params validation. While this is intentional for administrative control, it represents a centralized point of control that could be improved with a more flexible authority management system.