- Hacken
- Audits
- messiah-network
- [SCA] Messiah Network | Messiah-Token | Jul2025
Introduction
We express our gratitude to the Messiah Network team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
The Messiah project consists of two smart contracts. The fist is an ERC20 token that incorporates advanced anti-bot and anti-whale protections, dynamic tax mechanics, and Uniswap integration. The second is a Vesting contract that governs token distribution, enabling precise, multi-token vesting schedules for multiple beneficiaries with linear vesting and administrative controls.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Messiah Network |
| Audited By | Viktor Lavrenenko, Panagiotis Konstantinidis |
| Approved By | Ataberk Yavuzer |
| Website | https://www.messiah.network/→ |
| Changelog | 04/07/2025 - Preliminary Report |
| 15/07/2025 - Final Report | |
| Platform | Ethereum |
| Language | Solidity |
| Tags | ERC-20, Fungible Token, Vesting, Swaps |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Messiah Network
- Audited By
- Viktor Lavrenenko, Panagiotis Konstantinidis
- Approved By
- Ataberk Yavuzer
- Changelog
- 04/07/2025 - Preliminary Report
- 15/07/2025 - Final Report
- Platform
- Ethereum
- Language
- Solidity
- Tags
- ERC-20, Fungible Token, Vesting, Swaps
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/Messiah-Network/messiah-token→ |
| Initial Commit | ce808b887975a03798b8a27e55a6ac151db49005 |
| Remediation Commit | abe7c167726c54be9c4db0ca06717767abc53911 |
Review Scope
- Initial Commit
- ce808b887975a03798b8a27e55a6ac151db49005
- Remediation Commit
- abe7c167726c54be9c4db0ca06717767abc53911
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are partially missed:
The purpose of the contracts in scope is not described in the documentation.
Business logic and NatSpec comments are provided.
Use cases are provided.
Project's features are described.
Technical description is not provided:
Key function's descriptions are missing.
No information on used technologies provided.
The architectural overview is missing.
Code quality
The code duplicates commonly known contracts instead of reusing them.
Several template code patterns were found.
The development environment is configured.
Test coverage
Code coverage of the project is 71.95 % (branch coverage):
Deployment and basic user interactions are covered with tests.
Negative cases coverage is partially missed.
Interactions by several users are not tested thoroughly.
System Overview
Messiah-Token is a decentralized protocol with the following contracts:
Messiah - ERC-20 token with advanced trading features, anti-bot mechanisms, and fee collection system that mints all initial supply to a deployer. Additional minting is not allowed.
It has the following attributes:
Name: Messiah
Symbol: MSIA
Decimals: 18
Total supply: 100000000 * 1e18.
MultiBeneficiaryVestingWallet - a vesting contract that manages token distribution schedules for multiple beneficiaries and multiple tokens.
Privileged roles
The owner of the
Messiahcan:transfer ownership to another address via the
transferOwnership()function.activate trading and enable token swapping via the
enableTrading()function.remove transaction and wallet limits after token is stable via the
removeLimits()function.permanently disables the transfer delay mechanism via the
disableTransferDelay()function.update the threshold for automatic token swapping via the
updateSwapTokensAtAmount()function.update the maximum transaction amount via the
updateMaxTxnAmount()function.update the maximum wallet size via the
updatemaxWalletsAmount()function.exclude/include addresses from maximum transaction limits via the
excludeFrommaxTx()function.emergency switch to disable contract sales if necessary via the
updateSwapEnabled()function.permanently reduces the maximum possible fee rate via the
ceilMaxFee()function.update the buy fee percentage via the
updateBuyFees()function.update the sell fee percentage
updateSellFees()function.exclude/include addresses from paying fees via the
excludeFromFees()function.set or remove AMM pair addresses via the
setAutomatedMarketMakerPair()function.update the marketing wallet address via the
updateMarketingWallet()function.update the development wallet address via the
updateDevWallet()function.update the address authorized to blacklist accounts via the
setBlacklister()function.permanently remove the blacklisting capability via the
renounceBlacklister()function.
The owner of the
MultiBeneficiaryVestingWalletcan:create or update a vesting schedule for a specific beneficiary and token via the
addVestingSchedule()function.create multiple vesting schedules for different beneficiaries and tokens in a single transaction via the
batchAddVestingSchedule()function.withdraw excess tokens that are not committed to vesting schedules via the
withdrawExcessToken()function.withdraw a specific amount of accidentally sent Ether via the
withdrawEther()function.withdraw all accidentally sent Ether from the contract via the
withdrawAllEther()function.transfer ownership to another address via the
transferOwnership()function.
Potential Risks
The functioning of the system significantly relies on specific external contracts. Any flaws or vulnerabilities in these contracts adversely affect the audited project, potentially leading to security breaches or loss of funds.
The absence of restrictions on state variable modifications by the owner leads to arbitrary changes, affecting contract integrity and user trust, especially during critical operations like trading phases.
The use of broad onlyOwner and onlyBlacklister access control allows a single entity to perform high-impact actions. If these roles are compromised, they could lead to disabling trading restrictions, mismanaging token distribution or misconfigurations.
The contracts allow immediate execution of sensitive changes (e.g., enabling trading, updating fees, setting vesting amounts), with no delay or time-lock mechanism. This increases the risk of unreviewed or rushed changes affecting users.
The lack of multi-signature requirements for key operations centralizes decision-making power, increasing vulnerability to single points of failure or malicious insider actions, potentially leading to unauthorized transactions or configuration changes.
The Messiah contract allows the owner to renounce the blacklister role by calling the renounceBlacklister() function. There is a risk that previously blacklisted users will never be whitelisted if the blacklister role is address(0).
The project's smart contracts are non-upgradable. While this approach enhances immutability, it also limits the ability to patch vulnerabilities, fix bugs, or introduce improvements after deployment. In the event of unintended behavior or security issues, the absence of an upgrade mechanism significantly reduces the available response options, potentially leading to prolonged downtime or the need for a full contract migration.
If the users are not excluded from paying the fees, they might receive drastically smaller amounts of tokens then expected.
If devWallet or marketingWallet are malicious contracts, they could revert ETH transfers, potentially blocking swaps or causing token transfers to fail.
The swapTokensForEth() function does not set minimum tokenOut amount as well as the deadline in the Uniswap swapExactTokensForETHSupportingFeeOnTransferTokens() function. There is a risk that it might affect the output token amount of the swap.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-1149 | Division by Zero in swapBack Triggers DoS and Freezes Sell Functionality | fixed | High | |
| F-2025-1149 | Replayable Signature in enableTradingWithPermit Enables Repeated and Malicious Calls | fixed | Medium | |
| F-2025-1157 | Use of Push Payments in swapBack() Risks Swap Failure | accepted | Low | |
| F-2025-1157 | Incomplete ETH Distribution in manualSwap() Decreases User Experience | fixed | Low | |
| F-2025-1150 | Redundant ETH Balance Calculations in swapBack Reduce Code Clarity and Efficiency | fixed | Low | |
| F-2025-1150 | Transfer Delay Protection Can Be Bypassed via Contract Calls | accepted | Low | |
| F-2025-1148 | Missing Check Allows Owner to Withdraw Vested Tokens Contrary to NatSpec Warning | fixed | Low | |
| F-2025-1148 | Signature Malleability Enables Unauthorized Trading Activation | fixed | Low | |
| F-2025-1155 | Redundant Utility Function min() Leads To Extra Gas Costs | fixed | Observation | |
| F-2025-1151 | Public Functions Not Used Internally Increase Gas Costs | accepted | 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://github.com/hknio/Messiah-Network___messiah-token→ |
| Initial Commit | ce808b887975a03798b8a27e55a6ac151db49005 |
| Remediation Commit | abe7c167726c54be9c4db0ca06717767abc53911 |
| Whitepaper | https://docs.messiah.network/→ |
| Requirements | NatSpec |
| Technical Requirements | NatSpec |
Scope Details
- Initial Commit
- ce808b887975a03798b8a27e55a6ac151db49005
- Remediation Commit
- abe7c167726c54be9c4db0ca06717767abc53911
- Whitepaper
- https://docs.messiah.network/→
- Requirements
- NatSpec
- Technical Requirements
- NatSpec
Assets in Scope
Appendix 3. Additional Valuables
Verification of System Invariants
During the audit of the Messiah-Token, Hacken conducted invariant-based fuzz-testing on the MultiBeneficiaryVestingWallet to evaluate the protocol’s reliability under unpredictable or adversarial conditions. A dedicated Foundry fuzzing suite was developed to simulate thousands of interactions across key functions such as adding vesting schedules, releasing tokens, and executing token or Ether withdrawals. Over 1,000 runs were performed across 4 invariants to ensure that core properties held true consistently. These included checks that released and vested token amounts never exceeded their allocations, Ether operations did not interfere with vesting logic, and overall token conservation was always respected.
Invariant | Test Result | Run Count |
|---|---|---|
| Released ≤ Total: Released tokens per beneficiary never exceed their allocated total. | Passed | 1K+ |
| Vested ≤ Total: Vested amount at any time remains within the allocated total. | Passed | 1k+ |
| Ether Isolation: Ether withdrawals do not alter vesting schedules. | Passed | 1k+ |
| Token Conservation: Released + contract balance never exceeds total supply. | Passed | 1k+ |
Invariant
- Released ≤ Total: Released tokens per beneficiary never exceed their allocated total.
Test Result
- Passed
Run Count
- 1K+
Invariant
- Vested ≤ Total: Vested amount at any time remains within the allocated total.
Test Result
- Passed
Run Count
- 1k+
Invariant
- Ether Isolation: Ether withdrawals do not alter vesting schedules.
Test Result
- Passed
Run Count
- 1k+
Invariant
- Token Conservation: Released + contract balance never exceeds total supply.
Test Result
- Passed
Run Count
- 1k+
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.