Mey Network Info
Mey Network is an integrated blockchain ecosystem designed to bridge the gap between physical assets and the digital world. By combining the power of Meychain—a dedicated Layer 1 blockchain for Real-World Assets (RWAs)—and MeyFi, our decentralized nance platform, Mey Network enables seamless tokenization, trading, and management of assets in a secure, scalable environment.
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.
Security Assessments
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.
Token transfer can be locked
Owner can lock user funds with owner functions.
Ownership is not renounced
The owner retains significant control, which could potentially be used to modify key contract parameters.
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:
- Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
- Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
- Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
- Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
- Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
- Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
- 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.
Ownership Privileges
- The owner can update the stakeRewardToken address.
- The owner can update the fee collector address.
- The owner can change the staking APR to any arbitrary value, including zero.
- The owner can set the locktime period to any arbitrary value.
- The owner can set the stake lock period to any arbitrary value.
- The owner can set the early unstake fees to any arbitrary value.
- The owner can deposit stake reward tokens into the contract.
- The owner can reset the user stakes values.
- The owner can withdraw the staking tokens from the contract.
- The owner can withdraw ETH from the contract.
Note - This Audit report consists of a security analysis of the Mey Network smart contract. This analysis did not include functional testing (or unit testing) of the contract’s logic. Moreover, we only audited the mentioned contract for the Mey Network team. Other contracts 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
/
Findings and Audit result
high Issues | 3 findings
Pending
#1 high Issue
Missing Validations in Critical Parameter-Setting Functions
The contract contains several owner-only functions for configuring critical parameters—setEarlyUnstakeFee, setLockTimePeriod, setStakeLockPeriod, and setStakingAPR—all of which lack necessary input validation. This absence of constraints creates significant centralization risks. An owner can set an earlyUnstakeFee greater than 100%, causing the unstake function to revert for users due to an arithmetic underflow, effectively creating a denial of service. Similarly, the ability to set arbitrarily long lock periods via setLockTimePeriod and setStakeLockPeriod could be exploited to trap user funds indefinitely or force nearly all unstakes to incur penalties. Furthermore, an unvalidated stakingAPR could be set to an unsustainably high level, misleading users and posing an economic risk to the protocol. Collectively, these missing checks allow a malicious or compromised owner to severely disrupt contract functionality and harm users' financial interests.
Pending
#2 high Issue
Centralization Risk Allows Owner to Seize User Funds
The contract contains a highly privileged resetUserStakes function that grants the owner the unilateral power to confiscate any user's entire staked and unstaked token balance. This function operates as a backdoor, allowing the owner to select a user, zero out their stake records within the contract's state, and then transfer the full value of those assets directly to the owner's own address. The existence of this function completely undermines the trustless nature of the protocol, as it means user funds are not secured by immutable code but are instead held at the discretion of the contract owner. This presents a critical risk, as a malicious owner or an attacker who compromises the owner's key can arbitrarily drain any user's funds, leading to a total and permanent loss of assets.
Pending
#3 high Issue
The owner can withdraw the staked tokens.
The contract contains a vulnerability within the withdrawERC20 function, which grants the owner the ability to steal all user-deposited funds. This function incorrectly allows the owner to specify the stakeRewardToken address and withdraw tokens without accounting for the contract's liabilities to its stakers. The function's logic only validates the withdrawal amount against the contract's total balance of that token, ignoring the fact that these tokens are user deposits recorded in the totalStaked variable. This oversight effectively creates a backdoor, enabling a malicious owner or a compromised owner's account to drain the entire pool of staked assets, leading to a complete and permanent loss of funds for all users of the protocol.
medium Issues | 2 findings
Pending
#1 medium Issue
Missing validation for token.
The initialize() and setStakeRewardToken() functions allow setting the stakeRewardToken address. However, neither function validates that the provided address is actually a contract. An externally owned account (EOA) or the zero address can be set as the token address. If stakeRewardToken is set to an address without any code (e.g., an EOA), all subsequent calls to functions that interact with the token via safeTransfer or safeTransferFrom (e.g., stake(), unstake(), claim(), depositRewards()) will revert. This would cause a permanent denial of service for all core contract functionality, effectively freezing all staked assets in the contract until the owner sets a valid contract address.
Pending
#2 medium Issue
Inaccurate Accounting for Fee-on-Transfer and Rebasing Tokens Leads to Contract Insolvency
The contract is vulnerable to insolvency due to its flawed accounting method when interacting with non-standard ERC20 tokens, such as those with fee-on-transfer or rebasing mechanisms. It incorrectly assumes that the amount specified in a deposit function like stake() or depositRewards() is the exact amount of tokens it receives. For fee-based tokens, the contract receives a smaller amount than it records in its internal ledgers, creating a deficit between its actual assets and its liabilities to users. This deficit accumulates with each deposit, inevitably leading to a state where the contract cannot honor all withdrawal requests, resulting in a permanent loss of funds for the last users attempting to withdraw.
low Issues | 1 findings
Pending
#1 low Issue
Missing zero or dead address check.
It is recommended to check that the address cannot be set to zero or dead address.
informational Issues | 1 findings
Pending
#1 informational Issue
Floating pragma solidity version.
Adding the constant version of solidity is recommended, as this prevents the unintentional deployment of a contract with an outdated compiler that contains unresolved bugs.