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.
Token cannot be burned
There is no burning within the contract without any allowances
Ownership is not renounced
The owner retains significant control, which could potentially be used to modify key contract parameters.
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 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
ReferralClaim.sol
- The admin can update the admin and signer in the contract.
- The admin can set the claim token and claim time in the contract.
- The admin can withdraw tokens from the contract.
Note—This Audit report consists of a security analysis of the Mey Network Referral claim smart contract. This analysis did not include functional testing (or unit testing) of the contract’s logic. Moreover, we only audited one token contract for the Mey Network team. Our team did not audit other contracts associated with the project. We recommend investors do their own research before investing.
Files and details
Findings and Audit result
medium Issues | 4 findings
Resolved
#1 medium Issue
Missing check for past timestamp
The setConfig function lacks validation to ensure the provided _claimTime is not in the past, which can lead to significant issues. If a past timestamp is set for claimStartAt, users may bypass intended delays or restrictions for claiming tokens, leading to premature claims and logical inconsistencies in time-sensitive operations. This oversight can also create security risks, as a malicious admin could exploit it to trigger unintended behaviors. Adding a check to ensure _claimTime is in the future (_claimTime >= block.timestamp) resolves this issue, ensuring the integrity, security, and proper functionality of time-dependent operations.
Acknowledged
#2 medium Issue
The owner can drain tokens.
The emergencyWithdraw function allows the admin to transfer any token from the contract without restrictions, posing a significant risk. There are no safeguards to prevent claimable tokens intended for users from being withdrawn. This unrestricted access enables the admin to drain all tokens, including user funds, potentially leading to users losing their rightful claims. Additionally, if the admin account is compromised or acts maliciously, the entire contract’s token balance can be emptied. To mitigate this risk, safeguards like restricting token withdrawals, excluding claimable tokens, and requiring multi-signature approvals for sensitive functions should be implemented.
Acknowledged
#3 medium Issue
Improper Validation of claimStartAt
he function checks that claimStartAt > 0 and block.timestamp > claimStartAt, but it does not prevent future timestamps from being set for claimStartAt. The admin could maliciously or accidentally set a future timestamp, delaying claims indefinitely. No checks in the setConfig function ensure that claimStartAt is set to a reasonable value. It is recommended to add the check that the claim start time should be in the reasonable value.
Acknowledged
#4 medium Issue
Centralized Control of claimToken
The admin can set claimToken to any address, potentially redirecting claims to malicious or unintended tokens. Legitimate users may lose access to their allocated tokens or receive a worthless token. The setConfig function allows unrestricted changes to claimToken. It is recommended to check that the claim token is a contract address and it should only be changed before the claim starts.
low Issues | 5 findings
Acknowledged
#1 low 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.
Resolved
#2 low Issue
Missing zero or dead address check.
The function does not check that the signer address cannot be zero or dead. So, it is recommended to check that the addresses cannot be set to zero or dead address.
Resolved
#3 low Issue
Missing emit
It is recommended to emit all the critical parameter changes.
Acknowledged
#4 low Issue
Insufficient Balance Logic
The function checks the contract’s balance (thisBal) against the claimAble amount but does not handle partial claims if the balance is insufficient. Legitimate users may not be able to claim their allocated tokens if the contract’s balance is temporarily low, leading to failed claims. The condition require(thisBal >= claimAble, 'Not enough balance') causes the transaction to revert entirely if the balance is insufficient, rather than allowing a partial claim.
Acknowledged
#5 low Issue
Lack of Robust State Management
The function sets isClaimed[recipient] = true, but this flag is not effectively used to prevent repeated claims. The flag’s purpose is unclear as the main validation relies on totalClaimed. This redundancy can lead to inconsistent behavior or logic errors. Multiple checks rely on totalClaimed but not on isClaimed. It is recommended to add a check on isClaimed so that there cannot be multiple claim by the user.