- Hacken
- Audits
- metasoilverse
- [SCA] MetaSoilVerse | MSVP | Sep2025
Introduction
We express our gratitude to the MetaSoilVerse team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
The MSVP is an ERC20 token standard with a built-in vesting mechanism.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for MetaSoilVerse |
| Audited By | David Camps Novi, Khrystyna Tkachuk |
| Approved By | Ivan Bondar |
| Website | https://www.msvprotocol.com/→ |
| Changelog | 09/09/2025 - Preliminary Report |
| 19/09/2025 - Final Report | |
| Platform | BSC |
| Language | Solidity |
| Tags | ERC-20, Fee-On-Transfer, Vesting |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for MetaSoilVerse
- Audited By
- David Camps Novi, Khrystyna Tkachuk
- Approved By
- Ivan Bondar
- Changelog
- 09/09/2025 - Preliminary Report
- 19/09/2025 - Final Report
- Platform
- BSC
- Language
- Solidity
- Tags
- ERC-20, Fee-On-Transfer, Vesting
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/msvprotocol/msvptoken→ |
| Initial Commit | 8d6e427 |
| Final Commit | b0ae3e5 |
Review Scope
- Initial Commit
- 8d6e427
- Final Commit
- b0ae3e5
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are sufficient
Technical description is provided.
Code quality
The development environment is configured.
Test coverage
Code coverage of the project is 72.12% (branch coverage).
Deployment and basic user interactions are covered with tests.
System Overview
The MSVP protocol is an advanced ERC20 token implementation with the MSVP.sol contract that integrates comprehensive vesting mechanics directly into the token logic, ensuring that locked tokens are visible in user balances but remain non-transferable until unlocked according to a precise tokenomics schedule. The contract enforces a multi-phase vesting process, including a cliff period and periodic unlocks, to support long-term distribution and incentivization strategies.
It has the following attributes:
Name: MetaSoilVerseProtocol
Symbol: MSVP
Decimals: 18
Total supply: 100 bilion tokens.
The token implements a transfer tax that is allocated to liquidity provision, development, marketing, and token burning of the remainder. The contract enforces configurable max transfer amount thresholds to mitigate large sell-offs, while allowing designated addresses to be excluded from these restrictions. Vesting schedules can be modified, deactivated, or canceled by the contract owner, with additional mechanisms for early release and emergency unlocks.
Privileged roles
Owner– the primary authority of the contract with full administrative control. It is responsible for managing the overall configuration and security of the system. The Owner can grant or revoke the SUBADMIN_ROLE, perform emergency actions such as unlocking all vesting schedules or pausing the protocol, and adjust vesting schedules (modification, deactivation, reactivation, or cancellation). The Owner also manages tokenomics parameters, including tax rates (transfer tax that distributes across liquidity, development, marketing, burn), and designated wallets. Additionally, the Owner has control over maximum transaction limits, tax exclusions, airdrop status, and batch updates of unlocked amounts. To ensure decentralization and reduce reliance on a single entity, the Owner has the ability to permanently renounce control by burning admin rights.SUBADMIN_ROLE– main responsibility is to create new vesting schedules for participants.
Potential Risks
At contract deployment, the entire token supply is minted directly to the contract owner. This creates a centralization risk, as the owner initially holds full control over the distribution of all tokens.
The contract owner has the ability to pause all token transfers, introducing a centralization risk as users must trust the owner not to misuse this power to arbitrarily restrict transfers or freeze the token’s functionality.
The updateUnlockedAmounts() function iterates over the entire participants array, which may cause the transaction to consume excessive gas; if the array becomes very large, execution could exceed the block gas limit, making the function unusable and preventing updates from being processed.
The contract allows the owner to update the transfer tax rate and its distribution percentages (LP contribution, development, marketing, and burn) at any time, even after users have already engaged with the token; although each rate is bounded by constraints, this introduces a centralization and trust risk since users are exposed to changing economic conditions that may alter their expected costs or benefits when interacting with the token.
The contract allows the owner to update the maximum transaction amount with the sole restriction that it must be greater than zero. This grants the owner the ability to set the limit to an arbitrarily low value, which could effectively prevent regular token transfers from occurring.
The contract allows the owner to renounce ownership through the burnAdminRights() function, which would make all owner-restricted functions permanently inaccessible. While this can be intentional, it introduces a risk that critical administrative operations—such as updating tax rates, contribution rates, or transaction limits—can no longer be performed, potentially leaving the system in an uncontrolled or unmanageable state.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-1272 | Unburned Remaining Tax Accumulates in the Contract Without Withdrawal Mechanism | fixed | Medium | |
| F-2025-1272 | Vesting Schedules Can Be Reactivated After Cancellation | fixed | Medium | |
| F-2025-1271 | Truncation in Vesting Calculations may Result in Dust Locked Tokens | fixed | Medium | |
| F-2025-1271 | Tokens are Not Transferred to User When Vesting is Increased | fixed | Medium | |
| F-2025-1270 | Owner Rights Can Be Burned While Contract Is Paused Permanently Locking Transfers | fixed | Medium | |
| F-2025-1306 | Admin Functions Can Only Modify the Latest Vesting Schedule | fixed | Low | |
| F-2025-1305 | Reactivation Ignores Active Vesting Locks which may Block Token Transfers | fixed | Low | |
| F-2025-1277 | Vesting Reactivation may Block Token Transfers | fixed | Low | |
| F-2025-1272 | Vesting Modification Uses Stale Unlocked Vested Amount | fixed | Low | |
| F-2025-1265 | Vesting Allocation Does Not Account for Transfer Tax Causing Tokens to Remain Non-Transferable During Vesting Period | fixed | Low |
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://github.com/msvprotocol/msvptoken→ |
| Initial Commit | 8d6e427 |
| Final Commit | b0ae3e5 |
| Whitepaper | N/A |
| Requirements | ./README.md |
| Technical Requirements | ./README.md |
Scope Details
- Initial Commit
- 8d6e427
- Final Commit
- b0ae3e5
- Whitepaper
- N/A
- Requirements
- ./README.md
- Technical Requirements
- ./README.md
Assets in Scope
Appendix 3. Additional Valuables
Verification of System Invariants
During the audit of Metasoilverse, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Foundy →, a tool used for 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, 5 invariants were tested over 500,000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.
Invariant | Test Result | Run Count |
|---|---|---|
| Vesting position is successfully created for any user and amount | Passed | 100k |
| Vesting position is successfully increased for any user and amount | Passed | 100k |
| Vesting position cannot be modified after end time, regardless of user and amount | Passed | 100k |
| Vesting position is successfully created for any user and amount after ending the previous position | Passed | 100k |
| Token transfer is successfully executed regardless of amount, sender and receiver | Passed | 100k |
Invariant
- Vesting position is successfully created for any user and amount
Test Result
- Passed
Run Count
- 100k
Invariant
- Vesting position is successfully increased for any user and amount
Test Result
- Passed
Run Count
- 100k
Invariant
- Vesting position cannot be modified after end time, regardless of user and amount
Test Result
- Passed
Run Count
- 100k
Invariant
- Vesting position is successfully created for any user and amount after ending the previous position
Test Result
- Passed
Run Count
- 100k
Invariant
- Token transfer is successfully executed regardless of amount, sender and receiver
Test Result
- Passed
Run Count
- 100k
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.