Audit name:
[SCA] Vancelian | Vance Token | Sep2024
Date:
Oct 17, 2024
Table of Content
Introduction
We express our gratitude to the Vancelian team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Vancelian aims to migrate their old Aktio ERC tokens to the newly introduced VNC ERC20 tokens.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Vancelian |
| Audited By | Aniruddha Dhumal, Adam Idarrha |
| Approved By | Yves Toiser |
| Website | https://www.vancelian.com→ |
| Changelog | 07/10/2024 - Preliminary Report |
| 10/10/2024 - Final Report | |
| Platform | Ethereum |
| Language | Solidity |
| Tags | Fungible Token, Proxy, Upgradable |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Vancelian
- Audited By
- Aniruddha Dhumal, Adam Idarrha
- Approved By
- Yves Toiser
- Website
- https://www.vancelian.com→
- Changelog
- 07/10/2024 - Preliminary Report
- 10/10/2024 - Final Report
- Platform
- Ethereum
- Language
- Solidity
- Tags
- Fungible Token, Proxy, Upgradable
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://bitbucket.org/automatateam/vance-token/src/develop/→ |
| Commit | 3ea92a5 |
Review Scope
- Commit
- 3ea92a5
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements were not provided.
Technical requirements were not provided.
Code quality
The code follows the Solidity Style Guide.
The code does follow best practices for readability & gas efficiency.
The development environment is configured.
Test coverage
Code coverage of the project is 100 % (branch coverage).
Comprehensive tests were provided which covered 100% of the branches.
System Overview
Vancelian is a migration protocol which migrates Aktio ERC20 tokens to Vance ERC20 tokens with the following contracts:
VNCToken — UUPS upgradable ERC-20 token designed to mint its entire initial supply to the contract owner upon deployment. No additional minting is allowed after this point. VNCToken incorporates multiple key features, including burnability, pausability, voting rights, and permit functionality. It is developed to replace the Aktio token following company rebranding.
It has the following attributes:
Name: Vancelian Native Coin
Symbol: VNC
Decimals: 18
Total supply: 100 million.
AktioToVNCMigrator — UUPS upgradable contract facilitating the migration of Aktio tokens to VNC tokens at a 1:1 ratio. This contract allows holders to seamlessly exchange their tokens as part of the transition from Aktio to VNC.
Privileged roles
The owner of both the VNCToken and AktioToVNCMigrator contracts holds the authority to pause and unpause the contracts at any time. Additionally, they can upgrade the contract implementations as necessary.
Potential Risks
The AktioToVNCMigrator contract lacks a mechanism to withdraw VNC tokens after they're transferred to the contract, risking the tokens becoming permanently stuck.
Upgradeable contracts typically rely on an upgrade mechanism controlled by one or more addresses, introducing centralization and potentially creating single points of failure or trust.
The contract mints the entire token supply to the deployer upon deployment, creating a significant centralization risk. This concentration of tokens in a single address gives the deployer disproportionate control over the token's distribution and potentially the protocol's governance.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-6402 | Denial of Service of migration of Aktio tokens | fixed | High | |
| F-2024-6406 | Public Functions That Should Be External | fixed | Observation | |
| F-2024-6400 | Floating Pragma | fixed | Observation | |
| F-2024-6399 | Use Ownable2StepUpgradeable instead of than OwnableUpgradeable | fixed | Observation |
Appendix 1. Definitions
Severities
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity | Description |
|---|---|
Critical | Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation. |
High | High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation. |
Medium | Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category. |
Low | Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution. |
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.
Potential Risks
The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://bitbucket.org/automatateam/vance-token/src/develop→ |
| Commit | 3ea92a5751a09bb3f7d783ba29e495e1befb4244 |
| Whitepaper | n/a |
| Requirements | n/a |
| Technical Requirements | n/a |
Scope Details
- Commit
- 3ea92a5751a09bb3f7d783ba29e495e1befb4244
- Whitepaper
- n/a
- Requirements
- n/a
- Technical Requirements
- n/a
Assets in Scope
Appendix 3. Additional Valuables
Verification of System Invariants
During the audit of Vancelian, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Foundry, a tool used for fuzz-testing, was employed to check how the protocol behaves under various inputs. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use fuzz-testing to ensure that several system invariants hold true in all situations.
Fuzz-testing allows the input of many random data points into the system, helping to identify issues that regular testing might miss. A specific foundry fuzzing suite was prepared for this task, and throughout the assessment, 2 invariants were tested over 100 000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.
Invariant | Test Result | Run Count |
|---|---|---|
Aktio total supply should always be equal to the initial supply: AKTIO.totalSupply() = = INITIAL_AKTIO_SUPPLY | Failed | 100 000 |
The number of Aktio tokens migrated should always be less or equal than the initial supply: totalAktioMigrated <= INITIAL_AKTIO_SUPPLY | Passed | 100 000 |
Invariant
- Aktio total supply should always be equal to the initial supply:
AKTIO.totalSupply() = = INITIAL_AKTIO_SUPPLY Test Result
- Failed
Run Count
- 100 000
Invariant
- The number of Aktio tokens migrated should always be less or equal than the initial supply:
totalAktioMigrated <= INITIAL_AKTIO_SUPPLY Test Result
- Passed
Run Count
- 100 000
Additional Recommendations
The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.
To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:
Detecting changes to ownership or critical permissions.
Monitoring large or unexpected transactions and minting events.
Pausing operations when irregularities are identified.
These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.